Some constructs are easier to express in XML than inside the HTML; typically, complex OGNL expressions.
When building base pages from which you may extend (or base components), using annotations is great because it provides an inheritance mechanism. Tapestry 3.0 and earlier didn't have any kind of inheritance mechanism ... often, many different subclasses would have to include identical snippets of XML. I widely use a mix of all three, depending on the situation. It's a bit too late to get this perfect in Tapestry 4.0. What's there is good enough, consider it a kind of "trial balloon", that leaves plenty of room open for later improvements. I, too, would like something less clunky than the current annotations and I have some ideas for this for 4.1 ... basically, methods to invoke inside finishLoad() to provide bindings for parameters there, rather than in annotations (or in templates or in XML). However, unlike Wicket (and JSF), I'm very comitted to the basic premise that Tapestry pages are static in structure, and consistent between instances (and between servers in a cluster). Therefore, the style of "new For()" discussed in this message is not a good fit, it opens up Tapestry for many impossible to trace errors. Instead, Tapestry will continue to be highly dynamic when rendering (via Block/RenderBlock and friends). We'll have to see where Wicket goes, but anyone who has worked on Tapestry 4.0, with its extensive support for injection, will certainly find that somewhat missing in Wicket's simpler model. On 11/15/05, Matt Welch <[EMAIL PROTECTED]> wrote: > What are the downsides of defining the components in the template > itself? The only one I see off the top of my head (and it's not minor, > I grant) is that if your web developer isn't also an application > developer, there a greater chance the component definitions will get > mangled when all that information is in the template. Anything else? > > Matt > > > > On 11/15/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > > yes - thats it. > > you can define the components using annotations which is quite ugly, > > then you can define them in your html template, > > then you can define them in your .page (for page classes) or .jwc (for > > component classes) xml specifications. > > > > Ofcause, if you wish your head to spin real bad you can also mix all > > three :) > > > > > > ציטוט Matt Welch: > > > On 11/15/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > > > > > >>You are right, component annotations are clumsy. But, currently there > > >>are 3 ways to define a component in a page - you might find .jwc or > > >>.html way more apealing, and still use annotations for injecting or > > >>setting defaults - that way you still can use what you like > > >>(annotations) *and* convenient component defs. > > > > > > > > > Ron, could you go into a little more detail about what you're > > > describing here? What is the ".jwc" way? Is that the same things as > > > the xxx.page XML file way? I assume the HTML way is by using implicit > > > components. > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > -- 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
