You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mike Watson <mi...@gmail.com> on 2008/07/02 06:07:22 UTC

Re: REST plugin URL syntax

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

2008/6/18 Jeromy Evans <je...@blueskyminds.com.au>:
> Don Brown wrote:
>>
>> I believe it is technically possible to do this, but not at all
>> intuitive right now.  This is probably my number one improvement
>> request for the REST plugin.
>>
>> You should be able change the wildcard mapper to one that recognizes
>> named wildcards then use them in your namespace annotation like this:
>> @Namespace("/book/{bookId}")
>>
>>
>> Don
>>
>
> Yeah, I use this feature heavily to support URIs matching Mike's
> requirement.
>
> in struts.xml
> <bean type="com.opensymphony.xwork2.util.PatternMatcher"
> name="namedVariablePatternMatcher"
> class="com.opensymphony.xwork2.util.NamedVariablePatternMatcher"/>
>
> in *actions.*.ChapterContoller.java
> @Namespace("/book/{bookId}")
> public class ChapterController implements ModelDriven<Chapter> {
>
>  private void setBookId(Long id) {...}
>  private void setId(Long id) { ..}
>  private Chapter getModel() {...}
>
>  public HttpHeaders show() {
>   model = bookService.lookupChapter(bookid, id);
>   if (model != null) {
>     return new DefaultHttpHeaders("show");
>   } else {
>     return new DefaultHttpHeaders("error");
>   }
>  }
>  public HttpHeaders index() {...}
> }
>
> and
>
> in *actions.BookContoller.java
> @Namespace("/")
> public class BookController implements ModelDriven<Book> {  }
>
> regards,
> Jeromy Evans
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Mike Watson <mi...@gmail.com>.
Thanks heaps Jeromy, I'll grab the 2.1.3 snapshot and try again.

A vanilla sample app would be great (others would probably find it useful too).

Cheers

Mike

2008/7/3 Jeromy Evans <je...@blueskyminds.com.au>:
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Dave Newton <ne...@yahoo.com>.
--- On Thu, 7/10/08, Mike Watson <mi...@gmail.com> wrote:
> So what's the best way to get the latest 2.1.3 snapshot as source?

Via SVN.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Mike Watson <mi...@gmail.com>.
So what's the best way to get the latest 2.1.3 snapshot as source?
Only the jars seem to be in the maven snapshot repo...

Are there any instructions on doing that somewhere? I've looked but
can't find them...

2008/7/3 Jeromy Evans <je...@blueskyminds.com.au>:
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Mike Watson wrote:
>
> BTW, if I want a controller to work in multiple namespaces do I need
> to declare seperate packages in struts.xml instead of just relying on
> the @Namespace annotation?
>
> Thanks again for all your help.
>
>   

Unfortunately when using Codeheind, you do have to create a new package 
for each namespace. The easiest way to do that is to extend your action 
and add a @Namespace for each subclass.  It's wasteful but works.

The Convention Plugin that (eventually) supersedes Codeheind does 
include a @Namespaces() annotation.

Glad I could help!



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Mike Watson <mi...@gmail.com>.
Jeromy,

Thanks *heaps* for finfing the time to do that. I'd pretty much done
everything your demo does except for one little detail:

  <constant name="struts.patternMatcher" value="namedVariablePatternMatcher"/>

Doh!

Now to see if that's broken my fancy pants image handler...

BTW, if I want a controller to work in multiple namespaces do I need
to declare seperate packages in struts.xml instead of just relying on
the @Namespace annotation?

Thanks again for all your help.

2008/7/12 Jeromy Evans <je...@blueskyminds.com.au>:
> Jeromy Evans wrote:
>>
>>
>> Dusty, you're right. I just had a quick look and I do have a custom action
>> mapper that checks whether the pattern above references an action or method
>> for that exact reason (it checks the list of available actions and gives
>> precedence to those).  Works great for me.
>>
>> I released another actionmapper that solved the problem using a different
>> approach. It will be deprecated, but it's still up for info:
>> http://code.google.com/p/struts2urlplugin/
>
> I had an opportunity to throw together a sample application.  Apologies for
> the delay.
>
> Relevant source and commentary are included in the demo.
> http://www.blueskyminds.com.au/url-hierarchy/
>
> From the description:
> "This webapp demonstrates a technique to access resources with hierarchical
> relationships in Struts 2.
>
> The model is a Book with a list of Chapters. Each Book has a unique URI:
> eg. /book/1 (book #1)
>
> Each chapter also has a unique URI:
> eg. /book/1/chapter/2 (chapter #2 in book #1)
>
> Following Struts2 conventions, the list of books and list of chapters in a
> book are also available:
> eg. /book (list of books)
> eg. /book/1/chapter (list of chapters in book #1)
>
> regards,
> Jeromy Evans
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Jeromy Evans wrote:
>
>
> Dusty, you're right. I just had a quick look and I do have a custom 
> action mapper that checks whether the pattern above references an 
> action or method for that exact reason (it checks the list of 
> available actions and gives precedence to those).  Works great for me.
>
> I released another actionmapper that solved the problem using a 
> different approach. It will be deprecated, but it's still up for info: 
> http://code.google.com/p/struts2urlplugin/

I had an opportunity to throw together a sample application.  Apologies 
for the delay.

Relevant source and commentary are included in the demo.
http://www.blueskyminds.com.au/url-hierarchy/

 From the description:
"This webapp demonstrates a technique to access resources with 
hierarchical relationships in Struts 2.

The model is a Book with a list of Chapters. Each Book has a unique URI:
eg. /book/1 (book #1)

Each chapter also has a unique URI:
eg. /book/1/chapter/2 (chapter #2 in book #1)

Following Struts2 conventions, the list of books and list of chapters in 
a book are also available:
eg. /book (list of books)
eg. /book/1/chapter (list of chapters in book #1)

regards,
 Jeromy Evans



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Mike Watson wrote:
> 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,
>   

Sorry guys, I haven't had a chance to get back to this yet. 

Dusty wrote:

> This doesn't seem right.  How can you distinguish between something like
> /book/1/customMethod and /book/1/chapter? 



Dusty, you're right. I just had a quick look and I do have a custom 
action mapper that checks whether the pattern above references an action 
or method for that exact reason (it checks the list of available actions 
and gives precedence to those).  Works great for me.

I released another actionmapper that solved the problem using a 
different approach. It will be deprecated, but it's still up for info: 
http://code.google.com/p/struts2urlplugin/



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Mike Watson <mi...@gmail.com>.
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 <du...@yahoo.com>:
>
> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
> --
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by dusty <du...@yahoo.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 

-- 
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: REST plugin URL syntax

Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org