dev members, i am surpised and disappointed to hear that there is an implementation of the editable table that was not implemented. weblogic's table tag has full support for editing (albeit proprietary). my previous company a year ago wrote a tags to support editable tables (albeit specific to our company needs). i believe you cannot have a full functioning table without editing capabilities.
john, the issue is a standard mechanism to support selectable items. the post and get are just means to an end. i proposed a get in my original email actually. a post has another set of issues. a post would mean that the table would need to submit to a form element that would be outside of the displaytag. once you leave the comfort of you custom tags, it gets complicated for the end user. the posted form (a struts action for example) would now have to be cognizant of all the attributes that the displaytag now handles to support sorting and paging. alternatively, you could write a displaytag action class (or just a regular servlet) that handles the displaytag attributes, but then the user still needs to include the servlet in the web.xml file and make other references to it outside of the displaytag. the problem with a tag wrapping the displaytag is the displaytag inherently cannot support input fields. today, sorting and paging just do not supply a hook to update an editable field. all, i believe that the displaytag can completely self managed input fields with a good, thought-out design. obviously tolga proposed (and implemented) one. i am merely proposing one currently (and i have thought of several ways to simplify my original design). i need a definitive answer from the members and contributors of the project whether there is interest in making the tag support editable tables. if not, i will continue to look elsewhere, since i do not feel like making changes to the displaytag and then have to manage my own changes with new displaytag changes. tolga, can you explain how you are supporting editable tags, i.e. how to manage checkbox state when the table is sorted. how to manage checkbox state when a button outside of the displaytag is clicked, such as a "delete selected" button. thanks, steve ----- Original Message ----- From: "Dr. Tolga Yalcinkaya" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 01, 2004 1:17 PM Subject: Re: [displaytag-devel] checkboxes and other types > We have implemented a fully editable version of this tag library and > submitted as a contribution a while back (check the patches section > under source forge project). It deals with all the issues that Steve > is raising, more... > > I still do not understand why you guys insist on stating that the > editable display tag is not in the scope of this tag library! > Obviously there is a need and people have been asking for this for a > long time, and there are several reference implementations (besides > ours) out there. > > So, I agree with Steve... Furthermore I say it is time for you guys to > accept the requirements/requests/wishes from the greater user community, > and implement the editable tag library!!! > > T. > > > > John York wrote: > > > So it seems that the main problem is with maintaining the checkbox > > state after clicking on a paging or sorting link. If these links were > > made POSTs instead of GETs, that would solve this problem, right? So > > it seems that the addition to the table tag would be to allow the user > > to have the HTML generated in a way to submit the form for you. > > > > 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 > > > > > > > > > ------------------------------------------------------- > 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
