Mixing and matching (XML and annotations) works quite well.
Perhaps the biggest advantage is inheritance; base classes can use
annotations to define things that are inherited by page classes; in
3.0 you could provide abstract getters, but would require that each
page include a duplicated snippet of XML to support it.
In this example, the @Bean would likely go in a base class. In 3.0 and
4.0, I define a base class for all my application pages with a few
common things, like a validation delegate. I might have declared it
as:
@Bean(MyDelegate.class)
public abstract IValidationDelegate getDelegate();
The advantage here is the the @Bean means that the delegate is not
created until first referenced, and is discarded at the end of the
request.
I especially like annotations that don't correspond to anything in the
XML. My favorite is @Message (though I just discovered a bug in it
that I need to fix).
@Message
public abstract String getInvalidUserId();
Is the equivalent of
return getMessages().getMessage("invalid-user-id");
@Message
public abstract String tooManyAttempts(int delay);
The latter example doesn't work. It would be the equivalent of:
return getMessages().format("too-many-attempts", new Integer(delay))
On 7/6/05, Scott F. Walter <[EMAIL PROTECTED]> wrote:
> Luc Peerdeman wrote:
>
> > Hi Scott,
> >
> > It is interesting this is possible, however, I see this example more
> > as a good illustration of why the approach of 'everything in one file'
> > is not a good idea. I think it is ugly and not readable, and will
> > impact maintainability negatively. Furthermore, it is solving a
> > 'problem' that imho is not a real problem. Spindle will let me jump
> > between the parts of a component quite easily and that is all I need.
> > All aspects of a component have their own file which makes things much
> > simpler.
> >
> > Cheers, Luc.
> >
> > Scott F. Walter wrote:
> >
> >> Using Tapestry 4 beta, I was successfully able to create a standard
> >> page (which has validation with custom delegate) in Tapestry using
> >> annotations. I was then able to delete my page specification
> >> file. Will I remove all page specification files from my
> >> applications? Probably not, I will take it case by case. I will
> >> definetly be marking persistent fields as well as assets as
> >> annotations. Components will be another story, based on their
> >> complexity. Below is an example of having a page without a page
> >> specifcation file (I have included the contents of the page
> >> specification file in comments for comparison):
> >>
> >> public abstract class DataEntry extends BasePage implements
> >> PageRenderListener{
> >> /** Creates a new instance of Home */
> >> public DataEntry() {
> >> } @InjectState("visit")
> >> public abstract Visit getVisitObject();
> >> @InjectState("global")
> >> public abstract Global getGlobalObject(); /*
> >> <bean name="delegate"
> >> class="com.scottwalter.sandbox.tapestry4.MyDelegate"
> >> property="delegate"/>
> >> */
> >> @Bean
> >> public abstract MyDelegate getDelegate();
> >> public void pageBeginRender(PageEvent event) {
> >> if(getPerson()==null) {
> >> System.out.println("creating new person");
> >> Person p = new Person();
> >> p.setFirstName("Scott");
> >> p.setLastName("Walter");
> >> setPerson(p);
> >> }
> >> } @Persist
> >> public abstract Person getPerson();
> >> public abstract void setPerson(Person p);
> >> /*
> >> <component id="firstNameField" type="TextField">
> >> <binding name="value" value="ognl:person.firstName"/>
> >> <binding name="validators" value="required,minLength=3,myname"/>
> >> <binding name="displayName" value="First Name"/>
> >> </component>
> >> */
> >> @Component( id="firstNameField", type = "TextField",
> >> bindings = { "value = ognl:person.firstName",
> >> "displayName = First Name",
> >> "validators =
> >> required,minLength=3,myname"
> >> }) public abstract TextField
> >> getFirstNameField();
> >> /*
> >> <component id="lastNameField" type="TextField">
> >> <binding name="value" value="ognl:person.lastName"/>
> >> <binding name="validators"
> >> value="required,minLength=3,lastnamer=walter"/>
> >> <binding name="displayName" value="Last Name"/>
> >> </component>
> >> */
> >> @Component( id="lastNameField", type = "TextField",
> >> bindings = { "value = ognl:person.lastName",
> >> "displayName = Last Name",
> >> "validators = required,minLength=3"
> >> })
> >> public abstract TextField getLastNameField();
> >> /*
> >> <component id="ageField" type="TextField">
> >> <binding name="value" value="ognl:person.age"/>
> >> <binding name="translator" value="number,pattern=#"/>
> >> <binding name="displayName" value="Age"/>
> >> <binding name="validators" value="required,min=0,max=120"/>
> >> </component>
> >> */
> >> @Component( id="ageField", type = "TextField",
> >> bindings = { "value = ognl:person.age",
> >> "translator = number,pattern=#",
> >> "displayName = Your Age",
> >> "validators = required,min=5,max=10"
> >> }) public abstract TextField
> >> getAgeField();
> >> public void doForm() { }
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> I do agree, I don't think annotations should mean the elimination of the
> page specification file. First and foremost developers should be
> thinking about maintainability. As you can see from my little demo page
> if you have many components on page, using annotations will really start
> to make your page class unreadable or at the very least hard to
> understand. But annotations do have their place in my opinion, marking
> fields as pesistent and using assets.
>
> --
>
> Scott F. Walter Scott F. Walter
> Principal Consultant
> Vivare, Inc.
>
> E: [EMAIL PROTECTED]
> E: [EMAIL PROTECTED]
> Visit scottwalter.com <http://scottwalter.com> --Point. Click. Explore!
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
