Well, what I'm suggestion are possible conventions for T5. Tapestry has always provided mechanisms to "step outside" the conventions in a fairly easy way.
Some examples of existing ways to step outside of the T4 conventions: ITemplateSourceDelegate ISpecificationResolverDelegate No reason why the "one Pojo used by many pages/component" case couldn't be handled this way. Geoff On 2/26/06, Jeff Lubetkin <[EMAIL PROTECTED]> wrote: > It's late here in Seattle, and I'm headed to bed, but I wanted to react to > one thing in your message before I process the rest of it. > > Geoff wrote: > >What if the developer doesn't want to write a class at all? > > >Too bad, "the class is the page/component". > > I'm not sure if we're the common case, but this would make Tapestry 5 > unusable for my company's purposes. We have many pages of "content" which > are be based off of a single class, and were built by our HTML developers > with no Java developer assistance whatsoever (after the default class was > built). The combination of annotations, specless pages, implicit components, > and a default page class allow us to do this. Not only are we able to > create these pages without a Java developer, but we can deploy these pages > without propping any Java code, which is much more tenable operationally. > > Most of the goals of T5 are laudable, and are things I'd love to see in the > framework, but I certainly hope that the move toward those goals doesn't > prevent me from using it. > > jeff > > > > ________________________________ > > From: Geoff Longman [mailto:[EMAIL PROTECTED] > Sent: Sat 2/25/2006 10:48 PM > To: Tapestry development > Subject: [Discuss]long - Tapestry 5 stuff. > > > > I want to throw out some ideas about the upcoming work on Tapestry 5. > Everyone wants T4.1 and T5 to happen a lot quicker than T4 did. I'm > focusing on T5 in the hopes that getting some discussion going will > help grease the wheels. > > I'm not putting this on the wiki at this time. > > First, I made some statements here > http://wiki.apache.org/jakarta-tapestry/Tapestry5LookupDebate which I > now think are somewhat flawed as I was approaching the topic from a T4 > pov which is not applicable as I think T5 is a whole different beast. > > I'm looking again as the statements Howard made in > http://www.nabble.com/forum/ViewPost.jtp?post=2687072&framed=y and at > the resulting responses and it looks like: > > - The scope for T4.1 is a 'tweaking' of T4. > - T5 is a world changer and the changes will vastly alter what > Tapestry 'is' without much thought given to backwards compatibility. > > Assuming the following as a starting point for T5: > > (from Howards post) > - Annotations based. JDK 1.5. > - No XML for pages and components. Just HTML and Annotations. > - Concrete, not abstract, page and component classes > - No inheritance imposition > - Transforming class loader driven by annotations (i.e., @Persist on > the field, not the method) > - Change detection; automatic invalidate and reload of changed objects > (including Java classes) > - "Modern" templates: Templates as well formed XML, using a namespace > for Tapestry attributes and elements > - A "preview" mode for pages > - Partial rendering of pages (for Ajax operations) > - Improved management of page state (including dynamic state during the > render) > - Vastly simplified API > - Clear deliniation between public/stable and private/internal/unstable APIs > > I want to initiate some discussion based on a subset of the above: > > - Annotations based. JDK 1.5. > - No XML for pages and components. Just HTML and Annotations. > - Concrete, not abstract, page and component classes > - No inheritance imposition > > (I have an case for keeping a (modified) form of the xml for > pages/components as an optional item but that's an argument for a > later time) > > So we are talking about Tapestry developers writing concrete Pojos > instead of abstract classes that inherit from Tapestry classes. A __ > good idea__. > > In T5, in a statement similar to Sun's "the network is the computer", > the goal is that "the class is the page/component". Howard has said > this was the goal he was working towards when building T4. In T4 the > implementation of that goal is incomplete. The java class is not the > main actor in T4, the actual class *used* is ambiguous depending on > the name used to reference a page or component. It was also possible > for the same name to resolve to different classes in some contexts. > > In a world where "the class is the page/component" the name used to > reference the page or component is irrelevant. All 'namings' that > resolve to one class are referring the same page/component. (It would > be nice to have a few namings as possible!). > > Sidebar - as I progress it will become clear that the various Tapestry > "lookup rules" will move from a complex task to a much simpler one as > the whole lookup mechanism was designed in T3 to find xml files > (gone?) and was just tweaked in T4 in the move towards "the class is > the page/component". > > So, in T5 a page/component is a concrete pojo and there is no > inheritance requirement. > > Let's ignore the concept of namespaces for a moment. Now that "the > class is the page/component" there is a natural naming for any T5 > page/component. That naming is the fully qualified name of the class! > (Don't freak out yet, remember we are ignoring namespaces right now). > > How does T5 decide that a particular Pojo is a page/component? > > I would suggest the following (obvious) requirement: > > "Pojos are Tapestry pages/components if and only if they contain, > directly, an @Component or @Page annotation" > > In T4 a component class need not have the @Component annotation and > there is no @Page annotation. The 'componentness" or "pageness" of a > class was based on the results of the "lookup" and even the @Component > annoation was optional to maintain compatibility for developers not > using JDK1.5. There is need to make @Component or @Page optional in T5 > as JDK 1.3/1.4 will not be supported. > > In the spirit of "start of strict and relax things later" I would > suggest that the statement I made previously: "All 'namings' that > resolve to one class are referring to the same page/component" be > implemented in a strict fashion in T5. > > What does this mean? Well, in T4 it's possible to specify no class at > all and (with customization possible) BaseComponent or BasePage would > be used as the class. Or, use the same class for more than one page or > component. In Pojo world the former sentence is gone anyways as > BaseComponent and BasePage make no sense if there is no inheritance > from Tapestry classes. The latter sentence is not possible since the > "the class *is* the page/component". > > So what if a developer creates a component Pojo and wants to base many > other components on the same pojo? > > Subclass it and add an @Component annotation. > > What if the developer doesn't want to write a class at all? > > Too bad, "the class is the page/component". > > The act of creating a class (perhaps by subclassing) "creates" an new > component in our, currently global, namespace. > > I think this is simpler and better than what's been done to date. What > have we gotten rid of? > > - BaseComponent and BasePage are already gone (No inheritance imposition) > - There is no ambiguity as to what *exactly* is a Page or Component in > the system. > - Resolving a name to a page/component is simplified - no need for > org.apache.tapestry.default-page-class > - Resolving a name to a page/component is even more simplified - no > need to check an xml file for a 'class' tag - indeed no need to find > the xml file at all (if they are still around). > > I think this would also make tools easier. Need to find everything to > generate a Component Reference? Just write an AnnotationProcessor that > gobbles up all the classes that have a @Component annotation. The fact > that one class relates to one component (and only one component) means > that such a tool no longer needs to re implement the old "lookup > rules" in order to find all the components. > > Now we have a global namespace containing a bunch of pages/components > identified by the fully qualified name of their classes. > > This: > > <span jwcid="@/org/apache/tapestry/contrib/ajax/XTile"/> > > is an awful way to have to refer to a component! > > In T4, the "lookup rules" provide the ability to refer to pages and > components by nicer, shorter, names. > > If anyone has paid any attention to my recent ramblings the current > facility for doing this leaves the door open for components and pages > to "cross namespace boundaries" and a lot of fun (not) can occur when > this happens. Howard has mused about adding code to check to disallow > these situations. I think that, in T4 anyways, it would be hard to do > and pretty hacky to boot. > > Since "simple names" are the main culprit in boundary crossing issues, > lets visit namespaces in T5 and see if we can't prevent it from ever > happening or at least make it easier to detect and disallow. > > First that global namespace of fqns, T5 should not allow anyone to > refer to a component in this way. period. Well, there is an exception > described later. By definition a global namespace crosses all > boundaries so let's stomp on that. That means the current T4 "rule" > that looks for a name relative to the default package is out > altogether or at least severely restricted. > > OPTION 1 > > Each namespace should declare it's boundaries and no other namespace > is allowed to cross them. That declaration would be in the form of a > package. "A package?" you say? Why not, isn't the word "package" a > pretty good description of a "container of stuff" which is what a > namespace really is anyway? > > Now, because each namespace declares a package as it's own, let's say > for now that every page/component class in that package or it's > descendant is 'owned' by that namespace. > > Checking for boundary crossing becomes easier, just check all the > packages of the namespaces in the app - if they overlap you have a > boundary crossing situation. > > This is radical and I don't think people will like it. It restricts > what packages they can use to locate thier Pojos. Plus, T5 I assume > will continue the tradition of being very lazy and not load up all the > namespaces up front so that "easy" check isn't really all that easy. > > OPTION 2 > > "Make each page/component declare it's namespace" > > Something like > > @Component{ns="contrib"} > @Page{ns="tacos"} > > Ok, that sounds as bad as the first option. But is it really? Every > class declares it's package. Every xml file that exists in Tapestry > today declares it's dtd (that's a kind of namespace too). Plus it > removes any need to impose draconian "rules" like OPTION 1. > > The trick is to make it a painless as possible. > > The first thing to do it make it optional for applications. If a > page/component does not declare it's namespace it's considered to be > part of the application namespace. This does leave the door open to > namespace boundary crossing in war files containing more than one T5 > app, but what can you do? A sacrifice for usability. The apps will > still run ok in most cases. This could be avoided if a developer chose > to declare the namespace for all of their application > pages/components. > > If the last paragraph is accepted we do know that the application > namespace and any library namespaces won't overlap since it's implied > that a namespace declaration is required for a library component or > page. > > We now have a scheme that allows developers to put their pojos > anywhere they like and Tapestry can easily check for an illegal > (boundary crossing) access: > > > <span jwcid="@contrib:inspector/Inspector"/> (legal in T4!) > > Would be illegal as Inspector would report it's namespace as > "inspector" and that's not "contrib". > > Pls, no complicated "rules" for determining the namespace of a > page/component based on it's location in the classpath. Is it really > that onerous to type ns="contrib"? Stay strict at first and relax > later. Like after I retire :-) > > Where does the "tacos" in @Page{ns="tacos"} come from? > > The <application-specification> tag currently has a 'name' attribute, > why not add that to the <library-specification> too? Should keep it > optional for applications and make it required for libraries. > > A neat side effect is that if Tapestry could discover all the .library > files at runtime then the <library> tag could become optional as each > library would declare it's 'name'. > > If we had this: > > <libary-specification name="contrib"/> > > then it would be possible to make: > > <libary name="contrib" > specification-path="/org/apache/tapestry/contrib/Contrib.library"/> > > optional. > > [ > ok i'm off on a tangent now. > How does tapestry discover all the libraries? Steal an idea from > HiveMind and do this for any "public" libraries: > > /META-INF/tapestry-library.properties (or xml or whatever). > > library=/org/apache/tapestry/contrib/Contrib.library > > or to borrow xml from Mike Henderson's Palette: > > <library id="groovestry" label="Groovestry" > preferredNamespace="groovestry" > specificationPath="/org/apache/tapestry/contrib/groovestry/Groovestry.library" > downloadURL="http://www.mjhenderson.com/tapestry/components/groovestry/groovestry-0.7.jar"; > version="0.7"> > > If T5 grabs all the tapestry-library files the same way HM grabs all > the /META_INF/hivemodule.xml files, it has "discovered" all the > libraries in the app. > > ] > > We have put somewhat strict checks on namespace crossing but have not > yet made it possible to refer to a page or component by a nice simple > name. > > 1. Add the <page-alias>/<component-alias> tags I described in > http://wiki.apache.org/jakarta-tapestry/Tapestry5LookupDebate. These > would be replacements for <page> and <component-type> which were only > used to find xml anyways. > > 2. Do the same thing Tapestry does now with the "lookup" rules. It > would be much simpler as we are not looking for xml specs any more ( > we'd still use org.apache.tapestry.page-class-packages and all that > guff). > > Ok, this message is already wayyyy to long. But I did mention that I > saw a case for keeping a (modified) version of the page/component xml > files. > > There is only one case: keeping cruft out of the templates. > > On the project I'm working on now we have an amazing HTML/CSS > developer and we try as hard as possible to make her life easier by > not using the @ syntax for components in our templates. > > This: > > <component id="tree" type="AjaxTree"> > <binding name="ajaxListener" expression="listeners.ajaxRequestStart"/> > <binding name="ajaxParameters" expression="ajaxPageState"/> > <binding name="cssclass" expression="currentCSS"/> > <binding name="label" expression="currentLabel"/> > <binding name="labelProvider" > expression="beans.datasource.labelProvider"/> > <binding name="selection" expression="selectedTreeNodes"/> > <binding name="labelSelection" expression="labelSelection"/> > <binding name="treeManager" > expression="beans.datasource.treeManager"/> > <binding name="treeProvider" > expression="beans.datasource.treeContentProvider"/> > <binding name="showingCheckboxes" expression="true"/> > <binding name="labelsSelectable" > expression="contentType == @...long class name [EMAIL > PROTECTED]"/> > </component> > > Is much better for her than the template alternative. > > I say keep the xml, but collapse it so that only <component> and > <meta> tags are allowed. > > Simplify the "rules" for finding these new xml files. Find the class > *first* and if it's in a library the xml must be in the same package. > If it's in the app namespace it must either be in the same package as > the class or at a point relative to the app xml location. Just two > rules! > > If you made it this far, thanks for your patience. > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
