Just got through reading the responses to my concern, and it looks like what I need (multiple templates using a single class) will be supported somehow. I'm not averse to a bit of customization being required for this, but it strikes me as a common enough issue that the customization required should be minor. It seems that without support for this, Tapestry's answer to the common question "How do I do a simple HTML include?" is "Create a Java class!", which will drive away developers. As for some of the other ideas on this thread and from the post that Geoff quoted: mix-ins: Love the idea, especially if they can provide parameters to the containing component. We're already using behavior-only components to simulate a mixin like concept, and the parameters are key. > - Annotations based. JDK 1.5. > - No XML for pages and components. Just HTML and Annotations. > - Concrete, not abstract, page and component classes When bringing a new developer up to speed on Tapestry, I find that there are two areas that they immediately question, and require lots of explaining: abstract class proliferation, and exceptions for redirecting. Concrete classes would be a big help with the first (and queue-based rendering with the second). I do see one possible downside to concreteness. The enhancement process, before you understand it, looks like magic. Abstractness makes it obvious where the magic is happening...the abstract methods must turn into something, otherwise the class can never be instantiated. If the magic starts happening to my concrete methods, will it be obvious how and when they're going to change? Will concrete code that I write (say, property getter/setters) be overwritten by T5's enhancement process? In the end, I think I'd take a little confusion here over the current all abstract state of things, but it's something to consider. > - No inheritance imposition One of my biggest beefs with Tapestry's current class structure is that I can't have a Form component (that derives from AbstractFormComponent) that also has a template. There are workarounds, but this is exactly the kind of thing that inheritance based systems get wrong. Flattened class structures + mixin/injected behaviors are the way to go. > - Change detection; automatic invalidate and reload of changed objects > (including Java classes) Please! We had a requirement to change our templates multiple times per-day, while under load. I ended up writing a replacement template and page loader that could handle this cleanly without simply flushing every cache in the system and bottlenecking. > - Vastly simplified API > - Clear deliniation between public/stable and private/internal/unstable APIs Noble idea, as long as the implementation of this doesn't make it any harder for me to replace or modify pieces of the infrastructure. One of the reasons I chose Tapestry for Zillow was that it had both 1) a well-written and commented codebase that I could mine and understand, and 2) I could relatively easily replace those pieces that I found wouldn't work for me. I really hope this continues. jeff
________________________________ From: Geoff Longman [mailto:[EMAIL PROTECTED] Sent: Sun 2/26/2006 1:42 PM To: Tapestry development Subject: Re: [Discuss]long - Tapestry 5 stuff. comments inline.... On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > My only issue with "the component is the class" is for components, > especially simple pages, that simply do not have a Java class. This > is an edge case and, to be honest, if I had to pair up each > > HelloWorld.html > > with > > @Component > public class HelloWorld > { > } > > > I would not loose much sleep. But I also think it should not be > necessary, if com.myco.myapp.pages.HelloWorld does not exist, Tapestry > should (at most) emit a warning, and work around that. > > I still think, from the point of view of something like Trails, that > we want the ability to either work around a missing component class, > or fabricate the component class on the fly. This will take some > noodling. Well, a new class, created by hand or by fabrication has a unique place in the classpath so I think that would satisfy "the component is the class". The trick and the noodling is to craft a way to associate the fab class with it's template in way that's not too arcane. Solving it for the no class case would probably go a long way to solving the other edge case: "default classes". (Which would make Jeff happy). > > And I still want to stick with the basic premise that Tapestry pages > are static in structure, and dynamic in behavior. I think that is > still very important from both a tools point of view, and from a > runtime efficiency point of view. Yep, I think T4 strayed away from this enough to cause the grief I'm having now. And T4's runtime efficency trips a bit on it too. One name can resolve to mulitple classes but once T4 finds a class, that's it - there's no chance that other class can play role. > > I think we are aggreeing ... page name --> FQCN is the goal, the > question is how the FQCN can be encoded and abbreviated. Hooray! > > Geoff, what did you think of my "mount points" idea? I'm going to give it some more thought and respond this evening. Geoff > > On 2/26/06, Geoff Longman <[EMAIL PROTECTED]> wrote: > > On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > <snip> > > > My idea so far has been that we map directly from the path to a page name. > > </snip> > > > > One big problem with Spindle + T4 is that the page name has this > > special status as the focal point. > > > > Before T4 the spec object was the focal point. This was great as the > > was usually built from a xml file which is a static entity and static > > entities are what tools have to work with. And files are the easiest > > thing of all to "find". Allowing for some exceptions > > (<page>/<component-type> tags) it was a reasonable to infer the name > > of the page/component from the name of the spec file. Again with some > > exceptions the class and template "finding" was unabiguous - a spec > > had one class and one template. > > > > In T4 the focus moves to the name a developer uses to reference the > > page/component. And that focus is completely ambiguous as to what > > class/template applies. It depends on the context in which the > > developer uses the name. Tools either have to build a massive map of > > all possible combinations of name/class/xml/template (most of which > > are never going to be used) or impose artificial rules to make the > > task manageable. > > > > I found out quickly that IDE users are not interested in more "rules" > > on the use of the tool. > > > > Simply pasting even more rules on top of this inside Tapestry does not > > go to the root of the problem and only has a minor benefit in tools > > w/respect to reduced complexity. > > > > Turn the focus away from the spec object to another static entity. > > We've already left xml behind as a possible focus so that leaves only > > the template and the class. I think everyone would agree that the > > template is not the right choice which leaves the class. If the class > > is the 'king' then the spec object becomes a subordinate player as it > > should be. > > > > The fqn of the class becomes the name of the page/component and it > > just becomes an excercise in allowing developers to use 'simpler > > names' that map to the fqn. All the pieces are there now to do this. > > > > I fail to see why "the class is the page/component" (a poor statement > > of this concept of focus) is unreasonable. > > > > Geoff > > > > -- > > The Spindle guy. http://spindle.sf.net > > Get help with Spindle: > > http://lists.sourceforge.net/mailman/listinfo/spindle-user > > Blog: http://jroller.com/page/glongman > > Feature Updates: http://spindle.sf.net/updates > > > > --------------------------------------------------------------------- > > 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] > > -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Blog: http://jroller.com/page/glongman Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- 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]
