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 ------------------------------------------------------------------------------ }}} - 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. + These two rules make no more sense if the `<component-alias name="" full-name=""/>` tag of my first suggestion are adopted. The old `<component-type>` tag mapped names to jwc files. If the 'name' of the 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 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 @@ -139, +139 @@ Rules like this one may cause components to cross namespace boundaries or they may not. It requires concious effort and understanding of the rule to 'prevent' boundary crossing. Quite the opposite of conciously using this 'feature' to solve some obscure domain problem. What happended to ''the simplest choice is the right choice''? - Why does removing this rule not cause the world to end? Since the convention already is that that /WEB-INF/servlet-name/ should be the location for of the application spec in the multiple-app-per-war scenario then this rule is moot even today as the previous rule (relative to the app spec location) would be hit and matched first. If the user follows the convention then not only is the rule not needed, the fact that it is there at all is just a mechanism to cause pages/components to cross namespace boundaries. Removing the rule is is like a defensive measure, applications that don't follow the convention would break in a documentable, easily explainable way. + Why does removing this rule not cause the world to end? Since the convention already is that that `/WEB-INF/servlet-name/` should be the location for of the application spec in the multiple-app-per-war scenario then this rule is moot even today as the previous rule (relative to the app spec location) would be hit and matched first. If the user follows the convention then not only is the rule not needed, the fact that it is there at all is just a mechanism to cause components to cross namespace boundaries. Removing the rule is is like a defensive measure, applications that don't follow the convention would break in a documentable, easily explainable way. {{{ As a side note I want to state again that this crossing boundaries situation is a bad thing. Tapestry already has a mechanism for sharing pages and components...libraries. Libraries are an explicit, documented, mechanism for sharing. Namespace boundary crossing is undocumented and kinda hacky don't you think? @@ -154, +154 @@ There are two impacts to this rule, both are questionable: - *If the user has one app in the war and has no .application file, then Tapestry has already installed a synthetic app spec in /WEB-INF anyways and this rule would never be encountered at runtime. If the is an application file in /WEB-INF then same applies. + *If the user has one app in the war and has no `.application` file, then Tapestry has already installed a synthetic app spec in `/WEB-INF` anyways and this rule would never be encountered at runtime. If the is an application file in `/WEB-INF` then same applies. - *In any other scenario related to the location of the .application file, whether there is one or many applications in the war, and then this rule is just a mechanism for components to cross namespace boundaries. + *In any other scenario related to the location of the `.application` file, whether there is one or many applications in the war, and then this rule is just a mechanism for components to cross namespace boundaries. Like the previous rule, removing this one is doing the Tapestry user community a service (in my opinion) by eliminating a case where boundary crossing can occur implicity. @@ -164, +164 @@ * <li><i>type</i>.jwc in the application root (within the context root) }}} - I don't really understand why this rule was added in the first place. This rule makes it possible to place a spec in a location outside of /WEB-INF which means it's possible that the xml file itself would be served to a browser, thus exposing the implementation of the application. yikes! It's an unwritten rule (or worse its a written rule and I missed it in the docs) that these files never be served. + I don't really understand why this rule was added in the first place. This rule makes it possible to place a spec in a location outside of `/WEB-INF` which means it's possible that the xml file itself would be served to a browser, thus exposing the implementation of the application. yikes! It's an unwritten rule (or worse its a written rule and I missed it in the docs) that these files never be served. Somebody help me out here. Why should this rule remain? @@ -176, +176 @@ * <li>By searching for a named class file within the org.apache.tapestry.component-class-packages }}} - The packages declared by using the meta property org.apache.tapestry.component-class-packages may overlap. They may overlap with the packages declared in the org.apache.tapestry.component-class-packages of other namespaces. But, that is an explicit choice made by the developer and not an implicit rule enfoced by Tapestry. + The packages declared by using the meta property `org.apache.tapestry.component-class-packages` may overlap. They may overlap with the packages declared in the `org.apache.tapestry.component-class-packages` of other namespaces. But, that is an explicit choice made by the developer and not an implicit rule enforced by Tapestry. + Page Lookup + + Most of the arguments made for Component lookup apply also to Page lookup. But there are some cases where boundary crossing is impossible to eliminate (and indeed may be desired by some. but not me). That case is described below and as it will definitely still exist, it should be explicity explained in the Tapestry documentation, warning of possible pitfalls. + + Here are the proposed, modified, page lookup rules. + + see PageSpecificationResolverImpl for the unmodified rules. + {{{ + <removed> + * <li><i>simple-name </i>.page in the same folder as the application specification + <removed> + <removed> + <removed> + * <li><i>simple-name </i>.html as a template in the application root, for which an implicit + * specification is generated + * <li>By searching the framework namespace + * <li>By invoking + * [EMAIL PROTECTED] org.apache.tapestry.resolver.ISpecificationResolverDelegate#findPageSpecification(IRequestCycle, INamespace, String)} + * </ul> + * <p> + * Pages in a component library are searched for in a more abbreviated fashion: + * <ul> + <removed> + * <li><i>simple-name </i>.page in the same folder as the library specification + * <li>By searching the framework namespace + * <li>By invoking + * [EMAIL PROTECTED] org.apache.tapestry.resolver.ISpecificationResolverDelegate#findPageSpecification(IRequestCycle, INamespace, String)} + }}} + + Each of the removed rules above corresponds exactly to a rule I proposed be removed from the set of rules for component lookup. Apart from the rule removed due to my suggested new tag `<page-alias name="" full-name=""/>`, each removed rule eliminated a case where boundary crossing (this time for pages) could occur implicitly. + + The remaining page rules allow boundary crossing to occur. The first is implicit and can onlu occur when there is more than one Tapestry application in a war file. + + {{{ + * <li><i>simple-name </i>.html as a template in the application root, for which an implicit + * specification is generated + }}} + + Can't remove this rule or the notion of specless page is a goner. This rule means that pretty much every template in the context is implicity a page in every application namespace in the war file. This needs to be documented. + + The last rule: + + {{{ + * <li>By invoking + * [EMAIL PROTECTED] org.apache.tapestry.resolver.ISpecificationResolverDelegate#findPageSpecification(IRequestCycle, INamespace, String)} + }}} + Is a user supplied class used to resolve pages when all else fails. Since the developer of the application supplies an implementation of `ISpecificationResolverDelegate`, no implicit boundary crossing can occur anyways. The implementation of Tapestry is free from responsibility. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
