RE: Router.attach Patterns
Hello, 1) Coocoon map concept (http://cocoon.apache.org/2.2/core-modules/core/2.2/1376_1_1.h tml), just to provide more declarative way to configure URI - Restlets mapping? In Restlet 1.1, we'll introduce the support for more declarative XML configurations based on WADL and probably an additional custom XML file. See related issues: WADL support: http://restlet.tigris.org/issues/show_bug.cgi?id=59 XML configuration: http://restlet.tigris.org/issues/show_bug.cgi?id=164 2) Internal Restful design of web-application? means to get name for each of the individual classes/resources/restlet with the help of java5 annotation @uri(schema://internal/weatherwidgetresource) and use them as individual pipes (POST data to proccess and getTheRepresentation of the result) [...] Good points, and I think 1.1 will please you because we'll have new related features: 1) The ability to internally dispatch requests without going thought the network layers (no IO for representations): http://restlet.tigris.org/issues/show_bug.cgi?id=157 2) The support of a private and internal access scheme (ex: riap://component/myAppPath/myResource) that will allow modularization of applications and efficient composition of resources via XSLT or other means. This is inspired from Cocoon pseudo-protocols: http://restlet.tigris.org/issues/show_bug.cgi?id=374 Best regards, Jerome
Re: Router.attach Patterns
On 11/6/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
Thanks for sharing all the details.
1) For the root attachment issue, you can use this approach instead:
// To match only URIs that are strictly equal to /
Template template = router.attach(/, rootRestlet).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
// To match all other URIs
router.attach(/, everythingElseRestlet);
2) For the mapping of URIs with a .js extension to a resource you can do:
Template template = router.attach(/{foo}.js).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
template.getDefaultVariable().setType(TYPE_URI_ALL);
or
template.getVariables().put(foo, new Variable(TYPE_URI_ALL));
Does that cover all your needs or am I still missing something ?
That certainly provides a way for my current set of patterns.
This all needs to be better documented in both how to use the API to
accomplish this and the fact that the specification for URI templates mentions
nothing about matching semantics. As such, restlet.org should have
such a specification somewhere.
--Alex Milowski
Re: Router.attach Patterns
On 11/8/07, xasima [EMAIL PROTECTED] wrote: Hi, Jerome and Alex. We can use http://smallx.dev.java.net or cocoon maps notation (http://cocoon.apache.org/2.2/core-modules/core/2.2/853_1_1.html) to provide info for the coordination of such a pipes / URI. I think that reasons to do this are a) to get all advantages that cocoon offers by providing declarative URI model and pipeline support b) do the mentioned actions in distibuted manner, since each pipe can be deployed in any place of the web (or in scope of your cluster), due to REST notion of the pipe (GET, POST) and ability to negotiate on the representation (JAVA_IN_PROCESS, SAX, DOM, or custom one). It many ways, the use of URI templates in the API makes the API itself somewhat declarative. Being the person who started the smallx project, I'm not sure what you mean. I've been using Restlet for awhile now and it provides me a greater degree flexibility. Although, I have create my own set of XML configuration files for specifying virtual hosts and their applications. BTW, smallx has had a major change and is now available from two different google code projects: * http://code.google.com/p/xml-infoset * http://code.google.com/p/smallx The new version of smallx doesn't not contain all the XML infoset processing technology as that has been refactored into the xml-infoset project. All that remains in the smallx project is the XML pipelining technology--which has now moved forward to XProc (http://www.w3.org/TR/xproc/). My eventual plan is to provide an XProc integration with Restlet in the smallx project. --Alex Milowski
Re: Router.attach Patterns
Hi, Jerome and Alex. What do you think on the implementation: 1) Coocoon map concept (http://cocoon.apache.org/2.2/core-modules/core/2.2/1376_1_1.html), just to provide more declarative way to configure URI - Restlets mapping? 2) Internal Restful design of web-application? means to get name for each of the individual classes/resources/restlet with the help of java5 annotation @uri(schema://internal/weatherwidgetresource) and use them as individual pipes (POST data to proccess and getTheRepresentation of the result) We can use http://smallx.dev.java.net or cocoon maps notation (http://cocoon.apache.org/2.2/core-modules/core/2.2/853_1_1.html) to provide info for the coordination of such a pipes / URI. I think that reasons to do this are a) to get all advantages that cocoon offers by providing declarative URI model and pipeline support b) do the mentioned actions in distibuted manner, since each pipe can be deployed in any place of the web (or in scope of your cluster), due to REST notion of the pipe (GET, POST) and ability to negotiate on the representation (JAVA_IN_PROCESS, SAX, DOM, or custom one). I 'd be pleased to work on such an feature.
RE: Router.attach Patterns
Hi Alex,
Thanks for sharing all the details.
1) For the root attachment issue, you can use this approach instead:
// To match only URIs that are strictly equal to /
Template template = router.attach(/, rootRestlet).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
// To match all other URIs
router.attach(/, everythingElseRestlet);
2) For the mapping of URIs with a .js extension to a resource you can do:
Template template = router.attach(/{foo}.js).getTemplate();
template.setMatchingMode(Template.MODE_EQUALS);
template.getDefaultVariable().setType(TYPE_URI_ALL);
or
template.getVariables().put(foo, new Variable(TYPE_URI_ALL));
Does that cover all your needs or am I still missing something ?
Best regards,
Jerome
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
part de Alex Milowski
Envoyé : lundi 5 novembre 2007 22:17
À : discuss@restlet.tigris.org
Objet : Re: Router.attach Patterns
On 11/5/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
As you probably know, we already have a way to specify the
type of each
variable in an URI template via the
org.restlet.util.Variable class and the
Template.variables and Template.defaultVariable properties.
Could you describe the use case(s) that would require a
full regex syntax in
URI templates ?
The problem is that if you look at the specification for URI
templates[1], it explains
how templates can be used to create URI values and not how
they are matched.
In fact, I can't really find that information anywhere except
in the code.
Unfortunately, looking at the URI templates specification, I can find
inconsistencies
between generating and matching URI values.
One of the examples is:
http://example.com/{q}
http://example.com/hello#world
where q=hello#world.
If you tried to use the URI template http://example.com/{q};, you'd
get 'hello' for the
variable 'q' because the default is to use a URI segment rather than
the remaining
URI path.
In several of my applications I need to be able to match a remaining
URI path. When I've
developed custom code, I attach a Finder to do that but I have
problems when the root needs
to be handled differently than its sub-resources.
I've run into trouble with simple applications that are configured
from a configuration file
where the match pattern is specified and a restlet is attached for
all sub paths.
For example, if you want to map:
/ - RootRestlet.class
/.* - EverythingElseRestlet.class
you can use the two templates:
/ - RootRestlet.class
/{name} - EverythingElseRestlet.class
Now, that does the right thing only because any resource below the
root must have an
additional segment in typical directory hierarchy paths. The problem
is that the Request
instance now has a Reference where the getRemainingPart() does not
return the whole
subpath without prefixing the name attribute value. Then you have
special case your
attached Restlet to deal with that oddity.
Certainly the above problem can be solved by allowing more control
over the Route or
by messing with the template used by the route. It just seems
incomplete that you can
attach a Restlet to a template/pattern that says all sub resources
but not the root without
messing up the getRemainingPart() call.
Another simple use case is knocking out a URI (e.g. a moved or bad
resource) from amongst
valid ones by mapping it to a error handling resource. For example,
you might want to find all
paths then end with .js under a certain resource.
[1]
http://bitworking.org/projects/URI-Templates/draft-gregorio-ur
itemplate-01.html
--Alex Milowski
RE: Router.attach Patterns
Hi Alex, As you probably know, we already have a way to specify the type of each variable in an URI template via the org.restlet.util.Variable class and the Template.variables and Template.defaultVariable properties. Could you describe the use case(s) that would require a full regex syntax in URI templates ? Best regards, Jerome -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex Milowski Envoyé : samedi 3 novembre 2007 03:24 À : discuss@restlet.tigris.org Objet : Router.attach Patterns While I like the simplicity of URI patterns, I find I want the ability to specify a regex often. I wonder if there is someway to provide both? Maybe: Router r = ... r.attachPattern(/some/path/.*,...); Then I could do; r.attachPattern(/some/path/(.*),...) and then in the request get the group. We could bind the groups so that their group # is the name of the attribute: Object o = request.getAttributes().get(1); --Alex Milowski
Re: Router.attach Patterns
On 11/5/07, Jerome Louvel [EMAIL PROTECTED] wrote:
Hi Alex,
As you probably know, we already have a way to specify the type of each
variable in an URI template via the org.restlet.util.Variable class and the
Template.variables and Template.defaultVariable properties.
Could you describe the use case(s) that would require a full regex syntax in
URI templates ?
The problem is that if you look at the specification for URI
templates[1], it explains
how templates can be used to create URI values and not how they are matched.
In fact, I can't really find that information anywhere except in the code.
Unfortunately, looking at the URI templates specification, I can find
inconsistencies
between generating and matching URI values.
One of the examples is:
http://example.com/{q}
http://example.com/hello#world
where q=hello#world.
If you tried to use the URI template http://example.com/{q};, you'd
get 'hello' for the
variable 'q' because the default is to use a URI segment rather than
the remaining
URI path.
In several of my applications I need to be able to match a remaining
URI path. When I've
developed custom code, I attach a Finder to do that but I have
problems when the root needs
to be handled differently than its sub-resources.
I've run into trouble with simple applications that are configured
from a configuration file
where the match pattern is specified and a restlet is attached for
all sub paths.
For example, if you want to map:
/ - RootRestlet.class
/.* - EverythingElseRestlet.class
you can use the two templates:
/ - RootRestlet.class
/{name} - EverythingElseRestlet.class
Now, that does the right thing only because any resource below the
root must have an
additional segment in typical directory hierarchy paths. The problem
is that the Request
instance now has a Reference where the getRemainingPart() does not
return the whole
subpath without prefixing the name attribute value. Then you have
special case your
attached Restlet to deal with that oddity.
Certainly the above problem can be solved by allowing more control
over the Route or
by messing with the template used by the route. It just seems
incomplete that you can
attach a Restlet to a template/pattern that says all sub resources
but not the root without
messing up the getRemainingPart() call.
Another simple use case is knocking out a URI (e.g. a moved or bad
resource) from amongst
valid ones by mapping it to a error handling resource. For example,
you might want to find all
paths then end with .js under a certain resource.
[1]
http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-01.html
--Alex Milowski
