Hi,
I am proposing two extensions to the current Tree/LeafInclude
functionality.
(to those unknown with the current tree/leaf functionality: it allows
you to include a file based on a given 'object path', the tags will
include the file most suited based on the objects you provide.)
1. Use of inheritance in LeafInclude
When LeafIncluding a file, if a specific file for an object cannot be
found, the LeafInclude tag falls back to the name of the builder of the
object as a path-element. For instance:
object '1' is of type 'portals'
object '2' is of type 'maps'
When leafincluding file 'bla.jsp', with objectpath '1,2', the following
files will be evaluated and the first one to be found will be included:
/1/2/bla.jsp
/1/maps/bla.jsp
/portals/maps/bla.jsp
When however we have an object '3' which is of type 'programs' which
extends of 'maps', one would like to evaluate the following paths:
/1/2/bla.jsp
/1/programs/bla.jsp
/1/maps/bla.jsp
/portals/programs/bla.jsp
/portals/maps/bla.jsp
The current tree/leaf includes do not provide this functionality. I've
written a patch for 1.6 which has been running in a production
environment for a while; I wish to port this to current CVS-HEAD to
integrate it.
2. Use of fixed path elements
Currently, it is only possible to use objectnumbers or objectaliases in
the 'objectlist' parameter of LeafInclude/TreeInclude. Often, it is
required to include files in different subdirectories than Tree/Leaf can
produce, for instance if you wish to include from a different root
(prefix the path with a static path element), or use subdirectories
(infix the path with a static path element). An example:
object '1' is of type 'portals'
object '2' is of type 'maps'
leafinclude of file 'bla.jsp' and objectlist 'first,1,second,2,third'
should evaluate:
/first/1/second/2/third/bla.jsp
/first/1/second/maps/third/bla.jsp
/first/portals/second/maps/third/bla.jsp
A dirty workaround is possible: create objects with objectaliases
'first', 'second' and 'third' and override their 'getSmartPath()' method
in the builder class. This is a however very ugly hack in my opinion, it
would be far cleaner if the Tree/Leafinclude would support fixed path
elements. For this too I already have a well tested patch for 1.6 which
I wish to port to CVS HEAD.
Any comments?
Johannes
