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