generics

[Erik van Oosten]

In my current project I have:
10 Forms that use a CompoundPropertymodel and
5 Forms that have no model.

IMHO both Form forms :) should be easy to work with.

Regards,
    Erik.


Eelco Hillenius wrote:

>> thats my point. you work on fields of one object, true, but it does
>> not necessarily have to be the form's modelobject unless you use a
>> compound property model. eg
>>
>>        Form<Void> form = new Form<Void>("form")
>>        {
>>            protected void onSubmit() { value = dosomethingwith(symbol); }
>>        };
>>        add(form);
>>
>>        form.add(new TextField<String>("symbol", new
>> PropertyModel<String>(this, "symbol")));
>>
>> where [value] and [symbol] are clearly fields on the container that
>> parents the form. inside onsubmit i can just as easily access the
>> object directly without it being the model object of the form. now if
>> we factor out the form into a static inner or a top level class, just
>> like the link discussion, it becomes valuable to have the model.
>>    
>
> Yeah, you're right actually. I realize now that I rarely use Form's
> model directly. And I actually do the special stuff in the buttons
> anyway.
>
> Eelco
>
>
>  

--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Erik van Oosten]

In my current project we try to do everything by BookmarkablePageLinks.

Count:
- 1 Link with an abstractreadonlymodel
- 14 Links without model
- 13 bookmarkablepagelinks without model
- 2 ajaxfallbacklinks without model

in addition we have 4 many used subclasses of bookmarkablepagelink that
do not have a model.

Maybe not representative, but with 1 link with a model out of 30+ lead
me to think that Link without generics is just fine. For Forms I would
like to keep generics.

Regards,
    Erik.


Igor Vaynberg wrote:

> the question here is: do most people use the model in the Link or not?
>
> when you use compound property model in conjunction with form
> components you never call getmodel/object() on those either. what now?
> not generify form components? i dont think a strict criteria will
> work.
>
> some components fall into a gray area which needs to be discussed and
> generified on case by case basis. when i was generifying wicket my
> primary usecase is to use Link with a model so i went that way. start
> a discussion/vote and see where that goes in a different thread. i
> will be happy to go with what the majority thinks in this particular
> case.
>
> -igor
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

the 13 bookmarkable link are not really model things anyway :)

But this discussions just tells us that many people uses things many
different ways.
And that is just a problem to say what is the good way
So i think i am still +1 for a Link and a Generic/ModelLink

johan


On Wed, Jul 2, 2008 at 3:37 PM, Erik van Oosten <e.vanoosten@...>
wrote:

> In my current project we try to do everything by BookmarkablePageLinks.
>
> Count:
> - 1 Link with an abstractreadonlymodel
> - 14 Links without model
> - 13 bookmarkablepagelinks without model
> - 2 ajaxfallbacklinks without model
>
> in addition we have 4 many used subclasses of bookmarkablepagelink that do
> not have a model.
>
> Maybe not representative, but with 1 link with a model out of 30+ lead me
> to think that Link without generics is just fine. For Forms I would like to
> keep generics.
>
> Regards,
>   Erik.
>
>
> Igor Vaynberg wrote:
>
>> the question here is: do most people use the model in the Link or not?
>>
>> when you use compound property model in conjunction with form
>> components you never call getmodel/object() on those either. what now?
>> not generify form components? i dont think a strict criteria will
>> work.
>>
>> some components fall into a gray area which needs to be discussed and
>> generified on case by case basis. when i was generifying wicket my
>> primary usecase is to use Link with a model so i went that way. start
>> a discussion/vote and see where that goes in a different thread. i
>> will be happy to go with what the majority thinks in this particular
>> case.
>>
>> -igor
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Rodolfo Hansen-2]

IMHO too many ways to do the same thing makes a project very hard to
maintain.
Development generally becomes more expensive and error prone, as you forget
the initial mindset you where in when you started, or have the same
components used one way in here, and another way there.

One has to be wary of a framework that is too orthogonal. At least in my
opinion...
I like how you guys have treated the whole generics issue, precisely in the
sense that there wont be the choice of having the same component either
generified or ungenerified..

To be a little dramatic: A 100k line project where 50% of forms are
generified and the other are using casts doesn't seem very nice.

On Wed, Jul 2, 2008 at 9:43 AM, Johan Compagner <jcompagner@...>
wrote:

> the 13 bookmarkable link are not really model things anyway :)
>
> But this discussions just tells us that many people uses things many
> different ways.
> And that is just a problem to say what is the good way
> So i think i am still +1 for a Link and a Generic/ModelLink
>
> johan
>
>
> On Wed, Jul 2, 2008 at 3:37 PM, Erik van Oosten <e.vanoosten@...>
> wrote:
>
> > In my current project we try to do everything by BookmarkablePageLinks.
> >
> > Count:
> > - 1 Link with an abstractreadonlymodel
> > - 14 Links without model
> > - 13 bookmarkablepagelinks without model
> > - 2 ajaxfallbacklinks without model
> >
> > in addition we have 4 many used subclasses of bookmarkablepagelink that
> do
> > not have a model.
> >
> > Maybe not representative, but with 1 link with a model out of 30+ lead me
> > to think that Link without generics is just fine. For Forms I would like
> to
> > keep generics.
> >
> > Regards,
> >   Erik.
> >
> >
> > Igor Vaynberg wrote:
> >
> >> the question here is: do most people use the model in the Link or not?
> >>
> >> when you use compound property model in conjunction with form
> >> components you never call getmodel/object() on those either. what now?
> >> not generify form components? i dont think a strict criteria will
> >> work.
> >>
> >> some components fall into a gray area which needs to be discussed and
> >> generified on case by case basis. when i was generifying wicket my
> >> primary usecase is to use Link with a model so i went that way. start
> >> a discussion/vote and see where that goes in a different thread. i
> >> will be happy to go with what the majority thinks in this particular
> >> case.
> >>
> >> -igor
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

[Eelco Hillenius]

> To be a little dramatic: A 100k line project where 50% of forms are
> generified and the other are using casts doesn't seem very nice.

But if you would find the need to cast the model object of a component
(form), that's the time to use the generic version. So you'd only use
the non-generic versions when you don't do anything interesting with
the model (or don't use it at all).

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[svenmeier]

Just because you're using a CompoundPropertyModel on your Forms doesn't
mean you need it generified.

Sven

Roland Huss schrieb:

>
> igor.vaynberg wrote:
>  
>> On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
>> <eelco.hillenius@...> wrote:
>> thats my point. you work on fields of one object, true, but it does
>> not necessarily have to be the form's modelobject unless you use a
>> compound property model.
>>
>>    
>
> The usage of a CompoundPropertyModel as a Form-model saved us quite some
> typing and it's IMO
> a very common use case. In fact, this it propbably the most relevant use
> case for a CPM anyway.
> So, I'm in favor of having a Form with Model (or at least a variation like a
> ModelForm<T> ...)
>
> ... roland
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Roland Huss]

But at the end, I want my model object back to do some business with it, so I could either store the CPM myself for later reference (but why would I want to do this ?) or retrieve it from the Form's model (typesafe, if possible). That's why a generified Form would be nice.

... roland

svenmeier wrote:

Just because you're using a CompoundPropertyModel on your Forms doesn't
mean you need it generified.

Sven

Roland Huss schrieb:
>
> igor.vaynberg wrote:
>  
>> On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
>> <[e-mail]> wrote:
>> thats my point. you work on fields of one object, true, but it does
>> not necessarily have to be the form's modelobject unless you use a
>> compound property model.
>>
>>    
>
> The usage of a CompoundPropertyModel as a Form-model saved us quite some
> typing and it's IMO
> a very common use case. In fact, this it propbably the most relevant use
> case for a CPM anyway.
> So, I'm in favor of having a Form with Model (or at least a variation like a
> ModelForm<T> ...)
>
> ... roland
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[svenmeier]

Another thought:
Why do we have a setter for the model actually?

I never call setDefaultModel() (formerly setModel()) in my code. In
wicket-examples it seems that most calls to setDefaultModel() are done
from inside the constructor (where it is sometimes needed because you
cannot call instance methods before the super constructor call).

Shouldn't we declare this method (final) protected?
Custom components could just handle generified models in the
constructor, the non-final getDefaultModel() could be overriden with the
preferred return type (as already suggested).

And we could get rid of the 'default' in all this method names which
frankly don't look too good to me.

Sven

Johan Compagner schrieb:

> thats completely up how you use it
> I can think of a lot that dont use models on FormComponents but only on
> Forms
> If you use CompoundModel then you never will touch or give a FormComponent a
> model.
> and all your stuff is done on the Model of the Form. (in the onSubmit for
> example)
>
> So this can never be generalized like this will never be used this way
> The only way for this is to have a complete separate stack of
> "ModelComponents/GenericComponents"
>
> See for example Link, Igor says i use model a lot. Eelco says he never uses
> it.. (but he uses it on button if i read correctly which is the same thing
> as a link)
>
> johan
>
>
> On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten <jan.kriesten@...>
> wrote:
>
>  
>> Hi,
>>
>>  i agree that its no big deal, i am just trying to figure out some sort
>>    
>>> of guidelines for when we do include the type and when we dont. if we
>>> say that we only include the type when the component uses its model
>>> then neither Link nor Form qualify. in fact neither will ListItem.
>>> only things like ListView and FormComponents will qualify.
>>>
>>>      
>> I'd actually prefer untyped Link and Form, since I also don't use Models on
>> them directly most of the time. But other's may have a different style and
>> always use Models...
>>
>> Best regards, --- Jan.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jul 2, 2008 at 12:53 PM, Sven Meier <sven@...> wrote:
> Another thought:
> Why do we have a setter for the model actually?

Consider the case (that I sometimes have) where you want to set the
model in the component's constructor, but it needs a bit of
preparation first in such a way that you can't do it in the super or
this call.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Timo Rantalaiho]

On Wed, 02 Jul 2008, Johan Compagner wrote:
> I still dont see a complete decoupling or do you mean only getDefaultXxxx()?

What I mean is that post-1.4 it would be good to remove the
defaultModel* stuff and other IModel dependencies from
Component, and maybe try to move towards a more case-by-case
model handling in generified (actually
typed-after-their-default-model-type) components as well.

> So all the getModel() (Link/FormComponent) are still there?

I wouldn't mind trying to see if we could remove the magic
currently done in get/setModel* in those too, and if model
becomes a normal field in those (instead of an element
stored in Component.data), open it to subclasses by making
it protected and leave implementing a part of those methods
to the users. Often it's better for the design to avoid
using getters and setters.

Some of the magic might work in the models themselves, for
example making the component aware models... aware of the
relevant components :)

This might turn out not to be practical, and either way
having the get/setModel* by default in the generified
components is fine by me -- just thinking about different
options, and whether they have relevance on what will go to
1.4.

Best wishes,
Timo

--
Timo Rantalaiho          
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Timo Rantalaiho]

On Wed, 02 Jul 2008, Matej Knopp wrote:
> I still don't see what's wrong with GenericPanel. It's certainly much
> easier to type than ModelContainingPanel.

Nothing wrong with that either, it's just very generic :)

There are a lot of ways of making use of generics in a
component besides just adding the type parameter bound to
the type parameter of the model of the component.

I mean, if you have

public FooPanel extends GenericPanel<Foo> {
    public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
    ...
    }
...
}

it's not so much more generic than

public FooPanel extends Panel {
    public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
    ...
    }
...
}

> I strongly disagree. There are good reasons for Wicket to bind model
> and component together and I think what we have in 1.4 right now is a
> balanced compromise.

I'd be glad to hear more on this! For now, I imagine that a
lot of stuff that the Component IModel dependency exists for
could be done in other ways.

And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.

Again, I'm just exploring, and perhaps overlooking
something.

> Also if we don't provide the convenience classes
> people will bound to write their own (because it's the only reasonable
> way to migrate project that already uses generics).

That's true, I just thought it would be no big deal and only
affect the earliest 1.4 adopters (or those still converting
from 2.0 if there are any left) (sorry :)). I had in mind
that if we then remove those convenience classes in 1.5,
they would have to move to the user codebases anyway, but
maybe 1.4 -> 1.5 will not be such a common migration path
because of API breaks.

> I don't buy this. Our components have a lot of methods, but most of
> them are not part of public API. I plan to prefix those methods with a
> common prefix for 1.5 so they don't confuse regular users. But I
> really don't see how removing four methods (*defaultModel) improves
> our api.

It would be better (altough harder) to move responsibilities
away from Component to other classes, which could be then
marked as not being a part of the public API. When you do
the rename I'll be happy to do a spike of moving some of the
renamed stuff away from Component altogether :)

> Models have always been conceptually bound to component. Right now the
> problem of our API is not that we have a model slot in component. It
> is that we have exactly one model slot. This doesn't work well for all
> components, since some don't need model at all and some need more than
> one.

Yeah, if we cannot get rid of the default model handling
(which I still hope to be possible), at least a more
flexible abstraction (IModelsContainer?) might be good.

> esier. Now thinking about it, the name should really suggest that
> there is one model per component. Maybe PanelWithModel could be the
> name after all :)

PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent :)

Best wishes,
Timo

--
Timo Rantalaiho          
Reaktor Innovations Oy    <URL: http://www.ri.fi/ >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> What I mean is that post-1.4 it would be good to remove the
> defaultModel* stuff and other IModel dependencies from
> Component, and maybe try to move towards a more case-by-case
> model handling in generified (actually
> typed-after-their-default-model-type) components as well.

I'm very much in favor of that. If it were up to me, I would actually
try to cut away from component (and other pivotal classes for that
matter) as much as possible. I'd love Wicket to feel lighter and more
pointed with 1.5 rather than heavy with convenience like it is now.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

Okay, long story short.

I'm gonna be -1 on removing model utility methods and default model
slot from component until you suggest a clean and transparent way to
support
- compound (inherited) models
- component assigned models
- automatic detachment

Just because you don't use these features it doesn't mean there are
not users who do.
There is convenience, removing bloat and just crippling the API. And
there's difference between these.

Don't take me wrong, I don't mind removing the *default* methods from
components, but not in a way that is going to sacrifice any of the
mentioned functionality.

On Thu, Jul 3, 2008 at 5:32 AM, Timo Rantalaiho <Timo.Rantalaiho@...> wrote:

> On Wed, 02 Jul 2008, Matej Knopp wrote:
>> I still don't see what's wrong with GenericPanel. It's certainly much
>> easier to type than ModelContainingPanel.
>
> Nothing wrong with that either, it's just very generic :)
>
> There are a lot of ways of making use of generics in a
> component besides just adding the type parameter bound to
> the type parameter of the model of the component.
>
> I mean, if you have
>
> public FooPanel extends GenericPanel<Foo> {
>    public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
>    ...
>    }
> ...
> }
>
> it's not so much more generic than
>
> public FooPanel extends Panel {
>    public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
>    ...
>    }
> ...
> }
>
>> I strongly disagree. There are good reasons for Wicket to bind model
>> and component together and I think what we have in 1.4 right now is a
>> balanced compromise.
>
> I'd be glad to hear more on this! For now, I imagine that a
> lot of stuff that the Component IModel dependency exists for
> could be done in other ways.

Sure, mind sharing how?

>
> And there is some functionality in there that Wicket might
> be better without. For example, onModelChanged / Changing
> things become tricky when you share the same model between
> different instances. And when using setModelObject() with an
> object that is equal to the current model object, but a
> different instance (such as a Hibernate-persisted object
> bound to the correct session), you have to either do
> getModel().setObject() or change the model comparator.
>
> Again, I'm just exploring, and perhaps overlooking
> something.
>
>> Also if we don't provide the convenience classes
>> people will bound to write their own (because it's the only reasonable
>> way to migrate project that already uses generics).
>
> That's true, I just thought it would be no big deal and only
> affect the earliest 1.4 adopters (or those still converting
> from 2.0 if there are any left) (sorry :)). I had in mind
> that if we then remove those convenience classes in 1.5,
> they would have to move to the user codebases anyway, but
> maybe 1.4 -> 1.5 will not be such a common migration path
> because of API breaks.
>
>> I don't buy this. Our components have a lot of methods, but most of
>> them are not part of public API. I plan to prefix those methods with a
>> common prefix for 1.5 so they don't confuse regular users. But I
>> really don't see how removing four methods (*defaultModel) improves
>> our api.
>
> It would be better (altough harder) to move responsibilities
> away from Component to other classes, which could be then
> marked as not being a part of the public API. When you do
> the rename I'll be happy to do a spike of moving some of the
> renamed stuff away from Component altogether :)

From component where? ComponentUtil? Component has a very strong and
complicated contract. There are lot of methods in component, but there
are reasons for it. There are parts like rendering though that might
need to be cleaned up.

>
>> Models have always been conceptually bound to component. Right now the
>> problem of our API is not that we have a model slot in component. It
>> is that we have exactly one model slot. This doesn't work well for all
>> components, since some don't need model at all and some need more than
>> one.
>
> Yeah, if we cannot get rid of the default model handling
> (which I still hope to be possible), at least a more
> flexible abstraction (IModelsContainer?) might be good.
>
>> esier. Now thinking about it, the name should really suggest that
>> there is one model per component. Maybe PanelWithModel could be the
>> name after all :)
>
> PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent :)
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

Ligther? Does it meen with no Compund and ComponentAssignedModel?
Wouldn't that feel more like crippled?
The default model slot doesn't take any runtime space when you don't
use it, property would. And removing four methods from component will
hardly make it much lighter.

-Matej

On Thu, Jul 3, 2008 at 7:13 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>> What I mean is that post-1.4 it would be good to remove the
>> defaultModel* stuff and other IModel dependencies from
>> Component, and maybe try to move towards a more case-by-case
>> model handling in generified (actually
>> typed-after-their-default-model-type) components as well.
>
> I'm very much in favor of that. If it were up to me, I would actually
> try to cut away from component (and other pivotal classes for that
> matter) as much as possible. I'd love Wicket to feel lighter and more
> pointed with 1.5 rather than heavy with convenience like it is now.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

>
> And there is some functionality in there that Wicket might
> be better without. For example, onModelChanged / Changing
> things become tricky when you share the same model between
> different instances. And when using setModelObject() with an
> object that is equal to the current model object, but a
> different instance (such as a Hibernate-persisted object
> bound to the correct session), you have to either do
> getModel().setObject() or change the model comparator.
>

setModelObject isn't the best idea IMHO. Models should support some
kind of state change notifications, we might want to improve that for
1.5, though it probably wouldn't be very easy to do.

-Matej

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <matej.knopp@...> wrote:

>>
>> And there is some functionality in there that Wicket might
>> be better without. For example, onModelChanged / Changing
>> things become tricky when you share the same model between
>> different instances. And when using setModelObject() with an
>> object that is equal to the current model object, but a
>> different instance (such as a Hibernate-persisted object
>> bound to the correct session), you have to either do
>> getModel().setObject() or change the model comparator.
>>
>
> setModelObject isn't the best idea IMHO. Models should support some
> kind of state change notifications, we might want to improve that for
> 1.5, though it probably wouldn't be very easy to do.

Well, we can hardly detect change of propertypromodels unless we pull
and compare the value every time...
>
> -Matej
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
> Ligther? Does it meen with no Compund and ComponentAssignedModel?
> Wouldn't that feel more like crippled?
> The default model slot doesn't take any runtime space when you don't
> use it, property would. And removing four methods from component will
> hardly make it much lighter.

I wasn't just thinking about models though. *I* would like us to go
through the API when we start on 1.5 and remove anything that isn't
necessary. Remove all the the deprecations and convenience methods
that have (easy) alternatives. All the while keeping an easy upgrade
path in mind of course.

Of course, things like compound property models are pretty cool, and
we should keep supporting the types of models we are supporting now.
But maybe we can find a way to add this kind of support to components
without needing it to be built in. Or maybe not and in the end our
conclusion will be to stick with 1.4's model. But lets try to be
creative before we give up on that :-)

We're getting a bit ahead of ourselves now though, unless we already
want to start coding on 1.5. It is probably a better idea to finalize
1.4 first, and decide on what to generify by default based on the
likeliness it will help users for this version.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:
> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>> Wouldn't that feel more like crippled?
>> The default model slot doesn't take any runtime space when you don't
>> use it, property would. And removing four methods from component will
>> hardly make it much lighter.
>
Big +1 on that :)

> I wasn't just thinking about models though. *I* would like us to go
> through the API when we start on 1.5 and remove anything that isn't
> necessary. Remove all the the deprecations and convenience methods
> that have (easy) alternatives. All the while keeping an easy upgrade
> path in mind of course.
>
> Of course, things like compound property models are pretty cool, and
> we should keep supporting the types of models we are supporting now.
> But maybe we can find a way to add this kind of support to components
> without needing it to be built in. Or maybe not and in the end our
> conclusion will be to stick with 1.4's model. But lets try to be
> creative before we give up on that :-)

Creative is ok for me. Destructive isn't :)
>
> We're getting a bit ahead of ourselves now though, unless we already
> want to start coding on 1.5. It is probably a better idea to finalize
> 1.4 first, and decide on what to generify by default based on the
> likeliness it will help users for this version.

Yeah, agree on this as well.

-Matej
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

Matej: drink some coffee, you're +1-ing yourself now :)

Martijn

On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp <matej.knopp@...> wrote:

> On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>> Wouldn't that feel more like crippled?
>>> The default model slot doesn't take any runtime space when you don't
>>> use it, property would. And removing four methods from component will
>>> hardly make it much lighter.
>>
> Big +1 on that :)

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

Rofl :) I've slept like 4 hours. I wanted to +1 Eelco of course. Or
maybe that just my Ego and my subconciousness messing with me.

On Thu, Jul 3, 2008 at 10:22 AM, Martijn Dashorst
<martijn.dashorst@...> wrote:

> Matej: drink some coffee, you're +1-ing yourself now :)
>
> Martijn
>
> On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp <matej.knopp@...> wrote:
>> On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
>> <eelco.hillenius@...> wrote:
>>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>>> Wouldn't that feel more like crippled?
>>>> The default model slot doesn't take any runtime space when you don't
>>>> use it, property would. And removing four methods from component will
>>>> hardly make it much lighter.
>>>
>> Big +1 on that :)
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...