Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of musachy@gmail.com designates
 209.85.198.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=c1wuEAN/BQO4PgU1MDYrFPC5nT/6BYlqtcW8X4NuRXhPmrQrqaov8l8rKxVoNIZCoh
         irzx5yxcx9WCzQQ29bC0RBcGVG2sHAy1+F1xyl8qovGR8TMt6jaCQr/aUEZmwzC0JoSi
         BJIOSsoSBNP9k+yyjeAMr2OOQ7l3cSzNve0bs=
Message-ID: <d8bdeb6f0808261522k2e6d0ec4xbbda6f57619e1ad7@mail.gmail.com>
Date: Tue, 26 Aug 2008 18:22:20 -0400
From: "Musachy Barroso" <musachy@gmail.com>
To: "Jordi Fernandez" <jordi.fernandez@esilog.com>
Subject: Re: Re: S2 as JSR for Action Framework
Cc: "Struts Developers List" <dev@struts.apache.org>
In-Reply-To: <48B48043.30207@esilog.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d8bdeb6f0808250626s48335470s3b339d51c446450c@mail.gmail.com>
	 <48B48043.30207@esilog.com>

That is pretty much what I had in mind, the only thing is that I would
suggest to look at the convention plugin instead, as that is what we
will be using, some day. The convention plugin is in then sandbox,
drop an email here if you need help finding your way around in the
code.

musachy

On Tue, Aug 26, 2008 at 6:14 PM, Jordi Fernandez
<jordi.fernandez@esilog.com> wrote:
> 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
>>>
>>>
>>
>>
>>
>


-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

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