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]
