durusmail: quixote-users: Re: Request contexts
Request contexts
2003-12-11
Re: Request contexts
2003-12-11
2003-12-11
2003-12-12
2003-12-12
2003-12-13
2003-12-13
2003-12-16
2003-12-16
2003-12-16
2003-12-16
2003-12-15
Re: Request contexts
2003-12-16
2003-12-16
2003-12-24
2003-12-30
2003-12-31
Re: Request contexts
Graham Fawcett
2003-12-16
Oscar Rambla wrote:
> On Thursday 11 December 2003 11:06, Graham Fawcett wrote:
>
>>My suggestion is to allow a "context object" to be added to the
>>Publisher in the handler script, while it's being configured. This
>>object would then be available to each request via the request.context
>>attribute.
>
>
>
> In my case, user, from its session menu, has acces to several
> applications/packages/apis.
>

A nice thing about your approach is that you could modify the context based on
the user's credentials. This could be useful if access-control checks are
required/desired on the back-end: you could only access those things which your
session permitted you to. It reminds me of Lotus Notes/Domino, where all
back-end classes are access through the user session for this reason.

Personally, I like the idea of passing the applications/packages/api's to the
Publisher. A drawback of your approach is that it requires a SessionPublisher
in order to work, and thus it is a bit less general.

> Then, the initial publisher context should be updated with info. from
> application with posteriority.
>
> I'm not sure, if my case fits in your proposal or this is a bad practice and i
> should downsize my pattern from [1publisher , +applications] to [1publisher ,
> 1application].

There are similarities between the proposals, and I do not see your approach as
a bad practice.

If you were to switch to my proposed method, you wouldn't need to downsize:
there's no reason why your "context object" couldn't refer to a wide range of
back-end applications. It could be as simple or as complex as you required.

>
> Suggestions are welcome.

Me too!

-- G

>
> Oscar Rambla
> CODI




reply