I am not sure about that approach. On one hand it is very "strutsish", in that is supports many ways of doing the same thing, and provides ways to extend what is provided, on the other hand, I think we should learn from other frameworks and just don't give users that many options, for they can be confusing, and frustrating when there is not enough documentation.
Looking at ajax, and the ajax tags I think we have 2 kind of users: the power users, they won't use the ajax tag at all, unless they are doing something extremely simple. the beginners: they will use the ajax tags out of the box. When the beginners need to do something that is not provided by the tags out of the box, they start hacking away, and end up dumping the tags. So our target is the beginners, and they don't want customization, they just want to drop a few tags on their jsps and get it working. Based on that, I think we should either: don't provide any ajax tags at all, or just provide a very limited set of tags (like what Jeromy listed) with very little functionality to cover simple use cases, and use a reliable and simple framework for the implementation. Disregarding what path we take, I think it is fairly obvious that the Dojo plugin will end up unmaintained, that's why we should users know that we do not plan on upgrading from 0.4.3. musachy On Mon, Jul 21, 2008 at 10:24 PM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Musachy Barroso wrote: >> >> With all the problems/questions and time that the ajax tags have >> caused, and not having any takers on porting to the latest Dojo >> release. I would propose to deprecate, or even remove the Dojo plugin, >> or at least let users know that we will not be upgrading to a newer >> Dojo version anytime soon. I still like the idea of some *very* basic >> tags to cover the most simple use cases, but I think Dojo was not the >> right tool for the job. >> >> > > This is a BIG call. Although I share the sentiment, the ajax tags are an > often-stated "great feature" of S2. At least, that's what users comment > until they need to do something sophisticated with the underlying library. > > I suggest an approach which is consistent with the above, should be in line > with your thoughts Musachy and may even make Martin C happy: > > There are some core tags that must be provided/maintained by S2: > - remote div > - async submit of a form, targetting a div > - async get (anchor tag), targetting a div > > We'd still supply those as tags as a minimum in say an "ajax plugin". > > Rather than bundle ajax libraries with S2, we would only bundle a few > templates for integration of those tags with common libraries. We use the > existing theme's for this: > eg. > <s:submit theme="dojo" href="form.action"/> > <s:submit theme="yui" href="form.action"/> > <s:submit theme="jquery" href="form.action"/> > The templates implement the markup or inline javascript for a > default/reference implementation. > > The template for the s:head tag would include the default scripts to setup > the library. > <s:head theme="dojo"> will setup the bundled Dojo during the deprecated > period > <s:head theme="jquery"> will include jquery dependencies from a > default/overridden location (supplied by user). > The s:head tag would be optional, but the user will be responsible for > ensuring the library is available. > > Library-specific extensions for the tags would be specified via dynamic > attributes only. > > All other dojo widget tags would be deprecated (tabbedPanel, autocompleter). > > NOTE: > Ajax validation and client-side validation also deserve some discussion > later. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
