Mixins! That's a super kickass idea :) As for the 4.1 - 5 time period, I'm hoping that after the initial ajax work is done (I think I'm about done mulling over the new rendering logic) I can provide a little more support in the general framework area so that there is more breathing room for all the tap 5 dev. If things continue on as planned I might even be able to enlist the help of one other dev. (maybe, I'm still working on him... )
j On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > A few thoughts ... > > To Jeff (not Jeff's) concern; a page class w/o a template should still > be acceptible. Tapestry will use some kind of template class when a > real class is not provided. > > My idea so far has been that we map directly from the path to a page name. > > The application will have a standard package name, let's call it > com.example.root. > > You will put your pages under com.example.root.pages and your > component under com.example.root.components. Further, you will put > your mixins under com.examples.root.mixins. > > I'll get to mixins shortly. > > > The first part of your application configuration will be to define > what this root package is. I'm not sure where or how yet; probably > inside web.xml. > > The T4 approach of mapping sub-folders to sub-packages will still hold. > > In addition, you'll be able to "mount" libraries as virtual folders. > > So, you can mount "tacos" to net.sourceforge.tacos and page names of > the form "tacos/Foo" will be search for under net.sf.tacos.pages. > > Again, not sure where this configuration will go. Possibly in web.xml. > > As today, there will be a special case where components not found in > the local namespace are searched for in the framework namespace. > > I think there should be some checking to ensure that packages are not > nested within other packages. This should remove the ambiguity that > plagues Geoff and Spindle. > > Page vs. Component > > I think IPage extends IComponent was one of the design mistakes of > Tapestry. For T5, the page will be present but not generally visible > or useful to the application developer. Every page will have a root > component. When you provide a page class, you are actually providing > the class for the page's root component. There will be only one > implementation of the Page interface, internal to Tapestry. > > Mixins > > I've been designing the flow-of-control for rendering very differently > from Tapestry; in fact, more like JSP tags (but not as horrible). The > JSP tag API was designed so that you could perform the render using a > queue, not tail recursion. I don't know that any servlet containers > actually do this (a consequence of the standard JSP compilers), but > Tapestry 5 will. This is great ... no more thrown exceptions for > flow-of-control. With the way queuing will work, flow of control will > alternate between user code and Tapestry code. I want to avoid the > giant stack traces of Tapestry 4. > > I have about four stages (maybe more coming) for rendering a > component, forming a little state machine. > My concept is that, instead of implementing an interface, you will > annotation ordinary methods with corresponding annotations. Like T4 > listener methods, the methods will be flexible in parameters and > return values. > > Having these seperate methods means that you have many "join points", > thus mixins. > The mixins hook into lifecycle states. Basically, mixins are "partial > components" that can be applied to a component's implementation, or > into the use of a component. A mixin will add behaviors and possibly > parameters to a component. > > I think a lot of the form handling and Ajax logic can be added this way. > > Have to shower/pack now ... headed to SF for a couple of days. > > > 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] > > > > > > > -- > 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] > >
