I didn't say it before, but in that I agree with you all, they could be
in a plugin, I just think we should have them, somewhere. A separate
project, I don't think it is a good idea, there are plenty of ajax
projects out there, and we don't want to implement a lot of tags (that
javascript is driving me nuts already :) ).
musachy
Don Brown wrote:
I agree with both of you :) On one hand, I hate to maintain code in
Struts that doesn't provide any real added value and saps already
precious resources and time. On the other hand, I want to make Struts
immediately useful and having a powerful tag library is key.
I'm wondering if having ajax wrapping tags are ok, but perhaps reusing
the "theme" feature is a bad idea and these tags should be given their
own library. This library could, in fact, be a plugin or even an
external project that we bundle with Struts 2 much like Spring or DWR.
Don
Musachy Barroso wrote:
I wouldn't agree to have tags for every Dojo widget, which would be
insane, but keeping these few tags, can make life a lot easier for
users who only want to add some "ajax-behavior" here and there in
their applications.
musachy
Ian Roughley wrote:
This has been my concern for some time now... especially with the
dojo / ajax tags. What we seem to be doing is simply wrapping the
dojo tag with a s2 tag - providing ways to access the dojo specific
attributes.
There are then additional issues - such as the dojo code releasing
more often then s2 (3 releases I think since ww became s2); not all
the attributes of the dojo tag in the s2 taglib; and not all the
functionality included (especially advanced functionality). If
users then want to upgrade the dojo library themselves, they are
forced to deal with possible conflicts - either running 2 different
version (one in s2 and another); using one version and possibly
breaking the s2 tags; migrating all the tags from s2 taglibs to pure
dojo; or simply becoming frustrated and not using the features
(which I think is the worse situation).
Perhaps this is best left to the dojo html with s:property taglibs
for values?
/Ian
Don Brown wrote:
The question is do we want to create one Struts tag library that
does everything, or focus on tags that require close ties with our
framework? While I like the idea of providing more features and
tags to our users, I wonder if within Struts is the best place to
host it...
Don
Ted Husted wrote:
I know I've implemented paging a dozen different ways, and
reducing to
a tag of our own sounds like a good idea. Ditto with sorted
tables. If
you wanted to contribute the tags, the thing to do would be to file a
CLA and open a JIRA ticket with the code attached,.
* http://apache.org/licenses/#clas
-Ted.
On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote:
Hello,
I've been working with webwork since June. My company migrated
from a
home-grown webframework to webwork and it has been a very good
experience. I'm excited to see how struts2 can improve on an
already
top-notch framework.
In the process of integrating webwork with our software, I
implemented
several UI tags that probably could be used on other projects. I
wanted
to get a feel for whether there was a desire to add these tags to
the
core struts project. Although there are other open source tags that
implement this functionality, we leverage the template based
nature of
the UI tags very heavily and wanted tags that allowed us this
type of
customization.
Pager - the pager tag is used to display a small pager display to
allow
pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is
used on
almost all the pages where we have lists of data.
SortColumn - the sort column tag displays the column name, the
current
sort direction and is hyperlinked so that the sort
direction/selected
sort column can be changed (e.g. Name ^ or Name v)
So, my question is: Is there any interest in adding these kinds
of tags
to the core struts tag library, or should these be separate? I
would
think there would be enough other projects out there that would need
these types of tags to warrant it, however, I've been doing only
database apps for the last 2 years, so my perspective may be
skewed a bit.
Thanks,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
