Has somebody an idea on how to implement a one-to-many relation between VisualThemes and WebApps ? There should be a way to tell that a VisualTheme1 can be applyed to application1, application2 while VisualTheme2 can be applied to application2 and application3.
AFAIK there is no an entity that models WebApps so I cannot see what is the right way to do this. Any idea? -Bruno 2009/1/1 Jacques Le Roux <jacques.le.r...@les7arts.com>: > Sounds like a reasonnable solution. I can't see the point discussing on this > so long (maybe I miss it ;o). > My opinion is that this should be open : they should be "shareable" but do > not have to be (if it's understandable in real English > ;o) > > Jacques > > From: "Bruno Busco" <bruno.bu...@gmail.com> >> >> 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. >>>> >> >>>> >> >>> >>> >>> >>> >> > >
