If you make sure
die_on_bad_params => 1
is set in your HTML::Template constructor, then any variable which
isn't set in the template, or is misspelt will cause the page to die -
the designer can then tell what's wrong by simply looking at the error
message.
Carl
On 02/12/05, Boon Chew <[EMAIL PROTECTED]> wrote:
>
> Well, I guess I should have explained the need of this
> with a more solid real world use case.
> Recently I am involved in a project using Krang, a CMS
> system written in Perl that utilizes HTML::Template.
> Now here is the thing, we are fairly new to the code
> base, but in a few days of going through the code and
> poking around the code, we were able to implement
> quite a few new features for the client.
>
> But our understanding of the system is still immature
> and incomplete, and there are times the template var
> is being set somewhere in the inheritance chain, and
> we know a template can access a specific variable
> (through incomplete doc and tmpl_if test), but there
> is no way to know how to access the variable without
> going through the code tracing out where and what is
> sent to the template. And what if the documentation
> misses talking about a var that is sent to the
> template? No one you can find out unless you poke
> around the code, but the process can be time consuming
> as not all the templates are being set in one file
> (due to OO).
>
> I find it surprising that people expect problems can
> be solved with documentation, or communication with
> the frontend folks. In the real world, documentation
> is never as complete as should, I mean, it's hard
> enough to get some to comment their code! And in the
> real world, you don't always start a project with code
> that you have written as well. The need to be able to
> introspect and access what is sent to the template
> without having the perl code is a useful and
> justifiable feature of any server-side scripting
> framework.
>
>
> - boon
>
> --- "Webmaster Techcode.NET" <[EMAIL PROTECTED]>
> wrote:
>
> >
> > ----- Original Message -----
> > From: Boon Chew
> >
> > I want a way to quickly display all the info in a
> > var - a Dumper output if you will. But more than
> > that, like in some other server-side language, you
> > can query the column lists (or hash keys) and loop
> > through those and use a piece of generic code when
> > all you intend to do is to display everything in the
> > var.
> >
> > ----- Original Message -----
> >
> > I agree - something like Data::Dumper in
> > HTML::Template context would be great.
> >
> > And you can also "you can query the column lists (or
> > hash keys) and loop through those" in Perl just like
> > in any other server-side language ...
> >
> > foreach(@array){
> > print $_,"\n<br>";
> > }
> >
> >
> >
> > ----- Original Message -----
> > The tight coupling of knowledge between what's being
> > sent from the perl code and the HTML can be avoided,
> > that's the whole point of the design of the template
> > module (vs Mason where you mingle Perl code with
> > display code) right? It just seems ugly when I have
> > to tell a designer to go look at the perl file to
> > see what he is getting in the var. He should be
> > able to find that out fro m some sensible
> > constructs.
> > ----- Original Message -----
> >
> > You missed the point ...
> >
> > I mean - designer shouldn't need to take a look at
> > Perl code to figure out what you are outputing ...
> > And "some sensible constructs" are documents that
> > folow every project. Have you ever heared of terms
> > like API or Interface? You and you designer need to
> > agree on "Interface" - in your case the data he can
> > use in the template ...
> >
> > Anyway - the quick and simple solution that just
> > crossed my mind ;)
> >
> > Make something a rule - for each template - you
> > could create a special variable. Say you can name it
> > : "the_dump" or whatever.
> > And simply dump via Data::Dumper all variables that
> > you (plan) populate the template with - or send to
> > template.
> >
> > Actualy - this could be made as part of
> > HTML-Template ...
> >
> > Anyway - then your designer could just add <tmpl_var
> > name="the_dump"> at the end of the template if he is
> > not sure what data he can access.
> >
> > Of course - next thing he will complain is why in
> > the hell he can't do a preview in Dreamweaver with
> > test data already populated ...
> >
> > Cheers,
> > Alex.
> > N¬HY޵隊X¬²š'²ŠÞu¼'¦[§?‰ÜŒ¨º
> > Þ¦Øk¢è!–ˆ ŠW¬~Šé(r)†åzk¶ŠC£
> [EMAIL PROTECTED],º·âž a{›
> å?,àHòÔ4¨m¶ŸÿiÛ(±ÙÜ¢oÚv'ïûjYhr'ׯ:æŠrXœ?{f–צ¦Vzë (r)ÉšŠX§‚X¬´{f–צ¦Vzë (r)Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ–+-²Ê.ÇŸ¢¸ ?ë–+-³ùb²Ø§~?á¶imzjej×(r)±êì
>
>
>
>
> __________________________________________
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Html-template-users mailing list
> Html-template-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>
