You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Longman <gl...@gmail.com> on 2006/02/26 07:48:46 UTC
[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 ..@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
Re: [Discuss]long - Tapestry 5 stuff.
Posted by Geoff Longman <gl...@gmail.com>.
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 <jk...@gmail.com> 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 <gl...@gmail.com> 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
> > ..@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
> >
> >
>
>
--
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
Re: [Discuss]long - Tapestry 5 stuff.
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <gl...@gmail.com> 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
> ..@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
>
>
Re: [Discuss]long - Tapestry 5 stuff.
Posted by Geoff Longman <gl...@gmail.com>.
I've been thinking about the page/component xml files some more.
If they're out for T5 they are out. end of email.
If they were to stay in this form only:
On 2/26/06, Geoff Longman <gl...@gmail.com> wrote:
<snip!>
>
> There is only one case: keeping cruft out of the templates.
>
<snip!>
> I say keep the xml, but collapse it so that only <component> and
> <meta> tags are allowed.
(BTW <meta> should be dropped too, replaced by annotations)
Then the xml falls out of any primary role in instantiating a page and
only comes into play during the later stages of the PageLoader's work.
That is, the part that builds the component tree.
I say link this stripped down xml to the template (somehow) since (in
my world) it no longer plays a role in instantiating the page - it's
just used to build the component tree. It's now just a facet of the
template.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org