BaseFieldTag

[ma...@pallo.de]

Hello,

first of all, i am working with struts framework and its a great thing.

I have changed the  BaseFieldTag for supporting the readonly attribute in 
<html:text> elements. If you want, i can send the changes to you.....



Markus Pallo

Re: BaseFieldTag

[Michael Westbay <we...@seaple.icc.ne.jp>]

In reply to Winterfeldt-san who wrote:

> > I had to do something like this for a report and if
> > there was a standard gif or jpg to represent a
> > checked/unchecked checkbox and selected/unselected
> > radio button I think it would be ok.

Hackett-san wrote:

> Except that checkboxes look different on each platform (and sometimes
> there are even variances between browsers), so a single image would not
> look right on all systems. I think we'll have to wait for browser
> support of "disabled" is improved, unless there is a way to simulate the
> effect in JavaScript under Navigator 4.x. (Still, where does that leave
> Lynx users?)

I think that what he wants is something like a TagLib that produces hooks into something like DynAPI button widgets at:

    http://www.dansteinman.com/dynduo/

There are cross browser DHTML implementations for button images, radio buttons, check boxes, and more, all done with images, so the widets look alike on all platforms and browsers.

A TagLib that uses these would be very interesting.  But I don't think that they belong in Struts.  Perhaps another project could be built off of them.

--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/

RE: BaseFieldTag

[Michael Hackett <mh...@pictorius.com>]

--- David Winterfeldt <dw...@yahoo.com> wrote:

> --- "Craig R. McClanahan" <cr...@apache.org> wrote:
> > But how would you render disabled checkbox, radio
> > button, or combo box controls?
>
> I had to do something like this for a report and if
> there was a standard gif or jpg to represent a
> checked/unchecked checkbox and selected/unselected
> radio button I think it would be ok.

Except that checkboxes look different on each platform (and sometimes
there are even variances between browsers), so a single image would not
look right on all systems. I think we'll have to wait for browser
support of "disabled" is improved, unless there is a way to simulate the
effect in JavaScript under Navigator 4.x. (Still, where does that leave
Lynx users?)

--
Michael Hackett
Developer, Pictorius Inc.

Re: BaseFieldTag

[David Winterfeldt <dw...@yahoo.com>]

--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> 
> 
> On Thu, 22 Mar 2001, David Winterfeldt wrote:
> 
> > The disabled attribute sounds best if enought
> browsers
> > support it, but if they don't what if readonly
> wasn't
> > an html attribute, but a Struts one and if it was
> > 'true' the field could written out as text?  I
> don't
> > know know if this has already been suggested or
> not.
> > 
> 
> Two Issues:
> 
> (1) Render as text only
> 
> This idea is appealing for text or textarea type
> fields, if we are willing
> to accept the difference in visual appearance.  But
> how would you render
> disabled checkbox, radio button, or combo box
> controls?  Or would it be
> acceptable to only use disabled on text and
> textarea?
> 
I had to do something like this for a report and if
there was a standard gif or jpg to represent a
checked/unchecked checkbox and selected/unselected
radio button I think it would be ok.  Or use text
(which wouldn't look nice), but have it somewhere in
the configuration to specify an image for a checked
checkbox.  Also, if someone had a combo box, they
would have supplied a collection or list of keys and
values so the display value could be generated. 
Hidden fields for anything written out as text or
images could be created at the same.  It would just
encapsulate this.

<logic:equal name="registrationForm" property="action"
            scope="request" value="Create">
  <html:text property="username" size="16"
maxlength="16"/>
</logic:equal>
<logic:equal name="registrationForm" property="action"
            scope="request" value="Edit">
  <bean:write name="registrationForm"
property="username"
             scope="request" filter="true"/>
<html:hidden property="username"/>
</logic:equal>

instead

<logic:equal name="registrationForm" property="action"
            scope="request" value="Create">
  <html:text property="username" size="16"
maxlength="16"/>
</logic:equal>
<logic:equal name="registrationForm" property="action"
            scope="request" value="Edit">
  <html:text property="username" size="16"
maxlength="16" readonly="true"/>
</logic:equal>

The output would be the same.  And in the future when
all browsers support the disabled feature that could
be used instead.  

> (2) Standard compliance
> 
> So far, 100% of the HTML code that Struts tags
> generates is compliant with
> the HTML 4.01 specification.  This will become more
> important if and when
> XHTML becomes more popular, because you can then
> validate conformance.  To
> me, this is an important principle.  What do you
> think?
> 
I think it is important to comply to the standards as
much as possible.

> > David
> 
> Craig
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

id attribute again

[Michael Hackett <mh...@pictorius.com>]

This came up here briefly not too long ago, but I don't think it was
settled to any degree. Scott Snyder asked about generating "id"
attributes for <input> tags generated by the Struts taglib, I believe
for the purpose of using stylesheets. I have another reason for wanting
the id attribute: <label> tags. The fields to which they refer must have
an id defined; it doesn't work on the name attribute.

I understand that there is a bit of a difficulty in simply reusing the
property/name value for the id, as this would cause problems if a page
included two forms with any identically named fields (or the id was used
anywhere else outside the forms). So perhaps the Struts-generated IDs
could be a dot-notation name based on the form and field names (e.g.
loginForm.userName). Unfortunately, this might not be ideal for the
stylesheet user who wants to format every field with a particular name
in a certain way, but one could still use classes to achieve the desired
result (though slightly less conveniently).

The other issue would be what to use for the form name. The simplest
answer is to use the existing name (either specified or, more typically,
obtained by looking up the specified action in the action mapping), but
then you're forced to repeat the form name in the JSP file when it might
previously have been specified only in the struts-config.xml file
(making it easier to change). However, if an <html:label> tag was added
(or labels could be incorporated into the existing custom tags), the
need to specify the form name in the JSP would be largely eliminated.
Otherwise, one might want the ability to add a page-local name in the
<html:form> tag.

Any thoughts on this?

--
Michael Hackett
Developer, Pictorius Inc.

Re: BaseFieldTag

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 22 Mar 2001, David Winterfeldt wrote:

> The disabled attribute sounds best if enought browsers
> support it, but if they don't what if readonly wasn't
> an html attribute, but a Struts one and if it was
> 'true' the field could written out as text?  I don't
> know know if this has already been suggested or not.
> 

Two Issues:

(1) Render as text only

This idea is appealing for text or textarea type fields, if we are willing
to accept the difference in visual appearance.  But how would you render
disabled checkbox, radio button, or combo box controls?  Or would it be
acceptable to only use disabled on text and textarea?

(2) Standard compliance

So far, 100% of the HTML code that Struts tags generates is compliant with
the HTML 4.01 specification.  This will become more important if and when
XHTML becomes more popular, because you can then validate conformance.  To
me, this is an important principle.  What do you think?

> David

Craig

Re: BaseFieldTag

[David Winterfeldt <dw...@yahoo.com>]

The disabled attribute sounds best if enought browsers
support it, but if they don't what if readonly wasn't
an html attribute, but a Struts one and if it was
'true' the field could written out as text?  I don't
know know if this has already been suggested or not.

David

--- "Craig R. McClanahan"
<Cr...@eng.sun.com> wrote:
> markus@pallo.de wrote:
> 
> > Hello,
> >
> > first of all, i am working with struts framework
> and its a great thing.
> >
> > I have changed the  BaseFieldTag for supporting
> the readonly attribute in
> > <html:text> elements. If you want, i can send the
> changes to you.....
> >
> > Markus Pallo
> 
> Sorry for the late response ... email issues.
> 
> In the HTML 4.01 spec, the "readonly" attribute is
> only defined on the
> <textarea> element, so I am reluctant to add it to
> <html:text> (which
> generates an <input> element).
> 
> In 4.01, however, there is a "disabled" attribute on
> most of the tags of
> interest.  Do enough browsers support this that it
> would be worth
> implementing?
> 
> Craig
> 
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: BaseFieldTag

["Craig R. McClanahan" <Cr...@eng.sun.com>]

markus@pallo.de wrote:

> Hello,
>
> first of all, i am working with struts framework and its a great thing.
>
> I have changed the  BaseFieldTag for supporting the readonly attribute in
> <html:text> elements. If you want, i can send the changes to you.....
>
> Markus Pallo

Sorry for the late response ... email issues.

In the HTML 4.01 spec, the "readonly" attribute is only defined on the
<textarea> element, so I am reluctant to add it to <html:text> (which
generates an <input> element).

In 4.01, however, there is a "disabled" attribute on most of the tags of
interest.  Do enough browsers support this that it would be worth
implementing?

Craig