tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-tapestry Wiki] Update of "Tapestry5LookupDebate" by GeoffLongman
Date Sat, 11 Feb 2006 21:09:02 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-tapestry Wiki" for change
notification.

The following page has been changed by GeoffLongman:
http://wiki.apache.org/jakarta-tapestry/Tapestry5LookupDebate

New page:
I find it confusing that Tapestry has so many ''rules'' for finding things like specifications
and templates.

At first, as the SpindleGuy I was not enamoured of the ability to prefix names with path parts
like
{{{
mycomponents/MyComponent
}}}
I understand the utility for end users but, boy, from a tool developers pov it's hard to support.

In discussing/debating the implementation of Tapestry5 I first want to say that I embrace
the above completely. I think it's possible to keep all the  existing utility and, with a
few tweaks, make tool development a whole lot easier.

First, since backwards compatilibity is not an issue and names with path parts is here to
stay I would propose that if at least the .application and .library files will stay around...
{{{

Remove <page> and <component-type> as they exist today.

Instead of a name mapped to a specification path, these should be replaced with two new (optional)
tags:

<page-alias name="" full-name=""/>

and 

<component-alias name="" full-name=""/>

where 'name' and 'full-name' have the same meaning in both tags.

name - a short name which is the alias of the full name (including path part) of the page
or component in the namespace. 
       'name' is a simple identifier with no path parts.

full-name - the full name, including path parts, of the page or component in the namespace.



}}}

Tapestry 3 was xml-centric in that the specification was the lynchpin. Howard has already
stated that, althought the implementation is incomplete in Tapestry 4, he sees the need for
the name (incl path parts) to become the lynchpin for the whole operation.

I think the above change is respectful of that intention. These two tags allow a user to optionally
define a short alias for any page or component in the namespace.

Secondly, I've been again looking at the ''rules'' for locating pages and components. I think
that with some simple tweaks these ''rules'' can be vastly simplified with little impact on
the utility of Tapestry.

First, the Tapestry 4 'rules' for locating components (from ComponentSpecificationResolverImpl).
{{{
<ul>
 * <li>As declared in the application specification
 * <li><i>type</i>.jwc in the same folder as the application specification
 * <li><i>type</i> jwc in the WEB-INF/ <i>servlet-name </i>
directory of the context root
 * <li><i>type</i>.jwc in WEB-INF
 * <li><i>type</i>.jwc in the application root (within the context root)
 * <li>By searching the framework namespace
 * <li>By searching for a named class file within the org.apache.tapestry.component-class-packages
 * property (defined within the namespace)
 * </ul>
 * The search for components in library namespaces is more abbreviated:
 * <li>As declared in the library specification
 * <li><i>type </i>.jwc in the same folder as the library specification
 * <li>By searching the framework namespace
 * </ul>
}}}

First, if the my first suggestion above for aliases was adopted we can cut out two rules right
away:
{{{
<ul>
 <removed>
 * <li><i>type</i>.jwc in the same folder as the application specification
 * <li><i>type</i> jwc in the WEB-INF/ <i>servlet-name </i>
directory of the context root
 * <li><i>type</i>.jwc in WEB-INF
 * <li><i>type</i>.jwc in the application root (within the context root)
 * <li>By searching the framework namespace
 * <li>By searching for a named class file within the org.apache.tapestry.component-class-packages
 * property (defined within the namespace)
 * </ul>
 * The search for components in library namespaces is more abbreviated:
 <removed>
 * <li><i>type </i>.jwc in the same folder as the library specification
 * <li>By searching the framework namespace
 * </ul>
}}}

What if the remaining could be further simplified, without losing any existing utility, to
this...
{{{
<removed>
 * <li><i>type</i>.jwc in the same folder as the application specification
<removed>
<removed>
<removed>
 * <li>By searching the framework namespace
 * <li>By searching for a named class file within the org.apache.tapestry.component-class-packages
 * property (defined within the namespace)
 * </ul>
 * The search for components in library namespaces is more abbreviated:
 <removed>
 * <li><i>type </i>.jwc in the same folder as the library specification
 * <li>By searching the framework namespace
 * </ul>
}}}

Wouldn't that be nice? I think it can be done with some adopted conventions and with a change
to where Tapestry currently creates a synthetic Application specification when the .application
file is missing.

The adopted conventions would be:

{{{
1. By convention, Tapestry looks for components according to these rules (insert the above
abbreviated list of rules).

2. By convention, if you are going to deploy multiple Tapestry application in the same .war
file and you have a .application file, it is expected that you will place it in the folder
/WEB-INF/name/ where name is the name defined for the servlet in web.xml. This convention
is not enforced at runtime. Its a recommended 'best practice'.

3. By convention, if you do not have a .application file Tapestry will install a synthetic
(invisible) specification. The synthetic specification will have a path and that path will
be:

   - /WEB-INF/name/name.application when the folder /WEB-INF/name/ exists and where name is
the name defined for the servlet in web.xml; or
   - /WEB-INF/name.application if the above folder /WEB-INF/name does not exist.
}}}



--I have to run, I have plenty to add to argue this case so pls don't tear it up too much
before I finish it this evening GeoffLongman

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


Mime
View raw message