Re: [cgiapp] Transferring control to another application

[bradford]

Bill, yes I have. But that really doesn't answer my question. I could be
any module that I am trying to transfer control to.

Brad

 On Dec 19, 2005, at 9:21 PM, [EMAIL PROTECTED] wrote:

 Typical scenario: The user is initially directed to Login.pm. After
 successfully logging in, a home screen is output. From there they can
 fire
 user.cgi and User.pm. Of course, I want to check their log-in status at
 the start of the User app, so I check the session. If they timed out, I
 want to direct them back to Login.pm.

 How do I do that and keep some object in tact?

 Have you looked at:

   CGI::Application::Plugin::Authentication;

 It will help maintain state between timeouts.

 Kindest Regards,

 --
 Bill





-
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] Re: RFC: Standard config interface for CGI::Application

[Mark Stosberg]

On 2005-12-20, Michael Graham [EMAIL PROTECTED] wrote:

 I want CGI::Apps to eventually have something like 'mark par'. Part of
 'mark par' conuld involve altering the configuration to adjust this.
 Exactly how...I'll leave to someone else.

 Yeah, I want that feature too!  One of the main barriers IMO is making
 C::A-based apps relocatable - i.e. they don't care where in the
 filesystem they run from.  I'd even be in favour of first class
 methods for this purpose, if people would use them:  

 my $root = $self-root_dir;
 my $uri = $self-root_uri;
 my $path = $self-relpath('foo/bar/baz');

 Maybe a CAP::Relpath plugin that CAP::PAR could depend on :)

 Anyway, someone can correct me if I've got the details wrong, but I
 think that when a PAR file is first run, it creates a randomly named
 directory in either /tmp or the user's home dir.  Into this directory it
 unpacks all of its modules, scripts and datafiles.

 So at the time when you package up the app, this directory doesn't
 actually exist yet, so you can't edit the config files to point to it.  

 It would have to be done via a config plugin that computes a value for
 'root_dir' based on the runtime value of $ENV{'PAR_TMP'}.

I can say two things:

1. Here's the source for most of the PAR-related logic that Catalyst
uses:
http://search.cpan.org/src/SRI/Catalyst-5.61/lib/Module/Install/Catalyst.pm
It doens't do anything with this environment variable. 

2. My hard drive has started to make a noise that concerns me. I hope
   it's just cold. (Could be. It's -5F as I prepare to walk to work!)

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]

[cgiapp] Re: RFC: (v2!) Standard config interface for CGI::Application

[Mark Stosberg]

Revised proposal follows.

On 2005-12-20, Mark Stosberg [EMAIL PROTECTED] wrote:

 Here's the specific API proposal I have in mind:

 =head2 $self-config
  
  Returns a hashref containing application configuration details.
  
  The intended use is to load to read-only configuration details once
  from a config file at start up time.  

  For applications that need little configuration, Lconfig() is not
  necessary-- using CPARAMS in an instance script should suffice.

  Also, the Cparam() is the appropriate method to use to set a
  configuraiton value at run time.

  Typically Cconfig() is overridden by a plugin which eases the process
  the parsing a configuration file. Configuration plugins that provide at
  least this basic API include:

   ...

  Please note that these plugins are free to provide to additional
  functionality beyond this. 



=head2 $self-config

The intended use is to load to read-only configuration details once
from a config file at start up time.  

This service is provided by plugins (list below). They must support at
at least this syntax:

 my $value = $self-config('key');

By default, Cconfig() simply returns undef, making it safe for other
plugins to directly to check if C$self-config('key') returns the
value it needs 

For applications that need little configuration, Lconfig() is not
necessary-- using CPARAMS in an instance script should suffice.

Also, the Cparam() is the appropriate method to use to set a
configuration value at run time.

Configuration plugins that provide at least this basic API include:

 ...

Please note that these plugins are free to provide to additional
functionality beyond this. 

=cut

sub config { undef }

=head3 Standard config variables

Users are encouraged to use these standard config variable names, to
ease compatibility between plugins: 

 ROOT_URI - A URI corresponding to the project root (http://foo.com/proj )
 ROOT_DIR - a file system path to the same location ( /home/joe/www/proj )

All-caps are used to denote that config variables are essentially global
constants. 

Mark

PS: When did URI become the favored term over URL?

Still Confused about That in Indiana










-- 
--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark StosbergPrincipal Developer  
   [EMAIL PROTECTED] Summersault, LLC 
   765-939-9301 ext 202 database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .


-
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] Re: RFC: Standard config interface for CGI::Application

[Michael Peters]

Mark Stosberg wrote:
 On 2005-12-20, Michael Graham [EMAIL PROTECTED] wrote:
 
Before anyone gets too worried, I would like to point out that this
proposal would not require a core change to C::A, but could be
implemented with a plugin using the existing plugin system.
 
 
 It be a plugin, but I think the definition of a standard API for this
 belongs in the core. Since we are talking about a single (5 line? )
 optional method, I think it's reasonable to add there.  It can still be 
 ignored or overridden if you choose. 

I'm actually leaning toward Graham's idea here that it just be in the plugins. I
like the API but I'm not sure it's something that should be in the core. I know
configuration is something pretty basic that every framework should have, but I
don't see C::A as a framework... more as a framework for building frameworks.

Besides, if the config plugins stabilize their API and it works out great then
more discussion can be had on adding it to the core. If it ends up being a
disaster, oh well, no permanent damage to C::A (maybe just a few plugin authors
who have to deprecate an old APIs).

* need a clean way of dealing with config formats that don't support
  hierarchical data structures.
 
 
 I see that happening like this: The session plugin declares: 
 
 You can configure me through your config file if you use one of the
 plugins that is powerful enough to support hierarchical data structures. 
 Otherwise, configure me manually.
 
 In other words, if you want to stick with a less powerful config file
 system, you aren't any worse off than you are now. 

I agree with this. There are tons of config systems that support hierarchical
data. If someone decides to not use one, they need to deal with that fact
themselves.

* plugins that want a database handle should be encouraged to look
  to $self-dbh before they get their connection info from the
  config file.
 
 
 Agreed. Also, supporting sub { $self-dbh } is nice when people /do/ use
 the explicit config interface. This keeps the handle from actually being  
 created until it is needed, if at all. 
 
 
* Any other computed config values that plugins typically need?
 
 
 Not that I can think of. 
 
 
* It might be reasonable to allow multiple config 'providers'.  For
  instance having a 'root_dir' param available that all plugins can
  rely on could be a really useful thing.

I think this idea definitely illustrates why this should not be in the core. Why
should C::A care about where your project is running? Sure your project might
care, but should C::A?

 I want CGI::Apps to eventually have something like 'mark par'. Part of
 'mark par' conuld involve altering the configuration to adjust this.
 Exactly how...I'll leave to someone else.

Again, not something that I think should be in the core. This is definitely
something that I don't want. PAR is neat, but not completely everything that I
need.

I'm much happier with something like the krang build/install system. If you need
a binary for a specific platform, you just take the source, run the build script
and viola! It even builds it's own apache/mod_perl/mod_ssl server with it, so
you never have to worry about server configuration. Of course these binaries
aren't cross-platform, but in reality neither are most PARs.

-- 
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] Transferring control to another application

[Ricardo SIGNES]

* [EMAIL PROTECTED] [2005-12-19T22:21:25]
 Influenced by a long thread that I started over the weekend about the
 number of run modes allowed in an application, I've been breaking my one
 large app into several. I have a question about turning control back to
 another module.

We do this a lot, with a method that, simplified to remove other weird things
we do, looks like this:

  sub redispatch {
my ($self, $newclass) = @_;
eval require $newclass;
die $@ if $@;

# by default, at the end of the runmode, the value is sent
# as the response.  we want to return the value instead.
local $ENV{CGI_APP_RETURN_ONLY} = 1;

$self-register_wrapper; # set up TT2 wrapping, a la Mason autohandler

return $newclass-new(
  PARAMS = { map { $_ = $self-param($_) } $self-param },
  QUERY  = $self-query,
)-run;
  }

This works very nicely.

-- 
rjbs


pgpSMIdMqNb3Q.pgp
Description: PGP signature

Re: [cgiapp] Re: RFC: Standard config interface for CGI::Application

[Cees Hek]

On 12/20/05, Mark Stosberg [EMAIL PROTECTED] wrote:
 On 2005-12-20, Michael Peters [EMAIL PROTECTED] wrote:
 
  I'm actually leaning toward Graham's idea here that it just be in the 
  plugins. I
  like the API but I'm not sure it's something that should be in the core. I 
  know
  configuration is something pretty basic that every framework should have, 
  but I
  don't see C::A as a framework... more as a framework for building 
  frameworks.

 In my v2 RFC I proposed a very minimum of code in the core:

  sub config { return undef }

 And that's just a convenience for plugin authors so they don't have to
 check if the 'config' method exists, they can directly check

  $self-config('key_i_want');

I want to create a standard logging API that plugins and users can use
as well (with plugins that support Log::Dispatch, Log::Log4perl and
simple print to STDERR plugins).  Should we add stubs for those
methods into the core as well?

Although 'config' is a pretty common requirement, I think it is a
slippery slope adding a stub for it into the core.

That having been said, I do believe a common configuration API is
necesary that other modules/plugins can depend on.

Cheers,

Cees

-
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] Transferring control to another application

[Brian Soebekti]

I came across the same requirements under similar circumstances. What
I ended up doing was creating a new accessor/mutator method that kept
a data structure of all run modes that required authentication, I
named this login_run_modes.

I then overrode the cgiapp_prerun method to check if
$self-get_current_runmode() existed within my structure of run modes
requiring authentication. If it did then it changed run modes to the
login run mode using the prerun_mode() method.

Why did I do it this way? First off, I wanted to be able to centrally
manage all the run modes that required auth from one location. I
didn't want to put checks at arbitrary places to ensure this.
Secondly, with the structure of C::A it makes sense to make checks in
cgiapp_prerun as this is the only place where you can call
prerun_mode() from (at least that's what the POD says).

Without boring you to death, the code roughly looks like:

sub setup
{

$self-login_run_modes('some', 'list', 'of', 'run', 'modes');

}

sub login_run_modes
{
# store run modes in structure and return structure if no params given
}

sub cgiapp_prerun
{
if (exists $self-login_run_modes(){$self-get_current_runmode()})
{
$self-prerun_mode($someLoginRunMode);
}
}



On 12/19/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Influenced by a long thread that I started over the weekend about the
 number of run modes allowed in an application, I've been breaking my one
 large app into several. I have a question about turning control back to
 another module.



-
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] Re: RFC: Standard config interface for CGI::Application

[Mark Stosberg]

On 2005-12-20, Cees Hek [EMAIL PROTECTED] wrote:
 On 12/20/05, Mark Stosberg [EMAIL PROTECTED] wrote:
 On 2005-12-20, Michael Peters [EMAIL PROTECTED] wrote:
 
  I'm actually leaning toward Graham's idea here that it just be in the 
  plugins. I
  like the API but I'm not sure it's something that should be in the core. I 
  know
  configuration is something pretty basic that every framework should have, 
  but I
  don't see C::A as a framework... more as a framework for building 
  frameworks.

 In my v2 RFC I proposed a very minimum of code in the core:

  sub config { return undef }

 And that's just a convenience for plugin authors so they don't have to
 check if the 'config' method exists, they can directly check

  $self-config('key_i_want');

 I want to create a standard logging API that plugins and users can use
 as well (with plugins that support Log::Dispatch, Log::Log4perl and
 simple print to STDERR plugins).  Should we add stubs for those
 methods into the core as well?

This is consistent with the CGI::App's history and current design, which
consists of mostly empty space-- it mostly suggests a way to build your 
applications. Truly the frame in framework. 

Since the 1.0 release over five years ago, web development has grown up.
Projects have gotten bigger and more complex as a norm. There are more 
modules and layers involved and more abstraction. With this complexity
comes a greater need for standardization and cooperation of /all/
aspects to maintain sanity. 

 Although 'config' is a pretty common requirement, I think it is a
 slippery slope adding a stub for it into the core.

I don't think so. We are experts building the future of CGI::Application
based on hind sight. It's not that we think we might need a standard
config() next year, we can how we could have used it last year.

To answer your question about logging-- Yes I think we should define a
mininum common logging API and possibly add a stub for it as well.
Since you are more involved in that aspect, I would welcome a proposal
for that aspect.

For other suggested additions I think we should continue to bring them
to the group for the discussion and be critical about what's essential
and how to best design it.

Here's the use case for a decent logging API:

Successful websites continue to be refined after they are in production.
To drive that refinement cycle it's critical to have good feedback about
what's workingand  what isn't.

A well designed logging system can help you as a developer identify and
respond to key problems as they arise. It's so much nicer to find out 
about bugs before a customer or end user reports them! 

This is not only possible but easy with a logging system that allows to 
flag some errors as critical and others as warning. 

A tool like 'swatch' can complete the loop by monitoring your log files 
and e-mail the dev team when critical errors come up.

 http://www.spitzner.net/swatch.html

The role of CGI::App should to make it easy to include this 'best
practice' in your workflow. We can do that providing a standard,
minimal logging API, and let plugins do the heavy lifting. 

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]

[cgiapp] Re: Transferring control to another application

[Mark Stosberg]

On 2005-12-20, Ricardo SIGNES [EMAIL PROTECTED] wrote:

 We do this a lot, with a method that, simplified to remove other weird thin=
 gs
 we do, looks like this:

   sub redispatch {
 my ($self, $newclass) =3D @_;
 eval require $newclass;
 die $@ if $@;

 # by default, at the end of the runmode, the value is sent
 # as the response.  we want to return the value instead.
 local $ENV{CGI_APP_RETURN_ONLY} =3D 1;

 $self-register_wrapper; # set up TT2 wrapping, a la Mason autohandler

 return $newclass-new(
   PARAMS =3D { map { $_ =3D $self-param($_) } $self-param },
   QUERY  =3D $self-query,
 )-run;
   }

 This works very nicely.

Interesting. This looks sort of like the sub_request that Catalyst has:

 http://search.cpan.org/perldoc?Catalyst::Plugin::SubRequest

Why not use an external redirect, giving the resulting page a bookmarkable URL? 

(It realize it takes a little more time and resources for an external
redirect because it's a roundtrip to the browser and back.)

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] Re: RFC: Standard config interface for CGI::Application

[Ron Savage]

On Tue, 20 Dec 2005 13:42:01 -0500, Cees Hek wrote:

Hi Cees

 Although 'config' is a pretty common requirement, I think it is a
 slippery slope adding a stub for it into the core.

Let's make it a short slope!

I propose adding 2:

o log_config
o session_config

How many web apps do without both of these?

All others, repeat all others, are optional.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 21/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=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] Re: Transferring control to another application

[Brad Cathey]

Mark,

 On 2005-12-20, Ricardo SIGNES [EMAIL PROTECTED] wrote:
 
 We do this a lot, with a method that, simplified to remove other weird thin=
 gs
 we do, looks like this:
 
   sub redispatch {
 my ($self, $newclass) =3D @_;
 eval require $newclass;
 die $@ if $@;
 
 # by default, at the end of the runmode, the value is sent
 # as the response.  we want to return the value instead.
 local $ENV{CGI_APP_RETURN_ONLY} =3D 1;
 
 $self-register_wrapper; # set up TT2 wrapping, a la Mason autohandler
 
 return $newclass-new(
   PARAMS =3D { map { $_ =3D $self-param($_) } $self-param },
   QUERY  =3D $self-query,
 )-run;
   }
 
 This works very nicely.
 
 Interesting. This looks sort of like the sub_request that Catalyst has:
 
  http://search.cpan.org/perldoc?Catalyst::Plugin::SubRequest
 
 Why not use an external redirect, giving the resulting page a bookmarkable
 URL? 
 
 (It realize it takes a little more time and resources for an external
 redirect because it's a roundtrip to the browser and back.)
 
Do you mean something like:

sub cgiapp_prerun
{
   my $self = shift;
   if ($self-session-param('logged_in'))
   {
  #do stuff
   }
   else
   {
  $self-header_type('redirect');
  $self-header_props(-url=index.cgi?rm=sl);
}   #index.cgi is the instance script for the log-in
}

?

Brad


 
 
 -
 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] Re: Transferring control to another application

[Cees Hek]

On 12/20/05, Brad Cathey [EMAIL PROTECTED] wrote:
 Do you mean something like:

 sub cgiapp_prerun
 {
my $self = shift;
if ($self-session-param('logged_in'))
{
   #do stuff
}
else
{
   $self-header_type('redirect');
   $self-header_props(-url=index.cgi?rm=sl);
 }   #index.cgi is the instance script for the log-in
 }

or simplify that with the CAP::Redirect plugin:

use CGI::Application::Plugin::Redirect;

sub cgiapp_prerun {
   my $self = shift;
   if ($self-session-param('logged_in')) {
  #do stuff
   }
   else{
  return $self-redirect(index.cgi?rm=sl);
   }
}

This does practically the same thing, except it also short circuits
the runmode (in your example, the runmode is still executed).

Cheers,

Cees

-
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] Re: RFC: Standard config interface for CGI::Application

[Mark Stosberg]

On 2005-12-20, Ron Savage [EMAIL PROTECTED] wrote:
 Let's make it a short slope!

 I propose adding 2:

 o log_config
 o session_config

 How many web apps do without both of these?

 All others, repeat all others, are optional.

It seems like you might be confusing standard config names with standard
APIs. It seems like you are thinking of

 # logging configs inside!
 $self-config('log_config');

At the moment, I'm not interesting doing anything with sessions in the
core, because there seems to be a lot less need for for a standard API
there. How many  other plugins want to use a session object? Maybe just
the Auth plugins that I can think of. 

As far I'm concerned, ::Plugin::Session and CGI::Session can be the
defacto API to follow, and session plugins can follow suit. 

Logging on the other hand is a lot like warn and die-- nearly every
plugin could make use of them.

But I should I stop now. I'm tired and grumpy.

Mark

-- 
http://mark.stosberg.com/ 


-
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] Re: Transferring control to another application

[Ricardo SIGNES]

* Mark Stosberg [EMAIL PROTECTED] [2005-12-20T17:20:18]
 
  This works very nicely.
 
 Interesting. This looks sort of like the sub_request that Catalyst has:
 
  http://search.cpan.org/perldoc?Catalyst::Plugin::SubRequest
 
 Why not use an external redirect, giving the resulting page a bookmarkable
 URL? 

Well, it takes a little more time and resources for an external redirect, for
one thing.
 
 (It realize it takes a little more time and resources for an external
 redirect because it's a roundtrip to the browser and back.)

Ah, well then:

Also, this goes back to the iterative dispatch that I talked about a while ago.

  http://example.com/webservice/object/o_id/subobject/so_id/action

All service goes through Webservice::Root.  An autorunmode for object
consumes the next part of the path, picks up the object in quesiton, and
redispatches to Webservice::Object, which does the same for the related
subobject.  Webservice::Object::Subobject has a runmode action which actually
does something with the found subobject, using its own logic and any available
form data.

-- 
rjbs


pgpIMcQkVQERk.pgp
Description: PGP signature