http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-tp167905p167908.html
It would be nice if - while you're mulling this over - someone could at least
). Just that small change
If that gets committed, there may be an issue with some of Jacopo's work - since
he had originally modified header.ftl for a single alternative css file. The css
file LIST that I proposed is preferable, but Jacopo was unable to create a list
). In a nutshell, whatever
components use Jacopo's alternative css file will have to be corrected to use a
I would also like to thank Jacopo and anyone else who worked on Jira 174 to get
the GlobalDecorator idea implemented. Without that work, a user-selected UI
> 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