There is one in particular from tacos whom I think might make a good addition here, but I wasn't sure when/if to bring it up. He's starting to take over a lot of things I used to do and is in general doing a great job. (Andreas)
The dev I was speaking about was someone else though, used to be a contrib to jboss before they split and ran ;) Is now doing a lot of RoR / other work...(he also used tapestry a lot during 2.0 I think) Since I'll be working directly with him professionally and we'll be more or less relying on tapestry/hivemind ' s success to boost our own I don't think it'll be very hard to motivate him. (assuming the community supports it ) He's a much better coder/architect than me, so I'm really hoping we can get him in here eventually. j On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > What's life like in the Tacos community? Is there anyone there who > could/should move up to Tapestry committer? > > On 2/26/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > > -- > 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] > >
