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]
