JQuery integration

[Musachy Barroso <mu...@gmail.com>]

> I definitely agree that a thoughtful design is the right starting place.
> Taking this to the extreme, one thing that I mentioned in my earlier post
> (without too much thought) was that perhaps some kind of standardized
> specification for binding ajax features to standard struts tags (including
> perhaps standardized widget tags - which may not be functional without the
> plugin) would be something worth thinking about as there are an increasing
> number of struts-ajax library integration each with their own integration
> mechanisms and syntax. Given the variety of ajax implementations, this might
> be ambitious at the moment, but definitely worth a thought. This would
> probably take the form of some kind of standardized <bind/> tag spec with
> specified behaviour for implementations.
>

I think we should keep simple, and down to JQuery. I don't think it is
worth the effort to go with some generic interface where multiple
libraries can be plugged in. IMO that would add more complexity, lots
of bugs and zillions of questions on the mailing lists(just supporting
one library has been hard). I would say the same thing about the
widgets, adding anything else beyond the jquery datepicker would be
too much.

> At the moment, I have taken the other route and integrated a few jquery
> ajax-enabled tags, but it shouldn't be too much work to switch these to a
> <bind/> tag implementation. So far, I have integrated the div, anchor,
> submit and tabbed pane tags (using a custom head tag to inject jquery
> dependencies). I have NOT implemented the full set of tag attributes for
> these that dojo provided, opting to start with the minimal, critical
> attributes first. For the binding I have implemented a very lightweight
> custom publish/subscribe jQuery extension framework which is one of the few
> things I really liked about the dojo framework. (I'll be sharing this once
> on jquery as well once well tested)
>

Topics is one of the things that would be very nice to have, and I
agree that we should start very small.


> Perhaps surprisingly, I have currently implemented the templates using the
> javatemplates plugin (not yet freemarker), simply because I've been too lazy
> to pick up the freemarker template syntax which I'm not very familiar with
> yet (this might be a great starting place for some collaborative help).

I really like JQuery's one-liners, so maybe it won't be that hard to
read in java code, if it get complex then I'd suggest swtiching to
FreeMarker.

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

Re: JQuery integration

[Wes Wannemacher <we...@wantii.com>]

On Wed, Feb 25, 2009 at 9:39 AM, Musachy Barroso <mu...@gmail.com> wrote:
>> On an aside, have you definitively decided to move the json interceptor and
>> result-type into the core?
>>
>
> Nobody seems to be against it, so I guess we just have to vote on it.
>
> musachy
>

There were no objections to the original thread about moving it to
core. I wasn't sure whether or not Musachy wanted to do it, or if it
became my job since I originally asked about it :)

Eric, my suggestion earlier was for the framework to make it easy...
Having a do-it-all tag for the model I suggested would simply invite
too many requests for customization, etc. I just figured that if we
consider it as a convention, then provide the documentation for how to
accomplish it, with tags that easily support the convention, we might
be doing well. I'll take a look at the code you've got at some point
soon.

As far as the UI components go, my original thought was to build them
out as other plugins... There really isn't a whole lot to stop us from
having extra plugins that add extra widgets. Since many of JQuery's UI
widgets seem to be projects of their own (unless they have been
absorbed into JQuery proper), to me it makes sense to have a separate
plugin that allows the plugin to follow the development of the
individual widget. Plus, separating it will allow us to release and
keep the main JQuery plugin we're talking about slim and easier to
maintain. I could be wrong here, so feel free to disagree, but it
makes sense to me that the non-absorbed widgets be dealt with this
way. The problem we will have though is that most plugins are built to
not depend on other plugins, in this instance, I think it makes sense
to disregard this rule.

-Wes

-- 
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher

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

Re: JQuery integration

[Musachy Barroso <mu...@gmail.com>]

> On an aside, have you definitively decided to move the json interceptor and
> result-type into the core?
>

Nobody seems to be against it, so I guess we just have to vote on it.

musachy

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

Re: JQuery integration

[Obinna <ob...@gmail.com>]

I have created a google code struts2-jquery-plugin project [
http://code.google.com/p/struts2-jquery-plugin/] and checked in my initial
code. It is still in its infancy with only basic support for a few tags and
I've already logged a number of issues to work on (most notably, writing
some test cases).
James, if you're still interested in collaborating, perhaps you could take a
look before we begin to talk, - It's structured similar to the dojo plugin
at the moment.
I added a few notes to the wiki.
Included in the static files is the publish/subscribe framework. It is very
light and can be used elsewhere. I'll submit to jquery eventually.

WRT to the widgets & jQuery plugins, the principle I've taken so far is to
only use widgets that are part of the official jQuery-UI distro, that is,
not to use any third party plugins. These are all fairly stable and should
make the maintenance easier as Wes pointed out. At the moment, the
jQuery-UI<http://docs.jquery.com/UI>widgets only include -- accordion
menu, datepicker, dialog, tabbed pane,
progress bar and slider (most of which don't make sense for this effort) --
but there are quite a number more in their
pipepline<http://jqueryui.pbwiki.com/>and a few (including
autocomplete) slated for the next jQuery-UI release
(1.7).

I agree that form submission should be high on the prioprity list. jQuery
makes this quite simple, and in the current code, like with the dojo
plugins,  the anchor and submit tags take a 'formId' which already does this
but without validation at the moment. I'll add this to the issue list...

Wes, with regards, to the list management work-flow you described, are you
thinking of a specialized widget that handles all this or just a framework
that makes this very easy? If it's the latter then I think we're almost
there already. With the current subscribe/publish framework, several
ajax-request handler hooks are pre-defined for the major element event (for
example, before, after, success, error, always for the 'click'  load event
of a div) and hooking in to *any *event 'callback' is easy. For
extensibility, we can easily expose *all *events for an element to this,
effectively allowing users to make publish and subscribe to *any * triggered
event.

On an aside, have you definitively decided to move the json interceptor and
result-type into the core?

- Eric


2009/2/24 Musachy Barroso <mu...@gmail.com>

> Validation with JQuery should not be hard using the JSON validation
> interceptor. This could be a good time to improve how the tags are
> laid out to support adding/removing validation errors, Dave already
> brought this up before and I think he did some changes already.
>
> musachy
>
> On Tue, Feb 24, 2009 at 11:17 AM, Wes Wannemacher <we...@wantii.com> wrote:
> > On Mon, Feb 23, 2009 at 4:26 PM, Obinna <ob...@gmail.com> wrote:
> >> 2009/2/23 Musachy Barroso <mu...@gmail.com>
> >>
> >>> > I definitely agree that a thoughtful design is the right starting
> place.
> >>> > Taking this to the extreme, one thing that I mentioned in my earlier
> post
> >>> > (without too much thought) was that perhaps some kind of standardized
> >>> > specification for binding ajax features to standard struts tags
> >>> (including
> >>> > perhaps standardized widget tags - which may not be functional
> without
> >>> the
> >>> > plugin) would be something worth thinking about as there are an
> >>> increasing
> >>> > number of struts-ajax library integration each with their own
> integration
> >>> > mechanisms and syntax. Given the variety of ajax implementations,
> this
> >>> might
> >>> > be ambitious at the moment, but definitely worth a thought. This
> would
> >>> > probably take the form of some kind of standardized <bind/> tag spec
> with
> >>> > specified behaviour for implementations.
> >>> >
> >>>
> >>> I think we should keep simple, and down to JQuery. I don't think it is
> >>> worth the effort to go with some generic interface where multiple
> >>> libraries can be plugged in. IMO that would add more complexity, lots
> >>> of bugs and zillions of questions on the mailing lists(just supporting
> >>> one library has been hard). I would say the same thing about the
> >>> widgets, adding anything else beyond the jquery datepicker would be
> >>> too much.
> >>
> >>
> >> I agree. In addition to the datepicker, I think the tabbed pane widget
> is
> >> quite useful (I have already implemented it actually). I'd also like to
> see
> >> an autocompleter, but there is no native jQuery-UI widget for it yet
> (though
> >> a couple of strong candidates) and I remember the dojo autocompleter
> being a
> >> bit of a headache.
> >
> > I'm not completely convinced that the tabbedpanel is necessary... One
> > thing I think we might want to consider is to avoid JQuery's plugin's
> > unless they are absolutely necessary. Keeping ourselves close to
> > JQuery proper may save us in maintenance down the line. That being
> > said, there are elements available as plugins that provide
> > functionality that we will want or need (better datepickers).
> >
> >
> >>>
> >>> > At the moment, I have taken the other route and integrated a few
> jquery
> >>> > ajax-enabled tags, but it shouldn't be too much work to switch these
> to a
> >>> > <bind/> tag implementation. So far, I have integrated the div,
> anchor,
> >>> > submit and tabbed pane tags (using a custom head tag to inject jquery
> >>> > dependencies). I have NOT implemented the full set of tag attributes
> for
> >>> > these that dojo provided, opting to start with the minimal, critical
> >>> > attributes first. For the binding I have implemented a very
> lightweight
> >>> > custom publish/subscribe jQuery extension framework which is one of
> the
> >>> few
> >>> > things I really liked about the dojo framework. (I'll be sharing this
> >>> once
> >>> > on jquery as well once well tested)
> >>> >
> >>>
> >>> Topics is one of the things that would be very nice to have, and I
> >>> agree that we should start very small.
> >>>
> >>
> >> Subscription/publishing using topics is provided in the jquery-subcribe
> >> framework I've put together and heavily used by the generated jquery
> code.
> >> This is included in js files injected by head tag
> >
> > That's good that you've already got something in the works. This is
> > one of the pieces that JQuery misses, that would make it fit well
> > within struts.
> >
> >>
> >>
> >>>
> >>> > Perhaps surprisingly, I have currently implemented the templates
> using
> >>> the
> >>> > javatemplates plugin (not yet freemarker), simply because I've been
> too
> >>> lazy
> >>> > to pick up the freemarker template syntax which I'm not very familiar
> >>> with
> >>> > yet (this might be a great starting place for some collaborative
> help).
> >>>
> >>> I really like JQuery's one-liners, so maybe it won't be that hard to
> >>> read in java code, if it get complex then I'd suggest swtiching to
> >>> FreeMarker.
> >>>
> >>
> >> Not excessively complex at the moment but getting there. Will implement
> with
> >> freemarker soon i hope.
> >>
> >>
> >
> > Another point I'd like to make is that I think a first stab would be
> > to make a plugin that will enable AJAX form submission with
> > validation. It's an easy task, but it is one of the most common
> > use-cases. In the "old" days of struts2, you could ajax validation,
> > just by adding 'theme="ajax"'. Althought I don't think it's worthwhile
> > to strive for that sort of interoperability, it would be nice to have
> > a set of form tags and a convention that allows a simple
> > list-add|edit|delete-list workflow. Using a subscribe/publish/notify
> > type of paradigm on the (preferably JSON) responses of each request,
> > would allow users to hook their own handlers into each event.
> >
> > Here is how I see the work ->
> >
> > 0. have a head tag to include the necessary stuff
> > 1. create a tag for retrieving and then exposing data... This would
> > allow you to hook a handler to the response. I would use this to
> > generate the list
> > 2. create a form tag and handlers for validation errors. This would
> > require a bit of massaging of the JSON results (IMO). Generally, the
> > client has no idea what happened on the server (response code of
> > action method / validation status).
> > 3. create form elements that support the validation error messages.
> >
> > -Wes
> >
> >
> >
> > --
> > Wes Wannemacher
> > Author - Struts 2 In Practice
> > Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> > http://www.manning.com/wannemacher
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Re: JQuery integration

[Musachy Barroso <mu...@gmail.com>]

Validation with JQuery should not be hard using the JSON validation
interceptor. This could be a good time to improve how the tags are
laid out to support adding/removing validation errors, Dave already
brought this up before and I think he did some changes already.

musachy

On Tue, Feb 24, 2009 at 11:17 AM, Wes Wannemacher <we...@wantii.com> wrote:
> On Mon, Feb 23, 2009 at 4:26 PM, Obinna <ob...@gmail.com> wrote:
>> 2009/2/23 Musachy Barroso <mu...@gmail.com>
>>
>>> > I definitely agree that a thoughtful design is the right starting place.
>>> > Taking this to the extreme, one thing that I mentioned in my earlier post
>>> > (without too much thought) was that perhaps some kind of standardized
>>> > specification for binding ajax features to standard struts tags
>>> (including
>>> > perhaps standardized widget tags - which may not be functional without
>>> the
>>> > plugin) would be something worth thinking about as there are an
>>> increasing
>>> > number of struts-ajax library integration each with their own integration
>>> > mechanisms and syntax. Given the variety of ajax implementations, this
>>> might
>>> > be ambitious at the moment, but definitely worth a thought. This would
>>> > probably take the form of some kind of standardized <bind/> tag spec with
>>> > specified behaviour for implementations.
>>> >
>>>
>>> I think we should keep simple, and down to JQuery. I don't think it is
>>> worth the effort to go with some generic interface where multiple
>>> libraries can be plugged in. IMO that would add more complexity, lots
>>> of bugs and zillions of questions on the mailing lists(just supporting
>>> one library has been hard). I would say the same thing about the
>>> widgets, adding anything else beyond the jquery datepicker would be
>>> too much.
>>
>>
>> I agree. In addition to the datepicker, I think the tabbed pane widget is
>> quite useful (I have already implemented it actually). I'd also like to see
>> an autocompleter, but there is no native jQuery-UI widget for it yet (though
>> a couple of strong candidates) and I remember the dojo autocompleter being a
>> bit of a headache.
>
> I'm not completely convinced that the tabbedpanel is necessary... One
> thing I think we might want to consider is to avoid JQuery's plugin's
> unless they are absolutely necessary. Keeping ourselves close to
> JQuery proper may save us in maintenance down the line. That being
> said, there are elements available as plugins that provide
> functionality that we will want or need (better datepickers).
>
>
>>>
>>> > At the moment, I have taken the other route and integrated a few jquery
>>> > ajax-enabled tags, but it shouldn't be too much work to switch these to a
>>> > <bind/> tag implementation. So far, I have integrated the div, anchor,
>>> > submit and tabbed pane tags (using a custom head tag to inject jquery
>>> > dependencies). I have NOT implemented the full set of tag attributes for
>>> > these that dojo provided, opting to start with the minimal, critical
>>> > attributes first. For the binding I have implemented a very lightweight
>>> > custom publish/subscribe jQuery extension framework which is one of the
>>> few
>>> > things I really liked about the dojo framework. (I'll be sharing this
>>> once
>>> > on jquery as well once well tested)
>>> >
>>>
>>> Topics is one of the things that would be very nice to have, and I
>>> agree that we should start very small.
>>>
>>
>> Subscription/publishing using topics is provided in the jquery-subcribe
>> framework I've put together and heavily used by the generated jquery code.
>> This is included in js files injected by head tag
>
> That's good that you've already got something in the works. This is
> one of the pieces that JQuery misses, that would make it fit well
> within struts.
>
>>
>>
>>>
>>> > Perhaps surprisingly, I have currently implemented the templates using
>>> the
>>> > javatemplates plugin (not yet freemarker), simply because I've been too
>>> lazy
>>> > to pick up the freemarker template syntax which I'm not very familiar
>>> with
>>> > yet (this might be a great starting place for some collaborative help).
>>>
>>> I really like JQuery's one-liners, so maybe it won't be that hard to
>>> read in java code, if it get complex then I'd suggest swtiching to
>>> FreeMarker.
>>>
>>
>> Not excessively complex at the moment but getting there. Will implement with
>> freemarker soon i hope.
>>
>>
>
> Another point I'd like to make is that I think a first stab would be
> to make a plugin that will enable AJAX form submission with
> validation. It's an easy task, but it is one of the most common
> use-cases. In the "old" days of struts2, you could ajax validation,
> just by adding 'theme="ajax"'. Althought I don't think it's worthwhile
> to strive for that sort of interoperability, it would be nice to have
> a set of form tags and a convention that allows a simple
> list-add|edit|delete-list workflow. Using a subscribe/publish/notify
> type of paradigm on the (preferably JSON) responses of each request,
> would allow users to hook their own handlers into each event.
>
> Here is how I see the work ->
>
> 0. have a head tag to include the necessary stuff
> 1. create a tag for retrieving and then exposing data... This would
> allow you to hook a handler to the response. I would use this to
> generate the list
> 2. create a form tag and handlers for validation errors. This would
> require a bit of massaging of the JSON results (IMO). Generally, the
> client has no idea what happened on the server (response code of
> action method / validation status).
> 3. create form elements that support the validation error messages.
>
> -Wes
>
>
>
> --
> Wes Wannemacher
> Author - Struts 2 In Practice
> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> http://www.manning.com/wannemacher
>
> ---------------------------------------------------------------------
> 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

Re: JQuery integration

[Wes Wannemacher <we...@wantii.com>]

On Mon, Feb 23, 2009 at 4:26 PM, Obinna <ob...@gmail.com> wrote:
> 2009/2/23 Musachy Barroso <mu...@gmail.com>
>
>> > I definitely agree that a thoughtful design is the right starting place.
>> > Taking this to the extreme, one thing that I mentioned in my earlier post
>> > (without too much thought) was that perhaps some kind of standardized
>> > specification for binding ajax features to standard struts tags
>> (including
>> > perhaps standardized widget tags - which may not be functional without
>> the
>> > plugin) would be something worth thinking about as there are an
>> increasing
>> > number of struts-ajax library integration each with their own integration
>> > mechanisms and syntax. Given the variety of ajax implementations, this
>> might
>> > be ambitious at the moment, but definitely worth a thought. This would
>> > probably take the form of some kind of standardized <bind/> tag spec with
>> > specified behaviour for implementations.
>> >
>>
>> I think we should keep simple, and down to JQuery. I don't think it is
>> worth the effort to go with some generic interface where multiple
>> libraries can be plugged in. IMO that would add more complexity, lots
>> of bugs and zillions of questions on the mailing lists(just supporting
>> one library has been hard). I would say the same thing about the
>> widgets, adding anything else beyond the jquery datepicker would be
>> too much.
>
>
> I agree. In addition to the datepicker, I think the tabbed pane widget is
> quite useful (I have already implemented it actually). I'd also like to see
> an autocompleter, but there is no native jQuery-UI widget for it yet (though
> a couple of strong candidates) and I remember the dojo autocompleter being a
> bit of a headache.

I'm not completely convinced that the tabbedpanel is necessary... One
thing I think we might want to consider is to avoid JQuery's plugin's
unless they are absolutely necessary. Keeping ourselves close to
JQuery proper may save us in maintenance down the line. That being
said, there are elements available as plugins that provide
functionality that we will want or need (better datepickers).


>>
>> > At the moment, I have taken the other route and integrated a few jquery
>> > ajax-enabled tags, but it shouldn't be too much work to switch these to a
>> > <bind/> tag implementation. So far, I have integrated the div, anchor,
>> > submit and tabbed pane tags (using a custom head tag to inject jquery
>> > dependencies). I have NOT implemented the full set of tag attributes for
>> > these that dojo provided, opting to start with the minimal, critical
>> > attributes first. For the binding I have implemented a very lightweight
>> > custom publish/subscribe jQuery extension framework which is one of the
>> few
>> > things I really liked about the dojo framework. (I'll be sharing this
>> once
>> > on jquery as well once well tested)
>> >
>>
>> Topics is one of the things that would be very nice to have, and I
>> agree that we should start very small.
>>
>
> Subscription/publishing using topics is provided in the jquery-subcribe
> framework I've put together and heavily used by the generated jquery code.
> This is included in js files injected by head tag

That's good that you've already got something in the works. This is
one of the pieces that JQuery misses, that would make it fit well
within struts.

>
>
>>
>> > Perhaps surprisingly, I have currently implemented the templates using
>> the
>> > javatemplates plugin (not yet freemarker), simply because I've been too
>> lazy
>> > to pick up the freemarker template syntax which I'm not very familiar
>> with
>> > yet (this might be a great starting place for some collaborative help).
>>
>> I really like JQuery's one-liners, so maybe it won't be that hard to
>> read in java code, if it get complex then I'd suggest swtiching to
>> FreeMarker.
>>
>
> Not excessively complex at the moment but getting there. Will implement with
> freemarker soon i hope.
>
>

Another point I'd like to make is that I think a first stab would be
to make a plugin that will enable AJAX form submission with
validation. It's an easy task, but it is one of the most common
use-cases. In the "old" days of struts2, you could ajax validation,
just by adding 'theme="ajax"'. Althought I don't think it's worthwhile
to strive for that sort of interoperability, it would be nice to have
a set of form tags and a convention that allows a simple
list-add|edit|delete-list workflow. Using a subscribe/publish/notify
type of paradigm on the (preferably JSON) responses of each request,
would allow users to hook their own handlers into each event.

Here is how I see the work ->

0. have a head tag to include the necessary stuff
1. create a tag for retrieving and then exposing data... This would
allow you to hook a handler to the response. I would use this to
generate the list
2. create a form tag and handlers for validation errors. This would
require a bit of massaging of the JSON results (IMO). Generally, the
client has no idea what happened on the server (response code of
action method / validation status).
3. create form elements that support the validation error messages.

-Wes



-- 
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher

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

Re: JQuery integration

[Obinna <ob...@gmail.com>]

2009/2/23 Musachy Barroso <mu...@gmail.com>

> > I definitely agree that a thoughtful design is the right starting place.
> > Taking this to the extreme, one thing that I mentioned in my earlier post
> > (without too much thought) was that perhaps some kind of standardized
> > specification for binding ajax features to standard struts tags
> (including
> > perhaps standardized widget tags - which may not be functional without
> the
> > plugin) would be something worth thinking about as there are an
> increasing
> > number of struts-ajax library integration each with their own integration
> > mechanisms and syntax. Given the variety of ajax implementations, this
> might
> > be ambitious at the moment, but definitely worth a thought. This would
> > probably take the form of some kind of standardized <bind/> tag spec with
> > specified behaviour for implementations.
> >
>
> I think we should keep simple, and down to JQuery. I don't think it is
> worth the effort to go with some generic interface where multiple
> libraries can be plugged in. IMO that would add more complexity, lots
> of bugs and zillions of questions on the mailing lists(just supporting
> one library has been hard). I would say the same thing about the
> widgets, adding anything else beyond the jquery datepicker would be
> too much.


I agree. In addition to the datepicker, I think the tabbed pane widget is
quite useful (I have already implemented it actually). I'd also like to see
an autocompleter, but there is no native jQuery-UI widget for it yet (though
a couple of strong candidates) and I remember the dojo autocompleter being a
bit of a headache.


>
> > At the moment, I have taken the other route and integrated a few jquery
> > ajax-enabled tags, but it shouldn't be too much work to switch these to a
> > <bind/> tag implementation. So far, I have integrated the div, anchor,
> > submit and tabbed pane tags (using a custom head tag to inject jquery
> > dependencies). I have NOT implemented the full set of tag attributes for
> > these that dojo provided, opting to start with the minimal, critical
> > attributes first. For the binding I have implemented a very lightweight
> > custom publish/subscribe jQuery extension framework which is one of the
> few
> > things I really liked about the dojo framework. (I'll be sharing this
> once
> > on jquery as well once well tested)
> >
>
> Topics is one of the things that would be very nice to have, and I
> agree that we should start very small.
>

Subscription/publishing using topics is provided in the jquery-subcribe
framework I've put together and heavily used by the generated jquery code.
This is included in js files injected by head tag


>
> > Perhaps surprisingly, I have currently implemented the templates using
> the
> > javatemplates plugin (not yet freemarker), simply because I've been too
> lazy
> > to pick up the freemarker template syntax which I'm not very familiar
> with
> > yet (this might be a great starting place for some collaborative help).
>
> I really like JQuery's one-liners, so maybe it won't be that hard to
> read in java code, if it get complex then I'd suggest swtiching to
> FreeMarker.
>

Not excessively complex at the moment but getting there. Will implement with
freemarker soon i hope.


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