Thank you David, I will try to implement this model. This means we need an additional entity VisualThemeType, correct?
-Bruno 2009/1/5 David E Jones <david.jo...@hotwaxmedia.com>: > > The WebSite entity basically corresponds to a webapp (usually referred to in > the webapp using a webSiteId in the web.xml file). > > About the association, and this may be what you have in mind, the WebSite > should point to a theme "type" rather than individual themes. The "type" is > what all of the styles in the theme are associated with. When new themes are > created as long as they are made for a certain theme type then webapps with > that theme type can use them. > > -David > > > On Jan 5, 2009, at 4:47 AM, Bruno Busco wrote: > >> 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. >>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> > >
