Thread: [htmltmpl] wish: <tmpl_dump>
Brought to you by:
samtregar
From: Mark S. <ma...@su...> - 2005-08-06 23:09:15
|
It should be easier for a designer to get an answer to the question: "What tokens do I have available?" I think there is a fairly reasonable way to make this easier. A <tmpl_dump> tag could be added which outputs all the possible tmpl_loop tmpl_var names, along with their values, right in the template. When the designer is done with this reference, it can be removed. I think the hard part of this implementation is already done, in the form of HTML::Template::Dumper which does basically just this. It can output human-friendly YAML, which could simply be wrapped in a <pre> tag to complete the presentation. All that's left to be done is to add the glue that supports calling this from a new tag. This is another example of a nice feature that could be implemented with a plugin system. I have contacted the author of HTML::Template::Set to see if he would like to make a plugin version of that extension as well. A sample of using HTML::Template::Dumper is below. Mark # Sample HTMl::Template::Dumper script and output #!/usr/bin/perl use lib './lib'; use HTML::Template::Dumper; my $t = HTML::Template::Dumper->new( scalarref => \'<tmpl_var outer><tmpl_loop deloop><tmpl_var inner></tmpl_loop>', ); $t->set_output_format('YAML'); $t->param( outer => 'My Outer', deloop => [ { inner => 'First Inner', }, { inner => 'Second Inner'} ], ); print $t->output(); # output --- #YAML:1.0 deloop: - inner: First Inner - inner: Second Inner outer: My Outer -- http://mark.stosberg.com/ |
From: Sam T. <sa...@tr...> - 2005-08-07 17:57:10
|
On Sat, 6 Aug 2005, Mark Stosberg wrote: > It should be easier for a designer to get an answer to the question: > "What tokens do I have available?" > > I think there is a fairly reasonable way to make this easier. > > A <tmpl_dump> tag could be added which outputs all the possible > tmpl_loop tmpl_var names, along with their values, right in the > template. It sounds nice but I'd personally find it pretty useless. Most of my use of HTML::Template involves inspecting the template with query() and setting up the variables and loops that are actually requested. This is how Krang works, for example. > It can output human-friendly YAML, which could simply be wrapped > in a <pre> tag to complete the presentation. Heh. Human-friendly YAML, huh? I'd aim for something a little friendlier than that - like formatted HTML. BTW - your pluggable stuff looks great. I'm fresh out of time to look at it more closely but I think you're on the right track. I'm not completely convinced it belongs in-core yet, if only because that would put you at the mercy of my absurdly slow release schedule... -sam |
From: Philip T. <phi...@gm...> - 2005-08-07 20:19:34
|
Sometime on Aug 7, ST cobbled together some glyphs to say: > It sounds nice but I'd personally find it pretty useless. Most of my > use of HTML::Template involves inspecting the template with query() > and setting up the variables and loops that are actually requested. > This is how Krang works, for example. query() is good for programmers, not for web designers. The guys who work only the HTML need an HTML way of querying the template. -- Life is the living you do, Death is the living you don't do. -- Joseph Pintauro |
From: Mark S. <ma...@su...> - 2005-08-08 00:54:19
|
On 2005-08-07, Sam Tregar <sa...@tr...> wrote: > On Sat, 6 Aug 2005, Mark Stosberg wrote: > >> It should be easier for a designer to get an answer to the question: >> "What tokens do I have available?" >> >> I think there is a fairly reasonable way to make this easier. >> >> A <tmpl_dump> tag could be added which outputs all the possible >> tmpl_loop tmpl_var names, along with their values, right in the >> template. > > It sounds nice but I'd personally find it pretty useless. Most of my > use of HTML::Template involves inspecting the template with query() > and setting up the variables and loops that are actually requested. > This is how Krang works, for example. Interesting. I hadn't heard of that technique being used before. I do recall that this feature could be accomplished somewhat automatically if code refs were used for values-- the code refs would only be executed if they were used. I have rarely needed that myself. This seems like a reasonable default for people who aren't using die_on_bad_params (which seems to be a lot of users). >> It can output human-friendly YAML, which could simply be wrapped >> in a <pre> tag to complete the presentation. > > Heh. Human-friendly YAML, huh? Yes. It's the first bullet point on the YAML website: "YAML documents are very readable by humans." I agree, from looking at the example: http://www.yaml.org/start.html > I'd aim for something a little > friendlier than that - like formatted HTML. If the feature was implemented, I wouldn't argue over whether YAML or formatted HTML. > BTW - your pluggable stuff looks great. Thanks! > I'm fresh out of time to look at it more closely but I think you're on > the right track. I'm not completely convinced it belongs in-core yet, There would be some immediate benefits. I believe being in-core would mean my "Dot" plugin could be used with HTML::Template::Set immediately, for those who cared to use both together. In the ::Pluggable sub-class, ::Set has to be be re-written as a plugin to cooperate. > if only because that would put you at the mercy of my absurdly slow > release schedule... I'm really hoping the simple bug report for removing a hardcoded package name can be released soon, because even as a ::Pluggable sub-class, we depend on that patch. I'm also help to with release engineering. For example, I could prepare things in CVS and you could refine them for release, or basically "bless" something if you liked it. Of course, CVS is not the most flexible source control system. With a system like darcs, you could really "undo" a patch of mine you didn't like. While CVS, reversing or undoing a patch that touched multiple files would be rather painstaking. I've been doing something like this to help the CGI::Session 4.0 release get out the door using SVN. Mark -- http://mark.stosberg.com/ |
From: Mark F. <mar...@ea...> - 2005-08-08 01:17:10
|
From: "Mark Stosberg" <ma...@su...> > > It sounds nice but I'd personally find it pretty useless. Most of my > > use of HTML::Template involves inspecting the template with query() > > and setting up the variables and loops that are actually requested. > > Interesting. I hadn't heard of that technique being used before. I've done it for a *long* time. It's great. It let's the template drive common code. Mark |
From: Mark S. <ma...@su...> - 2005-08-10 03:31:51
|
On 2005-08-08, Mark Fuller <mar...@ea...> wrote: > From: "Mark Stosberg" <ma...@su...> >> > It sounds nice but I'd personally find it pretty useless. Most of my >> > use of HTML::Template involves inspecting the template with query() >> > and setting up the variables and loops that are actually requested. >> >> Interesting. I hadn't heard of that technique being used before. > > I've done it for a *long* time. It's great. It let's the template drive > common code. Is there is a generalized way to solve this, or do you have to write custom query functions every time? Mark |
From: Sam T. <sa...@tr...> - 2005-08-08 05:41:26
|
On Mon, 8 Aug 2005, Mark Stosberg wrote: > Interesting. I hadn't heard of that technique being used before. I do > recall that this feature could be accomplished somewhat automatically if > code refs were used for values-- the code refs would only be executed if > they were used. I have rarely needed that myself. For better or worse code-refs don't work for loops. I'll fix that someday! Also, setting up a code-ref takes time that query() can save you in many cases. > > Heh. Human-friendly YAML, huh? > > Yes. It's the first bullet point on the YAML website: > > "YAML documents are very readable by humans." I happen to disagree. YAML is more readable than a lot of serialization formats (probably all), but that doesn't make it fit for documentation! I'd call it "mostly readable by humans" I think. > > I'm fresh out of time to look at it more closely but I think you're on > > the right track. I'm not completely convinced it belongs in-core yet, > > There would be some immediate benefits. I believe being in-core would > mean my "Dot" plugin could be used with HTML::Template::Set immediately, > for those who cared to use both together. In the ::Pluggable sub-class, > ::Set has to be be re-written as a plugin to cooperate. I guess that's cool. It doesn't exactly compel me to action though. I tend to think of ::Set as an abomination better avoided than supported! > > if only because that would put you at the mercy of my absurdly slow > > release schedule... > > I'm really hoping the simple bug report for removing a hardcoded package > name can be released soon, because even as a ::Pluggable sub-class, we > depend on that patch. Yeah, I like that one. Since you've put it in RT I can virtually guarantee that it'll be in the next release. It's hard to forget things in RT. I'll try to grab some time to make a release soon. > I'm also help to with release engineering. For example, I could prepare > things in CVS and you could refine them for release, or basically > "bless" something if you liked it. Hmmmm. Maybe. You've been somewhat, how should I put it... hard to persuade. Here's how I'd like to proceed: you keep working on the pluggable magic in a sub-class. Keep me informed about stuff that absolutely has to be fixed in-core and I'll try to get the fixes out ASAP. Some ways down the line, possibly as part of the fabled HTML::Template 3.0 project, I'll see about merging in your sub-class. Sound workable? -sam |