http://ofbiz.116.s1.nabble.com/Dev-configurable-custom-views-tp167905p167919.html
In your CRM example, would it be essentially the same web page, only different
> Hi David,
>
> The first specific use for it is for the CRM application, where the
> "home" page could either be "My Accounts" or "My Teams' Accounts". An
> example would be:
> ViewPrefItem - application: CRM (or ORDERMGR, etc.), section: ACCOUNTS,
> viewPrefType: MY_OR_TEAM, viewPrefEnumId: MY_VALUES or MY_TEAM_VALUES
> Then it gets associated up to the ViewPreference and through to a UserLogin.
>
> I'm not sure about implementation yet...maybe it should go through form
> and screen widget. We're still trying to figure out how best to
> implement it.
>
> Over time it could support choices about different screens' values, form
> CSS, etc. etc.
>
> Hope this helps...
>
> Si
>
> David E Jones wrote:
>
>>Si,
>>
>>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?
>>
>>I guess what I'm looking for is the "user story"...
>>
>>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?
>>
>>-David
>>
>>
>>Si Chen wrote:
>>
>>
>>>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>>>
>>>
>>
>>_______________________________________________
>>Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev>>
>>
>>
>>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev