Seaside-Rest and routing engine

Is there any reason the Seaside-REST-Core-Route needs to be in the Seaside-REST-Core package?. As far as I can see the routing is not dependent on seaside.
It would work as well if it uses GRError base class instead of WAError and GRObject instead of WAObject, right? I see the routing is useful even outside the scope of seaside. The Seaside-REST-Core-Handler package uses the Seaside-REST-Core-Route package. So, is there any reason not to make the routing independent?

thanks,

Norbert_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Mon, Jan 7, 2013 at 4:22 PM, Norbert Hartl <[hidden email]> wrote:
> Is there any reason the Seaside-REST-Core-Route needs to be in the Seaside-REST-Core package?. As far as I can see the routing is not dependent on seaside.
> It would work as well if it uses GRError base class instead of WAError and GRObject instead of WAObject, right?

As far as I can see it depends on the request context, the path
consumer and the url.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Am 07.01.2013 um 21:11 schrieb Philippe Marschall <[hidden email]>:

> On Mon, Jan 7, 2013 at 4:22 PM, Norbert Hartl <[hidden email]> wrote:
>> Is there any reason the Seaside-REST-Core-Route needs to be in the Seaside-REST-Core package?. As far as I can see the routing is not dependent on seaside.
>> It would work as well if it uses GRError base class instead of WAError and GRObject instead of WAObject, right?
>
> As far as I can see it depends on the request context, the path
> consumer and the url.
>
Ok, I missed the obvious ones. Would have been too easy :)

Thanks,

Norbert

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev