Thread: [htmltmpl] how to determine if tmpl_var exists in a loop?
Brought to you by:
samtregar
From: Kapoor, N. <nis...@xc...> - 2004-04-16 13:39:22
|
I have used=20 if ($template->query(name =3D> 'tmplVar')) {} to check if a tmpl_var exists in the template or not. How/what do I use for a tmpl_var inside a tmpl_loop? Thanks Nishi |
From: Roger B. W. <ro...@fi...> - 2004-04-16 14:01:54
|
On Fri, Apr 16, 2004 at 08:39:05AM -0500, Kapoor, Nishikant wrote: >I have used >if ($template->query(name => 'tmplVar')) {} >to check if a tmpl_var exists in the template or not. >How/what do I use for a tmpl_var inside a tmpl_loop? Recurse or append parameters. See the documentation, under: "query()" also allows you to get a list of parameters inside a loop (and inside loops inside loops). which explains it very clearly. Roger |
From: <al...@lo...> - 2004-04-17 15:40:10
|
I don't know what you are trying to do, but that doesn't seem like a good thing. It feels like you're making the code overly complex. You should think it through thoroughly to see if theres a better way. Alan. ----- Original Message -----=20 From: "Kapoor, Nishikant" <nis...@xc...> To: "H::T (E-mail)" <htm...@li...> Sent: Friday, April 16, 2004 6:39 AM Subject: [htmltmpl] how to determine if tmpl_var exists in a loop? I have used=20 if ($template->query(name =3D> 'tmplVar')) {} to check if a tmpl_var exists in the template or not. How/what do I use for a tmpl_var inside a tmpl_loop? Thanks Nishi ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users |
From: Puneet K. <pk...@ei...> - 2004-04-17 16:10:36
|
On Apr 17, 2004, at 10:39 AM, <al...@lo...> wrote: > I don't know what you are trying to do, > but that doesn't seem like a good thing. > It feels like you're making the code overly complex. > You should think it through thoroughly to see > if theres a better way. > > Alan. > > > ----- Original Message ----- > From: "Kapoor, Nishikant" <nis...@xc...> > To: "H::T (E-mail)" <htm...@li...> > Sent: Friday, April 16, 2004 6:39 AM > Subject: [htmltmpl] how to determine if tmpl_var exists in a loop? > > > I have used > > if ($template->query(name => 'tmplVar')) {} > > to check if a tmpl_var exists in the template or not. > > How/what do I use for a tmpl_var inside a tmpl_loop? > > I am curious too... I've been using H-T for about a year and a half, and I've never had to query the template. My assumption is that params in the template are assigned by me, so I would automatically know what vars exist in the template. What is/are a typical circumstance(s) where I would not already know what vars exist in a template and would want to use query to find out? Thanks. |
From: Roger B. W. <ro...@fi...> - 2004-04-17 16:18:27
|
On Sat, Apr 17, 2004 at 11:10:35AM -0500, Puneet Kishor wrote: >What is/are a typical circumstance(s) where I would not already know >what vars exist in a template and would want to use query to find out? The most obvious case is the one in which someone else is being given the HTML design part of the job. A secondary case is general debugging - if the template passes the syntax check but doesn't show the expected results, it's helpful to be able to show H::T's idea of its internal structure. Roger |
From: Karen J. C. <si...@ph...> - 2004-04-17 16:25:04
|
On Sat, 17 Apr 2004, Puneet Kishor wrote: PK>What is/are a typical circumstance(s) where I would not already know PK>what vars exist in a template and would want to use query to find out? It's the split between template and programming thing. I've considered this myself... suppose you're wanting to build a form, with a great deal of customization involved layout/graphics wise (so that none of the form-building tools are really adequate). Suppose further that the script doesn't really care (much) what's in the form, because its only job is to save the settings in a file. I can't speak to the original poster's exact situation, but I've been mulling over something along these lines. Problem *I* have is that the script really needs to know more than just the parm name... it should know whether the end-user obeyed the form length, actually picked one of the SELECT options or hand-built a bogus submission, things like that. I haven't quite figured out whether I should write something that analyzes a read-in template to produce verification code (and if so, whether it should happen on the fly or not), use a meta-template to produce both the verification code and HTML fragments, or what. -- Karen J. Cravens si...@ph... |
From: Puneet K. <pk...@ei...> - 2004-04-17 16:44:46
|
On Apr 17, 2004, at 11:25 AM, Karen J. Cravens wrote: > On Sat, 17 Apr 2004, Puneet Kishor wrote: > > PK>What is/are a typical circumstance(s) where I would not already know > PK>what vars exist in a template and would want to use query to find > out? > > It's the split between template and programming thing. I've considered On Apr 17, 2004, at 11:18 AM, Roger Burton West wrote: > On Sat, Apr 17, 2004 at 11:10:35AM -0500, Puneet Kishor wrote: > >> What is/are a typical circumstance(s) where I would not already know >> what vars exist in a template and would want to use query to find out? > > The most obvious case is the one in which someone else is being given > the HTML design part of the job. Interesting. I have approached this always with the attitude that I have to separate programming from display as much as possible. I've just finished a relatively complicated app -- a single cgi script about 2000 lines long, and about 45 different templates. My approach has been to create the templates in such a way that they could exist as a standalone website even if there was no H-T involved. In other words, if a designer-type decided to load the entire templates folder with its stylesheets and javascripts and whatnot in a designer-type program (GoLive or Dreamweaver, etc.), a complete, well-formed website would manifest, of course, with tmpl_vars intact. It may look a bit kooky since tables won't be fleshed out, and a few unavoidable tmpl_ifs won't be logic-ed out, but nonetheless -- it would be a website with all its links and scripts and behaviors and whatnot. On Apr 17, 2004, at 11:25 AM, Karen J. Cravens wrote: > > I can't speak to the original poster's exact situation, but I've been > mulling over something along these lines. Problem *I* have is that the > script really needs to know more than just the parm name... it should > know > whether the end-user obeyed the form length, actually picked one of the > SELECT options or hand-built a bogus submission, things like that. sure... the user's actions would arrive to you (the cgi) as cgi params. Most all decisions can be made based on those. In fact, even before that, quite a few illogical user acts can be trapped with judicious use of javascript. On Apr 17, 2004, at 11:18 AM, Roger Burton West wrote: > A secondary case is general debugging - if the template passes the > syntax check but doesn't show the expected results, it's helpful to be > able to show H::T's idea of its internal structure. > ok. This might make sense. I've usually just rolled my own debug breakpoints simply because I am really scared of the perl debugger. Thanks folks, for your insights. |
From: Karen J. C. <si...@ph...> - 2004-04-17 16:57:10
|
On Sat, 17 Apr 2004, Puneet Kishor wrote: PK>Interesting. I have approached this always with the attitude that I PK>have to separate programming from display as much as possible. I've Yes, but is the data part of the "programming," or part of the "display?" In the case of this project, the data definition is part of the programming for a *different* set of scripts, but this script is the UI for settings maintenance (for/by the user). Because the nontechnical-user--friendliness is the paramount issue, it's the HTML designer who gets to decide how the stuff is presented as far as layout, the order things get handled on, and so on, so the script has to follow the pattern set by the display in this case. PK>sure... the user's actions would arrive to you (the cgi) as cgi params. PK>Most all decisions can be made based on those. In fact, even before PK>that, quite a few illogical user acts can be trapped with judicious use PK>of javascript. I'm not so concerned about illogical, but rather about hostile. Because it's going to be a public Internet app, I have to assume that some users are going to look at the code and submit data that deliberately violates it. So the script has to know what list selections are permissible (presently I feed those *from* the script via TMPL_LOOP), things like that. Client-side checking absolutely can't be trusted to do that. -- Karen J. Cravens si...@ph... |
From: Clifton R. <cli...@ti...> - 2004-04-17 18:37:51
|
On Sat, Apr 17, 2004 at 11:44:45AM -0500, Puneet Kishor wrote: > On Apr 17, 2004, at 11:25 AM, Karen J. Cravens wrote: > >On Sat, 17 Apr 2004, Puneet Kishor wrote: > > > >PK>What is/are a typical circumstance(s) where I would not already know > >PK>what vars exist in a template and would want to use query to find > >out? > > > >It's the split between template and programming thing. I've considered > > On Apr 17, 2004, at 11:18 AM, Roger Burton West wrote: > > >On Sat, Apr 17, 2004 at 11:10:35AM -0500, Puneet Kishor wrote: > > > >>What is/are a typical circumstance(s) where I would not already know > >>what vars exist in a template and would want to use query to find out? > > > >The most obvious case is the one in which someone else is being given > >the HTML design part of the job. > > Interesting. I have approached this always with the attitude that I > have to separate programming from display as much as possible. I've > just finished a relatively complicated app -- a single cgi script about > 2000 lines long, and about 45 different templates. My approach has been > to create the templates in such a way that they could exist as a > standalone website even if there was no H-T involved. In other words, > if a designer-type decided to load the entire templates folder with its > stylesheets and javascripts and whatnot in a designer-type program > (GoLive or Dreamweaver, etc.), a complete, well-formed website would > manifest, of course, with tmpl_vars intact. It may look a bit kooky > since tables won't be fleshed out, and a few unavoidable tmpl_ifs won't > be logic-ed out, but nonetheless -- it would be a website with all its > links and scripts and behaviors and whatnot. That's exactly the approach I decided we should take for designing our GUI. In fact, the final form of most of the templates was created in Dreamweaver. On a similar principle, I made the various CGI scripts for displaying the templates load the template with the name exactly corresponding to the URL it's invoked under. That sounds a little confusing to say, but it just means that if you go to an URL like /admin/home/news.html, the CGI will pick up that URL and open and render a template from the path .../templates/home/news.html. This approach has worked quite well for us. -- Clifton -- Clifton Royston -- cli...@ti... Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss |
From: Puneet K. <pk...@ei...> - 2004-04-17 19:01:35
|
On Apr 17, 2004, at 1:37 PM, Clifton Royston wrote: > On Sat, Apr 17, 2004 at 11:44:45AM -0500, Puneet Kishor wrote: >> On Apr 17, 2004, at 11:25 AM, Karen J. Cravens wrote: >>> On Sat, 17 Apr 2004, Puneet Kishor wrote: >>> >>> PK>What is/are a typical circumstance(s) where I would not already >>> know >>> PK>what vars exist in a template and would want to use query to find >>> out? >>> >>> It's the split between template and programming thing. I've >>> considered >> >> On Apr 17, 2004, at 11:18 AM, Roger Burton West wrote: >> >>> On Sat, Apr 17, 2004 at 11:10:35AM -0500, Puneet Kishor wrote: >>> >>>> What is/are a typical circumstance(s) where I would not already know >>>> what vars exist in a template and would want to use query to find >>>> out? >>> >>> The most obvious case is the one in which someone else is being given >>> the HTML design part of the job. >> >> Interesting. I have approached this always with the attitude that I >> have to separate programming from display as much as possible. I've >> just finished a relatively complicated app -- a single cgi script >> about >> 2000 lines long, and about 45 different templates. My approach has >> been >> to create the templates in such a way that they could exist as a >> standalone website even if there was no H-T involved. In other words, >> if a designer-type decided to load the entire templates folder with >> its >> stylesheets and javascripts and whatnot in a designer-type program >> (GoLive or Dreamweaver, etc.), a complete, well-formed website would >> manifest, of course, with tmpl_vars intact. It may look a bit kooky >> since tables won't be fleshed out, and a few unavoidable tmpl_ifs >> won't >> be logic-ed out, but nonetheless -- it would be a website with all its >> links and scripts and behaviors and whatnot. > > That's exactly the approach I decided we should take for designing > our GUI. In fact, the final form of most of the templates was created > in Dreamweaver. > > On a similar principle, I made the various CGI scripts for displaying > the templates load the template with the name exactly corresponding to > the URL it's invoked under. That sounds a little confusing to say, but > it just means that if you go to an URL like /admin/home/news.html, the > CGI will pick up that URL and open and render a template from the path > .../templates/home/news.html. > > Clifton, That is really cool. Could you (here, or offline) share more about how you did this? In effect, the users are not going to index.cgi?do=somecrap, but they are going to /website/somecrap. So you can use path_info, but how are you getting the cgi to fire up? I know this can be accomplished somewhat with the help of mod_rewrite, but that is not always possible. I am very interested in knowing how you are accomplishing this. Thanks. |
From: <al...@lo...> - 2004-04-17 19:31:34
|
Hello Puneet. Slightly off topic but useful for making templating easy and not looking = like a cgi. Puneet said: >In effect, the users are not going to index.cgi?do=3Dsomecrap, but they = are=20 >going to /website/somecrap. So you can use path_info, but how are you=20 >getting the cgi to fire up? Its easy if you have control over your server. make a soft link to your cgi directory and call it something related to = your app /cgi-bin/information.cgi?do=3Dparameters becomes /mortgage/information/parameters This doesn't work for all servers. I have a shared one that won't let me do that, so I had to have an = extension. but you can do this differently by making up a new filename extension = and making it act like a cgi In this case, Mortgage_Rate.html is a parameter, not a file, but it = looks like a file. http://marketside.com/mortgage/mortgage.cgi/Mortgage_Rate.html On another server that I control, I can change mortgage.cgi to just = mortgage. On this one I could have made the extension .info act like a cgi and = then I could have used http://marketside.com/mortgage/mortgage.info/Mortgage_Rate.html - but by the time I realised that, it was in all the search engines. And this makes it easy to use Templates but not make it too obvious. Alan. |
From: Clifton R. <cli...@ti...> - 2004-04-18 20:33:37
|
On Sat, Apr 17, 2004 at 02:01:33PM -0500, Puneet Kishor wrote: ... > That is really cool. Could you (here, or offline) share more about how > you did this? In effect, the users are not going to > index.cgi?do=somecrap, but they are going to /website/somecrap. So you Exactly. > can use path_info, but how are you getting the cgi to fire up? > I know this can be accomplished somewhat with the help of mod_rewrite, > but that is not always possible. I am very interested in knowing how > you are accomplishing this. This is really a webserver configuration issue, but just I wanted to reaffirm that it's very possible under Apache or most other webservers. For our application I'm running mini_httpd, which is not super high performance, but seems to be the smallest and simplest webserver that will do SSL. For this webserver, the CGI mapping is simply a list of shell glob patterns that you set in the configuration file. For Apache, the configuration is done via the ScriptAlias directive. The standard convention is to map "/cgi-bin/" in the URL's path, like this: ScriptAlias /cgi-bin/ "/usr/local/apache/share/cgi-bin/" But you can just as easily map some other path, for instance: ScriptAlias /gui/ "/usr/local/mycoolguiscripts/" or (I think) ScriptAlias /gui/ "/usr/local/cgi-bin/thisdoesitall.pl" If you want to have one script for everything, you can, as you noted, take its invocation info out of PATH_INFO with something like this near the head of your script: my $name = $ENV{PATH_INFO}; $name =~ s%^.*/gui[^/]*/%%; # Add trailing index.html if filled in by web server $name =~ s%/$%/index.html%; # Remove leading slash $name =~ s%^/%%; Then access to "http://www.example.com/gui/home.html" would result in $name being set to "home.html", ready for concatenation of your template path prefix. If you have a number of different scripts for different elements of the user interface, one strategy is to hard- or soft- link those scripts into all the appropriate points in the URL hierachy where ScriptAlias points, and then you can simply use SCRIPT_NAME as the starting point instead of PATH_INFO. -- Clifton -- Clifton Royston -- cli...@ti... Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss |
From: petersm <pe...@ve...> - 2004-04-17 16:38:34
|
Puneet Kishor <pk...@ei...> > > I am curious too... I've been using H-T for about a year and a half, > and I've never had to query the template. My assumption is that params > in the template are assigned by me, so I would automatically know what > vars exist in the template. > > What is/are a typical circumstance(s) where I would not already know > what vars exist in a template and would want to use query to find out? > > Thanks. Querying the template allows you to be able to create another layer of abstraction between the code and the template. We use it to create a custom 'TemplateLoader' that will look at a given template, and by the naming convention that we use on the vars and loops it will actually create the SQL statements, query the database and load the templates. The only thing we have to remember is to use the nameing convention for the vars. This works for about 95% of the occassions that we use H::T and then the other %5 we use it more straight forward. The benefits of this are that if we want to add some more data to the template (an extra column or field or something) we just add the correct TMPL_VAR to the template and then the TemplateLoader does the rest. We don't have to change the code. If you're curiosity is piqued, then you can check out how we do this at cheesepizza.venzia.com. The module in question is named 'CheesePizza::TemplateLoader'. Michael Peters Venzia |