Also depending on toString() is not the way we want. toString should be used for debugging not display.
ok. i can buy that too. but, we're already using toString() everywhere except for this place... perhaps we should fix that.
also, if this is our approach, shouldn't the displayString() method be accessed through a separate interface like IDisplayString so that it can be generic to all model objects?
What model objects are you talking about?
Because i don't have that problem with any other model that i know of currently
For example if form has a Model. Then elements from that model are already get through the property model like: user.name
Then the users name is output. So there we have already that control.
Are you saying you have an example besides the dropdowns values list where we do toString() on Objects that are not the base onces (String/Numbers/Dates)
and also: What if we want one time just the lastname to display and another time first and lastname??
technically you could do this in your toString(), but it sounds like we're not going to use that.
what i like about toString() is that everybody already knows it. what i don't like about it is what you point about debugging strings...
using toString to display objects is a bad idee.
I never do that, if i program in swing and i need to display an object in a table or list, i always write a Renderer for that.
That is the way it should be done.
as i said toString is for debugging. For example in the toString of a persistent object i don't want to see only the name or firstname + lastname
What i want to see there for for example a User persistent object class is this:
User[id=1,name=Jonathan]
So that for example debug or log output is telling me the right info.
i wish Object had been built with toDebugString() and toDisplayString() or something...
That would be handy except that the toDisplayString can or should return different things under different circumstances.
The problem if you don't extend list then you can't do a drop in replacement into the DropDown anyway
because it needs a List (or Collection) for getting the values.
you could still get a List that has the values in it from the detachable container. that feels more like the right approach to me, even if it does involve wrapping elements in the list...
No this is really a thing what i don't like.
Because this is so much more work looping everytime over the complete collection to wrap it.
agree. but what we really want is a single model for dropdown choice values that is generic and can be easily extended. 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.
NOO (sorry about this shouting :))
don't do it in a single model. Struts had this in some form, i hate this
Because then you get very large models.. because then the selection and the values that it can choose must both come from the same model class and if you have 5 combo's on that form
the model is getting very large.
for example a Model around a user class could be this:
UserModel
{
User user;String getName() void setName(String)
// Selection of the combo Role getRole() void setRole(Role)
// the values of the combo:
Collection getRoles()
}
and that last 3 method should be there for every drop down/list you have.
This is horrible and pushes things to simple models that suddenly becomes complex.
But i really don't mind that because it is a list anyway and you will use an ArrayList 99% of the times for it anyway.
this does work now, but i suspect that the fragility in this kind of structure is a risk for future evolution. and again, i really dislike that we need more than Collection or IModel semantics to implement the various list classes. it works, but it's not general and elegant enough for me to love it. those classes shouldn't need know anything special about how their models are put together... a list driven component should access its model through a single simple interface. Collection seems acceptable for that, but i'm sceptical about that too (and i'll admit to writing that probable mistake ;-)). i really think that a ListModel and DetachableListModel with wrappers for ids would be better. then people can easily create new unthought-of models in the future.
How wrappers around id's?
You have to know 2 things: What is the id and what should be displayed. This is without touching the persistent classes itself just not possible.
After that you also should be able to get back what object is really selected!
So the string that you get like "1" should be mapped to the persistent object that is in the collection and that object must be set as the selection in the model
First "1" can be a long or a integer or even just a string in that persistent obejct. It can be anything. So the dropdown must be able to lookup it.
No the IIdList implementation does that and it knows what it should be and it knows how it can compare it so when it is equals.
Of course this can be more automatic by using converters.. So asking what the return type is of the getID method and then convert the string to that id
then walk over the complete list getting the id value and compare it with it.
i personally find this way of working with the IIdList just fine. I find it easy to use and gives me full control.
i see that this is a practical thing that is useful. it's just that the structure here feels too specialized and potentially fragile to me for a public API... i was always bothered by the Collection parameter here and think we should have a nice elegant model class now...
But tell me. What methods would you introduce in such a model?? You have at least to be able to iterate over it somehow...
johan
------------------------------------------------------- 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
