exactly Repeaters is very nice that the populateItem is generified.. I think
that is really handy..
And if the EditPage now wanted a specific type then you need now to cast at
that place..
I thing that the example below is exactly the thing that generics are pretty
good:
populateItem(ListItem<Person> item) {
add(new Link<Person>("edit", item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
(and EditPage is by itself already generified to <Person>)
This is just a perfect thing that i say yes very nice you see exactly what
the code should do
and cant say that this is really verbose..
johan
On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst <
[EMAIL PROTECTED]> wrote:
> 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]
>
>
