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]
