Jesse, I too am not sure how Howard was planning to address 'non enhanced' pojos. Perhaps it's related to these from Howards original post:
- Concrete, not abstract, page and component classes and - Transforming class loader driven by annotations (i.e., @Persist on the field, not the method) If you get rid of the xml then all you have left is annotations. If Pojos are concrete, how much enhancment is left? *You* have to have concrete getters/setters and a field declaration for all fields. I guess one would need *something* for @Persist fields (fireObservedChanged). But other than that the 'peer' could read the annotations and perform the sets/injects/whatever without any enhancement. In fact, now that I have written the above it appears that the only enhancement case left is @Persist! Of course if the Pojo was a true bean and fired java.beans.PropertyChangeEvents then you would not need to enhance for @Persist either. Geoff On 2/26/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > 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] > > > > > > -- 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]
