-- Check box decorators, -- Add new rows, -- Edit/Update existing rows (inline editing), -- Delete existing rows.
It is already implemented using the earlier version.
See it in action at http://raibledesigns.com/display-edit/index.jsp
Tolga.
[EMAIL PROTECTED] wrote:
Aim ---
To enable a table to be created with the same functionality as the existing Display Tag, which can also be used as input for a form. Any changes should be backwards compatible, not add complications to the existing code and should be as simple as possible to implement and maintain.
Detail ------
We need to be able to create form input controls inside the table itself. In its simplest form we need to be able to specify the type of control that a cell will display, and inform its naming conventions. At present, the ColumnDectorator class allows a formatting of the tables underlying data for display purposes. The ColumnDecorator defines a single method which just takes the underlying value. For form controls, we need to be able to specify the type of control. If the control is being used for each cell in the specified column, and naming is not a problem then the existing ColumnDecorator is good enough. However for the input to be meaningful it would have to be named relative to its row in the table, for example "name[2]" would refer to a text input on the third row in the table if we were to adopt a standard array indexing model, as is standard practise where using forms as inputs in Struts.
Potential Solutions ------------------- 1.) On the face of it the simplest solution is to pass into the ColumnDecorator the row index of the cell being rendered - a similar approach is taken with the various Swing-based renderers which works very well (and is very flexible). This would be a very quick fix. The problem with this approach is that it requires a change to the ColumnDecorator interface, breaking backwards compatibility
2.) Another approach would be to subclass the existing TableTag to allow the use of a new type of ColumnDecorator class. Here the problem is that the use of the ColumnDecorator is buried several layers deep in the Column class itself, and reworking this code would be a significant refactoring effort.
3.) Add a new decorator type with a new interface, which is used in preference of the existing ColumnDecorator, effectively deprecating the old version. The new Decorator interface would be more similar to Swing-based renderers, and migration of ColumnDecorators to the new type would be trivial. Backwards compatibility is retained, although this does add extra code complexity.
Basically, I'm not sure how to proceed. I would really like this functionality and would be happy to work on implementing it - however there doesn't seem to be an easy solution! Comments/suggestions greatly appreciated...
sam
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
