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: <entry> <matching-uri-pattern>/foo/{foos}/bar</matching-uri-pattern> <invoke>com.coyotereporting.foo.Bar</invoke> </entry> 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
