Andy Wardley <[EMAIL PROTECTED]> writes:
> If the template specified (e.g. foo/bar/ping) can't be found then it
> backs up the path until it can find a template (e.g. foo/bar) which
> defines the block identified by the remainder of the path (e.g. ping).
>
> This feature is disabled by default, but can be enabled by setting the
> EXPOSE_BLOCKS option to any true value.
I like ways to access objects.
Template blocks can be taken from diffrent places. Being predefined
or being a file somewhere in the paths provided.
There should be a way to easily find where a block is defined. Which
path? Which line in the file?
Maby defined by a template from a SQL DB. But provided by what part
of code?
In some cases the subpart can be reaced by obj.subobj.part.value.
Here we have somthing that should be an object hierarchy, but tries to
look like part in a directory hierarchy.
Putting methods in the path and providing access to dubtemplates
should be parts of the same thing. Make it objects.
path.foo.bar.ping
I have been torn between the beuty of not having file extensions and
marking up the types of files. I prefere to call my templates
"lib/this_type/cool_thing.tt", but I would like to refere to the
template by saying [% INCLUDE cool_thing %]. The context provides the
appropriate path "this_type".
If you decided to continue with this/kind/of/name you should provide
automatic stripping of the '.tt' extension. But i would rather have
them be proper objects. Since you already have some aliases to the
curent template and part.
Thus : just add an object interface to the file hiearchy that makes
the transition into the blocks in the file transparent. The objects
can be stored anywhere. In DB, generated by methods, or as files in
dirs.
> Unless I hear any objects, of course....
OBJECTS! Use the objects, Andy!
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
