You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sudhaker Raj <su...@gmail.com> on 2005/08/29 17:05:05 UTC
Some thoughts.
1. Do we have need of tags like these?
<html:js src="/script/util.js" />
<html:css src="/css/style.css" />
Currently we are suppose to use html:rewrite tag or some crud method.
<script language="javascript" src="<html:rewrite src="/script/util.js"
/>"></script>
CSS is bit neat because of @import but JS is still making code look nasty.
2. Do we have need of tag attribute like this?
<html:form mode="edit">
...
</html:form>
<html:form mode="confirm">
...
</html:form>
<html:form mode="show">
...
</html:form>
Setting the mode attribute to 'confirm' will convert all form-field
into a hidden field and will replace all editable area with a label
showing current values. Similarly setting mode attribute to 'show'
will simply replace all editable area with a label showing current
values.
The show mode can be very well used for followings
* Same JSP code can be used to show details and edit details.
* Confirm filled values before finally submitting.
* Form can be made read-only or editable based on user's credentials.
This can be further improved to control field level rendering and security.
--
Cheers,
Sudhaker Raj
http://thej2ee.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by Sudhaker Raj <su...@gmail.com>.
That is why I proposed.
> Setting the mode attribute to 'confirm' will convert all
> form-field into a hidden field and will replace all editable
> area with a label showing current values. Similarly setting
> mode attribute to 'show' will simply replace all editable
> area with a label showing current values.
On 8/29/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> Since Struts 1.2.7 the <html:form> tag now has "disabled" and "readonly"
> attributes, which if set affect the controls contained in the form.
>
> So if you use <html:form disabled="true"> then the controls contained in
> the form are disabled.
>
> If you use <html:form readonly="true"> then the controls contained in the
> form are readonly. According to the HTML 4 Spec. the "readonly" attribute
> is only valid for <input type="text">, <input type="password"> and
> <textarea> elements and so only the <html:text>, <html:password> and
> <html:textarea> tags are affected by this setting.
>
> I guess if you want a form to be "readonly" and you also have controls such
> as <html:checkbox>, <html:radio> or <html:select> to be affected by the
> setting then this doesn't provide a complete solution. It is relatively easy
> to have custom versions of the struts tags for these kind of elements which
> either emit a "readonly" attribute (some browsers support this even though
> its not in the Spec) or do some other custom processing. The
> prepareFocusEvents() method in BaseHandlerTag is the best place to look to
> understand how this has been implemented in Struts.
>
> Niall
>
> ----- Original Message -----
> From: "Sudhaker Raj" <su...@gmail.com>
> Sent: Monday, August 29, 2005 4:05 PM
>
>
>
> 2. Do we have need of tag attribute like this?
>
> <html:form mode="edit">
> ...
> </html:form>
>
> <html:form mode="confirm">
> ...
> </html:form>
>
> <html:form mode="show">
> ...
> </html:form>
>
> Setting the mode attribute to 'confirm' will convert all form-field
> into a hidden field and will replace all editable area with a label
> showing current values. Similarly setting mode attribute to 'show'
> will simply replace all editable area with a label showing current
> values.
>
> The show mode can be very well used for followings
>
> * Same JSP code can be used to show details and edit details.
> * Confirm filled values before finally submitting.
> * Form can be made read-only or editable based on user's credentials.
>
> This can be further improved to control field level rendering and security.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Cheers,
Sudhaker Raj
http://thej2ee.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Since Struts 1.2.7 the <html:form> tag now has "disabled" and "readonly"
attributes, which if set affect the controls contained in the form.
So if you use <html:form disabled="true"> then the controls contained in
the form are disabled.
If you use <html:form readonly="true"> then the controls contained in the
form are readonly. According to the HTML 4 Spec. the "readonly" attribute
is only valid for <input type="text">, <input type="password"> and
<textarea> elements and so only the <html:text>, <html:password> and
<html:textarea> tags are affected by this setting.
I guess if you want a form to be "readonly" and you also have controls such
as <html:checkbox>, <html:radio> or <html:select> to be affected by the
setting then this doesn't provide a complete solution. It is relatively easy
to have custom versions of the struts tags for these kind of elements which
either emit a "readonly" attribute (some browsers support this even though
its not in the Spec) or do some other custom processing. The
prepareFocusEvents() method in BaseHandlerTag is the best place to look to
understand how this has been implemented in Struts.
Niall
----- Original Message -----
From: "Sudhaker Raj" <su...@gmail.com>
Sent: Monday, August 29, 2005 4:05 PM
2. Do we have need of tag attribute like this?
<html:form mode="edit">
...
</html:form>
<html:form mode="confirm">
...
</html:form>
<html:form mode="show">
...
</html:form>
Setting the mode attribute to 'confirm' will convert all form-field
into a hidden field and will replace all editable area with a label
showing current values. Similarly setting mode attribute to 'show'
will simply replace all editable area with a label showing current
values.
The show mode can be very well used for followings
* Same JSP code can be used to show details and edit details.
* Confirm filled values before finally submitting.
* Form can be made read-only or editable based on user's credentials.
This can be further improved to control field level rendering and security.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts #2.
Posted by Sudhaker Raj <su...@gmail.com>.
@ my suggestion #2
It was not fully cooked idea and I just popped it for the sake of discussion.
We developed a similar framework in one of our previous project where
we were using widgets kind of control for each HTML form element.
For example:
If some field is set to use currency widget, then in edit mode it was
rendering a DHTML powered right-aligned textbox, which has inbuilt and
atomic capability of prefixing $ and adding comma etc (business really
liked it). In view mode it was simply a label with currency formatting
in our standard format.
Similarly date selector was rendering another widget with textbox
followed by a calendar icon. Needless to say, that icon was popping a
DHTML calendar and filling date textbox. In view mode it was a label
with just formatted date.
In case of a multi-line field (say comments), edit mode was rendering
a standard textarea and view mode was rendering html code with all NL
replaced with <br /> !!!
The whole interface was themed for our application and we had a group
of rendering styles to choose from for every form field. It was a very
powerful and still simple to use framework.
-
The port of the same in struts world can to be a new taglib with
formdef like plug-in where you can define your rendering component
declaratively and pass dirty job of rendering HTML to this taglib. All
corporate have some UI standards as well and making (customizing) a
superset of widgets and style should not be any problem.
I agree this won't solve every problem out-of-box, but guess no one can.
Thanks for your inputs.
On 8/29/05, Martin Cooper <mf...@gmail.com> wrote:
> The form modes sound nice in theory, but I suspect you'd end up having to
> write multiple renderings by hand anyway. I assume that the purpose was to
> avoid this.
>
> For example, how would a non-editable checkbox be rendered? Yes/No? On/Off?
> A green tick and a red cross? What about the result of a set of grouped
> checkboxes? (You'd presumably have to add a tag to indicate that they are a
> group, also.) A group of radio buttons? People are going to want to have
> control over these things, and I find it hard to imagine how that would be
> done without a multitude of attributes and options. It would end up being
> simpler to just write separate renderings.
>
> --
> Martin Cooper
>
>
> On 8/29/05, Sudhaker Raj <su...@gmail.com> wrote:
> >
> > 1. Do we have need of tags like these?
> >
> > <html:js src="/script/util.js" />
> > <html:css src="/css/style.css" />
> >
> > Currently we are suppose to use html:rewrite tag or some crud method.
> >
> > <script language="javascript" src="<html:rewrite src="/script/util.js"
> > />"></script>
> >
> > CSS is bit neat because of @import but JS is still making code look nasty.
> >
> >
> > 2. Do we have need of tag attribute like this?
> >
> > <html:form mode="edit">
> > ...
> > </html:form>
> >
> > <html:form mode="confirm">
> > ...
> > </html:form>
> >
> > <html:form mode="show">
> > ...
> > </html:form>
> >
> > Setting the mode attribute to 'confirm' will convert all form-field
> > into a hidden field and will replace all editable area with a label
> > showing current values. Similarly setting mode attribute to 'show'
> > will simply replace all editable area with a label showing current
> > values.
> >
> > The show mode can be very well used for followings
> >
> > * Same JSP code can be used to show details and edit details.
> > * Confirm filled values before finally submitting.
> > * Form can be made read-only or editable based on user's credentials.
> >
> > This can be further improved to control field level rendering and
> > security.
> >
> > --
> > Cheers,
> > Sudhaker Raj
> > http://thej2ee.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
--
Cheers,
Sudhaker Raj
http://thej2ee.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by Martin Cooper <mf...@gmail.com>.
The form modes sound nice in theory, but I suspect you'd end up having to
write multiple renderings by hand anyway. I assume that the purpose was to
avoid this.
For example, how would a non-editable checkbox be rendered? Yes/No? On/Off?
A green tick and a red cross? What about the result of a set of grouped
checkboxes? (You'd presumably have to add a tag to indicate that they are a
group, also.) A group of radio buttons? People are going to want to have
control over these things, and I find it hard to imagine how that would be
done without a multitude of attributes and options. It would end up being
simpler to just write separate renderings.
--
Martin Cooper
On 8/29/05, Sudhaker Raj <su...@gmail.com> wrote:
>
> 1. Do we have need of tags like these?
>
> <html:js src="/script/util.js" />
> <html:css src="/css/style.css" />
>
> Currently we are suppose to use html:rewrite tag or some crud method.
>
> <script language="javascript" src="<html:rewrite src="/script/util.js"
> />"></script>
>
> CSS is bit neat because of @import but JS is still making code look nasty.
>
>
> 2. Do we have need of tag attribute like this?
>
> <html:form mode="edit">
> ...
> </html:form>
>
> <html:form mode="confirm">
> ...
> </html:form>
>
> <html:form mode="show">
> ...
> </html:form>
>
> Setting the mode attribute to 'confirm' will convert all form-field
> into a hidden field and will replace all editable area with a label
> showing current values. Similarly setting mode attribute to 'show'
> will simply replace all editable area with a label showing current
> values.
>
> The show mode can be very well used for followings
>
> * Same JSP code can be used to show details and edit details.
> * Confirm filled values before finally submitting.
> * Form can be made read-only or editable based on user's credentials.
>
> This can be further improved to control field level rendering and
> security.
>
> --
> Cheers,
> Sudhaker Raj
> http://thej2ee.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Some thoughts.
Posted by Sudhaker Raj <su...@gmail.com>.
@ James – Regarding my thought #1
If we are not going to merge this tiny and simple thing in struts-html
then we should better make it total separate and generic taglib. I
don't see any point in making struts-ex.
I am currently working on extensive javascript taglib, which I am
planning to submit to "Jakarta Taglibs". Some example usage of that
tag will be as followings
Script
<js:script src="someurl"/>
Alert
<js:alert> any jstl tag or struts bean:message </js:alert>
<js:alert value="${somevar" />
Var
<js:var jsvar="myJsVar" value="${somevar}" />
<js:var jsvar="myJsVar"> any jstl tag or struts bean:message </js:var>
Object
<js:object jsvar="myJsObject" value="${someBeanOrMap} />
Array
<js:array jsvar="myJsArray" value="${someArrayOrCollection} />
Array2D
<js:array2d jsvar="myJsArray2D" value="${someNestedVar} />
ArrayObject
<js:arrayObject jsvar="myJsArrayObject" value="${someNestedVar} />
Note: someNestedVar can be anything which makes matrix like data (two
dimentional).
Some more tags...
All of these tags will generate java script code, which can be used
for complex client side processing and validation. Tags will also
handle all special characters and escaping required for JS.
Sample output from object tag could be.
<script language="javascript">
var myJsObject = {attr1: "value1", attr2: "value2", attr3: "value3"};
// in case it is scoped js object, var will be suppressed.
Profile.address = {addr1: "999 Some Street", addr2: "Some City, Some
State", zip: "99999"};
</script>
If some Jakarta-taglibs committer is also on this list, please guide
me with the submission process.
Thanks,
On 8/29/05, James Mitchell <ja...@mac.com> wrote:
> Sounds interesting. Although I think the best approach for this
> would be to do this in a separate tag, extending/overriding where
> appropriate.
>
> If you have time and would like to donate such an effort, perhaps we
> could put this into an "extensions" or "sandbox" taglib package.
>
>
> So something like this...
> <struts-ext:javascript page="/script/util.js"/>
>
> ("page" used here instead of "src" to be consistent with existing tags)
>
> Thoughts?
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
> On Aug 29, 2005, at 11:05 AM, Sudhaker Raj wrote:
>
> > 1. Do we have need of tags like these?
> >
> > <html:js src="/script/util.js" />
> > <html:css src="/css/style.css" />
> >
> > Currently we are suppose to use html:rewrite tag or some crud method.
> >
> > <script language="javascript" src="<html:rewrite src="/script/util.js"
> > />"></script>
> >
> > CSS is bit neat because of @import but JS is still making code look
> > nasty.
> >
> >
> > 2. Do we have need of tag attribute like this?
> >
> > <html:form mode="edit">
> > ...
> > </html:form>
> >
> > <html:form mode="confirm">
> > ...
> > </html:form>
> >
> > <html:form mode="show">
> > ...
> > </html:form>
> >
> > Setting the mode attribute to 'confirm' will convert all form-field
> > into a hidden field and will replace all editable area with a label
> > showing current values. Similarly setting mode attribute to 'show'
> > will simply replace all editable area with a label showing current
> > values.
> >
> > The show mode can be very well used for followings
> >
> > * Same JSP code can be used to show details and edit details.
> > * Confirm filled values before finally submitting.
> > * Form can be made read-only or editable based on user's credentials.
> >
> > This can be further improved to control field level rendering and
> > security.
> >
> > --
> > Cheers,
> > Sudhaker Raj
> > http://thej2ee.com
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Cheers,
Sudhaker Raj
http://thej2ee.com
Re: Some thoughts.
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Frank,
I agree that most committers are not interested in putting effort into
developing the Struts tags, however they haven't completely stagnated (see
the "Tag Library Changes" section in the Struts 1.2.7 release notes) and I
am happy to continue working on them, although having said that the amount
of time I have for open source varies.
http://struts.apache.org/userGuide/release-notes.html
Niall
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
Sent: Monday, August 29, 2005 4:31 PM
<snip>
> The one comment I would make is more in reply to James... we see
> relatively frequent questions asked about the status of the Struts
> taglibs, if they are going to be expanded, etc. In fact, I think this
> very topic was just brought up this weekend on the dev list. Yet, any
> time someone proposes changes or additions to the existing taglibs, it
> is nearly always met with the "let's do this as an extension" answer.
</snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by Leon Rosenberg <le...@friendscout24.de>.
Ops... I think I've sent my mail too fast...
so i can "forget about it again"?
leon
On Mon, 2005-08-29 at 12:01 -0400, James Mitchell wrote:
> Well, the taglibs are more or less feature complete. So any changes
> are really "extensions" or "nice-to-have".
>
> Also, I think the comments made (in prior discussions) about the
> taglibs being "no longer supported" is not really accurate...but I
> won't go there right now ;)
>
> There has been some pretty extensive refactoring over the years of
> the underlying taglib code to better support extensions like we are
> proposing, so I don't see why you couldn't go do this yourself on
> another project, or submit these as extensions.
>
> Thoughts?
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
> On Aug 29, 2005, at 11:31 AM, Frank W. Zammetti wrote:
>
> > I too think these are some interesting suggestions, especially the
> > form mode thing... you can do some neat tricks with CSS to actually
> > remove the box portion from text fields and such, so you could in
> > fact still have an <input> field there but it would look like plain
> > text, which would allow no other code anywhere to change.
> >
> > The one comment I would make is more in reply to James... we see
> > relatively frequent questions asked about the status of the Struts
> > taglibs, if they are going to be expanded, etc. In fact, I think
> > this very topic was just brought up this weekend on the dev list.
> > Yet, any time someone proposes changes or additions to the existing
> > taglibs, it is nearly always met with the "let's do this as an
> > extension" answer.
> >
> > I for one would be very much against any change that alters the
> > current functionality. Backwards compatibility is an important
> > goal in my mind. But, as far as additions go, I'd personally like
> > to see more of an acceptance of doing those sorts of things. There
> > is something to be said for not letting the taglibs get bloated
> > too, but the taglibs really have stagnated (or stabalized I suppose
> > one could say :) ) and suggestions like these I think could open up
> > the floodgates a bit, so to speak.
> >
> > Frank
> >
> > James Mitchell wrote:
> >
> >> Sounds interesting. Although I think the best approach for this
> >> would be to do this in a separate tag, extending/overriding where
> >> appropriate.
> >> If you have time and would like to donate such an effort, perhaps
> >> we could put this into an "extensions" or "sandbox" taglib package.
> >> So something like this...
> >> <struts-ext:javascript page="/script/util.js"/>
> >> ("page" used here instead of "src" to be consistent with existing
> >> tags)
> >> Thoughts?
> >> --
> >> James Mitchell
> >> Software Engineer / Open Source Evangelist
> >> Consulting / Mentoring / Freelance
> >> EdgeTech, Inc.
> >> http://www.edgetechservices.net/
> >> 678.910.8017
> >> AIM: jmitchtx
> >> Yahoo: jmitchtx
> >> MSN: jmitchell@apache.org
> >> Skype: callto://jmitchtx
> >> On Aug 29, 2005, at 11:05 AM, Sudhaker Raj wrote:
> >>
> >>> 1. Do we have need of tags like these?
> >>>
> >>> <html:js src="/script/util.js" />
> >>> <html:css src="/css/style.css" />
> >>>
> >>> Currently we are suppose to use html:rewrite tag or some crud
> >>> method.
> >>>
> >>> <script language="javascript" src="<html:rewrite src="/script/
> >>> util.js"
> >>> />"></script>
> >>>
> >>> CSS is bit neat because of @import but JS is still making code
> >>> look nasty.
> >>>
> >>>
> >>> 2. Do we have need of tag attribute like this?
> >>>
> >>> <html:form mode="edit">
> >>> ...
> >>> </html:form>
> >>>
> >>> <html:form mode="confirm">
> >>> ...
> >>> </html:form>
> >>>
> >>> <html:form mode="show">
> >>> ...
> >>> </html:form>
> >>>
> >>> Setting the mode attribute to 'confirm' will convert all form-field
> >>> into a hidden field and will replace all editable area with a label
> >>> showing current values. Similarly setting mode attribute to 'show'
> >>> will simply replace all editable area with a label showing current
> >>> values.
> >>>
> >>> The show mode can be very well used for followings
> >>>
> >>> * Same JSP code can be used to show details and edit details.
> >>> * Confirm filled values before finally submitting.
> >>> * Form can be made read-only or editable based on user's
> >>> credentials.
> >>>
> >>> This can be further improved to control field level rendering
> >>> and security.
> >>>
> >>> --
> >>> Cheers,
> >>> Sudhaker Raj
> >>> http://thej2ee.com
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> 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
> >>
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: Some thoughts.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> In light of how *I* build web apps today, we don't need the taglibs at all!
> ;-) ;-)
Ironically, I don't think I've ever used the taglibs in a production app
at all, so you and I would agree on that point :)
But, I do think there is an opportunity to encapsulate some more
functionality than is there now and make them more versatile and overall
useful in more "modern" webapp development. They almost get in the way
now if your trying to do more advanced things, and I really don't think
that needs to be the case.
If there are some ideas floating around on how to do that, why not be
receptive to them? I think the slippery slope that James referred to is
a completely valid concern, but one that can be managed. To not want to
develop them because they might be considered "feature-complete" now
doesn't strike me as a great argument... I think the automobile circa
1969 was pretty close to feature-complete at the time... love that '69
Mustang :) ...but new ideas came about, and they got incorporated, and
now we realize that calling cars feature-complete back them would have
been wrong. Might that not be the case with the taglibs now?
But, this boils down to there being some ideas and someone being able to
convince everyone they are worth wild and, of course, willing to do the
work. But, it also comes down to those who have commit priveleges being
willing to entertain the ideas.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by Martin Cooper <mf...@gmail.com>.
On 8/29/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> James Mitchell wrote:
> > Well, the taglibs are more or less feature complete. So any changes
> > are really "extensions" or "nice-to-have".
>
> I think this is the part of the equation I don't necessarily agree
> with... I think saying they are feature-complete in terms of what they
> were meant to be years ago *is* accurate. They do what was set out to
> provide,
>
> Saying they are feature-complete in terms of what we are doing now in
> web development however, isn't accurate.
>
> As a for instance, some months back I proposed adding AJAX functionality
> to the HTML taglibs. The idea garnered a fair amount of interest from a
> number of Struts users who chose to comment. Ultimately, I went off and
> did it on my own, and probably for the better, but the point is that
> integrating some degree of AJAX functionality into the existing tags
> would not have been on the list when they were originally created, but I
> for one think it should be now, so in a sense I don't consider them
> feature-complete because of this omission. This is just one example,
> there are others I'm sure.
>
> It depends on how one defines "feature-complete". In terms of what they
> were originally intended, no argument, they *are* feature-complete.
>
> In terms of what they *should* be now, in light of how web development
> is being done today, then no, I for one would not call them
> "feature-complete".
In light of how *I* build web apps today, we don't need the taglibs at all!
;-) ;-)
--
Martin Cooper
> Also, I think the comments made (in prior discussions) about the
> > taglibs being "no longer supported" is not really accurate...but I
> > won't go there right now ;)
>
> Agreed here... anyone that says they are no longer being supported is
> not painting an accurate picture. Saying they are a very low priority
> in terms of growth though, *that* I think is accurate.
>
> > There has been some pretty extensive refactoring over the years of the
> > underlying taglib code to better support extensions like we are
> > proposing, so I don't see why you couldn't go do this yourself on
> > another project, or submit these as extensions.
>
> Two things here... one is that there is a considerable difference
> between extending an existing tag and having to use a new one and simply
> expanding the existing tag. It is true that with 1.3 the situation is
> considerably better since it is a separate sub-project. Kudos for that,
> and as soon as 1.3 is released everyone will benefit from that effort.
> But, any time someone says people should just create new tags that are
> extensions to the existing ones, it kind of misses the point.
>
> Again, using the AJAX example... and please don't think this is sour
> grapes or anything on my part... I'm long since past what I proposed,
> but this happens to be the best example I have :) With the AJAX stuff I
> originally did, people just used the same tags. They didn't have to
> drop a new JAR in, didn't have to declare a new taglib, nothing like
> that. What they have been using all along was exactly the same, there
> was just some new functionality there if they needed it. This is
> inherently different than using an extended version of HTML that has to
> be added after the fact.
>
> Frank
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Some thoughts.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
James Mitchell wrote:
> Well, the taglibs are more or less feature complete. So any changes
> are really "extensions" or "nice-to-have".
I think this is the part of the equation I don't necessarily agree
with... I think saying they are feature-complete in terms of what they
were meant to be years ago *is* accurate. They do what was set out to
provide,
Saying they are feature-complete in terms of what we are doing now in
web development however, isn't accurate.
As a for instance, some months back I proposed adding AJAX functionality
to the HTML taglibs. The idea garnered a fair amount of interest from a
number of Struts users who chose to comment. Ultimately, I went off and
did it on my own, and probably for the better, but the point is that
integrating some degree of AJAX functionality into the existing tags
would not have been on the list when they were originally created, but I
for one think it should be now, so in a sense I don't consider them
feature-complete because of this omission. This is just one example,
there are others I'm sure.
It depends on how one defines "feature-complete". In terms of what they
were originally intended, no argument, they *are* feature-complete.
In terms of what they *should* be now, in light of how web development
is being done today, then no, I for one would not call them
"feature-complete".
> Also, I think the comments made (in prior discussions) about the
> taglibs being "no longer supported" is not really accurate...but I
> won't go there right now ;)
Agreed here... anyone that says they are no longer being supported is
not painting an accurate picture. Saying they are a very low priority
in terms of growth though, *that* I think is accurate.
> There has been some pretty extensive refactoring over the years of the
> underlying taglib code to better support extensions like we are
> proposing, so I don't see why you couldn't go do this yourself on
> another project, or submit these as extensions.
Two things here... one is that there is a considerable difference
between extending an existing tag and having to use a new one and simply
expanding the existing tag. It is true that with 1.3 the situation is
considerably better since it is a separate sub-project. Kudos for that,
and as soon as 1.3 is released everyone will benefit from that effort.
But, any time someone says people should just create new tags that are
extensions to the existing ones, it kind of misses the point.
Again, using the AJAX example... and please don't think this is sour
grapes or anything on my part... I'm long since past what I proposed,
but this happens to be the best example I have :) With the AJAX stuff I
originally did, people just used the same tags. They didn't have to
drop a new JAR in, didn't have to declare a new taglib, nothing like
that. What they have been using all along was exactly the same, there
was just some new functionality there if they needed it. This is
inherently different than using an extended version of HTML that has to
be added after the fact.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by James Mitchell <ja...@mac.com>.
Well, the taglibs are more or less feature complete. So any changes
are really "extensions" or "nice-to-have".
Also, I think the comments made (in prior discussions) about the
taglibs being "no longer supported" is not really accurate...but I
won't go there right now ;)
There has been some pretty extensive refactoring over the years of
the underlying taglib code to better support extensions like we are
proposing, so I don't see why you couldn't go do this yourself on
another project, or submit these as extensions.
Thoughts?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Aug 29, 2005, at 11:31 AM, Frank W. Zammetti wrote:
> I too think these are some interesting suggestions, especially the
> form mode thing... you can do some neat tricks with CSS to actually
> remove the box portion from text fields and such, so you could in
> fact still have an <input> field there but it would look like plain
> text, which would allow no other code anywhere to change.
>
> The one comment I would make is more in reply to James... we see
> relatively frequent questions asked about the status of the Struts
> taglibs, if they are going to be expanded, etc. In fact, I think
> this very topic was just brought up this weekend on the dev list.
> Yet, any time someone proposes changes or additions to the existing
> taglibs, it is nearly always met with the "let's do this as an
> extension" answer.
>
> I for one would be very much against any change that alters the
> current functionality. Backwards compatibility is an important
> goal in my mind. But, as far as additions go, I'd personally like
> to see more of an acceptance of doing those sorts of things. There
> is something to be said for not letting the taglibs get bloated
> too, but the taglibs really have stagnated (or stabalized I suppose
> one could say :) ) and suggestions like these I think could open up
> the floodgates a bit, so to speak.
>
> Frank
>
> James Mitchell wrote:
>
>> Sounds interesting. Although I think the best approach for this
>> would be to do this in a separate tag, extending/overriding where
>> appropriate.
>> If you have time and would like to donate such an effort, perhaps
>> we could put this into an "extensions" or "sandbox" taglib package.
>> So something like this...
>> <struts-ext:javascript page="/script/util.js"/>
>> ("page" used here instead of "src" to be consistent with existing
>> tags)
>> Thoughts?
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> Consulting / Mentoring / Freelance
>> EdgeTech, Inc.
>> http://www.edgetechservices.net/
>> 678.910.8017
>> AIM: jmitchtx
>> Yahoo: jmitchtx
>> MSN: jmitchell@apache.org
>> Skype: callto://jmitchtx
>> On Aug 29, 2005, at 11:05 AM, Sudhaker Raj wrote:
>>
>>> 1. Do we have need of tags like these?
>>>
>>> <html:js src="/script/util.js" />
>>> <html:css src="/css/style.css" />
>>>
>>> Currently we are suppose to use html:rewrite tag or some crud
>>> method.
>>>
>>> <script language="javascript" src="<html:rewrite src="/script/
>>> util.js"
>>> />"></script>
>>>
>>> CSS is bit neat because of @import but JS is still making code
>>> look nasty.
>>>
>>>
>>> 2. Do we have need of tag attribute like this?
>>>
>>> <html:form mode="edit">
>>> ...
>>> </html:form>
>>>
>>> <html:form mode="confirm">
>>> ...
>>> </html:form>
>>>
>>> <html:form mode="show">
>>> ...
>>> </html:form>
>>>
>>> Setting the mode attribute to 'confirm' will convert all form-field
>>> into a hidden field and will replace all editable area with a label
>>> showing current values. Similarly setting mode attribute to 'show'
>>> will simply replace all editable area with a label showing current
>>> values.
>>>
>>> The show mode can be very well used for followings
>>>
>>> * Same JSP code can be used to show details and edit details.
>>> * Confirm filled values before finally submitting.
>>> * Form can be made read-only or editable based on user's
>>> credentials.
>>>
>>> This can be further improved to control field level rendering
>>> and security.
>>>
>>> --
>>> Cheers,
>>> Sudhaker Raj
>>> http://thej2ee.com
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>>
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> 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
Re: Some thoughts.
Posted by Leon Rosenberg <le...@friendscout24.de>.
> The one comment I would make is more in reply to James... we see
> relatively frequent questions asked about the status of the Struts
> taglibs, if they are going to be expanded, etc. In fact, I think this
> very topic was just brought up this weekend on the dev list. Yet, any
> time someone proposes changes or additions to the existing taglibs, it
> is nearly always met with the "let's do this as an extension" answer.
>
> I for one would be very much against any change that alters the current
> functionality. Backwards compatibility is an important goal in my mind.
> But, as far as additions go, I'd personally like to see more of an
> acceptance of doing those sorts of things. There is something to be
> said for not letting the taglibs get bloated too, but the taglibs really
> have stagnated (or stabalized I suppose one could say :) ) and
> suggestions like these I think could open up the floodgates a bit, so to
> speak.
>
> Frank
As I'm currently working on some extensions on struts-tags, I would
appreciate if we'd had a list somewhere to put "needed
extensions" (maybe let the users vote for it?) so I can work through it.
The commiters still can decide whether to install the patch or put it in
an extensions package :-)
And yes, I fully agree with Frank, that the taglibs could use some more
engagement, so I'm trying to put it in :-)
best regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I too think these are some interesting suggestions, especially the form
mode thing... you can do some neat tricks with CSS to actually remove
the box portion from text fields and such, so you could in fact still
have an <input> field there but it would look like plain text, which
would allow no other code anywhere to change.
The one comment I would make is more in reply to James... we see
relatively frequent questions asked about the status of the Struts
taglibs, if they are going to be expanded, etc. In fact, I think this
very topic was just brought up this weekend on the dev list. Yet, any
time someone proposes changes or additions to the existing taglibs, it
is nearly always met with the "let's do this as an extension" answer.
I for one would be very much against any change that alters the current
functionality. Backwards compatibility is an important goal in my mind.
But, as far as additions go, I'd personally like to see more of an
acceptance of doing those sorts of things. There is something to be
said for not letting the taglibs get bloated too, but the taglibs really
have stagnated (or stabalized I suppose one could say :) ) and
suggestions like these I think could open up the floodgates a bit, so to
speak.
Frank
James Mitchell wrote:
> Sounds interesting. Although I think the best approach for this would
> be to do this in a separate tag, extending/overriding where appropriate.
>
> If you have time and would like to donate such an effort, perhaps we
> could put this into an "extensions" or "sandbox" taglib package.
>
>
> So something like this...
> <struts-ext:javascript page="/script/util.js"/>
>
> ("page" used here instead of "src" to be consistent with existing tags)
>
> Thoughts?
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
> On Aug 29, 2005, at 11:05 AM, Sudhaker Raj wrote:
>
>> 1. Do we have need of tags like these?
>>
>> <html:js src="/script/util.js" />
>> <html:css src="/css/style.css" />
>>
>> Currently we are suppose to use html:rewrite tag or some crud method.
>>
>> <script language="javascript" src="<html:rewrite src="/script/util.js"
>> />"></script>
>>
>> CSS is bit neat because of @import but JS is still making code look
>> nasty.
>>
>>
>> 2. Do we have need of tag attribute like this?
>>
>> <html:form mode="edit">
>> ...
>> </html:form>
>>
>> <html:form mode="confirm">
>> ...
>> </html:form>
>>
>> <html:form mode="show">
>> ...
>> </html:form>
>>
>> Setting the mode attribute to 'confirm' will convert all form-field
>> into a hidden field and will replace all editable area with a label
>> showing current values. Similarly setting mode attribute to 'show'
>> will simply replace all editable area with a label showing current
>> values.
>>
>> The show mode can be very well used for followings
>>
>> * Same JSP code can be used to show details and edit details.
>> * Confirm filled values before finally submitting.
>> * Form can be made read-only or editable based on user's credentials.
>>
>> This can be further improved to control field level rendering and
>> security.
>>
>> --
>> Cheers,
>> Sudhaker Raj
>> http://thej2ee.com
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Some thoughts.
Posted by James Mitchell <ja...@mac.com>.
Sounds interesting. Although I think the best approach for this
would be to do this in a separate tag, extending/overriding where
appropriate.
If you have time and would like to donate such an effort, perhaps we
could put this into an "extensions" or "sandbox" taglib package.
So something like this...
<struts-ext:javascript page="/script/util.js"/>
("page" used here instead of "src" to be consistent with existing tags)
Thoughts?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Aug 29, 2005, at 11:05 AM, Sudhaker Raj wrote:
> 1. Do we have need of tags like these?
>
> <html:js src="/script/util.js" />
> <html:css src="/css/style.css" />
>
> Currently we are suppose to use html:rewrite tag or some crud method.
>
> <script language="javascript" src="<html:rewrite src="/script/util.js"
> />"></script>
>
> CSS is bit neat because of @import but JS is still making code look
> nasty.
>
>
> 2. Do we have need of tag attribute like this?
>
> <html:form mode="edit">
> ...
> </html:form>
>
> <html:form mode="confirm">
> ...
> </html:form>
>
> <html:form mode="show">
> ...
> </html:form>
>
> Setting the mode attribute to 'confirm' will convert all form-field
> into a hidden field and will replace all editable area with a label
> showing current values. Similarly setting mode attribute to 'show'
> will simply replace all editable area with a label showing current
> values.
>
> The show mode can be very well used for followings
>
> * Same JSP code can be used to show details and edit details.
> * Confirm filled values before finally submitting.
> * Form can be made read-only or editable based on user's credentials.
>
> This can be further improved to control field level rendering and
> security.
>
> --
> Cheers,
> Sudhaker Raj
> http://thej2ee.com
>
> ---------------------------------------------------------------------
> 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