This is only a completely passing observation, but I'm starting to see problems with having the xml files around for the pages/components myself...Which have not as much to do with looking up components but more about being able to do the non extension of component/page mechanism.
I don't know how it all works, but couldn't figure out how the component enhancement chain was going to be able to differentiate between normal methods and those provided by annotated services and such without using annotation-only strict rules. The idea being the these POJO friendly pages/components aren't ~really~ pure instances of the original class when it's all said and done...They could very well still be extended and have all sorts of unseemly things done to them by javassist later ....But, having those xml definitions makes it impossible to differntiate between what are injectable/whatever method and what are just some other kind of method... That's my take on it at least...Maybe howard has something planned in 5 that creates a pure POJO that isn't enhanced by anything, but it sounds pretty hard. :) j On 2/26/06, Geoff Longman <[EMAIL PROTECTED]> wrote: > > 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] > >
