On 3/25/07, Brad Smith <[EMAIL PROTECTED]> wrote:
Thanks Kito. I was also considering a servlet filter approach but am
leaning towards a custom Processor implementation based on Shale's
remoting as you and Rahul recommend.
My only lingering concern is the need to have the url end in the same
extension that the JSF servlet is expecting (html in this case). I
suppose I could append an "index.html" on every URL but that has a
slight code "smell". :)
That is Remoting (and JSF) will require
http://localhost:8080/myapp/projects/office2/index.html
instead of
http://localhost:8080/myapp/projects/office2
in order to properly process the request.
Perhaps
http://localhost:8080/myapp/projects/office2.html
might be a little better?
Shale Remoting will get you part ways towards RESTful URLs with JSF,
but by no means all the way. One thing you'll find, for example, is
that Shale Remoting dispenses with the idea of saving and restoring
the state of the component tree, because the use case it was designed
for (back end of Ajax transactions or static resource retrieval) does
not need this.
It would be an interesting idea to contemplate exactly what it would
take to create an environment that creates RESTful URLs as simply as,
say, recent Rails versions can do it. My bet is this wouldn't take a
large amount of code ... in the mean time, you can probably get quite
a ways.
Craig
Brad
On Sat, 2007-03-24 at 17:24 -0400, Kito D. Mann wrote:
> Brad,
>
> I often use a Servlet filter for this type of stuff, but a cleaner approach
> might be to use Shale Remoting (http://shale.apache.org/remoting). The
> process() method in your MethodBindingProcessor
> (http://shale.apache.org/1.0.4/shale-remoting/apidocs/org/apache/shale/remot
> ing/impl/MethodBindingProcessor) implementation could load the projects, set
> the veiw id, and jump to the render response phase.
