http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167988.html
Whatever structure you use is fine with me. I only hope the implementation is
> Adrian,
>
> I would not like a scheme where all sorts of data were bundled into a
> key like TypeId. It would make searching much harder later, and it's
> not really consistent with the rest of OFBiz (see for example the
> ProductPrice entity) either. That's just my 2 cents anyway.
>
> Si
>
> Adrian Crum wrote:
>
>>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>>
>>
>>
>>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev