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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |