struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <...@fdar.com>
Subject Re: Struts2 jQuery Plugin - Logo
Date Mon, 27 Jul 2009 15:39:12 GMT
I haven't looked at the code for the jquery plugin yet, but I can offer
some insight into the problems with the dojo integration.  At the time
of writing, dojo was the most mature framework out there.  The problems
we encountered was with JS programming model that dojo used as well as a
strong integration due to the API, which caused problems when the API
changed.  This led to problems upgrading, and the code going dead. 
There were also always problems explaining how the use, and debug, the
tags.  Overall, not a great solution.

I'm glad someone stepped up to add ajax functionality to the framework
(since Philip was all words and no action :-)).  I believe this is
something that we need for greater adoption (something I've spoken to
Ted about in the past).  What I would want to make sure of, is that the
integration is more loosely coupled than the original dojo integration
(once again, not looked at the code).  I think this is important to
avoid the problems of the past.  But I do agree with Rene in that there
is a much better understanding of ajax and ajax frameworks today, which
will also help us, especially using jquery as a base technology.

/Ian


Rene Gielen wrote:
> That is what I also regognize from the disussions a while ago.
>
> We all know that the Dojo tags turned out as a nightmare. Dojo looked
> promising back in these days, with all it's supporters and some good
> solutions when there were only few alternative frameworks around.
> Nevertheless, not only the programming model was hard to get and to
> understand, also the API was in constant flux without ever coming to a
> stable state for years. Today we can consider Dojo as the biggest loser
> in the JS framework run.
>
> jQuery nowadays has turned out to be stable both in functionality and
> API stability, compact, fast, mature and easy to understand. It can
> really be considered as _the_ JS/AJAX framework besides Prototype, and
> the adoption is overwhelming. Many Java web delvelopers, including a
> couple a S2 community members I know of, have already incorporated plain
> jQuery into their projects and built up a good knowledge about it. Most
> of our "competitors" incorporate it either directly or via mature
> plugins, have a look at Myfaces, Richfaces, Icefaces or Wicket.
>
> My feeling was that there was a consensus that jQuery would be the way
> to go if we wanted to go provide a good AJAX solution, but we had not
> enough resources to build a plugin from scratch. Now Johannes stepped up
> and presented a complete plugin, and IMO we should see this as a great
> opportunity. If we don't want to fall terribly behind the other web
> frameworks, we need a decent and state of the art AJAX support - pure
> Web 1.0 interfaces are more and more going away, and people tend to
> judge a web framework for consideration in their projects also by it's
> AJAX capabilities - e.g. when Rainer and I did some Struts 2 talks the
> last couple of months for JUG Cologne, that was a very clear feedback we
> got from many people in the audience.
>
> Once the plugin is there, I don't see why it would be any harder to
> maintain than oher external library plugins we have, let's say Spring or
> Sitemesh or what not - especially since I suspect a lot of S2 developers
> and community members are using jQuery on regular basis and will be able
> to help with their experience. Also, we don't have to fear an API
> breaking with every minor release as we had with Dojo, which made
> maintaining it that hard.
>
> - René
>
> Musachy Barroso schrieb:
>   
>> A while back we said that we would remove the "ajax built in" from the
>> feature list if we didn't find a replacement for the Dojo tags. Some
>> work was done on a  jquery plugin by Wes, and I think I dropped 1 line
>> of code somewhere, but is hasn't got far, but we do want simple ajax
>> tags to replace the dojo ones.
>>
>> The way I see it, and I thought we were all in the same page, is that
>> we should have very simple ajax tags for the simple use cases, and not
>> go beyond that. The simple ajax tags is not the problem, the problem
>> is the library that we used to implement it which ended up creating a
>> bigger problem that it was supposed to fix.
>>
>> musachy
>>
>> On Fri, Jul 24, 2009 at 11:47 AM, Martin Cooper<martinc@apache.org> wrote:
>>     
>>> Whoa. Before we go rushing off gung ho to include this as part of Struts
>>> itself, shall we re-discuss the topic that, right now, applies to this
>>> plugin just as much as to the Dojo tags?
>>>
>>> I mean, of course, the fact that we specifically decided that we didn't want
>>> to support a specific AJAX library any more, as a part of the main Struts
>>> distribution. We didn't want to get ourselves into a situation in which we
>>> had a set of tags that relied on an external library that we would then be
>>> expected to support. We didn't want to have another AJAX plugin as part of
>>> Struts that a very small number, if any, of our committers could - and,
>>> especially, would - support on an ongoing basis.
>>>
>>> I'm not fundamentally opposed to bringing this in, but let's not get too
>>> goggle-eyed over this and forget all the issues that we've hit and discussed
>>> before. If we want to make a conscious decision to change our collective
>>> mind, so to speak, then OK, but let's be aware that that's what we seem to
>>> be talking about right now.
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>> On Fri, Jul 24, 2009 at 7:15 AM, Wes Wannemacher <wesw@wantii.com> wrote:
>>>
>>>       
>>>> I'd rather consider trying to bring this into the main struts distro.
>>>> I didn't look at the code, but if other devs are interested in this
>>>> route, we have to consider the following -
>>>>
>>>> IP Clearance
>>>> Our testing policy
>>>>
>>>> I think we can handle the IP clearance, as long as we know it's a step
>>>> we'd have to make. As I've said before on the testing policy, we'd be
>>>> better served to use selenium rather than JUnit to deal with an AJAX
>>>> plugin (just my opinion)...
>>>>
>>>> Anyone else have any thoughts?
>>>>
>>>> -Wes
>>>>
>>>> On Fri, Jul 24, 2009 at 10:06 AM, Johannes Geppert<jogep@web.de> wrote:
>>>>         
>>>>> Rene Gielen wrote:
>>>>>           
>>>>>> Brilliant work! I would love to see this integrated in S2 distribution,
>>>>>> if possible. Did you already setup a maven repo location for it?
If not,
>>>>>> let me know if you need help to add a repo space to your google code
svn
>>>>>> area.
>>>>>>
>>>>>>             
>>>>> I'am glad that you like the plugin. I don't have any experience with
>>>>>           
>>>> maven,
>>>>         
>>>>> so it will be nice if you can help me to add it to google code.
>>>>>
>>>>>
>>>>> -----
>>>>> ---
>>>>> web: http://www.jgeppert.com
>>>>> twitter: http://twitter.com/jogep
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>           
>>>> http://www.nabble.com/Struts2-jQuery-Plugin---Logo-tp24642384p24645147.html
>>>>         
>>>>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>           
>>>> --
>>>> Wes Wannemacher
>>>>
>>>> Head Engineer, WanTii, Inc.
>>>> Need Training? Struts, Spring, Maven, Tomcat...
>>>> Ask me for a quote!
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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