Re: [cgiapp] C::A::P::Session not 'remembering' session
Cees:
> That is odd, as it usually works out of the box without requiring any
> configuration.
You're absolutely right. I was just trying too hard. After commenting out
session_config and having it work, I successfully added back in:
$self->session_config( DEFAULT_EXPIRY => '+15m');
As I am finding with all of C::A stuff (this being my first week using
C::A and the plug-ins) is that it's almost *too* easy. I was telling a
fellow coder, who has yet to make the switch, that I'm incredulous
everytime I use a new plug-in (once I get them installed).
Anyway, hats off to all those who have contributed to the C::A way, the
Perlmonks that pushed me in the first place (guilt), and for this
list-serve that has made the jump so much easier for me.
Brad
> On 12/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
>> Seems like I have spent more time on C::A::P::Session than all the other
>> plugins combined--and I just can't get it to work.
>
> That is odd, as it usually works out of the box without requiring any
> configuration.
>
>> It is setting a session
>> in cgiapp_postrun after logging in for the first time (it is also
>> setting
>> a cookie very nicely). This is evidenced by the line: 'logged_in: 1" in
>> my
>> debug2.txt file and the visual setting of the cookie.
>>
>> However, when I come return from the next HTML page to execute another
>> runmode, the session is coming up empty. This is evidenced by the line:
>> 'logged_in: ' in my debug1.txt file.
>>
>> In good olde CGI::Session, I have to use the session id to retrieve the
>> session:
>>
>>my $session_id = cookie('CGISESSID');
>>my $session = new CGI::Session("driver:File", $session_id,
>> {Directory=>'/tmp'});
>
> Actually, you don't have to do that with CGI::Session, you can just
> give it a CGI.pm object and it will figure out the session_id from
> that. That is the technique that CAP::Session uses.
>
>> I see that an id is created in the cookie by C::A::P::S, but how is it
>> use
>> to retrieve the session, if at all? Here's my bare bones code:
>>
>> sub cgiapp_init {
>>my $self = shift;
>>
>>$self->session_config(
>>CGI_SESSION_OPTIONS => [ "driver:File", $self->query,
>> {Directory=>'/tmp'} ],
>>DEFAULT_EXPIRY => '+15m',
>>COOKIE_PARAMS => { -name=> 'designsoft',
>> -path=> '/'},
>>SEND_COOKIE => 1);
>
> What you are doing here is telling CAP::Session to use a different
> name for the cookie. The docs for CAP::Session warn you about doing
> that. My recommendation would be to comment out your entire
> 'session_config' line and let CAP::Session use its defaults. That
> should work for everyone. Then you can start adding customizations in
> and test as you make changes. That way you will figure out where
> things are going wrong.
>
> Cheers,
>
> Cees
>
>
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: C::A::P::Session not 'remembering' session
On 2005-12-17, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> sub cgiapp_postrun {
>my $self = shift;
>$self->set_session(); #set the session
> }
>
> sub set_session {
>my $self = shift;
>$self->session->param(user_name => $user_name);
>$self->session->param(user_id => $user_id);
>$self->session->param(logged_in => 1); #persistent
>
> open (DEBUG, ">debug2.txt") or die "debug error: $!";
> print DEBUG "logged_in:". $self->session->param('logged_in')."\n"; close
> DEBUG;
> }
I recommended using postrun for this, becaues it runs after every run
mode in the module, but is only needed one once: After you have logged
in. I would find it more efficient and logicial to then call
set_session() at the end of the login processing run mode.
"postrun" tends to be rarely used my experience.
The one related thing I have done is to call "$self->session->flush()"
in the teardown() phase. I think that should happen automatically.
Mark
--
http://mark.stosberg.com/
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: C::A::P::Session not 'remembering' session
Mark, > > I recommended using postrun for this, becaues it runs after every run > mode in the module, but is only needed one once: After you have logged > in. I would find it more efficient and logicial to then call > set_session() at the end of the login processing run mode. Thanks, I didn't realize that it ran after every run mode. I'll put it up in cgiapp_init. > > "postrun" tends to be rarely used my experience. > > The one related thing I have done is to call "$self->session->flush()" > in the teardown() phase. I think that should happen automatically. Are you saying flush happens automatically and not to use it? One more question. flush comes from C::S. Am I reading that I can use methods from the "parent" modules in the C::A::Plugins? Thanks, Brad > > > Mark > > -- > http://mark.stosberg.com/ > > > - > Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ > http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=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=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: C::A::P::Session not 'remembering' session
On 2005-12-17, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> "postrun" tends to be rarely used my experience. >> >> The one related thing I have done is to call "$self->session->flush()" >> in the teardown() phase. I think that should happen automatically. > > Are you saying flush happens automatically and not to use it? If you don't mind, let me read the documentation for CGI::Session flush to you: flush() "Synchronizes data in the buffer with its copy in disk. Normally it will be called for you just before the program terminates, or session object goes out of scope, so you should never have to flush() on your own. " > One more question. flush comes from C::S. Am I reading that I can use > methods from the "parent" modules in the C::A::Plugins? I'm not quite sure what you are asking. To be safe, use the method calling conventions that you see documented. Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: C::A::P::Session not 'remembering' session
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 17, 2005 2:29 PM > To: Mark Stosberg > Cc: cgiapp@lists.erlbaum.net > Subject: Re: [cgiapp] Re: C::A::P::Session not 'remembering' session > > > Mark, > > > > I recommended using postrun for this, becaues it runs after > every run > > mode in the module, but is only needed one once: After you > have logged > > in. I would find it more efficient and logicial to then call > > set_session() at the end of the login processing run mode. > > Thanks, I didn't realize that it ran after every run mode. > I'll put it up > in cgiapp_init. > > > > "postrun" tends to be rarely used my experience. > > > > The one related thing I have done is to call > "$self->session->flush()" > > in the teardown() phase. I think that should happen automatically. > > Are you saying flush happens automatically and not to use it? > Yes, exactly. You can (and should) never call flush() directly, since it is automatically called when your CGI::Session object goes out of scope (i.e. it is DESTROYed). Not calling flush() is a nice way to check if you have memory leaks in your apps (I got bitten a couple of times by this). A memory leak could be caused by a circular reference: it happens for example if you save in a cgiapp param an external object whith a field which points back to the cgiapp object (and you don't weaken this latter reference). In this case, if you are using a persistent environment (such as (Apache|ModPerl)::Registry* or FastCGI), your CGI::Session object gets never DESTROYed, so your session parameters are not saved on disk (that is, at the next request you'll find your session data not updated). Ciao, Emanuele. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Good practices: how many run modes in an app
I'm writing a medium-sized web-based financial application that will have up to 50 run modes between presenting empty forms, saving, editing, updating, and deleting from them. Run modes *could* be broken down into groups, e.g., these 4 deal with managing users, these 6 deal with managing project specifications, etc. Being new to C::A I'm curious if there are any general rules of thumb as to the number of run modes (subs) that are run in any given Appl.pm. Besides the long list under setup, there might be performance issues, and places where trying to use a common sub might get messy. In my pre-C::A days I would have been more inclined to break it down into various scripts, maybe by function. But I'm not sure of how this fleshes out in a C::A world. Comments? Thanks, Brad - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
Brad Cathey wrote: > I'm writing a medium-sized web-based financial application that will have up > to 50 run modes between presenting empty forms, saving, editing, updating, > and deleting from them. Run modes *could* be broken down into groups, e.g., > these 4 deal with managing users, these 6 deal with managing project > specifications, etc. 50 is definitely too much. There isn't a hard rule to follow for what is too much, but I think there can never be too few. I usually split them up by functionality or user authentication level. And remember that base classes are your friend here. For instance, if I have admin and normal users and each can view reports. Some reports are the same, but some are different, I would split them up into the following structure: MyApp::Base - base class for all my app classes that might have classes to deal with configuration, database, sessions, templates, etc that they all have in common. MyApp::Report- base class for reports that contains those reports that everyone can see as well as common methods used to generate reports, graphs, etc MyApp::Report::Admin - app class containing admin reports MyApp::Report::User - normal user reports Most of it is personal perference, but you really need to break it into structures. > Being new to C::A I'm curious if there are any general rules of thumb as to > the number of run modes (subs) that are run in any given Appl.pm. Besides > the long list under setup, there might be performance issues, and places > where trying to use a common sub might get messy. I think the keyword here is 'messy'. OO programming in general is not about speed. It's almost always slower to use an OO approach, but it's very useful for organization. No matter what you write, you are always going to be making changes and adding new stuff. The better organized and cleaner it is, the happier you (and the person after you) will be. > In my pre-C::A days I would have been more inclined to break it down into > various scripts, maybe by function. But I'm not sure of how this fleshes out > in a C::A world. I'd follow the same kind of approach that you used to have. The advantage of the C::A world over using multiple scripts is inheritance. Break common functionality and common run modes out into base classes and you will be much happier. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
Thank you Michael, that was very helpful. Unfortunately it uncovered areas I'm unfamiliar with, that a good study of OO will help. > > Brad Cathey wrote: >> I'm writing a medium-sized web-based financial application that will have up >> to 50 run modes between presenting empty forms, saving, editing, updating, >> and deleting from them. Run modes *could* be broken down into groups, e.g., >> these 4 deal with managing users, these 6 deal with managing project >> specifications, etc. > > > 50 is definitely too much. There isn't a hard rule to follow for what is too > much, but I think there can never be too few. I usually split them up by > functionality or user authentication level. And remember that base classes are > your friend here. For instance, if I have admin and normal users and each can > view reports. Some reports are the same, but some are different, I would split > them up into the following structure: > > MyApp::Base - base class for all my app classes that might have classes > to deal with configuration, database, sessions, >templates, etc that they all have in common. > MyApp::Report - base class for reports that contains those reports that >everyone can see as well as common methods used to >generate reports, graphs, etc > MyApp::Report::Admin - app class containing admin reports > MyApp::Report::User - normal user reports > > Most of it is personal perference, but you really need to break it into > structures. > >> Being new to C::A I'm curious if there are any general rules of thumb as to >> the number of run modes (subs) that are run in any given Appl.pm. Besides >> the long list under setup, there might be performance issues, and places >> where trying to use a common sub might get messy. > > I think the keyword here is 'messy'. OO programming in general is not about > speed. It's almost always slower to use an OO approach, but it's very useful > for > organization. No matter what you write, you are always going to be making > changes and adding new stuff. The better organized and cleaner it is, the > happier you (and the person after you) will be. > >> In my pre-C::A days I would have been more inclined to break it down into >> various scripts, maybe by function. But I'm not sure of how this fleshes out >> in a C::A world. > > I'd follow the same kind of approach that you used to have. The advantage of > the > C::A world over using multiple scripts is inheritance. Break common > functionality and common run modes out into base classes and you will be much > happier. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Good practices: how many run modes in an app
On 2005-12-17, Michael Peters <[EMAIL PROTECTED]> wrote: > > Brad Cathey wrote: >> I'm writing a medium-sized web-based financial application that will have up >> to 50 run modes between presenting empty forms, saving, editing, updating, >> and deleting from them. Run modes *could* be broken down into groups, e.g., >> these 4 deal with managing users, these 6 deal with managing project >> specifications, etc. > > > 50 is definitely too much. There isn't a hard rule to follow for what is too > much, but I think there can never be too few. I usually split them up by > functionality or user authentication level. And remember that base classes are > your friend here. For instance, if I have admin and normal users and each can > view reports. Some reports are the same, but some are different, I would split > them up into the following structure: > > MyApp::Base- base class for all my app classes that might have classes > to deal with configuration, database, sessions, >templates, etc that they all have in common. > MyApp::Report - base class for reports that contains those > reports that >everyone can see as well as common methods used to >generate reports, graphs, etc > MyApp::Report::Admin - app class containing admin reports > MyApp::Report::User - normal user reports > > Most of it is personal perference, but you really need to break it into > structures. This is a FAQ that there should be a page about on the wiki if there is not already. Michael's answer is a great start. Anyone want to work on this? http://www.cgi-app.org/ Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Simple Implementation of Ajax.pm
There was a thread here in October with a request for an example of a simple implementation of CGI::App and Ajax. But then it went on and got a little too complicated -- at least I don't see any implementations simple enough for my skills in the followup posts :-) I'd particularly like to see something done with CGI::Ajax.pm, as I imagine it would be fairly easy to use that module. What I'd like to do, initially, is update a database without generating a new page. thanks Bruce - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Good practices: how many run modes in an app
I agree wholeheartedly with Mark. I've found this very helpful. A discussion and some examples of the base and apps classes in use would be great as well. Brad >> 50 is definitely too much. There isn't a hard rule to follow for what is too >> much, but I think there can never be too few. I usually split them up by >> functionality or user authentication level. And remember that base classes >> are >> your friend here. For instance, if I have admin and normal users and each can >> view reports. Some reports are the same, but some are different, I would >> split >> them up into the following structure: >> >> MyApp::Base - base class for all my app classes that might have classes >> to deal with configuration, database, sessions, >>templates, etc that they all have in common. >> MyApp::Report - base class for reports that contains those reports that >>everyone can see as well as common methods used to >>generate reports, graphs, etc >> MyApp::Report::Admin - app class containing admin reports >> MyApp::Report::User - normal user reports >> >> Most of it is personal perference, but you really need to break it into >> structures. > > This is a FAQ that there should be a page about on the wiki if there is > not already. Michael's answer is a great start. > > Anyone want to work on this? http://www.cgi-app.org/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
On Dec 17, 2005, at 1:48 PM, Bruce McKenzie wrote:
There was a thread here in October with a request for an example of a
simple implementation of CGI::App and Ajax. But then it went on and
got a little too complicated -- at least I don't see any
implementations simple enough for my skills in the followup posts :-)
I'd particularly like to see something done with CGI::Ajax.pm, as I
imagine it would be fairly easy to use that module. What I'd like to
do, initially, is update a database without generating a new page.
Hi Bruce,
Did you try to get the example in the docs for CGI::Ajax running?
I'm including the example script I got running on my desktop below,
hope it helps... After I got it running I played with Cees Hek's
"CGI-Application-Plugin-HTMLPrototype-0.20 - PodViewer Example"
It provides another approach and exercise to learn some AJAX stuff and
I ended up keeping the demo just to use for reference sake.
Kindest Regards,
--
Bill Stephenson
#!/usr/bin/perl
use CGI::Ajax;
use CGI;
my $input;
my $cgi = new CGI();
my $pjx = new CGI::Ajax( 'evenodd' => \&evenodd_func );
print $pjx->build_html($cgi,\&Show_HTML);
sub evenodd_func {
$input = shift;
# see if input is defined
if ( not defined $input ) {
return("input not defined or NaN");
}
# see if value is a number (*thanks Randall!*)
if ( $input !~ /\A\d+\z/ ) {
return("input is NaN");
}
# got a number, so mod by 2
$input % 2 == 0 ? return("EVEN") : return("ODD");
}
sub Show_HTML {
my $html = qq~
CGI::Ajax Example
Enter a number:
~;
return $html;
}
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
Thanks. I didn't have any trouble getting the dox examples running.
What has me flummoxed is getting an onClick event attached to a submit
button that will do what I want it to -- not submit the form, but rather
send the changed fields to an external perl script (run mode?) and
confirm that the changes were processed by the script without redrawing
the page. I think this probably isn't difficult, but I can't seem to
sort out who does what, when and where.
Here's what I tried:
# run mode in WebApp.pm
sub display_test_form {
my $self = shift;
use CGI::Ajax;
my $url = "handle_form.pl"; # A separate script to try
# to simplify things;
my $pjx = new CGI::Ajax( 'submit_formdata' => $url );
my $ajax_js = $pjx->show_javascript();
$self->tt_params(ajax_js=>$ajax_js);
my $output = $self->tt_process('test_form.tt2');
return $output;
}
// on the page generated by TTK (in addition to the javascript code
// generated by CGI::Ajax.pm
function doSubmit(){
submit_formdata(['Bert'],['resultdiv']); //Bert is a text field
return false;
}
and attached to the submit button:
onclick= doSubmit();
// doesn't work -- generates a "element has no properties"
// Javascript error
also tried the more obvious :
onclick = "submit_formdata(['Bert'],['resultdiv']);return false"
But that submits the damn form.
I was hoping just to get my feet wet -- HTML::Prototype looks kinda
deep for a beginner :-)
Bruce
Bill Stephenson wrote:
On Dec 17, 2005, at 1:48 PM, Bruce McKenzie wrote:
There was a thread here in October with a request for an example of a
simple implementation of CGI::App and Ajax. But then it went on and
got a little too complicated -- at least I don't see any
implementations simple enough for my skills in the followup posts :-)
I'd particularly like to see something done with CGI::Ajax.pm, as I
imagine it would be fairly easy to use that module. What I'd like to
do, initially, is update a database without generating a new page.
Hi Bruce,
Did you try to get the example in the docs for CGI::Ajax running?
I'm including the example script I got running on my desktop below, hope
it helps... After I got it running I played with Cees Hek's
"CGI-Application-Plugin-HTMLPrototype-0.20 - PodViewer Example"
It provides another approach and exercise to learn some AJAX stuff and I
ended up keeping the demo just to use for reference sake.
Kindest Regards,
--
Bill Stephenson
#!/usr/bin/perl
use CGI::Ajax;
use CGI;
my $input;
my $cgi = new CGI();
my $pjx = new CGI::Ajax( 'evenodd' => \&evenodd_func );
print $pjx->build_html($cgi,\&Show_HTML);
sub evenodd_func {
$input = shift;
# see if input is defined
if ( not defined $input ) {
return("input not defined or NaN");
}
# see if value is a number (*thanks Randall!*)
if ( $input !~ /\A\d+\z/ ) {
return("input is NaN");
}
# got a number, so mod by 2
$input % 2 == 0 ? return("EVEN") : return("ODD");
}
sub Show_HTML {
my $html = qq~
CGI::Ajax Example
Enter a number:
~;
return $html;
}
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
Bruce McKenzie wrote: I was hoping just to get my feet wet -- HTML::Prototype looks kinda deep for a beginner :-) I posted a perlmonks link on how I got my first CGI::App based Ajax widget running. It's very basic and simple so don't expect too much from it but it works. http://perlmonks.org/?node_id=469879 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
On Sat, 17 Dec 2005 14:48:37 -0500, Bruce McKenzie wrote:
Hi Bruce
> There was a thread here in October with a request for an example of
> a simple implementation of CGI::App and Ajax. But then it went on
> and got a little too complicated -- at least I don't see any
Yes, that's a pity.
I suggest you simply try it for yourself. I'll be something worth learning even
if - initially - it's not clear what's going on.
I use JavaScript::RPC::Server::CGI rather than CGI::Ajax, but the end result it
the same. I will try to create a demo or 2 next week. Here's hoping I get an
energy supply for Xmas :-).
With the docs for CGI::Ajax, there are a few things to note (the docs are quite
good, actually, I'll just mention things which are unclear [to me]):
o The synopsis has:
I think it would have been clearer to say:
name = "some_name"
so that you do not get the wrong idea about the usage of id.
o In section 4 Usage Methods, part 3 Sending Perl Subroutine Output to a
Javascript function, the part in bold is important, but the example below that
uses innerHTML. I've never used innerHTML myself. It would have been clearer if
the author had said: This is just one (1) way to do things.
To be specific, my JS functions populate fields with names such as:
input_add_entity_parent_entity_id
which in this case is defined as:
I needed a menu, so I used a select, and I needed to set a default value, hence
the tmpl_vars.
This indicates you can output HTML (here a pop-up menu), not just output passive
text.
It also indicates I did not output to a field identified by a div, because
JavaScript::RPC::Server::CGI does not work that way. I started using this module
before I saw CGI::Ajax was available, but since my file of manually-written JS
functions is over 300 lines long, using the latter module to auto-generate JS,
while /very/ neat, is not an option. Converting my code to use CGI::Ajax is not
worthwhile, on the principle of Don't Fix It If It Ain't Broke. I have nothing
against CGI::Ajax, of course.
This simply indicates that what you do is up to you.
o In part 4 URL/Outside Script CGI::Ajax example, it may not be clear, but in
the example:
my $url = 'scripts/other_script.pl';
my $pjx = new CGI::Ajax( 'external' => $url );
'external' is just some arbitrary name, not a reserved word.
With CGI::Ajax, choosing to use a URL is optional, which is good, whereas with
JavaScript::RPC::Server::CGI, you always do that. Here's a bit of JS:
jsrsExecute('/cgi-bin/mids/rpc-server.cgi',
find_add_primary_parent_callback,
'find_entity', prefix);
where find_add_primary_parent_callback is another JS function which receives the
output from Perl, and 'find_entity' is the Perl sub which gets called.
It's a good design, IMHO, to have a stand-alone CGI script for your AJAX work,
and I also have a Perl module (containing 'find_entity') dedicated to this too.
o Also in part 4 URL/Outside Script CGI::Ajax example, there is:
onClick="exported_func(['args__$input1','args__$input2'],
['resultdiv']);"
I think what the author is saying here is that the Perl script which outputs the
HTML containing this onClick, can pass data values to the Perl script called by
the AJAX process, by using the special prefix 'args__'.
o Dive in!
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 18/12/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
Thanks Fred -- that looks straightforward enough. However, the reason I'm attracted to CGI::Ajax (formerly Perljax) is that (as I understand the dox) you can do Ajax without knowing Javascript or XML :-) The module is quite new, so if I manage to figure this out, maybe I'll post my solution. The module authors maintain a bulletin board -- I've posted this question there, too -- http://www.perljax.us/forums/viewtopic.php?p=45#45 Cheers, Bruce Fred Moyer wrote: Bruce McKenzie wrote: I was hoping just to get my feet wet -- HTML::Prototype looks kinda deep for a beginner :-) I posted a perlmonks link on how I got my first CGI::App based Ajax widget running. It's very basic and simple so don't expect too much from it but it works. http://perlmonks.org/?node_id=469879 . - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Simple Implementation of Ajax.pm
On 2005-12-18, Ron Savage <[EMAIL PROTECTED]> wrote: > On Sat, 17 Dec 2005 14:48:37 -0500, Bruce McKenzie wrote: > > Hi Bruce > >> There was a thread here in October with a request for an example of >> a simple implementation of CGI::App and Ajax. But then it went on >> and got a little too complicated -- at least I don't see any In my experience I have extremely impressed with the Prototype.js library, and can recommend learning it. It will make basic things like what you need now easy, and it will be do very flashy things later when you are ready. Lots of docs are accessible through here: http://del.icio.us/search/?all=prototype+docs For what you need, a basic call to "Ajax.request" or Ajax.updater" should take care of it. HTML::Prototype and the related plugin are just wrappers about this. I like having them to get started with, but I find it easy enough to work directly with Prototype once I got the hang of it. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
On 12/17/05, Brad Cathey <[EMAIL PROTECTED]> wrote: > > I'm writing a medium-sized web-based financial application that will have up > to 50 run modes between presenting empty forms, saving, editing, updating, > and deleting from them. Run modes *could* be broken down into groups, e.g., > these 4 deal with managing users, these 6 deal with managing project > specifications, etc. I would break each of them up into functional areas. My rule of thumb is never more than 12, rarely more than 6, preferably 4 or less. Anything more and I'm trying to do too much in the controller and should be offloading into business objects. Rob - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Simple Implementation of Ajax.pm
Ron Savage wrote: o The synopsis has: I think it would have been clearer to say: name = "some_name" so that you do not get the wrong idea about the usage of id. Spot on, Ron! I got this note from one of the CGI::Ajax authors: "looks like you just need to add id's ... we don't use names, maybe we should add a fallback, if element not found by id look for: document.forms.element..." Thanks. Bruce - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
