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 03:31:44 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

------------------------------------------------------------------------------
  
  }}}
  
- 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
+  * {@link 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
+  * {@link 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
+  * {@link 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message