RE: Java 6
I can run JVM6. The issue seems to be J6/Tomcat calling Restlet (J5) calling my resources J6. I can do 5/5/5 and 6/5/5, but not 6/5/6-as far as I can tell. Cliff Binstock Coyote Reporting _ From: Malcolm Sparks [mailto:malc...@congreve.com] Sent: Thursday, April 02, 2009 11:15 AM To: discuss@restlet.tigris.org Subject: Re: Java 6 A more general note: Applications compiled with Java 5 typically run on Java 6 JVMs without problems. Applications compiled with Java 6 don't run on Java 5 JVMs- the Java 5 JVM detects that the bytecode version is higher and therefore rejects it. So, in theory, you don't need a Java 6 build of Restlet. Which JVM are you running on? On 31 Mar 2009, at 17:57, Cliff Binstock wrote: Is it correct that the current build is based on Java 1.5? Is there a Java 6 build available? Or do I have to build this myself? Notably, I cant run a Java 6 compiled application under tomcat w/Java 6. Im not 100% certain, but it appears that this is because Restlet itself is 1.5 (I get class version errors loading the restlet application). Thanks much, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1565626
Java 6
Is it correct that the current build is based on Java 1.5? Is there a Java 6 build available? Or do I have to build this myself? Notably, I can't run a Java 6 compiled application under tomcat w/Java 6. I'm not 100% certain, but it appears that this is because Restlet itself is 1.5 (I get class version errors loading the restlet application). Thanks much, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1497681
RE: POST redirect to GET
Thank you! Cliff Binstock Coyote Reporting _ From: Erik Beeson [mailto:erik.bee...@gmail.com] Sent: Monday, March 16, 2009 4:09 PM To: discuss@restlet.tigris.org Subject: Re: POST redirect to GET Go back and reread the HTTP spec. In particular, read about "303 See Other" on the first hit here: http://www.google.com/search?q=http+status --Erik On Mon, Mar 16, 2009 at 3:57 PM, Cliff Binstock wrote: My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When Im done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember Im inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried ?method=get, but I suppose thats getting ignored because Im not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1336044
POST redirect to GET
My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When I'm done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember I'm inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried "?method=get", but I suppose that's getting ignored because I'm not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1335863
RE: DOM formatting
I would concur. The default should probably be false. However, I still think the feature is very useful: theres a lot to be said for having the default return readable. Also, I know I suggested indent, but it should probably be auto-format or pretty-print or some such: indent sounds like it should be a number (e.g., indent 4 characters). Cliff Binstock Coyote Reporting _ From: remidewi...@gmail.com [mailto:remidewi...@gmail.com] On Behalf Of Rémi Dewitte Sent: Friday, February 06, 2009 4:02 AM To: discuss@restlet.tigris.org Subject: Re: DOM formatting Jérôme, I have the feeling that defaulting it to true is not really the right thing to do. I think you don't need very often to have the XML output in a fashionable way and it will by default consume more resources for nothing. Because most of the time xml is not meant to be consumed by humans (except debugging). Moreover, IE or FF are both able to display XML trees. If you use curl to test your XML Restlet, just do somthing like this : curl url | xmllint --format - And you are done. Rémi On Fri, Feb 6, 2009 at 12:54, Jerome Louvel wrote: Hi Cliff, Good suggestion. I've just added this "indent" property to DomRepresentation in SVN trunk. Its value is true by default. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com> http://www.noelios.com _ De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoyé : vendredi 6 février 2009 00:40 À : discuss@restlet.tigris.org Objet : RE: DOM formatting Stephen, Thanks for the input still seems like it should be more trivial [ DomRepresentation#setIndent(boolean), perhaps ] Cliff Binstock Coyote Reporting _ From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] Sent: Thursday, February 05, 2009 1:41 PM To: discuss@restlet.tigris.org Subject: Re: DOM formatting Hi, Have you considered subclassing DomRepresentation and overriding its createTransformer() method to set the output properties you want (in your case, OutputKeys.INDENT to yes)? I had a case where I had to modify some properties of the XML being produced, and I found that the easiest way to do it was to subclass the representation in this way. On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock wrote: The DOMRepresentation, writes out the DOM as-is. Certainly this is great in most cases. However, it would be nice if there was "pretty-print" option that provided easy-to-look at XML. Of course, I can (and probably will) run the DOM through my own transformation to pretty-print, but it seems like use case might be a common desire. My current use case is building a Document with Elements, but no Text nodes, so the resultant XML is one unreadable line. If there is an existing trivial way to do this, great. If not, consider this a feature request. Thanks! Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1113782
RE: DOM formatting
Stephen, Thanks . for the input . still seems like it should be more trivial [ DomRepresentation#setIndent(boolean), perhaps ] Cliff Binstock Coyote Reporting _ From: Stephen Groucutt [mailto:stephen.grouc...@gmail.com] Sent: Thursday, February 05, 2009 1:41 PM To: discuss@restlet.tigris.org Subject: Re: DOM formatting Hi, Have you considered subclassing DomRepresentation and overriding its createTransformer() method to set the output properties you want (in your case, OutputKeys.INDENT to yes)? I had a case where I had to modify some properties of the XML being produced, and I found that the easiest way to do it was to subclass the representation in this way. On Thu, Feb 5, 2009 at 4:12 PM, Cliff Binstock wrote: The DOMRepresentation, writes out the DOM as-is. Certainly this is great in most cases. However, it would be nice if there was "pretty-print" option that provided easy-to-look at XML. Of course, I can (and probably will) run the DOM through my own transformation to pretty-print, but it seems like use case might be a common desire. My current use case is building a Document with Elements, but no Text nodes, so the resultant XML is one unreadable line. If there is an existing trivial way to do this, great. If not, consider this a feature request. Thanks! Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1109609
Magic File Feature request
Another feature request: It would be very nice to have a way to tell the FileRepresentation to set the MediaType based on the magic type determination. There is no way to return the right type based a java.io.File today, is there? Thanks again, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1109596
DOM formatting
The DOMRepresentation, writes out the DOM as-is. Certainly this is great in most cases. However, it would be nice if there was "pretty-print" option that provided easy-to-look at XML. Of course, I can (and probably will) run the DOM through my own transformation to pretty-print, but it seems like use case might be a common desire. My current use case is building a Document with Elements, but no Text nodes, so the resultant XML is one unreadable line. If there is an existing trivial way to do this, great. If not, consider this a feature request. Thanks! Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1109135
RE: Custom conneg for (X)HTML media types
Simon, Like you, I've been struggling between the default content negotiation, and the fact that I want a) flexibility; b) reasonable "default" handling in the browsers. Note that most of my routes can return many media types. While I am considering revisiting the Metadata classes (per Jerome), I currently have what you might call content negotiation logic in Resource#generateRepresentation overrides. One of the things I do here is just handle IE as an exceptional case. Literally: if (agent.equals("MSIE") && mtype.equals(MediaType.APPLICATION_XHTML_XML)) { mtype = MediaType.TEXT_HTML; } So, the default (when reasonable) is to return XHTML. FF/Opera/etc. get the XHTML content type; IE gets HTML. Cliff Binstock Coyote Reporting > -Original Message- > From: Simon Reinhardt [mailto:simon.reinha...@koeln.de] > Sent: Friday, January 30, 2009 12:25 PM > To: discuss@restlet.tigris.org > Subject: Custom conneg for (X)HTML media types > > Hi, > > When working with XHTML you have to be careful how to deliver it. The > appropriate content type is application/xhtml+xml in which case the > supporting browser will treat it as XML (for parsing, in the DOM and in > CSS for example). However non-supporting browsers like IE will choke on > that and offer you the page for download. Therefore you can alternatively > serve it as text/html - with the disadvantage that it will be parsed and > treated as HTML. > Now, of course you can look into the Accept header to find out if the > browser will support XHTML or not and serve it under an appropriate > content type accordingly. The problem with that are the Accept headers > that browsers actually send. Opera and FF ask for both media types, with > the same preference, text/html coming first. IE doesn't ask for any HTML > media type at all but just tells you that it accepts some other stuff and > then anything with a preference of 1. So, the default conneg algorithm > doesn't work here: If I register two variants, the HTML one coming first, > then all browsers will get the HTML version. If I register two variants, > the XHTML one coming first, then all browsers will get the XHTML version, > even IE which doesn't support it. > This situation was being recognised by the W3C and they came up with a > custom conneg algorithm [1]. The idea is to only serve XHTML when it is > explicitly listed in the Accept header - and when it is, give it > precedence over HTML. They say there that you should do that for XHTML > documents that follow the compatibility guidelines and therefore can be > rendered by non-supporting browsers properly, so they don't really do > conneg but just serve one variant with different media types. But of > course nothing stops you from really writing two variants, one in HTML > 4.01 and one in XHTML+SVG+MathML for example (the latter wouldn't be valid > to serve as text/html at all). > > So the question here is, can you think of an easy way to implement this > custom conneg (or rather just Accept-header inspection) algorithm in > Restlet? > > Thanks, > Simon > > [1] http://www.w3.org/TR/2009/NOTE-xhtml-media-types-20090116/#media-types > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=107 > 6412 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1077338
RE: media type adaptor
Jerome, I am using the standard content negotiation, and am declaring multiple variants. The issue is that I have LOTS of variants (HTML, XML, Excel spreadsheets, and more), and sometimes the variant I return might have NOTHING to do with the content list requested (Excel, for example, is not in the IE or FF content request list). I will look at the MetadataService rewrite, which might help. However I don’t currently have a “general” rule (which I think is what the MetadataService remap might accomplish), but the type-to-return rules are determined by the requested URLs. I will consider this, however, maybe I can (and should) make it more consistent. Thanks for the pointing these items out. I definitely will look at both the MetadataService and the TunnelService to see if I can better use the infrastructure. Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:jerome.lou...@noelios.com] Sent: Friday, January 16, 2009 12:49 AM To: discuss@restlet.tigris.org Subject: RE: media type adaptor Hi Cliff, It seems like doing what you propose would overlap with the normal content negotiation which should be driven by client preferences. If you want to return the same representation as both "application/xhtml+xml" and "text/xml", if can simply declare the two variants and return the same "technical" representation for each one of them, either via the current if/else if approach or in the near future via the representXhtml() and representXml() methods. Also, in the MetadataService, the same extension (ex: "xml") can be mapped to several media types (ex: "text/xml" and "application/xml") so in this case, the representXml() method would match both. Regarding the browser nonsense, we did implement a solution in the TunnelService that can automatically rewrite the preferences based on the user agent name (see the "userAgentTunnel" property). Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoyé : jeudi 15 janvier 2009 19:31 À : discuss@restlet.tigris.org Objet : RE: media type adaptor J�r�me, Some more thoughts … from experience … 1. Need a flag to determine if alternate representations are acceptable (Requester asked for HTML, but I don’t have that, and wish to return XML). 2. If alternate is acceptable, need a prioritized (ordered) list of acceptable variants (look for XHTML, then look for HTML, then look for XML).� You should probably have a default, but it should be easy to override. 3. If you feel like getting into the browser nonsense (and I’d understand if you didn’t), bypass/translate to another type.� For example, IE doesn’t behave kindly to XHTML return type.� Of course, any behavior here must be customizable (overridable). Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:jerome.lou...@noelios.com] Sent: Wednesday, January 14, 2009 10:14 AM To: discuss@restlet.tigris.org Subject: RE: media type adaptor Hi all, We have a similar plan in the tube! "Faciliate Resource to Representation mapping" http://restlet.tigris.org/issues/show_bug.cgi?id=303 The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) and storeRepresentation(*) to the more specific versions if available like: representXml(?) for an XML representation ("xml" being mapped in MetadataService like for file extensions) representJson(?) for a JSON representation ... This would handle the dispatching automatically while still allowing a manual dispatching by overriding the generic represent(*) method when more appropriate (and for backward compatibility). How does it sound? Best regards, J�r�me Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoy� : mardi 13 janvier 2009 17:43 � : discuss@restlet.tigris.org Objet : RE: media type adaptor Taylor, I have implemented a solution like this and I highly recommend it. I actually have taken it one step further and bound the routes (and the implementation) dynamically: there is very little Java code, mostly just XML-based configuration. In the cases where configuration does not make sense, then I have subclasses that provide an implementation as your message implies. I can tell you that you will want to pass in the request to the callback: you don’t always need it, but sometimes you need some contextual infor
RE: media type adaptor
Jérôme, Some more thoughts from experience 1. Need a flag to determine if alternate representations are acceptable (Requester asked for HTML, but I dont have that, and wish to return XML). 2. If alternate is acceptable, need a prioritized (ordered) list of acceptable variants (look for XHTML, then look for HTML, then look for XML). You should probably have a default, but it should be easy to override. 3. If you feel like getting into the browser nonsense (and Id understand if you didnt), bypass/translate to another type. For example, IE doesnt behave kindly to XHTML return type. Of course, any behavior here must be customizable (overridable). Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:jerome.lou...@noelios.com] Sent: Wednesday, January 14, 2009 10:14 AM To: discuss@restlet.tigris.org Subject: RE: media type adaptor Hi all, We have a similar plan in the tube! "Faciliate Resource to Representation mapping" http://restlet.tigris.org/issues/show_bug.cgi?id=303 The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) and storeRepresentation(*) to the more specific versions if available like: representXml(?) for an XML representation ("xml" being mapped in MetadataService like for file extensions) representJson(?) for a JSON representation ... This would handle the dispatching automatically while still allowing a manual dispatching by overriding the generic represent(*) method when more appropriate (and for backward compatibility). How does it sound? Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : Cliff Binstock [mailto:cliff.binst...@coyotereporting.com] Envoyé : mardi 13 janvier 2009 17:43 À : discuss@restlet.tigris.org Objet : RE: media type adaptor Taylor, I have implemented a solution like this and I highly recommend it. I actually have taken it one step further and bound the routes (and the implementation) dynamically: there is very little Java code, mostly just XML-based configuration. In the cases where configuration does not make sense, then I have subclasses that provide an implementation as your message implies. I can tell you that you will want to pass in the request to the callback: you dont always need it, but sometimes you need some contextual information (see previous post about wanting the original route URI, for example). Cliff Binstock Coyote Reporting _ From: Taylor Cowan [mailto:taylor_co...@yahoo.com] Sent: Tuesday, January 13, 2009 7:12 AM To: discuss@restlet.tigris.org Subject: media type adaptor I'm new to restlets and would like some feedback from the community on some experimentation. Instead of if/else'ing through the list of variant types and calling the appropriate logic, I'd like reslets to do that for me. The example "MediaType" below is similar to the restlet version, except that each enumeration overrides a call back, for example, the text/html type calls back to handleTextHTML(). TEXT_HTML("text/html", "HTML document") { @Override public Representation callBack(VariantHandler arg0) { return arg0.handleTextHTML(); } }, The application developer then extends a resource from BaseResource, and implements the methods they'd like to handle. (like the AWT MouseEvent adaptors of old) The examples are not complete, I only implmented 4 media types. The BaseResource gets the media type, converts to the appropriate extended MediaType, and the invokes the callback. @Override public Representation represent(Variant variant) throws ResourceException { String mediaType = variant.getMediaType().getName(); return MediaType.value(mediaType).callBack(this); } So to handle HTML, the developer just does this: @Override public Representation handleTextHTML() { // here's where we respond to HTML clients. } http://restlets.s3.amazonaws.com/VariantHandler.java http://restlets.s3.amazonaws.com/BaseResource.java http://restlets.s3.amazonaws.com/MediaType.java -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1026796
RE: media type adaptor
Taylor, I have implemented a solution like this and I highly recommend it. I actually have taken it one step further and bound the routes (and the implementation) dynamically: there is very little Java code, mostly just XML-based configuration. In the cases where configuration does not make sense, then I have subclasses that provide an implementation as your message implies. I can tell you that you will want to pass in the request to the callback: you don't always need it, but sometimes you need some contextual information (see previous post about wanting the original route URI, for example). Cliff Binstock Coyote Reporting _ From: Taylor Cowan [mailto:taylor_co...@yahoo.com] Sent: Tuesday, January 13, 2009 7:12 AM To: discuss@restlet.tigris.org Subject: media type adaptor I'm new to restlets and would like some feedback from the community on some experimentation. Instead of if/else'ing through the list of variant types and calling the appropriate logic, I'd like reslets to do that for me. The example "MediaType" below is similar to the restlet version, except that each enumeration overrides a call back, for example, the text/html type calls back to handleTextHTML(). TEXT_HTML("text/html", "HTML document") { @Override public Representation callBack(VariantHandler arg0) { return arg0.handleTextHTML(); } }, The application developer then extends a resource from BaseResource, and implements the methods they'd like to handle. (like the AWT MouseEvent adaptors of old) The examples are not complete, I only implmented 4 media types. The BaseResource gets the media type, converts to the appropriate extended MediaType, and the invokes the callback. @Override public Representation represent(Variant variant) throws ResourceException { String mediaType = variant.getMediaType().getName(); return MediaType.value(mediaType).callBack(this); } So to handle HTML, the developer just does this: @Override public Representation handleTextHTML() { // here's where we respond to HTML clients. } http://restlets.s3.amazonaws.com/VariantHandler.java http://restlets.s3.amazonaws.com/BaseResource.java http://restlets.s3.amazonaws.com/MediaType.java -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022252
RE: Retrieving the UriTemplate associated to a Resource class
Fabio, I had asked this question as well. The answer is to do this: final Router router = new Router(getContext()) { @Override public Restlet getNext(final Request request, final Response response) { final Restlet result = super.getNext(request, response); if (result instanceof Route) { final Route route = (Route) result; final String uriPattern = route.getTemplate().getPattern(); s_logger.log(Level.INFO,"User requested route: " + uriPattern); request.getAttributes().put(TEMPLATE_URI_PATTERN_ATTRIBUTE, uriPattern); } return result; } }; You can then get the value with request.getAttribute Cliff Binstock Coyote Reporting > -Original Message- > From: Fabio Mancinelli [mailto:fabio.mancine...@gmail.com] > Sent: Wednesday, January 07, 2009 8:07 AM > To: discuss@restlet.tigris.org > Subject: Retrieving the UriTemplate associated to a Resource class > > Dear all, > > I have already implemented this by building additional infrastructure, but > I was wondering if, from inside a Resource, there is a way for retrieving > which UriTemplate is associated to a given Resource class. > > To be more explicit: > > In application: > router.attach("/myResource", MyResource.class) > > In MyResource I would like to have something like: > getUriTemplateFor(MyResource.class) -> "/myResource" > > I digged a bit into the API but I haven't find anything like this. > > Thanks, > Fabio > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=101 > 0096 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022243
RE: REQUEST FireFox cache control
Wow. Thanks for the great, detailed response. I will look at the "non-standard header mechanism." And . I concur with you that IE isn't always right. Or worse, for things that you would think would be "basic" (like content-types, and cache control)-or at least handled consistently by 2008-IE, FF, Opera (and most certainly all others) have different ideas. Cliff Binstock Coyote Reporting _ From: Rob Heittman [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 6:48 PM To: discuss@restlet.tigris.org Subject: Re: REQUEST FireFox cache control Hi Cliff, Jerome is on holiday, so I'll take a shot at this; if I'm wrong, Thierry will take a shot at me :-) I'm pretty sure that the "transient" property is only useful to identify entities that can only be consumed once; for example, stream-based representations. I don't think they do or are meant to influence cache behavior in any way. This RFE tracks the idea of introducing caching support to Restlet (both internally, and influencing client side cache behavior): http://restlet.tigris.org/issues/show_bug.cgi?id=25 Interesting work is scheduled to happen on this in the near future. At present, you must set the Cache-Control header directly using the non-standard header mechanism: http://www.restlet.org/documentation/1.1/api/org/restlet/data/Message.html#g etAttributes() This will produce a warning, I think (unless it was turned off recently) but will get the desired effect. I was hoping to propose a patch in the 1.1 timeframe that would directly support the Cache-Control header without yet conquering the rest of RFE 25, but did not get around to it. I still think this is worth doing in a 1.1 incremental release -- it's a common, common need. http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-and-ie-caching/ I read this article and, while I think its technical statements are correct, it seems to have been written from the perspective that IE's behavior is per spec, which I feel it is not. <http://blog.httpwatch.com/2008/10/15/two-important-differences-between-fire fox-and-ie-caching/> (which is hopefully correct), FF will only respond as expected if you also set "no-store". In otherwords, "Cache-control: no-cache no-store". See sections 14.9.1 and 14.9.2 of the HTTP 1.1 RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 "no-cache" will stop FF from storing the page in the disk cache for subsequent requests -- but you can still generally hit the back button to return to the page as originally seen. You must use "no-store" if you mean to avoid disclosure of sensitive information, not store the page anywhere including the memory cache, and to reload it on any redisplay. I feel that this behavior tracks the RFC text more accurately; IE has it wrong by not using "no-store" for this purpose. Depending on what you mean to happen, you should use the appropriate thing. I use "no-store" on pages that absolutely must not be reloaded for any reason, but generally use "no-cache" for good performance combined with good "liveness" of content. - R -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981752
REQUEST FireFox cache control
It appears that Firefox doesn't respect expiration date or cache-control properly. I would like most/all of my routes to expire immediately (and require a reload). I'm guessing that Representation#setTransient sets the "Cache-control: no-cache" for the return headers. However, according to http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firef ox-and-ie-caching/ (which is hopefully correct), FF will only respond as expected if you also set "no-store". In otherwords, "Cache-control: no-cache no-store". REQUEST: Perhaps the indirect effect of "setTransient" could set both of these? Could someone point me to where the effect of #isTransient actually does something to the header? Thanks much, Cliff -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981380
Simple "Reference" suggestion
Another Restlet suggestion: The Reference class should definitely have a #toURI method. It should possibly also have a URI constructor. Thanks, Cliff -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=981233
RE: Restlet "Directory" suggestion
Jerome, Inline ... > Thanks for the good feed-back on Directory. > > 1) Could you give more information/pointers? What do you want to transform > with XSLT, the directory listing? Yes, the directory listing. While quite obtuse, in Tomcat there is a built-in XML directory listing to which you can apply a stylesheet. Perhaps you could automatically return different variants? > 3) You could add a Guard filter in front of your Directory that would deal > with that, unless the authorization is based on the actual file. Could you > detail your use case a bit more? The basic guard isn't friendly enough. If I have users 'John', 'Fred', and 'Alice', I'd like to have /user/John; /user/Fred; /user/Alice. Each person has access only to their own directory (or perhaps some other complex authorization like groups). Cliff
Restlet "Directory" suggestion
Thierry, et al, I have been working with the "Directory" class, and running into limitations. I realized that because I am also running Tomcat, the built-in webdav met my needs. However--and because you were asking for suggestions--I realized that the Directory class could easily be improved: 1) Allow for stylesheets, see Tomcat's WebdavServlet setup (localXsltFile, and globalXsltFile). Note that a URI (instead of a path) would be even better. 2) Have the default representation return XHTML (instead of the current nonX HTML). This would allow a programmatic caller to read the list as XML (a request from one of my users). 3) Add a simple authorization hook, or at least clearly describe how to authorize access to certain directories. Note that even in Tomcat, I had to go digging through the code to figure out how to subclass. 4) Add full webdav capability. Given that WebdavServlet is Apache License--and not very big--it seems that you could easily support full webdav out of the box. Cliff Binstock Coyote Reporting
RE: Usurping Directory
As an upgrade (Restlet request!), looking through the source code it seems that the simplest thing would be if I could insert my own ReferenceList implementation. Perhaps you could have a #setReferenceList option which would take my own (sub-)class. Not only could I change the HREF, but it would be great to put in my own HTML representation anyway, with style, logo, etc. Cliff _ From: Cliff Binstock [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 2:54 PM To: discuss@restlet.tigris.org Subject: Usurping Directory I would like to modify the standard Directory to return something different than "the" file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the "bottom" (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom "DirectoryResource" which is attached to a "Directory" via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
RE: routes with URIs
Intriguing. Never even occurred to me that something as simplistic as NOT encoding might work. This is great, but doesn't mesh nicely with the rest of REST, since of course what I really want is: /urls/{url}/foo/bar And there would be no way to know where the end of the embedded URL was, and the beginning of the rest of the route (/foo/bar) was: http://localhost:9876/toto?url=http://www.example.com/foo.xml/foo/bar?a=1&b= 2 Cliff > -Original Message- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Monday, November 10, 2008 2:25 AM > To: discuss@restlet.tigris.org > Subject: RE: routes with URIs > > > Hi Cliff, > > I have just done a simple test, typing this URI in Firefox 3: > http://localhost:9876/toto?url=http://www.example.com/foo.xml?a=1&b=2 > > On the server, I just return as an entity the URI entered, which displayed > exactly the same value in the browser. > > Then, I tried this: > http://localhost:9876/toto/url/http://www.example.com/foo.xml?a=1&b=2 > > And it displayed the same value again, both in FF3 and IE7. See attached > server code. > > I guess you are encountering encoding issue at other levels. Maybe in your > HTML page that is initially sent to your browser. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : Cliff Binstock [mailto:[EMAIL PROTECTED] > Envoye : vendredi 31 octobre 2008 21:30 > A : discuss@restlet.tigris.org > Objet : routes with URIs > > To all, > > Wondering if anyone has any experience or great ideas: > > I have a need to specify URLs (not the uri-pattern) when fetching > Resources. > > A simple degenerate case is this: > > /urls/{url} > > Where {url} points to some random place on the web. While I have thought > of > a number of workarounds, I can't come up with an elegant solution. As a > point of reference, a URL encoded URL doesn't seem to work with most > browsers. You might, for example, think that this: > http://www.example.com/foo.xml > Might turn into this: > http%3A%2F%2Fwww.example.com%2Ffoo.xml > or more precisely, for the aforementioned route: > /urls/http%3A%2F%2Fwww.example.com%2Ffoo.xml > > But again, most browsers (at least IE and Firefox) aren't happy about > this. > > So far I've thought of solutions like: >* POST >* Require something besides "/" delimiter >* Pre-cache using something else (with POST), like /specify-url ... >* Use some sort of (non-standard) encoding > > Has anyone had to do anything similar? Or any ideas on a user-friendly > solution? > > > Thanks in advance, > > Cliff
Usurping Directory
I would like to modify the standard Directory to return something different than "the" file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the "bottom" (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom "DirectoryResource" which is attached to a "Directory" via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
routes with URIs
To all, Wondering if anyone has any experience or great ideas: I have a need to specify URLs (not the uri-pattern) when fetching Resources. A simple degenerate case is this: /urls/{url} Where {url} points to some random place on the web. While I have thought of a number of workarounds, I can't come up with an elegant solution. As a point of reference, a URL encoded URL doesn't seem to work with most browsers. You might, for example, think that this: http://www.example.com/foo.xml Might turn into this: http%3A%2F%2Fwww.example.com%2Ffoo.xml or more precisely, for the aforementioned route: /urls/http%3A%2F%2Fwww.example.com%2Ffoo.xml But again, most browsers (at least IE and Firefox) aren't happy about this. So far I've thought of solutions like: * POST * Require something besides "/" delimiter * Pre-cache using something else (with POST), like /specify-url ... * Use some sort of (non-standard) encoding Has anyone had to do anything similar? Or any ideas on a user-friendly solution? Thanks in advance, Cliff
RE: Router swallowing exceptions
I am using V1.1 RC2 Cliff Binstock _ From: Thierry Boileau [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 2:33 AM To: discuss@restlet.tigris.org Subject: Re: Router swallowing exceptions Hello Cliff, I get an Instantiation exception with a warning trace when running with the current trunk. ATTENTION: Exception while instantiating the target handler. java.lang.InstantiationException at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Instan tiationExceptionConstructorAccessorImpl.java:30) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.restlet.Finder.createTarget(Finder.java:186) [...] What release of Restlet are you using? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org <http://www.restlet.org/> Noelios Technologies ~ Co-founder ~ http://www.noelios.com <http://www.noelios.com/> I unfortunately accidentally discovered that if a "Resource" is not instantiable (e.g., the class is abstract, constructor is protected, etc.), the router-which is unable to complete its work-does "nothing" and doesn't log anything either It would be most appreciated if it would log a (probably SEVERE) error if it was unable to instantiate the Resource. For example, if you have this: attach(router, "/not-instantiable", com.example.resource.MyAbstractResource.class); and of course: package com.example.resource; public abstract class MyAbstractResource extends Resource { . } Thanks much, Cliff Binstock Coyote Reporting
Router swallowing exceptions
I unfortunately accidentally discovered that if a "Resource" is not instantiable (e.g., the class is abstract, constructor is protected, etc.), the router-which is unable to complete its work-does "nothing" and doesn't log anything either It would be most appreciated if it would log a (probably SEVERE) error if it was unable to instantiate the Resource. For example, if you have this: attach(router, "/not-instantiable", com.example.resource.MyAbstractResource.class); and of course: package com.example.resource; public abstract class MyAbstractResource extends Resource { . } Thanks much, Cliff Binstock Coyote Reporting
Form Processing bug?
I believe there is something wrong, or at least unpleasant in the Restlet Engine (V1.1 RC2). I am using the "language" as a form input. I have a simple test case (below) which mimics the form input. Input of this: http://localhost:8080/test?lang=all <http://localhost:8080/xbrlet/test/test?lang=all&language=all&xyz=all> &language=all&xyz=all Provides (expected): Test Form Data: lang = all xyz = all language = all But, input of this: http://localhost:8080/test?lang=fr <http://localhost:8080/test?lang=fr&language=fr&xyz=fr> &language=fr&xyz=fr Provides (unexpected): Test Form Data: lang = fr xyz = fr (note missing "language = fr "text). Random sampling: It works for language="it", and "de", but not "en" or "fr". Is there something special about the language name? I can of course use some other name, but I spent hours tracing this down. I have tried it in Tomcat (my standard environment) and standalone. Here's the quick test code, pasted basically into your HelloWorldResource example: @Override public Representation represent(final Variant variant) { final Form form = getRequest().getResourceRef().getQueryAsForm(); final StringBuffer formsb = new StringBuffer(); if (form != null) { formsb.append("Form Data:\n"); for (String name : form.getNames()) { final String value = form.getFirstValue(name); formsb.append("\t"); formsb.append(name); formsb.append(" = "); formsb.append(value); formsb.append("\n"); } } final Representation representation = new StringRepresentation("Test " + formsb.toString(), MediaType.TEXT_PLAIN); final Response response = getResponse(); response.setStatus(Status.SUCCESS_OK); return representation; } Cliff Binstock Coyote Reporting
RE: uriPattern exactness
Jérôme, I suppose I could specialize the Routerit hadnt occurred to me. For better or worse it seemed logical to me to use the standard router, and have a Resource dynamically binding the behaviors. The key is that the behaviors come in a handful of flavors, so I have a behavior interface and factory. You are right that I could move the abstraction up a level, I suppose. Note that some URIs are bound in a fixed standard way to the Router. The other advantage to the current approach is that there is just a very lightweight controller (a Resource), between the standard Router, and my standard behaviors. You can completely change the way the router works, or I can completely change the way the behaviors work, and maintenance on the controller is minimal. If I get to dynamically binding the URIs (user-specified routes), I will keep in mind if subclassing the Router is better or not. Frankly, the current controller would work just fine, the only issue is attaching/detaching the router on the fly, which on the surface doesnt really seem problematic. Cliff Binstock Coyote Reporting _ From: Jerome Louvel [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2008 12:47 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness Hi Cliff, Aren't you trying to develop a specialized Router? Router can be dynamically modified by adding/removing routes at runtime. If your routers (pattern + target resource) are externalized in an XML file, you could regularly look for changes and either: * update the existing router to match the changes * create a new router, configure it and plug it as a replacement of the previous one In the first case, you could simply write a Router subclass that would be very reusable. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _ De : Erik Beeson [mailto:[EMAIL PROTECTED] Envoyé : mardi 21 octobre 2008 00:23 À : discuss@restlet.tigris.org Objet : Re: uriPattern exactness In what scenario (other than maybe development) do your routes change at runtime? --Erik On Mon, Oct 20, 2008 at 2:44 PM, Cliff Binstock <[EMAIL PROTECTED]> wrote: Jérôme, I thought of another reason why it would be *really nice* to know the matching URI pattern: I would like to be able to dynamically determine how to handle a resource request from a configuration. To simplify my actual use case, suppose for example that I implemented a default resource, and the default resource could look at, say, an external XML configuration file to determine which class to really call (dynamically). This external configuration might look like: /foo/{foos}/bar com.coyotereporting.foo.Bar Right now, I can see how to use the above to dynamically define *resources* once on startup, but not how to "abstract" this one level to have the default resource call different handlers on the fly. So, if I can add to the long term request list: 1) Get back the original URI (e.g., /foo/{foos}/bar) 2) Get back the "as-matched" URI (e.g., /foo/myFoo/bar). Note that #1 above (original URI Pattern), would enable a very flexible default handler. Cliff Binstock Coyote Reporting > -Original Message- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2008 4:02 AM > To: discuss@restlet.tigris.org > Subject: RE: uriPattern exactness > > > Hi Cliff, > > In combination with MODE_EQUALS, you could also add a variable for your > extensions like: "/foos/{foo}/bar.{ext}". That could reduce the number of > alternative routes you would have to attach. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : Cliff Binstock [mailto:[EMAIL PROTECTED] > Envoye : vendredi 17 octobre 2008 01:28 > A : discuss@restlet.tigris.org > Objet : RE: uriPattern exactness > > Aron, > > Thanks, I didn't realize this was here. This would potentially work, and > I > may end up using it. > > Frankly, I want to be able to "have my cake and eat it too". An exact > match > using this construct would work, but would also force me to itemize every > possible variation of a path via router.attach(). I was hoping to do some > "fuzzy" enforcement in a base "Resource" class. > > Cliff Binstock > Coyote Reporting > > > > > > -Original Message- > > From: Aron Roberts [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 16, 2008 11:37 AM > > To: discuss@restlet.tigris.org > > Subject: RE
RE: uriPattern exactness
Thierry, This works great, thank you very, very much! I now have fully dynamic behaviors. Can I suggest that you make this a standard attribute? Regardless, this works for me. Cliff Binstock Coyote Reporting _ From: Thierry Boileau [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2008 12:26 AM To: discuss@restlet.tigris.org Subject: Re: uriPattern exactness Hi Cliff, as a workaround, you can derive the Router class and override the "getNext" method. It will give you access to the route, and then the matched pattern: Router router = new Router(getContext()) { @Override public Restlet getNext(Request request, Response response) { Restlet result = super.getNext(request, response); if (result instanceof Route) { Route route = (Route) result; request.getAttributes().put("pattern", route.getTemplate().getPattern()); } return result; } }; By doing so, you're able to update the request and include the pattern as an attribute. Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org <http://www.restlet.org/> Noelios Technologies ~ Co-founder ~ http://www.noelios.com <http://www.noelios.com/> Jérôme, I thought of another reason why it would be *really nice* to know the matching URI pattern: I would like to be able to dynamically determine how to handle a resource request from a configuration. To simplify my actual use case, suppose for example that I implemented a default resource, and the default resource could look at, say, an external XML configuration file to determine which class to really call (dynamically). This external configuration might look like: /foo/{foos}/bar com.coyotereporting.foo.Bar Right now, I can see how to use the above to dynamically define *resources* once on startup, but not how to "abstract" this one level to have the default resource call different handlers on the fly. So, if I can add to the long term request list: 1) Get back the original URI (e.g., /foo/{foos}/bar) 2) Get back the "as-matched" URI (e.g., /foo/myFoo/bar). Note that #1 above (original URI Pattern), would enable a very flexible default handler. Cliff Binstock Coyote Reporting -Original Message- From: Jerome Louvel [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 4:02 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness Hi Cliff, In combination with MODE_EQUALS, you could also add a variable for your extensions like: "/foos/{foo}/bar.{ext}". That could reduce the number of alternative routes you would have to attach. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Cliff Binstock [mailto:[EMAIL PROTECTED] Envoye : vendredi 17 octobre 2008 01:28 A : discuss@restlet.tigris.org Objet : RE: uriPattern exactness Aron, Thanks, I didn't realize this was here. This would potentially work, and I may end up using it. Frankly, I want to be able to "have my cake and eat it too". An exact match using this construct would work, but would also force me to itemize every possible variation of a path via router.attach(). I was hoping to do some "fuzzy" enforcement in a base "Resource" class. Cliff Binstock Coyote Reporting -Original Message- From: Aron Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 11:37 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness In the message "Re: uriPattern exactness", dated 2008-10-16, Cliff Binstock wrote: P.S. What is worse (maybe very confusing) is that this might match too: /foo/myFoo/bar/baz/bletch/fred.xml Again, I would like to forcefully ensure that this doesn't end up matching. From memory - by default, the mode for matching incoming URIs to your URI templates is 'starts with' rather than 'equals'. As Jerome wrote back in February 2008: In some cases, you might want to change this default mode, and this is easy to do via the "defaultMatchingMode" property on Router, or by modifying the "matchingMode" property of the template associated with the route created by the Router.attach() methods. For the modes, you can use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants." Here's one example of the latter: router.getTemplate().setMatchingMode(Template.MODE_EQUALS) Hope this is germane to your needs. Aron
RE: uriPattern exactness
Erik, Great question. Its not so much that the routes change at runtime (although I was contemplating user-configurable routingwouldnt that be intriguing!), but I want the behavior to change at runtime. Ultimately, we will allow users to define their own behaviors (you dont like the XML we return for one of the routes? Specify your own). The immediate (and most annoying) problem is that the web server Resources are extremely light weight, and we have a whole bunch of one-line Resource classes to call the corresponding behaviors, which is ridiculous, not to mention tedious, error prone, and a maintenance annoyance. Even today, all of the behavior-switching is taken care of by a single abstract class. Cliff Binstock Coyote Reporting _ From: Erik Beeson [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2008 3:23 PM To: discuss@restlet.tigris.org Subject: Re: uriPattern exactness In what scenario (other than maybe development) do your routes change at runtime? --Erik On Mon, Oct 20, 2008 at 2:44 PM, Cliff Binstock <[EMAIL PROTECTED]> wrote: Jérôme, I thought of another reason why it would be *really nice* to know the matching URI pattern: I would like to be able to dynamically determine how to handle a resource request from a configuration. To simplify my actual use case, suppose for example that I implemented a default resource, and the default resource could look at, say, an external XML configuration file to determine which class to really call (dynamically). This external configuration might look like: /foo/{foos}/bar com.coyotereporting.foo.Bar Right now, I can see how to use the above to dynamically define *resources* once on startup, but not how to "abstract" this one level to have the default resource call different handlers on the fly. So, if I can add to the long term request list: 1) Get back the original URI (e.g., /foo/{foos}/bar) 2) Get back the "as-matched" URI (e.g., /foo/myFoo/bar). Note that #1 above (original URI Pattern), would enable a very flexible default handler. Cliff Binstock Coyote Reporting > -Original Message- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2008 4:02 AM > To: discuss@restlet.tigris.org > Subject: RE: uriPattern exactness > > > Hi Cliff, > > In combination with MODE_EQUALS, you could also add a variable for your > extensions like: "/foos/{foo}/bar.{ext}". That could reduce the number of > alternative routes you would have to attach. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : Cliff Binstock [mailto:[EMAIL PROTECTED] > Envoye : vendredi 17 octobre 2008 01:28 > A : discuss@restlet.tigris.org > Objet : RE: uriPattern exactness > > Aron, > > Thanks, I didn't realize this was here. This would potentially work, and > I > may end up using it. > > Frankly, I want to be able to "have my cake and eat it too". An exact > match > using this construct would work, but would also force me to itemize every > possible variation of a path via router.attach(). I was hoping to do some > "fuzzy" enforcement in a base "Resource" class. > > Cliff Binstock > Coyote Reporting > > > > > > -Original Message- > > From: Aron Roberts [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 16, 2008 11:37 AM > > To: discuss@restlet.tigris.org > > Subject: RE: uriPattern exactness > > > > In the message "Re: uriPattern exactness", dated 2008-10-16, Cliff > > Binstock wrote: > > > > >P.S. What is worse (maybe very confusing) is that this might match > too: > > >/foo/myFoo/bar/baz/bletch/fred.xml > > >Again, I would like to forcefully ensure that this doesn't end up > > matching. > > > >From memory - by default, the mode for matching incoming URIs to > > your URI templates is 'starts with' rather than 'equals'. > > > > As Jerome wrote back in February 2008: > > >In some cases, you might want to change this default mode, and this > > >is easy to do via the "defaultMatchingMode" property on Router, or by > > >modifying the "matchingMode" property of the template associated with > > >the route created by the Router.attach() methods. For the modes, you > can > > >use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants." > > > >Here's one example of the latter: > > > > router.getTemplate().setMatchingMode(Template.MODE_EQUALS) > > > >Hope this is germane to your needs. > > > > Aron
RE: uriPattern exactness
Jérôme, I thought of another reason why it would be *really nice* to know the matching URI pattern: I would like to be able to dynamically determine how to handle a resource request from a configuration. To simplify my actual use case, suppose for example that I implemented a default resource, and the default resource could look at, say, an external XML configuration file to determine which class to really call (dynamically). This external configuration might look like: /foo/{foos}/bar com.coyotereporting.foo.Bar Right now, I can see how to use the above to dynamically define *resources* once on startup, but not how to "abstract" this one level to have the default resource call different handlers on the fly. So, if I can add to the long term request list: 1) Get back the original URI (e.g., /foo/{foos}/bar) 2) Get back the "as-matched" URI (e.g., /foo/myFoo/bar). Note that #1 above (original URI Pattern), would enable a very flexible default handler. Cliff Binstock Coyote Reporting > -Original Message- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2008 4:02 AM > To: discuss@restlet.tigris.org > Subject: RE: uriPattern exactness > > > Hi Cliff, > > In combination with MODE_EQUALS, you could also add a variable for your > extensions like: "/foos/{foo}/bar.{ext}". That could reduce the number of > alternative routes you would have to attach. > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -Message d'origine- > De : Cliff Binstock [mailto:[EMAIL PROTECTED] > Envoye : vendredi 17 octobre 2008 01:28 > A : discuss@restlet.tigris.org > Objet : RE: uriPattern exactness > > Aron, > > Thanks, I didn't realize this was here. This would potentially work, and > I > may end up using it. > > Frankly, I want to be able to "have my cake and eat it too". An exact > match > using this construct would work, but would also force me to itemize every > possible variation of a path via router.attach(). I was hoping to do some > "fuzzy" enforcement in a base "Resource" class. > > Cliff Binstock > Coyote Reporting > > > > > > -Original Message- > > From: Aron Roberts [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 16, 2008 11:37 AM > > To: discuss@restlet.tigris.org > > Subject: RE: uriPattern exactness > > > > In the message "Re: uriPattern exactness", dated 2008-10-16, Cliff > > Binstock wrote: > > > > >P.S. What is worse (maybe very confusing) is that this might match > too: > > >/foo/myFoo/bar/baz/bletch/fred.xml > > >Again, I would like to forcefully ensure that this doesn't end up > > matching. > > > >From memory - by default, the mode for matching incoming URIs to > > your URI templates is 'starts with' rather than 'equals'. > > > > As Jerome wrote back in February 2008: > > >In some cases, you might want to change this default mode, and this > > >is easy to do via the "defaultMatchingMode" property on Router, or by > > >modifying the "matchingMode" property of the template associated with > > >the route created by the Router.attach() methods. For the modes, you > can > > >use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants." > > > >Here's one example of the latter: > > > > router.getTemplate().setMatchingMode(Template.MODE_EQUALS) > > > >Hope this is germane to your needs. > > > > Aron
RE: uriPattern exactness
John and Jérôme, Thanks much, this is *exactly* what I need! Cliff > -Original Message- > From: John D. Mitchell [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2008 7:54 AM > To: discuss@restlet.tigris.org > Subject: Re: uriPattern exactness > > On Friday 2008.10.17, at 04:01 , Jerome Louvel wrote: > [...] > > In combination with MODE_EQUALS, you could also add a variable for > > your > > extensions like: "/foos/{foo}/bar.{ext}". That could reduce the > > number of > > alternative routes you would have to attach. > > Yes and no. I use that trick but I still have to also have e.g.: > /foos/{foo}/bar > as well since the dot shouldn't be there if there's no extension. When > I last looked, I couldn't find any way to make things optional (so if > it's still not possible to do that in the latest versions, I'd suggest > looking into it -- something like /bar(.{ext})? so that it hangs > together properly). > > FWIW, I do send both to the same resource and just have the resource > look for the optional parts. e.g.: > ext = (String) request.getAttributes().get("ext"); > if (null == ext) > ext = ""; > > I've also used a combination of EQUALS and the default STARTS_WITH to > keep the numbers of routes a bit more manageable. > > Take care, > John
RE: uriPattern exactness
Aron, Thanks, I didn't realize this was here. This would potentially work, and I may end up using it. Frankly, I want to be able to "have my cake and eat it too". An exact match using this construct would work, but would also force me to itemize every possible variation of a path via router.attach(). I was hoping to do some "fuzzy" enforcement in a base "Resource" class. Cliff Binstock Coyote Reporting > -Original Message- > From: Aron Roberts [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2008 11:37 AM > To: discuss@restlet.tigris.org > Subject: RE: uriPattern exactness > > In the message "Re: uriPattern exactness", dated 2008-10-16, Cliff > Binstock wrote: > > >P.S. What is worse (maybe very confusing) is that this might match too: > >/foo/myFoo/bar/baz/bletch/fred.xml > >Again, I would like to forcefully ensure that this doesn't end up > matching. > >From memory - by default, the mode for matching incoming URIs to > your URI templates is 'starts with' rather than 'equals'. > > As Jerome wrote back in February 2008: > >In some cases, you might want to change this default mode, and this > >is easy to do via the "defaultMatchingMode" property on Router, or by > >modifying the "matchingMode" property of the template associated with > >the route created by the Router.attach() methods. For the modes, you can > >use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants." > >Here's one example of the latter: > > router.getTemplate().setMatchingMode(Template.MODE_EQUALS) > >Hope this is germane to your needs. > > Aron
RE: uriPattern exactness
P.S. What is worse (maybe very confusing) is that this might match too: /foo/myFoo/bar/baz/bletch/fred.xml Again, I would like to forcefully ensure that this doesn't end up matching. Cliff Binstock Coyote Reporting _ From: Cliff Binstock [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 8:54 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness Thierry, Actually what I want to do, sometimes, is abort the processing.(and probably return a "Not Found" error). Right now, the caller can use a somewhat "garbage" uri, and the uriPattern will match. Note that I want to be very selective, because I want to match, for example "./bar.xml", but probably not "./barlksjfljj.xml". Thanks. Cliff Binstock Coyote Reporting _ From: Thierry Boileau [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 2:27 AM To: discuss@restlet.tigris.org Subject: Re: uriPattern exactness Hi Cliff, I'm sorry, but I think I miss your question. ;) What do you want to do? What kind of entity will handle the data: "the exact matched pattern for "/foos/myFoo/barlksjfljj.xml" "? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org <http://www.restlet.org/> Noelios Technologies ~ Co-founder ~ http://www.noelios.com <http://www.noelios.com/> I was wondering if there is some trick way to find the exact matched pattern. Specifically, I am seeing this (somewhat logical) behavior. If the uriPattern is "/foos/{foo}/bar" This of course matches something like "/foos/myFoo/barlksjfljj.xml" What I want is: If I type in "/foos/myFoo/barlksjfljj.xml", I could determine that "/foos/myFoo/bar" was the actual match. Maybe I just missed an existing API call? :) Thanks much in advance, Cliff Binstock
RE: uriPattern exactness
Thierry, Actually what I want to do, sometimes, is abort the processing.(and probably return a "Not Found" error). Right now, the caller can use a somewhat "garbage" uri, and the uriPattern will match. Note that I want to be very selective, because I want to match, for example "./bar.xml", but probably not "./barlksjfljj.xml". Thanks. Cliff Binstock Coyote Reporting _ From: Thierry Boileau [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 2:27 AM To: discuss@restlet.tigris.org Subject: Re: uriPattern exactness Hi Cliff, I'm sorry, but I think I miss your question. ;) What do you want to do? What kind of entity will handle the data: "the exact matched pattern for "/foos/myFoo/barlksjfljj.xml" "? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org <http://www.restlet.org/> Noelios Technologies ~ Co-founder ~ http://www.noelios.com <http://www.noelios.com/> I was wondering if there is some trick way to find the exact matched pattern. Specifically, I am seeing this (somewhat logical) behavior. If the uriPattern is "/foos/{foo}/bar" This of course matches something like "/foos/myFoo/barlksjfljj.xml" What I want is: If I type in "/foos/myFoo/barlksjfljj.xml", I could determine that "/foos/myFoo/bar" was the actual match. Maybe I just missed an existing API call? :) Thanks much in advance, Cliff Binstock
uriPattern exactness
I was wondering if there is some trick way to find the exact matched pattern. Specifically, I am seeing this (somewhat logical) behavior. If the uriPattern is "/foos/{foo}/bar" This of course matches something like "/foos/myFoo/barlksjfljj.xml" What I want is: If I type in "/foos/myFoo/barlksjfljj.xml", I could determine that "/foos/myFoo/bar" was the actual match. Maybe I just missed an existing API call? :) Thanks much in advance, Cliff Binstock