turday, September 28, 2002 3:03 PM
To: [EMAIL PROTECTED]
Subject: CGI Forms Problems (Getting Old Params)
Yesterday I ported a few thousand lines of code I'd been working on
over to Perl. It was quite a bit of work getting all of the strict
stuff correct and then fighting with the modules-d
On Sat, 28 Sep 2002, Shannon Appelcline wrote:
[snip]
> I start off with a simple index.cgi that I've made extremely short to
> avoid the issue of nested subroutines. It has a require:
>
> --
> $main::filePath = "/var/www/skotos/myskotos";
> require "${main::filePath}/modules/lib/mylib.pm";
Sh
ore modularized. (Huzzah.)
Unfortunately I've been continuing to have one program that I can't
figure out. Somehow, my information being submitted through forms
sometimes reverts to old data after I've clicked "Submit" and before
it's processed.
Now, I've read throug
Hello,
SS>The below is a sample bit of code I am using for very simple forum
SS>software. It acts erratically, sometimes seeing the contents of the form
SS>being POSTed to it and sometimes not. If a form POSTed is under 500
SS>bytes in length it works fine. Anything higher is hit and miss.
SS>
SS
On 8/8/2002 at 2:44 PM Richard Dice wrote:
>> So the idea when migrating from CGI to mod_perl for this most-finished
> > project was: Change as little as possible.
>
>That's a very sound idea. But I have a question: regarding the piece of
>code that you provided here, is that the original code
On 29 Apr 2002 09:16:42 +1000
simran <[EMAIL PROTECTED]> wrote:
: Have a look at the HTML::FillInForm module as well...
Yeah, thank you, I'll give it a try. I guess this is a natural candidate
for an output chain, the HTML generated by two or three Apache modules
will need that post-process, so
Have a look at the HTML::FillInForm module as well...
it works wonders for me...
On Sat, 2002-04-27 at 04:43, darren chamberlain wrote:
> * Ken Clark <[EMAIL PROTECTED]> [2002-04-26 14:33]:
> > I'll throw my technique into the ring, too. I use Template Toolkit
> > most of the time, and I pass
* Ken Clark <[EMAIL PROTECTED]> [2002-04-26 14:33]:
> I'll throw my technique into the ring, too. I use Template Toolkit
> most of the time, and I pass the original Apache request object back
> to the template as a parameter. Then I call the "param" method to
> fill in the "value" of form elemen
Forgot to cc the list.
-- Forwarded message --
Date: Fri, 26 Apr 2002 11:35:37 -0400 (EDT)
From: Ken Y. Clark <[EMAIL PROTECTED]>
To: F.Xavier Noria <[EMAIL PROTECTED]>
Subject: Re: How to generate pre-filled forms?
On Fri, 26 Apr 2002, F.Xavier Noria wrote:
> Da
ry template.
* One can pass an object reference to a template as long as it has a
method called "param" that behaves as CGI::param(). The idea is that
will be translated to $r->param('color').
* HTML::FillInForm parses an already constructed HTML page and
At 4:15 PM +0200 4/26/02, F.Xavier Noria wrote:
>I am writing some modules that receive a form, process it, and return a
>page that includes that very form. Is there a standard way to fill that
>returned form so the user sees the same data he sent there, as CGI.pm
>does?
>
>-- fxn
>
>PS: I am usin
mentation:
> Note that HTML::FillInForm is directly supported in Apache::ASP.
> Other toolkits may support it as well.
Embperl's automatic form fill is one of the main reasons I use it. Without a
single line of perl, forms will automatically get filled in, using GET and POST
arguments that
At Fri, 26 Apr 2002 07:17:44 -0700,
Paul Lindner wrote:
> Note that HTML::FillInForm is directly supported in Apache::ASP.
> Other toolkits may support it as well.
You can get the glues for HTML::Template and TT:
HTML::Template::FillInForm and Template::Plugin::FillInForm from
http://bulknews.ne
On Fri, Apr 26, 2002 at 04:15:52PM +0200, F.Xavier Noria wrote:
> I am writing some modules that receive a form, process it, and return a
> page that includes that very form. Is there a standard way to fill that
> returned form so the user sees the same data he sent there, as CGI.pm
> does?
>
> -
I am writing some modules that receive a form, process it, and return a
page that includes that very form. Is there a standard way to fill that
returned form so the user sees the same data he sent there, as CGI.pm
does?
-- fxn
PS: I am using Apache modules + HTML::Template if that matters.
> I'm curious about one thing: How easy is it to do fill-out forms
> with pipelining templating systems like AxKit? I'd think that in
> such cases the stylesheet would have to do so much work that it
> would become, in essence, like a CGI script.
Can you explain what wor
>
> > But then if you're happy with EmbPerl, why switch?
>
> A couple of reasons, really:
>
> 1) well, I actually wouldn't switch per se; people think in
> different ways, and it's often useful to support (and feel
> comfortable with) different development paradigms
>
Embperl 2.0 (sta
> -Original Message-
> From: Richard L. Goerwitz III [mailto:[EMAIL PROTECTED]]
>
> Is AxKit the best of the pipelining breed, though? (I personally
> am finding XML to be a ghastly, ugly thing; it all started with
> namespaces, which are implemented via attributes in a horribly
> kludgy
Matt Sergeant wrote:
> But then if you're happy with EmbPerl, why switch?
A couple of reasons, really:
1) well, I actually wouldn't switch per se; people think in
different ways, and it's often useful to support (and feel
comfortable with) different development paradigms
2) EmbPe
I tend to use PerForm for complex forms:
http://theoryx5.uwinnipeg.ca/CPAN/data/AxKit-XSP-PerForm/PerForm.html
Others write custom taglibs:
http://theoryx5.uwinnipeg.ca/CPAN/data/AxKit/Apache/AxKit/Language/XSP/Tagli
bHelper.html
The general idea is that the output is an abstract
;m curious about one thing: How easy is it to do fill-out forms
with pipelining templating systems like AxKit? I'd think that in
such cases the stylesheet would have to do so much work that it
would become, in essence, like a CGI script. In other words, the
neat separation between content and p
Matt Sergeant wrote:
> Its only insecure if you don't use sysopen($fh, $newname, O_RDWR | O_EXCL
> | O_CREAT) (and then get a new filename if that failed 'cos the file
> existed).
Well, then at least the subroutines mkstempt and mkstemp are insecure,
since they call (funny, the comment below is b
On Thu, 19 Oct 2000, Alexander Farber (EED) wrote:
> Matt Sergeant wrote:
> > Not multiple times, but let them upload and store in a temp file, which
> > you can store the filename as a hidden field. Use File::MkTemp to create
> > the filenames.
>
> Thanks for the advice, but doesn't File::MkTem
Matt Sergeant wrote:
> Not multiple times, but let them upload and store in a temp file, which
> you can store the filename as a hidden field. Use File::MkTemp to create
> the filenames.
Thanks for the advice, but doesn't File::MkTemp have a race condition?
The subroutine File::MkTemp::mktemp do
Matt Sergeant wrote:
>
> On Thu, 19 Oct 2000, Alexander Farber (EED) wrote:
>
> > How do you handle uploading files when using multi-paged
> > forms (for example entered text and a picture are previewed
> > before storing into the database and special directory)?
>
On Thu, 19 Oct 2000, Alexander Farber (EED) wrote:
> How do you handle uploading files when using multi-paged
> forms (for example entered text and a picture are previewed
> before storing into the database and special directory)?
>
> Uploaded files can't be passed as hidden
How do you handle uploading files when using multi-paged
forms (for example entered text and a picture are previewed
before storing into the database and special directory)?
Uploaded files can't be passed as hidden fields, right?
So do you let your users to upload the same file several
time
ill functionality
into Apache::ASP with the help of HTML::FillInForm, and
think that the best "standardized" way would model the ASP+
method as Paul mentions below with
...
At output time then the buffer will be inspected for
these forms, and autofilled. Note that this will
probably b
st->Form if you wish.
Then put something like this in your apache configuration:
XMLSubsMatch fillin
Finally, surround your forms like this:
And voila, instant filled in forms..
Note that a small variation to this technique allows for ASP3.0 style
evaluation of form
hi,
I am interested in knowing the best way to generate forms w/ mod_perl. At
the moment I use CGI.pm in combination w/ mod_perl. But I am not sure I
am using it correctly or if it's the best way.
Perhaps I should just use a HTML::Template?
Here is a bit of the output code from my pr
Vivek Khera wrote:
> > "PH" == Peter Haworth <[EMAIL PROTECTED]> writes:
>
> >>
> >> HTML::Form? :)
>
> PH> Well, duh! Why didn't I think of that? Unfortunately though,
> PH> HTML::Form already exists, and doesn't really do the same kind of
> PH> thing. How about HTML::FormGen?
>
> How 'bo
> "PH" == Peter Haworth <[EMAIL PROTECTED]> writes:
>>
>> HTML::Form? :)
PH> Well, duh! Why didn't I think of that? Unfortunately though,
PH> HTML::Form already exists, and doesn't really do the same kind of
PH> thing. How about HTML::FormGen?
How 'bout HTML::StickyForms ?
--
=-=-=-=-=-=
Peter Haworth wrote:
>
> brian moseley wrote:
> > On Mon, 22 May 2000, Peter Haworth wrote:
> > > In light of the non-dependency on mod_perl, the
> > > Apache::Request::Form name is also out. I'd still rather
> > > not use the CGI::Form name, in case there are any
> > > current users whose interf
? :)
>
> Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already
> exists, and doesn't really do the same kind of thing. How about HTML::FormGen?
HTML::Forms?
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl
brian moseley wrote:
> On Mon, 22 May 2000, Peter Haworth wrote:
> > In light of the non-dependency on mod_perl, the
> > Apache::Request::Form name is also out. I'd still rather
> > not use the CGI::Form name, in case there are any
> > current users whose interface would change, which is a
> > sha
> "PH" == Peter Haworth <[EMAIL PROTECTED]> writes:
PH> In light of the non-dependency on mod_perl, the
PH> Apache::Request::Form name is also out. I'd still rather not use
PH> the CGI::Form name, in case there are any current users whose
PH> interface would change, which is a shame, because
On Mon, 22 May 2000, Peter Haworth wrote:
> That's fairly likely. How about this kind of interface?
>
> my $form=CGI::Form->new($r); # Except for the name. See below
> # Or: my $form=CGI::Form->new($cgi);
>
> print $form->textfield(name => 'name', size => '60', default => 'Peter');
yup,
brian moseley wrote:
> On Wed, 17 May 2000, Vivek Khera wrote:
>
> > I think the name CGI::Form is appropriate, since the
> > forms are part of the CGI protocol, not anything
> > mod_perl or Apache sepecific. CGI::Form seems to be an
> > abandoned module, so I&#x
On Fri, 19 May 2000, Doug MacEachern wrote:
> 'ref_array' => sub {
> my @a;
> push @a, \($one, $two, $three);
> my_print(@a);
> },
aha. i knew i wasn't on crack. i just forgot an important
detai
: >
: >On Wed, 17 May 2000, Peter Haworth wrote:
: >
: > > Drew Taylor and I are about to write a subclass of Apache::Request
which
: > > includes form element generation methods, a la CGI.pm. The current
: >favourite
: > > name is Apache::Request::Forms, but we&
"Jeffrey W. Baker" wrote:
>
> On Thu, 18 May 2000, brian moseley wrote:
>
> > On Thu, 18 May 2000, Autarch wrote:
> > pretty slow if you build a string using .= instead of using
> > smarter methods, like pushing strings onto an array and then
> > joining it.
>
> You tried to sell me that when I
On Fri, 19 May 2000, Matt Sergeant wrote:
>
> Damn - forgot smiley. Sorry :-)
doh. your reponse combined with my jetlag == foncusion :-)
On Fri, 19 May 2000, Doug MacEachern wrote:
> > I would say that the bigger picture is definitely not generating HTML with
> > functions - use templates or stylesheets.
>
> you're probably right. but that's not what i was getting at.
> i was trying to make points about the bigger picture in gen
Matt,
All I'm looking for is the fastest way to print sticky form elements. I
already use HTML::Template for the page templating engine (and it works
very well!). I need to take a look at CGI v.3 beta to see if it answers
some of my concerns about memory usage.
Matt Sergeant wrote:
>
> On Fri,
On Fri, May 19, 2000 at 06:08:41PM +0100, Matt Sergeant wrote:
>
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.
At the very moment, I have a problem to find arguments to persuate my
colleagues to accept this vision. Do you
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.
you're probably right. but that's not what i was getting at.
i was trying to make points about the bigger picture in general. trying
to answer "why write something in c that's
o, in my book, for generating regular HTML.
The only problem is with making a template that has sticky forms with
non-text fields. Making a sticky menu select object ain't easy in
templated-HTML, in my experience. I prefer to do forms (at least the
menus
On Fri, 19 May 2000, Doug MacEachern wrote:
> personally, i like to have generic things written in c, things that won't
> change much or at all after they are first implemented (not including bug
> shaking). e.g. Apache::Request. both c and Perl are great languages and
> blend very well togethe
On Fri, 19 May 2000, Autarch wrote:
> Well, my point was that the decision to code something in C should be done
> because it offers an overwhelming (orders of magnitude) improvement,
> preferably on more than one front (speed, memory, ease of maintenance
> (haha) ).
small savings here and ther
On Fri, 19 May 2000, Doug MacEachern wrote:
> > C seems like serious overkill for something to simply generate plain text
> > output. How slow is making a string in perl compared to doing it in C?
> > I can't imagine there's to much of a difference.
>
> more like Perl is serious overkill :)
>
On Fri, 19 May 2000, Gunther Birznieks wrote:
> eg I think there was a thread on this list way back about OO method calls
> versus direct package references... and people said that OO method calls
> have a lot of overhead, but I think in later versions of Perl, OO method
> call paths are cach
On Thu, 18 May 2000, brian moseley wrote:
> On Thu, 18 May 2000, Jeffrey W. Baker wrote:
>
> > .= concatenation is way faster
>
> i don't have any results to back up my claim. therefore,
> my words are eaten :)
>
> i was convinced tho, even way back before you came to cp. i
> wonder what convi
On Thu, 18 May 2000, Autarch wrote:
> C seems like serious overkill for something to simply generate plain text
> output. How slow is making a string in perl compared to doing it in C?
> I can't imagine there's to much of a difference.
more like Perl is serious overkill :)
SV's are BIG, noti
> i do think that doug's separation of responsibilities into
> classes is the right one. your widget toolkit probably
> shouldn't be named Apache::HTML tho, unless it's actually
> using the apache api in some fashion.
one reason i was thinking Apache::HTML is so we can use ap_pool for
allocations
I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:
- The target is automatically : add , update, select data
from a table reading data typed by the user.
- I didn't want to use the Apache api, so it even can be
used out of apache, so I ca
At 10:53 AM 5/18/00 -0700, brian moseley wrote:
>On Thu, 18 May 2000, Jeffrey W. Baker wrote:
>
> > .= concatenation is way faster
>
>i don't have any results to back up my claim. therefore,
>my words are eaten :)
>
>i was convinced tho, even way back before you came to cp. i
>wonder what convince
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
> .= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
Autarch wrote:
> I really don't think we need yet another module doing what CGI does. The
> people who've worked on the new version have done a very good job of
> addressing the memory and speed concerns people had about the current
> monolothic version. I think its much better to extend their
-default=>$value" part of the method call isn't it? I don't create
forms elements with out specifying the default value.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
On Thu, 18 May 2000, brian moseley wrote:
> On Thu, 18 May 2000, Autarch wrote:
>
> > C seems like serious overkill for something to simply
> > generate plain text output. How slow is making a string
> > in perl compared to doing it in C? I can't imagine
> > there's to much of a difference.
>
On Thu, 18 May 2000, brian moseley wrote:
> i suggest that instead of subclassing Apache::Request, you
> write the following set of classes:
>
> 1) html widget class
> 2) sticky forms class - use html widget class, take $r or $q
>as param
> 3) "wrapper&quo
On Thu, 18 May 2000, Drew Taylor wrote:
> What do you define the difference to be between #1 and
> #2? All I need is sticky forms - primarily the
> popup_menu(). If HTML widgets are b(), td(), etc, then
> we didn't plan on creating those. Forms is the main
> point of th
brian moseley wrote:
>
> On Thu, 18 May 2000, Autarch wrote:
>
> > C seems like serious overkill for something to simply
> > generate plain text output. How slow is making a string
> > in perl compared to doing it in C? I can't imagine
> > there's to much of a difference.
>
> pretty slow if y
brian moseley wrote:
>
> i suggest that instead of subclassing Apache::Request, you
> write the following set of classes:
>
> 1) html widget class
> 2) sticky forms class - use html widget class, take $r or $q
>as param
> 3) "wrapper" class - gives you the
On Thu, 18 May 2000, Autarch wrote:
> C seems like serious overkill for something to simply
> generate plain text output. How slow is making a string
> in perl compared to doing it in C? I can't imagine
> there's to much of a difference.
pretty slow if you build a string using .= instead of us
new module.
ah, ok. bumming.
i suggest that instead of subclassing Apache::Request, you
write the following set of classes:
1) html widget class
2) sticky forms class - use html widget class, take $r or $q
as param
3) "wrapper" class - gives you the CGI.pm interface, uses
sticky
On Wed, 17 May 2000, Doug MacEachern wrote:
> personally, i'd like to see Apache::HTML for generating html, written in
> c. something simple along the lines of HTML::AsSubs, then another class
> to glues it and Apache::Request together that provides CGI.pm features,
> like &#x
brian moseley wrote:
>
> On Thu, 18 May 2000, Drew Taylor wrote:
>
> > I personally have code that puts a CGI.pm object in the
> > object ($self), which is then used for both HTML
> > generation AND fetching params AND cookies.
> >
> > For example, I have lines like 'my $val =
> > $self->{CGI}->
On Thu, 18 May 2000, Drew Taylor wrote:
> I personally have code that puts a CGI.pm object in the
> object ($self), which is then used for both HTML
> generation AND fetching params AND cookies.
>
> For example, I have lines like 'my $val =
> $self->{CGI}->param('blah')' as well as 'my $form =
>
brian moseley wrote:
>
> On Thu, 18 May 2000, Peter Haworth wrote:
>
> > I'm getting more confident about calling it
> > Apache::Request::Form (no "s", for name similarity with
> > CGI::Form) now. It is dependent on Apache::Request,
> > after all, and reusing the CGI::Form name makes it look
> >
On Thu, 18 May 2000, Peter Haworth wrote:
> I'm getting more confident about calling it
> Apache::Request::Form (no "s", for name similarity with
> CGI::Form) now. It is dependent on Apache::Request,
> after all, and reusing the CGI::Form name makes it look
> more general than it really is, not t
GI.pm features,
> > like 'sticky forms'. but, i haven't given that much thought.
> Well, I wouldn't mind doing it in C (since the raison d'etre is to be as
> absolutely fast & lean as possible), but I don't know C. :-(
I'd have no problem writing it
st together that provides CGI.pm features,
> > like 'sticky forms'. but, i haven't given that much thought.
> Well, I wouldn't mind doing it in C (since the raison d'etre is to be as
> absolutely fast & lean as possible), but I don't know C. :-(
i sugges
Doug MacEachern wrote:
>
> personally, i'd like to see Apache::HTML for generating html, written in
> c. something simple along the lines of HTML::AsSubs, then another class
> to glues it and Apache::Request together that provides CGI.pm features,
> like 'sticky form
On Wed, 17 May 2000, Peter Haworth wrote:
> Drew Taylor and I are about to write a subclass of Apache::Request which
> includes form element generation methods, a la CGI.pm. The current favourite
> name is Apache::Request::Forms, but we'd like to know if anyone has a better
&
brian moseley wrote:
>
> what part of the mod_perl api are you going to actually use?
> with the list of widgets you sent earlier, i'm hard pressed
> to see where anything other than $obj->param will be useful
> to you. i don't see where you would get any benefit from
> being "mod_perl specific".
Gunther Birznieks wrote:
> You stated why but it seemed a bit vague. You mention performance. What
> about CGI.pm's HTML generation methods is too slow that you will improve
> using mod_perl specific features? And why is the API itself a reason for it
> being slow that you have to make the API i
rrent
> favourite
> > > name is Apache::Request::Forms, but we'd like to know if anyone has a
> better
> > > one.
> >
> > There's going to be a new version of CGI some time in the future which
> > will allow you to only use the parts of it you
request anyway.
If people didn't want you to pervert the code, they wouldn't have made it
open source.
> > I think the name CGI::Form is appropriate, since the forms are part of
> > the CGI protocol, not anything mod_perl or Apache sepecific.
> > CGI::Form seems to be
ke is not really needed as the new
CGI.pm will do what you want and will have a reasonably reduced memory and
speed overhead. One thing that could be done to improve this would be to
break the currently fairly large CGI::Object::Html class into several
smaller classes (::Forms ::Tables ::??). Then
On Wed, 17 May 2000, Drew Taylor wrote:
> That is an interesting point Brian. What I would like is
> a single object I can use to get form params OR generate
> HTML, ala CGI.pm, but mod_perl specific for speed
> reasons. The idea is to have as small a memory footprint
> as possible, using the mod
>>>>> "DT" == Drew Taylor <[EMAIL PROTECTED]> writes:
>> I think the name CGI::Form is appropriate, since the forms are part of
DT> Well, in our case we are looking to make it mod_perl specific. See my
Right... But if your interface only relies on cal
>>>>> "bm" == brian moseley <[EMAIL PROTECTED]> writes:
bm> actually forms are specified in HTML, not CGI.
Ok... if you say so.
bm> consider writing your forms library to depend on an
bm> interface, not a specific class, so that users can provide
bm>
brian moseley wrote:
>
> peter: i question why you want to subclass Apache::Request,
> rather than provide a helper class that maybe maintains a
> reference to an Apache::Request object, or some other weaker
> type of relationship.
That is an interesting point Brian. What I would like is a single
code from one module in another if they
are both released under the same license?
> I think the name CGI::Form is appropriate, since the forms are part of
> the CGI protocol, not anything mod_perl or Apache sepecific.
> CGI::Form seems to be an abandoned module, so I'm sure you
On Wed, 17 May 2000, Vivek Khera wrote:
> I think the name CGI::Form is appropriate, since the
> forms are part of the CGI protocol, not anything
> mod_perl or Apache sepecific. CGI::Form seems to be an
> abandoned module, so I'm sure you can get permission to
> adopt it and
Autarch wrote:
>
> On Wed, 17 May 2000, Peter Haworth wrote:
>
> > Drew Taylor and I are about to write a subclass of Apache::Request which
> > includes form element generation methods, a la CGI.pm. The current favourite
> > name is Apache::Request::Forms, but we
>>>>> "PH" == Peter Haworth <[EMAIL PROTECTED]> writes:
PH> Drew Taylor and I are about to write a subclass of Apache::Request
PH> which includes form element generation methods, a la CGI.pm. The
PH> current favourite name is Apache::Request::Forms, b
Autarch wrote:
> On Wed, 17 May 2000, Peter Haworth wrote:
>
> > Drew Taylor and I are about to write a subclass of Apache::Request which
> > includes form element generation methods, a la CGI.pm. The current
> > favourite name is Apache::Request::Forms, but we'd lik
:
>Drew Taylor and I are about to write a subclass of Apache::Request which
>includes form element generation methods, a la CGI.pm. The current favourite
>name is Apache::Request::Forms, but we'd like to know if anyone has a better
>one.
>
>The module is currently planned to be
On Wed, 17 May 2000, Peter Haworth wrote:
> Drew Taylor and I are about to write a subclass of Apache::Request which
> includes form element generation methods, a la CGI.pm. The current favourite
> name is Apache::Request::Forms, but we'd like to know if anyone has a better
> on
Drew Taylor and I are about to write a subclass of Apache::Request which
includes form element generation methods, a la CGI.pm. The current favourite
name is Apache::Request::Forms, but we'd like to know if anyone has a better
one.
The module is currently planned to be fairly bare-boned,
d when there is no side effect.
e.g. when submitting a search query, when asking for one's bank balance
or otherwise fetching info. The browser uses the GET method to fetch
HTML docs, images, and everything else except forms which specify a
different method.
POST is to be used when there is
where I select an article to
modify and hit 'modify', it sends me to the cancel page. Checking the
source of the select page the 'submit' variable was set to 'modify' as it
should have been... if it is a caching issue, do you any way to fix that?
Thanks in advance,
Hi Etienne,
CGI forms are "sticky"--they remember their value from the previous call,
even if you manually set a value. Try adding a -force=>1 to the hashref
that gets passed into the submit function
($q->submit(-name=>'submit',-value=>'Modify',-force=&g
Hi,
I'm having trouble with a script is use for posting, modifying,
and submiting queued news to a database that gets used by another script
to (to display stuff in the database).
When no parameters are passed in, the script displays a list of all the
articles waiting to be posted (from a databas
96 matches
Mail list logo
