Answers below...
Gwyn Evans wrote:
Hi,
The two things that I really have reservations about are :-
(1) renaming Table to List
- I didn't think that was agreed & I think it would be a big
mistake - The result, where you'd have to explicitly specify which
List you meant would be very off-putting.
and
I think we (allmost?) agreed on using ListView. List would be problematic, though it is the best name for the component.
(5) an empty table is an exceptionYes. I still feel very strongly that an empty list *should not* throw and exception. There's nothing wrong with providing an empty list. Just like there's nothing wrong with providing and empty string to a Label or e.g. an empty tree to a tree component. The effect of throwing an exception when an empty model is provided would be that it would be more difficult to use the table component in a generic fashion as you allways would have to check the contents of your model before even adding the component.
- Again, I think that would be wrong. If I do a query on a DB, I
may get an empty ResultSet, but I can still use the standard 'while
(rs.next())' construct to process it. Wicket should be doing the
same, not requiring speoial case code.
I think I agree with Juergens' other points. They should be tested well though. Last week I added some unit tests for tables/ tablenavigation, and created a basic jWebUnit test in the examples project. Anyone starting the refactor of table/ tablenavigation, please use/ elaborate these tests (especially the ones in the core project).
Regards,
Eelco
The other changes seem fine, but will they increase the complexity of the 'default' usage significantly? (I don't think so, but haven't gone through them in depth as I've not got that much familiarity with the existing code.)
/Gwyn
On Wed, 17 Nov 2004 17:44:13 +0100, Donnerstag, Juergen
<[EMAIL PROTECTED]> wrote:
Tables, let's try it again. The current Table implementation has several weaknesses:
1) There seems to be an common understanding that the class names Table and Cell are not a perfect fit. Did we already agree on renaming Table to List and Cell to ListItem? That is what I would propose. However only if we move the Table's pageing functionality out of it.
2) Maybe Table instead of PagedTable and RowItem (subclass of Cell with alternating styles) are good names for html like table, as they now reflect there purpose: markup tables and their respective rows. And paging is a typical functionality of a html table. Currently the Table implementation deals with pages, which is really no core functionality of a general table
3) You don't always want to slice your table in equally sized pages. A more general and far more flexible approach is to use a "view". "Views" have a startIndex and a viewSize. They are similiar to sublists, except that you don't copy the elements into another List, but make use of a startIndex and viewSize. Which is faster and avoids creating plenty of short-lived java objects. Table pages are easily implemented with this approach as well (see 3.a as well)
3.a) The List returned by List.subList() can not be used to display a portion of all list elements because a) the List implementation returned it not subclass-able and b) not serializable. For Wicket models being Serializable is a prerequisite. Thus, currently you have to (shallow) copy (addAll) the elements into another List.
4) You do not always know at page construction time (only during page.handleRender) what the size of the table will be, because of lazy loading the data. Subtotals and Grouping are other good examples. In general, there are two approaches: You may calculate the subtotals upfront, or while your are rendering (populateCell). Or you may determine the groups (and subgroups) upfront or on-the-fly while rendering. In both cases you want to /deliberatly/ stop further processing of the table. The current Table implementation assumes a fixed size List with no possibility to "break" the loop. And the solutions I can think of are: a) populateCell() and renderCell() return a boolean value with false breaking the loop b) an additional method e.g. breakLoop(true) or c) use of Iterator instead of for(i=...) with the possiblity to implement your own hasNext() implementation.
5) I still think that an empty table is an exception and should be treated deliberatly outside of the Table and the Wicket framework. Which, by the way, would be consistent with current Wicket components. None of them is currently disabling themselves automatically.
6) A Table Navigation bar is a Table itself. A table which model objects are the table numbers. The page number is equal to cell.getIndex(). Hence, the navigaton bars underlying model object is easy to create, but we are creating java objects for nothing, just to meet the weaknesses of the current implementation. What is needed is a Table implementation, which does not rely on the model list object (and it's size), but solely on startIndex and viewSize. I know that the navigation bar is the only situation where I can think of where this makes sense, but table navigation bars are very common. In order not to confuse users of Wicket, I do not propose to use a kind of BaseTable, but to use methods which are subclassable. E.g. getListSize() which in case of a normal table provides the page or table size, but in case of the navigation bar the table.pageCount(). populateCell() than uses cell.getIndex() instead of the model list object to populate the cell. Thus we achieve the flexibility required, without a base class, and without the need for redundant model objects for the navigation bar.
Suggestions: A) rename Table => List; rename Cell => ListItem; rename PagedTable => Table; provide RowItem class
B) implement startIndex and viewSize in List; make necessary changes to Table
C) Throw an exception if Lists (and Table) models object lists are empty
D) Implement necessary changes (as suggest above) for more elegant navigation bars
E) Don't know which is the best solution to break the loop
Any ideas?
Regards Juergen
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Wicket-develop mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Wicket-develop mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-develop
