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 Mon, 13 Feb 2006 01:53:15 GMT
Dear Wiki user,

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

The following page has been changed by GeoffLongman:

  I understand the utility for end users but, boy, from a tool developers pov it's hard to
  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.
+ The goal Howard has implied is that xml specifications are going to go away in Tapestry
5. While I'm uncertain that getting rid of them completely is the best goal (ex. getting rid
of <component> tags leaves us with cruft in the templates no?) I m certain that specification
objects that have Resource locations are going to stay around.
+ A lot of what I'm going to touch on is currently related to the locations of xml specification
files and how Tapestry finds them. Assuming that these specs go away doesn't really change
what I'm laying out as the specification objects will still be there, even if they are completely
  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...
@@ -34, +38 @@

- 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.
+ 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 names (incl path parts) of Pages/Components 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.
@@ -111, +115 @@

     - /WEB-INF/name.application if the above folder /WEB-INF/name does not exist.
+ So let's look at the rules that would be removed and I'll argue why they should be removed
and why thier removal is not catastrophic.
+ {{{
- --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 (was delayed and today is my son's birthday, more updates
soon) GeoffLongman
+ * <li>As declared in the application specification
+ and
+ * <li>As declared in the library specification
+ }}}
+ These two rules make no more sense if the <page-alias name="" full-name=""/> and <component-alias
name="" full-name=""/> of my first suggestion are adopted. The old <page> and <component-type>
tags mapped names to specification files. If the 'name' of the page/component is to be truely
more important than the xml file (and indeed if the xml is going away) then these new tags
make more sense, making it easier to reference a page/component (with a possible long name).
If the xml is gone or the path to the xml is no longer paramount, then the two rules above
are no longer needed and can be dropped.
+ {{{
+ * <li><i>type</i> jwc in the WEB-INF/ <i>servlet-name </i>
directory of the context root
+ }}}
+ I don't know if anyone has been paying attention to my ramblings (recently or at all) but
Tapestry allows pages/components to exist in more than one namespace. While I'm not enmoured
of this I can live with it if it's something that and end user would use as a tool with full
knowledge of the possible pitfalls and possible impacts.
+ But, I'm not happy that rules like the previous make it likely that user's will end up with
thier pages/components in multiple namespaces as a consequence of how Tapestry works and not
by a concious decision. In fact most Tapestry users would never be aware that this rule (and
others I would like to see go away) virtually ''assure'' that this state will exist in thier

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

View raw message