URL Dispatch Proposal

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

URL Dispatch Proposal

Nicolas Cannasse
Hi,

I wrote a small class (attached file) which is a proposal for a common
Dispatch API for URL requests, potentially replacing several
already-existing possibilities such as mtwin.web.Handler, some parts of
poko and ufront.

I would be happy to get feedback on this, and know if it's a good
candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date
haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org

Dispatch.hx (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Julien CASTETS
Reading the documentation and it sounds nice to me :)
I'll use it for sure next project

Thank you
Julien

2011/8/1 Nicolas Cannasse <[hidden email]>
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Tony Polinelli
Looks great- i hope (and trust) that you didnt take much from poko, im sure this is much better ;P 

The bit that im a little shaky on is the sub-dispatching. Since the dispatch type should be known at compiletime, will this be possible:

class Api {
function doR( d : Dispatch, ?args:{c:String}) {
var i = new (resolveClass(c));
d.dispatch(i);

}
}

class services.Image{
function doResize(args:{w:Int, h:Int})
{
// code 
}
}

im sure this code wont work - but basically, being able to rout the request to a sub API based on a request ( r ), and then have it's api available. If this is possible, the it will be great! 




Dispatch.run("r/services.Image/resize/234/533",new Hash(),new Api());

On Tue, Aug 2, 2011 at 4:28 AM, Julien CASTETS <[hidden email]> wrote:
Reading the documentation and it sounds nice to me :)
I'll use it for sure next project

Thank you
Julien

2011/8/1 Nicolas Cannasse <[hidden email]>
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Tarwin Stroh-Spijer
Still a little unsure of the exactities of it, but I'm a little worried about the Bool. Shouldn't it also take "1" for "true"? Or is it that way already? Just my bad reading of the manual.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Tue, Aug 2, 2011 at 10:05 AM, Tony Polinelli <[hidden email]> wrote:
Looks great- i hope (and trust) that you didnt take much from poko, im sure this is much better ;P 

The bit that im a little shaky on is the sub-dispatching. Since the dispatch type should be known at compiletime, will this be possible:

class Api {
function doR( d : Dispatch, ?args:{c:String}) {
var i = new (resolveClass(c));
d.dispatch(i);

}
}

class services.Image{
function doResize(args:{w:Int, h:Int})
{
// code 
}
}

im sure this code wont work - but basically, being able to rout the request to a sub API based on a request ( r ), and then have it's api available. If this is possible, the it will be great! 




Dispatch.run("r/services.Image/resize/234/533",new Hash(),new Api());

On Tue, Aug 2, 2011 at 4:28 AM, Julien CASTETS <[hidden email]> wrote:
Reading the documentation and it sounds nice to me :)
I'll use it for sure next project

Thank you
Julien

2011/8/1 Nicolas Cannasse <[hidden email]>
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Tony Polinelli
Bool (0/null/falsetrue otherwise)

anything other than those are "true" so yes - 1 would be true i would guess


On Tue, Aug 2, 2011 at 1:48 PM, Tarwin Stroh-Spijer <[hidden email]> wrote:
Still a little unsure of the exactities of it, but I'm a little worried about the Bool. Shouldn't it also take "1" for "true"? Or is it that way already? Just my bad reading of the manual.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________



On Tue, Aug 2, 2011 at 10:05 AM, Tony Polinelli <[hidden email]> wrote:
Looks great- i hope (and trust) that you didnt take much from poko, im sure this is much better ;P 

The bit that im a little shaky on is the sub-dispatching. Since the dispatch type should be known at compiletime, will this be possible:

class Api {
function doR( d : Dispatch, ?args:{c:String}) {
var i = new (resolveClass(c));
d.dispatch(i);

}
}

class services.Image{
function doResize(args:{w:Int, h:Int})
{
// code 
}
}

im sure this code wont work - but basically, being able to rout the request to a sub API based on a request ( r ), and then have it's api available. If this is possible, the it will be great! 




Dispatch.run("r/services.Image/resize/234/533",new Hash(),new Api());

On Tue, Aug 2, 2011 at 4:28 AM, Julien CASTETS <[hidden email]> wrote:
Reading the documentation and it sounds nice to me :)
I'll use it for sure next project

Thank you
Julien

2011/8/1 Nicolas Cannasse <[hidden email]>
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Franco Ponticelli
In reply to this post by Nicolas Cannasse
I really like the idea, simple and functional as usual.
I've not seen at the implementation so some of the consideration below may not apply:
  • lazy loading for the api maybe important if a lot of Dispatch are used (some api may require a mysql connection,some not ...)
  • the routing system is a little too simplistic. Optional parameters in the path may be very handy but once you decide to support them it becomes a little complicated to establish what is optional and what is not.
  • the idea of using macros to type check everything is brilliant but I think that runtime checks should be integrated as well. Uris may be loaded from a DB, diversified for localization ...
Again I really appreciate the API simplicity that hides the Macros complexity and probably adding more features would over-complicate it without being really useful to 90% of the users.

Franco

On Mon, Aug 1, 2011 at 9:53 AM, Nicolas Cannasse <[hidden email]> wrote:
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Tarwin Stroh-Spijer
I don't think URIs need to be localized do they? It sounds a little 'heavy' to load this kind of thing from a DB right?

I guess some CMSs or such might support 'synonyms' or some such idea for URIs ie /child/1 == /enfants/1 ?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Tue, Aug 2, 2011 at 2:33 PM, Franco Ponticelli <[hidden email]> wrote:
I really like the idea, simple and functional as usual.
I've not seen at the implementation so some of the consideration below may not apply:
  • lazy loading for the api maybe important if a lot of Dispatch are used (some api may require a mysql connection,some not ...)
  • the routing system is a little too simplistic. Optional parameters in the path may be very handy but once you decide to support them it becomes a little complicated to establish what is optional and what is not.
  • the idea of using macros to type check everything is brilliant but I think that runtime checks should be integrated as well. Uris may be loaded from a DB, diversified for localization ...
Again I really appreciate the API simplicity that hides the Macros complexity and probably adding more features would over-complicate it without being really useful to 90% of the users.

Franco

On Mon, Aug 1, 2011 at 9:53 AM, Nicolas Cannasse <[hidden email]> wrote:
Hi,

I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.

I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.

I've written complete documentation here :
http://haxe.org/manual/dispatch

Subject to change and open for remarks/improvements.

The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.

Enjoy !

Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Franco Ponticelli
I actually love localizing my uris and SEOs will love you if you can provide that feature. About the loading it can be a DB, a config file or any other mean to produce runtime uris. Again I am only pointing outs things that might or might not be important, it really depends on what you want to achieve.
For example I love the fact that I may use this system perfectly on the client side where the options I pointed out are probably worthless.

Franco

On Monday, August 1, 2011, Tarwin Stroh-Spijer <[hidden email]> wrote:
> I don't think URIs need to be localized do they? It sounds a little 'heavy' to load this kind of thing from a DB right?
> I guess some CMSs or such might support 'synonyms' or some such idea for URIs ie /child/1 == /enfants/1 ?
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321 <tel:%2B61%203%208060%205321>
> _______________________
>
>
> On Tue, Aug 2, 2011 at 2:33 PM, Franco Ponticelli <[hidden email]> wrote:
>>
>> I really like the idea, simple and functional as usual.
>> I've not seen at the implementation so some of the consideration below may not apply:
>>
>> lazy loading for the api maybe important if a lot of Dispatch are used (some api may require a mysql connection,some not ...)
>> the routing system is a little too simplistic. Optional parameters in the path may be very handy but once you decide to support them it becomes a little complicated to establish what is optional and what is not.
>> the idea of using macros to type check everything is brilliant but I think that runtime checks should be integrated as well. Uris may be loaded from a DB, diversified for localization ...
>>
>> Again I really appreciate the API simplicity that hides the Macros complexity and probably adding more features would over-complicate it without being really useful to 90% of the users.
>> Franco
>> On Mon, Aug 1, 2011 at 9:53 AM, Nicolas Cannasse <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.
>>>
>>> I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.
>>>
>>> I've written complete documentation here :
>>> http://haxe.org/manual/dispatch <http://haxe.org/manual/dispatch>
>>>
>>> Subject to change and open for remarks/improvements.
>>>
>>> The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.
>>>
>>> Enjoy !
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org <http://haxe.org>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org <http://haxe.org>
>
>
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Tony Polinelli

Hi Nicholas - can you give an example of how this class might work in a very simple page request - using getParams for example - i am still a little confused i think.




On Tue, Aug 2, 2011 at 4:06 PM, Franco Ponticelli <[hidden email]> wrote:
I actually love localizing my uris and SEOs will love you if you can provide that feature. About the loading it can be a DB, a config file or any other mean to produce runtime uris. Again I am only pointing outs things that might or might not be important, it really depends on what you want to achieve.
For example I love the fact that I may use this system perfectly on the client side where the options I pointed out are probably worthless.

Franco


On Monday, August 1, 2011, Tarwin Stroh-Spijer <[hidden email]> wrote:
> I don't think URIs need to be localized do they? It sounds a little 'heavy' to load this kind of thing from a DB right?
> I guess some CMSs or such might support 'synonyms' or some such idea for URIs ie /child/1 == /enfants/1 ?
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321 <tel:%2B61%203%208060%205321>

> _______________________
>
>
> On Tue, Aug 2, 2011 at 2:33 PM, Franco Ponticelli <[hidden email]> wrote:
>>
>> I really like the idea, simple and functional as usual.
>> I've not seen at the implementation so some of the consideration below may not apply:
>>
>> lazy loading for the api maybe important if a lot of Dispatch are used (some api may require a mysql connection,some not ...)
>> the routing system is a little too simplistic. Optional parameters in the path may be very handy but once you decide to support them it becomes a little complicated to establish what is optional and what is not.
>> the idea of using macros to type check everything is brilliant but I think that runtime checks should be integrated as well. Uris may be loaded from a DB, diversified for localization ...
>>
>> Again I really appreciate the API simplicity that hides the Macros complexity and probably adding more features would over-complicate it without being really useful to 90% of the users.
>> Franco
>> On Mon, Aug 1, 2011 at 9:53 AM, Nicolas Cannasse <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I wrote a small class (attached file) which is a proposal for a common Dispatch API for URL requests, potentially replacing several already-existing possibilities such as mtwin.web.Handler, some parts of poko and ufront.
>>>
>>> I would be happy to get feedback on this, and know if it's a good candidate or not to become part of the haXe standard library.
>>>
>>> I've written complete documentation here :
>>> http://haxe.org/manual/dispatch <http://haxe.org/manual/dispatch>

>>>
>>> Subject to change and open for remarks/improvements.
>>>
>>> The code itself is cross-platform, and you will need an up-to-date haXe/SVN to compile+run it.
>>>
>>> Enjoy !
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org <http://haxe.org>

>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org <http://haxe.org>
>
>
--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Nicolas Cannasse
In reply to this post by Tony Polinelli
Le 02/08/2011 02:05, Tony Polinelli a écrit :

> Looks great- i hope (and trust) that you didnt take much from poko, im
> sure this is much better ;P
>
> The bit that im a little shaky on is the sub-dispatching. Since the
> dispatch type should be known at compiletime, will this be possible:
>
> class Api {
> function doR( d : Dispatch, ?args:{c:String}) {
> var i = new (resolveClass(c));
> d.dispatch(i);
>
> }
> }
>
> class services.Image{
> function doResize(args:{w:Int, h:Int})
> {
> // code
> }
> }
>
> im sure this code wont work - but basically, being able to rout the
> request to a sub API based on a request ( r ), and then have it's api
> available. If this is possible, the it will be great!

You will have to modify a bit doR :

function doR( d : Dispatch, args : { c : String } ) {
   var i = Type.createIstance(Type.resolveClass(args.c));
   d.runtimeDispatch(untyped Dispatch.extractConfig(i));
}

Then add in all your classes that you want to be able to call this way :

   static var _ = Dispatch.make(new MyClass());

In order to make sure that every Config is built at compiletime.

It's not very easy but it will work.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Nicolas Cannasse
In reply to this post by Franco Ponticelli
Le 02/08/2011 06:33, Franco Ponticelli a écrit :
> I really like the idea, simple and functional as usual.
> I've not seen at the implementation so some of the consideration below
> may not apply:
>
>   * lazy loading for the api maybe important if a lot of Dispatch are
>     used (some api may require a mysql connection,some not ...)

What do you mean by "lazy loading" ? By using sub-dispatching you will
get a lazy behavior since the second dispatch will only occur if the
first one matches.

>   * the routing system is a little too simplistic. Optional parameters
>     in the path may be very handy but once you decide to support them it
>     becomes a little complicated to establish what is optional and what
>     is not.

You mean like the following ?

function doUser( ?name : String ) {
}

That would allow both :

Dispatch.run("/user/xxxx", ...
Dispatch.run("/user", ...

Will be easy to add I think.

>   * the idea of using macros to type check everything is brilliant but I
>     think that runtime checks should be integrated as well. Uris may be
>     loaded from a DB, diversified for localization ...

One possible implementation for this, tell me if it feels good :

Use @dynamic to mark methods that might see their name changed, then use
onMeta by subclassing Dispatch to modify the "name" value.

Another option would be to add a
   function resolveName(name) { return name; }
to Dispatch that could be overriden again with custom behavior.

> Again I really appreciate the API simplicity that hides the Macros
> complexity and probably adding more features would over-complicate it
> without being really useful to 90% of the users.

Simplicity is often a good way to allow things to be customized, that's
why I'm happy if we can find a simple way of implementing each of the
particular cases you might have. It would prove that the basic are right.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Nicolas Cannasse
In reply to this post by Tony Polinelli
Le 02/08/2011 11:27, Tony Polinelli a écrit :
>
> Hi Nicholas - can you give an example of how this class might work in a
> very simple page request - using getParams for example - i am still a
> little confused i think.

Like this ?

Dispatch.run(neko.Web.getURI(),neko.Web.getParams(),new Api());

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Franco Ponticelli
In reply to this post by Nicolas Cannasse
What do you mean by "lazy loading" ? By using sub-dispatching you will get a lazy behavior since the second dispatch will only occur if the first one matches.

I mean instantiating the API class only when it is used ... if you have 20 URIs and only one will "react" to a certain path, you might not want to instantiate the API for the 19 that are not running.
 
You mean like the following ?

function doUser( ?name : String ) {
}

That would allow both :

Dispatch.run("/user/xxxx", ...
Dispatch.run("/user", ...

That exactly right ... One more thing you might consider is capturing some how the extension if exists. It may be a good and simple way to determine a certain kind of response (json vs xml or jpg vs png ...).
With those features I think you will cover most of the cases. Some edge case may still exist like non optional part being at the right of optional parts, or fixed parts being mixed with optionals and maybe not separate by the slash ... as an example consider this: /image/crop/30x30/id.png  (crop could be optional as well a just one of the size values). Taking care of all those cases is tricky without a DSL and DSL may add unwanted complexity (that the way ufront went anyway).
 
Another option would be to add a
 function resolveName(name) { return name; }
to Dispatch that could be overriden again with custom behavior.

The resolveName seems perfect.

One last thing I have not mentioned before is how to integrate with a view. The current controllers do not return anything and act on a "known" context. The problem with that is that makes controllers harder to reuse.

Franco


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Nicolas Cannasse
Le 02/08/2011 17:24, Franco Ponticelli a écrit :
>     What do you mean by "lazy loading" ? By using sub-dispatching you
>     will get a lazy behavior since the second dispatch will only occur
>     if the first one matches.
>
>
> I mean instantiating the API class only when it is used ... if you have
> 20 URIs and only one will "react" to a certain path, you might not want
> to instantiate the API for the 19 that are not running.

Not sure for PHP, but for other platforms it doesn't make any change if
you have a small or big class. And I guess that in PHP with code caching
on it doesn't matter either.

>     You mean like the following ?
>
>     function doUser( ?name : String ) {
>     }
>
>     That would allow both :
>
>     Dispatch.run("/user/xxxx", ...
>     Dispatch.run("/user", ...
>
>
> That exactly right ...

Will look at adding it.

> One more thing you might consider is capturing
> some how the extension if exists. It may be a good and simple way to
> determine a certain kind of response (json vs xml or jpg vs png ...).

Extension (actually the complete filename + extension) will be captured
with a String argument, I'm not sure if/how we should treat it differently.

> With those features I think you will cover most of the cases. Some edge
> case may still exist like non optional part being at the right of
> optional parts, or fixed parts being mixed with optionals and maybe not
> separate by the slash ...

For such exotic cases, you can still capture only the fixed parts in
arguments and request the Dispatch instance to process the rest of the
parts by-hand.

> as an example consider this:
> /image/crop/30x30/id.png  (crop could be optional as well a just one of
> the size values). Taking care of all those cases is tricky without a DSL
> and DSL may add unwanted complexity (that the way ufront went anyway).

I need to add the handle for "doDefault", in your example that would
mean having :

class Api {
   function doImage( d : Dispatch ) {
        d.dispatch(new ImageApi());
   }
}

class ImageApi {
   function doDefault( file : String ) {
   }
   function doCrop( size : String, file : String ) {
   }
}

Sounds good ?

>     Another option would be to add a
>       function resolveName(name) { return name; }
>     to Dispatch that could be overriden again with custom behavior.
>
>
> The resolveName seems perfect.

Will add it.

> One last thing I have not mentioned before is how to integrate with a
> view. The current controllers do not return anything and act on a
> "known" context. The problem with that is that makes controllers harder
> to reuse.

Not sure if that's what you mean here, but I need to test if it's
possible to have "dispatch" return the doXXX returned value : no problem
for Neko/JS, not sure for Flash9/CPP when the doXXX returns Void.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

bubblebenj
One thing I don't understand is why function name should be for "/user"
doUser 
instead of simply
user ?

Ben

On Wed, Aug 3, 2011 at 6:29 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 02/08/2011 17:24, Franco Ponticelli a écrit :

   What do you mean by "lazy loading" ? By using sub-dispatching you
   will get a lazy behavior since the second dispatch will only occur
   if the first one matches.


I mean instantiating the API class only when it is used ... if you have
20 URIs and only one will "react" to a certain path, you might not want
to instantiate the API for the 19 that are not running.

Not sure for PHP, but for other platforms it doesn't make any change if you have a small or big class. And I guess that in PHP with code caching on it doesn't matter either.


   You mean like the following ?

   function doUser( ?name : String ) {
   }

   That would allow both :

   Dispatch.run("/user/xxxx", ...
   Dispatch.run("/user", ...


That exactly right ...

Will look at adding it.


One more thing you might consider is capturing
some how the extension if exists. It may be a good and simple way to
determine a certain kind of response (json vs xml or jpg vs png ...).

Extension (actually the complete filename + extension) will be captured with a String argument, I'm not sure if/how we should treat it differently.


With those features I think you will cover most of the cases. Some edge
case may still exist like non optional part being at the right of
optional parts, or fixed parts being mixed with optionals and maybe not
separate by the slash ...

For such exotic cases, you can still capture only the fixed parts in arguments and request the Dispatch instance to process the rest of the parts by-hand.


as an example consider this:
/image/crop/30x30/id.png  (crop could be optional as well a just one of
the size values). Taking care of all those cases is tricky without a DSL
and DSL may add unwanted complexity (that the way ufront went anyway).

I need to add the handle for "doDefault", in your example that would mean having :

class Api {
 function doImage( d : Dispatch ) {
       d.dispatch(new ImageApi());
 }
}

class ImageApi {
 function doDefault( file : String ) {
 }
 function doCrop( size : String, file : String ) {
 }
}

Sounds good ?


   Another option would be to add a
     function resolveName(name) { return name; }
   to Dispatch that could be overriden again with custom behavior.


The resolveName seems perfect.

Will add it.


One last thing I have not mentioned before is how to integrate with a
view. The current controllers do not return anything and act on a
"known" context. The problem with that is that makes controllers harder
to reuse.

Not sure if that's what you mean here, but I need to test if it's possible to have "dispatch" return the doXXX returned value : no problem for Neko/JS, not sure for Flash9/CPP when the doXXX returns Void.


Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Franco Ponticelli
In reply to this post by Nicolas Cannasse

>> I mean instantiating the API class only when it is used ... if you have
>> 20 URIs and only one will "react" to a certain path, you might not want
>> to instantiate the API for the 19 that are not running.
>
> Not sure for PHP, but for other platforms it doesn't make any change if you have a small or big class. And I guess that in PHP with code caching on it doesn't matter either.

He problem is not mch having a new instance or loading a type but what the constructor does. For example It may open a db connection that is not used.

>> One more thing you might consider is capturing
>> some how the extension if exists. It may be a good and simple way to
>> determine a certain kind of response (json vs xml or jpg vs png ...).
>
> Extension (actually the complete filename + extension) will be captured with a String argument, I'm not sure if/how we should treat it differently.

Me neither but etension may be of some importance.

> I need to add the handle for "doDefault", in your example that would mean having :
>
> class Api {
>  function doImage( d : Dispatch ) {
>        d.dispatch(new ImageApi());
>  }
> }
>
> class ImageApi {
>  function doDefault( file : String ) {
>  }
>  function doCrop( size : String, file : String ) {
>  }
> }
>
> Sounds good ?

I think so.

Franco
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Justin Donaldson-3
In reply to this post by bubblebenj

On Tue, Aug 2, 2011 at 10:33 PM, benjamin Dubois <[hidden email]> wrote:
One thing I don't understand is why function name should be for "/user"
doUser 
instead of simply
user ?


I had the same question.  I assumed it was because the function for "/" could be do().

-Justin


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Nicolas Cannasse
In reply to this post by bubblebenj
Le 03/08/2011 07:33, benjamin Dubois a écrit :
> One thing I don't understand is why function name should be for"/user"
> doUser
> instead of simply
> user ?

The reason is quite simple : you might have other helper methods in your
api that you don't want people to be able to call, for instance :

function deleteUser( uid : Int ) {
}

So in order to ensure that the Dispatch has only access to methods that
are "callable" we prefix them with "do".

(+ this is already a convention we've been using at MotionTwin in
neko.web.Handler's)

I'll maybe add a note about this particular point in Dispatch documentation.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Gamehaxe
Hi,
Is there any room for digest authentication?  That would be nice.
Also, in a multi-threaded environment, and a fresh start, it
might be nice to pass the request/response object. Or would
you suggest TLS?

Hugh

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: URL Dispatch Proposal

Jon Sully
In reply to this post by Nicolas Cannasse
You could also perhaps specify which are callable using metadata:

class AdminApi {
    @default function home() {}
    @route function create() {}
    @route function update(id:Int) {}   
    function helper() {}
}



On 3 August 2011 10:28, Nicolas Cannasse <[hidden email]> wrote:
Le 03/08/2011 07:33, benjamin Dubois a écrit :

One thing I don't understand is why function name should be for"/user"
doUser
instead of simply
user ?

The reason is quite simple : you might have other helper methods in your api that you don't want people to be able to call, for instance :

function deleteUser( uid : Int ) {
}

So in order to ensure that the Dispatch has only access to methods that are "callable" we prefix them with "do".

(+ this is already a convention we've been using at MotionTwin in neko.web.Handler's)

I'll maybe add a note about this particular point in Dispatch documentation.


Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
12