RE: Input taglibs - enhancements

[Karl von Randow <ka...@cactuslab.com>]

Hi Curt,

Sorry for the slow reply. I'm not convinced that it is a good solution,
but I think it does solve the problem.

The problem is to know whether the form should be in a default state or
whether it has existing state. For all other form elements that is easy
to discover; only checkboxes (and I guess radio buttons) have the
trouble. So having a field (not checkbox or radio) that accompanies the
checkbox that you can test to see whether it has a value (indicating
that the form has already been used, and is perhaps being redisplayed)
and therefore no value for the checkbox means select none rather than
use defaults.

It's a messy solution, maybe it's the beginnings of a good one?

Using the bean with the checkbox solves the problem as you can not use
the defaults attribute on the checkbox tag and instead set defaults in
the bean when it is constructed.

Cheers,
k@rl

-----Original Message-----
From: Curt Wilhelm [mailto:Curt.Wilhelm@Sun.COM] 
Sent: Thursday, 26 September 2002 6:42 a.m.
To: Karl von Randow
Cc: taglibs-dev@jakarta.apache.org
Subject: Re: Input taglibs - enhancements


Hi Karl,

thanks for the response.  Some comments in line.

Karl von Randow wrote:
> Hi Curt,
> 
> The first bug is addressed; that is changing selected to 
> selected="true", checked->checked="true", multiple->multiple="true".

thanks!
> 
> 
> The second bug. The whole checkbox default / request thing is a bit 
> tricky - the reason the code checks if the request is completely empty

> is because the absence of a param with the name of the tag doesn't 
> mean that a default value should be used, it may mean that the 
> checkbox was unchecked and the form redisplayed (as checkbox names are

> ommitted from the query string if they are unchecked, rather than 
> being given name=false).
> 
> I have contemplated ways around this problem for a while - none seem 
> particularly satisfactory. The problem disapears if a JavaBean is used

> with the form as it can always retrieve the value from the bean (if 
> there is one) - ignoring the request.
> 
> The best solution I've considered is to have a hidden field in the 
> form
> (autogenerated) which indicates whether this particular form has been
> displayed before (and thus should not use default values) or not (and
> thus should use default values). What do people think?

I now see why this is tricky.  However, I'm not convinced that this is 
the solution.  Can you provide a simple example?

> 
> Cheers,
> k@rl
> 
> 
> 
> -----Original Message-----
> From: Curt Wilhelm [mailto:Curt.Wilhelm@Sun.COM]
> Sent: Wednesday, 25 September 2002 4:06 a.m.
> To: Tag Libraries Developers List
> Subject: Re: Input taglibs - enhancements
> 
> 
> Hi Karl,
> 
> I'd like to see the following bugs solved in the this update.
> 
> 12688 - Add support for xslt pages.  a simple fix to comply with xls
> transformations.
> 
> 12189 - Setting default values for the <input:checkbox> Tag.  this
> allows the default value to be set by the request attribute
> 
> Feel free to contact me if you have any questions.
> 
> Regards,
> 
> 
> Curt Wilhelm
> email: Curt.Wilhelm@Sun.Com
> 
> 
> Karl von Randow wrote:
> 
>>Hi guys,
>>
>>Seems like there's quite a bit of interest in the input taglib at the
>>moment!
>>
>>I've uploaded the work I've done on the input taglib to
>>http://www.xk72.com/input/. I haven't updated usage.html yet, but the 
>>changes and main doc page (the autogen one) is updated.
>>
>>This covers most of the things that have been raised recently. Are we
>>at a point where we can proceed?
>>
>>Cheers,
>>k@rl
>>
>>-----Original Message-----
>>From: Shawn Bayern [mailto:bayern@essentially.net]
>>Sent: Wednesday, 11 September 2002 7:45 a.m.
>>To: Tag Libraries Developers List
>>Subject: Re: Input taglibs - enhancements
>>
>>
>>Sounds good to me.  Karl has good ideas for the Input Taglib, and we
>>haven't had a new committer in a while; I think this would be a good 
>>way to ensure new contributions are handled, since I don't have much 
>>time these days to work on the Input Taglib.
>>
>>Shawn
>>
>>On Mon, 9 Sep 2002, Henri Yandell wrote:
>>
>>
>>
>>>If Shawn wants to kick off a Vote on it, I'm +1. The ideas sound good

>>>and worth exploring.
>>>
>>>Hen
>>>
>>>On Tue, 10 Sep 2002, Karl von Randow wrote:
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>I have been conversing with Shawn Bayern regarding enhancements to 
>>>>the input taglib, as follows:
>>>>
>>>>* Adding an attributesText attribute to each tag, allowing a string 
>>>>to be supplied with additional attributes for a tag. Eg. <input:text
>>>
>>>>name="email" attributesText='size="20" class="emailBox" 
>>>>onClick="return emailClicked()"'/>
>>>>
>>>>* Adding form bean functionality, similar to that offered in Struts,
>>>
>>>>where an input tag (or entire form) can take its value from a bean 
>>>>rather than the request.
>>>>
>>>>* Enabling the select tag to specify the order in which option 
>>>>elements are rendered, and adding an input:option tag to facilitate 
>>>>smaller select lists.
>>>>
>>>>* Adding an input:hidden tag for hidden form elements.
>>>>
>>>>I have made these modifications for use in several projects I am 
>>>>working on and have found them very useful. I'd appreciate some 
>>>>feedback and guidance on how to proceed as I would like to 
>>>>contribute these back to the taglib project. Shawn has offered his 
>>>>nomination as a committer, and his blessing to take over active 
>>>>maintenance of the Input Taglib.
>>>>
>>>>Kind regards,
>>>>Karl
>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>
>><ma...@jakarta.apache.org>
>>
>>>>For additional commands, e-mail: 
>>>><ma...@jakarta.apache.org>
>>>>
>>>>
>>>--
>>>To unsubscribe, e-mail:
>>
>><ma...@jakarta.apache.org>
>>
>>>For additional commands, e-mail: 
>>><ma...@jakarta.apache.org>
>>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail: 
>><ma...@jakarta.apache.org>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
> 
> <ma...@jakarta.apache.org>
> 
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
> 
> 
> 
> --
> To unsubscribe, e-mail: 
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 
> 

-- 
Curt Wilhelm
Sun ONE Studio - Release Engineering
tel: x69245 - 925-264-4278
cell: 925-323-8931
email: Curt.Wilhelm@Sun.Com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>