[cgiapp] CGI::Application status update from the maintainer
B. Estrade
estrabd at gmail.com
Thu Sep 6 10:48:00 EDT 2012
Snipped
On Thu, Sep 06, 2012 at 09:12:40AM +1000, Ron Savage wrote:
> Hi Brett
> > It would be really nice to merge in some bare bones Authentication and
> > Authorization support - maybe ever by more fully developing CAP's lifecycle.
>
> Likewise. It's a pity a standard(!) way of doing this with CAP doesn't
> seem to have evolved /with the approval of all/.
>
> > Here are some items I would like to see addressed.
> >
> > 1. scalability - it is unnecessarily awkward to have more than 2
> > levels of subclassing currently.
>
> This statement worries me. Could you please expand.
>
> Also, did you look at CGI::Snapp::Demo::Four::Wrapper, which easily
> wraps CGI::Snapp::Demo::Four. It's specifically a (simple) demo of
> sub-classing.
>
> > Direct subclass of CAP uses cgi_init; child of subclass uses setup;
> > anything else must call SUPER::setup.
>
> How does this differ from any other class which uses sub-classing? The
> parent method is either completely overridden or called /and/ partially
> overridden. Or am I missing something?
What I mean is that there are 2 methods that basically do the same
thing. If you have MyApp (ISA CGI::Application), you would initialize
runmodes and whatnot via cgiapp_init. Say you subclass MyApp to get
MyApp::Foo, but want to keep what is going on in MyApp::cgiapp_init;
but you have your own specific MyApp::Foo runmodes. You'd most cleanly
do this by defining MyApp::Foo::setup. Now, what if you want to
subclass MyApp::Foo into MyApp::Foo::Derp, but you have some Derp
specific runmodes. You end up having to redefine cgiapp_init or
setup; in either case, you're going to have to make an explicit call
to SUPER::cgiapp_init or SUPER::setup.
You're limited to 2 generations below CAP if you want to subclass
without explicitly calling on SUPER because you have 2 explicit
methods -cgiapp_init and setup. I am suggesting a way to provide any
number of generations without having to call on SUPER.
Here is my real world use case. I split my applications into 2 parts;
one amounts to the UI payload delivery, basically HTML that makes all
calls asynchronously. The other is strictly non-UI and handles only
asynchronous requests (i.e., the "REST" API). And I typically have
this hierarchy:
1. WebCommon.pm (ISA CGI::Application; implements Authentication and common run modes)
2. WebApp.pm (ISA WebCommon; base class for the UI delivery or initial "view")
3. WebAPI.pm (ISA WebCommon; base class for the "REST" API)
>From there, I may have another or even another 2 levels of WebApps or
WebAPIs. In WebCommon.pm, I define cgiapp_init; in WebApps.pm and
WebAPI.pm, I define a setup. Beyond that, I redefine setup with a call
to $self->SUPER::setup - not something I really like doing.
>
> > 3. a more fully developed plugin/event system; I think this goes along
> > with #2 (i.e., a few more hooks), but in addition to this I have
> > always thought it would be useful to have some sort of mechanism
> > through which plugins might be able to query one another. A good
> > example (and actually the main motivation for #2 and #3) are the CAP
> > Authorization and Authentication plugins. The short list of troubles
> > I have had with using these two are:
> >
> > * when used together, Authorization is called before Authentication,
> > making it awkward to handle authorization errors of unauthenticated
> > guests (or maybe Authz assumes an authenticated session);
> >
> > * default behavior of Authz is to query directly the Authorization
> > plugin instance for a username; this works fine in that situation,
> > but there is no clear way for plugin A to make information available
> > to plugin B;
>
> There's no doubt they are awkward. I'd argue the underlying CAP
> structure is sound, and just this part need a bug re-think.
>
> > 4. more flexibility with the query object...err response object; I've
> > run into some hoops to jump through when I wanted to use CGI::Simple
> > and be able to upload capabilities on or off in a sub class.
>
> It'd help if you could expand on this issue.
I want to use CGI::Simple, but do not want to enable uploads app-wide.
I have a subclass (WebAPI::UploadApp, say) where I do want to enable
uploads.
In WebCommon.pm, I have to do this:
our $cgi; #= CGI::Simple->new;
sub cgiapp_get_query {
use CGI::Simple ();
$cgi = CGI::Simple->new();
return $cgi;
}
Then in order to override that CGI::Simple to enable uploads, in
WebAPI::UploadApp, I have to do this:
sub cgiapp_get_query {
my $self = shift;
use CGI::Simple ();
$CGI::Simple::DISABLE_UPLOADS = 0;
$self::SUPER::cgi = CGI::Simple->new();
return $self::SUPER::cgi;
}
Granted, there is probably a more correct, cleaner, or better way to do
this; if so, I am all ears.
>
> > 5. persistence - I would like to say that I'd like to learn more about CAP and
> > the ecosystem in persistent environments. It's my impression that
> > there are some corner cases or funny issues with it. I do not claim
> > this is true, but I think that we can all agree that while persistent
> > environments such as mod_perl are considered old fashioned, I think
> > that they will prove remain relevant amist the tide of alternatives and
> > "middleware" laden configurations. For me, the ultimate goal would be
> > to use CAP to create a responsive and consistent daemon type
> > application as served by Apache, defined strictly through things like runmodes,
> > plugins, etc. Is PSGI the path to this? Maybe, maybe not.
>
> I only use plack (dev) and starman (prod), but I used to use
> Apache(2)::Registry, with CAP. Is that what you're referring to.
Yes.
>
> Is there something specific which needs to be added?
>
I don't know :)...I plan on investigating persistent environments more
in the near future.
> > 6*. the last mile - in application frameworks, I am unsure of any that
> > take the finite state machine model to its logical max. This thought
> > may be way out there, but defining things like runmodes only takes you
> > so far. Going a step further, perhaps done through more feature dispatching
> > or routing, it'd be really nice to be able to define the application
> > runmodes in terms of a transition function (e.g., current runmode,
> > input, resulting runmode). In otherwords, support defining an
> > application to the fullest extent possible though some sort of runmode
> > dispatch table annotations.
>
> Perhaps you need Mojo after all :-)).
Maybe so.
>
>
> > *(forgive me this one is "out there", and I still have not sat down to
> > figure out what such a capability would look like or value it would
> > actually add)
>
> On the contrary - many thanx.
>
> We need all ideas to be put out there.......
Thanks :)
Brett
>
> --
> Ron Savage
> http://savage.net.au/
> Ph: 0421 920 622
>
> ##### CGI::Application community mailing list ################
> ## ##
> ## To unsubscribe, or change your message delivery options, ##
> ## visit: http://lists.openlib.org/mailman/listinfo/cgiapp ##
> ## ##
> ## Web archive: http://lists.openlib.org/pipermail/cgiapp/ ##
> ## Wiki: http://cgiapp.erlbaum.net/ ##
> ## ##
> ################################################################
>
--
Register Now for cPanel Conference
Oct 8-10, 2012, Houston, Texas
http://conference.cpanel.net/
More information about the cgiapp
mailing list