On Wed, 10 Aug 2005 19:37:32 -0700, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
Yes there is a synergy but the current methods are still
quite different - have to think abaout it. In case we make no
model mapping (a removeall for no iprimarykeyprovider) than
the counter is not realy needed.
Indeed, simply removeall() and use a local counter for the ids. We can
still
wrap it in a iprimarykeyprovider.
Yes. Generally: I think if DataView is thought for relational DBs only
than the primaryKey() should be kept in the interface, otherwise it should
be not and equals should be used. Ggenerating primaryKeys without a
backing DB for general Java Objects is not always easy and not the java
way - equals is. The option of iprimarykeyprovider should remain in any
case. Your decision.
Another thing:
Maybe in onRender instead of rendering over the viewSize we
could use the Component.size().
If we do this we would have to lock the add()/remove()/etc methods in the
dataview.
Or what we can do is record the number of actual dataitems added in
onbeginrequest in a field, and use that in render(). Thoughts?
Why do we have to lock them?
Just of my head: A simple thing would be if we make a super class of
DataView (call it TableView) where the user has to add/remove DataItems on
his own - no model no onBeginRequest(). The user could add the DataItems
from the outside - something like JGoodies PanelBuilder - or by overriding
onBeginRequest. TableView would only onRender() repeat over them.
TableView would have no model at all - perfect decoupling;-).
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
