My ideal system would be those the designer can see the server-side
objects and data fields in the database, and only associate them with
the template by drag-n-drop.
The designer doesn't sees any special tags, and doesn't have to conform
to those "variables" with the programmer. The associations can be done by
the programmer too, and he can also be isolated from the HTML codes.
Just like those commercial application servers available on the net, but
I think no one would choose (mod)perl as the API/platform.
If there're any comparable large scale application server based on Perl,
I would like to hear about that. Some would say Perl is not good as
Java/C/C++ in doing that, but I think we can have the core written in C/C++
and use Perl as a glue between the developer and the system.
Just my daylight dreaming....
(I hear someone is saying "bull s**t!")
Roger Espel Llima wrote:
>
> On Thu, Jul 27, 2000 at 01:28:06PM +0200, Darko Krizic wrote:
> > There is one big difference in the enhydra approach: The templates are
> > standard HTML, because the id tag is part of the HTML standard. The
> > designer can create the whole site and make a dry test, because all
> > links even work. The tags (with ids) can contain valid values.
>
> That is neat :)
>
> However, I contend that designers should be testing against a test
> server, not their local hard drives, in which case the obvious thing to
> do is put the templating engine on the test server (without the
> app-specific perl code).
>
> The advantage of this becomes obvious when you start using templating
> techniques to share html code among pages: design bits, common
> navigation for the site, for parts of the site, etc. Then the plain
> files for each of the pages can't be used statically for a "dry test"
> anymore.
