Yet another option is to use implicit components in your html template.
Makes your template uglier, of course, but... :)
Robert Zeigler
Nick Stuart wrote:
> Well isn't this already possible at the moment with 4.0 (minus the
> fact that you still need some kind of JWC or PAGE file)? Basically
> just have your support class hold all the spec stuff (annotations and
> such) then have your actual page class where the listeners and stuff
> are extend that. Your support class will all extend AbstractPage or
> Component and still be abstract.
>
> I kind of like this idea, minus the fact it adds another file to keep
> track of, but doing it all in Java and not XML helps a bit in that
> respect. Overall I think its a good idea, and the main thing to get
> rid of is the whole XML file altogether, or at least make it optional.
>
> -Nick
>
> On 7/1/05, Phil Zoio <[EMAIL PROTECTED]> wrote:
>
>>In the choice of whether to use annotations or XML for adding
>>functionality to a page is big one, which raises a lot of issues:
>>
>>Annotation +ves
>>- annotations make component and page inheritance much easier (even
>>possible!), because decorations definitions can be overridden in subclasses
>>- need to maintain 2 files instead of 1, per page
>>
>>Annotation -ves
>>- clumsy to configure, perhaps
>>- the side effect of introducing a getter to the page. If your
>>application code does not need the getter, then why should it be there?
>>The page/component class gets cluttered with extra methods not relating
>>to the direct responsibilities of the page class
>>
>>One alternative ... have a concept of a PageSupport class (optional). If
>>this is not there, then the specification loader will attempt to read
>>from the XML specification.
>>If it is there, then it can be used for annotation definitions (Beans,
>>Components, etc.) - stuff not ordinarily needed by your application code
>>in the page itself.
>>ASOs and services can still be injected into the main page class. You
>>could inject the page support class into the page class
>>
>>That way you get
>>- uncluttered application page classes
>>- an inheritance hierarchy for addon definitions
>>
>>OK, you end up with 2 Java classes instead of one, but I still prefer
>>the idea of having more classes with clear responsibilities than fewer
>>cluttered ones with divided responsibilities
>>
>>Just a thought - any comments?
>>
>>
>>Kent Tong wrote:
>>
>>
>>>Hi,
>>>
>>>It seems that Howard is going to migrate from page specification
>>>to annotation. While I understand that for stuff like page
>>>properties, annotation is better than the page specification,
>>>but I really don't understand why we should specify the components
>>>using annotations like:
>>>
>>>@Component(type = "Conditional", bindings =
>>> { "condition=message", "element=div" })
>>>public abstract IComponent getIfMessage();
>>>
>>>After all, a component and its bindings have got very little to
>>>the getter. In fact, we may not need that getter at all. The
>>>bindings are also very clumsy to write.
>>>
>>>--
>>>Author of an e-Book for learning Tapestry (http://www.agileskills2.org/EWDT)
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
