> > Basically, some of the 'Assemblers' treat the 'build' method in one
> > of two ways:
> >
> > 1 - construct the page and return it as a concrete element
> > 2 - store the page into the document created when
>'RunData.getPage' is invoked
>
>Correct. There is also a 3rd short circuit that allows you to write directly
>to the servletoutputstream. See the Screen "ImageServer" for an example of
>why this is necessary.
This is definitely nice functionality [ImageServer].
>RunData is NOT global. Well, it is in the perspective of a single invocation
>of Turbine, but it is unique across invocations. It isn't and should not be
>cached or have stored as data ANYWHERE.
I meant it in the sense of 'per invocation'.
> > Is the multiple definitions of 'build' intentional or a result of
>> migrating code? Is anyone else concerned about this? Is anyone not
>> concerned? Should we try to do something to clear up the definition a
>> bit?
>
>It is intentional....the modules all subclass Assemblers, right? :-)
>
>The intentional behavior may or may not be "right", but I did work it that
>way because Modules are essentially the same but are re-purposed and
>extended for their own specific needs. ie: Layout is not the same as Screen,
>but it is close.
It's good functionality, just a bit confusing to new users like me
maybe. I think I'm starting to get it now...
On a more pragmatic note:
What do you think about changing the return types on Layout and Page like this?
Assembler: New Method: Current Return: Proposed Return:
---------- --------------- --------------- ----------------
Action performAction void void
Layout buildLayout void ConcreteElement
Navigation buildNavigation ConcreteElement ConcreteElement
Page buildPage void ConcreteElement
Screen buildScreen ConcreteElement ConcreteElement
Also, 'buildAction' didn't sound right to me... so I put in 'performAction'.
Comments?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
