http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167987.html
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.
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