Re: page annotation vs specification - an alternative

[Phil Zoio <ph...@realsolve.co.uk>]

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: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: page annotation vs specification - an alternative

[Robert Zeigler <ro...@scazdl.org>]

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 <ph...@realsolve.co.uk> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: page annotation vs specification - an alternative

[Phil Zoio <ph...@realsolve.co.uk>]

With annotations you get the opportunity to effectively move the 
contents of the spec file into a Java class. The question is where is 
the best place to put the annotations within your application class 
hierarchy. Currently this is the page class itself - the annotation 
processor will only add your annotated definitions to the page 
specification if they are present as annotated getters in the page class.

My suggestion is that there may be a better place to put these 
annotation definitions than the page class. For the most part, the 
contents of the spec file is used to "help" the HTML - component 
definitions are an example. For the most part, the spec file contents 
are not needed by the page class itself. There are obviously exceptions 
(such as validation within the page class), but generally your page 
class methods don't usually need references to the components and 
validators themselves, and even when they do, they don't usually need to 
know how these objects are configured.

(Of course, I'm not thinking of ASOs and services, which need to be 
directly accessible to the page class)

Suppose there are two pages in your application which are almost the 
same, and have some common component and validator definitions.

With annotations in the page class, to get reuse of definitions, you could:
- put all these component and validator definitions in a common base class
- put overriding or additional definitions in the page classes

The trouble is that you also use the inheritance hierarchy for other 
purposes other than sharing spec definitions. For example, you may be 
using the base class for common application specific tasks, such as 
validating logins, etc. I think you could end up having quite messy page 
classes. They already do quite a lot even without annotation definitions.

By having a separate "page support" class that the framework can look in 
for annotation definitions may be useful, because it would allow you to 
keep your page classes clean. You could enable sharing and inheritance 
of annotated definitions to operate independently of inheritance within 
page classes (just the GoF Bridge pattern)

Probably a pipe dream at late this stage but at the moment I see a risk 
of annotations making page classes look pretty messy

Phil



Nick Stuart wrote:

>Well, it wouldn't upset the page Hierarchy if you made use of this
>mainly for Components and not pages, and there is nothing stopping you
>from putting the annotations and everything else in an interface and
>simply, "Implement it and forget it!"  :)
>
>And I guess I'm missing the cut off of what you consider the page
>class vs the page template and really what would be in one but not the
>other. I see the template as the HTML file you write, which is
>supported by the spec file and may or not be backed by a class.
>
>Your idea of two inheritance hierarchies may be a good one, but
>explain a bit further :)
>
>-Nick
>
>On 7/1/05, Phil Zoio <ph...@realsolve.co.uk> wrote:
>  
>
>>I take your point regarding using the superclass of your actual page
>>class as your "page support" class. The problem I see here is that this
>>would interfere with your page inheritance hierarchy. Also you would not
>>be able to indepedently subclass the page support file.
>>
>>I guess the main part of the idea was whether it would be useful and
>>make sense to have two inheritance hierarchies, one for the page class
>>and one for attaching functionality to your page needed by the template
>>but not the page class itself?
>>
>>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 <ph...@realsolve.co.uk> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: page annotation vs specification - an alternative

[Nick Stuart <ba...@gmail.com>]

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 <ph...@realsolve.co.uk> 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: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org