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 IModel<V> 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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#a8516354
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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
