On Mon, 14 Feb 2000, Gerald Richter wrote:
> 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?
Yes, that makes sense. Perhaps an optional argument for Execute that lists
the variables to export? Actually, there has to be a way to get variables
in both directions. Perhaps an export list and an import list in the
params to Execute? Or maybe if you just make sure we can export hashes
like %fdat, %cdat and %errors, then that would take care of the
bidirectional need.
> 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.
Yep. I'm kinda thinking of making templates easy to use for newbie
engineers. Although specialized variables tend to duplicate things that
are in other variables, they are useful for making things easier to use. I
don't know if there's an elegant way to do it, though -- after all my
meetings, I don't have a lot of brainpower left right now for design.
> > 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", "/".
I realized this, and I definitely like the way you did it. The only thing
it doesn't give me is _per page_ "_top.html" files. If you see my example
at the top, you see it looks for y/z_top.html first. This functionality
isn't supported in the path right now. Just a thought: What if the path
somehow supported a prefix on filenames? Like if it was "y/z:y/:./", then
you tack on the filename after each element in the path. The only problem
is that this would require a trailing "/" on true directory names, but if
you changed EmbperlObject to generate conforming paths it wouldn't be so
much of a problem (I think).
> 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.
Yes. I may do this, since there's typically only one template per website.
Or perhaps in a single function each template calls (which is what I'm
currently doing).
> > 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
I really liked this "action" idea when I found out about it, as it solves
multi-state responses to forms (error state, success state, etc.) very
elegantly. Out of curiosity, what do you typically do for forms? An
example might be a registration form where there are required fields. How
does your page flow work?
> > 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
