[Jakarta-tapestry Wiki] Update of "Tapestry5LookupDebate" by GeoffLongman

[Apache Wiki <wi...@apache.org>]

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