Not every object is displayable which is why Object doesn't
contain the mechanism you ask for. In fact, the majority of objects are
*not* displayable. When adding this mechanism in Wicket, please try to
only add the property where it makes sense and in the manner that makes
sense. To me, getDisplayString() could turn out to be too generic and a
more component-specific method would be preferred . . .
I guess what I am saying is: lets get some specific examples of
where you need this functionality and see what makes sense there. I
don't think you can apply this property blindly.
Gili
On Wed, 26 Jan 2005 13:45:49 -0800, Jonathan Locke wrote:
>
>
>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
>
-------------------------------------------------------
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
