file upload object - getting form field name
I need to get the form field name from a form upload.
I've been using the upload object and looping through
my uploads:
foreach my $upload ($r-upload) {
# do stuff
}
The first form has 10 fields (labeled
upload1-upload10). For a quick hack I simply used a
counter and all was good:
my $upload_id = 0;
foreach my $upload ($r-upload) {
$upload_id++;
# do stuff
}
However, the next page will display the results of the
upload...all the good images uploaded, and a bad image
icon for the ones that didn't meet the upload criteria
(size, type, etc). The images maintain their original
order.
At this point the user is allowed to reupload new
images to replace the bad images (the is an upload
button on for each bad image, not for good images).
Now my counter fails, as if the user tries to replace
upload3 (and that's the only one that is bad), my
counter thinks it's upload1 and replaces the wrong
image.
Is there a way to get the field name...I didn't see
this in the cookbook or the archives...
Thanks.
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins [EMAIL PROTECTED] wrote: If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- md [EMAIL PROTECTED] wrote: Is it possible to have row-level locking (as opposed to table-level or null locker) with MySQL 4.x and Apache::Session? Looks like I get that with InnoDB automatically... __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
We're using Apache::Session::MySQL (Apache::Session 1.54) and occassionaly see long lock times. Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL. I'm looking at Apache::Session::Flex and setting Lock='Null'...however, I get the impression from an old email (see below) that Flex is for debugging only. First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL? Is moving to Apache::Session::Flex a good choice (and then we could also change the session table to INNODB), or should I create my own Apache::Session::MySQL-type module by changing Lock = 'Null'? I didn't see much discussion on this in the archives, so if it is there, please point me to the thread... Thanks... -- On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: Regarding Flex, nobody uses it. It is for debugging. If you have a particular variant of Flex that you use all the time (very likely), you can code up a 6-line module to make a real implementation like all the other session modules. Flex is for debugging, period. __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Table/row locking with Apache::Session::Mysql /Apache::Session::Flex
--- Perrin Harkins [EMAIL PROTECTED] wrote: It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem. We talked about this, but in our case, I don't believe this will be an issue. Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet. We put almost nothing in the session other than the user id. There are three apps sharing the same session table, and I believe one app may put two or three other things other than the user id (like current page id and affiliate id...both which I should be able to remove someday:)...but never-the-less, very little data in the session. I've gotten most of my sessioning information from this list (and you), so I believe we are session correctly :) If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module. That's what I figured and that's what I'm going to do. Thanks again, -- md __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: Apache::Session and user sessions
--- Perrin Harkins [EMAIL PROTECTED] wrote: Todd W wrote: I have a table with some basic user information (first name, last name, address, phone number, etc...). That's permanent data, not session data. Session data is transient. I was reading through the archives and came across this. Everyone was so helpful the last time I had a Apache::Session question (thread what goes in a session?) so I'm back with another question. The last project I worked on really had no transient data, so the only thing I put in the session was the user id (well, there was one transisent item...current page, so that got put in the session as well). The project I'm currently working on (mod_perl, TT, Apache::Session) is a registration system. Since this is closer to a shopping cart, I would consider the data transisent. My question is with regards to whether I need or should put the submitted data into the session as the user navigates the forms (to create an account). The user will be taken through three forms to create an account. So for instance, form one will ask the user to create a username, password, and provide an email address. Before moving on to form two (billing info), should I put this data in the session, or just go ahead and dump it in the database (after making any nec. checks), since I won't need the info until they actually login? Or should I collect all the info from all three screens by putting it in the session as the user traverses the forms and then put it all in the database at once? I'm currently using the first option. BTW, it is possible for a user to create a free account by hitting form one only, so no harm would come if something happened after form one. Another question, while not mod_perl related (sorry:), is how to taint check input data like usernames, address fields and email addresses. All info is just put in the database, no unsafe system calls are run. I'm curious as to what characters to limit for usernames in particular. Thanks... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). I haven't looked at the cache modules docs yet...would it be possible to build cache on the separate load-balanced machines as we go along...as we do with template caching? By that I mean if an item has cached on machine one then further requests on machine one will come from cache where if on machine two the same item hasn't cached, it will be pulled from the db the first time and then cached? If this isn't possible, I'm not sure if I'll be able to implement any caching or not (some of the site configuration is out of my hands) and everything seems so user specific...I'll definitely reread your posts and go through my app for things that should be cached. I would be curious though that if my choice is simply that the data is stored in the session or comes from the database with each request, would it still be best to essentially only store the session id in the session and pull everything else from the db? It still seems that something trivial like a greeting name (a preference) could go in the session. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. The only thing I can think of right now is a calendar...that should probably be cached. The only gotcha would be that the calendar would need to update every day, at least on the current month's pages. But this is only on a feature page, not a users created page (that is a user can click a link on their daily page that takes them to a feature page where they can go through archives). You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. Even though there are some preset pages, the user can change the names and the user can also create a cutom page with its own name. So there could be thousands of unique page names, many (most) specific to unique users (like Jim's Sports Page, etc.). Not to mention that between the fact that the users' daily pages can have any number of user selected features per page and features themselves can have archive depths of anywhere from 3 to 20 years, there's a lot of info. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). Very good advice. I've found that occasionally something happens to my session where the sesssion id is ok but some of the other data disapears (like current page id) which really screws things up until you log out and log back in again. This leads me to suspect that I've answered my own question from above. It's just whether I can cache or not. Thanks for all your time and help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
Thanks...you've given me plenty to work with. Great explination. This is good pragmatic stuff to know! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Apache::Session - What goes in session?
I'm using mod_perl and Apache::Session on an app that is similar to MyYahoo. I found a few bits of info from a previous thread, but I'm curious as to what type of information should go in the session and what should come from the database. Currently I'm putting very little in the session, but what I am putting in the session is more global in nature...greeting, current page number, current page name...data that doesn't change very often. I'm pulling a lot of info from the database and I wonder if my design is sound. Most of the info being pulled from the database is features for the page. Now I need to add global modules to the page which will show user info like which pages they have created and which features are being emailed to the user. These modules will display on every page unless the user turns them off. It seems that since this info wouldn't change very often that I should put the data in the session... Anyone have any general tips on session design? Thanks. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: md wrote: That doesn't sound very global to me. What happens when users open multiple browser windows on your site? Doesn't it screw up the current page data? I don't think global was the term I should have used. What I mean is data that will be seen on all or most pages by the same user...like Hello Jim, where Jim is pulled from the database when the session is created and passed around in the session after that (and updated in the db and session if user changes their greeting name). Current page name and id are never stored in db, so different browser windows can be on different pages...I'm not sure if that's good or bad. However, changes to the user name will be seen in both browser windows since that's updated both in the session and db. Optimizing database fetches or caching data is independent of the session issue. Nothing that is relevant to more than one user should ever go in the session. Correct. That little info I am putting in the session corresponds directly to a single user. That sounds like a user or subscriptions object to me, not session data. Once again, I shouldn't have used the term global. This is the subscriptions info for a single user...that's why I had thought to put this in the session instead of pulling from the db each page call since the data will rarely change. This info will be displayed on every page the user visits (unless they turn off this module). No, that's caching. Don't use the session for caching, use a cache for it. They're not the same. A session is often stored in a database so that it can be reliable. A cache is usually stored on the file system so it can be fast. The session is stored in a database (Apache::Session::MySQL), and I am using TT caching for the templates, but I'm not sure how to cache the non-session data. I've seen this discussed but I definitely need more info on this. As it stands I see two options: get data from the session or get it from the db...how do I bring caching into play? Things like the login status of this session, and the user ID that is associated with it go in the session. Status of a particular page has to be passed in query args or hidden fields, to avoid problems with multiple browser windows. Data that applies to multiple users or lasts more than the current browsing session never goes in the session. What about something like default page id, which is the page that is considered your home page? This id is stored permanently in the db (lasts more than the current current browsing session) but I keep it in the session since this also rarely changes so I don't want to keep hitting the db to get it. Thanks again... __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: Current page name and id are never stored in db, so different browser windows can be on different pages... I thought your session was all stored in MySQL. Why are you putting these in the session exactly? If these things are not relevant to more than one request (page), they don't belong in the session. They should just be in ordinary variables. You are correct, these items are in the session in the db. I meant that they weren't kept in long term storage in the db after the session ended like the default page id and user name are. The current page id/name is only relevent for an active session. Once a session is started current page is set to whatever the default page id is and will change as the user changes pages. The only reason I did this (as I recall) is that way I can get the page name once. You should use a cache for that, rather than the session. This is long-term data that you just want quicker access to. Yes, that's exactly what I want to do. My main concern is long-term data that I want quicker access to. I can definitely get it all from the db, but that doesn't seem very efficient. Template Toolkit caches the compiled template code, but it doesn't cache your data or the output of the templates. What you should do is grab a module like Cache::Cache or Cache::Mmap and take a look at the examples there. You use it in a way that's very similar to what you're doing with Apache::Session for the things you referred to as global. There are also good examples in the documentation for the Memoize module. Great...exactly the kind of info I was looking for. I'll look at those. We are using a load-balanced system; I shoudl have mentioned that earlier. Won't that be an issue with caching to disk? Is it possible to cache to the db? There are various reasons to use a cache rather than treating the session like a cache. If you put a lot of data in the session, it will slow down every hit loading and saving that data. In a cache, you can just keep multiple cached items separately and only grab them if you need them for this page. With a cache you can store things that come from the database but are not user-specific, like today's weather. Thank you for all the excellent advice and explination(in this and other posts). Most of the info I'll be pulling is *very* user-specific...user name, which features to display on which page, what features the user gets by email, etc. What happens is the user logs in and then the username (greeting), the default page id (the user can create many pages with different features per page) and what features go on the default page are pulled from the database and the default page is displayed, as well as any module info. The modules will consist of a pages module with the names of all the pages the user has created (with links) and a emails module which will display all the features that the user is getting via email. These modules will be displayed on every page. You can see that almost everything is user-specific. Right now I'm storing the page names/ids in a hash ref in the session (the emails module isn't live yet), but I thought that I would change that and only store the module id and pull the names from the db (if the user hasn't turned off the module) with each page call. Thanks again for all the info! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: when to mod_perl?
--- Cees Hek [EMAIL PROTECTED] wrote: I would build your application using plain old CGI, following the guidlines that mod_perl provides for running CGI applications under the Apache::Registry module. If you properly analyse your application, and build small tight CGI scripts, then when the load goes up, you can pick and choose the heaviest hit scripts and run them under Apache::Registry for the performance boost. Thanks...that sounds reasonable. I doubt that all the dynamic pieces of this site would really require mod_perl. To answer another's reply, this will run on either Linux or BSD. Also, if the load goes really high, you can ask for more hardware, and run the entire site under Apache::Registry without any code changes. Upgrading hardware once the load gets high was discussed...This would make the migration easier, as I have told the client that we may start with CGI then move to mod_perl later. I've never used Apache::Registry before, but this sounds like a good solution. I would recommend taking a look at CGI::Application. It provides a very clean framework for building CGI programs, and by using it, you will avoid most if not all of the pitfalls that most CGI programs have that require them to be recoded, or cleaned up for use with Apache::Registry. I normally use CGI::Application, but in this case I'll also need something like CGI::Session as well, not to mention either Template-Toolkit or HTML::Template. Are there any gotchas with CGI::Session and Apache::Registry? And yes, I'll read The Guide :) Good luck... Thanks for the help! __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: when to mod_perl?
--- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Per Einar Ellefsen [EMAIL PROTECTED] wrote: At 23:06 12.06.2002, md wrote: I'm not quite sure about this, been wondering about it, but in theory you should be able to use DirectoryIndex index.phtml and like that you won't have to worry about / etc anymore. Try it out.. And so I did...it won't work since mod_dir (as far as I can tell) looks for a physical file, and my index.phtml is virtual. What I'm really trying to do is more like the PHP I'm replacing. I should be able to go to: www.someserver.com/index.phtml for a dynamic page and www.someserver.com/index.html for a static page. I'm guessing that my best solution would be to use HTML::Mason or Apache::ASP instead of Template-Toolkit. However, I can' really do that...it took me a while to get the designers to use TT, and I doubt I can get them to change again. I may try using the PerlTransHandler to change the uri to a location...say with www.someserver.com/index.phtml the uri gets changed to /modperl (or www.someserver.com/somedir/index.phtml the uri becomes /modperl/somedir) which is used in a Location /modperl directive. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Per Einar Ellefsen [EMAIL PROTECTED] wrote: At 16:04 13.06.2002, md wrote: What I'm really trying to do is more like the PHP I'm replacing. I should be able to go to: www.someserver.com/index.phtml for a dynamic page and www.someserver.com/index.html for a static page. Does PHP do that? Yes...since both index.html and index.php are physical files. Using HTML::Mason or Apache::ASP won't solve anything special. It's still the same basic thing. Except that there will by a physical file with embedded code like PHP, so I think Mason and Apache::ASP would be closer to what I want. However, I don't have that option. I'd really like to use a Location, but the request is to keep existing directory structures (over 200 top-level directories) and the main index page needs to be dynamic as well. Let's assess your situation a litte: why can't you just put your TT templates into your document root, and do like with your PHP pages? That would solve the current problem you seem to be facing. Because the templates need to be processed by a mod_perl script and I need to map that somehow. Furthermore, have you looked into the Apache::Template module? I think it's pretty close to what you want. I haven't looked at it, but I believe it's just a wrapper to Template-Toolkit. Thanks for the suggestions :) __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Perrin Harkins [EMAIL PROTECTED] wrote: I don't really see the problem. You can map all the URLs that end with a certain extension to one module that does some work and then calls a template. OK...the little light bulb has just come on... I didn't realize that I could put my templates directly in htdocs. Now I can create a template and call it index.phtml and set DirectoryIndex to include index.phtml and all works like I want. Thanks! __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Mapping to location /
I'm replacing an exisiting PHP site with mod_perl and
Template-Toolkit.
I normally set up mod_perl to use a location like
this:
Location /something
and set the handler to my mod_perl module.
However, I need to map to / since I'm replacing a
system where there are existing PHP files like
www.someserver.com/index.php or
www.someserver.com/about.php.
I decided to do use
Location /
to map to my main mod_perl script.
The first thing it does is to check if the uri ends
with a .phtml extension (or www.someserver.com or
www.someserver.com/...same with subdirectories). If
there is, I continue processing, otherwise I decline
it and let Apache handle it.
If I have a .phtml (or a directory index) I check if I
have a template. If I have a template TT takes over,
if not I return DECLINED and let Apache take over.
http.conf
-
Location /
PerlSetVar websrc_root /usr/local/templates
SetHandler perl-script
PerlHandler Test::MyModule
/Location
Beginning of MyModule.pm
-
# Get the uri
my($uri, $uri2);
$uri = $uri2 = $r-uri;
$uri2 =~ s[^/][]; # remove the leading '/'
# We only want to see .phtml files, or urls that end
with '/'
# or where the stuff past the last '/' doesn't contain
any '.'s.
# We'll check the later two case for a template and
then
# decline it if no template is found.
unless ($uri =~ /\.phtml$/ or
$uri =~ m!/$! or
$uri =~ m!.*/[^\.]+$!) {
return DECLINED;
}
Is this the best way to do this?
--
Thanks
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Aaron Ross [EMAIL PROTECTED] wrote: Would Files *.phtml /Files do the trick? No...the files don't actually exist under htdocs since I'm using Template-Toolkit. Thanks though. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Per Einar Ellefsen [EMAIL PROTECTED] wrote:
Can't you just drop the Location and use
Files *.phtml
SetHandler
/Files
or something like that? Seems like it would avoid
some overhead for you.
True...but the files don't actually exist. The
path/filename is used to map to a template.
However, I'm not sure if I understand what you mean
with
$uri =~ m!.*/[^\.]+$!) {
This may not be the best regex..but what I was trying
to do was to match something like
/directory/subdirectory which would normally be
redirected back to
/directory/subdirectory/index.html (or whatever is
set as DirectoryIndex files). I want to check for a
/directory/subdirectory/index.phtml file.
Hmm, but if you don't have a template, then you have
nothing to serve, right?
I'd like to also have other mod_perl handlers mapped
to other Locations like normal, so for example
/something I may not have a corresponding template
but I would have a
Location /something.
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- Per Einar Ellefsen [EMAIL PROTECTED] wrote: At 19:14 12.06.2002, Per Einar Ellefsen wrote: Location .*\.phtml|/ Sorry, make that LocationMatch ... /Location And /LocationMatch of course. That should work...thanks. For the most part *all* .phtml pages will be doing the same thing, taking session data and parsing out templates. In some cases I may need something entirely different as far as logic goes, like a message board or a reg form, but still using TT and session data. That's where I'll be using a different Location, TT Plugins or Stas's suggestion...or any other suggestions I may receive. HTML::Mason would probably be a closer match to what I'm trying to do (replacing PHP), but we use TT for everything :) __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Mapping to location /
--- darren chamberlain [EMAIL PROTECTED] wrote: If you use a translation handler, you can just return DECLINED for everything you aren't specifically handling, and let mod_dir do it's thing, instead of emulating it. I still would like to check first if there is an index.phtml template instead of going directly to the directory index files like index.html. Can I add my virtual index.phtml to DirectoryIndex so I don't have to look for it in my handler? I'm not quite clear on this one...but it might be once I read the guide on translation handlers :) I think what you want is something like this: I'll try this...thanks. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
