ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno Busco" <bruno.bu...@gmail.com>
Subject Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
Date Mon, 05 Jan 2009 19:31:52 GMT
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.jones@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.roux@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.busco@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.crum@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.jones@hotwaxmedia.com>
>>>>> wrote:
>>>>>
>>>>>> From: David E Jones <david.jones@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) <jira@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.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

Mime
View raw message