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 <[EMAIL PROTECTED]> 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 <[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]
