Dev - configurable custom views
Locked
12
12
 
|
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 |
Re: Dev - configurable custom views
|
|
We implemented UI themes that users can choose from. Maybe some of that work
could be helpful. 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 |
|
|
Maybe . . . Can you create a JIRA issue for it?
Adrian Crum wrote: We implemented UI themes that users can choose from. Maybe some of that work could be helpful. 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 |
Re: Dev - configurable custom views
|
|
Sure.
Also, someone asked me privately about the implementation, so I'll C&P it here... I modified header.ftl to support alternative style sheets. If an alternative style sheet is in the environment, then the maincss.css is disabled and the alternative is used. I copied and modified the maincss.css file to create different themes. One css file for each theme. I set up a "Workspace Manager" web page where the user can select from a list of themes. The web page stores their selection in the user setting entity. I modified the GlobalDecorator so that it calls an action that gets the user's current theme from the user setting entity and puts it in the environment. Some of this was submitted in Jira 174. That Jira issue is kinda outdated now, but the changes I made to header.ftl will still work. Si Chen wrote: > Maybe . . . Can you create a JIRA issue for it? > > Adrian Crum wrote: > >>We implemented UI themes that users can choose from. Maybe some of that work >>could be helpful. >> >> >> >>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 |
|
|
In reply to this post by Si Chen-2
Hi Si,
How should user use this preference feature, could you please provide more information? I think it should be a very interesting feature, but I am not sure if it can be as powerful as I expect with the current GUI rendering mechanism. Thanks Lei On 5/10/06, Si Chen <[hidden email]
> wrote: Hi everybody - _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views
|
|
In reply to this post by Adrian Crum
http://jira.undersunconsulting.com/browse/OFBIZ-880
Adrian Crum wrote: > Sure. > > Also, someone asked me privately about the implementation, so I'll C&P it here... > > I modified header.ftl to support alternative style sheets. If an alternative > style sheet is in the environment, then the maincss.css is disabled and the > alternative is used. > > I copied and modified the maincss.css file to create different themes. One css > file for each theme. > > I set up a "Workspace Manager" web page where the user can select from a list of > themes. The web page stores their selection in the user setting entity. > > I modified the GlobalDecorator so that it calls an action that gets the user's > current theme from the user setting entity and puts it in the environment. > > Some of this was submitted in Jira 174. That Jira issue is kinda outdated now, > but the changes I made to header.ftl will still work. > > > > Si Chen wrote: > > >>Maybe . . . Can you create a JIRA issue for it? >> >>Adrian Crum wrote: >> >> >>>We implemented UI themes that users can choose from. Maybe some of that work >>>could be helpful. >>> >>> >>> >>>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 |
|
|
In reply to this post by Si Chen-2
Hi all...
I am migrating the ofbiz data from windows to linux. The problem is all the table names is lowercase when i exported the data from windows. But the uppercases are used in ofbiz codes. Application can't find any tables on linux platform. I readed some articles in the internet. They all highly recommender using lowercase names for database design. So I am confused that why ofbiz used uppercase for table and column names? Thanks, Andy
Yahoo! Mail goes everywhere you do. Get it on your phone. _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Why not use lowercase for table names and column names
|
|
Andy,
Entity names use a combined case and tables use uppercase. I don't know that it really matters what case is used, (any case will work) that's just what OFBiz has chosen to do. If you are trying to migrate, you can avoid the problem you describe by using the entity export in webtools. E.g. 1/ Dump your data from windows box using XML export. 2/ Install OFBiz on the linux box 3/ import your data using something like... java -jar -Xmx512M ofbiz.jar -install -timeout=7200 - dir=/path/to/your/xml/files I hope this solves your problem -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Andrew,
Thanks for your help! I think the resolvent you mentioned in your mail should be the correct way for this problem. However, I changed the lower_case_table_names setting of mysql. You can find its reference via http://mysql.telepac.pt/doc/refman/4.1/en/name-case-sensitivity.htmlIt's also can resolve the problem, but not recommend. :) Ok, thanks again. Andy
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. _______________________________________________ Dev mailing list Dev@... http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Why not use lowercase for table names and column names
|
|
Andy,
That's an interesting trick, thanks for sharing it. On Thu, 2006-05-11 at 05:33 -0700, Andy Lu wrote: > Andrew, > > Thanks for your help! > I think the resolvent you mentioned in your mail should be the correct > way for this problem. > However, I changed the lower_case_table_names setting of mysql. You > can find its reference via > http://mysql.telepac.pt/doc/refman/4.1/en/name-case-sensitivity.html > It's also can resolve the problem, but not recommend. :) > > Ok, thanks again. > > Andy > > > > ______________________________________________________________________ > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great > rates starting at 1¢/min. > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views
|
|
In reply to this post by Si Chen-2
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 |
|
|
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 |
Re: Dev - configurable custom views
|
|
It would be nice if - while you're mulling this over - someone could at least
commit the change to header.ftl (http://jira.undersunconsulting.com/browse/OFBIZ-880 ). Just that small change will enable a number of users to easily customize the UI. 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 the screen widget (see the notes on http://jira.undersunconsulting.com/browse/OFBIZ-174 ). In a nutshell, whatever components use Jacopo's alternative css file will have to be corrected to use a css file list. 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 theme would require a lot more modification. -Adrian 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 |
Re: Dev - configurable custom views
|
|
In reply to this post by Si Chen-2
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 |
Re: Dev - configurable custom views
|
|
In reply to this post by Adrian Crum
Adrian,
about the styleSheet LIST issue: some time ago, David told me how to create lists inside a screen action tag: <set field="styleSheets[]" value="/images/customstyles.css"/> <set field="styleSheets[]" value="/images/specialcustomstyles.css"/> So this is no more an issue; it's ok for me to commit your changes. However, what do you (all) think of the attached patch? Jacopo Adrian Crum wrote: > It would be nice if - while you're mulling this over - someone could at least > commit the change to header.ftl > (http://jira.undersunconsulting.com/browse/OFBIZ-880 ). Just that small change > will enable a number of users to easily customize the UI. > > 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 the screen widget (see the notes on > http://jira.undersunconsulting.com/browse/OFBIZ-174 ). In a nutshell, whatever > components use Jacopo's alternative css file will have to be corrected to use a > css file list. > > 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 > theme would require a lot more modification. > > -Adrian > Index: framework/common/webcommon/includes/header.ftl =================================================================== --- framework/common/webcommon/includes/header.ftl (revision 7592) +++ framework/common/webcommon/includes/header.ftl (working copy) @@ -41,8 +41,15 @@ <script language="javascript" src="<@ofbizContentUrl>/images/calendar1.js</@ofbizContentUrl>" type="text/javascript"></script> <script language="javascript" src="<@ofbizContentUrl>/images/selectall.js</@ofbizContentUrl>" type="text/javascript"></script> <script language="javascript" src="<@ofbizContentUrl>/images/fieldlookup.js</@ofbizContentUrl>" type="text/javascript"></script> - <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> - <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> + <#if layoutSettings.styleSheets?has_content> + <#--layoutSettings.styleSheets is a list of style sheets. So, you can have a user-specified "main" style sheet, AND a component style sheet.--> + <#list layoutSettings.styleSheets as styleSheet> + <link rel="stylesheet" href="<@ofbizContentUrl>${styleSheet}</@ofbizContentUrl>" type="text/css"> + </#list> + <#else> + <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> + <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> + </#if> <#if layoutSettings.extraStyleSheet?exists> <#-- Component-specified style sheet --> <link rel="stylesheet" href="${layoutSettings.extraStyleSheet}" type="text/css"/> _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
In reply to this post by David E. Jones
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: _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views
|
|
In your CRM example, would it be essentially the same web page, only different
data and/or labels? Si Chen wrote: > 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 _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Some of the data would be different. Later some of the sections of a
page might be hidden. Or we might change default viewIndex, etc. for
the user throughout the application.
Si Adrian Crum wrote: In your CRM example, would it be essentially the same web page, only different data and/or labels? Si Chen wrote: _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - configurable custom views
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
Since no one has objected to this, could we get it committed? -Adrian Jacopo Cappellato wrote: > Adrian, > > about the styleSheet LIST issue: some time ago, David told me how to > create lists inside a screen action tag: > > <set field="styleSheets[]" value="/images/customstyles.css"/> > <set field="styleSheets[]" value="/images/specialcustomstyles.css"/> > > So this is no more an issue; it's ok for me to commit your changes. > > However, what do you (all) think of the attached patch? > > Jacopo > > > Adrian Crum wrote: > >> It would be nice if - while you're mulling this over - someone could >> at least commit the change to header.ftl >> (http://jira.undersunconsulting.com/browse/OFBIZ-880 ). Just that >> small change will enable a number of users to easily customize the UI. >> >> 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 the screen widget (see the >> notes on http://jira.undersunconsulting.com/browse/OFBIZ-174 ). In a >> nutshell, whatever components use Jacopo's alternative css file will >> have to be corrected to use a css file list. >> >> 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 theme would require a lot more modification. >> >> -Adrian >> > > > ------------------------------------------------------------------------ > > Index: framework/common/webcommon/includes/header.ftl > =================================================================== > --- framework/common/webcommon/includes/header.ftl (revision 7592) > +++ framework/common/webcommon/includes/header.ftl (working copy) > @@ -41,8 +41,15 @@ > <script language="javascript" src="<@ofbizContentUrl>/images/calendar1.js</@ofbizContentUrl>" type="text/javascript"></script> > <script language="javascript" src="<@ofbizContentUrl>/images/selectall.js</@ofbizContentUrl>" type="text/javascript"></script> > <script language="javascript" src="<@ofbizContentUrl>/images/fieldlookup.js</@ofbizContentUrl>" type="text/javascript"></script> > - <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> > - <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> > + <#if layoutSettings.styleSheets?has_content> > + <#--layoutSettings.styleSheets is a list of style sheets. So, you can have a user-specified "main" style sheet, AND a component style sheet.--> > + <#list layoutSettings.styleSheets as styleSheet> > + <link rel="stylesheet" href="<@ofbizContentUrl>${styleSheet}</@ofbizContentUrl>" type="text/css"> > + </#list> > + <#else> > + <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> > + <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> > + </#if> > <#if layoutSettings.extraStyleSheet?exists> > <#-- Component-specified style sheet --> > <link rel="stylesheet" href="${layoutSettings.extraStyleSheet}" type="text/css"/> > > > ------------------------------------------------------------------------ > > > _______________________________________________ > 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
|
|
David,
what do you think of this? Jacopo Adrian Crum wrote: > Jacopo, > > Since no one has objected to this, could we get it committed? > > -Adrian > > > Jacopo Cappellato wrote: >> Adrian, >> >> about the styleSheet LIST issue: some time ago, David told me how to >> create lists inside a screen action tag: >> >> <set field="styleSheets[]" value="/images/customstyles.css"/> >> <set field="styleSheets[]" value="/images/specialcustomstyles.css"/> >> >> So this is no more an issue; it's ok for me to commit your changes. >> >> However, what do you (all) think of the attached patch? >> >> Jacopo >> >> >> Adrian Crum wrote: >> >>> It would be nice if - while you're mulling this over - someone could >>> at least commit the change to header.ftl >>> (http://jira.undersunconsulting.com/browse/OFBIZ-880 ). Just that >>> small change will enable a number of users to easily customize the UI. >>> >>> 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 the screen widget (see the >>> notes on http://jira.undersunconsulting.com/browse/OFBIZ-174 ). In a >>> nutshell, whatever components use Jacopo's alternative css file will >>> have to be corrected to use a css file list. >>> >>> 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 theme would require a lot more modification. >>> >>> -Adrian >>> >> >> ------------------------------------------------------------------------ >> >> Index: framework/common/webcommon/includes/header.ftl >> =================================================================== >> --- framework/common/webcommon/includes/header.ftl (revision 7592) >> +++ framework/common/webcommon/includes/header.ftl (working copy) >> @@ -41,8 +41,15 @@ >> <script language="javascript" src="<@ofbizContentUrl>/images/calendar1.js</@ofbizContentUrl>" type="text/javascript"></script> >> <script language="javascript" src="<@ofbizContentUrl>/images/selectall.js</@ofbizContentUrl>" type="text/javascript"></script> >> <script language="javascript" src="<@ofbizContentUrl>/images/fieldlookup.js</@ofbizContentUrl>" type="text/javascript"></script> >> - <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> >> - <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> >> + <#if layoutSettings.styleSheets?has_content> >> + <#--layoutSettings.styleSheets is a list of style sheets. So, you can have a user-specified "main" style sheet, AND a component style sheet.--> >> + <#list layoutSettings.styleSheets as styleSheet> >> + <link rel="stylesheet" href="<@ofbizContentUrl>${styleSheet}</@ofbizContentUrl>" type="text/css"> >> + </#list> >> + <#else> >> + <link rel="stylesheet" href="<@ofbizContentUrl>/images/maincss.css</@ofbizContentUrl>" type="text/css"/> >> + <link rel="stylesheet" href="<@ofbizContentUrl>/images/tabstyles.css</@ofbizContentUrl>" type="text/css"/> >> + </#if> >> <#if layoutSettings.extraStyleSheet?exists> >> <#-- Component-specified style sheet --> >> <link rel="stylesheet" href="${layoutSettings.extraStyleSheet}" type="text/css"/> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |