Re: [Phplib-users] Template reverse transformation

[Tim M. <tw...@al...>]

Hello Nathan,

Thanks for your response.

I had considered just putting comments at the beginning and end of
templates as you suggested - that may still be an option.  It would seem
that is an easy thing to automate, though, and could provide a great
deal of benefit.  Having to put comments in each template is a bit of an
inconvenience and opens the door for inconsistency problems if you ever
want to rename your templates, whereas an automated solution would
require no additional effort and would always be up-to-date in the
markers that it prints.

Let me offer an analogy to demonstrate why you would want this.  Say you
have a C program that crashes when you run it.  How do you fix it?  You
recompile with "gcc -g" and re-run the program in a debugger.  What if
there was no debug mode?  Well, you could put printf statements at the
start and end of every function call so that you know where it crashes,
but that is substantially less convenient and not necessarily as
accurate.

I should also clarify that it's not essential that the whole process be
automated - the Dreamweaver scenario was more of an example than a plan
for how I will use this in practice (I still use Emacs when I edit
HTML).  While it would be nice to have a system which automatically
modifies templates based upon modifications to output from those
templates, I think it might be a sufficient first step to have a tool
which takes as input the original HTML page (which was the result of
combining templates) and the modified HTML page (edited in Dreamweaver,
Emacs, or whatever) and prints out a list of what templates you need to
modify and what the diffs are between the original output and the
modified output for each template (ala Gtkdiff).

When you say that the goal of the PHPLIB template system is to do one
thing well, is that one thing forward template transformations?  I guess
what I'm looking for would fall under the umbrella of a template
management which would cover both forward and reverse transformations
(or at least aid in reverse transformations).

Thanks,
- Tim Macinta



"nathan r. hruby" wrote:
> 
> On Tue, 6 May 2003, Tim Macinta wrote:
> 
> >
> > I consider ease of use by designers to be extremely important in a
> > templating system.  Ideally, this would mean that there is seamless
> > WYSIWYG support so that designers who use things like Dreamweaver can
> > edit a *single* HTML file with *real* data on it and have the changes
> > reflected in the templates that were used to build that page.  I know
> > there is a temptation to ask what's so hard about editing Template1,
> > Template2, etc by hand, but for designers that only know Dreamweaver and
> > don't know HTML, it's a moot point - regardless of how hard it is, it's
> > not an option in a lot of cases.
> >
> 
> Coddling lazy, stupid or incompetent designers doesn't make them better
> and only makes matters worse.  That said, I'm all for making things simple
> for everyone and not making people have to jump through hoops just to get
> their job done.  There is a fine line though, and it requires both side to
> give a little.  If your designers can't use HTML fragments at all, then
> they need to try just a little bit harder at what they do, or you need to
> try a little bit harder at teaching them what they need to know in order
> to be comfortable.  I personally think you're trying to bend over
> backwards for something that really isn't worth the time, energy or effort.
> 
> Additional personal rant:  Dreamweaver blows big fat chunks and lowers the
> IQ of it's users by 10 points every time they upgrade :-P
> 
> >
> > Below is how this could be achieved in a system that would be
> > implemented from scratch.  The basic gist is that you can put the
> > templating system in "debug" mode, which would then result in pages
> > being generated with <span> tags wrapping template fragments and
> > variables so as to identify them later.  The designer would edit the
> > single, exported page (which contains real data instead of variable
> > names) in a WYSWIG editor and then upload the modified page to the
> > template system.  The template system would then use the <span> tags to
> > figure out which templates created which pieces of the page and then
> > modify those templates accordingly.
> >
> 
> Why?  You're not talking about breaking apart a single file into discrete
> templates, you're talking about taking discreet templates, gluing them
> into a valid page, editing them, and then taking them apart again.
> Different things, which is a subtle difference.  If you have discrete
> teplates already in a phplib tempalte system, just add comment lines at
> the top and bottom of each template 'nugget' indicating what it is, then
> in post processing, jsut rip the edited page back into components with
> miltiline regexps and process those.  You can do that outside the phplib
> templating engine.
> 
> > That's the Reader's Digest summary - see below for *much* more detail.
> > My question again is whether something similar could be built into
> > PHPLIB and what this would take?  I know this would be extremely
> > difficult to make work correctly with probably the majority of PHPLIB's
> > features, but I'd still be happy even if getting a reverse
> > transformation feature necessitated that I use a certain sub-set of
> > PHPLIB features in my templates.
> >
> 
> phplib's tempalte.inc does not meet most of the needs you cite, nor do I
> think it should out of the box.  It's goal is to do one thing well and
> fast, which it does.  If you need additional features it's up to you to
> implement them for your own specific needs using tempalte.inc as a
> reference or as the core for your projects.
> 
> [snip thesis]
> 
> -n
> --
> ------
> nathan hruby
> na...@ds...
> ------
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users