Posted by
Si Chen-2 on
URL: http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-tp167905p167907.html
Hi David,
My immediate needs are fairly limited, but I thought it might be nice
to put the framework in place so we can expand it as we need. It could
be supplementary to the ability to change the code, so we can offer
user- and developer-configurable views, etc.
I looked over Adrian Crum's work, which is quite good, and thought that
perhaps we should generalize it a step further like this:
ViewPreference - viewPreferenceId*, description
(master header entity)
ViewPreferenceItem - viewPreferenceId, viewPrefItemTypeId,
viewPrefTypeId, viewPrefEnumId (fk Enumeration), viewPrefValue,
viewPrefIndicator
(kind of like a SurveyQuestion - can either point to an enumeration,
true/false, or value)
ViewPrefItemType - viewPrefItemTypeId, description
(3 possible values: BOOLEAN, ENUMERATION, VALUE, to control
viewPreferenceItem)
ViewPrefType - viewPrefTypeId, description, application, screenName,
formName
(This controls whether the view preference is just a free-form view
preference or whether it should be associated specifically with a
particular screen or form. For example, CSS_STYLE could be free form
and used anywhere. Or, you can add an application and screen/form name
to control an aspect of that particular screen/form or application.
Specifically what is specified is left open at this point. We can fill
it in later.)
UserLoginViewPref - userLoginId, viewPreferenceId, fromDate, thruDate
(Associate user logins with preferences)
Probably permission for create/update/expire view preferences. User
can either update his own or update others' if he/she had permission.
Does this make sense?
Si
David E Jones wrote:
Si,
This could be something of interest in the project. I've certainly heard questions about things like this over the years...
Stepping back a little from the implementation: what types of things would the user be able to configure? You mentioned different content, and I've heard requests for things like custom fields on a form, or removing fields, or even going as far as "user configurable reports" and the like. I think a lot of this stems from what some applications do to make these sorts of changes easier, and in some cases this is the _only_ way to change the apps, so people get really hung up about it and aren't sure what to think when it is not included in something like OFBiz.
-David
Si Chen wrote:
Hi everybody -
We want to implement a feature where users can configure their view
choices in the applications. For example, the same page can serve up
different content, etc. I think this would have to be implemented
specifically in each application, but nevertheless a common data model
for all of them might be nice.
My questions:
1. Is this something we want in OFBIZ?
2. If so, here's what I have so far
ViewPreference: header entity with an ID, description, etc.
ViewPreferenceItem consisting of viewPrefId, component, view, item (FK
on enum)
ViewPreferenceEnums is a list of allowable choices for all the view
preferences
UserLoginViewPreference - allows userLogin to be associated with a view
preference
Does this sound reasonable?
Where I'm a little hazy is how ViewPreferenceItem should be. Should be
structured around application compnent and view-request, or around
screens and sub-screens, or form/fields? Or should we have something
that would allow all of the above, so users can configure any of those?
Thanks,
Si
_______________________________________________
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