2. Magma before serializing any PRDecorated looks to see if there
are any empty PRChildren and removes them before writing to its
buffers. [ I think that this will work , though I am not 100%
certain, but then we have PRChildren being created and destroyed
over and over.]
That should be fine, they don't have any semantics besides holding
3. Use an interface such as
aStructure withChildren: [ :children | children add: ( aNewPage ) ]
where #withChildren: cleans up afterwards.
There is such an interface already:
aStructure enumerator do: [ :each | ... ].
You can also configure it to walk recursively:
aStructure enumerator all do: [ :each | ... ].
Traverse hidden structure:
aStructure enumerator hidden do: [ :each | ... ].
Traverse the reciever:
aStructure enumerator with do: [ :each | ... ]
And all combinations of those.
4. Rewrite the commands above to use some form of visitor as you
I noticed that in the Seaside part of Pier the lookup of environments
didn't go trough visitors. I fixed that in Pier-Seaside-lr.80.
I also fixed a bug I noticed in Pier-Security-lr.35.
>> and an access interface defined for children... #addChild:
>> #childAt: #childAt:ifAbsent: #childAt:ifPresent:
>> #childrenIncludes: #removeChild:
> I don't see why this would help. As far as I see none of my code
> uses any of this functionality directly.
I think that you forgot the command actions #doExecute etc. see above
Yes, there might be more places where I violated my own design :-/
PRCommand-#validateName: aString of: aChildStructure in: aStructure
This one does not create a decoration, since it tests #hasChildren
before calling #childrenDecoration.
PRCommand-#uniqueName: aString in: aStructure
This one creates a new unnecessary decoration in some rare cases, I
will fix it as soon as possible.
These all add a child, therefor it doesn't matter.
I fixed that in Pier-Model-lr.80.
Fair enough, I thought as much, but when I found PRStructure-
#addChild: it indicated to me that you had thought of having a
child-accessing interface of sorts, and so I simply completed the
set to provide the functionality actually used in the image.
This is solely a convenience method to allow building trees of Pier
pages programmatically using cascades.
and so this enables things like
PRCommand>>uniqueName: aString in: aStructure
"Answer an unique structure name with the prefix aString within
the parent aStructure."
| index name |
and: [ aStructure childrenIn: [ :children | children
includes: aString ] ])
ifFalse: [ ^ aString ].
index := 1.
[ aStructure childrenIn: [ :children | children includes:
(name := aString , ' ' , (index := index + 1) asString) ] ]
would that be better?