struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <mr...@twdata.org>
Subject Re: S2 as JSR for Action Framework
Date Mon, 25 Aug 2008 03:33:01 GMT
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

>
> --
> Martin Cooper
>
>
> This idea of a JSR would be standardizing the third group, but I
>> wonder if maybe the better direction to go is not a new API, but build
>> extensions on JAX-RS [2].  To me, this group's niche is apps that need
>> lightweight presentation engines a layer above servlets, but still
>> very much "web-y".  JSR 311 aims to make restful resources easy to
>> build, which isn't far from restful web applications.  Especially as
>> more and more applications are starting to rely on client-side AJAX
>> interfaces, the need for a solid RESTful backend only gets stronger.
>> The storage of server-side state of the component frameworks becomes
>> less important, and if you don't want the bulk of Grails, this
>> approach may be attractive.
>>
>> For my day job, we need to build REST interfaces to our web apps, so
>> we are looking to standardize on JAX-RS.  Well, we also need a
>> lightweight web framework for our plugin system, and if we are already
>> using something like Jersey [3], it would be nice to be able to write
>> web apps using the same technology.  This use case is obviously very
>> specific to our situation, but it is the direction I'll likely be
>> taking in the next few months.
>>
>> Don
>>
>> [1] http://www.source-code.biz/MiniTemplator/
>> [2] https://jsr311.dev.java.net/
>> [3] https://jersey.dev.java.net/
>>
>> On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <frans@meruvian.org> wrote:
>> > hi all
>> >
>> > is it possible that S2 become part of JCP?
>> >
>> > java server action framework
>> >
>> > right now only component framework there
>> >
>> > any idea?
>> >
>> >
>> >
>> > --
>> > --
>> > Frans Thamura
>> > Meruvian Foundation
>> >
>> > Mobile: +62 855 7888 699
>> > Linkedin: http://www.linkedin.com/in/fthamura
>> >
>> > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan...
>> > URL:
>> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>

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


Mime
View raw message