Thanks Carl, useful tip.  Taking your idea one step
further, I think having an option such as

show_all_params => 1 that shows all the params passed
to the template in a Dumper fashion will be quite
useful.


- boon

--- Carl Franks <[EMAIL PROTECTED]> wrote:

> 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–צ¦V­zë(r)ɚŠX§‚X¬´{f–צ¦V­zë(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
> 
=== message truncated ===



                
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs


-------------------------------------------------------
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

Reply via email to