agree. but what we really want is a single model for dropdown choice values that is generic and can be easily extended.
That would be exellent!
and so this is where i really feel like we're going into the ditch... the Collection constructor should be sufficient for any dropdown or list because it's a very nice elegant interface. if we make a detachable list model which yields a normal Collection through a getter method, then we can put all this code back the way it was because it doesn't have to know about these "special" collections. the idea that any component should have to know details about IIdList is the most bothersome thing about it all to me and i think the reason i started this discussion... alternatively, i think it would make me feel even better if there was an IListModel (extends IModel, probably) with a ListModel implementation and a DetachableListModel implementation for databases.
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
