Then make sure each setting name is unique.
-Adrian
Bruno Busco wrote:
Adrian,
I understand how the getUserPreferenceGroup service works.
I only see a problem when I will try to store two records that will
have the same PK.
-Bruno
2009/12/8 Adrian Crum :
Group the screen settings by screen n
Adrian,
I understand how the getUserPreferenceGroup service works.
I only see a problem when I will try to store two records that will
have the same PK.
-Bruno
2009/12/8 Adrian Crum :
> Group the screen settings by screen name. Use the user preferences services
> to get all settings for the curre
Group the screen settings by screen name. Use the user preferences
services to get all settings for the current screen. The service returns
a Map, where the key is the setting's name, and the value is the
setting's value.
-Adrian
Bruno Busco wrote:
Sorry, for sure I am missing something but
Sorry, for sure I am missing something but...
if the prim-key is
and we want to use:
userLoginId -> to specify the user the setting belongs to (i.e. admin)
userPrefTypeId -> to specify the screen setting name (i.e.
ProductKeywordsPanel_collapsed)
userPrefGroupTypeId -> to specify the
No. The userPrefGroupTypeId field is optional, therefore it cannot be
part of the primary key. Use the user preference services to get
preference groups.
I believe most (if not all) widget model classes have a getName() method.
-Adrian
Bruno Busco wrote:
Hi Adrian,
I am trying to implement a
Hi Adrian,
I am trying to implement as you suggested but I found two difficulties:
1) the entity UserPreference has the following prim-key:
while it should be
to do what you propose. Should we change it?
2) how to retrieve the screen name from a screenlet widg
Then do the same thing in the model widget code.
-Adrian
Bruno Busco wrote:
This would mean to change all the screens! :-(
2009/12/7 Adrian Crum :
...
Bruno Busco wrote:
Adrian,
sorry for the bad sentence,
Could we move this somehow in the screen widget?
2009/12/7 Bruno Busco :
> This would mean to change all the screens! :-(
>
> 2009/12/7 Adrian Crum :
>>
>>
>>
>>
>> > value="MyScreen"/>
>>
>>
>>
>> ...
>>
>>
>>
>>
This would mean to change all the screens! :-(
2009/12/7 Adrian Crum :
>
>
>
>
> value="MyScreen"/>
>
>
>
> ...
>
>
>
>
> Bruno Busco wrote:
>>
>> Adrian,
>> sorry for the bad sentence, I couldn't even read myself
value="MyScreen"/>
...
Bruno Busco wrote:
Adrian,
sorry for the bad sentence, I couldn't even read myself.
I meant that GLOBAL_PREFERENCES gets already loaded in the ApplicationDecorator.
So now we ha
Adrian,
sorry for the bad sentence, I couldn't even read myself.
I meant that GLOBAL_PREFERENCES gets already loaded in the ApplicationDecorator.
So now we have two options to have screenlets with the same id saved
indipendently:
1) Use a screen related userPrefGroupTypeId.
2) Combine the screen n
Bruno Busco wrote:
Thank you Adrian,
but then how to the theme loaded easily? The global ones are already
loaded along the selected theme etc.
-Bruno
Or you can combine the screen name and sceenlet id for the preference
key, instead of (screenlet.id+"_collapsed" )
Bilgin
Expanded/collapsed has nothing to do with themes.
-Adrian
Bruno Busco wrote:
Thank you Adrian,
but then how to the theme loaded easily? The global ones are already
loaded along the selected theme etc.
-Bruno
2009/12/7 Adrian Crum :
Bruno,
Don't forget the UserPreference entity also has a us
Thank you Adrian,
but then how to the theme loaded easily? The global ones are already
loaded along the selected theme etc.
-Bruno
2009/12/7 Adrian Crum :
> Bruno,
>
> Don't forget the UserPreference entity also has a userPrefGroupTypeId field,
> so you could group the collapsed settings by scree
Bruno,
Don't forget the UserPreference entity also has a userPrefGroupTypeId
field, so you could group the collapsed settings by screen. That would
solve the shared id problem.
-Adrian
bus...@apache.org wrote:
Author: buscob
Date: Mon Dec 7 17:24:21 2009
New Revision: 888030
URL: http://s
15 matches
Mail list logo
