[jira] Created: (OFBIZ-2106) Visual Themes for Ecommerce

[David E Jones-3]

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) <[hidden email]>:
>>
>>   [ 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.
>>
>>

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659963#action_12659963 ]

Bruno Busco commented on OFBIZ-2106:
------------------------------------

The Multiflex ecommerce theme is also available in the OFBiz Visual Theme Gallery http://docs.ofbiz.org/display/OFBIZ/Visual+Themes+Gallery

> 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, EcommerceVisualTheme.patch, screenshot.JPG, screenshot_1.jpg, vt_multiflex.zip, 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.

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Busco updated OFBIZ-2106:
-------------------------------

    Attachment: bin.zip

An additional change I forgot to describe in the BrowseCategoryCSS patch file is the restyling of the breadcrumbs with a special class style for it.
The html embedded "->" chars have been removed and replaced by a CSS specified bullet arrow.
In this updated bin.zip file I added the relative bullet gif used by the patch.

> 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, bin.zip, BrowseCategoryCSS.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, screenshot.JPG, screenshot_1.jpg, vt_multiflex.zip, 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.

[Bruno Busco]

David,
I agree 100% to this idea.

As far as I can understand the proposed patch is complelety aligned to this.
Please advice if you see it is not.

-Bruno

2008/12/30 David E Jones <[hidden email]>:

>
> 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) <[hidden email]>:
>>>
>>>  [
>>> 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.
>>>
>>>
>
>

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
> To: [hidden email]
> 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) <[hidden email]>:
> >>
> >>   [
> 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.
> >>
> >>

     

[David E Jones-3]

We could certainly have some styles shared, but if we introduced the  
restriction that all styles had to be shared it would severely limit  
what can be done in both public facing and internal sites. I don't  
think we'll ever get around the simple fact that different designs  
require different sets of styles. If you don't believe that to be the  
case, just try doing so with the simple and artificial scenario of the  
current OFBiz internal apps and the ecommerce demo.

If we accept that not all possible apps could be driven by the same  
set of styles then we need to support multiple sets of styles, with a  
different theme set/template for each set of styles.

Unless I'm misunderstanding something that's really the only  
distinguishing, and therefore relevant, point.

-David


On Dec 31, 2008, at 10:04 AM, Adrian Crum wrote:

> 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 <[hidden email]>  
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for  
>> Ecommerce
>> To: [hidden email]
>> 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) <[hidden email]>:
>>>>
>>>>  [
>> 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.
>>>>
>>>>
>
>
>

[Adrian Crum-2]

I guess it's because I don't see eCommerce as being that unique. In other words, we have a dozen or so back office applications that all share the same visual theme, so why can't eCommerce share it too?

What makes eCommerce so different? Nothing as far as I can tell. It has a masthead, footer, main navigation, main content area, columns, screenlets, etc - just like the back office applications.

If we don't enforce theme compatibility, then what is the point in having them? There would be no guarantee (or even a reasonable expectation) that a particular theme will work with a particular application. I believe the visual theme framework has been set up in such a way that there is very little restriction in layout, but it has enough structure to ensure compatibility. If restrictions are found, we can address them at that time.

-Adrian

--- On Wed, 12/31/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
> To: [hidden email]
> Date: Wednesday, December 31, 2008, 11:58 AM
> We could certainly have some styles shared, but if we
> introduced the restriction that all styles had to be shared
> it would severely limit what can be done in both public
> facing and internal sites. I don't think we'll ever
> get around the simple fact that different designs require
> different sets of styles. If you don't believe that to
> be the case, just try doing so with the simple and
> artificial scenario of the current OFBiz internal apps and
> the ecommerce demo.
>
> If we accept that not all possible apps could be driven by
> the same set of styles then we need to support multiple sets
> of styles, with a different theme set/template for each set
> of styles.
>
> Unless I'm misunderstanding something that's really
> the only distinguishing, and therefore relevant, point.
>
> -David
>
>
> On Dec 31, 2008, at 10:04 AM, Adrian Crum wrote:
>
> > 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
> <[hidden email]> wrote:
> >
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual
> Themes for Ecommerce
> >> To: [hidden email]
> >> 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)
> <[hidden email]>:
> >>>>
> >>>>  [
> >>
> 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.
> >>>>
> >>>>
> >
> >
> >

     

[David E Jones-3]

I guess Adrian doesn't believe me. Could someone pitch in and share  
your experiences implementing designs for ecommerce sites?

To get things started (hopefully) I'd say the biggest distinction is  
that for internal applications efficiency and few surprises are the  
goal, and therefore consistency is important, and for ecommerce sites  
the goal is to make each one different and attract attention and keep  
users on the site through any means possible.

If you have the same styles you have the same column widths, colors,  
etc, etc. What if you have multiple ecommerce sites with very  
different audiences? If all we give designers is a dramatically  
limited palette we can't expect to see good results... just consistent  
ones.

-David


On Dec 31, 2008, at 9:42 PM, Adrian Crum wrote:

> I guess it's because I don't see eCommerce as being that unique. In  
> other words, we have a dozen or so back office applications that all  
> share the same visual theme, so why can't eCommerce share it too?
>
> What makes eCommerce so different? Nothing as far as I can tell. It  
> has a masthead, footer, main navigation, main content area, columns,  
> screenlets, etc - just like the back office applications.
>
> If we don't enforce theme compatibility, then what is the point in  
> having them? There would be no guarantee (or even a reasonable  
> expectation) that a particular theme will work with a particular  
> application. I believe the visual theme framework has been set up in  
> such a way that there is very little restriction in layout, but it  
> has enough structure to ensure compatibility. If restrictions are  
> found, we can address them at that time.
>
> -Adrian
>
> --- On Wed, 12/31/08, David E Jones <[hidden email]>  
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for  
>> Ecommerce
>> To: [hidden email]
>> Date: Wednesday, December 31, 2008, 11:58 AM
>> We could certainly have some styles shared, but if we
>> introduced the restriction that all styles had to be shared
>> it would severely limit what can be done in both public
>> facing and internal sites. I don't think we'll ever
>> get around the simple fact that different designs require
>> different sets of styles. If you don't believe that to
>> be the case, just try doing so with the simple and
>> artificial scenario of the current OFBiz internal apps and
>> the ecommerce demo.
>>
>> If we accept that not all possible apps could be driven by
>> the same set of styles then we need to support multiple sets
>> of styles, with a different theme set/template for each set
>> of styles.
>>
>> Unless I'm misunderstanding something that's really
>> the only distinguishing, and therefore relevant, point.
>>
>> -David
>>
>>
>> On Dec 31, 2008, at 10:04 AM, Adrian Crum wrote:
>>
>>> 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
>> <[hidden email]> wrote:
>>>
>>>> From: David E Jones
>> <[hidden email]>
>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual
>> Themes for Ecommerce
>>>> To: [hidden email]
>>>> 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)
>> <[hidden email]>:
>>>>>>
>>>>>> [
>>>>
>> 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.
>>>>>>
>>>>>>
>>>
>>>
>>>
>
>
>

[Bruno Busco]

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 <[hidden email]>:

> 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 <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
>> To: [hidden email]
>> 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) <[hidden email]>:
>> >>
>> >>   [
>> 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.
>> >>
>> >>
>
>
>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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 <[hidden email]>:
>> 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 <[hidden email]> wrote:
>>
>>> From: David E Jones <[hidden email]>
>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
>>> To: [hidden email]
>>> 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) <[hidden email]>:
>>> >>
>>> >>   [
>>> 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.
>>> >>
>>> >>
>>
>>
>>
>>
>

[Bruno Busco]

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 <[hidden email]>:

> 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" <[hidden email]>
>>
>> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]> wrote:
>>>
>>>> From: David E Jones <[hidden email]>
>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
>>>> To: [hidden email]
>>>> 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) <[hidden email]>:
>>>> >>
>>>> >>   [
>>>>
>>>> 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.
>>>> >>
>>>> >>
>>>
>>>
>>>
>>>
>>
>
>

[David E Jones-3]

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 <[hidden email]>:
>> 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" <[hidden email]>
>>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>  
>>>> wrote:
>>>>
>>>>> From: David E Jones <[hidden email]>
>>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for  
>>>>> Ecommerce
>>>>> To: [hidden email]
>>>>> 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) <[hidden email]>:
>>>>>>>
>>>>>>>  [
>>>>>
>>>>> 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.
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>

[Bruno Busco]

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 <[hidden email]>:

>
> 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 <[hidden email]>:
>>>
>>> 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" <[hidden email]>
>>>>
>>>> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> From: David E Jones <[hidden email]>
>>>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for
>>>>>> Ecommerce
>>>>>> To: [hidden email]
>>>>>> 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) <[hidden email]>:
>>>>>>>>
>>>>>>>>  [
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

[David E Jones-3]

There has already been some discussion of the visual theme "type" (ie  
the one where Adrian was taking the position of a single set of styles  
and I was taking the position of the need for multiple sets of styles,  
including opening to custom sets). I don't actually like the term  
"type" for this as it doesn't really mean anything in this context  
(IMO), ie it's too generic.

If no one has a better suggestion I like the name "VisualStyleSet"  
better, with a visualStyleSetId added to VisualTheme and to WebSite as  
well.

-David


On Jan 5, 2009, at 11:31 AM, Bruno Busco wrote:

> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>>>
>>>> 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" <[hidden email]>
>>>>>
>>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> From: David E Jones <[hidden email]>
>>>>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for
>>>>>>> Ecommerce
>>>>>>> To: [hidden email]
>>>>>>> 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) <[hidden email]>:
>>>>>>>>>
>>>>>>>>> [
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>

[Jacques Le Roux]

+1

Also because the morpheme Type is often used in OFBiz when reffering to the Extended Entity Model (with TypeAttr, etc.)

Jacques

From: "David E Jones" <[hidden email]>

>
> There has already been some discussion of the visual theme "type" (ie  the one where Adrian was taking the position of a single
> set of styles  and I was taking the position of the need for multiple sets of styles,  including opening to custom sets). I don't
> actually like the term  "type" for this as it doesn't really mean anything in this context  (IMO), ie it's too generic.
>
> If no one has a better suggestion I like the name "VisualStyleSet"  better, with a visualStyleSetId added to VisualTheme and to
> WebSite as  well.
>
> -David
>
>
> On Jan 5, 2009, at 11:31 AM, Bruno Busco wrote:
>
>> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>>
>>>>> 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" <[hidden email]>
>>>>>>
>>>>>> 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 <[hidden email]>:
>>>>>>>
>>>>>>> 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 <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> From: David E Jones <[hidden email]>
>>>>>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for
>>>>>>>> Ecommerce
>>>>>>>> To: [hidden email]
>>>>>>>> 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) <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>> [
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>

[Bruno Busco]

David,
I am trying to implement this...
(assuming that "VisualStyleSet" is actually "VisualThemeSet")

if I well understand, with the proposed association, a VisualTheme can be
part of only one VisualThemeSet,
a WebSite can use only one VisualThemeSet and so we cannot have a theme
applied to more than one WebSite.

Couldn't we have a VisualThemeWebSiteAppl entity with two fields WebSiteId
and VisualThemeId so that we can have a many to many association?

-Bruno



2009/1/5 Jacques Le Roux <[hidden email]>

> +1
>
> Also because the morpheme Type is often used in OFBiz when reffering to the
> Extended Entity Model (with TypeAttr, etc.)
>
> Jacques
>
>
> From: "David E Jones" <[hidden email]>
>
>>
>> There has already been some discussion of the visual theme "type" (ie  the
>> one where Adrian was taking the position of a single set of styles  and I
>> was taking the position of the need for multiple sets of styles,  including
>> opening to custom sets). I don't actually like the term  "type" for this as
>> it doesn't really mean anything in this context  (IMO), ie it's too generic.
>>
>> If no one has a better suggestion I like the name "VisualStyleSet"
>>  better, with a visualStyleSetId added to VisualTheme and to WebSite as
>>  well.
>>
>> -David
>>
>>
>> On Jan 5, 2009, at 11:31 AM, Bruno Busco wrote:
>>
>>  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 <[hidden email]>:
>>>
>>>>
>>>> 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 <[hidden email]>:
>>>>>
>>>>>>
>>>>>> 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" <[hidden email]>
>>>>>>
>>>>>>>
>>>>>>> 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 <[hidden email]>:
>>>>>>>
>>>>>>>>
>>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>  From: David E Jones <[hidden email]>
>>>>>>>>> Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for
>>>>>>>>> Ecommerce
>>>>>>>>> To: [hidden email]
>>>>>>>>> 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) <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>

[David E Jones-3]

On Jan 14, 2009, at 10:47 AM, Bruno Busco wrote:

> David,
> I am trying to implement this...
> (assuming that "VisualStyleSet" is actually "VisualThemeSet")
>
> if I well understand, with the proposed association, a VisualTheme  
> can be
> part of only one VisualThemeSet,

Correct.

> a WebSite can use only one VisualThemeSet

Correct.

> and so we cannot have a theme
> applied to more than one WebSite.

Incorrect. Transitive logic does not apply to one-way relationships  
(these are one-to-many, not one-to-one).

Any number of themes can be part of a theme set. Any number of web  
sites can use a theme set.

There is no constraint between themes and web sites, just between  
themes and theme sets, and web sites and theme sets.

-David

[Bruno Busco]

Yes,
understood, thank you.
-Bruno

2009/1/14 David E Jones <[hidden email]>

>
>
>
>
> On Jan 14, 2009, at 10:47 AM, Bruno Busco wrote:
>
>  David,
>> I am trying to implement this...
>> (assuming that "VisualStyleSet" is actually "VisualThemeSet")
>>
>> if I well understand, with the proposed association, a VisualTheme can be
>> part of only one VisualThemeSet,
>>
>
> Correct.
>
>  a WebSite can use only one VisualThemeSet
>>
>
> Correct.
>
>  and so we cannot have a theme
>> applied to more than one WebSite.
>>
>
> Incorrect. Transitive logic does not apply to one-way relationships (these
> are one-to-many, not one-to-one).
>
> Any number of themes can be part of a theme set. Any number of web sites
> can use a theme set.
>
> There is no constraint between themes and web sites, just between themes
> and theme sets, and web sites and theme sets.
>
> -David
>
>

[Nicolas Malin (Jira)]

     [ https://issues.apache.org/jira/browse/OFBIZ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Busco updated OFBIZ-2106:
-------------------------------

    Fix Version/s: OFBIZ 9.3

> 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
>             Fix For: OFBIZ 9.3
>
>         Attachments: bin.zip, bin.zip, BrowseCategoryCSS.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, screenshot.JPG, screenshot_1.jpg, vt_multiflex.zip, 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.

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666846#action_12666846 ]

Jacques Le Roux commented on OFBIZ-2106:
----------------------------------------

Bruno,

What is the status of this issue please ?

> 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
>             Fix For: Release Branch 9.3
>
>         Attachments: bin.zip, bin.zip, BrowseCategoryCSS.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, EcommerceVisualTheme.patch, screenshot.JPG, screenshot_1.jpg, vt_multiflex.zip, 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.