Dev - configurable custom views take 2
Locked
Dev - configurable custom views take 2
 
|
After attempting to implement ViewPreferences, we found a few issues that
suggested overdesign. Upon reconsidering the model, we came up with a much better one, ViewPreference - viewPreferenceId* (serial ID) - userLoginId* - viewPrefTypeId* (see ViewPrefType) - fromDate - thruDate - viewPrefItemTypeId (Whether the value is Enum or a String) - viewPrefEnumId (Stores Enum value) - viewPrefValue (Stores String value) ViewPrefType - viewPrefTypeId* - application (e.g., OFBIZ, CRMSFA, etc.) - applicationSection (e.g., ORDERMGR) - screenName - formName Essentially, the ViewPreference is key-value data tied to a specific userLoginId. The key is simply the viewPrefTypeId, which contains information about the "coordinates" of where in the applicatin the preference applies. That way one can select all keys (preferences) for a given form, screen, etc. An example of usage: Suppose we want to let the user select from several possible views of the order list in ordermgr, * Sales Orders Only * Purchase Orders Only * All Orders We define a ViewPrefType for this preference (global cooridnate for simplicity): <ViewPrefType viewPrefTypeId="ORDER_LIST_PREF" application="OFBIZ" /> And the options are by enumeration, <Enumeration enumId="ORDER_LIST_PREF_ALL" ... /> <Enumeration enumId="ORDER_LIST_PREF_SALES" ... /> <Enumeration enumId="ORDER_LIST_PREF_PURCH" ... /> Then the value is determined by a ViewPreference entry, <ViewPreference viewPreferenceId="1000" userLoginId="admin" viewPrefTypeId="ORDER_LIST_PREF" fromDate="..." viewPrefItemTypeId="ENUMERATION" viewPrefEnumId="ORDER_LIST_PREF_ALL" /> So now the admin will see all orders. If the admin changes it to list sales orders, the viewPrefEnumId is updated to "ORDER_LIST_PREF_SALES". Next time the admin comes to the order list, he'll see sales orders. Later on, if we want to group them, we can have ViewPrefGroup. - Leon _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views take 2
|
|
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 Leon Torres wrote: > After attempting to implement ViewPreferences, we found a few issues that > suggested overdesign. Upon reconsidering the model, we came up with a much > better one, > > ViewPreference > - viewPreferenceId* (serial ID) > - userLoginId* > - viewPrefTypeId* (see ViewPrefType) > - fromDate > - thruDate > - viewPrefItemTypeId (Whether the value is Enum or a String) > - viewPrefEnumId (Stores Enum value) > - viewPrefValue (Stores String value) > > ViewPrefType > - viewPrefTypeId* > - application (e.g., OFBIZ, CRMSFA, etc.) > - applicationSection (e.g., ORDERMGR) > - screenName > - formName > > Essentially, the ViewPreference is key-value data tied to a specific > userLoginId. The key is simply the viewPrefTypeId, which contains > information about the "coordinates" of where in the applicatin the > preference applies. That way one can select all keys (preferences) > for a given form, screen, etc. > > An example of usage: Suppose we want to let the user select from several > possible views of the order list in ordermgr, > > * Sales Orders Only > * Purchase Orders Only > * All Orders > > We define a ViewPrefType for this preference (global cooridnate for simplicity): > > <ViewPrefType viewPrefTypeId="ORDER_LIST_PREF" application="OFBIZ" /> > > And the options are by enumeration, > > <Enumeration enumId="ORDER_LIST_PREF_ALL" ... /> > <Enumeration enumId="ORDER_LIST_PREF_SALES" ... /> > <Enumeration enumId="ORDER_LIST_PREF_PURCH" ... /> > > Then the value is determined by a ViewPreference entry, > > <ViewPreference viewPreferenceId="1000" userLoginId="admin" > viewPrefTypeId="ORDER_LIST_PREF" fromDate="..." > viewPrefItemTypeId="ENUMERATION" viewPrefEnumId="ORDER_LIST_PREF_ALL" /> > > So now the admin will see all orders. If the admin changes it to list > sales orders, the viewPrefEnumId is updated to "ORDER_LIST_PREF_SALES". > Next time the admin comes to the order list, he'll see sales orders. > > Later on, if we want to group them, we can have ViewPrefGroup. > > - Leon > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views take 2
|
|
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 |
Re: Dev - configurable custom views take 2
|
|
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 |
Re: Dev - configurable custom views take 2
|
|
Oops, my bad. The UserSettings entity is something we created in house. It's not
a part of OFBiz. Sorry for the confusion. 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 |
|
|
In reply to this post by Adrian Crum
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:
_______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views take 2
|
|
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 |
Re: Dev - configurable custom views take 2
|
|
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 |
|
|
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: _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views take 2
|
|
In reply to this post by David E. Jones
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 |
Re: Dev - configurable custom views take 2
|
|
Adrian Crum wrote:
> 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) Hi, do you realize that the model we propose is exactly this? It's also a superset. We have exactly those get/set methods in our implementation. You don't have to use the extra fields in the ViewPrefType Entity, they are only metadata. Both your proposal and the one posted by us are essentially a persistent hashmap with two keys, the userLoginId and a String key. (We took out the fromDate and thruDate.) So pardon me if I don't understand your objections, which have appeared to have caused the inclusion of this feature, no matter who's version, to be stalled. - Leon _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |