tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-tapestry Wiki] Update of "Tapestry5LookupDebate" by GeoffLongman
Date Mon, 13 Feb 2006 02:37:40 GMT
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message