Menu
▾
▴
openinteract-dev
|
From: Chris W. <ch...@cw...> - 2005-06-28 15:13:20
|
On Jun 2, 2005, at 5:49 PM, Antti M V=E4h=E4kotam=E4ki wrote:
...
> A quick look in the Action class seems to indicate that relatively =20
> few places in the action depend on CTX->request but they are vital =20
> parts like additional assigning, language handle (and thus $action-=20
> >_msg), message passing from request, checking cache (because of an =20=
> admin check and cache params in request) and fetching parameters =20
> from request.
Actually in most of these places (except the cache) and an explicit =20
call (like param_from_request()) we do a CTX->request and only if it =20
returns something use it. So in execute() we have:
my $request =3D CTX->request;
if ( $request ) {
... do stuff with $request....
So if you're creating actions in by themselves without a request =20
available it should just do the right thing. Are you not seeing this?
> ....
> Also after this, could it be possible to find out the task and =20
> additional parameters before execute?
> Now they are all being gathered in execute and it is thus pretty =20
> hard to do any security checks, or anything else, before the =20
> determined task is executed. So when you create an Action, it is =20
> pretty much a black box and you can just fire execute off and see =20
> what happens, since you can't know which task it chooses to execute =20=
> and thus which additional parameters it will have set..
This is a good idea, although we'll have to add a couple more =20
properties so that we don't recheck the task validity and reassign =20
params. (Not a big deal.). Did you create a JIRA task for this?
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: <an...@io...> - 2005-06-29 08:27:07
|
Chris Winters wrote: > So if you're creating actions in by themselves without a request > available it should just do the right thing. Are you not seeing this? Yes this was one of the things i noticed when I really started working on what I was doing. Even in the actionresolver worked without a request, which was nice :) Anyway I had to do some tweaks of my own to get things working, since I had to make the same action to work while using a normal request, while being called from an another request with the user privileges and also while being called without a given request or a user at all, skipping all securities. The problem was that I needed values that were normally acquired using CTX but couldn't use CTX, since it had the state my initial action used and I needed a different state to run my action correctly. In the end I just added some extra accessors to my base Action class and set all the needed values there already in the actionresolver so it didn't have to call CTX (for other than lookups) at all when executed. Ideally (for my use) actionresolver would, in addition to what it does now, determine the _actual_ task, store additional url parameters to the action instead of the request and assign these parameters to accessors based on url_additional config. It could possibly even copy the request parameters to the action if request exists (I didn't need this myself this time). I personally store also the current language to the action and use that language for _msg calls, but I'm not sure if this is a common need. Maybe a good approach, at least for request params, would be to allow assigning this data to action's accessors and if they are not set, then try to fetch them from the request? Anyway all this data should be accessible from actions methods. I'm really not sure how vital this separation would be in the common use, but it might also make the structure easier to understand if actions were more self contained.. maybe ;) By the way, assigning url_additional automatically according to configuration is a brilliant idea in many ways :) I just started to think of it more and concluded that if the task could be determined before execute then we could assign url_additional before execute, we possibly wouldn't need the additional url parameters in action anymore, thus separating us from the request.. nice :) >> Also after this, could it be possible to find out the task and >> additional parameters before execute? > > This is a good idea, although we'll have to add a couple more > properties so that we don't recheck the task validity and reassign > params. (Not a big deal.). Did you create a JIRA task for this? Well I was not, and still am not sure of the actual things that should be done ;) So I prefer discussing them instead of creating misinformed and stupid JIRA issues ;) - Antti |
|
From: <an...@io...> - 2005-07-02 21:49:26
|
Antti M Vähäkotamäki wrote:
> By the way, assigning url_additional automatically according to
> configuration is a brilliant idea in many ways :) I just started to
> think of it more and concluded that if the task could be determined
> before execute then we could assign url_additional before execute, we
> possibly wouldn't need the additional url parameters in action anymore,
> thus separating us from the request.. nice :)
Thought about this some more. I think it is a good idea to reserve an
accessor (or a parameter) in the action for the array of all additional
parts since it defines the action much like action's name or it's
task. You never know when it is needed ;)
Also it would be nice to add the rest of the additional parts, which
were not mapped to a param, to a separate param.
So if your url would be:
/filearea/download/users/madonna/music/garbage.mp3
and your action.ini would have:
[filearea url_additional]
download = area_type
download = area_id
The you would end with an action such that:
$action->additional -> [ 'users', 'madonna', 'music', 'garbage.mp3' ]
$action->param('area_type') -> 'users'
$action->param('area_id') -> 'madonna'
$action->param('other_additional') -> [ 'music', 'garbage.mp3' ]
What do you think?
Also in Dicole we have a $action->derive_url -function which tries to
take the current action's url and modify it a bit:
$action->derive_url( task => 'view') =>
/filearea/view/users/madonna/music/garbage.mp3
You might want concider something similiar for OI2 - it has been quite
handy for our use since we also usually have an additional id in the url
specifying target user or group and it hardly ever changes. We haven't
yet modified it to use url_additional settings so that it would be
possible to override also those in a similiar fashion, but I think it
will be done at some point like this:
$action->derive_url( area_id => 'bjork', other_additional => [
'robots.txt'] ) -> /filearea/download/users/bjork/robots.txt
- Antti
|
|
From: Chris W. <ch...@cw...> - 2005-07-04 14:47:33
|
On Jul 2, 2005, at 5:49 PM, Antti M V=E4h=E4kotam=E4ki wrote:
> Thought about this some more. I think it is a good idea to reserve =20
> an accessor (or a parameter) in the action for the array of all =20
> additional parts since it defines the action much like action's =20
> name or it's task. You never know when it is needed ;)
That's probably a good idea. I moved the code to assign these from =20
the request into a separate subroutine as well, so you can do:
# assign the additional parameters from the Request object
$action->url_additional_param_from_request;
my @values =3D url_additional_param;
BTW, is there a better name for these things? Calling everything =20
'url_additional' is very klunky and not terribly descriptive.
> Also it would be nice to add the rest of the additional parts, =20
> which were not mapped to a param, to a separate param.
>
> So if your url would be:
> /filearea/download/users/madonna/music/garbage.mp3
>
> and your action.ini would have:
> [filearea url_additional]
> download =3D area_type
> download =3D area_id
>
> The you would end with an action such that:
> $action->additional -> [ 'users', 'madonna', 'music', 'garbage.mp3' ]
> $action->param('area_type') -> 'users'
> $action->param('area_id') -> 'madonna'
> $action->param('other_additional') -> [ 'music', 'garbage.mp3' ]
>
> What do you think?
It's not a bad idea. (That Action class just keeps growing... :-)
> Also in Dicole we have a $action->derive_url -function which tries =20
> to take the current action's url and modify it a bit:
> $action->derive_url( task =3D> 'view') =3D> /filearea/view/users/=20
> madonna/music/garbage.mp3
>
> You might want concider something similiar for OI2 - it has been =20
> quite handy for our use since we also usually have an additional id =20=
> in the url specifying target user or group and it hardly ever =20
> changes. We haven't yet modified it to use url_additional settings =20
> so that it would be possible to override also those in a similiar =20
> fashion, but I think it will be done at some point like this:
> $action->derive_url( area_id =3D> 'bjork', other_additional =3D> =20
> [ 'robots.txt'] ) -> /filearea/download/users/bjork/robots.txt
I think a lot of the functionality in OpenInteract2::URL does this. =20
For instance, to replicate the above you'd do:
$action->create_url({ TASK =3D> 'view', URL_PARAMS =3D> [ 'users', =20=
'madonna', ... ] );
Creating a shortcut to fill the URL_PARAMS with default values, or to =20=
be smarter to associate some additional parameters with named values =20
(like your 'area_id' above) seems application-specific, and may be =20
more appropriate a base Action class in your app.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: <an...@io...> - 2005-07-05 22:59:53
|
A new try - last versio of this mail disappeared :(
Chris Winters wrote:
> That's probably a good idea. I moved the code to assign these from the
> request into a separate subroutine as well, so you can do:
>
> # assign the additional parameters from the Request object
> $action->url_additional_param_from_request;
> my @values = url_additional_param;
What if all of the assigning would be done already in the actionresolver?
This way you wouldn't need to store tha url params in request at all.
You would pass _only_ the relative url to an actionresolver and the
actionresolver would return you an action which has task, language,
params from additional and params from request.
Language and request params could be fetched using action's interface so
that if they are not set for the action, they will be fetched from
CTX->request, but if they are set, the set values would be used instead.
I think this would not only add new possibilities by making the action
truly independent fron the request, but it would also simplify the
execution process.
> It's not a bad idea. (That Action class just keeps growing... :-)
Well if you can move task validation and additional parameter populating
from execute to actionresolver, it wouldn't be a huge addition for the
Action to add the possibility to make action run independently from the
request but still using similiar ways to control actions behaviour.
This would make it possible to do a gateways that would make it possible
to call normal requests but get the results in a filtered form
(returning pages in ajax-readable form for example).
Also this would make it possible to build a public gateway so that if
requests are called through this gateway, they would send correct HTTP
headers so that for example squid could timecache them, but the requests
could be called by others normally getting the latest data.
Like this:
/public/request/myaction/mytask/myadditional/
sub request {
my ( $self ) = @_;
my $sub_action = MyActionResolver->resolve(
join '/', $self->param('other_additional')
);
# maybe set some extra params
# maybe override language or request params
# issue correct cache headers
return $sub_action->execute;
}
> Creating a shortcut to fill the URL_PARAMS with default values, or to
> be smarter to associate some additional parameters with named values
> (like your 'area_id' above) seems application-specific, and may be more
> appropriate a base Action class in your app.
Well generally you are correct - if you don't know how the urls are
parsed (since any of the actionresolvers might get it), you don't know
how they are generated either. This is probably only for us then.
- Antti
|
|
From: Chris W. <ch...@cw...> - 2005-06-28 15:03:40
|
On May 26, 2005, at 9:51 AM, Antti V=E4h=E4kotam=E4ki wrote: > Oh. I just noticed that there was a url_none which can be used to =20 > prevent action from being executed directly by a request. No need =20 > for a none-controller then :) Yeah. > But I'm still not sure about the error on lookup failure.. It's tricky: throwing an exception when you cannot find an action =20 makes for nice execution flow -- you can just catch the exception at =20 a higher level, and if you're writing code where you're actively =20 looking for an action it's pretty easy to just catch the exception. However, I agree that looking up an action might not be the best =20 place for an exception (conceptually speaking). We'd have to do quite =20= a bit of retrofitting to make this happen... I dunno, has this =20 bothered anyone else? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: <an...@io...> - 2005-06-28 20:16:56
|
Nice to hear from you Chris! :) I didn't realise I had send that many mails - huh.. I feel like I'm flooded with the replies even though the mails I personally wrote were even longer, so I can't imagine how you managed to handle those in such a short time :) Well given the amount of sole crap I wrote too hastily (which I since discovered while acually doing stuff and not just rolling around in thoughts and browsing code), the fact that you know OI2 "a bit better" and are a native english speaker might have something to do with that - but still I do give you a huge credit for what you managed to do :) But now for the actual stuff - I'll keep the emails separate since they handle different areas (and I don't probably have the time to answer them all just now). >> But I'm still not sure about the error on lookup failure.. > > It's tricky: throwing an exception when you cannot find an action > makes for nice execution flow -- you can just catch the exception at > a higher level, and if you're writing code where you're actively > looking for an action it's pretty easy to just catch the exception. Yes that is true, but the problem is that the error gets logged anyway since the exception is always thrown after: $log_act->error( $msg ); > However, I agree that looking up an action might not be the best > place for an exception (conceptually speaking). We'd have to do quite > a bit of retrofitting to make this happen... I dunno, has this > bothered anyone else? Well in my opinnion it's a difference in how you see the purpose of the function. If you see it just as a means to change a known name to the corresponding action object, then throwing an exception is a good idea when this turns out not to be possible. On the other hand if you see it as a function to look up and return the action that is registered for the given name, then it would be reasonable to just quietly return nothing if there was no actual failure but the name jst wasn't registered to any acions. I personally don't think that you should actually change the logic and get rid of exceptions since they are a really handy way of doing things. I just don't want a mandatory error in my logs when it happens :) Anyway for me "lookup_action" somewhat sounds like it would be the latter one. I might be wrong here since I'm not a native speaker. - Antti |
|
From: Sam V. <sa...@vi...> - 2005-07-07 04:43:19
|
Perrin Harkins wrote: >>I'm using debian's apache-perl. > Not a good idea. I recommend you build your own. The apache builds > that come with Linux distros are notorious for causing problems. Of course, much better if you're using FastCGI mode is to scrap Apache entirely, and just use a nice little web server like lighttpd. In any case, a statement like that is pretty much handwaving. Doing a custom build will merely give you a different set of problems to deal with. I wouldn't knock the binary packages so much just on principle. Sam. |
|
From: Perrin H. <pe...@el...> - 2005-07-07 16:32:31
|
On Thu, 2005-07-07 at 16:43 +1200, Sam Vilain wrote: > In any case, a statement like that is pretty much handwaving. Doing a > custom build will merely give you a different set of problems to deal > with. I wouldn't knock the binary packages so much just on principle. It's handwaving from experience. The Bricolage project tried pretty hard to make the Red Hat binaries of mod_perl work, and finally had to give up because users kept on having mysterious problems that couldn't be reproduced by developers. We get the same thing on the mod_perl list -- strange problem, gone when the user switches to their own build. The issues probably stem from the fact that packagers for distributions have to try to make a server that works for running every conceivable project all at once. They build in a lot more, or use DSO, or both. It's not so different from the situation with the perl packages most distros provide. The one from Red Hat has threading and debugging compiled in, which makes it about 15% slower than a perl built on the same OS with all the defaults. - Perrin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X