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