i had originally done exactly what you proposed. but there are a two major flaws and a one minor architectural issues.
1) try to sort your table. all checked selections are lost. 2) try to paginate your table. all checked selections are lost. 3) checkboxes and other input fields are core to a table, i disagree with you argument. find a table used in a production system, and you will find the ability to select items with checkboxes for things like multiple delete, etc. plus, your example is using struts, not everyone out there is using struts (even though they should). and finally, where did your variable 'number' come from. is it in the data bean? if so, you have put view logic in your model. now to do sorting and pagination under your supposition, you'd have to have an action to handle the form submission for sorting and pagination, something i believe should be avoided. to avoid this complexity at the end user's level, it would be much better to "bake" these common elements into the table itself. thoughts? steve ----- Original Message ----- From: "John York" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 01, 2004 10:22 AM Subject: Re: [displaytag-devel] checkboxes and other types > I've used checkboxes before with this tag, why do you need to implement > it as part of the tag itself? All these other issues come up becuase of > this simple thing not working, so it seems to me, it'd be better to make > some enhancement to get the checkboxes working without having to add > them directly to the code. In my mind, this type of thing is not within > the scope of this project. Since you should be able to customize most of > what is output within the table, why can't you just do this? > > <form ...> > > <display:table ...> > <display:column property="number"> > <html:checkbox name="formName" property="checkboxes[<%=number%>]"> > Checkbox <bean:write name="number"/> > </html:checkbox> > </display:column> > </display:table> > > </form ...> > > All you'd need for this with struts is a form with a checkbox array in > it. the collection you're iterating over would need to have a value in > it indicating the current position within the entire collection, so you > could just create a 'number' field with values 0 - n, where n is he > total number of elements. > > The only other thing you might need with paging is adding a hidden field > within the form declaring the start and end indexes, so you know which > fields were actually visible when the form was submitted. > > Does this do what you need, or am I missing something? > > John > > > steven melzer wrote: > > > hello all, > > > > i am very impressed with the displaytags and have been using them for > > a few weeks. i want to thank you for creating them and open sourcing > > the project. > > > > i have a need to add checkboxes to a table for selections. i have > > seen code in the mailing lists on how to create a checkbox decorator > > to handle this. i implemented it and it worked. however, i need some > > additional functionality with the checkboxes including support for > > checkboxes under sorting and under paging, both of which do not work > > today. > > > > as such, i have started designing and implementing a solution to > > handle this. > > > > to begin, i created two additional ColumnTag attributes, "type" and > > "name". type would be a value such as "checkbox", "radio", "image", > > "textbox". the name attribute would be used in conjunction with type > > to give the input field a name. for a checkbox and radio, if the name > > isn't specified, the default name with be "selected". this is an > > important feature. the property attribute today would define the > > value of the input field. this is quite "struts-like" and gives tag > > users lots of flexibility. i modified the ColumnTag, HeaderCell, and > > TableTag classes, as well as the tld, to do this. i have enclosed the > > code. it is not properly commented (sorry, i will correct this later) > > and is not complete (i only have been focusing on the checkbox right > > now), but will give you an idea of what i am thinking of. > > > > if you are comfortable with part 1 above, then part 2 is where the big > > changes happen. since input fields require a form to submit, then a > > form tag is added to the beginning of the table and the end of the > > table. the name of the form is the name of the of the table. this > > should be innocuous, except in the case where a developer puts the > > displaytag inside another form tag. this would cause problems because > > html does not support nested form tags. in my experience this > > shouldn't be a problem since the only reason to put a table in a form > > tag is to capture things like the checkboxes for selection, which we > > are going to handle with the displaytags own form tag. give that one > > some thought. > > > > the TableTag will need an additional attribute "form", which defines > > where the form tag will post to. this will be anywhere the user wants > > and doesn't need to be any special class, jsp, or servlet. > > > > to handle sorting and paging, however, the displaytag will need to > > "submit" the input field selections to capture these values. but, the > > form tag has already been defined as a user defined action outside of > > the displaytag constructs. so, instead, the displaytag will need to > > capture the input field data without submitting. there are two ways > > that i can percieve to handle this: > > 1) alter the form action location dynamically in javascript and then > > submit, and send the action back to the displaytag jsp page we are on. > > 2) instead of submitting, assemble (as a get) the checkbox selections > > as part of the anchor hyperlink in the sort headers and paging headers. > > both of these are simple javascript scripts and can work in all > > browser, IE3.0 or greater, NS 2.2 or greater. the javascript could be > > added above the table as a script. > > so the question is, why the form tag at all if we can pass the data > > without the need for a real submit. this "fake" submits would only > > apply to thing within the displaytag. things outside of the > > displaytag, such as the buttons to actually do the work on the > > selected items, such as "delete", "process", etc. would still require > > you to post the data to the applications custom actions. > > > > but this still doesn't get me where i want to be, since i still need a > > way to know, when a list is sorting, which selections where checked. > > in my case, i could associate the checkbox property to a unique value > > which i can compare against. but i can envision this would not work > > in all cases. so instead, there needs to be some external way to map > > the selection checkboxes back to the items in the list without using a > > row number (since sorting would change that) or "unique value search" > > (also terribly slow). > > the best i have come up with (and this breaks the MVC rules badly) is > > to create an interface called Selectable, the all data beans in the > > list used by displaytag would need to implement (at least to use this > > new functionality). the Selectable interface would have a > > getSelected() and setSelected() methods. also, a SelectableDataBean > > would implement this interface so that any data bean could subclass it > > and would just "work" with the selection displaytag functions. > > > > obviously, i haven't done anything outside of the code i have sent and > > therefore am looking for feedback on the code i sent and the idea of > > adding the type and name attributes. then, i am looking for some > > suggestions of the rest of my design. > > > > i believe no matter what the eventual solution, this functionality is > > imparative to move the displaytag to the next level of usability. > > > > thanks, > > steven melzer > > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > displaytag-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/displaytag-devel ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
