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 ------------------------------------------------------------------------------ * <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 an end user would use ''as a tool with full knowledge of the possible pitfalls and possible impacts''. + 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 (in other words to cross namespace boundaries). While I'm not enmoured of this I can live with it if it's something that an end user would use ''as a tool with full knowledge of the possible pitfalls and possible impacts''. - Rules like this one may cause pages/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''? + 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. - ''On 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?'' + ''On 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?'' {{{ * <li><i>type</i>.jwc in WEB-INF @@ -151, +151 @@ *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 pages/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. @@ -163, +163 @@ Somebody help me out here. Why should this rule remain? + So, that covers all the removed rules. This does not eliminate the possibility that components will cross namespace boundaries. But it makes crossing an explicit action on the part of a Tapestry developer rather than an something that happens implictly due to the way Tapestry is implemented. + + Ok, so how is it still explicity possible a component to cross boundaries? If the above changes are accepted I think there is just one way: + + {{{ + * <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. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
