Posted by
Adrian Crum on
URL: http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-take-2-tp167983p167990.html
David,
Thank you very much for your input!
User preferences settings is an idea I developed for the enterprise app that I
am porting from into OFBiz. I learned long ago that something like this can be
used extensively if implemented correctly. It was one of the first things I
moved over to OFBiz. That's why I kept mistakenly saying that the UserSettings
entity was a part of OFBiz - it had been in there so long that I forgot I put it
there.
I'd like to make one last comment, then I'll drop the subject. I'm not trying to
be argumentative, I just believe strongly that I have a good solution.
If a user preferences entity had only three fields, you can still perform
sophisticated searching on it.
Consider this entity:
UserPreference
- userLoginId*
- userPrefItem
- userPrefValue (String)
And a service built on it:
UserServices
String getUserPreference(userLoginId, userPrefItem)
Map getUserPreferencesLike(userLoginId, userPrefItem)
String setUserPreference(userLoginId, userPrefItem, userPrefValue)
That's basically all you need to implement Si's idea. Other entities can be
built around this to provide pick lists of valid settings and valid values for
those settings.
Using Leon's example, here's how it works:
A preference to let the user select from several
possible views of the order list in ordermgr - OFBIZ_ORDERMGR_VIEW_ORDER_LIST_PREF
Someone mentioned earlier the need to control whether wholesale prices are
displayed, so lets add that control too -
OFBIZ_ORDERMGR_VIEW_DISPLAY_COSTS
Add a report output type preference - OFBIZ_ORDERMGR_REPORTS_OUTPUTTYPE
Somewhere there's a web page that allows the user to set these preferences. The
web page calls UserServices:
setUserPreference(userLoginId, "OFBIZ_ORDERMGR_VIEW_ORDER_LIST_PREF", "ALL")
setUserPreference(userLoginId, "OFBIZ_ORDERMGR_VIEW_DISPLAY_COST", "YES")
setUserPreference(userLoginId, "OFBIZ_ORDERMGR_REPORTS_OUTPUTTYPE", "PDF")
Now it's time to display the Order Manager page. An action calls UserServices:
Map ViewSettingsMap = getUserPreferencesLike(userLoginId, "OFBIZ_ORDERMGR_VIEW_")
The service looks up matching preferences in the UserPreference entity using the
SQL LIKE keyword, strips the supplied key skeleton (userPrefItem) from the
results and returns this set of key-value pairs:
"ORDER_LIST_PREF", "ALL"
"DISPLAY_COST", "YES"
Screen widgets and FTL templates love Maps. With this Map we have an easy way to
control the view.
There you have it - a single entity and a simple service that can control any
user preference anywhere in OFBiz. Si says my implementation is "not really
consistent with the rest of OFBiz." I disagree. Take a look at SecurityPermission.
I've made my case. I'm done.
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.
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev