Custom request handling howto?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Michael Rueger-6
Hi all,

after tinkering with Aida a bit I'm trying to setup a handler for a REST
callback. I thought registering a Resource would do the trick, but it
seems AIDA still goes through the motions of finding an App object for
the Resource object.
Am I overlooking something or is there currently no way to bypass this
hardwired dispatching to object/app pairs?
I could imagine that double dispatching the lookup could solve this
problem, so registered objects/resources could bring their own custom
request handling with them. Or introducing handler objects that define
how the lookup and the request handling is done. So we could have
handler objects for object/app pairs (maybe with additional scope), raw
request handlers, etc...

Suggestions? Ideas? Pointers?

Thanks

Michael

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Janko Mivšek
Hi Michael,

Michael Rueger wrote:

> after tinkering with Aida a bit I'm trying to setup a handler for a REST
> callback. I thought registering a Resource would do the trick, but it
> seems AIDA still goes through the motions of finding an App object for
> the Resource object.

Yes, because URL resolution is handled entirely by Aida's Url resolver
after request came to AIDASite. Method override AIDASite>>helpResolve:
is where Swazoo's Url resolution is stopped and handled by Aida instead.

> Am I overlooking something or is there currently no way to bypass this
> hardwired dispatching to object/app pairs?

I would start expanding AIDASite>>helpResolve: to try to resolve
sub-resources first and if can't be resolved there, then go to Aida for
final resolution. This would be easy to achieve, IMO.

So for instance if you'd like to use FileMappingResource for serving
static files instead of Aida, you'd add this resource to AIDASite and
set uriPatern (with 'files' for instance) to serve static files from
/files. Something like that.

> I could imagine that double dispatching the lookup could solve this
> problem, so registered objects/resources could bring their own custom
> request handling with them. Or introducing handler objects that define
> how the lookup and the request handling is done. So we could have
> handler objects for object/app pairs (maybe with additional scope), raw
> request handlers, etc...

> Suggestions? Ideas? Pointers?

I think the Url resolution can be extended in two ways:

- to extend Swazoo way of resolution also to the sub-resources of
   AIDASite, as it is shown above,
- to extend Aida way of resolution. URLResolver resolve urls in three
   levels already and this can be extended:
   1. if Url is registered for some object, request is passed to
      that object. This is normally a domain object which passes
      it to its App (see Object>>printWebPageFor: session)
   2. if not 1 then a static file is tried to be found
   3. if not 2 then a so called method resource is searched for

Look URLResolver>>ooRefFromURL: for above resolution. In any case the
Url will be resolved to a pointer to some object, being domain object,
FileProxy or MethodResource, and request will be passed to it. This
object will also be registered in main URLResolver table at that time,
so that next time the resolution will be direct and fast.

To conclude, you can extend resolution in Aida way, which always resolve
  to some object or in Swazoo way, which resolve to some Resource.

I hope I hit your question more or less with that answer...

Best regards
Janko


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Michael Rueger-6
Janko Miv?ek wrote:

> I hope I hit your question more or less with that answer...

Yes you did.
I came up with a simple double dispatch, that allows objects to
intercept answering the request, see attachment.
You still need to register the resource or other object with the
URLResolver, but I see that as a good thing performance-wise anyways.

Cheers

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: answerDispatch.cs.gz
Type: application/x-gzip
Size: 621 bytes
Desc: not available
Url : http://lists.aidaweb.si/pipermail/aida/attachments/20071120/a577c816/attachment.gz 

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Janko Mivšek
Hi Michael,

Michael Rueger wrote:

> I came up with a simple double dispatch, that allows objects to
> intercept answering the request, see attachment.
> You still need to register the resource or other object with the
> URLResolver, but I see that as a good thing performance-wise anyways.


Let me try to understand you proposal by thinking about it a bit. Here
is a proposed additional method on Object, which is then overriden if
necessary in any other class:

Object answerTo: aRequest on: aSession for: site
        site answer: self to: aRequest on: aSession

and AIDASite then serve above call as it does now already:

AIDASite answerTo: aRequest
    | session object errorResponse |
   "["self log: self cr , (self logStringFor: aRequest) , self cr , ' s'.
        self shouldRedirect ifTrue:
                [^self redirectToOtherHost: aRequest].
        session := self sessionManager findOrMakeSessionFor: aRequest.
   ...


So, question is, who is calling first method? Where the caller finds
session and site?

This seems also a generalization of current Object>>printWebPageFor:
method, which looks a good approach.

Can you provide a simple example of your double dispatch use?

Best regards
Janko



--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Michael Rueger-6
Janko Miv?ek wrote:

> Object answerTo: aRequest on: aSession for: site
> site answer: self to: aRequest on: aSession
>
> and AIDASite then serve above call as it does now already:
>
> AIDASite answerTo: aRequest
>     | session object errorResponse |
>    "["self log: self cr , (self logStringFor: aRequest) , self cr , ' s'.
> self shouldRedirect ifTrue:
> [^self redirectToOtherHost: aRequest].
> session := self sessionManager findOrMakeSessionFor: aRequest.
>    ...
>
>
> So, question is, who is calling first method? Where the caller finds
> session and site?

The magic is a little further down in the answerTo: method (which is the
first one being called), where the answerTo:on:for: method is called on
the object.

...
        object := self objectTo: aRequest forSession: session.
        object isNil ifTrue: [^HTTPResponse notFound].

        ^object answerTo: aRequest on: session for: self

> This seems also a generalization of current Object>>printWebPageFor:
> method, which looks a good approach.

I first thought about simply overriding that method on my resource
subclass, but then some crucial information like the current request is
missing in that call. (assuming that the last request in the session
object might not be the one you are currently processing)

> Can you provide a simple example of your double dispatch use?

I'm overriding the answerTo:on:for: method in my resource subclass to do
the rest request processing. No real code to show yet though, just a
self halt ;-)

Michael

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Janko Mivšek
Michael, just before sleep I'm answering just a simplest question :)

Michael Rueger wrote:

>> This seems also a generalization of current Object>>printWebPageFor:
>> method, which looks a good approach.
>
> I first thought about simply overriding that method on my resource
> subclass, but then some crucial information like the current request is
> missing in that call. (assuming that the last request in the session
> object might not be the one you are currently processing)

Last request actually is a request currently processed and not a
previous one. Well, method name should obviously be better ...Maybe is a
time to rename it? Simply to #currentRequest?

But current request becomes last request after response is sent and
before the next request came. But again, who cares about it during that
time? Well, some housekeeping methods determine a session activity from
timestamp of last request...

So, what is better among two bad choices, that's the question now!

Janko

--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Michael Rueger-6
Janko Miv?ek wrote:

> Last request actually is a request currently processed and not a
> previous one. Well, method name should obviously be better ...Maybe is a
> time to rename it? Simply to #currentRequest?

I figured that that was the intention.
But, would it be possible:
if a second request for the same session came in (e.g the user has two
browser windows open or another ajax request comes in) before the first
request is completed that this assumption would be no longer valid?

Michael


Reply | Threaded
Open this post in threaded view
|

WebSession lastRequest (was Custom request handling howto)

Janko Mivšek
Hi Michael,

Michael Rueger wrote:

>> Last request actually is a request currently processed and not a
>> previous one. Well, method name should obviously be better ...Maybe is a
>> time to rename it? Simply to #currentRequest?
>
> I figured that that was the intention.
> But, would it be possible:
> if a second request for the same session came in (e.g the user has two
> browser windows open or another ajax request comes in) before the first
> request is completed that this assumption would be no longer valid?

Yes, you are right. And this is happening also when images are loading
in parallel.

What is interesting that so far that was not a problem but it is very
valuable to know, what is happening here. Thanks to pointing that
potential problem out!

What I'll do is to better comment that method, but let the name stay the
same.

Also, this means that #printWebPageFor: aSession is not reliable enough
and that we really need to add an argument aRequest, to be sure which
request we are actually serving in case of multiple requests at once.

So, let the search for a better solution continue!


Update: I just comment #lastRequest method:

   "last request served on that session. It is also current one until
   response is sent. Note also that multiple requests can be served at
   once! In this case last request will be the one one which
   last started! "


Janko

--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Nicholas Moore
In reply to this post by Janko Mivšek
I want to make documents (.pdf, .doc or .html) in a directory available
for download. I can populate the page easily enough with the document
links, but when I try to download the link, I get a 404 not found. In
this case is it best to modify Swazoo or Aida, perhaps by modifying
ooRefFromURL: as you suggest below? If so how, by using FileProxy?

Nicholas

Janko Miv?ek wrote:

>
>
> I think the Url resolution can be extended in two ways:
>
> - to extend Swazoo way of resolution also to the sub-resources of
>    AIDASite, as it is shown above,
> - to extend Aida way of resolution. URLResolver resolve urls in three
>    levels already and this can be extended:
>    1. if Url is registered for some object, request is passed to
>       that object. This is normally a domain object which passes
>       it to its App (see Object>>printWebPageFor: session)
>    2. if not 1 then a static file is tried to be found
>    3. if not 2 then a so called method resource is searched for
>
> Look URLResolver>>ooRefFromURL: for above resolution. In any case the
> Url will be resolved to a pointer to some object, being domain object,
> FileProxy or MethodResource, and request will be passed to it. This
> object will also be registered in main URLResolver table at that time,
> so that next time the resolution will be direct and fast.
>
> To conclude, you can extend resolution in Aida way, which always resolve
>   to some object or in Swazoo way, which resolve to some Resource.
>
> I hope I hit your question more or less with that answer...
>
> Best regards
> Janko
>
>
>  

--

*Nicholas J Moore*
+33 555 092 140
+33 682 904 357
*TSR International
*Thought Leaders in Communication & Complexity
www.TSR-i.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aidaweb.si/pipermail/aida/attachments/20071123/e38a4282/attachment.htm 

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Janko Mivšek
Hi Nicholas,

Nicholas Moore wrote:
> I want to make documents (.pdf, .doc or .html) in a directory available
> for download. I can populate the page easily enough with the document
> links, but when I try to download the link, I get a 404 not found. In
> this case is it best to modify Swazoo or Aida, perhaps by modifying
> ooRefFromURL: as you suggest below? If so how, by using FileProxy?

I think you can do that simply by providing a text url for a link on
your page and setup a right AIDASite>>homeDirectory.

Something like:

        e addLinkTo: '/files/document.pdf' text: 'document.pdf'.

URLResolver will then automatically search for that file in
<homeDirectory>/files and if found, make aFileProxy and register it in
URLResolver.

Best regards
JAnko


> Janko Miv?ek wrote:
>>
>>
>> I think the Url resolution can be extended in two ways:
>>
>> - to extend Swazoo way of resolution also to the sub-resources of
>>    AIDASite, as it is shown above,
>> - to extend Aida way of resolution. URLResolver resolve urls in three
>>    levels already and this can be extended:
>>    1. if Url is registered for some object, request is passed to
>>       that object. This is normally a domain object which passes
>>       it to its App (see Object>>printWebPageFor: session)
>>    2. if not 1 then a static file is tried to be found
>>    3. if not 2 then a so called method resource is searched for
>>
>> Look URLResolver>>ooRefFromURL: for above resolution. In any case the
>> Url will be resolved to a pointer to some object, being domain object,
>> FileProxy or MethodResource, and request will be passed to it. This
>> object will also be registered in main URLResolver table at that time,
>> so that next time the resolution will be direct and fast.
>>
>> To conclude, you can extend resolution in Aida way, which always resolve
>>   to some object or in Swazoo way, which resolve to some Resource.
>>
>> I hope I hit your question more or less with that answer...
>>
>> Best regards
>> Janko
>>
>>
>>  
>
> --
>
> *Nicholas J Moore*
> +33 555 092 140
> +33 682 904 357
> *TSR International
> *Thought Leaders in Communication & Complexity
> www.TSR-i.com
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Aida mailing list
> Aida na aidaweb.si
> http://lists.aidaweb.si/mailman/listinfo/aida

--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Custom request handling howto?

Nicholas Moore
Thanks JAnko, the problem was with my homeDirectory setting,
Nicholas

Janko Miv?ek wrote:

> Hi Nicholas,
>
> Nicholas Moore wrote:
>  
>> I want to make documents (.pdf, .doc or .html) in a directory available
>> for download. I can populate the page easily enough with the document
>> links, but when I try to download the link, I get a 404 not found. In
>> this case is it best to modify Swazoo or Aida, perhaps by modifying
>> ooRefFromURL: as you suggest below? If so how, by using FileProxy?
>>    
>
> I think you can do that simply by providing a text url for a link on
> your page and setup a right AIDASite>>homeDirectory.
>
> Something like:
>
> e addLinkTo: '/files/document.pdf' text: 'document.pdf'.
>
> URLResolver will then automatically search for that file in
> <homeDirectory>/files and if found, make aFileProxy and register it in
> URLResolver.
>
> Best regards
> JAnko
>
>
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aidaweb.si/pipermail/aida/attachments/20071124/2aa355d5/attachment-0001.htm