http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167989.html
Ah, yes... the very crux of the issue...
Whenever trying to design something reusable in a generic way you either create something extremely low level (ie: write it using POJOs), or create a higher level tool that is a benefit _because_ of its limits, not in spite of them. You can't have both, so the limits chosen become the point, and to choose the right limits/constraints you need to look at a lot of examples of things you need/want to be able to do with it.
This is _THE_ reason why the OFBiz framework took so long to evolve. I and others involved in writing it were simply not sufficiently omniscient to create it as it is now from the very beginning. To find what you need to do with it the best thing to do is pick your best guess tool from existing things others have done, and then basically do it manually until a sufficient pattern of redundancy emerges so you can design something to only deal with what you care about.
This sort of per-user configuration is something that cries out for that. So far we've seen 3 or 4 examples of how this stuff might be used, which is way insufficient and with those I think the chances of getting a good re-usable result are about one in a million. I wouldn't even recommend starting something like this without at least 100 specific customizations it is meant to solve, unless the point is to reduce the scope and not make it the preferred long-term solution, or plan to use it as a stepping stone (like we did with JPublish) until more specific usage scenarios can be compiled, and then replace it with whatever comes along.
> Whatever structure you use is fine with me. I only hope the implementation is
> generic enough so we can use it for other user preferences.
>
> Si Chen wrote:
>
>> 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>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev