Re: Dev - configurable custom views take 2
Posted by
Si Chen-2 on
URL: http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167992.html
Well, at this point we've gotten the entities laid out and have some
general ideas on how they could be used. I think it's fairly
extensible and reusable, but obviously time will be the best judge of
that. So, should we commit it to the party manager for now, so others
can start playing with it? Or should we just keep it out of OFBiz for
now? If you'd like, I can put the patch on JIRA, and you can take a
look at it.
Si
David E Jones wrote:
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.
-David
Adrian Crum wrote:
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
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev