As for the number thing, maybe that was a bad example. That's just the first thing that came to mind. I suppose each element at a minimum would need to maintain whether it is selected or not. However you do that is up to you.
This method is not unique to struts, I only used a struts example because that is what I thought you were asking for.
Of course, this whole discussion is based on allowing users to select options that aren't currently displayed on the page. Many UI designers would argue that this is a very dangerous thing to do. If you add some other sort of function button on the page, most users will assume that the button only operates on what they can see. Our company has done this in the past and then decided that it created too much confusion for our users. Of course, if this is an internal tool or everyone is well-trained how to use it, then you can make it work.
I do agree that this is a valuable thing to do, but I still think this is out of the scope of this tag. I'd rather see this implemented as it's own tag that could just wrap around the display tag. Something like this:
<display:form ...> <display:table ...> ... </display:table> </display:form>
This could then handle the possibilities of multiple forms on the same page, since the form actions could be constructed in such a way to identify the tables being operated on. Then, maybe you have the additional data that remembers what the form state is as an attribute to the <display:form> tag.
I know some of our other contributors have used forms and input elements in their tables before, so I'm interested to see what they think about this. I know Matt had implemented much of this in the past, I'm just not sure where it ended up.
John
steven melzer wrote:
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
------------------------------------------------------- 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
