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
