tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Longman" <glong...@gmail.com>
Subject Re: [Discuss]long - Tapestry 5 stuff.
Date Sun, 26 Feb 2006 17:14:00 GMT
Well, what I'm suggestion are possible conventions for T5. Tapestry
has always provided mechanisms to "step outside" the conventions in a
fairly easy way.

Some examples of existing ways to step outside of the T4 conventions:


No reason why the "one Pojo used by many pages/component" case
couldn't be handled this way.


On 2/26/06, Jeff Lubetkin <jefflub@zillow.com> 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:glongman@gmail.com]
> 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.
> 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.
> "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 ..@staticfield"/>
>     </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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

The Spindle guy.          http://spindle.sf.net
Get help with Spindle:   
Blog:                     http://jroller.com/page/glongman
Feature Updates:          http://spindle.sf.net/updates

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message