Changing ILRouter/ILDispatcher

Hi all,

I wonder if there is support to turn off redirect on POST, or in
general to set custom handlers. I try to produce some JSON responses
for some controllers but I would like to be able to control the format
(and to not emit redirects).

So I think I either want to be able to create a custom
ILRouter>>dispatchRequest to create a custom ILApplicationHandler or
in ILApplicationHandler be able to specify a ILJsonHandler subclass?

Am I missing something? I should probably draw an image on how
ILRouter, ILDispatcher and ILApplication are connected.

On Jul 29, 7:27 pm, zecke <[hidden email]> wrote:

> Am I missing something? I should probably draw an image on how
> ILRouter, ILDispatcher and ILApplication are connected.

I think it would be nice if all ILResponseHandler>>newResponse and
such would go through the ILApplication, e.g. similar to the
dispatchOverride,
this way in an application I should be able to define the response
code
for a request and could also provide the JSON.

I don't know how much magic it would be if:
   - ILApplication has access to the 'response' or at least code
   - ILApplication will always render the response (e.g. right now
     ILJsonHandler will fill the json response like it wants, or to be
     honest, only with updating widgets in mind)

what do you think?

Hi,

You can create a response and answer it from anywhere (including the
application):

- Subclass ILRequestHandler
- Create a ILResponse object
- Use your response handler to answer (using #handleRequest)

You can also respond in ILApplication using #returnResponse:, taking a
response object as argument. This will send a response notification.

> I don't know how much magic it would be if:
>    - ILApplication has access to the 'response' or at least code
There's no response yet when the application is handling the request.

>    - ILApplication will always render the response (e.g. right now
>      ILJsonHandler will fill the json response like it wants, or to be
>      honest, only with updating widgets in mind)
yes, but as you can use your own request handlers, or answer at any time
with your custom responses, does it really matter?


Cheers,
Nico

--
Nicolas Petton
http://www.nicolas-petton.fr

On Jul 31, 12:50 pm, Nicolas Petton <[hidden email]> wrote:
and the code will stop processing? My biggest problem right now is
that
when I do a HTTP POST with JSON Content the ILApplicationHandler
will decide to do a redirect (and losing the posted data) before I can
do anything in my ILApplication?


> yes, but as you can use your own request handlers, or answer at any time
> with your custom responses, does it really matter?

it does not, my main problem is that there are some decisions in
ILApplicationHandler that I want to do differently in this case.


So my two issues are:
    - Don't redirect on post without consulting the application
    - Generate a JSON response my way (your mail showed me a way
      to do this here, I still need to figure out how to use ILRouter/
ILRoute
      to dispatch to the right handler)

Le lundi 01 août 2011 à 02:14 -0700, zecke a écrit : Yes it will. As soon as a response notification is sent, the processing
stops there.

I think using custom handlers will solve your issues. Don't hesitate to
post here if you have trouble implementing them.

>       to do this here, I still need to figure out how to use ILRouter/
> ILRoute
>       to dispatch to the right handler)

You can access the current route from any Iliad object from the current
context (self context).

then you can read the class comment of ILRoute, I think it should be
helpful.

Cheers,
Nico

--
Nicolas Petton
http://www.nicolas-petton.fr

On Aug 1, 11:43 am, Nicolas Petton <[hidden email]> wrote:

> You can access the current route from any Iliad object from the current
> context (self context).

Thanks, I am still missing something. In ILRouter>>#dispatchRequest
the
decision to redirect is taken (which in turn will generate a
ILJsonHandler to
send the {'redirect':..} json. I must be missing something, e.g. where
in the
ILApplication can I change the decision which initial handler is
created?

Le lundi 01 août 2011 à 07:18 -0700, zecke a écrit :
>
> On Aug 1, 11:43 am, Nicolas Petton <[hidden email]> wrote:
>
> > You can access the current route from any Iliad object from the current
> > context (self context).
>
> Thanks, I am still missing something. In ILRouter>>#dispatchRequest

This will only redirect if you have both a cookie and a session id in
the url, so it should not redirect from there.

> the
> decision to redirect is taken (which in turn will generate a
> ILJsonHandler to
> send the {'redirect':..} json. I must be missing something, e.g. where
> in the
> ILApplication can I change the decision which initial handler is
> created?

here's an example. In the following, I create an action which will
trigger a JSON response with some data:

MyApplication>>index
        ^[:e |
                e a text: 'click me'; action: [self respondInJSON]]

MyApplication>>respondInJSON
        | response |
        response := ILResponse ok
                contentType: 'application/json';
                contents: (String streamContents: [:str |
                        #( 1 2 3 'hello world' ) printJsonOn: str]);
                yourself.
        self returnResponse: response.
        self halt "This line will never be executed, since all request
processing has been aborted with #returnResponse:"

HTH,
Nico


--
Nicolas Petton
http://www.nicolas-petton.fr

On Aug 1, 4:36 pm, Nicolas Petton <[hidden email]> wrote:

> > Thanks, I am still missing something. In ILRouter>>#dispatchRequest
>
> This will only redirect if you have both a cookie and a session id in
> the url, so it should not redirect from there.
>

Sorry for asking you to hold my hand. But I don't have a cookie or a
session
id in the URL. I do this from the console:

$ wget --post-data='{"JSON" : "1"}'http://localhost:8080/fooapp/
barcontroller

The problem is:
ILApplicationHandler>>#isRequestValid

self context previousStateRegistry notNil -> false
self request actionField isNil -> true, but the and: [] checks for
HTTP GET

All POSTs will be redirected, is this working differently to what you
thought
it would work like?

On Aug 2, 2:45 pm, zecke <[hidden email]> wrote:

Or to be more clear. There are three things that prevent the above
from working:

1.) ILApplicationHandler>>#requestIsValid will return false and force
a redirect
    (e.g the posted content is gone), changing the notNil to isNil
makes me pass
    this level

2.) ILApplicationHandler>>#handleRequest will pass things to the JSON
Handler
    (when --header="Accept: application/json" is set in the above
wget) that will
    send me a {"redirect" : "/foo" }, removing the hardcoded JSON
handling makes
    me avoid this (this does not involve the ILApplication)

3.) ILApplicationHandler>>#shouldRedirect retrurns true for a POST,
this way we
    will redirect before Object>>#asResponse is called which triggers
the dispatching
    to the controller.

can you confirm that? Which iliad should I be using?

holger

Another check showed me you're right, I forgot it was with POST
requests :/

So we have 2 solutions:
- Improve request handling and give more responsibility to ILApplication
- Use get requests (in Iliad there's no difference between GET and POST)

What do you think?

Cheers,
Nico

Le mardi 02 août 2011 à 06:11 -0700, zecke a écrit :
--
Nicolas Petton
http://www.nicolas-petton.fr

On Aug 4, 3:08 pm, Nicolas Petton <[hidden email]> wrote:
> Another check showed me you're right, I forgot it was with POST
> requests :/
>
> So we have 2 solutions:
> - Improve request handling and give more responsibility to ILApplication
> - Use get requests (in Iliad there's no difference between GET and POST)

I post some JSON (maybe XML) and it would be nice if I would not have
to move this into the URL. So in some way I would like to have more
advanced routing. We could eye at Seaside and see how they handle POST
and REST in general (the Seaside-Rest module).

Do you have a specific idea of how you would change routing?



Right now I load this into my rest image.

Iliad.ILApplicationHandler extend [
    handleRequest [
        <category: 'request handling'>
        self session isExpired ifTrue: [self session onExpire].
        self isRequestValid
            ifTrue: [self evaluateActions]
            ifFalse: [ILRedirectHandler new handleRequest].
        self shouldReturnEmptyResponse ifTrue: [
            self returnResponse: ILResponse ok].
"
        self shouldRespondInJson ifTrue: [
            ILJsonHandler new handleRequest]."
        self shouldRedirect
            ifTrue: [ILRedirectHandler new handleRequest]
            ifFalse: [self produceResponse]
    ]

    shouldRedirect [
        <category: 'testing'>
"   ^self request isTypeOfRequestForRedirect" <- hack post is always
req
        ^ false
    ]

    isRequestValid [
        <category: 'testing'>
        ^self context previousStateRegistry isNil  <- changed to isNil
            or: [self request actionField isNil and: [self request
isGet]]
    ]
]

Le mercredi 10 août 2011 à 01:37 -0700, zecke a écrit :
I think the first step is to avoid redirects, at least in your case, or
all together. Then give the application a chance to handle the request
before any request handler would probably do the trick, some kind of
#dispatchOverride for request handling?

It's just my thoughts for now, I didn't do anything yet.
BTW, if you have ideas or even working implementations, I'll be happy to
see it.

Cheers,
Nico

--
Nicolas Petton
http://www.nicolas-petton.fr

On Aug 16, 1:57 pm, Nicolas Petton <[hidden email]> wrote:
> Le mercredi 10 août 2011 à 01:37 -0700, zecke a écrit :
>
>

> I think the first step is to avoid redirects, at least in your case, or
> all together. Then give the application a chance to handle the request
> before any request handler would probably do the trick, some kind of
> #dispatchOverride for request handling?
>
> It's just my thoughts for now, I didn't do anything yet.
> BTW, if you have ideas or even working implementations, I'll be happy to
> see it.

I will attempt to come up with something but it will be in terms of
weeks
(hoping to do a small but during vacation)

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Hi!
Currently there's no such plan.

Of course, I'd be happy to review patches! ;) (or discuss about ways to do
it, but my time is too limited to work on that right now).

Cheers,
Nico

zecke writes:


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.