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.
Jeff is talking about one class (domain logic) having many templates not many templates having no class. I'm suggesting that this case not be handled by convention but rather by customization (one of those resolver delegate interfaces). BTW - "Tapestry will use some kind of template class when a real class is not provided." is confusing. You mean a 'default' class right? > > My idea so far has been that we map directly from the path to a page name. Absolutely, and I take this one step further path->page name->class > > 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 see where this is going... > > I'll get to mixins shortly. Good, 'cuz my blood pressure just spiked :-) > > > 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. What I suggested is a kind of "automount" like HiveMind has with /META-INF/hivemodule.xml. What is today the <library> tag would become an alias mechanism to disambiguate libraries that have the same "name" (Say another, unaware, developer called thier library 'tacos'). > > 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. Of course. > > 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. This is the OPTION 1 in my first message. I bounced that idea off users in the Spindle-dev list an it went over like a lead balloon. Too restrictive. User's want the freedom to place thier stuff anywhere they like and let Tapestry sort out the mess. As as an example of the impact of OPTION 1 one would have to repackage the framework/contrib/inspector libraries to avoid undesirable overlap. OPTION 2 is a tradeoff that left complete control in hands of developers but still made it easy to detect boundary crossing situations. > > 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. ok, I don't understand this. > > 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. Cool. can't say I understand any of it but cool. > > 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. Zing! Right over my head! I'm wary of this. Without understanding any of it it sounds like this makes Tapestry 5 even more complex (harder to learn) for the end user. Not mention I have no clue how a tool, Spindle/tapidea/Component Ref gen, would be able to sort it out. > > 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] > > -- 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]
