Hi Steve,
>From Steve Willer:
> This looks pretty neat. I don't think I told you, but I started at a new
> job last October, and immediately spearheaded an effort to replace their
> internal template system with an Embperl-based system. Well, I won. :-)
>
:-)
> However, the template language itself wasn't enough. As you've obviously
> noticed, a system for combining multiple files to make a single web page
> is vital, to avoid duplication in the site's files. I ended up writing an
> Apache handler, just like you did, and had the handler try to find
> _template.html from the url path all the way back to document_root, just
> like you did (only with a hardcoded name).
>
> So great, only EmbperlObject doesn't do some of the things I need, so I'd
> like to make a few feature requests. Things to think about, anyway:
>
> - I find it convenient to run the objects in the same namespace as
> the template. This way, globals and stuff can be shared between
> the template and the object.
>
This works only if you call the objects only from one template, because Perl
compiles them in the namespace and if you call them later from another
page/template with another namespace objects that can't work. (EmbperlObject
can handle mulitple templates depending on different parameter, but this
isn't documented yet, because it isn't quite ready yet)
If you really like to do so, we have to compile the perl (of every object)
for every namepsace it will run into. Currently I think more of a feature
like exporting variables (like Perl modules can do), so that they are
visible in all object during the request. What do you think?
> - It would be useful to find a way to get the exact path to the
> object, from the template. I used $PartPath, myself. I also had
> another variable called $Part, which gave the base of the filename
> of the object. e.g.:
> URL is http://whatever/x/y/z.html
> Template is htdocs/x/_template.html
> $PartPath is "y/"
> $Part is "z"
Currently you can get $ENV{SCRIPT_NAME} that contains /x/y/z.html and
$ENV{PATH_TRANSLATED} will contain the filename of page your are in at the
moment. Everything else you have strip out of these two at the moment.
> This is useful in situations where I want to have nav bars that
> are page-specific, then directory-specific, then site-default.
> In this example, for the top nav, I would look for y/z_top.html,
> then y/_top.html, then _top.html.
> Anyway, that's what I do. I don't know that my solution is the
> most elegant, though.
>
If you do an Execute ("_top.html") then it will look in the same directories
for _top.html, as it looked for the _template.html. In your example this
means Embperl will automaticly look for /x/y/_top.html and /x/_top.html, but
not /_top.html. Maybe it would be usefull to search for /_top.html also, but
I am not sure how it is the best to determinate where to stop the serach for
such sub-objects. The current solution would be to have a /_template.html
which that calls a _another_template.html and _another_template.html is the
one that is overwritten (and calls _top.html). In that way EmbperlObject
will always serach "/x/y", "/x", "/".
> - Similarly, I define a variable called $Section, which contains the
> last level of the path. For example, if $PartPath eq 'x/y/z/", then
> $Section is "z".
>
But this could be easily done with a Perl regex and I don't want to setup to
much globals, because they pollute your namespace and it takes time to set
them up. Both are bad in cases you don't need them. When we have the export
feature (I decribed above, or something which serve the same purpose), you
could simple set them up at the top of your template.
> - Because templates are output in any directory hierarchy, all links
> and image tags need to be mangled (or output with an absolute path,
> which doesn't work for me for other reasons). So, in every template,
> I define $urlprefix, which has one "../" for each path level between
> the template and the object. I currently grab the number of "/" minus
> "./" in $PartPath and x that with "../".
>
This would be definitly usefull, I add it to the TODO list
> - What do you do if you find a template, but you can't find the
> object? Do you still call the template?
It returns "not found"
> The reason I ask is that we use these things called "actions",
> where the filename in the URL doesn't usually exist. The "action"
> is a library object referenced by $fdat{AID}. The library object
> is executed, and depending on error or success state, it returns
> back different names for the object that should be loaded.
> *Then* we load the object. This very useful for form handlers that
> have different states, as it avoids redirects or big [$if$]
> blocks in html files.
> Any ideas?
>
I think we can make Embperl here more smart/configurable it is able to
handle this case also in your way
> Okay, so I'm a little verbose. Now I'll report a bug I've found lately:
> Remember, I run templates and objects in the same namespace? I've found
> that variables declared in the template often are not cleaned up at the
> end of the request. The next page load goes to the same template, of
> course, and the variable is still there.
>
I guess this is because you call the object from different pages (with
different namespaces). As mentioned above Perl can only compile them for one
namespace, so the object is compiled for namespace A, but Embperl things it
has to cleanup namespace B. Could this be the reason? If not, can you send
me a small example?
Gerald
P.S. I send a copy to the modperl list, because I think your thoughts are
interesting for other people as well :-)
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
