Re: [cgiapp] Variable Number of Column in a Table
On Thu, May 15, 2008 at 12:21 PM, Joshua Miller [EMAIL PROTECTED] wrote:
Yes, but it's not pretty...
And it may be pretty slow for largish result sets.
You could also consider using client-side javascript to do the table
layout and sending the data as JSON, but that obviously adds a level
of complexity.
TMPL_LOOP NAME=SQL_OUTPUT
TMPL_IF NAME=__first__
TR
TMPL_LOOP NAME=COLS
THHeaders go here/TH
/TMPL_LOOP
/TR
/TMPL_IF
TMPL_IF NAME=__odd__
TR
TMPL_LOOP NAME=COLS
TDRow of data in odd row color set/TD
/TMPL_LOOP
/TR
/TMPL_IF
TMPL_UNLESS NAME=__odd__
TR
TMPL_LOOP NAME=COLS
TDRow of data in even row color set/TD
/TMPL_LOOP
/TR
/TMPL_UNLESS
/TMPL_LOOP
$data = {
SQL_OUTPUT = [
{ COLS = [ { CELLDATA = blah },
{ CELLDATA = blah },
{ CELLDATA = blah },
] },
{ COLS = [ { CELLDATA = blah },
{ CELLDATA = blah },
{ CELLDATA = blah },
] },
],
};
--
Josh I.
On Thu, May 15, 2008 at 12:03 PM, Stephen Carville
[EMAIL PROTECTED] wrote:
Is there any way to have a template where the number of columns is
determined at run time? I know how to use TMPL_LOOP but that only
lets me vary the number of rows.
What I'm doing is creating a template for SQL reports so I want a
structure like:
TMPL_LOOP NAME=SQL_OUTPUT
TMPL_IF NAME=__first__
Headers go here
/TMPL_IF
TMPL_IF NAME=__odd__
Row of data in odd row color set
/TMPL_IF
TMPL_UNLESS NAME=__odd__
Row of data in even row color set
/TMPL_UNLESS
/TMPL_LOOP
--
Stephen Carville
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] Lazy DBI
On Thu, Feb 14, 2008 at 6:27 AM, Joshua Miller [EMAIL PROTECTED] wrote: Just my 2cents... Apache::DBI. Entirely forget about passing it around.. that's too much work. Create an ini file or something, and put your connection options in there, maybe even your own lib to connect to various db's, but call the connect from various libs whenever needed, and let Apache::DBI handle caching the connections. Apache::DBI is simply a more elegant solution... only problem is that it assumes you're running apache (not an problem for me). I was just starting an email that says the same thing. It just works, and no code changes need to be made (assuming you followed some pretty basic guidelines). Sean # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Re: [?? Probable Spam] [cgiapp] [slightly OT] modifying a main page from a popup
On Sunday 04 February 2007 15:12, Ron Savage wrote: On Sun, 04 Feb 2007 14:27:23 -0500, Sean Davis wrote: Hi Sean If the relation doesn't exist, I would like to open a popup to allow the user to create the object--no problem here. However, on submission of that object, I would like to update the original select box or option box with the new item. I could do an AJAX You could do this with JavaScript, but are you sure it's worth the effort? No, I'm not sure, but after a bit of googling, it seems pretty easy to do with javascript, in case anyone is interested. The key feature (for googling) is the opener: http://www.webdeveloper.com/forum/showthread.php?t=131327 Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] [slightly OT] modifying a main page from a popup
Hypothetically speaking (just think about how to build this), I have a complex page with a main object that (in sql terms) has a bunch of foreign-key relationships to other objects--imagine a series of select or option boxes for each of these relationships. If the relation doesn't exist, I would like to open a popup to allow the user to create the object--no problem here. However, on submission of that object, I would like to update the original select box or option box with the new item. I could do an AJAX call every time the focus changes to that select box, but is there a way to do it automatically upon submit in the other window? It seems that there is, as I have seen websites that do that. Any insight would be quite helpful. Thanks, Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] HT vs TT speed wise
On Tuesday 30 January 2007 10:04, Robert Hicks wrote: I have about a 5 page site. I have it going in TT since that is what I normally use. I got to thinking about whether HT was faster since it is just a templating system. Has anyone ever done a comparison? I haven't done a comparison, but I did run into a speed problem with generating some parts of a table using TT and looping (though the table was particularly abnormal--180 columns by several dozen rows--big loop). I ended up doing it in perl and then inserting that HTML chunk directly into the template. I expect that both template systems will have trouble with intensive looping or control structures. Caching the compiled templates may make a significant difference, but I never went that route. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] When would you not use CA
Robert Hicks wrote: I am being contracted for a small site for a friend. It is maybe 5-7 pages and probably 1 form and some AJAX sprinkled in. While I really love CA (I use it at work) I am wondering if this is too small to use Perl/CGI/CA for? Thoughts? I have watched several small projects with just a few pages quickly become programming challenges as functionality, no matter how simple, gets added. Usage examples: So, you need to keep a session between pages? How about error handling? Oh, and now someone wants a simple user login and authentication of some pages. For performance, I want to use my scripts under mod_perl (or I just think it is cool). These usage examples illustrate how a simple app can quickly become somewhat less simple. CA provides the framework upon which generalized solutions for each of these usage examples can be applied. It is definitely worthwhile climbing the CA learning curve. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Using AJAX with C::A
On Thursday 19 October 2006 11:12, RA Jones wrote: Michael Peters wrote: IMO, saying you want to learn AJAX without learning JS is like saying you want to learn web programming without learning HTML and HTTP. Sure there are probably frameworks out there that will hide those details from you, but sooner or later you're gonna have to get your hands dirty, or suffer the consequences :) Exactly what I feared, but fully appreciate the analogy. I've had a quick look at prototype.js and also jQuery and its tutorial, but it all seems very mysterious, and not at all clear how it can be integrated into a CGI::App. The prototype.js is simply included in your template, either as text or as a link. Then, you use its functions in your HTML markup (in your template). The only trick to making an AJAX call is to write a run_mode in your CGI::App that returns something that the AJAX call understands. This can be as simple as returning a snippet of HTML (but not the whole page, as your run_modes usually do) or can be JSON or XML. So, the integration is not really into the CGI::App (except for the minor modification to any run_mode that is going to return to an AJAX call) and inclusion of the prototype.js code in your HTML and finally including the code to make the actual AJAX call from your HTML page. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Ajax
On Thursday 12 October 2006 09:01, Robert Hicks wrote: I know this is sad. What is the term I should be looking for when I want to bring back only the associated records with a drop down selection? I assume you mean What AJAX command do I use?. That depends on the javascript framework you are working with. Have you settled on one yet? Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Ajax
On Thursday 12 October 2006 10:33, Michael Peters wrote: Robert Hicks wrote: It will probably be prototype since there is a CA plugin for it. Do you have a recommendation? But either way, if you're going to get into Ajax, don't be scared of Javascript. Any wrappers that exist (like HTML::Prototype) are good starting points, but if you're doing anything interesting they will quickly get in your way. I would agree here just to have an n=2. Not much to add other than to point out that these javascript libraries are simply text files at their most base level. I have found it useful to look at the code and to try to reproduce some of the simpler stuff myself, just for instructional purposes. I am NOT a javascript guru (or probably even a novice), but when I started looking at javascript it was helpful to not just use a library but to look at it for learning purposes. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] In the scope of CGI::APP?
Robert Hicks wrote: I would like to populate one combo box with data when the user chooses an option from another combo box. I am currently using CA and HT only and would like to keep it that way if possible. If that answer is Javascript that is okay...I would rather it not. ; ) Javascript is the cool way of doing it and does not necessarily require a round-trip to the server, but could (and if it were done, this is what people commonly call AJAX). The other way is to use an onChange attribute of the first combo box to submit the form back to the server. The server would make the appropriate changes and then resend the page to the browser with new values for the combo boxes. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Off-topic - graphing packages
On Friday 08 September 2006 06:36, RA Jones wrote: Sorry this is not directly relevant to C::A but may become so for me if I can find an answer - does anyone know of a Perl module/package that can plot a double-y log axis graph using dates (correctly handled) on the x-axis? DBD::Chart and GD::Graph can both do some of this but neither can do it all (as far as I can tell). Have you looked at using R (http://www.r-project.org) to do this? Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI Script to pass a file to different servers
On 7/6/06 3:00 PM, I BioKid [EMAIL PROTECTED] wrote: Dear All, We have 3 inhouse web servers and 2 remote web servers. All of this web server accept same type of files as input : say foo.txt (these file contain some data and the 5 web server will process it and gives its respective results) Now, we are planning to integrate these 5 server in to a single form (web page) (so that the users dont need to visit all the 5 web pages) But, my doubt is how I will pass this single file to different server ? Is there any technic ? Is there any particular module ? I -- I was thinking about this problem and I got one simple solution : 1. Provide a check box + file upload details on page one of new server 2. On next page there will be submit buttons for selected respective check boxes selected already 3. store the uploaded file in /tmp area 4. Onclick on submit button pass the file to respective server (but here also how to pass my file from my server to remote server ? ) Is this a feasible idea ? This doesn't sound like a very good design to me. Sounds like you are trying to use a distributed computing concept. I would make one machine the webserver to handle input/output for the user and set up a process on the webserver to distribute the files in the background to the appropriate compute machine. After processing, have each compute machine deposit the results back to the webserver. Sean P.S. It is generally not a good idea to post to several lists like you have done here. So far, this question sounds like it probably best fits on beginners-cgi. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: re-branding CGI::App
On 7/6/06 2:28 PM, Joel Gwynn [EMAIL PROTECTED] wrote: True. One should also consider google-ability. Web::Application could be as difficult to google as .NET. I further this sentiment. Sticking religiously to name is function satisfies one goal, but may fall short for others. Is there a big downside to going out on a limb with the name (perhaps within the Web:: namespace, perhaps not)? Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] OT: apache logout and a javascript question
On 5/2/06 4:39 AM, Michael Lackhoff [EMAIL PROTECTED] wrote: Hello, I followed the advice from this list and wrote mod_perl authentification- and authorization handlers to move this task from my application to apache. But now I have the problem that for this kind of authentification there is no 'logout' functionallity. How do others handle this problem? The best I could come up with was a tweak to the authentification handler that gives back an 401 error to everyone for the location /myapp/logout and then write my own error document for this location saying Logout successful or something like that. But still the user gets the pop up box from the browser to reauthentificate. Any better ideas? I typically have something like a teaser page that isn't protected that includes stuff like messages, usage stats, overview, etc. On that page, there can be a spot for the user information, if the user is logged in. If the user is not logged in, that can be replaced by a link to login (or the first real page of the app). When someone logs out, redirect back to your teaser page. Since this page is outside your app (while it could be a runmode), the user will not get any request for reauthentication. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
On 4/3/06 9:19 AM, Michael Lackhoff [EMAIL PROTECTED] wrote: On 3 Apr 2006 at 8:33, Michael Peters wrote: And if I want to give it a try, where can I read more about these Auth* handlers? This book chapter was written for apache 1.3 and mod_perl 1, so some of it might need some translation to mod_perl2 and apache2, but I hope will get the idea. http://www.modperl.com/book/chapters/ch6.html Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
On 4/3/06 8:33 AM, Michael Peters [EMAIL PROTECTED] wrote: Michael Lackhoff wrote: On 31 Mar 2006 at 12:18, Jesse Erlbaum wrote: One other note, on which I have been harping for years: If you are about to tell me that you can't have a separate instance script for each application because your login system would have to be duplicated in each application, then you're doing things wrong. Authentication and authorization belongs in Apache -- not in your CGI-App module. No, this is not the reason, why I want to split my application but still, I am not convinced that authorization belongs in Apache. Say I have an application with a company and branches. Now I want that a user is only allowed to run the runmodes with data of the brach the user belongs to. This info is within the application and Apache doesn't know anything about it -- at least if I don't want to duplicate my branch layout in a htgroups file or similar. Or if this case is still simple enough that with some tricks Apache can use the info in the database, what about special cases where a user is granted rights just for part of the info, say anything, except sallary? The 'knowledge' about the different roles of users is inherently within the application and I cannot see how Apache can do really flexible access restriction without being part of the application. Even the most complicated auth setup can be done in Apache using mod_perl Authz and Authen handlers. Even though it's running at the apache level, it's still a part of your application since it's connecting to your database and has your business logic. It's just done before your application has a chance to run. Just to add a bit here: Apache2 (and Apache1.3) includes handlers that divide the request/response cycle into phases (http://apache.perl.org/docs/2.0/user/handlers/http.html). CGI-applications live under the PerlResponseHandler. Note that there are a number of other handlers, and they are designed to be used. Under mod_perl, each of these handlers is accessible and truly can be useful, using only perl. It really isn't orthogonal to good CGI::App design to use these other phases of the request/response cycle if you are under mod_perl and have access to them. Doing so can actually lead to tighter, more reusable, more easily maintainable code, rather than less. As for business logic and fine-grained auth/authz, that can be incorporated in arbitrarily complex ways using the apache auth/authz handlers coded in perl. Imagine, for example, making a simple YAML file that includes runmodes followed by groups allowed to access them. Then, you could probably rather easily write up a perl handler that is fully general that allows you to specify a YAML file for each webapp. Changing the YAML file would offer any granularity for any website you care to create. A PerlSetVar could allow you to set the DB from which to grab information and you are up and running. When you design another webapp using CGI::App, you just write another YAML file as needed, use the same database (or a different one), etc. And, now you decide that RDMS isn't the way to go, but LDAP is, just alter your authen/authz handler slightly, and you are off-and-running. Perhaps most importantly, you can move an application over to Catalyst and the authen/authz doesn't need to change. And static content can be protected easily as well. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: cgiapp specification best practice
On 3/21/06 7:48 AM, Mark Stosberg [EMAIL PROTECTED] wrote: On 2006-03-21, Paul Johnston [EMAIL PROTECTED] wrote: Mark Stosberg wrote: We have a page on the wiki dedicated to this broad topic: http://cgiapp.erlbaum.net/cgi-bin/cgi-app/index.cgi?BestPractices If after reviewing that you are still curious, try framing a more specific question about a particular aspect you are interested in discussing the best practices for. I took a look at that, and it's got some really interesting resources on it. However - what I'm interested in is the process of building a site. An example would be: 1) Design what run-modes are required 2) Design the right number of templates 3) Design and Build external objects 4) Build plugins for cgiapp 5) Build test-suite 6) Build run-modes 7) Test 8) Plug In to templates Paul, I'm afraid the topic of building a site and your exhaustive list of what's involved is still a particularly broad topic to discuss-- enough content is involved for an all day seminar. If you would like detailed consulting on all aspects of the website construction process, I might suggest hiring a consultant for a day or two to jumpstart your engines. To be digestable in this medium of mutual volunteer support, I really think it would work best if you could pick a specific question which might be comprehensively answered in 15 minutes or less. Paul, Just to add a bit here (perhaps tangentially), I have used cgiapp to develop a set of online databases for gene expression data. The content isn't as important as the design process used. In my case, I am not a full-time programmer (in fact, I am not really a programmer by training at all), so my concept of design was to work with biologists closely over several months to come up with a set of pages that were user-friendly, fast, and powerful. CGI::Application is so flexible that adding pieces to it, removing pieces, switching templating solutions, or switching database backends on the fly is possible. So, while design is important, it can (and should) also maintain some flexibility, in my opinion--we certainly benefited from having some slow, clunky code at the beginning so that the user-experience in the end was better, but our design process won't work well in other situations. In summary, I'm not sure that a best practices (as defined in a list like that given above) is possible (or even desirable) given the innumerable types of projects to which and settings in which CGI::Application can be applied. Specific guidelines can be given (Use a template system), but beyond that, I think the larger design process should remain individualized and trying to define a best practices for that will be difficult. Just my 2 cents worth. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Design question - structure and authen/authz
Are you running your C::A site under mod_perl, or is the C::A straight perl cgi? Sean On 2/6/06 2:51 PM, Ed Pigg [EMAIL PROTECTED] wrote: Hi all, I'm reworking a C::A site to provide more flexibility and control. This site has been functioning using Apache Basic Authentication and that has served it's purpose up to now. I would like to use a sql database to store user information and retrieve access rights based upon group membership. If I use Apache built-in authorization modes, I can control location authorization in the host config. I may be missing something but I have not seen a mod_auth_mysql module for apache. I essentially would like any request to the site redirected to a login page if not logged in. This I know how to do. Would you make a static login page on index.html? or point into the application and let it handle the rest. If I want full control over served content, do I set the document root to be in my C::A base module? and redirect for static content? Must each page then be a template? or am I making this all too hard? Sorry if this is confusing, it probably shows where my thoughts are at the moment. Ed Pigg - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] The Web programming techniques best documentation question.
On 12/8/05 5:03 PM, Ron Savage [EMAIL PROTECTED] wrote: On Thu, 08 Dec 2005 22:01:58 +0300, Strong wrote: Hi Strong I want to study the techniques used in web programming those that o Class::DBI (or perhaps DBIx::Class) Doesn't get much press, but Rose::DB::Object is pretty nice and quite fast! On top of that, of course, we all have our own favourites. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] run mode switching;
On 9/19/05 1:08 AM, russell [EMAIL PROTECTED] wrote: Hello All, I am using CGI::Application with HTML::Template and have the very general question of how to control run mode switching using a templated approach? I have been hardcoding the next runmode that a submit button should invoke in the templates themselves, but this seems as though it will prohibit runmode/template reuse. How *should* this be done? The old perl idiom There are many ways to do this applies to this situation as well. However, the simplest way to do this is to make the url for form submission a template variable and fill it in from your CGI::App. Then, you can use whatever means you like to calculate the URL and place it into the form dynamically. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Best way to keep a value for entire session
On 9/14/05 11:50 PM, Ski Kacoroski [EMAIL PROTECTED] wrote:
Hi,
I am creating a password changing page and I have to use expect to
access Mac OSX open directory where the passwords reside. Is there a
nice way where I could make the connection in the cgiapp_init script and
then have it available for the entire app (kind of like the dbh plugin).
Right now I create and break the connection each time I need it in the
application.
Thanks in advance.
Could you do something like this in your app (or in your cgiapp subclass if
you want it to be reused):
sub od_connection {
my $self = shift;
#connection already exists from before
return ($self-{_od_connection}) if (exists($self-{_od_connection}));
#need to make connection, because it
#doesn't already exist
my $connection = ..
$self-{_od_connection} = $connection;
return $connection;
}
I haven't tested this and I don't know how you are making your connection to
the Open Directory server (fill in the '' above), but I hope you get the
idea. The first time this is called, either in cgiapp_init or, better, only
when needed (for some requests, you won't need the connection, so why make
it at all for those requests), the connection is made and stored. The
second and all subsequent times, you get the same connection object. Don't
forget to do error checking when making the connection.
HTH,
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Session question
On 9/14/05 3:08 PM, Ski Kacoroski [EMAIL PROTECTED] wrote:
Hi,
I am missing something and am hoping you can help. I am using example
code from CGI::Application::Plugin::Session. My code is at the end. My
problem is that I display a login form, but when the user clicks ok, the
cgiapp_prerun runs and because the login has not been processed yet,
starts up a new session so I never get to another run mode (the login
form template sets rm to student_pw). What is the trick I am missing?
I think that somewhere you have to process the input from the login form.
In other words, there has to be something (perhaps in the login run_mode)
that checks to see if a username and password were submitted from the login
form and then process these to see if the username and password are correct.
It is in this little piece of code that you have to set the logged-in
session variable.
cheers,
ski
sub cgiapp_init {
my $self = shift;
$self-session_config (
CGI_SESSION_OPTIONS = [driver:File, $self-query, {Directory =
'/tmp'}],
DEFAULT_EXPIRY = '+5m',
COOKIE_PARAMS = {-expires = '+5m', -path = '/tmp' },
SEND_COOKIE = 1
);
}
sub cgiapp_prerun {
my $self=shift;
unless ($self-session-param('logged-in') eq 'y') {
$self-prerun_mode('login');
}
}
sub setup {
my $self = shift;
$self-start_mode('login');
$self-run_modes(
'login' = 'showLoginForm',
'student_pw' = 'showStudentPWForm'
);
$self-tmpl_path(/var/www/password/templates/);
}
# Show the first form for entering the esis id, staff acct, and staff
password
# There is no session id created yet
sub showLoginForm{
my $self = shift;
my $q = $self-query;
my $template = $self-load_tmpl('staff_form.tmpl');
my $html = $template-output;
return $html;
}
sub showStudentPWForm {
}
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Help on possible CGI::Application::Plugin::HTML :Table
On 8/16/05 7:16 AM, Johan Bosman (EDS) [EMAIL PROTECTED] wrote: Thanks for the feedback. How should I use the HTML::Table module in a CGI::Application? It seems that I am doing something wrong. In the following code I call a function (_query ) from Query (run mode1) that creates the object $table1 . The problem is that this object is only visible from the _query function, and the next run mode (Table_Main) can't see it. I tried to change the scope of $table1, but it is still not working. I need to call _query from Query, other wise the progress bar doesn't work. Sorry for all the code) If I understand correctly, this isn't a problem with scope, exactly. After your first run mode is done, the script exits. It doesn't continue to run until the second run mode. Then, when it is re-run (the user goes to run_mode2), any variables, etc. from run_mode1 are gone. If you need to store information from one run_mode to the next, you will have to be use sessions, hidden fields, or cookies. Or did I misunderstand you? Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Sessions and Best Practices
On 8/15/05 9:36 AM, Will [EMAIL PROTECTED] wrote: I've been playing around with CGIA and I really like what I see. I've got some very simple apps under my belt, but now I'd like to build something more robust. I will need to authenticate users and keep track of them through my app ( and possibly other cgi-apps ). It's been quite some time since I've had to deal with sessions, and at the time I rolled my own version before I really knew what sessions were. Is there some sort of standardization, or best practices when it comes to sessions and cgi-app specifically? Have you seen: http://search.cpan.org/~ceeshek/CGI-Application-Plugin-Session-0.08/lib/CGI/ Application/Plugin/Session.pm And here: http://cgiapp.erlbaum.net/cgi-bin/cgi-app/index.cgi?LoginLogoutExampleApp Hope these help, Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Help on possible CGI::Application::Plugin::HTML:Table
On 8/15/05 11:55 AM, Johan Bosman (EDS) [EMAIL PROTECTED] wrote: I am using CGI::Application in a project that also requires HTML:Table and it looks like I would have to write a plug-in to accomplish this. I am not a regular Perl user and am not to sure what is involved in developing plug-ins for C::A. Can someone more experienced maybe point me in the right direction? You don't have to write a plugin to use it. You can simply use it as needed in your module. If you wanted to develop a plugin, it might be useful for others, but doing so certainly isn't a necessity to being able to use a module within CGI::Application. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] XML Through https
On 8/4/05 6:18 AM, Jabir Ahmed [EMAIL PROTECTED] wrote: Hello I have a url like https://secure.web.com and when i pass parameters to and send a request, it send a XML file in return. How do i capture the XML file and parse it using perl. the complete url with parameters would be like https://secure.web.com?userid=23;dt=23;age=21 Jabir, This probably isn't really the correct email list for this question, but you will probably want to look at LWP::Simple and XML::Simple. You would use LWP::Simple to get the URL and then use XML::Simple to parse the returned text. If you need more detail, try posting your question on http://www.perlmonks.org. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: [OT] CGI::Session is good, but we can do better (a new project is born?)
On Jun 17, 2005, at 12:14 AM, Mark Stosberg wrote: On 2005-06-17, David Emery [EMAIL PROTECTED] wrote: The couple of times I've tried working with Class::DBI, I found that it was quite noticably slow compared with doing the same thing via SQL + DBI. I think that could be a problem with something like sessions that tend to get run on every request. Performance is a concern I share, and I don't know how well Class::DBI will do there. However, assuming I don't expose anything that would very Class::DBI specific, the backend could be updated later, and much of the value returned. And just to add to the Class::DBI discussion a bit, there has been a fair amount of discussion on the Class::DBI email list of the behavior of Class::DBI (and more specifically Ima::DBI) under mod_perl. I haven't been following the discussion closely at all, but I would have to say it is a concern requiring some thought for those using mod_perl. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] calling run_mode if form has 2 submit buttons
On May 31, 2005, at 9:54 AM, Prakash Inuganti ((pinugant)) wrote: Hi, I am only couple of days old to using CGI::Application. If my form has 2 submit buttons and on click each should call a different run_mode, how do I handle that?. I can give one hidden field with name='rm', what do I do with the second one? Any help is appreciated. I have most of my run_modes submit back to themselves and then use logic within the run_mode to dispatch to the next run_mode which may vary depending on several the parameters on the page. I can easily validate input this way, also. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] configuration modules
Just to toss something else into the mix, I have been using XML::Simple, but don't have anything set up to do any caching, etc. It is, just as it says, quite simple to use. Sean On Mar 30, 2005, at 3:09 PM, Michael Peters wrote: Jeff MacDonald wrote: HI, Currently to load up my config's i have a hash in a .pl file that i just use Im looking at using one of the config file modules on cpan liek this one http://search.cpan.org/~wonko/CGI-Application-Plugin-Config-Simple -1.00/lib/CGI/Application/Plugin/Config/Simple.pm I'm not working in a cached environment at all right now that is, no mod_perl. Im wonderng how much extra over head would it be to load up that config file versus the method i'm using now.. There is some overhead, but the extent depends on how large the file is. If it's pretty small I would imagine the I/O of 'use'ing a file and reading the config would probably be most of the overhead and not the parsing. C::A::P::Config::Simple is just a simple wrapper around Config::Simple. If you are really concerned I would use Benchmark to create a typical file in both formats (or maybe all 4 formats since Config::Simple supports a very simple syntax, and http based syntax, and a .ini syntax) and then see how they compare. I'd guess the straight hash approach would be the fastest, but by how much, I don't have a clue. As for why i don't use mod_perl. it's a long story, and i'm working towards using it in the future. Well, keep working towards it :) -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Is this the best way to use Cache::FileCache to cache output?
Barry, I have never used it (nor do I have any details to share), but have you looked at: http://httpd.apache.org/docs-2.0/mod/mod_cache.html Sean On Mar 21, 2005, at 10:48 PM, Cees Hek wrote: On Mon, 21 Mar 2005 19:36:38 -0500, Barry Hoggard [EMAIL PROTECTED] wrote: I'm working on a site that does a lot of mysql hits, and I want to cache pages for an hour. Here is a quick summary of how I'm doing it, in a base class for all CGI::Application modules. I will add some kind of package or method regex when I get to the pages that I don't want cached. Is this the best approach, or is there a better way? This might run on a shared host as CGIs for now, so I'm concerned about performance, but I'm trying to keep things relatively simple. The code you provide looks like it should work. There are a few other options that you could research: - The Cache::Cache modules are known to be slow - might be worthwhile to checkout Cache::MMap which I understand is much faster - You could forgo the caching scheme and generate static pages every hour. This would be much more efficient (unless you have thousands of possible cached items that may not be called very often). - Ideally, you should let a reverse proxy do the caching for you by setting up Squid or Apache/mod_proxy in front of your webserver, and then set Expires headers for all your pages. This might not be possible, since you mention you are on a shared server... (you should probably set the Expires headers anyway, since it will help on page reloads). Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application
object
# so that it would be available later in the destroy sub.
#
# $self-param('_SESSION', $session-id());
#
#
If you want to store the session object, then this is probably what you
want:
$self-param('_SESSION',$session);
This stores the reference to the session object.
#
# This works, the session id appears on the template page.
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from
$self-param('_SESSION') as you have it currently coded. Instead, if
you make the change noted above, you could (to make it transparent) do:
my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());
elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
These should work with the first change noted above.
As a general comment, I would suggest using plugins whenever possible
when working with CGI::Application. These offer standard methods for
dealing with various objects commonly needed for web development
(sessions, database handles, templates, etc.). For example, it is
possible that you could create several connections to the database as
you have written here. Using the DBH plugin, your application can set
up one database handle (if needed, otherwise not) and share it
throughout. The session plugin will only create a session if a session
is needed; again, it makes the session object available throughout your
application as $self-session. I at first thought--I can this just as
well, but I learned that it was better to use these plugin modules
until I ran into a barrier that could not be overcome, then just build
on what was available. It is a great learning experience to see what
others have done, as it is (at least for me), usually amazing how small
these modules actually are, just cleverly and thoughtfully coded. And
most of the developers have given thought to running under a mod_perl
environment, where caching and singleton behaviors can be used.
Hope this helps
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 9:52 AM, Peter Fogg wrote:
On Mar 10, 2005, at 3:12 AM, Sean Davis wrote:
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the
reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I
am
sure that I have written code that does not conform to best
practices;
please feel free to comment, I need all the help I can get! BTW, I
know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application
object
# so that it would be available later in the destroy sub.
#
# $self-param('_SESSION', $session-id());
#
#
If you want to store the session object, then this is probably what
you want:
$self-param('_SESSION',$session);
This stores the reference to the session object.
#
# This works, the session id appears on the template page.
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from
$self-param('_SESSION') as you have it currently coded. Instead, if
you make the change noted above, you could (to make it transparent)
do:
my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());
elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently
commented out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
These should work with the first change noted above.
Originally, I tried $self-param('_SESSION',$session);. It didn't
work so I tried $self-param('_SESSION', $session-id());, it didn't
work either. At your suggestion, I changed back to
$self-param('_SESSION',$session); and uncommented the my $session
..., ...delete and ...flush lines of code above. I am still
getting this message: Error executing run mode '3': Can't call method
delete on an undefined value at .
Oops, my bad. Note that in order to have access to your session
object, it must be created first. It looks like in run_mode 3, a
session object hasn't been created. Remember that the run_modes do not
run in order (and, typically only 1 run_mode runs per request). In
order to set up your session for use later, set it up in setup and
store the session object at that point. Then you can call
$self-param('_SESSION') in any of your run_modes.
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote: On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Yep. Just be clear that YOU have to set assure that the session id is available at the next invocation of your script, either by way of a cookie value, a hidden field paramater, or a parameter in the URL. The browser does not handle this on its own (unlike for basic authentication, for example, but that is another issue). Really, try using cgi::app::plugin::session. Then, look at the code to see how it works. Like a good little module, it is VERY well documented (within the code itself), so you can literally read it for understanding Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Class::DBI please help with error
On Mar 10, 2005, at 5:17 PM, [EMAIL PROTECTED] wrote: Hi, I am using Class::DBI in my CGI::Application apps now with no problem when I use on my web host's server. I installed all needed modules locally in my account there and I have had no problems. The problem is using it in any way whatsoever on my home pc. I am now using Red Hat Linux running inside vmware (great recommendation by the way - thanks!) and I have everything running fine. I can even run simple apps that query a MySQL database using DBI. I upgraded Perl from 5.8.0 to 5.8.6 because the install for HTML::Template requested it (utf-8 issue I think). I installed Class::DBI with no problem, all tests ran fine. Everytime I try to run any code that tries to access a column, I get an error like this: [Thu Mar 10 14:26:52 2005] [error] [client 127.0.0.1] Can't use string (DBIx::ContextualFetch::ISA) as an ARRAY ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/DBI.pm line 531. The funny thing is that I am not using 5.8.0 anymore, even though the libraries are still there. Class::DBI and all of the new modules I installed are in /usr/local/lib/perl5/site_perl/5.8.6 if I do this from the command line: perl -e 'print $_\n for @INC' The 5.8.0 directories do not show up. If I do the equivalent listing of @INC from a cgi script, they do show up. You are running under mod_perl? If so, was it built against 5.8.0 or 5.8.6? If not, what does the #! line point to (which executable--is it the correct version of perl)? Also, did you install DBI under 5.8.6? But I am certainly NOT an expert I am at a loss for what to do at this point. Someone on irc mentioned upgrading mod_perl. I don't know if I have that on this system, but I am starting my scripts with #!/usr/bin/perl and my httpd.conf file is not set up for mod_perl. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 5:54 PM, Peter Fogg wrote: On Mar 10, 2005, at 11:13 AM, Sean Davis wrote: On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote: On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Yep. Just be clear that YOU have to set assure that the session id is available at the next invocation of your script, either by way of a cookie value, a hidden field paramater, or a parameter in the URL. The browser does not handle this on its own (unlike for basic authentication, for example, but that is another issue). Really, try using cgi::app::plugin::session. Then, look at the code to see how it works. Like a good little module, it is VERY well documented (within the code itself), so you can literally read it for understanding Sean Two questions and a comment and I'll be out of your hair! So I get the session id sent by the browser and do a $session = CGI::session-new( ... with the retrieved session id as the second parameter. The method will retrieve the session variables stored in the storage medium. Do I have that right? Yep. What is the feeling about the merits of the driver being File or DB_File or MySQL? I like relational databases, but that is just me. There are bound to be strong feelings one way or the other, particularly in terms of performance, so I would say until you have a problem, just pick one for experimentation purposes. The only reason that I didn't use CGI::Application::Plugin::Session in the first place is the fact that it is an alpha version as opposed to a 3+ version for CGI::Session. However, on your recommendation I will take a very close look at the plugin version to solve my problem. One of the (many) reasons that I like CGI::Application and its plugins is that all of the authors are on this list constantly, answering questions, responding (in a meaningful way) to bug reports or concerns, giving tips and tricks about how to best use the software. Therefore, I think that although CGI::App::plugin:: is likely to not be as battle-tested as something like CGI::Session or CGI itself, that doesn't mean it is full of bugs. And, even if it is, the author is likely to be on this list and can answer questions within minutes of your asking. Not many CPAN modules have this level of fast and personal support, I think. So, I would just use them all, but certainly if you have questions about one of the plugins, ask here--it is a very personable forum. In fact, I can remember a question coming up on the list (I think it was about sharing database handles throughout the application), and within less than 24 hours, someone had made a plugin to do just that. That is user support! Many thanks for the help that I received from you and Michael Peters. Regards, Peter - Let us know how it goes. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e
[cgiapp] Directory structure for website
This is a bit off-topic I have a cgi::app running as a mod_perl handler. I handle authen/authz via the handler, also, and log username with each request. This all works as expected. However, I also serve static HTML, CSS, and images as part of the site, some of which are shared between other cgi::apps. I would like to move away from keeping all this extraneous material in htdocs toward having project-specific directories to improve my own sanity, not to mention things like logging and access control. Any suggestions on how to do this in a mod_perl framework (or best-practices, in general)? Below is what I have in my httpd.conf file right now. Do I need to move authen/authz out of my cgi::app to accomplish the task--I think I probably do. The above is a bit convoluted. The main question is, what is the directory structure and authen/authz that folks find most useful under mod_perl? Thanks, Sean PerlModule C3 Location /sarcomadb SetHandler perl-script PerlHandler C3 /Location - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Directory structure for website
Pardon my supreme ignorance ;), but can someone explain what authz/authen is? Sorry for being opaque, Scott. And thanks, Michael for the detailed answer. Just to elaborate on authz/authen: Authz is short for authorization and authen is short for Authentication. These are formally separate phases of security. Michael adds Access, correctly, to that list. In a web setting, access control is used to limit access to a location or site based on non-personal information like domain from which the request is coming, time of day, day of week, hit limits, etc. Authentication is what most people think of when security is involved--it is the process of determining who the user is and guaranteeing that identity; it often involves user/password combinations, but can be more or less complicated. Authentication comes after authentication and is the process of determining that the user from the authen step is allowed (or not) to access a specific resource (page). There is a logical order-Access-Authentication-Authorization. See the apache website for a (mudh) more detailed discussion. Hope this helps. Sean Sean Davis wrote: This is a bit off-topic I have a cgi::app running as a mod_perl handler. I handle authen/authz via the handler, also, and log username with each request. This all works as expected. However, I also serve static HTML, CSS, and images as part of the site, some of which are shared between other cgi::apps. I would like to move away from keeping all this extraneous material in htdocs toward having project-specific directories to improve my own sanity, not to mention things like logging and access control. Any suggestions on how to do this in a mod_perl framework (or best-practices, in general)? Below is what I have in my httpd.conf file right now. Right now, I think one of the best examples of best practices when using C::A in a large project that runs under mod_perl is krang (http://krang.sourceforge.net). I am also planning on releasing (sometime in the next few months) the source for an application that I've been doing on the side. Krang uses H::T, CGI and Class::MethodMaker, where as my app uses TT, Apache::Request and Class::DBI. Two sides of the same C::A coin. I think the general directory layout (relative to the project root) is something like... /lib = perl modules /conf = configuration files /templates = template files /logs = application logs /bin= any scripts for starting/stoping/testing/etc /htdocs = images, css, javascript, etc I use CGI::Application::Dispatch to make urls easier, get rid or instance scripts (or make my httpd.conf file cleaner) and have my authz/authen be based on the path. Assuming my project is in '/sites/myapp' my httpd.conf (or at least my application specific portion in a vhost) file might look something like this: DocumentRoot/sites/myapp/htdocs Directory /sites/myapp/htdocs Options Indexes AllowOverride None Order allow,deny Allow from all /Directory ErrorLog/sites/myapp/logs/error_log PerlRequire /sites/myapp/conf/startup.pl PerlTaintCheck On PerlModule MyApp::Handler Location /app SetHandler perl-script PerlHandler CGI::Application::Dispatch PerlSetVar CGIAPP_DISPATCH_PREFIX MyApp PerlSetVar CGIAPP_DISPATCH_RM On PerlSetVar CGIAPP_DISPATCH_DEFAULT public AuthTypeMyApp::Handler AuthNamemyapp PerlAccessHandler MyApp::Handler-access PerlAuthenHandler MyApp::Handler-authen PerlAuthzHandlerMyApp::Handler-authz /Location LocationMatch /app/admin_.* Require group admin /LocationMatch LocationMatch /app/member_.* Require group member /LocationMatch Then I just define what a group of 'member' and 'admin' mean in MyApp::Handler. Do I need to move authen/authz out of my cgi::app to accomplish the task--I think I probably do. Not necessarily, but I think it'd be a good idea to keep them separate. But that's more for organization than for any limitation of mod_perl/C::A. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] [ANNOUNCE] CGI::Application::Plugin::LogDispatch - 0.03
Cees, Very nice, at least at the level of the description. Creating a singleton object is quite a nice touch. Seems like some selected other plugins could use the same idea? Sean On Jan 20, 2005, at 11:36 AM, Cees Hek wrote: A new version of CGI::Application::Plugin::LogDispatch has been uploaded to CPAN. It should hit the mirrors later today. For those that are impatient, you can download it or browse the distribution from the links listed below. This version adds support for storing the Log::Dispatch object as a singleton. This means that the Log::Dispatch object is only created once per process, which can be a performance boost in persistent environments like mod_perl and PersitentPerl. Each Log::Dispatch object is stored in the namespace of the module that 'use'ed the plugin. So it is not a true singleton, since you can still have multiple Log::Dispatch objects in memory, but there will ever only be one per module that uses the plugin. This was done so that you can have multiple CGI::App applications running that have different configurations for doing logging. The singleton object will automatically be inherited by subclasses. So if you want all your CGI::App applications to use the same Log::Dispatch instance, then create a serverwide Base class that loads the plugin and have all your applications inherit from this class. The plugin is fully backwards compatible, so you can continue to use it as is, and your Log::Dispatch objects will only last the duration of the request. I probably need to do a bit more work on the docs to make things a little bit clearer. Any help with that would be appreciated. Comments and feedback welcome... Links: http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin- LogDispatch-0.03.tar.gz http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin- LogDispatch-0.03/ Cheers, -- Cees Hek - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Session management with cgi-app.
Franki,
Are you using the plugin? If not, that might be a place to start, as
it does the session allocation/cookie reading in the right order
without requiring any work on your part.
Below is what I do (not using the plugin, but). It is NOT textbook
or even documented code, but it will hopefully give you an idea. Note
that I am using Apache::Session which uses a tied hash rather than
CGI::Session's nicer param facilities. However, the structure works
for both. What isn't here is that the session method sets a cookie if
one isn't present and always reads that cookie if it is present (which
is the default behavior for CGI::App::Plugin::Session when using
cookies?). The validation of the cookie happens afterward by looking
up the _logged_in parameter in the session. If it is present, we have
accomplished authentication and, if not, we need to go to login.
Hope this helps a bit and doesn't confuse matters further.
Sean
In my CGI::App subclass:
###
sub cgiapp_prerun {
###
my $self = shift;
my $session = $self-session;
if ($session-{'_logged_in'} eq 'in') {
return 1;
} else {
$self-prerun_mode('login');
}
return 1;
}
###
sub login {
###
my $self = shift;
my $errs = shift;
my $tt = $self-param('tt');
my $q= $self-query;
if ($q-param('login_submitted') !$errs) {
return $self-process_login;
}
$q-param('rm' = 'login');
$q-param('frm' = 'login');
my $vars={err = $errs};
return $self-output('login_a.html',$vars);
}
###
sub process_login {
###
my $self = shift;
my $q= $self-query;
my $dbh = $self-dbh;
my $session = $self-session;
my $user = $q-param('user');
my $password = $q-param('password');
my $check= $dbh-check_login($user,$password,$q-get_remote_host);
my ($results,$err_page) = $self-check_rm('login','_login_profile');
return $err_page if $err_page;
if ($check =~ /^[0-9]/) {
$session-{'_user_id'}=$check;
$session-{'_logged_in'}='in';
return $self-front_page;
} else {
my $err = {some_errors = 1};
$err-{message} = $check;
return $self-login($err);
}
}
On Jan 18, 2005, at 12:39 PM, Franki wrote:
Hi guys,
I have written my session code with CGI::SESS and it works fairly
well, only it seems to create more then one session file for each
visitor.. one for when they first go to the app, and then it swaps to
another when they are logged in.
The result is that I have a session directory with huge numbers of
files in it, and had to create a crontab to delete old ones.
Does anyone have any good clean example code of CGI:APP integrating
with CGI::Session for a password protected app?
I have a suspecision that I seriously overcomplicated what is really a
fairly simple task, but seeing someone elses work might help me to see
the error of my ways.
rgds
Franki
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] More dynamic run_mode change questions
For those of you using path_info parsing to get at run_modes, how do YOU deal with the dynamic run_mode changes? It is easy enough to return $self-other_run_mode, but in the setting of using path_info, that seems contradictory and may even defeat the apache-based authorization concept (if done carelessly). I'm just curious as to what, in practice, people are doing. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Redirect question
On Jan 7, 2005, at 12:59 PM, Michael Graham wrote:
I am using CGI::App in a mod_perl environment. I typically have
run_modes submit back to themselves for validation, etc. If the form
information passes, I return $self-next_run_mode (just an example).
I have made a couple of changes to my previous coding style. First, I
am using path_info to get the runmode (makes linking and handler
dispatching much simpler). Second, because of the first, I want to
use
redirects to move from one run_mode to the next; that is, a form
submits back to itself and is validated, I do a
$self-redirect('next_run_mode'). It seems that redirects do not
conserve the POST information. Is this true? If so, does this sound
familiar to others? What other coding idioms do people use besides
submit-to-self?
I think the submit-to-self, then redirect method is the cleanest.
Not
always the best performing (because you have two HTTP requests after a
successful submit), but this method creates the fewest problems for
browsers and for your application.
I do like the submit to self because all my code for validation, state
changes, etc., is then relatively self-contained. At this point,
almost all my databases are read-only (with the exception of
user-management), so I'm not too worried about the double submit issue
for that type of data (which I can catch with a simple uniqueness
check).
So because of this, I'm trying to follow this rule of thumb: use POST
for submitting data that changes the state of the application and GET
for requesting pages without changing the app's state. That's more or
less what the HTTP spec tells you to do anyway, AFAIR.
As I understand it, your main problem with this approach is that
redirects do not conserve the POST information. Which POST
information are you trying to conserve?
You can add query params to the redirect URL, so you can pass a small
amount of state information that way.
Adding the information as a GET is something that I could certainly do.
As an example, I have a form that allows users to do a query (give the
parameter for a SQL statement). The display on the next page can be
configured via multiple parameters (about 8, a couple that allow
multiple values). It is this information that I would like to hang
onto. One possibility is to store these parameters in a session, but
if the user does a back a few times and resubmits a page that has
session information from a later page, the results might be unexpected.
I could stuff all of this into a GET (I'm fairly sure the resulting
string wouldn't be too long?), and perhaps that is what I should do for
the redirect.
For an example, I wrote a quick database for gene expression profiles.
We have a quirky access for it (you apply to via email submission
rather than automatic), but it is available. As you can see from the
URL, it is not mod_perl based and has somewhat limited functionality
compared to what I am currently trying to develop.
http://ntddb.abcc.ncifrcf.gov/cgi-bin/nltissue.pl
Thanks for all the insight from the group
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Redirect question
For an example, I wrote a quick database for gene expression profiles. We have a quirky access for it (you apply to via email submission rather than automatic), but it is available. As you can see from the URL, it is not mod_perl based and has somewhat limited functionality compared to what I am currently trying to develop. http://ntddb.abcc.ncifrcf.gov/cgi-bin/nltissue.pl Should be http://ntddb.abcc.ncifcrf.gov/cgi-bin/nltissue.pl Sorry! Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] problem with PATH_INFO not being recognized
Punkish,
Sorry about that. Version issue. The anonymous array I missed, also.
Again, sorry. Thanks for the pointers.
Sean
On Dec 9, 2004, at 11:10 AM, punkish wrote:
On Thu, 9 Dec 2004 06:33:12 -0500, Sean Davis [EMAIL PROTECTED]
wrote:
Punkish,
path_info is going to be interpreted as a cgi parameter, so if you
want
to feed the path_info parameter to your script, you need to do it as a
parameter. In practice, that means:
http:://localhost/~user/myapp/index.cgi?path_info=welcome
no Sean. You are likely confusing QUERY_STRING with PATH_INFO (these
are the cgi environment variables that populate the ENV hash).
PATH_INFO refers to the portion _after_ the immutable part of the URI.
so, the non-changing part of my URI is ../index.cgi and everything
after that becomes PATH_INFO.
For directing traffic (moving from one page to the next), you will
have
to provide path_info parameter in some manner.
Also, I think mode_param takes a single string like:
$self-mode_param('path_info');
C-A 3.31 provides a shortcut to grab PATH_INFO by setting
mode_param(path_info = 1)
And run_modes takes a hash of mode names and associated subroutines to
call like:
$self-run_modes(
'welcome' = 'welcome',
'login' = 'login',
)
yes, but you can also provide runmodes as an anon array as long as the
runmodes themselves are named exactly as the calls they are gonna
make.
so the above can be shortened to run_modes([qw/welcome login/])
Thanks anyway.
I the stuff above is correct, but someone can correct me if I'm wrong
on this. If you really need to dispatch from the path info like you
show below, you could look as CGI::Application::dispatch.
Sean
On Dec 9, 2004, at 1:40 AM, punkish wrote:
caution: extreme CGI-App n00b here.
My url is thus
http://localhost/~user/myapp/index.cgi
my extremely simple script is
sub setup {
my $self = shift;
$self-start_mode('welcome');
$self-mode_param(path_info = 1);
$self-run_modes([qw(welcome login verify about)]);
$self-tmpl_path('templates/');
}
sub welcome { blah }
sub login { blah }
..
the PATH_INFO is not being handled correctly as the run_mode keeps on
defaulting to 'welcome' no matter what path_info I provide after
index.cgi. Even if it is ..index.cgi/login or ..index.cgi/about, I
see
only 'welcome' almost as if no path_info was provided.
Please tell me what obviously stupid thing I am doing wrong so I may
not tear out my remaining hair.
Many thanks in advance for your patience and kindness.
--
punkish
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
punkish
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: CAP::Stream
On Dec 2, 2004, at 10:31 PM, Jason Purdy wrote: I updated the documentation from Mark's feedback: http://www.purdy.info/useperl/Stream.html I also took a first crack at the code for the Plugin - it wasn't actually that bad: http://www.purdy.info/useperl/Stream.pm.html So now I just need to test it out! This (ABOVE) is why I will stick with CGI::App! Question on streaming files yesterday === new plugin developed for today! WOW!!! Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Hidden variable or Query String or Form for run mode access?
On Nov 29, 2004, at 11:05 PM, Kasturirangan Rangaswamy wrote: Hi, I am sequentially accessing 4 run modes. At each run mode, I give the user a screen, perform some validations and move on to the next mode(screen). The screens are displayed using HTML::Template I am declaring a hidden HTML variable in each screen as follows INPUT TYPE=HIDDEN NAME='rm' VALUE='TMPL_VAR NAME='run_mode_value'' and am setting it's value in my Perl subroutine. Now, I actually constructed a 'Continue' link on each screen to move to the next one like so: a href=Continue/a and find that this overrides the mode-setting thats happening in my Perl program. So inspite of my specifying a mode in my sub, on clicking Continue, I am still taken to whatever place the href= takes me to. a. Now, I know I could call my instance script and pass it the mode-param variable along with an appropriate value but I dont like the idea of a query string on my browser address line. b. Also, I have not been using forms and dont want to if I can get away with that!. So 'POST' is not an option either. The whole point of using CGI (OK, not the whole point, but...) is to use forms to gather information from the user. Without forms, you can gather no information from the user; in addition, you cannot gather information from any hidden fields or anything else on the page. That said, if you want to pass any information from one invocation of your script to the next, you can use GET, POST, save the information on the server side or on the client side in a cookie. I would vote for doing what you are doing already, but you WILL need a form on your page if you want your script to be able to access the value. In other words, your script will ever see the INPUT tag above without it being within a form block. Try putting it in a form block to see if that does the trick. Also, your continue button then can be a simple submit button on the same form. Question is, if (a) and (b) are excluded, is any other way possible for me to use 'Continue' (as a link) and a hidden variable to move to the next mode. Is there something in that HREF link I may be missing? Any help is appreciated. Thanks, Sharad __ Do you Yahoo!? All your favorites on one personal page - Try My Yahoo! http://my.yahoo.com - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] OT: Apache2
Off-topic, but I am about to install an apache webserver on one of our machines as a development machine. To a person who does not do web development on a regular basis, but only on an as-needed basis, is there a reason to move to apache2? I know from recent discussions that CAP::apache::stuff is tough enough moving to apache 1.x, so presumably apache2 support is further off? Thanks for any insight. Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] OT: Apache2
On Nov 18, 2004, at 12:00 PM, Michael Peters wrote: Sean Davis wrote: Off-topic, but I am about to install an apache webserver on one of our machines as a development machine. To a person who does not do web development on a regular basis, but only on an as-needed basis, is there a reason to move to apache2? I know from recent discussions that CAP::apache::stuff is tough enough moving to apache 1.x, so presumably apache2 support is further off? Are you planning on doing development under mod_perl or vanilla cgi? As far as I know, vanilla cgi should work just fine under apache2. I haven't verified that CAP::Apache works under mod_perl2 (apahce2) but I don't imagine it would be that difficult to make sure it does. Support could be added quickly especially if there is interest :) Partially at your direction, I would like to move over to developing under mod_perl. It would be nice to have persistent connections (particularly to some analysis packages that have HUGE startup times) and speed. Within the CGI::App framework, HTML generation is pretty simple using graphical tools with fine-level changes made using template tools and HTML::Fillinform. In short, I see less and less need for CGI for much of what I am doing. I can't say I will divorce myself from it (who in his/her right mind would say such a thing!) entirely, but Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Moving on to mod_perl
I have an application that I think would be well-served by moving over to a mod_perl environment and would like to proceed in that direction. I was hoping someone might be willing to share a few step-by-steps or a couple of good links as to how to go about that. I have an Apache server with mod_perl running. I use a couple of DBI connections, CGI::Session (the plugin), and TT as the template engine. As far as I know, I have no global variables defined. Thanks, Sean - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] getting data into a param
On Oct 21, 2004, at 11:41 AM, Robert wrote: Do I need to stuff the results of that while loop into a return statement or can I just call the following in my application script: my $page_content = WebDB::attu_all(); Nope. This definitely won't work. You will probably need to read a bit about using subroutines, as CGI::App is built on passing values around between subroutines. $template-param( CONTENT = $page_content, ); This won't either. I'm not sure at what point you are in developing your cgiApp application--not very far? If you are using your print statements to generate HTML, then you just need to put all of that into one large string and return that from your run_mode. CGI::App will just plop it on the page. Using HTML::Template is different in that you generate values that are then plugged into the template. You probably need to look at HTML::Template documentation a bit more. Sean - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] RFC - C::A::Plugin::Apache
This is my own naivete--what other plugins are affected by such a move? CGI::Session--I think it just needs a param method form the query object? DBH will work just fine, I assume? Others? Sean - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Hybrid static/dynamic site
Joel, You might also look at using Template Toolkit (see site http://template-toolkit.org). It has scripts to allow whole websites to be built with the invocation of a single script. You could also build your templates for the dynamic content at the same time, just leaving the dynamic content for fill-in later. You could then have a run-mode that serves each static page based on some cgi parameter(s). Sean On Oct 6, 2004, at 10:09 PM, Joel Gwynn wrote: I'm working on a web site that will be a combination of static pages and application pages, and I'd like to use cgiapp to build the static pages. I've been browsing the archives, and can't find any real answers. Should I be considering a separate utility or CMS based on HTML::Template? - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Form validation
3. Has anyone developed a generic class based on Class::DBI that supports codes tables. Up until adopting DBI.pm, I always rely on a generic codes table to store fairly static application decodes that really don't need their own table. Some of the codes are keyed on language (error message decode) and also have an effective date (e.g. new menu option). Primary key is type/code/lang/effective date. Here are a few rows from one which is probably a better illustration. +--+--+--+++ | type | code | language | edate | decode | +--+--+--+++ | sex | M| EN | 2001-09-01 | Male | | sex | F| EN | 2001-09-01 | Female | | entity | M| EN | 2001-09-01 | Member | | entity | O| EN | 2001-09-01 | Opposition | | entity | V| EN | 2001-09-01 | Venue | | contact | th | EN | 2001-09-01 | Home | | contact | tw | EN | 2001-09-01 | Work | | contact | tm | EN | 2001-09-01 | Mobile | | contact | fh | EN | 2001-09-01 | Home Fax | | contact | fw | EN | 2001-09-01 | Work Fax | | contact | em | EN | 2001-09-01 | Email | | contact | ct | EN | 2001-09-01 | Club Tel | | contact | cf | EN | 2001-09-01 | Club Fax | | language | en | EN | 2001-09-01 | English| | language | nl | EN | 2003-09-01 | Dutch | +--+--+--+++ My aim would be to be able to access the decode directly from the HTML::Template by declaring a relationship solely in the Class::DBI. E.g. error decode message in from ValidateRM and labels for fields in the original forms themselves. For point 3 and direct access from the template, have you looked at Template Toolkit? I find it richer and more intuitive than HTML::Template, but I imagine the same can be done using HTML::Template. However, with TT, you could develop a simple function to do the mapping how you see fit and pass it as a coderef to Template Toolkit. In fact, if you encode your decode table (sorry about all the codes) as a module, you can access the methods directly from your template. See here for examples and, in particular, use of a coderef: http://www.template-toolkit.org/docs/blue/Tutorial/ Web.html#DYNAMIC_CONTENT_GENERATION_VIA_CGI_SCRIPT I'm not sure if this directly addresses your question, but hope it helps, anyway. Sean - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Building Complex Applications with C::A and helper modules
I have looked into CDBI a bit more (it was I that started all of this several days ago). I am still concerned about handling joins. I agree that it (CDBI) looks fantastic for getting information from a single table at a time, but I often need to pull data from different columns in several tables at a time or perform a join (or multiple) to get the information that I want. In my particular case, I have some 50 tables, many with only 2-3 columns because of the relationality of the data, so performing multiple selects to drill down to data from a fourth or fifth join using the CDBI framework seems quite tedious and successfully defeats the power of modern SQL engines for performing these joins in a very systematic fashion, using more than just a primary key if possible. I recognize that CDBI still allows the flexibility of straight-up SQL, which is why I may ultimately use it, but I am curious if there is more coming along in joins than has been discussed. This is certainly getting outside the realm of CGI::App list, but I have had so many recommendations from users here that I thought I might benefit from a tad bit more insight. Sean - Original Message - From: William McKee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 04, 2004 9:53 AM Subject: Re: [cgiapp] Building Complex Applications with C::A and helper modules On Sat, Oct 02, 2004 at 01:11:54AM -0400, Caleb Rutan wrote: That is somewhere in the neighborhood of pre-alpha. The caching stuff is not there, and the DB abstraction is not clean at all. It doesn't handle multi-column keys for tables well, nor does it do joins very smoothly. Those issues are almost done. Hi Caleb, Thanks for sharing your framework design. I'm curious why you don't use Class::DBI. Is there some limitation in its design? I find that it works just as well for external scripts accessing the database as for my CGI::App applications. I had started down the road of building a custom database interface module and am very glad to have found a community who has already made much further progress than I had. CDBI can handle multi-column primary keys and has some alpha support for joins. William -- Knowmad Services Inc. http://www.knowmad.com - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Separate database module?
Jaclyn,
Again, thanks for the help. I am working on producing something like
what you propose. I have a database module that works with a simple
perl script, but when I add it into my CGI::App with an accessor
subroutine, I always get:
Can't locate object method selectrow_array via package ntDBH at
/Library/Perl/5.8.1/CGI/Session/MySQL.pm
which is now understandable as I'm using CGI::Session with mysql
storage, so I need to have straight DBI methods available to
CGI::Session. I'm thinking that I have two options:
1) open a second database handle directly to DBI (not ideal)
2) inherit DBI methods in my ntDBH package
I'm looking at how to do 2. Any hints? I know this is more a perl
question than CGI::App, but I thought folks (like me) might benefit
from seeing the answer. I don't want to abuse the list, though, so
direct me elsewhere or ignore
Thanks,
Sean
On Sep 30, 2004, at 4:10 PM, Jaclyn Whitehorn wrote:
On Sep 30, 2004, at 2:52 PM, Sean Davis wrote:
I am building a cgi::application that queries pretty extensively (at
least for me) from a MySQL database. I am having trouble with
maintainability, as the SQL code is mixed into the perl code and,
unfortunately, we are changing the database schema fairly often right
now. I was wondering what hints folks have about managing the SQL
parts away from the logic of the code. For my limited programming
skills, writing subroutines within my CGI::App is easiest but
probably not the most flexible.
In my last project, I was running into the same type of problem. I
ended up backing up from the code and looking at the process, then
splitting into multiple modules. This particular project ended up
with:
(1) A CGI::Application module (well, actually based on my SuperApp
subclass of CGI::Application)
(2) A module to handle database stuff
(3) A module to handle .procmailrc stuff (which if I could avoid
forever, I'd be happy)
(4) A module to handle some generic formatting tasks (taking stuff
from db and formatting for web and vice-versa)
After the split, the main CGI::Application-based module ONLY handled
taking info from user, simple logic, and putting stuff back. Since my
session management and some display tasks are done in my SuperApp,
this module is 275 lines total. Much nicer IMHO.
So, how to handle the DB? I added an accessor function to my CGI::App
module, based on some code Cees Hek (I think??) posted a while back:
sub dbh {
my $self = shift;
if (!$self-{_dbh}) {
# create DB object
$self-{_dbh} = MyDB-new();
}
return $self-{_dbh};
}
where MyDB is my database module, which is of course used at the
beginning.
In MyDB.pm, new() handles the connection, and DESTROY handles the
disconnect. Then I coded all the queries and updates I would do to
this particular project, some in a generic sense and others not. So
in my CGI::App module I end up with calls like:
$self-dbh-get_list('prefs',$userid);
YMMV...
Jaclyn
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Separate database module?
I am building a cgi::application that queries pretty extensively (at least for me) from a MySQL database. I am having trouble with maintainability, as the SQL code is mixed into the perl code and, unfortunately, we are changing the database schema fairly often right now. I was wondering what hints folks have about managing the SQL parts away from the logic of the code. For my limited programming skills, writing subroutines within my CGI::App is easiest but probably not the most flexible. Thanks, Sean - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Separate database module?
Thanks all for the input--I can't believe how much and how useful it was. I have started making a separate module with simple methods for performing queries that I will use often. I have a couple of larger objects stored in normalized tables, so I will probably try these as objects with methods to access the various pieces. I had thought about Class::DBI, but the overhead bothers me a bit as does the need to describe the table structure (which I am trying to get away from a bit, as it seems to be changing often). Sean - Original Message - From: William McKee [EMAIL PROTECTED] To: Sean Davis [EMAIL PROTECTED] Cc: cgiapp [EMAIL PROTECTED] Sent: Thursday, September 30, 2004 4:00 PM Subject: Re: [cgiapp] Separate database module? On Thu, Sep 30, 2004 at 03:52:45PM -0400, Sean Davis wrote: I am building a cgi::application that queries pretty extensively (at least for me) from a MySQL database. I am having trouble with maintainability, as the SQL code is mixed into the perl code and, unfortunately, we are changing the database schema fairly often right now. I was wondering what hints folks have about managing the SQL parts away from the logic of the code. For my limited programming skills, writing subroutines within my CGI::App is easiest but probably not the most flexible. Class::DBI has been a lifeline for me in this kind of situation. All of my SQL is kept in a single file (or can be broken up into a set of modules if you prefer). Although it makes it unnecessary to write SQL for many common procedures, it can easily handle custom SQL when you have joins or want to do some performance tweaking. I know some other folks here are using it and could offer some other views. There is a wiki[1] with a tutorial and some useful recipes for getting started. Good luck, William [1] http://www.class-dbi.com/cgi-bin/wiki/index.cgi -- Knowmad Services Inc. http://www.knowmad.com - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] cgi::application::plugin::session question
This is a VERY basic question regarding sessions with CGI. I have some
code below that I would expect to look for a cgi::cookie with a session
ID from a previous visit. If the cookie exists, use the session ID
from the cookie, otherwise the session ID is undefined and C::A::P::S
makes a new session. However, it seems that I get a new session with
each visit to the page (my first runmode does contain a call to
$self-session, which I understand will generate the cookie). I am
missing some important concept here, but just can't figure out what.
Can someone enlighten me a bit?
sub setup {
my $self=shift;
$self-start_mode('query_text');
$self-mode_param('rm');
$self-run_modes(
'query_text' = 'text_query',
#'query_location' = 'text_query',
#'query_GO' = 'text_query',
#'query_exprs'= 'text_query',
'return_results' = 'return_results',
'do_heatmap' = 'do_heatmap',
'mode4' = 'return_graphical_results',
);
$self-param('dbh' = DBI-connect($dsnnlt,
$nltuser,
$nltpass
))
or croak Database connection not made: $DBI::errstr;
my $sid = $self-query-cookie(CGISESSID) || undef;
$self-session_config(
CGI_SESSION_OPTIONS = ['driver:MySQL',$sid,
{Handle=$self-param('dbh')}],
COOKIE_PARAMS = {
-domain = 'nih.gov',
-expires = '+12h',
-path= '/',
},
SEND_COOKIE = 1,
);
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: cgi::application::plugin::session question
On Sep 29, 2004, at 8:34 AM, Mark Stosberg wrote:
On 2004-09-29, Sean Davis [EMAIL PROTECTED] wrote:
$self-param('dbh' = DBI-connect($dsnnlt,
$nltuser,
$nltpass
))
or croak Database connection not made: $DBI::errstr;
Hmm... looks like a good use for ::Plugin::DBH :)
my $sid = $self-query-cookie(CGISESSID) || undef;
$self-session_config(
CGI_SESSION_OPTIONS = ['driver:MySQL',$sid,
{Handle=$self-param('dbh')}],
I think this is what is happening: You are trying to initialize
the session with a value from a cookie which doesn't exist, so it's
creating a new session instead. The standard idiom is to initialize
from the CGI object. This will check both the cookie and the CGI params
for a value, and then create a new session if niether is found. So:
s/$sid,/$self-query,/
Mark,
Thanks for pointing out ::Plugin::DBH. I plan on using it, also, but
the project started prior to the release and I just haven't changed
over yet.
I used the idiom you suggest (both originally, and again, just to be
sure). It seems like the cookie is never being created? I am using
Template Toolkit for my templating and include a header in the
template. Is this an issue?
Sean
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] cant read cookie values from popup window.......
The correct list is:
[EMAIL PROTECTED]
Hope that helps.
On Sep 21, 2004, at 5:48 AM, manoj tr wrote:
hai,
At first i am very sorry to write again to this list. may i please
know the mailing list that i put this question?.
Secondly i use the strict paragma and and declared variable as
correctly. After compilation there is no error and this time also i
cant read the cookie from the second window. I request you to please
point out the error if any one faced this problem.
i send thecode that i corrected as follows.
***
***
#!/usr/bin/perl
use strict;
use CGI;
our $output = new CGI();
our $input = new CGI;
our $cookie;
print Content-type: text/html\r\n\r\n;
if ($input-param('cmd') eq 'test2') {test2;}
else { test; }
sub test {
$cookie = $output-cookie(-name = 'uid', -value = '100', -expires
= '+1d');
$output-header(-expires = '-1d',-cookie = $cookie);
print html\n;
print head\n;
print $cookie. ssf \n;
print script language=\Javascript\\n;
print function spawn(page) {;
print
window.open(page,\\,\left=5,top=5,height=480,width=600,status=yes,t
oolbar=no,menubar=no,scrollbars=yes\);} /script\n;
print /head\n;
print body lang=en-US style=\background-color: rgb(153,
204, 255);\\n;
printh3MENU/h3\n;
print pa href=\#\
Onclick='spawn(\/testcookie.pl?cmd=test2\)\'Online Test /a/p;
print /body/html\n;
}
sub test2 {
print html\n;
print head\n;
print /head\n;
print body lang=en-US style=\background-color: rgb(153,
204, 255);\\n;
print $cookie. dff \n;
printh3MENU/h3\n;
print pa href=\#\ Online Test /a/p;
print /body/html\n;
}
***
***
Regards
Manoj
--
__
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Basic parameter passing question
I am using HTML::Template and need to pass cgi parameters between run
modes. Do I have to always use a hidden field, or is it adequate to
set the parameter via $query-param('name','value')? In my current
app, I seem to have to use a hidden field and I have seen others
choosing to do both, also. Can someone clarify for me?
Thanks.
Sean
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: plugins
Cees, Just wondering: is the template toolkit plugin forthcoming on cpan? Thanks, Sean - Original Message - From: Mark Stosberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 9:33 PM Subject: [cgiapp] Re: plugins On 2004-05-29, Cees Hek [EMAIL PROTECTED] wrote: The great thing about CGI::Application is that it gives you the freedom to use whatever modules you want and buildup your own toolbox of code. But that is also a drawback to new users, since there is quite a bit of work that needs to be done if you want session support, authentication, logging, database access, etc... By building a bunch of simple add on modules like the Session module I wrote, we can simplify life for newcomers, without restricting the power and flexibility that CGI::Application currently enjoys. And perhaps show long time users of CGI::Application other ways of handling these common (and sometimes mundane) tasks. We are now close to this vision with the plugins now available. There's cfg() dbh() validate_rm() session() I currently have a Template Toolkit plugin that I have used in a couple of projects already, and also, an authentication plugin. However, for my authentication stuff to work, I need to be able to execute a bit of code at the cgiapp_prerun stage, which drove me to write this patch. Cees, would you be willing to share your authentication plugin? Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Unexpected CGI and HTML
I am new to the CGI and CGI-App world and, of course, have some code that is
confusing me. Here is the code for OligoMap.pm (below). If I use runmode
mode3, I go to return_probe_details. If I use runmode=mode1, I go to
subroutine query_probe which uses CGI.pm to generate HTML to insert into an
HTML Template (excerpt below). If I go to return_probe_details, which does
not use HTML::Template, the HTML is generated without issue. If, on the
other hand, I use the HTML::Template in query_probe, I get the following
error message (server log). Can anyone help me out with what I am missing?
Thanks,
Sean
HTML::Template : Attempt to set nonexistent parameter 'input
type=checkbox name=
fetchwhat value=blat hits /blat hits' - this parameter name doesn't
match any de
clarations in the template file : (die_on_bad_params = 1) at
/Library/WebServer/CGI
-Executables/OligoMap.pm line 81
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect()
.
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect()
.
[Thu Jun 24 16:25:35 2004] [error] [client 127.0.0.1] Premature end of
script header
s: /Library/WebServer/CGI-Executables/oligo.pl
package OligoMap;
use strict;
use base 'CGI::Application';
use DBI;
use HTML::Template;
# database setup
# hardcoded access stuff
REMOVED for security reasons
sub setup {
my $self=shift;
$self-start_mode('mode1');
$self-mode_param('rm');
$self-run_modes(
'mode1' = 'query_probe',
'mode3' = 'return_probe_details',
);
$self-param('probedbh' = DBI-connect($dsnprobe,
$probeuser,
$probepass,
{
RaiseError = 1,
PrintError = 0,
AutoCommit = 0
}
)) ||
die Database connection not made: $DBI::errstr;
$self-param('ensdbh' = DBI-connect($dsnens,
$ensuser,
'',
{
RaiseError = 1,
PrintError = 0,
AutoCommit = 0
}
)) ||
die Database connection not made: $DBI::errstr;
}
sub teardown {
my $self = shift;
#Disconnect databases;
$self-param('ensdbh')-disconnect();
$self-param('probedbh')-disconnect();
}
sub query_probe {
my $self = shift;
# Get CGI query object;
my $q= $self-query();
my $template = $self-load_tmpl('test.html');
$template-param('HELLO' = 'hello');
$template-param('STARTFORM' = $q-start_form());
$template-param('tbname' = $q-textfield(-name = 'name'));
$template-param('fetchwhat' = $q-checkbox_group(
-name='fetchwhat',
-values=['Database Cross-references',
'Blat Hits',
'Ensembl Mapping Information',],
-defaults=['Database Cross-references'],
-linebreak=0));
$template-param('b_submit' = $q-submit());
$template-param('ENDFORM' = $q-end_form);
$template-param('HIDDEN' = $q-hidden(-name = 'rm', -value =
'mode3'));
return $template-output;
}
sub return_probe_details {
my $self = shift;
# Get Query Object
my $q = $self-query();
my $output = '';
$output .= $q-start_html(-title = 'Query Human Oligo Probe',
-BGCOLOR = 'aquamarine');
$output .= $q-startform();
$output .= 'hello';
$output .= 'p';
$output .= $q-checkbox_group(
-name='fetchwhat',
-values=['Database Cross-references',
'Blat Hits',
'Ensembl Mapping Information',],
-defaults=['Database Cross-references'],
-linebreak=0);
$output .= $q-end_form;
$output .= $q-end_html();
return $output;
}
1;
HTML TEMPLATE:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
titleQuery Qiagen Oligo Probes/title
/head
body bgcolor=aquamarine
h1Query Qiagen Oligo Probes/h1
!-- TMPL_VAR NAME=HELLO --
!-- TMPL_VAR NAME=STARTFORM --
!-- TMPL_VAR NAME=HIDDEN --
!-- TMPL_VAR NAME=tbname --
!-- TMPL_VAR NAME=fetchwhat --
!-- TMPL_VAR NAME=b_submit --
!-- TMPL_VAR NAME=ENDFORM --
hr
/body
/html
On 6/24/04 3:18 PM, William McKee [EMAIL PROTECTED] wrote:
On Thu, Jun 24, 2004 at 01:42:35PM -0400, Sean Davis wrote:
From where is the tagset div/div coming? It isn't a problem here, of
course, but if I try to use this with HTML::template, it is causing
problems. Any ideas?
Hi Sean,
That's a good question. I don't understand what problems you forsee with
HTML::Template since you are generating all of your html output rather
than using H::T to parse a template file. Perhaps if you could show the
complete example, we could be a further assistance.
Also, you might want to try asking it on the CGI-Application mailing
list as lots of folks
