Re: [cgiapp] CGI::Application and CGI::Session
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application
object
# so that it would be available later in the destroy sub.
#
# $self-param('_SESSION', $session-id());
#
#
If you want to store the session object, then this is probably what you
want:
$self-param('_SESSION',$session);
This stores the reference to the session object.
#
# This works, the session id appears on the template page.
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from
$self-param('_SESSION') as you have it currently coded. Instead, if
you make the change noted above, you could (to make it transparent) do:
my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());
elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
These should work with the first change noted above.
As a general comment, I would suggest using plugins whenever possible
when working with CGI::Application. These offer standard methods for
dealing with various objects commonly needed for web development
(sessions, database handles, templates, etc.). For example, it is
possible that you could create several connections to the database as
you have written here. Using the DBH plugin, your application can set
up one database handle (if needed, otherwise not) and share it
throughout. The session plugin will only create a session if a session
is needed; again, it makes the session object available throughout your
application as $self-session. I at first thought--I can this just as
well, but I learned that it was better to use these plugin modules
until I ran into a barrier that could not be overcome, then just build
on what was available. It is a great learning experience to see what
others have done, as it is (at least for me), usually amazing how small
these modules actually are, just cleverly and thoughtfully coded. And
most of the developers have given thought to running under a mod_perl
environment, where caching and singleton behaviors can be used.
Hope this helps
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 3:12 AM, Sean Davis wrote:
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the
reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I
know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application
object
# so that it would be available later in the destroy sub.
#
# $self-param('_SESSION', $session-id());
#
#
If you want to store the session object, then this is probably what
you want:
$self-param('_SESSION',$session);
This stores the reference to the session object.
#
# This works, the session id appears on the template page.
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from
$self-param('_SESSION') as you have it currently coded. Instead, if
you make the change noted above, you could (to make it transparent)
do:
my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());
elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
These should work with the first change noted above.
Originally, I tried $self-param('_SESSION',$session);. It didn't
work so I tried $self-param('_SESSION', $session-id());, it didn't
work either. At your suggestion, I changed back to
$self-param('_SESSION',$session); and uncommented the my $session
..., ...delete and ...flush lines of code above. I am still
getting this message: Error executing run mode '3': Can't call method
delete on an undefined value at .
As a general comment, I would suggest using plugins whenever possible
when working with CGI::Application. These offer standard methods for
dealing with various objects commonly needed for web development
(sessions, database handles, templates, etc.). For example, it is
possible that you could create several connections to the database as
you have written here. Using the DBH plugin, your application can set
up one database handle (if needed, otherwise not) and share it
throughout. The session plugin will only create a session if a
session is needed; again, it makes the session object available
throughout your application as $self-session. I at first thought--I
can this just as well, but I learned that it was better to use these
plugin modules until I ran into a barrier that could not be overcome,
then just build on what was available. It is a great learning
experience to see what others have done, as it is (at least for me),
usually amazing how small these modules actually are, just cleverly
and thoughtfully coded. And most of the developers have given thought
to running under a mod_perl environment, where caching and singleton
behaviors can be used.
Hope this helps
Sean
It does indeed help. I will definitely take a look at the
session-management plugin.
Thanks again for the help.
Peter -
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 9:52 AM, Peter Fogg wrote:
On Mar 10, 2005, at 3:12 AM, Sean Davis wrote:
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the
reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I
am
sure that I have written code that does not conform to best
practices;
please feel free to comment, I need all the help I can get! BTW, I
know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application
object
# so that it would be available later in the destroy sub.
#
# $self-param('_SESSION', $session-id());
#
#
If you want to store the session object, then this is probably what
you want:
$self-param('_SESSION',$session);
This stores the reference to the session object.
#
# This works, the session id appears on the template page.
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from
$self-param('_SESSION') as you have it currently coded. Instead, if
you make the change noted above, you could (to make it transparent)
do:
my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());
elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently
commented out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
These should work with the first change noted above.
Originally, I tried $self-param('_SESSION',$session);. It didn't
work so I tried $self-param('_SESSION', $session-id());, it didn't
work either. At your suggestion, I changed back to
$self-param('_SESSION',$session); and uncommented the my $session
..., ...delete and ...flush lines of code above. I am still
getting this message: Error executing run mode '3': Can't call method
delete on an undefined value at .
Oops, my bad. Note that in order to have access to your session
object, it must be created first. It looks like in run_mode 3, a
session object hasn't been created. Remember that the run_modes do not
run in order (and, typically only 1 run_mode runs per request). In
order to set up your session for use later, set it up in setup and
store the session object at that point. Then you can call
$self-param('_SESSION') in any of your run_modes.
Sean
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
Originally, I tried $self-param('_SESSION',$session);. It didn't
work so I tried $self-param('_SESSION', $session-id());, it
didn't work either. At your suggestion, I changed back to
$self-param('_SESSION',$session); and uncommented the my $session
..., ...delete and ...flush lines of code above. I am still
getting this message: Error executing run mode '3': Can't call
method delete on an undefined value at .
Oops, my bad. Note that in order to have access to your session
object, it must be created first. It looks like in run_mode 3, a
session object hasn't been created. Remember that the run_modes do
not run in order (and, typically only 1 run_mode runs per request).
In order to set up your session for use later, set it up in setup and
store the session object at that point. Then you can call
$self-param('_SESSION') in any of your run_modes.
Sean
.
.
.
sub create_set
{
my ($self, @args) = @_;
my $data_source = 'DBI:mysql:db_gokart';
my $db_Username = 'go_kart';
my $db_Password = 'N5q23B';
my $dbh = DBI-connect($data_source, $db_Username, $db_Password,
{RaiseError = 1, PrintError = 0})
or die Can't
connect to $data_source: $DBI::errstr;
###
# Session created here
#
# my $session = CGI::Session-new(driver:MySQL, undef,
{Handle=$dbh});
#
###
$session-param(-name = '_IS_LOGGED_ON', -value = '1');
###
# Session stored in CGI::Application instance here
#
# $self-param('_SESSION', $session);
#
###
my $cgi = $self-query();
my $sid_cookie = $cgi-cookie($session-name(), $session-id());
$self-header_props(-type='text/html', -cookie=$sid_cookie);
my $page = HTML::Template-new(filename =
'/Library/WebServer/CGI-Executables/_TEST_/session/
sessionTest_MySQL_create_set.tmpl');
###
# Session is successfully retrieved here
#
# $page-param('-sessionref' = $self-param('_SESSION'));
#
###
return $page-output();
}
sub destroy
{
my ($self, @args) = @_;
###
# Session is not successfully retrieved here
#
# my $session = $self-param('_SESSION');
#
###
$session-delete();
$session-flush();
my $page = HTML::Template-new(filename =
'/Library/WebServer/CGI-Executables/_TEST_/session/
sessionTest_MySQL_destroy.tmpl');
# $page-param('-sessionref' = $self-param('_SESSION'));
return $page-output();
}
.
.
.
You are absolutely right that the session has not been created in sub
destroy. However, I ALWAYS call sub create_set before I call sub
destroy. My thinking is that if I create the session object in sub
create_set and save it in the application object that the session
object should be available in the application object when I
subsequently call sub destroy. BTW, the way my application works is
that I display a page with three links. The second link calls sub
create_set and displays a message that a session object has been
created. A link on that page takes one back to the original page. The
third link calls sub destroy expecting to find the session object
available in the application object which doesn't seem to be the case.
It seems that the session object is going out of scope before sub
destroy is called.
Peter -
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
Peter Fogg wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. I think there might be some confusion about how 'param' works. Once a run mode returns content to the browser, anything in $self-param is gone (actuall everything except cookies is 'gone' since HTTP is stateless). It does not maintain state (that's what sessions are for :). So you can't store anything in there and expect it to still be there after you deliver a page to the user. Others have suggested it before so I'm just following up... Have you looked at CGI::Application::Plugin::Session? It's about the easiest way in the world to use sessions with C::A. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Peter - - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
I ran into this, too and thought it would make a great infusion for the
Perl Webdev community.
I'm still trying to get my head around it, but having it supported in
cgiapp would be great, perhaps as a Plugin or something.
Here are some other ideas:
1) HTML::Template
In the PHP example, they have a ? rs_show_javascript(); ?. Then the
backend has to worry about escaping the JavaScript code. HTML::Template
already has a nice ESCAPE feature: !-- TMPL_VAR NAME=rs_javascript
ESCAPE=JS --
2) App. Development
What would the app look like? How can we make it simple for webdevs?
-
use WWW::AJAX::Simple;
my $app = WWW::AJAX::Simple-new();
$app-expose_function( 'multiply' );
$app-run();
-
That was my initial take, but having it as a Plugin sounds tastier. ;)
-
use CGI::Application::Plugin::SAjax;
sub setup {
# ...
$self-sajax_methods( [ qw( multiply divide ) ] );
}
-
It'd be neat to do something (prolly more complicated method definitions
ala dfv) such that the Plugin can create the JavaScript functions
automatically.
$self-sajax_methods( {
'multiply' = { 'params' = [ qw( x y ) ], 'reset_value' = 'z' },
'divide' = { 'params' = [ qw( x y ) ], 'reset_value' = 'z' },
} );
Can you imagine what would happen if Mark/Cees/Michael/Jesse/Sam got
ahold of this? ;)
I would love to help out on this effort, so please count me in, if
you're looking for help. :)
- Jason
Steve Comrie wrote:
Good Afternoon,
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's
basically a way for web pages to communicate with the server and return
information through JavaScript without having to refresh the page.
You can read more about it here:
http://www.adaptivepath.com/publications/essays/archives/000385.php and see it in
action here: http://www.google.com/webhp?hl=encomplete=1
There are currently some useful applications for AJAX and, I'm sure, lots of
superfluous ones too. I'm hopeful that the number of useful ones will grow as
the technology becomes more wide-spread and easy to use, which brings me to the
point of my post.
I stumbled across a site called SAJAX (http://www.modernmethod.com/sajax/)
today that has developed a *S*imple AJAX method that can be used with Perl, via
their Sajax.pm file.
After playing around with it for a while, I was able to strip down their code
(actually getting rid of all their Perl code, and leaving only the JavaScript,
which I edited and packaged up as a .js file) in-order to figure out exactly
how AJAX works and more importantly, how to easily integrate it with a CGI::App
based module.pm file.
I converted their demo app -
http://www.modernmethod.com/sajax/sajax-0.8/php/example_multiply.php to one running
on my code using C::A - http://www.unobserved.org/misc/rs/
I invite anyone that's interested in learning more about using AJAX to take a
look at my sample app.
I've provided source files for download from the page which include:
- index.html
- remotescript.js ( the required javascript library that does all the
XMLHTTPRequest magic )
- rscalc.cgi ( C::A instance script )
- RemoteScriptCalc.pm ( C::A Application Module )
The example uses 2 very simple run-modes, a multiply and a divide run-mode. The
divide() run-mode takes advantage of how to handle error messages when
communicating with the script remotely.
As far as I can tell, I see no problem with including a couple of AJAX based
run-modes into an existing C::A module (provided you setup the JavaScript on
the calling page properly).
Hopefully, some others will find this useful and hopefully be able to use it in
their C::A apps. I know I intend to implement it soon for apps where I know the
browser requirements are met.
I didn't document the code very much, but I kept it nice, clean and organized
to help readability. Good knowledge of javascript is needed to hack the
remotescript.js file, but you don't need to be an expert in-order to use it.
If you want to talk about the applications of using XMLHTTPRequest with C::A
I'm sure we can keep this on the list, but if you're having trouble getting my
sample code to install or work on your server contact me directly so we don't
clutter up the list. I'll try and help out time permitting.
BTW - I don't know what the exact browser requirements are however, I just know
it works on my WinXP IE6 or Firefox. The SAJAX site might have more info on
that.
That URL again is: http://www.unobserved.org/misc/rs/
Steve Comrie
LEAD SOFTWARE ARCHITECT | OCTANE
T: 416.977.2525
F: 416.977.8481
355 ADELAIDE ST. W. SUITE 1B
TORONTO, ONTARIO M5V 1S2
WWW.OCTANE.TO
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To
RE: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Very Fine Work. Thanks for contributing this to the community. Cheers --Fred -Original Message- From: Steve Comrie [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 10:54 AM To: cgiapp@lists.erlbaum.net Subject: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX Good Afternoon, If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's basically a way for web pages to communicate with the server and return information through JavaScript without having to refresh the page. You can read more about it here: http://www.adaptivepath.com/publications/essays/archives/00038 5.php and see it in action here: http://www.google.com/webhp?hl=encomplete=1 There are currently some useful applications for AJAX and, I'm sure, lots of superfluous ones too. I'm hopeful that the number of useful ones will grow as the technology becomes more wide-spread and easy to use, which brings me to the point of my post. I stumbled across a site called SAJAX (http://www.modernmethod.com/sajax/) today that has developed a *S*imple AJAX method that can be used with Perl, via their Sajax.pm file. After playing around with it for a while, I was able to strip down their code (actually getting rid of all their Perl code, and leaving only the JavaScript, which I edited and packaged up as a .js file) in-order to figure out exactly how AJAX works and more importantly, how to easily integrate it with a CGI::App based module.pm file. I converted their demo app - http://www.modernmethod.com/sajax/sajax-0.8/php/example_multiply.php to one running on my code using C::A - http://www.unobserved.org/misc/rs/ I invite anyone that's interested in learning more about using AJAX to take a look at my sample app. I've provided source files for download from the page which include: - index.html - remotescript.js ( the required javascript library that does all the XMLHTTPRequest magic ) - rscalc.cgi ( C::A instance script ) - RemoteScriptCalc.pm ( C::A Application Module ) The example uses 2 very simple run-modes, a multiply and a divide run-mode. The divide() run-mode takes advantage of how to handle error messages when communicating with the script remotely. As far as I can tell, I see no problem with including a couple of AJAX based run-modes into an existing C::A module (provided you setup the JavaScript on the calling page properly). Hopefully, some others will find this useful and hopefully be able to use it in their C::A apps. I know I intend to implement it soon for apps where I know the browser requirements are met. I didn't document the code very much, but I kept it nice, clean and organized to help readability. Good knowledge of javascript is needed to hack the remotescript.js file, but you don't need to be an expert in-order to use it. If you want to talk about the applications of using XMLHTTPRequest with C::A I'm sure we can keep this on the list, but if you're having trouble getting my sample code to install or work on your server contact me directly so we don't clutter up the list. I'll try and help out time permitting. BTW - I don't know what the exact browser requirements are however, I just know it works on my WinXP IE6 or Firefox. The SAJAX site might have more info on that. That URL again is: http://www.unobserved.org/misc/rs/ Steve Comrie LEAD SOFTWARE ARCHITECT | OCTANE T: 416.977.2525 F: 416.977.8481 355 ADELAIDE ST. W. SUITE 1B TORONTO, ONTARIO M5V 1S2 WWW.OCTANE.TO - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote: On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Yep. Just be clear that YOU have to set assure that the session id is available at the next invocation of your script, either by way of a cookie value, a hidden field paramater, or a parameter in the URL. The browser does not handle this on its own (unlike for basic authentication, for example, but that is another issue). Really, try using cgi::app::plugin::session. Then, look at the code to see how it works. Like a good little module, it is VERY well documented (within the code itself), so you can literally read it for understanding Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Hi Steve, -Original Message- If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's basically a way for web pages to communicate with the server and return information through JavaScript without having to refresh the page. Very cool stuff indeed. I converted their demo app - http://www.modernmethod.com/sajax/sajax- 0.8/php/example_multiply.php to one running on my code using C::A - http://www.unobserved.org/misc/rs/ [*SNIP*] The example uses 2 very simple run-modes, a multiply and a divide run- mode. The divide() run-mode takes advantage of how to handle error messages when communicating with the script remotely. I posted about a similar technology on the list just over a year ago [1]. It uses a library called JSRS [2]. I've written a perl module to interface with the library -- it can be found under the JavaScript::RPC namespace [3]. My module works slightly different in that you need to use it as your base class. Also, method parameters are sent to the sub via @_ rather than through the query string errors are reported just by die()ing. (Though, obviously you could write a module to do things similarly for AJAX) You can see these differences in the demo usage [4]. Anyway, I'm glad that this is finally becoming main-stream -- perhaps it will influence the way we write applications. Cheers, -Brian [1] http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg01593.html [2] http://www.ashleyit.com/rs/ [3] http://search.cpan.org/dist/JavaScript-RPC/ [4] http://search.cpan.org/src/BRICAS/JavaScript-RPC-0.06/demo/jsrpc.pl - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Jason,
IMHO, what the folks at SAJAX were trying to do (with including the
javascript code inside the Sajax.pm module) and calling SAJAX::functions
from inside your perl code is just way to complicated for no noticeable (at
least at first look) reason.
I'm sure for more complicated implementations there may be a need for a
helper function or module to make sure the returned content gets back to the
browser properly.
The meat of the technology is really in the JavaScript, not the language
that you're using on the server side. That's why I created a .js file to
encapsulate the XMLHTTPRequest.
The perl code behind it is actually QUITE simple, and in my opinion it
should stay that way. I think XMLHTTPRequest integrates *seamlessly* into
C::A without any Plugins or additional modules (at least for now).
1) HTML::Template
In the PHP example, they have a ? rs_show_javascript(); ?. Then the
backend has to worry about escaping the JavaScript code. HTML::Template
already has a nice ESCAPE feature: !-- TMPL_VAR NAME=rs_javascript
ESCAPE=JS --
I bypassed this step completely by created the .js file and including the
following in my template
script type='text/javascript' src='remotescript.js'/script
2) App. Development
What would the app look like? How can we make it simple for webdevs?
---
$self-sajax_methods( {
'multiply' = { 'params' = [ qw( x y ) ], 'reset_value' = 'z' },
'divide' = { 'params' = [ qw( x y ) ], 'reset_value' = 'z' },
} );
I by passed these steps by creating one standard javascript function that
all of your html file based XMLHTTPRequests use to call a server-side script
instead of a duplicated block of javascript code for each function that
SAJAX currently creates for each one.
Really just think of it as a form submit that returns very simple out put to
a javascript function already on the page as opposed to returning an entire
HTML page.
One plausible use is this:
I have a screen in my app that allows you to associate a record with a group
from a drop-down.
If you haven't created a group by the time you've gotten to the edit record
screen, you could make an XMLHTTPRequest to your code that created the group
(as long as you give the user a Create New Group input box on that page.
Your C::A script would receive the request just like it does any other
request, create the group, and return the new group id directly back to the
edit record page.
Now, that page could use a simple block of javascript code to add the new
group to the drop-down menu so that the user could select the group, save
the record and be done.
---
Steve Comrie
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Class::DBI please help with error
Hi, I am using Class::DBI in my CGI::Application apps now with no problem when I use on my web host's server. I installed all needed modules locally in my account there and I have had no problems. The problem is using it in any way whatsoever on my home pc. I am now using Red Hat Linux running inside vmware (great recommendation by the way - thanks!) and I have everything running fine. I can even run simple apps that query a MySQL database using DBI. I upgraded Perl from 5.8.0 to 5.8.6 because the install for HTML::Template requested it (utf-8 issue I think). I installed Class::DBI with no problem, all tests ran fine. Everytime I try to run any code that tries to access a column, I get an error like this: [Thu Mar 10 14:26:52 2005] [error] [client 127.0.0.1] Can't use string (DBIx::ContextualFetch::ISA) as an ARRAY ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/DBI.pm line 531. The funny thing is that I am not using 5.8.0 anymore, even though the libraries are still there. Class::DBI and all of the new modules I installed are in /usr/local/lib/perl5/site_perl/5.8.6 if I do this from the command line: perl -e 'print $_\n for @INC' The 5.8.0 directories do not show up. If I do the equivalent listing of @INC from a cgi script, they do show up. I am at a loss for what to do at this point. Someone on irc mentioned upgrading mod_perl. I don't know if I have that on this system, but I am starting my scripts with #!/usr/bin/perl and my httpd.conf file is not set up for mod_perl. I was tempted to delete all 5.8.0 material, but a little careful experimenting demonstrated that this is not a good idea. I'm sorry for giving so much information here, but I hope someone can give me a tip on where to go from here. I am starting to feel like there is a cosmic conspiracy keeping me from using this module on my home pc. Thanks! Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Class::DBI please help with error
On Mar 10, 2005, at 5:17 PM, [EMAIL PROTECTED] wrote: Hi, I am using Class::DBI in my CGI::Application apps now with no problem when I use on my web host's server. I installed all needed modules locally in my account there and I have had no problems. The problem is using it in any way whatsoever on my home pc. I am now using Red Hat Linux running inside vmware (great recommendation by the way - thanks!) and I have everything running fine. I can even run simple apps that query a MySQL database using DBI. I upgraded Perl from 5.8.0 to 5.8.6 because the install for HTML::Template requested it (utf-8 issue I think). I installed Class::DBI with no problem, all tests ran fine. Everytime I try to run any code that tries to access a column, I get an error like this: [Thu Mar 10 14:26:52 2005] [error] [client 127.0.0.1] Can't use string (DBIx::ContextualFetch::ISA) as an ARRAY ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/DBI.pm line 531. The funny thing is that I am not using 5.8.0 anymore, even though the libraries are still there. Class::DBI and all of the new modules I installed are in /usr/local/lib/perl5/site_perl/5.8.6 if I do this from the command line: perl -e 'print $_\n for @INC' The 5.8.0 directories do not show up. If I do the equivalent listing of @INC from a cgi script, they do show up. You are running under mod_perl? If so, was it built against 5.8.0 or 5.8.6? If not, what does the #! line point to (which executable--is it the correct version of perl)? Also, did you install DBI under 5.8.6? But I am certainly NOT an expert I am at a loss for what to do at this point. Someone on irc mentioned upgrading mod_perl. I don't know if I have that on this system, but I am starting my scripts with #!/usr/bin/perl and my httpd.conf file is not set up for mod_perl. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Class::DBI please help with error
[EMAIL PROTECTED] wrote: perl -e 'print $_\n for @INC' The 5.8.0 directories do not show up. If I do the equivalent listing of @INC from a cgi script, they do show up. Sounds like you have multiple perl installations on your box and your scripts are using a different one that you have in your PATH. Type 'which perl' at the command line to see where it sits, and then make sure your cgi scripts point to that same perl. If you are using mod_perl, then you will have to recompile it with the same perl that you are using from the command line. I am at a loss for what to do at this point. Someone on irc mentioned upgrading mod_perl. I don't know if I have that on this system, but I am starting my scripts with #!/usr/bin/perl and my httpd.conf file is not set up for mod_perl. It's easy to see if you have mod_perl built into your apache. /usr/local/apache/bin/httpd -l and look for an entry like 'mod_perl.c' If you don't see it, and you don't have anything in your config for mod_perl, then that's probably not what's happening. I was tempted to delete all 5.8.0 material, but a little careful experimenting demonstrated that this is not a good idea. Yeah, that won't solve the problem since it's still using the wrong perl whether or not the libraries are there. I'm sorry for giving so much information here, but I hope someone can give me a tip on where to go from here. I am starting to feel like there is a cosmic conspiracy keeping me from using this module on my home pc. Let us know if the above helps. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] Class::DBI please help with error
A wild guess - From memory, I believe the RH RPM installs Perl in /usr/bin, but if you compiled Perl from source without changing the defaults, it will most likely have installed in /usr/local/bin - so you may have two Perls installed, and your code may be pointing to the old one... Do you see a difference between /usr/bin/perl -v and /usr/local/bin/perl -v ? Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 11 March 2005 11:18 To: cgiapp@lists.erlbaum.net Subject: [cgiapp] Class::DBI please help with error Hi, I am using Class::DBI in my CGI::Application apps now with no problem when I use on my web host's server. I installed all needed modules locally in my account there and I have had no problems. The problem is using it in any way whatsoever on my home pc. I am now using Red Hat Linux running inside vmware (great recommendation by the way - thanks!) and I have everything running fine. I can even run simple apps that query a MySQL database using DBI. I upgraded Perl from 5.8.0 to 5.8.6 because the install for HTML::Template requested it (utf-8 issue I think). I installed Class::DBI with no problem, all tests ran fine. Everytime I try to run any code that tries to access a column, I get an error like this: [Thu Mar 10 14:26:52 2005] [error] [client 127.0.0.1] Can't use string (DBIx::ContextualFetch::ISA) as an ARRAY ref while strict refs in use at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/DBI.pm line 531. The funny thing is that I am not using 5.8.0 anymore, even though the libraries are still there. Class::DBI and all of the new modules I installed are in /usr/local/lib/perl5/site_perl/5.8.6 if I do this from the command line: perl -e 'print $_\n for @INC' The 5.8.0 directories do not show up. If I do the equivalent listing of @INC from a cgi script, they do show up. I am at a loss for what to do at this point. Someone on irc mentioned upgrading mod_perl. I don't know if I have that on this system, but I am starting my scripts with #!/usr/bin/perl and my httpd.conf file is not set up for mod_perl. I was tempted to delete all 5.8.0 material, but a little careful experimenting demonstrated that this is not a good idea. I'm sorry for giving so much information here, but I hope someone can give me a tip on where to go from here. I am starting to feel like there is a cosmic conspiracy keeping me from using this module on my home pc. Thanks! Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 11:13 AM, Sean Davis wrote: On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote: On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Yep. Just be clear that YOU have to set assure that the session id is available at the next invocation of your script, either by way of a cookie value, a hidden field paramater, or a parameter in the URL. The browser does not handle this on its own (unlike for basic authentication, for example, but that is another issue). Really, try using cgi::app::plugin::session. Then, look at the code to see how it works. Like a good little module, it is VERY well documented (within the code itself), so you can literally read it for understanding Sean Two questions and a comment and I'll be out of your hair! So I get the session id sent by the browser and do a $session = CGI::session-new( ... with the retrieved session id as the second parameter. The method will retrieve the session variables stored in the storage medium. Do I have that right? What is the feeling about the merits of the driver being File or DB_File or MySQL? The only reason that I didn't use CGI::Application::Plugin::Session in the first place is the fact that it is an alpha version as opposed to a 3+ version for CGI::Session. However, on your recommendation I will take a very close look at the plugin version to solve my problem. Many thanks for the help that I received from you and Michael Peters. Regards, Peter - - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] CGI::Application and CGI::Session
On Mar 10, 2005, at 5:54 PM, Peter Fogg wrote: On Mar 10, 2005, at 11:13 AM, Sean Davis wrote: On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote: On Mar 10, 2005, at 9:10 AM, Sean Davis wrote: You are absolutely right that the session has not been created in sub destroy. However, I ALWAYS call sub create_set before I call sub destroy. My thinking is that if I create the session object in sub create_set and save it in the application object that the session object should be available in the application object when I subsequently call sub destroy. BTW, the way my application works is that I display a page with three links. The second link calls sub create_set and displays a message that a session object has been created. A link on that page takes one back to the original page. The third link calls sub destroy expecting to find the session object available in the application object which doesn't seem to be the case. It seems that the session object is going out of scope before sub destroy is called. If you click on a link on a page, that reruns the script--the application object is not stored between clicks. By the time the page is generated in the browser, the application object is gone. You cannot then click on a link to go to another run_mode and find what was stored in the application object. Make sense? Sean Boy, is my understanding of objects in this environment WAY off base!! I think of objects as staying resident in the server memory until I destroy them. Your comment above makes sense and really turned on a light for me! So every request for my application results in the creation of a new application object, execution of the requested sub, submission of the resulting page to the browser and destruction of the application object. The request from the browser includes the previously set session id which I use to retrieve that session object from whatever storage system was used when the session was created. I would then use the data that is retrieved from the storage system to recreate a session object for the duration of the current request just as a new application object was created. Is this correct? Yep. Just be clear that YOU have to set assure that the session id is available at the next invocation of your script, either by way of a cookie value, a hidden field paramater, or a parameter in the URL. The browser does not handle this on its own (unlike for basic authentication, for example, but that is another issue). Really, try using cgi::app::plugin::session. Then, look at the code to see how it works. Like a good little module, it is VERY well documented (within the code itself), so you can literally read it for understanding Sean Two questions and a comment and I'll be out of your hair! So I get the session id sent by the browser and do a $session = CGI::session-new( ... with the retrieved session id as the second parameter. The method will retrieve the session variables stored in the storage medium. Do I have that right? Yep. What is the feeling about the merits of the driver being File or DB_File or MySQL? I like relational databases, but that is just me. There are bound to be strong feelings one way or the other, particularly in terms of performance, so I would say until you have a problem, just pick one for experimentation purposes. The only reason that I didn't use CGI::Application::Plugin::Session in the first place is the fact that it is an alpha version as opposed to a 3+ version for CGI::Session. However, on your recommendation I will take a very close look at the plugin version to solve my problem. One of the (many) reasons that I like CGI::Application and its plugins is that all of the authors are on this list constantly, answering questions, responding (in a meaningful way) to bug reports or concerns, giving tips and tricks about how to best use the software. Therefore, I think that although CGI::App::plugin:: is likely to not be as battle-tested as something like CGI::Session or CGI itself, that doesn't mean it is full of bugs. And, even if it is, the author is likely to be on this list and can answer questions within minutes of your asking. Not many CPAN modules have this level of fast and personal support, I think. So, I would just use them all, but certainly if you have questions about one of the plugins, ask here--it is a very personable forum. In fact, I can remember a question coming up on the list (I think it was about sharing database handles throughout the application), and within less than 24 hours, someone had made a plugin to do just that. That is user support! Many thanks for the help that I received from you and Michael Peters. Regards, Peter - Let us know how it goes. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe,
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Hi all, If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's basically a way for web pages to communicate with the server and return information through JavaScript without having to refresh the page. For those interested in using JavaScript to update parts of the page (rather that refreshing it completely) here is a whole (CGI::App-derived) framework built on that idea: http://search.cpan.org/~eric/OpenThought-0.71/lib/OpenThought.pm http://search.cpan.org/~eric/OpenPlugin-0.11/OpenPlugin/Application.pm It uses a hidden frame to communicate with the server (which is what people did before the advent of XMLHTTPRequest, but the idea is the same). I have not used OpenThought, just stumbled upon the link. And since we are at it, has anyone done experiments with building CGI::Apps for Mozilla XUL that they want to share? (This is of course totally non-cross-browser, so not useful for web sites, but could be worth a look for Intranet applications) Thilo - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Steve Comrie [EMAIL PROTECTED] wrote:
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX
it's basically a way for web pages to communicate with the server and
return information through JavaScript without having to refresh the
page.
You can read more about it here:
http://www.adaptivepath.com/publications/essays/archives/000385.php
and see it in action here:
http://www.google.com/webhp?hl=encomplete=1
[and here] ...SAJAX (http://www.modernmethod.com/sajax/)
[and now the CGI::App port, here] I converted their demo app
to one running on my code using C::A
http://www.unobserved.org/misc/rs/
I invite anyone that's interested in learning more about using AJAX
to take a look at my sample app.
Nice proof of concept, Steve!
I guess this is an (actually old) idea that's seems to have been hitting
critical mass lately (probably due to the clever new acronym!) Just a
few days ago, I was devouring the examples at
http://www.pengoworks.com/workshop/js/gateway/ (the zip code lookup
examples rock!) which actually doesn't use XMLHttpRequest at all, but
rather a hidden IFRAME (because this code is 5 years old). The concept
of non-page-loading web apps has been banging around that long, but I
guess Google Suggest and Google maps have just recently pushed the
technique to the tipping point.
I'm working on app currently that uses JavaScript to load a dozen or so
dropdowns, each of which can grow quite long indeed. One client
populated the thing with so much data that dynamic JS code had swelled
the page weight well past 700K! Fortunately that wasn't as painful as
it sounds since the business users of this (non-public) web app all
enjoy fast broadband connections, but that, the old fashioned way sure
isn't gonna scale!
So Google Suggest has got me thinking about dynamically populating drop
downs as the user types, with only the incrementally defined subsets of
data that they need to see. So I'm really itching to try this out with
CGI::App, too!
But now I'm not sure if XMLHTTPRequest of this hidden-IFRAME hack is the
best way to go. Google maps seem to be using an IFRAME, while Google
suggest uses the XMLHttpRequest {sigh}. I guess it doesn't matter now,
cross-browser-wise. The link below (almost a year old) says that
XMLHttpRequest support has been in IE since IE5, Mozilla since 1.4 and
Safari since 1.2 (and dubs the IFRAME trick a hack):
Apple Developer Connection: Dynamic HTML and XML: The XMLHttpRequest
Object
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
with it's own Appleesque example (loading an RSS feed of your mission
critical I-Tunes)
http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html
and here's another excellent article from the Apple developer
connection, this time a treatment of the hidden IFRAME route, which they
call Remote Scripting.
Remote Scripting with IFRAME:
http://developer.apple.com/internet/webcontent/iframe.html
While, here it is called Round-Tripping:
http://www.glendinning.org/webbuilder/roundTripIframe/
(which sounds more like something we'd rather not admit we did back in
high school...)
But whatever underlying technique is used, this is a Whole New Way of
thinking about developing web apps, and I'm guessing that, now that the
cross browser support is there, we'll be seeing (and building!) a lot of
these.
-dave
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Class::DBI please help with error
It's true: my new Perl (5.8.6) is at /usr/local/bin/perl That was the whole problem. Another problem that came up after was the lack of DBD- mysql. The rpm would not work. It was crazy. If I tried to install it said it was already installed. If I tried to remove, it said it was not installed. Then rpm got hung up and could not be killed. I then went to CPAN and ran install DBD::mysql. I had to change it to force install because most of the tests were being failed, probably because I had set the root password for mysql already. Rather than go through the trouble to make the tests work, I just forced the install. As far as I can tell, it's all working now. My little test web apps are running as expected. At least with vmware, I can save the virtual machine's state and write it to DVD for easy backup. It runs pretty fast, even on a 3 year old P4 1.8GHz laptop. Thanks for all the help! Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
