http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-tp167905p167917.html
These details look fine, but I can't really tell without knowing how you imagine them fitting in. In other words, this is more of a step forward and I think to really discuss this we need a step back...
Maybe a question will help: what sorts of things would the user be able to dynamically configure?
You mentioned specifying a css style (which is pretty HTML/CSS specific, but okay...), is there anything else? Is it just colors and fonts?
On a side note, would the implementation be done through the form widget, or would code to support it need to be added all over?
> 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