The trick (I believe) is that the url should be parsed from right to
left, not left to right. I don't think it's a hijack; for the
application I'm working on context is very important so knowing that a
given resource is being accessed in the context of another resource
has a big part to play in dictating which functions should be
available and how they behave. (The book/chapter model is just an
example I used to try and simplify the problem).
Jeromy, I'm still really struggling to get this going, I don't suppose
you've found time to knock up that demo app?
Thanks in advance,
Mike
2008/7/6 dusty <[EMAIL PROTECTED]>:
>
> This doesn't seem right. How can you distinguish between something like
> /book/1/customMethod and /book/1/chapter? Is it smart enough to see that
> chapter is a mapped action and customMethod is not and change what it
> invokes? If it works then great, but doesn't it feel like a hijack?
>
> As I look at apps in Struts and Rails I realize that I really don't ever
> need to address a child resource with something like /books/1/chapters/1.
> That is because the :id property for chapter is unique and so you just
> address chapters with /chapters/1. Most of the time, once I get a child I
> can figure out who the parent is in the action rather than relying on the
> url to tell me. I suppose that if :id is not unique for chapter and is some
> kind of composite that requires the book id in order to look the chapter up
> then you need both pieces of information, but that is an exception case,
> right?
>
> Either way, I am definitely interested on how Jeremy got this to work using
> namespaces. Are you using Codebehind or Convention Jeremy?
>
>
> Jeromy Evans - Blue Sky Minds wrote:
>>
>> Mike Watson wrote:
>>> Hi Jeromy,
>>>
>>> I've finally found time to try to resolve this but haven't had much luck.
>>>
>>> Just to recap, I'm looking to be able to do something similar to the
>>> following:
>>> /book -> returns a list of books
>>> /book/123 -> returns book with id 123
>>> /book/123/chapter/1 -> return chapter with id 1, retrieved from book
>>> 123 (this is a simplistic example, all resources have a unique ID)
>>>
>>> I'd also like to be able to control access based on the
>>> context/namespace used to access a resource e.g.:
>>> /logo/abc -> read or update
>>> /book/123/logo/abc -> read only
>>> (would I need multiple LogoControllers for this?)
>>>
>>> Using Namespaces as described by Jeromy below certainly seems to make
>>> sense but as soon as I start to try the example provided I lose the
>>> ability to GET /book/123, and I've tried with BookController having
>>> namespace of "/" or "/book" and neither works. And so far I haven't
>>> been able to successfully hit the ChapterController using a url like
>>> /book/123/chapter.
>>>
>>> Am I missing something really obvious? Is there something I need to
>>> put in the struts.xml to configure the namespaces as well as using the
>>> @Namespace annotation?
>>>
>>> Jeromy, you seem to be pretty knowledgeable about this - can you think
>>> of anything I might be doing wrong?
>>>
>>> Thanks in advance for your help.
>>>
>>> Mike
>>>
>>>
>>
>> Hi Mike, I'll throw a quick answer together now and try to give you a
>> more in-depth one in a day or two by building an example.
>>
>> The steps are:
>> 1. ensure struts is up-to-date. (2.1.3-SNAPSHOT preferably, to ensure
>> you have the latest ActionMappingParamsInterceptor)
>> 2. enable the NamedVariablePatternMatcher via struts.xml
>> 3. Create the BookController in the root namespace. GET /book/123 will
>> invoke BookController.show() with id=123
>> 4. Create the ChapterController in the namespace containing the book id
>> variable (/book/{bookid}). GET /book/123/chapter will invoke
>> ChapterContoller.index() with bookId=123.
>>
>> ie.
>>
>> @Namespace("/")
>> public class BookController implements ModelDriven<Book> { }
>>
>>
>> @Namespace("/book/{bookId}")
>> public class ChapterController implements ModelDriven<Chapter> { }
>>
>>
>> Now that's what *should* happen. I use it in a large application that
>> includes many other related tweaks so I'll throw together a vanilla
>> sample and post it somewhere.
>>
>> I'll come back to the authorization issue separately. The quick answer
>> is that you can omit methods that are never permitted and/or filter URLs
>> based on a URI pattern and/or user's role.
>>
>> regards,
>> Jeromy Evans
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/REST-plugin-URL-syntax-tp17855192p18298747.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
