struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Fernandez <jordi.fernan...@esilog.com>
Subject Re: Re: S2 as JSR for Action Framework
Date Tue, 26 Aug 2008 22:14:27 GMT
Hi Musachy,

I've been using struts 2 with the REST plugin in several projects
and it's been great. It's really nice (thanks for the job, Don!).
I'd like to make the REST plugin more JSR-311 like, too. I've
been studying the struts2 source code for some days, focusing
on the REST and the Codebehind plugin. I've created a new plugin
based on the REST plugin source code + the ClasspathPackageProvider
class from the codebehind plugin. I was thinking in the following
implementation path for initial implementation of a subset of the spec:

- Process jsr-311 @Path annotation with ClasspathPackageProvider to 
configure
namespaces, packages, etc. to match requests to resource methods
- Create jsr-311 interceptors to process @MatrixParam, @QueryParam, 
@PathParam,
etc, annotations.

Am I on the right path? Any advices from the most experienced?

Thanks in advance.

Musachy Barroso wrote:
> What are the plans for the future of the REST plugin? Has anybody
> tried to make it more JSR-311 like? I am not a REST user myself, but I
> am kind of bored and could help if there was a clear understanding of
> what needs to be done.
> 
> musachy
> 
> On Mon, Aug 25, 2008 at 12:30 AM, Jeromy Evans
> <jeromy.evans@blueskyminds.com.au> wrote:
>> Don Brown wrote:
>>> On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <martinc@apache.org>
>>> wrote:
>>>
>>>> Another option is a client-side component-based framework like Ext or
>>>> Flex
>>>> running directly against web services, RESTful or otherwise. No
>>>> server-side
>>>> web framework required. Of course, you could use something server-side
>>>> like
>>>> DWR to facilitate working with web services, or Jersey for RESTful
>>>> services,
>>>> but that would be a choice rather than a requirement.
>>>>
>>> This is a nice design, when you can do it. GWT is also a good way to
>>> build these types of apps.  Unfortunately, they can easily break much
>>> of what makes the web what it is - the back button, unique,
>>> addressable URI's, accessibility, search engine crawling, etc.
>>> Therefore, I think some sort of server-side web framework will usually
>>> be necessary, however, I don't think it has to go so far as JSF, where
>>> they try to push all the state to the server.  I was talking with a
>>> guy here at work who is looking to start using GWT more about how and
>>> where a plain HTML view of the application fits.  He wants to do very
>>> dynamic, client-side heavy views, but still needs to support search
>>> engines and REST clients.  What if you use Jersey for your REST API,
>>> GWT or straight JQuery for your client-side UI, then have Jersey +
>>> something generate HTML views of your REST API, which you could use
>>> for search engines and developers wanting to browse and interact with
>>> your application.  If you can have the HTML representation of your
>>> REST API auto-generated, you wouldn't have to maintain two different
>>> interfaces, and you could go fully nuts with your client-side heavy
>>> app without having to worry about accessibility or search engine
>>> issues.
>>>
>>> Don
>>>
>>>
>>
>> [rant] Personally I think search engines need to solve this problem.  The
>> era of crawling sites needs to close.  As a publisher of content I should be
>> able to connect to a Google API and publish my content and URIs to them in a
>> standard machine-friendly format ready for indexing.  Alternatively, I could
>> implement a dedicated-service for them to consume instead of emulating pages
>> of content in a non-page-oriented application. Then my application then can
>> be what it needs to be in any form suitable for my users instead of
>> perpetuating the artificial SEO-optimzation industry. [/rant]
>>
>> Anyway, despite that, I took this approach recently with a client-heavy
>> (single page) application myself, with the exception of autogeneration of
>> the HTML.  Basically:
>> - mandated that the client include a custom header (X-RequestedBy) and
>> signature in the request
>> - if headers present, the S2 rest plugin handled the request and returned
>> the resource in the requested content type. I just had to build the view
>> myself for html.
>> - if the header's not present and it was a GET, the REST plugin returned the
>> HTML view and sitemesh decorated it as a full HTML PAGE.
>> - if a resource was requested directly and the user had javascript, they
>> were redirected to the rich client with the best-guess initial state based
>> on the URI
>> - all flow control is managed on the client.
>>
>> That meant that one action could service requests for the resource for rich
>> clients and support search engines requests for the same content.
>> Search engines could browse the site through the same content spread over
>> many little well-formed pages.
>> Users accessing the site via the search engine's sub-URI would see the rich
>> client with appropriate initial state derived from the URI
>> On the client-side sensible URIs could still be used in links and listeners
>> adjusted the content type when appropriate.
>>
>> Users without JS could get by but were a low priority.  Users with screen
>> readers are still a challenge but not due to struts.
>>
>> This approach wasn't as simple as it should be though but confirms that
>> Don's idea is feasible.  The biggest problem was in fact with IE6 memory
>> leaks and the poor performance of javascript in most browsers.  A flex
>> client could have used the same services without a problem.  If automation
>> of a bland html view with a sitemap were provided for users without
>> javascript/flash you'd eliminate the double-up on the views for search
>> engines.
>>
>> I definitely like the direction these discussions are going.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
> 
> 
> 

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


Mime
View raw message