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 ------------------------------------------------------------------------------ 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. + + 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 synthetic. 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 applications. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
