+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" <david.jo...@hotwaxmedia.com>

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 <david.jo...@hotwaxmedia.com>:

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

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

-David


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

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

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

-Bruno

2009/1/1 Jacques Le Roux <jacques.le.r...@les7arts.com>:

Sounds like a reasonnable solution. I can't see the point  discussing on
this
so long (maybe I miss it ;o).
My opinion is that this should be open : they should be  "shareable" but
do
not have to be (if it's understandable in real English
;o)

Jacques

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

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

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

-Bruno

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

Bruno and David,

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

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

-Adrian


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

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

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

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

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

-David


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

Adrian,
I cannot see the problem.

Right now we have and maintain two themes, one for

ecommerce and one

for backoffice. Each theme is composed by an header, a

footer, several

stylesheets and other related files.

These files are distributed into ofbiz folders and

now, with the

introduction of VisualThemes, each set of file has

been grouped and

labeled with a VisualTheme.

I think that we will never add more themes into the

SVN (my

vt_multiflex.zip file is absolutely not intended to be

commited).

So we should always take care, into the SVN, of only

two themes as is

has been unitl now (no one more file).

In the theme gallery in Confluence there will be

hopefully more themes

available to be downloaded and installed locally. The

Theme manager

into OFBiz will let the user to have many of them to

choose from.

In this case the new visualThemeTypeId field could be

handy in a way

that only applicable themes out of what has been

installed are offered

to the user to choose from.

If OFBIZ-1119 will go further and we will have both

ecommerce and

backoffice to share the same stylesheets AND header

AND footer (which

I really do not think be possible) we could then do

not use the

visualTheme classification and use just one class.

-Bruno


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

[


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

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

Bruno,

I'm trying to be realistic. Look at OFBIZ-1119

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


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

            Key: OFBIZ-2106
            URL:

https://issues.apache.org/jira/browse/OFBIZ-2106

        Project: OFBiz
     Issue Type: New Feature
     Components: ecommerce
Affects Versions: SVN trunk
       Reporter: Bruno Busco
    Attachments: bin.zip,

BrowseCategoryCSS.patch, EcommerceVisualTheme.patch,
EcommerceVisualTheme.patch, screenshot.JPG, vt_multiflex.zip


Hi,
in the attached patch a simple implementation

of selectable visual themes for the ecommerce application.

I have added the "visualThemeId" to

the ProductStore entity. The user can select one of the
available themes in the EditProductStore screen.

I have defined the actual ecommerce theme as

the default theme that is "EC_DEFAULT".

I have followed for the ecommerce

main-decorator screen a pattern similar to what done for the
back-end.

One thing that we could think to do (but I

would like to hear someone about) is to add a
"typeId" field or similar to the VisualTheme
entity that could be used to distinguish between the themes
for the back-end and for the ecommerce.

Right now it is possible to select all of the

available themes for bost application and this results in a
mess if, for example, a theme for ecommerce is selected for
the back-end and viceversa.

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

the issue online.













Reply via email to