On Fri, 08 Feb 2013 13:27:26 -0200, sommeralex
<alexander.som...@gmail.com> wrote:
Hi Thiago,
Hi!
Thanx for the detailed answers! And sorry for being not clear. Sure,
value, option and selectModel are different, i just mixed them into "one
thing" in my questions.
They are very different things, so you shouldn't mix then into one thing.
For getting the list-items to select, i need a selectModel. This
selectModel consists of optionModels, the optionModel just gives me the
labels and
values. Hence, for linking the items to the DB entries (my server) the
valueEncoder translates the selected item to that item it actually
represents. (correct me if this is not true)
Yeah.
I thought that it is possible to add the optionModel to the appModule
somehow that it is "static".
Your sentence above doesn't make any sense. Again, the only thing that
goes to AppModule in this discussion is ValueEncoder. Please use the right
names for things or otherwise no one will understand what you're saying.
If i am using non-static option models, each user will always
request the list(s), e.g:
List<Color> colors = colorService.findAll(); //(taken from the example)
That's correct. On the other hand, the implementation of
ColorService.findAll() may cache results if you think that's a good thing.
and the selectModelFactory will always have to create the selectModel
from scratch:
// create a SelectModel from my list of colors (taken from the example)
colorSelectModel = selectModelFactory.create(colors, "name");
Yep. SelectModel is a throw-away object. And nothing prevents you to cache
this object. A good way of doing that would be you to create something
like ColorSelectModelFactory to encapsulate this logic and maybe cache
SelectModels.
the point is, that my - options for the optionModel are dynamic, but only
"slowly" increasing/changing and for that reason i thought that there
may be a more efficient way to "populate" the optionModel
You're saying OptionModel instead of SelectModel again. :(
The whole point here is that *you* know how *your* data changes, so *you*
need to write code that adequately deals with it. Just follow my
suggestion above: create a service that returns SelectModels for Color and
put all logic there. Your problem is too specific for Tapestry to provide
a generic solution.
in a way "globally" and that this global available option model has to
be updated time by time for staying accurate.
You're saying OptionModel instead of SelectModel again. :(
Your data isn't static, so your SelectModel isn't static. You have to live
with that. Or, if you know the dynamics of your data, write code that
deals with it.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
