Re: [Wicket-user] VOTE: IModel and 'model object' name change
We already have a getValue on formcomponent
that is the input value from the request or the model object as a string
(just the latest value)
So then that also has to be renamed. (and relearned)
I think getModelObject() is just what it says. (besides the getModel() call
we also have!)
else it should be getModelValue() not just getValue()
So i am -1 for changing getModelObject to getValue() that isn't descriptive
enough for me and will
collide with what we already have and that will result in even more renames.
I dont care to much +0 about changing the IModel interface itself (it
already has changed a bit because of the lost param in 2.0)
But i don't know if that really has much value.
johan
On 1/23/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding
a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models
a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment
instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Im -1.
As most of my models holds objects and not value, I've had no problem
understanding this part of the IModel.
I must admit that I may be blind to this because im used to the current naming,
and have been working with it for so long. I guess the new users would be the
ones best to tell us which would be better.
But I do think that getModelObject, is very descriptive.
It tells that you want to get the object that the model hold. getValue just
tells that you want to get a value, which value is it that you are getting is
an integer or what?
Regards Nino
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke
Sent: 23. januar 2007 07:51
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] VOTE: IModel and 'model object' name change
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote: ... in fact, that term is actually ambiguous since the object implementing IModel might be informally understood to be the model object (which is not what we mean)... You're very right. This is the major contributor to my confusion about models when I was first studying Wicket. I don't want to vote because I'm no one here and my vote is nothing. I just want to voice my opinion: I think the solution would be for the wiki and book writers to give more weight and clear explanations about models and relieve newbies from this confusion. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
If it is user opinion wanted, for what I am it is -1. I would be please with the change if I used wicket for a home hobby of making something easy. But the problem is that I'm working in a production environment. Every thing that will make 2.0 migration harder will make sure that it will not get used soon in the industry. The arguments are good, but I don't think it is worth it. Marc On 1/23/07, Otan [EMAIL PROTECTED] wrote: On 23/01/07, Jonathan Locke [EMAIL PROTECTED] wrote: ... in fact, that term is actually ambiguous since the object implementing IModel might be informally understood to be the model object (which is not what we mean)... You're very right. This is the major contributor to my confusion about models when I was first studying Wicket. I don't want to vote because I'm no one here and my vote is nothing. I just want to voice my opinion: I think the solution would be for the wiki and book writers to give more weight and clear explanations about models and relieve newbies from this confusion. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving people a chance to comment
as I
go.
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8378321
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1 for changing the method signature
+1 for more model examples particularly contextual ones, i.e. with a form
you often use the form component itself as the model (I can work on this if
things go as I hope with our web ui proofs of concept -- otherwise I'll be
off learning JSF)
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for
a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology. As
far
as Wicket itself is concerned, a model is anything that implements
the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and
adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we
can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on
models a
little
hard to follow. So now I'd like to revise the Working with
Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I
do
the
latter I could potentially post it somewhere else for comment
instead
of
directly replacing the existing page on the wiki. Perhaps we need
a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving
Re: [Wicket-user] VOTE: IModel and 'model object' name change
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could
Re: [Wicket-user] VOTE: IModel and 'model object' name change
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
Re: [Wicket-user] VOTE: IModel and 'model object' name change
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel as i
said,
but then just deprecate getModelObject() and add a preferred version as
getModelValue() as johan suggested. this would only break code that
directly
uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.
Eelco
On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
Re: [Wicket-user] VOTE: IModel and 'model object' name change
You make a good point. Something like IModelLocator would be a
clearer name for IModel. then its methods could be called get/setModel.
As you point out, IModel is only the model from the framework's
perspective. From the user's it is a model locator and the actual
model is the object returned by the locator interface. Maybe we
can consider this for 3.0 if there's strong agreement by then.
Gustavo Hexsel-3 wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's
very
late, but please at least read my argument below and think about it
for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters
since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as
derived from
the IModel interface naming) is really not helping anyone to
understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn
may
very understandably not want to deal with that so i won't be upset if
this
change can't happen. but i'd like to see it if it's possible, so at
any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was
there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology. As
far
as Wicket itself is concerned, a model is anything that implements
the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most
Re: [Wicket-user] VOTE: IModel and 'model object' name change
yes. that is the major concern.
for now, eelco could put a callout box in the book with a warning about
this ambiguity. we could also do the same in the javadoc for getModel()
and getModelObject() so any rare people who actually read the docs
won't be lost.
igor.vaynberg wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or
the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526645
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject () what do you really want? the model object or the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
geez, this makes so much sense like this! ;-)
Eelco Hillenius wrote:
Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.
Eelco
On 1/23/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then ReflectionModelAccessor or
CompositeModelAccessor, ...). They're not really models in any sense
that existing software patterns might agree, except maybe from the
framework-only perspective. The methods wouldn't even have to change
that much then.
[]s Gus
On 1/23/07, Matthijs Wensveen [EMAIL PROTECTED] wrote:
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between
model
object (as in the IModel instance) and modelObject (the object
contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming convention XXXModel so we had IModels
containing
modelObjects that were XXXModels. If that isn't an example of bad
naming, then what is? :D
In my opinion models containing values that are (of course) objects is
much clearer and would prevent this kind of madness. Luckily Eclipse
has
great refactoring features, so XXXModel soon became XXXModelObject.
Matthijs
Eelco Hillenius wrote:
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's
very
late, but please at least read my argument below and think about it
for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters
since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as
derived from
the IModel interface naming) is really not helping anyone to
understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model
object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn
may
very understandably not want to deal with that so i won't be upset
if this
change can't happen. but i'd like to see it if it's possible, so at
any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing
something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was
there
some crazy reason we didn't do this? It would be much easier and
more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little
more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display
and/or
edit. How exactly this value is held is determined by a given
model's
implementation of the wicket.model.IModel interface. This
interface
decouples a component from the data which forms its value. This
in turn
decouples the whole Wicket framework from any and all details of
model
storage, such as the details of a given persistence technology.
As far
as Wicket itself is concerned, a model is anything that
implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel
interface
since readers will be wondering what it looks like already. It
sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to
Re: [Wicket-user] VOTE: IModel and 'model object' name change
I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern). If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components. Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Yeah, the only real argument for that method other than brevity is that you
could override it.
It would be unreliable outside the core though and I can't think of a reason
to do that offhand.
Eelco Hillenius wrote:
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject () what do you really want? the model object or
the
object inside the model object?
-igor
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526768
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
what do you think of gustav and eelco's IModelLocator / get/setModel idea?
Frank Silbermann wrote:
I don't care much for getValue() because to me the word value suggests
atomic value (or even atomic constant) -- which is not the general
case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could be
confusing if it were common practices to embed wicket models inside of
wicket models (the Decorator pattern). If that's they case, I would
deprecate getModelObject() and replace it with getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity of
_wrapping_ business objects in Wicket model classes to be accessed by
wicket components. Once that process is understood, multiple levels of
wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just deprecate getModelObject() and add a preferred
version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8526796
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence
Re: [Wicket-user] VOTE: IModel and 'model object' name change
Yes, perhaps a better way to avoid overloading the word Model or
ModelObject is to use those words to refer to that which is wrapped
(usually a non-wicket oriented business object), and use something else
for the class which does the wrapping and provides access to the wicket
page component.
However, I'm not that keen on the name IModelLocator, as the current
IModel does many things other than merely locating the model. It
provides string-based access methods to the model's parts; it handles
persistance or detachability, etc.
So I'd prefer to make get/setModel methods of an interface named
IModelManager or IModelWrapper.
The verbs Manage and Wrap are still somewhat vague, but there's only
so much that can be done to tersely document a class that does well lots
more than just one thing.
At least IModelManager or IModelWrapper are not ambiguous (as is
ModelObject), and avoids overloading the word Model.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:55 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
what do you think of gustav and eelco's IModelLocator / get/setModel
idea?
Frank Silbermann wrote:
I don't care much for getValue() because to me the word value
suggests atomic value (or even atomic constant) -- which is not
the general case.
At first I thought of recommending getBusinessObject() to distinguish
the result from the framework-oriented model classes, but that could
be confusing if it were common practices to embed wicket models inside
of wicket models (the Decorator pattern). If that's they case, I
would deprecate getModelObject() and replace it with
getUnwrappedModel().
(Obviously, wicket documentation must somewhere explain the necessity
of _wrapping_ business objects in Wicket model classes to be accessed
by wicket components. Once that process is understood, multiple
levels of wrapping should not be too difficult to understand.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change
IModel as i said, but then just deprecate getModelObject() and add a
preferred version as
getModelValue() as johan suggested. this would only break code that
directly uses IModel (a more limited number of users).
Eelco Hillenius wrote:
I voted -1, but here is my opinion about the change proper.
public interface IModelV extends IDetachable {
V getValue();
void setValue(V value);
}
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
documentation on how models should be used is a lot more important.
we would also change getModelObject() to getValue() as well as any
other
related methods like getModelObjectAsString() to getValueAsString()
(or
valueAsString() if preferred). there might be naming conflicts
somewhere
or
other problems, but i don't know of any offhand.
Tbh, I actually don't think Component#getValue is for the better. I
think Component#getModelObject is way clearer than
Component#getValue.
In the end I think both value and object are ambiguous, and this
should be fixed by documentation and examples.
Btw, If there is *anything* I never liked about the whole model
business, it is the fact that Component has methods to get the model
value in the first place (getModelObject etc).
The indirection that IModel provides is something to get used to. It
is one of the places where we traded clarity and simplicity for
flexibility. I think it'll be hard to grasp for newbies no matter the
naming, so the better our documentation and examples are, the quicker
they will be able to wrap their head around it.
Eelco
--
--
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEV
DE
V
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-pa
ge
-tf3016921.html#a8526349
Sent from the Wicket - User mailing list archive at Nabble.com.
--
--
-
Take Surveys. Earn Cash. Influence the Future of IT Join
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote: getModelValue would have been better than getModelObject yeah. That said, imo (and I have stated this before), I think having those methods in the first place is distracting, as it doesn't push people in the direction of just letting the components and models work directly for them. I would hate to see this method go because I've used it frequently in cases where I have inner classes and anonymous classes. Fixable with only mild annoyance, though. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
On 1/23/07, James McLaughlin [EMAIL PROTECTED] wrote: On 1/23/07, Eelco Hillenius [EMAIL PROTECTED] wrote: getModelValue would have been better than getModelObject yeah. That said, imo (and I have stated this before), I think having those methods in the first place is distracting, as it doesn't push people in the direction of just letting the components and models work directly for them. I would hate to see this method go because I've used it frequently in cases where I have inner classes and anonymous classes. Fixable with only mild annoyance, though. It won't go. I'm using it myself as well to be honest. It's just distracting. Eelco - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] VOTE: IModel and 'model object' name change
With those names I am changing my vote to +1. Erik. Jonathan Locke wrote: what do you think of gustav and eelco's IModelLocator / get/setModel idea? -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] VOTE: IModel and 'model object' name change
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first paragraph
to be even more specific. Maybe it could be tweaked a little more, but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think should be
improved
(though this is a little hard to do in detail short of simply
annotating
the
page) or I can just plunge ahead and draft a revised page. If I do
the
latter I could potentially post it somewhere else for comment instead
of
directly replacing the existing page on the wiki. Perhaps we need a
'in
draft' part of the wiki for working on long pages like this one.
Actually, another alternative is for me to gradually introduce
changes to
the wiki page over a span of days, giving people a chance to comment
as I
go.
--
View this message in context:
http://www.nabble.com/revising-the-%22Working-with-Wicket-models%22-page-tf3016921.html#a8378321
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Re: [Wicket-user] VOTE: IModel and 'model object' name change
-1
I'm sorry, although I totally understand your argument, and how it may help
new users, but this will break already written code, will not add additional
level of functionality, and really it's just a matter of reading to
understand how IModel works, I did have difficulties when I started to
understand detachable models, but not the concept of the model itself.
Maybe new user need more detailed example and tutorials if they lack time
to read and understand the examples, which I still think they are available
around, and there is a book too, and there will be the long awaited wicket
book, that I can't really wait to get my hands on! :)
beside set value? what if it's not a value, I mean most of my models contain
an object with long list of values :)
One last thing, most of the programmers out there still don't use the OO
concept of programming, still don't implement proper patterns, and seriously
they don't think of interfaces for their design, I will have to include
myself with the lawzi ones (although I fully use OO even in database level),
I think we should not encourage this.
I'm sorry again
On 1/23/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to getValue() as well as any other
related methods like getModelObjectAsString() to getValueAsString() (or
valueAsString() if preferred). there might be naming conflicts somewhere
or
other problems, but i don't know of any offhand.
i realize we're about to enter beta, but i feel like this matters since
our
users have been telling us for some time now that models are hard to
understand and it seems likely that the term 'model object' (as derived
from
the IModel interface naming) is really not helping anyone to understand
things. in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean).
i realize this change would affect the book and so eelco and martijn may
very understandably not want to deal with that so i won't be upset if this
change can't happen. but i'd like to see it if it's possible, so at any
rate, i'm +1 and i think igor says he's +0.
Jonathan Locke wrote:
We did already break the model contract with 1.2/1.3... would
get/setObject-get/setValue be a huge hassle? Or am I spacing something
here?
Jonathan Locke wrote:
Made a few more changes. I think it's getting shorter/better.
My one regret looking at this documentation is that I wish
IModel.get/setObject were actually IModel.get/setValue. Or was there
some crazy reason we didn't do this? It would be much easier and more
natural to talk about a model's value this way...
Jonathan Locke wrote:
Nice work. I made a few small changes and rephrased the first
paragraph
to be even more specific. Maybe it could be tweaked a little more,
but
I think this sums it up better now:
In Wicket, a model holds a value for a component to display and/or
edit. How exactly this value is held is determined by a given model's
implementation of the wicket.model.IModel interface. This interface
decouples a component from the data which forms its value. This in
turn
decouples the whole Wicket framework from any and all details of model
storage, such as the details of a given persistence technology. As far
as Wicket itself is concerned, a model is anything that implements the
IModel interface, no matter how it might do that.
It does feel like this is the best place to show the IModel interface
since readers will be wondering what it looks like already. It sounds
scarier than it is, so why delay?
Loren Rosen wrote:
I've saved my rewritten version. (See
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
Comments by everyone from experts to complete newbies
are most welcome. Doubtless there are things that are confusing or
flat-out wrong.
In addition to rephrasing or rewriting a lot of material, and adding
a
few things, I
excised some details I thought would be distracting for a beginner.
Some of this
material is, I think, still useful, perhaps in a slightly more
advanced
More about
Models page.
igor.vaynberg wrote:
go ahead and edit the page...the wiki is versioned i think so we can
always
roll back.
when you are done with the majority let us know and we will review
the
changes.
-igor
On 1/15/07, Loren Rosen [EMAIL PROTECTED] wrote:
When I first started using Wicket I found the information on models
a
little
hard to follow. So now I'd like to revise the Working with Wicket
models
wiki page
(
http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models
)
to improve this. I'd be happy to outline what I think
