The WebSite entity basically corresponds to a webapp (usually referred to in the webapp using a webSiteId in the web.xml file).

About the association, and this may be what you have in mind, the WebSite should point to a theme "type" rather than individual themes. The "type" is what all of the styles in the theme are associated with. When new themes are created as long as they are made for a certain theme type then webapps with that theme type can use them.

-David


On Jan 5, 2009, at 4:47 AM, Bruno Busco wrote:

Has somebody an idea on how to implement a one-to-many relation
between VisualThemes and WebApps ?
There should be a way to tell that a VisualTheme1 can be applyed to
application1, application2 while VisualTheme2 can be applied to
application2 and application3.

AFAIK there is no an entity that models WebApps so I cannot see what
is the right way to do this.
Any idea?

-Bruno

2009/1/1 Jacques Le Roux <jacques.le.r...@les7arts.com>:
Sounds like a reasonnable solution. I can't see the point discussing on this
so long (maybe I miss it ;o).
My opinion is that this should be open : they should be "shareable" but do
not have to be (if it's understandable in real English
;o)

Jacques

From: "Bruno Busco" <bruno.bu...@gmail.com>

Adrian,
a solution to your point could be to support one-to-many relation
between VisualThemes and Applications.
So, if I design a theme that is not so specialized for ecommerce and
can work on backoffice also, I could relate it to both ecommerce AND
backoffice.
Or ecommerce1 (and not ecommerce2) and backoffice or something like this.

In the VisulaTheme selection lookups a filter for applicable VT will be
done.

-Bruno

2008/12/31 Adrian Crum <adrian.c...@yahoo.com>:

Bruno and David,

Your replies repeat the discussions we had during the development of the
Visual Themes implementation. I don't believe there is
any disagreement on their benefits, or how they are to be used, or the
future of theme galleries.

The point I was trying to make is this: If I'm a back office worker, and
I really like the theme used for the company's eCommerce
site, I should be able to select that theme for my back office
applications. Bruno's proposal would make that impossible because
eCommerce themes will work ONLY on eCommerce. I don't think we should
force that distinction. Plus, it places an additional
burden on theme developers who would have to create two versions of each
theme - one for back office applications and one for
eCommerce.

-Adrian


--- On Tue, 12/30/08, David E Jones <david.jo...@hotwaxmedia.com> wrote:

From: David E Jones <david.jo...@hotwaxmedia.com>
Subject: Re: [jira] Commented: (OFBIZ-2106) Visual Themes for Ecommerce
To: dev@ofbiz.apache.org
Date: Tuesday, December 30, 2008, 2:01 PM
Personally I like having the internal and public facing
sites different, and my guess is that most organizations
with a public facing site (ecommerce or other) will have it
quite different from the internal site(s).

To take this further, I think we should even support
multiple theme sets to the point where people can create
their own theme sets to use with custom applications whether
they be public facing or internal. For example some crazy
company might want a custom SFA app with its own theme
because their sales people have a very different set of
tastes from other departments in the company, and even
moreso because they want to design the application totally
differently so the same set of styles won't work.

That last point is really the most important: we really
should support the ability to have a themed application with
a custom set of styles and not force people to use the
styles OOTB. Whenever you dramatically change the design of
an app you tend to need different styles than for a very
different design and in those cases we either don't
support themes or we support multiple theme sets (I
don't like "theme type" BTW since it means
nothing, but not sure "theme set" is a lot better)
so people can introduce their own and have them live with
the OOTB OFBiz theme sets.

For OFBiz we'd probably maintain what we are
maintaining now: one for internal (back-end) apps, and one
for public facing apps (mostly ecommerce). The excuse that
these are being well maintained (or maintained to your
liking) right now doesn't influence this argument either
way, IMO, and is largely irrelevant.

-David


On Dec 30, 2008, at 2:04 PM, Bruno Busco wrote:

Adrian,
I cannot see the problem.

Right now we have and maintain two themes, one for
ecommerce and one
for backoffice. Each theme is composed by an header, a
footer, several
stylesheets and other related files.

These files are distributed into ofbiz folders and
now, with the
introduction of VisualThemes, each set of file has
been grouped and
labeled with a VisualTheme.

I think that we will never add more themes into the
SVN (my
vt_multiflex.zip file is absolutely not intended to be
commited).
So we should always take care, into the SVN, of only
two themes as is
has been unitl now (no one more file).

In the theme gallery in Confluence there will be
hopefully more themes
available to be downloaded and installed locally. The
Theme manager
into OFBiz will let the user to have many of them to
choose from.

In this case the new visualThemeTypeId field could be
handy in a way
that only applicable themes out of what has been
installed are offered
to the user to choose from.

If OFBIZ-1119 will go further and we will have both
ecommerce and
backoffice to share the same stylesheets AND header
AND footer (which
I really do not think be possible) we could then do
not use the
visualTheme classification and use just one class.

-Bruno


2008/12/30 Adrian Crum (JIRA) <j...@apache.org>:

 [

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

Adrian Crum commented on OFBIZ-2106:
------------------------------------

Bruno,

I'm trying to be realistic. Look at OFBIZ-1119
- it is 18 months old and no progress has been made on it.
That issue represents only one stylesheet. What you're
suggesting is that we have multiple versions of stylesheets
and other files for each theme - multiplied by the number of
themes in the project (if we agree to have more than one)
which yields potentially dozens of theme files that need to
be maintained. Yet currently we can't keep only one
updated.


Visual Themes for Ecommerce
---------------------------

              Key: OFBIZ-2106
              URL:
https://issues.apache.org/jira/browse/OFBIZ-2106
          Project: OFBiz
       Issue Type: New Feature
       Components: ecommerce
 Affects Versions: SVN trunk
         Reporter: Bruno Busco
      Attachments: bin.zip,
BrowseCategoryCSS.patch, EcommerceVisualTheme.patch,
EcommerceVisualTheme.patch, screenshot.JPG, vt_multiflex.zip


Hi,
in the attached patch a simple implementation
of selectable visual themes for the ecommerce application.
I have added the "visualThemeId" to
the ProductStore entity. The user can select one of the
available themes in the EditProductStore screen.
I have defined the actual ecommerce theme as
the default theme that is "EC_DEFAULT".
I have followed for the ecommerce
main-decorator screen a pattern similar to what done for the
back-end.
One thing that we could think to do (but I
would like to hear someone about) is to add a
"typeId" field or similar to the VisualTheme
entity that could be used to distinguish between the themes
for the back-end and for the ecommerce.
Right now it is possible to select all of the
available themes for bost application and this results in a
mess if, for example, a theme for ecommerce is selected for
the back-end and viceversa.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to
the issue online.










Reply via email to