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 ------------------------------------------------------------------------------ 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. + 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. + + Let me add that I understand the current implementation was built to make thing easier for new and veteran users of Tapestry. Those addition are one of the reasons why adoption of Tapestry has accelerated the way it has. I just think that the some of the impacts of past decisions were missed and need to be addressed. 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... {{{ @@ -141, +143 @@ ''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 + }}} + 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. + + *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. + + 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. + + {{{ + * <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. + + Somebody help me out here. Why should this rule remain? + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
