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
shame,
On Tue, 23 May 2000, 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
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 interface would
"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 ?
--
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, looks good.
"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 that seems
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
detail ;)
"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 was at CP,
:
: 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
:
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
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.
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, notice
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 convinced me!
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
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 :)
SV's
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 there
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 together.
"MS" == Matt Sergeant [EMAIL PROTECTED] writes:
MS I would say that the bigger picture is definitely not generating HTML with
MS functions - use templates or stylesheets.
Templates (especially ones that let you iterate over arrays) are the
way to go, in my book, for generating regular HTML.
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
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, 19 May 2000, Matt Sergeant wrote:
Damn - forgot smiley. Sorry :-)
doh. your reponse combined with my jetlag == foncusion :-)
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 forms'. but, i haven't given that
On Thu, 18 May 2000, Drew Taylor wrote:
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,
Drew Taylor wrote:
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 forms'.
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 to
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
more
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}-param('blah')'
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 'sticky forms'. but, i
On Thu, 18 May 2000, Drew Taylor wrote:
No, my /CURRENT/ setup uses CGI.pm. I want to eliminate
it entirely in this new module, while not having to
change any of my existing application code. I would like
to not change any lines like the ones above when
switching to the new module.
ah, ok.
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 CGI.pm interface, uses
sticky forms
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 you build a
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 this module.
well the function
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" class - gives you the CGI.pm interface, uses
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.
pretty
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
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!
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 convinced me!
You
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 =
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, only
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
one.
There's going to
If you are considering writing subclasses that do similar things to CGI.pm,
you might consider looking at CGI.pm 3.0 as the various features (eg HTML
generation) are more broken out... And then the two would run more parallel
to each other.
At 03:30 PM 5/17/00 +0100, Peter Haworth wrote:
Drew
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 like to know if
anyone has a better
"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, but we'd like to
PH know if anyone has a better one.
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 like to know if anyone has a better
Vivek Khera wrote:
Have you looked at CGI::Form that already exists? It would be a good
basis. Currently, it is based on CGI::Request but should be able to
use Apache::Request one would expect.
Actually, I have briefly looked at this module and looked no more when I
realized it was no
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
"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 either a CGI object or an Apache::Request object.
"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 calling $x-param() then
it can be based on any CGI-ish
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
At 11:32 AM 5/17/00 -0400, Drew Taylor wrote:
Vivek Khera wrote:
Have you looked at CGI::Form that already exists? It would be a good
basis. Currently, it is based on CGI::Request but should be able to
use Apache::Request one would expect.
Actually, I have briefly looked at this module
At 11:25 AM 5/17/00 -0400, you wrote:
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
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
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".
See
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
one.
The module is
54 matches
Mail list logo
