At 10:27 AM -0700 4/18/00, Frank Kim wrote:
> > > Comments?
> > For method names, "build" and "perform" seem better.
> > The full sense of the method is completed by the
> > object.
>
>I agree. At this point I don't think we need to worry about these semantic
>details esp since the names are not extremely bad.
Thanks for the comments.
I agree with keeping the names simple: build, perform, as George's
comments are valid (full sense of method is completed by object).
The only problem I see with this is that since 'build' is already
widely used throughout the code, there may be some migration
confusion. I think it's acceptable to have the confusion as users
switch to overriding 'doBuild' instead of 'build'... comments?
This leads to the other question and discussion:
At 10:32 AM -0700 4/18/00, jon wrote:
>You did a good job of explaining what you would change in the Proposed
>Return, but not *why*.
>
> > Also, 'buildAction' didn't sound right to me... so I put in
>'performAction'.
>
>I'm +1 on the name changes, just not the return changes until you give me a
>reason why. :-)
To answer your question, let me make sure first that I understand the
objects...
There is currently one base class called 'assembler' and the types of
'assembler's currently defined are:
-------------------------
Assembler - Action
- Page
- Layout
- Screen
- Navigation
- ScheduledJob
-------------------------
'Action' really doesn't ever create content... It carries out
actions. It should clearly not return a value representing content.
'ScheduledJob' also doesn't create content... It carries out a
scheduled job. It should not return a value representing content.
The rest of the objects ('Page', 'Layout', 'Screen', 'Navigation')
are there to create content. So it seems that they should all have a
similar method structure: return a value representing the screen
content. (Jon, this is my answer to your question).
Additional observations are that the objects 'Page' and 'Layout'
represent compositing of other objects. 'Page' executes actions and
determines the HTML document type; 'Layout' doesn't. Still, could
they be merged into a more useful common class called 'Composite'?
The objects 'Navigation' and 'Screen' return content directly without
compositing. I don't see substantial difference to 'Navigation' and
'Screen'. Could they be merged into a single class called 'Component'?
-------------------------
Action
Assembler - Composite - Page
- Layout
- Component - Screen
- Navigation
ScheduledJob
-------------------------
Then the class 'Assembler' could be defined as 'class representing
the ability to assemble content for a page'. A single loader could
then be used for 'Assembler's.
Just some thoughts...
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
