Hi,
To me this looks like your problem is that you have a getters with
side-effects? ( getUsers() for example ).
What if you set up your page-instance variables prior to rendering (not
during - take a look at page lifecycle phases), then you could determine
your blank option and retrieve/cache your user list without having "order"
issues.
If I'm not mistaken about the ValueEncoder i think it is not used while you
actually have the user list fetched (during initial page-render), but when
you choose to act on some user object. Its id is passed along to the page
and the encoder kicks in to provide you with a fully configured UserBean.
So the UserBean fetches basically happens during two different requests,
and probably only on the object(s) that you actually choose to do something
with.
- Of course you can cache the user list in session or similar and have it
available for later use, but I do not really like that option.
--
Chris
On Mon, Dec 31, 2012 at 9:24 AM, John <j...@quivinco.com> wrote:
> consider the following example
>
> When the select component is rendered the call to getUOption precedes the
> call to getUserSelectModel so the uOption state is not yet set.
>
> <form t:type="form" t:id="form">
> <t:errors />
> <t:zone t:id="userZone" id="userZone">
> <t:select t:id="user" t:blankOption="prop:uOption"
> t:model="userSelectModel"
> t:encoder="userEncoder" t:value="selectedUserId" t:zone="userZone" />
>
> public BlankOption getUOption() {
> return uOption? BlankOption.ALWAYS:BlankOption.NEVER;
> }
>
> public SelectModel getUserSelectModel() {
> return selectModelFactory.create(getUsers(), "username");
> }
>
> public List<UserBean> getUsers() {
> try {
> List<UserBean> results =
> usersDAO.getManagedUsers(stateBean.getUser().getUserId());
> if (results.size()) > 1) {
> uOption = true;
> } else {
> uOption = false;
> }
> return results;
> } catch (Exception ex) {
> log.error("could not obtain users: " + ex.getMessage());
> }
> return null;
> }
>
>
> Another dislike I have is with the ValueEncoder which has to invoke the
> DAO again to obtain a matching user although these were already loaded up
> when the model was created. It would be nice if the model cached the users
> and simply referred back to them there.
>
> public UserBean toValue(String clientValue) {
> try {
> return usersDAO.getUser(Integer.parseInt(clientValue));
> } catch (Exception ex) {
> log.error("user encoder could not resolve clientValue to a
> UserBean: "
> + ex.getMessage());
> return null;
> }
> }
>
> So overall I see the need for some shared cache with the select component,
> just loading a map up should do it?
>
> John
> ----- Original Message -----
> From: Geoff Callender
> To: Tapestry users
> Sent: Sunday, December 30, 2012 3:00 PM
> Subject: Re: select blankOption
>
>
> Some code please.
>
> On 31/12/2012, at 1:42 AM, John wrote:
>
> > I got that to work, it's great, I hadn't notice all the values can
> have a prefix to change the scope.
> >
> > The problem is that the method that returns the option values and sets
> the blankOption value is invoked after the blankOption getter.
> >
> > This is a problem I have hit before where a property value depends on
> the result of a property value that is invoked later. I don't really want
> to store results in the session and am wondering if I should use a cache
> instead.
> >
> > Is there any recomended approach in Tapestry? Maybe I should use
> ehCache?
> >
> > My typical example is a property that returns a collection from a DAO
> to iterate over for a table or select list, and then some other property
> whos state depends on that result in some way. So far I have been using
> intermediate helper beans to bind the related state data.
> >
> > John
> > ----- Original Message -----
> > From: Geoff Callender
> > To: Tapestry users
> > Sent: Sunday, December 30, 2012 1:37 PM
> > Subject: Re: select blankOption
> >
> >
> > Ah, so you were. Same applies.
> >
> > On 31/12/2012, at 12:24 AM, John wrote:
> >
> >> I was talking about blankOption, but I'll try with the prop prefix.
> >> ----- Original Message -----
> >> From: Geoff Callender
> >> To: Tapestry users
> >> Sent: Sunday, December 30, 2012 12:16 PM
> >> Subject: Re: select blankOption
> >>
> >>
> >> The default prefix is "literal". Use "prop", eg.
> blankLabel="prop:yourProperty".
> >>
> >> See Binding Expressions in
> http://tapestry.apache.org/component-parameters.html .
> >>
> >> Cheers,
> >>
> >> Geoff
> >>
> >> On 30/12/2012, at 11:07 PM, John wrote:
> >>
> >>> I would like to choose dynamically whether to display the blank
> option in my select component.
> >>>
> >>> I am using it to display an ALL value and don't want to show this if
> the select has only 1 option.
> >>>
> >>> Unfortunately the docs say that the blankOption is a literal and not
> a property. Is there any way to change that easily?
> >>>
> >>> Maybe it's easiest just to add a new option with the name and value
> I want?
> >>>
> >>> John
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
