Adrian, a solution to your point could be to support one-to-many relation between VisualThemes and Applications. So, if I design a theme that is not so specialized for ecommerce and can work on backoffice also, I could relate it to both ecommerce AND backoffice. Or ecommerce1 (and not ecommerce2) and backoffice or something like this.
In the VisulaTheme selection lookups a filter for applicable VT will be done. -Bruno 2008/12/31 Adrian Crum <adrian.c...@yahoo.com>: > Bruno and David, > > Your replies repeat the discussions we had during the development of the > Visual Themes implementation. I don't believe there is any disagreement on > their benefits, or how they are to be used, or the future of theme galleries. > > The point I was trying to make is this: If I'm a back office worker, and I > really like the theme used for the company's eCommerce site, I should be able > to select that theme for my back office applications. Bruno's proposal would > make that impossible because eCommerce themes will work ONLY on eCommerce. I > don't think we should force that distinction. Plus, it places an additional > burden on theme developers who would have to create two versions of each > theme - one for back office applications and one for eCommerce. > > -Adrian > > > --- On Tue, 12/30/08, David E Jones <david.jo...@hotwaxmedia.com> wrote: > >> From: David E Jones <david.jo...@hotwaxmedia.com> >> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce >> To: dev@ofbiz.apache.org >> Date: Tuesday, December 30, 2008, 2:01 PM >> Personally I like having the internal and public facing >> sites different, and my guess is that most organizations >> with a public facing site (ecommerce or other) will have it >> quite different from the internal site(s). >> >> To take this further, I think we should even support >> multiple theme sets to the point where people can create >> their own theme sets to use with custom applications whether >> they be public facing or internal. For example some crazy >> company might want a custom SFA app with its own theme >> because their sales people have a very different set of >> tastes from other departments in the company, and even >> moreso because they want to design the application totally >> differently so the same set of styles won't work. >> >> That last point is really the most important: we really >> should support the ability to have a themed application with >> a custom set of styles and not force people to use the >> styles OOTB. Whenever you dramatically change the design of >> an app you tend to need different styles than for a very >> different design and in those cases we either don't >> support themes or we support multiple theme sets (I >> don't like "theme type" BTW since it means >> nothing, but not sure "theme set" is a lot better) >> so people can introduce their own and have them live with >> the OOTB OFBiz theme sets. >> >> For OFBiz we'd probably maintain what we are >> maintaining now: one for internal (back-end) apps, and one >> for public facing apps (mostly ecommerce). The excuse that >> these are being well maintained (or maintained to your >> liking) right now doesn't influence this argument either >> way, IMO, and is largely irrelevant. >> >> -David >> >> >> On Dec 30, 2008, at 2:04 PM, Bruno Busco wrote: >> >> > Adrian, >> > I cannot see the problem. >> > >> > Right now we have and maintain two themes, one for >> ecommerce and one >> > for backoffice. Each theme is composed by an header, a >> footer, several >> > stylesheets and other related files. >> > >> > These files are distributed into ofbiz folders and >> now, with the >> > introduction of VisualThemes, each set of file has >> been grouped and >> > labeled with a VisualTheme. >> > >> > I think that we will never add more themes into the >> SVN (my >> > vt_multiflex.zip file is absolutely not intended to be >> commited). >> > So we should always take care, into the SVN, of only >> two themes as is >> > has been unitl now (no one more file). >> > >> > In the theme gallery in Confluence there will be >> hopefully more themes >> > available to be downloaded and installed locally. The >> Theme manager >> > into OFBiz will let the user to have many of them to >> choose from. >> > >> > In this case the new visualThemeTypeId field could be >> handy in a way >> > that only applicable themes out of what has been >> installed are offered >> > to the user to choose from. >> > >> > If OFBIZ-1119 will go further and we will have both >> ecommerce and >> > backoffice to share the same stylesheets AND header >> AND footer (which >> > I really do not think be possible) we could then do >> not use the >> > visualTheme classification and use just one class. >> > >> > -Bruno >> > >> > >> > 2008/12/30 Adrian Crum (JIRA) <j...@apache.org>: >> >> >> >> [ >> https://issues.apache.org/jira/browse/OFBIZ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659910#action_12659910 >> ] >> >> >> >> Adrian Crum commented on OFBIZ-2106: >> >> ------------------------------------ >> >> >> >> Bruno, >> >> >> >> I'm trying to be realistic. Look at OFBIZ-1119 >> - it is 18 months old and no progress has been made on it. >> That issue represents only one stylesheet. What you're >> suggesting is that we have multiple versions of stylesheets >> and other files for each theme - multiplied by the number of >> themes in the project (if we agree to have more than one) >> which yields potentially dozens of theme files that need to >> be maintained. Yet currently we can't keep only one >> updated. >> >> >> >> >> >>> Visual Themes for Ecommerce >> >>> --------------------------- >> >>> >> >>> Key: OFBIZ-2106 >> >>> URL: >> https://issues.apache.org/jira/browse/OFBIZ-2106 >> >>> Project: OFBiz >> >>> Issue Type: New Feature >> >>> Components: ecommerce >> >>> Affects Versions: SVN trunk >> >>> Reporter: Bruno Busco >> >>> Attachments: bin.zip, >> BrowseCategoryCSS.patch, EcommerceVisualTheme.patch, >> EcommerceVisualTheme.patch, screenshot.JPG, vt_multiflex.zip >> >>> >> >>> >> >>> Hi, >> >>> in the attached patch a simple implementation >> of selectable visual themes for the ecommerce application. >> >>> I have added the "visualThemeId" to >> the ProductStore entity. The user can select one of the >> available themes in the EditProductStore screen. >> >>> I have defined the actual ecommerce theme as >> the default theme that is "EC_DEFAULT". >> >>> I have followed for the ecommerce >> main-decorator screen a pattern similar to what done for the >> back-end. >> >>> One thing that we could think to do (but I >> would like to hear someone about) is to add a >> "typeId" field or similar to the VisualTheme >> entity that could be used to distinguish between the themes >> for the back-end and for the ecommerce. >> >>> Right now it is possible to select all of the >> available themes for bost application and this results in a >> mess if, for example, a theme for ecommerce is selected for >> the back-end and viceversa. >> >> >> >> -- >> >> This message is automatically generated by JIRA. >> >> - >> >> You can reply to this email to add a comment to >> the issue online. >> >> >> >> > > > >
