I often do the following:
populateItem(ListItem item) {
add(new Link("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}
So both are used often, but mostly to pass things around.
Martijn
On Thu, May 22, 2008 at 11:25 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> getModel() i agree, but getModelObject() is something that is used the most
> if i have to guess.
>
> Because in an onSubmit() of a form or a onClick of a Link what do most of
> you do?
>
> onSubmit()
> {
> dao.save(getModelObject())
> }
>
> onClick()
> {
> dao.delete(getModelObject())
> }
>
> johan
>
> On Thu, May 22, 2008 at 10:05 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
>> Although I'm not sure how many people call getModel/getModelObject
>> anyway. I think it's mostly about ListItems etc an i doubt anyone
>> would subclass it just because of getModel/getModelObject...
>>
>> -Matej
>>
>> On Thu, May 22, 2008 at 10:04 AM, Matej Knopp <[EMAIL PROTECTED]>
>> wrote:
>> > I would all be easier if getModel() and getModelObject() weren't
>> > final. (I know there's a reason why they are, I'm not questioning it).
>> >
>> > Then in your component subclass you coud do IModel<Integer> getModel()
>> > { return (IModel<Integer>)super.getModel() }, similiar with
>> > getmodelobject so you wouldn't have casts all over places and it would
>> > be safer too).
>> >
>> > -Matej
>> >
>> > On Thu, May 22, 2008 at 9:39 AM, Johan Compagner <[EMAIL PROTECTED]>
>> wrote:
>> >> It isnt all or nothing.. i never said that
>> >>
>> >> I just say if you dont want Component but you do want IModel
>> >> then you will get a warning at getModel()
>> >> we as a framework shouldnt hide the warning at that call.
>> >>
>> >> But i am also curious how many people get really the model back from a
>> >> component (not counting specific places like repeaters.onpopuplate)
>> >>
>> >> because i think most people do component.getModelObject() which then
>> needs a
>> >> cast
>> >>
>> >> But i like that extra helper method way more then having an extra
>> >> getUnsafeModel() method..
>> >> because thats explicit a developer has to really choose for it.
>> >>
>> >> i think there are 3 options
>> >>
>> >> 1> keep it what we have now, tweak it with the feedback we get from
>> 1.4M2
>> >> 2> drop it on Component only and have a class like you described above
>> to do
>> >> this: IModel<String> model = Unsafe.cast(component.getModel()); (its
>> still
>> >> a hack and a sense of false security but ok. if people really want
>> this..)
>> >> 3> drop it on Component and Model
>> >>
>> >>
>> >> i am +1 on 1
>> >> and -0 on 2 and 3
>> >>
>> >> I still think it is not bad. and you can come around it really easy by
>> just
>> >> creating a few extra classes like
>> >>
>> >> StringLabel
>> >> NumberLabel
>> >> StringTextField
>> >> NumberTextField
>> >>
>> >> if you only have a few of those extra all your code is cleanup
>> >>
>> >> johan
>> >>
>> >> On Thu, May 22, 2008 at 9:12 AM, Joni Freeman <[EMAIL PROTECTED]>
>> wrote:
>> >>
>> >>> Yeah, it could even be in its separate utility class:
>> >>>
>> >>> interface IModel<T> {}
>> >>>
>> >>> class Component {
>> >>> private IModel<?> model;
>> >>>
>> >>> public IModel<?> getModel() {
>> >>> return model;
>> >>> }
>> >>> }
>> >>>
>> >>> public class Unsafe {
>> >>> public static <T> IModel<T> cast(IModel<?> model) {
>> >>> return (IModel<T>) model;
>> >>> }
>> >>> }
>> >>>
>> >>> class MyComp extends Component {
>> >>> public MyComp() {
>> >>> IModel<Integer> model = Unsafe.cast(getModel());
>> >>> }
>> >>> }
>> >>>
>> >>> I'm merely pointing out that there exists a solution to do unsafe cast
>> >>> without getting compiler warning. Just like normal casts are handled.
>> >>>
>> >>> I don't think Johan's all or nothing proposition is very pragmatic one.
>> >>> Without generic IModel we do not get any API discoverability and our
>> >>> APIs continue to suck. For instance, how can API user know what kind of
>> >>> model this needs: MyJuicyComponent(String id, IModel model). At one
>> >>> point we did this: MyJuicyComponent(String id, IModel/*<Chocolate>*/
>> >>> model) but this convention is far from optimal. To be sure, one needs
>> to
>> >>> browse the sources...
>> >>>
>> >>> Joni
>> >>>
>> >>> On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
>> >>> > Well, maybe it really is a hack that's too ugly. We might have two
>> >>> methods,
>> >>> >
>> >>> > default getModel() that doesn't cast it and alternative convenience
>> >>> > one that does.
>> >>> >
>> >>> > -Matej
>> >>> >
>> >>> > On Wed, May 21, 2008 at 10:10 PM, Matej Knopp <[EMAIL PROTECTED]
>> >
>> >>> wrote:
>> >>> > > class Component {
>> >>> > > private IModel<?> model;
>> >>> > >
>> >>> > > public <T> IModel<T> getModel() {
>> >>> > > return (IModel<T>) model;
>> >>> > > }
>> >>> > > }
>> >>> > >
>> >>> > > I like this. Even with the possible class cast exception. Because
>> >>> > > without generics, it doesn't leave you no other option than to cast
>> it
>> >>> > > to your model, which isn't much better either, as you get the same
>> >>> > > result except that it looks uglier.
>> >>> > >
>> >>> > > -Matej
>> >>> > >
>> >>> > > On Wed, May 21, 2008 at 10:07 PM, Johan Compagner <
>> >>> [EMAIL PROTECTED]> wrote:
>> >>> > >> no i am really against that falls <V> IModel<V> getModel() method
>> >>> > >> that really abuses everything that generics stands for. For such a
>> >>> basic
>> >>> > >> thing.
>> >>> > >> this is really bad programming
>> >>> > >> If we drop it we also pretty much drop it from IModel or have
>> warnings
>> >>> in
>> >>> > >> the user code.
>> >>> > >>
>> >>> > >> But then drop it completely is better because then we have to do a
>> >>> cast and
>> >>> > >> you really think about that
>> >>> > >> Not having that fake assurance..
>> >>> > >>
>> >>> > >> johan
>> >>> > >>
>> >>> > >>
>> >>> > >> On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst <
>> >>> > >> [EMAIL PROTECTED]> wrote:
>> >>> > >>
>> >>> > >>> Before we do a vote I want to make sure what our alternatives
>> are.
>> >>> > >>>
>> >>> > >>> I still like Joni's alternative. I don't think they are an
>> >>> > >>> abomination, because the /potential/ class cast exception you get
>> is
>> >>> > >>> the same as with current 1.3. But the benefit of documenting the
>> >>> model
>> >>> > >>> parameters in DDC, LV, etc. is HUGE.
>> >>> > >>>
>> >>> > >>> I really appreciate the time and effort that went into
>> implementing
>> >>> > >>> the generification. But I also see what kind of mess this brought
>> and
>> >>> > >>> I really don't like the Component generification part.
>> >>> > >>>
>> >>> > >>> Martijn
>> >>> > >>>
>> >>> > >>> On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg <
>> >>> [EMAIL PROTECTED]>
>> >>> > >>> wrote:
>> >>> > >>> > ok so we pretty much have some core people wanting to back out
>> the
>> >>> > >>> > generics support.
>> >>> > >>> >
>> >>> > >>> > shall we start a vote? johan, gerolf and i have spent a
>> ridiculous
>> >>> > >>> > amount of time trying to generify the codebase and remove all
>> the
>> >>> > >>> > shitty warnings. if there is even a slight chance of this
>> getting
>> >>> > >>> > backed out i do not want to spend any more time on this until
>> the
>> >>> > >>> > issue is resolved.
>> >>> > >>> >
>> >>> > >>> > also we should halt m2 until this is resolved.
>> >>> > >>> >
>> >>> > >>> > personally i do not mind backing out generics, they turned out
>> to
>> >>> be
>> >>> > >>> > quiet a disappointment for me as well, but my feelings about
>> this
>> >>> are
>> >>> > >>> > not strong.
>> >>> > >>> >
>> >>> > >>> > we can still use generics such as setresponsepage(class<?
>> extends
>> >>> > >>> > page>) to gain bits of typesafety here and there, but if we
>> remove
>> >>> > >>> > them from component we obviously have to remove them from
>> imodel.
>> >>> > >>> >
>> >>> > >>> > so lets start a vote with a parallel discussion thread just for
>> >>> this.
>> >>> > >>> >
>> >>> > >>> > -igor
>> >>> > >>> >
>> >>> > >>> > On Wed, May 21, 2008 at 8:19 AM, Martijn Dashorst
>> >>> > >>> > <[EMAIL PROTECTED]> wrote:
>> >>> > >>> >> On Wed, May 21, 2008 at 5:05 PM, Johan Compagner <
>> >>> [EMAIL PROTECTED]>
>> >>> > >>> wrote:
>> >>> > >>> >>> Generics is type safety
>> >>> > >>> >>
>> >>> > >>> >> I didn't say generics isn't type safety. But APPLYING generics
>> for
>> >>> the
>> >>> > >>> >> Wicket framework API *ISN'T* its primary goal. API clarity
>> *IS*.
>> >>> Less
>> >>> > >>> >> questions on the mailing list regarding DDC, ListView, etc. is
>> the
>> >>> > >>> >> main goal for applying generics in Wicket.
>> >>> > >>> >>
>> >>> > >>> >>> I am against this abuse big time -1000 from me
>> >>> > >>> >>
>> >>> > >>> >> I'm -1000000000000000^1000000000000 for abusing my eyes and
>> brain
>> >>> in
>> >>> > >>> >> the way it currently is implemented in Wicket. It is
>> completely
>> >>> and
>> >>> > >>> >> utterly unusable for beginners. There is no way this is going
>> to
>> >>> make
>> >>> > >>> >> the number of questions on the mailinglist less (other than by
>> >>> scaring
>> >>> > >>> >> away anyone that wants to actually use the framework)
>> >>> > >>> >>
>> >>> > >>> >> Martijn
>> >>> > >>> >>
>> >>> > >>> >>
>> >>> ---------------------------------------------------------------------
>> >>> > >>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> > >>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>> > >>> >>
>> >>> > >>> >>
>> >>> > >>> >
>> >>> > >>> >
>> >>> ---------------------------------------------------------------------
>> >>> > >>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> > >>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >>> > >>> >
>> >>> > >>> >
>> >>> > >>>
>> >>> > >>>
>> >>> > >>>
>> >>> > >>> --
>> >>> > >>> Buy Wicket in Action: http://manning.com/dashorst
>> >>> > >>> Apache Wicket 1.3.3 is released
>> >>> > >>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>> >>> > >>>
>> >>> > >>>
>> ---------------------------------------------------------------------
>> >>> > >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> > >>> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>> > >>>
>> >>> > >>>
>> >>> > >>
>> >>> > >
>> >>> >
>> >>> > ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >>> >
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>>
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
