Johan Compagner wrote:
no not convinced
I hate a that a UI framework forces me to use a specific interface for my persistent objecsts
Those are 2 worlds..
ok. i can buy that. so, let's implement a solution that doesn't require this.
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?
this might give more flexibility for the lastname/firstname display problem in every model. the base model implementation could call toString() i suppose to make it less work on implementers...
obviously, i'm just brainstorming here since it sounds to me like you're right and the pattern might be applied throughout the project... what do you think about that?
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...
i wish Object had been built with toDebugString() and toDisplayString() or something...
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...
So if we don't extends list then we also should change the constructor of dropdown..
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.
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.
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...
johan
Jonathan Locke wrote:
if we decide this is the best approach, which is fine, maybe we could remove the List inheritance bit and put it in the model folder?
i dunno... did i convince you any more with my last arguments? ;-)
Johan Compagner wrote:
yes i also thought about that (that the objects had a display/id)
But then we would have to introduce a Interface in wicket (ISupportIdDisplay) that is completely drilled down to the persistence layer of the application
So the hibernate objects would have to implement a interface of wicket to show them in a DropDown/List
I really don't like that.
I also gould build a wrapper around those objects. But that is very time/memory consuming because now i just load the results of a hibernate query into
the IIdList impl. Then i have to loop through all of them and wrap them into an object.
So the best thing is just some glue between the DropDown and the Hibernate List like the IIdList
joihan
Jonathan Locke wrote:
Johan Compagner wrote:
i am making an example right now for the examples project.
I stil don't see how you could make a DetachableModel implentation for this...
ok the attach and the deattach do come from that one. But that are just 2 methods that are the same
setObject and getObject d on't make any sense for those because i need:
getDisplayValue(index row) and getRealValue(index row) and some others.
i see what you mean, but i was hoping this could be more oo... where each entry in the detachable list model has a display value and an id somehow
And remember the IIdList is NOT the base model, that every component have, where the selection is stored (the IModel)
And the selection values shouldn't also come from that Base Model because that would clutter the Model implementation greatly.
The AbstractDropDownChoice just does have 2 models.. That is something we can't go around..
One for the selection (IModel), and one for its list.(IIdModel)
sure, i was just thinking two IModels.
If you compare to swing then the IIdLis is a cellrenderer implementation..
I still don't see how you could make a DetachableModel for this because people just need to implement at least 3-4 methods
for a select to be able to get all the values and set the selected object back into the real IModel.
me either, but i'm still thinking here...
johan
Jonathan Locke wrote:
done with persistence / cookie refactor and thinking about other little things to fix.
i think i'm going to try refactoring IIdList tomorrow into something more like DetachableListModel. is any reason anyone thinks this won't work out? i'm curious why IIdList was the approach and not some kind of DetachableListModel... was it just "oh, didn't think of that" or am i missing something? (you could save me a bunch of time in doing this refactor if there was a good reason why the wicket.model classes didn't appeal for doing this).
thanks,
jon
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
------------------------------------------------------- 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
------------------------------------------------------- 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
------------------------------------------------------- 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
------------------------------------------------------- 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
