BeerBong wrote:
>
> Of course, we know this and used this feature.
>
> >
> > The you can reference $App in all scripts & includes,
> > just like
> >
> > <%= $App->print_something %>
>
> But our crew are 3 designers and 4 programmers.
> Designers know nothing about $App and other things, programmers don't know
> about CSS and other HTML stuff.
My point with mentioning the global objects was that was
the starting point for building an XMLSubs infrastructure,
because the XMLSubs themselves don't know more than the
attributes and body data they are passed otherwise.
> Huh!
> Great improvments, as I understand ASP scripts can contains XML tags only
> now.
> It is what we need, but correct me if I wrong, there are many other
> solutions, which do the same more efficient and simpler. This idealogy
> (separate code and html) is far away from original ASP idea _embed_ code
> into HTML.
I would approach your problem with an XMLSubs solution, which is
what it was designed for. I don't know if other ways are more
efficient ( benchmarks? ) or simpler. I have found the XMLSubs
solution to be very powerful way to create your own custom tags
for your design shop. If you can encapsulate all of your logic
in your custom tags, then you can free your designers from what
is going on behind the scenes, and they can get back to the
business of being creative artists!
The only way that Apache::ASP gets in the way of your needs, is
that it ALLOWS for <% %> code blocks to be embedded in your
templates. This is where its origins get in the way. The reason
this is a problem is that people will use this if they have it
to use, designers & programmers, and regardless of your coding
standards, it will happen...
What I would do to FORCE separation of logic from templates
is create a config
PerlSetVar CodeBlocks 0
which would automatically render <% %> useless. Then you could
develop your XMLSubs tag suite and the total templatting solution
for your shop. I believe also you would want to set
PerlSetVar XMLSubsStrictArgs 1
so that the attributes would not allow perl code so you could
strictly control the environment from a programming perspective.
Note that building your XMLSubs infrastructure is a significant
investment, but the productivity increases that you are looking
for can make it worthwhile.
--Josh
