Re: Re: al-macro and expr

Not currently, and I tend to agree that it would be nice. The downside
is the templating language starts to look like a programming language,
and you loose your separation between presentation and logic, and that
way lies PHP... 8-)

I guess it depends on your view, as I see this as mucking up the logic
with display code. We really want to display errors in red, which may
only apply to the web view. If it was a pda or cell phone view, we
would need to bold it because we wouldn't be sure the users had a color
screen (or could bold for that matter, but we'll assume they can).

The macro problems we have are very similar. Since we normally have
several people working on one site the need for a clean abstraction is
high. I don't want (or let for that matter) designers touch my
modules, and they only want me in their templates to make a form work
or to handle a for loop. The less we need to be in each others area,
the less likely someone will spend time trying to figure out what to do
with a file two people changed at once. The designers like to have the
navigation reflect which section of a site they are on, and sometimes
with global templates (such as a thank you page or an error page) it's
not possible to use the file on disk or the uri to determine this info
(and that can be messy on a large site anyway). Because I don't want a
bunch of page display vars set in my page_display, or them needing to
edit my page modules, they normally do an al-exec to set a var to read
in the nav macro. I think this clutters up the templates, and also the
nav macro - it would be cleaner if the macro tags allowed this kind of
interaction directly, and possibly the features of Matt's macro patch
on the wiki.

I'm much more of the mind to build a robust toolbox and let the
carpenter decide which tools to use and how, than provide a limited set
of tools because he may cut himself with some.

Mike