http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167993.html
Oops, my bad. The UserSettings entity is something we created in house. It's not
a part of OFBiz. Sorry for the confusion.
> Okay, so there is a chance we can reduce this further. This is just a suggestion
> - I like what you've done so far. Be patient, this is kind of long...
>
> Instead of
>
> ViewPrefType
> - viewPrefTypeId*
> - application (e.g., OFBIZ, CRMSFA, etc.)
> - applicationSection (e.g., ORDERMGR)
> - screenName
> - formName
>
> How about
>
> ViewPrefType
> - viewPrefTypeId*
> - prefContext
>
> In your version, viewPrefTypeId="ORDER_LIST_PREF", application="OFBIZ",
> applicationSection="ORDERMGR"
>
> In my version, prefContext="OFBIZ.ORDERMGR.ORDER_LIST_PREF", viewPrefTypeId=any
> unique value.
>
> Why do I suggest this? So that the view preferences aren't locked into concrete
> cells like screenName, formName, etc. Developers can put any context they want
> in prefContext.
>
> Abstracting that one step further, we could refer to these as user preferences,
> not just view preferences. Other preferences could be stored that way, such as
> report output preferences:
>
> <ViewPrefType viewPrefTypeId="1001"
> prefContext="OFBIZ.ORDERMGR.REPORTS.OUTPUTTYPE" />
>
> <Enumeration enumId="HTML" ... />
> <Enumeration enumId="PDF" ... />
>
> <ViewPreference userLoginId="admin"
> viewPrefTypeId="1001" fromDate="..."
> viewPrefItemTypeId="ENUMERATION" viewPrefEnumId="PDF" />
>
> So, we can use these entites for more than just view preferences. Since that is
> true, we should rename the entities so as not to confuse the other developers:
>
> UserPreference
> - userLoginId*
> - userPrefTypeId* (see UserPrefType)
> - fromDate
> - thruDate
> - userPrefItemTypeId (Whether the value is Enum or a String)
> - userPrefEnumId (Stores Enum value)
> - userPrefValue (Stores String value)
>
> UserPrefType
> - userPrefTypeId*
> - prefContext
>
> The names have changed, but you can still accomplish what you set out to do.
> PLUS, your implementation can be used for much more than controlling views.
>
> If something like this is worth considering, then I have one last suggestion.
> The UserPreference entity somewhat duplicates the existing UserSettings entity.
> UserSettings could have fields added to it to do the same thing.
>
> -Adrian
>
> Leon Torres wrote:
>
>
>>Oops, you're right about viewPreferenceId. It's kind of redundant. And context
>>is a better term than coordinate. I'm from a science background and my jargon
>>is showing. :-)
>>
>>- Leon
>>
>>
>>
>>Adrian Crum wrote:
>>
>>
>>>Leon,
>>>
>>>This looks great!
>>>
>>>One suggestion though - maybe refer to what the preference controls as a
>>>"preference context" instead of "coordinate." It might help newcomers understand
>>>its role better.
>>>
>>>What is the purpose of ViewPreference.viewPreferenceId? It seems to me that you
>>>could just look up the preference with a userLoginId and a viewPrefTypeId.
>>>
>>>-Adrian
>>
>>
>>_______________________________________________
>>Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev>>
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev>