An idea, for comments
Hi all
Fist of all, sorry for my bad english...
We "think/found" a technic to manage user action through a web
interface. And I like to know your opinion about it.
The goal is to trigger actions through the server without using cgi ( or
mod_perl ) fake pages.
The actions are managed by a Content Handler on a location:
Location /action
An example is better than long ( bad writen text ) so:
/action/Client/Add
Is parsed to obtains an object type ( "Client" ) and an action to
perform ( "Add" )
$object = "Client"
$method = "Add"
and posted data are read in $fdat ( hash table ref )
Then a perl package is found regarding the object type.
$package = MyNameSpace::Client;
An the action is called on that package.
The problem we have was that we wanted the handler to be able to call
any function available on any authorised package, whithout using a
dispatcher
with a long
if() {
}elsif(){
}elsif(){
}else{
}
To sumup, here want we are doing:
1: parsing URI, to obtain a package and a method
2: look if action is allowed on that package, by this user ( with a
session management ).
3: build a string $str = 'MyNameSpace::Client-Add( $session, $fdat
)', $fdat are the data posted throught the handler
4: calling $return = eval $str.
5: find a redirection page for that ( package, action, result )
That all, it's work fine and it's allowing to call package/object methods whithout
having fake pages to maintains.
Comments are very, very welcomes
--
Don't be irreplaceable, if you can't be replaced, you can't be promoted.
Re: An idea, for comments
Hi there, On Fri, 27 Oct 2000, Nouguier wrote: posted data are read in $fdat ( hash table ref ) [snip] 3: build a string $str = 'MyNameSpace::Client-Add( $session, $fdat)', 4: calling $return = eval $str. I hope you are careful with the contents of $fdat! 73, Ged.
Re: An idea, for comments
You want Apache::Dispatch. It's almost exactly what you are looking for
(and it really rocks, IMHO).
On Fri, 27 Oct 2000, Nouguier wrote:
Hi all
Fist of all, sorry for my bad english...
We "think/found" a technic to manage user action through a web
interface. And I like to know your opinion about it.
The goal is to trigger actions through the server without using cgi ( or
mod_perl ) fake pages.
The actions are managed by a Content Handler on a location:
Location /action
An example is better than long ( bad writen text ) so:
/action/Client/Add
Is parsed to obtains an object type ( "Client" ) and an action to
perform ( "Add" )
$object = "Client"
$method = "Add"
and posted data are read in $fdat ( hash table ref )
Then a perl package is found regarding the object type.
$package = MyNameSpace::Client;
An the action is called on that package.
The problem we have was that we wanted the handler to be able to call
any function available on any authorised package, whithout using a
dispatcher
with a long
if() {
}elsif(){
}elsif(){
}else{
}
To sumup, here want we are doing:
1: parsing URI, to obtain a package and a method
2: look if action is allowed on that package, by this user ( with a
session management ).
3: build a string $str = 'MyNameSpace::Client-Add( $session, $fdat
)', $fdat are the data posted throught the handler
4: calling $return = eval $str.
5: find a redirection page for that ( package, action, result )
That all, it's work fine and it's allowing to call package/object methods whithout
having fake pages to maintains.
Comments are very, very welcomes
--
Don't be irreplaceable, if you can't be replaced, you can't be promoted.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
RE: An idea, for comments
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Friday, October 27, 2000 7:44 AM To: Nouguier Cc: perl Subject: Re: An idea, for comments You want Apache::Dispatch. It's almost exactly what you are looking for (and it really rocks, IMHO). for anyone who is interested, I'm pretty close to releasing the latest version of Dispatch. here's the Changes so far: - added support for output filtering thanks to Ken Williams for additional Apache::Filter functionality - added FILTERING section to documentation - added DispatchISA functionality to set parent classes for dispatched module - added DispatchAUTOLOAD directive to make AUTOLOAD behavior user defined - added AUTOLOAD section to documentation - more, better documentation - modified Apache::ModuleConfig-get() calls thanks to Doug MacEachern for the enlightenment - fixed bug that allowed for duplicate DispatchExtras directives - fixed dispatch_index bug - fixed one minor "my $x if 0" condition - fixed DispatchStat ISA directive to properly recurse all levels - made mod_perl 1.2401 required due to DIR_MERGE memory leak in 1.24 unfortunately, the filtering capability will not be available until Apache::Filter 1.12 is released (which is incompatable and implemented totally differently from the current Apache::Filter) DispatchISA is my favorite part of the module so far, which allows you to really take advantage of inheritance by specifying any number of (additional) classes all your dispatched classes should inherit from (like a generic Utils package or whatever). It's nothing you can't do by setting @ISA yourself, you can pretty much do everything Dispatch does yourself anyway ;) for anyone who wants a preview, you can find it at http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.07.tar.gz comments most welcome... --Geoff
RE: An idea, for comments
On Fri, 27 Oct 2000, Geoffrey Young wrote: - made mod_perl 1.2401 required due to DIR_MERGE memory leak in 1.24 Thats a pretty stern requirement at least until 1.25 is released. Perhaps you could do what I intend to do with AxKit - do a regex which renames DIR_MERGE to DISABLED_DIR_MERGE when running under 1.24 (needs to be done physically in the file when you run Makefile.PL otherwise it will crash). -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: An idea, for comments
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Friday, October 27, 2000 8:04 AM To: Geoffrey Young Cc: Nouguier; '[EMAIL PROTECTED]' Subject: RE: An idea, for comments On Fri, 27 Oct 2000, Geoffrey Young wrote: - made mod_perl 1.2401 required due to DIR_MERGE memory leak in 1.24 Thats a pretty stern requirement at least until 1.25 is released. Perhaps you could do what I intend to do with AxKit - do a regex which renames DIR_MERGE to DISABLED_DIR_MERGE when running under 1.24 (needs to be done physically in the file when you run Makefile.PL otherwise it will crash). that sounds interesting - I'd like to see what you have so far... I'm not sure I'll go that route, though - maybe if it relied on cvs... but since 1.24-01 is an official release, I don't see any harm in requiring it. Doug had said that it's pretty close to being 1.25 and there's lots more bug fixes that are important in that release as well (though DIR_MERGE is the only one that affects Dispatch I think)... besides, I'm waiting to hear from Ken on an ETA on the new Apache::Filter - if it's too far away I'll comment out the filtering stuff and release 0.07, otherwise I'll probably wait on that - I'm starting to get on a Apache::Compress kick :) --Geoff -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: An idea, for comments
This is very similar to SOAP (Simple Object Access Protocol). There is a perl
module that implements SOAP. It's also like the many perl RPC modules.
On 27-Oct-2000 Nouguier wrote:
Hi all
Fist of all, sorry for my bad english...
We "think/found" a technic to manage user action through a web
interface. And I like to know your opinion about it.
The goal is to trigger actions through the server without using cgi ( or
mod_perl ) fake pages.
The actions are managed by a Content Handler on a location:
Location /action
An example is better than long ( bad writen text ) so:
/action/Client/Add
Is parsed to obtains an object type ( "Client" ) and an action to
perform ( "Add" )
$object = "Client"
$method = "Add"
and posted data are read in $fdat ( hash table ref )
Then a perl package is found regarding the object type.
$package = MyNameSpace::Client;
An the action is called on that package.
The problem we have was that we wanted the handler to be able to call
any function available on any authorised package, whithout using a
dispatcher
with a long
if() {
}elsif(){
}elsif(){
}else{
}
To sumup, here want we are doing:
1: parsing URI, to obtain a package and a method
2: look if action is allowed on that package, by this user ( with a
session management ).
3: build a string $str = 'MyNameSpace::Client-Add( $session, $fdat
)', $fdat are the data posted throught the handler
4: calling $return = eval $str.
5: find a redirection page for that ( package, action, result )
That all, it's work fine and it's allowing to call package/object methods
whithout having fake pages to maintains.
Comments are very, very welcomes
--
Don't be irreplaceable, if you can't be replaced, you can't be promoted.
--
Jason Bodnar
[EMAIL PROTECTED]
