You're right Adrian, I think I did miss what you were getting at.
Are you imagining a new entity called "Theme", or perhaps something
more specific like "VisualTheme" or some name like that? This entity
would have one or more stylesheet locations associated with it, and
perhaps other information. The theme IDs would be referred to in the
ProdCatalog entity, and in one or more user preference records as well.
Something along those lines?
-David
On Jul 11, 2008, at 11:20 AM, Adrian Crum wrote:
I think you missed something. Or maybe I wasn't clear enough.
eCommerce would work exactly like you described, the only difference
being instead of configuring a catalog or store to use a stylesheet,
you configure it to use a theme. User selected themes aren't used in
eCommerce.
On the back office side, the user can select a theme and it is
persisted in user settings.
Both eCommerce and the back office apps would share common theme
selection code. What they do with the themes is what's different.
Thinking about it more, it would be better to specify themes in
eCommerce instead of specifying stylesheets - since a theme might
require more than a stylesheet change.
-Adrian
David E Jones wrote:
It depends on the requirements and what we want to design for each
thing.
For ecommerce the common requirement is to let the people running
the store decide what it will look like, with possibly different
L&F for different sets of products (ie different catalogs).
Would (does?) anyone really want user selectable styling for
ecommerce?
On the backend it's different altogether. Those are the tools
employees, contractors, etc use on a regular basis and it might be
nice to allow them to change certain colors, fonts, etc... just
like you would do with your desktop and various applications on it.
Different requirements, different implementations and tools.
-David
On Jul 11, 2008, at 10:58 AM, Adrian Crum wrote:
Agreed. But do we want duplicate implementations?
Maybe we can come up with a framework implementation that
eCommerce builds on. Let's say the framework has a system of
selecting themes. Then in eCommerce, instead of specifying a
stylesheet in the ProdCatalog, you could specify a theme. The
framework theme-handling code would then use the appropriate style
sheet.
What do you think?
-Adrian
David E Jones wrote:
The ProdCatalog thingy is really only for the ecommerce site. For
manager application styling and preferences it would be serious
hack...
-David
On Jul 11, 2008, at 9:58 AM, Adrian Crum wrote:
Well, the system we implemented here is set up with an XML file
that has a selection of themes and where their files can be
found. The XML file is also used to present the user with a menu
of styles to choose from. Their selection is kept in user
preferences.
I like your idea better though. Maybe the user preference could
contain the primary key of a ProdCatalog record. The new MyPage
component could have an area that displays all ProdCatalog
records for the user to choose from.
-Adrian
David E Jones wrote:
Good question/point.... We're mainly just looking at skinning
the ecommerce application, ie the OOTB templates.
Something similar for the internal apps would be interesting...
are you thinking of something like a personal preference? For
that we could do something like specify or upload your own
stylesheet (that would override any styles desired in the
default one), or perhaps even get fancier and allow people to
specify certain things that would go into a dynamically
generated stylesheet of some sort to override the main
stylesheet...
-David
On Jul 11, 2008, at 9:47 AM, Adrian Crum wrote:
David,
That's great news! Will there also be a way to select the
theme for the back office applications?
-Adrian
David E Jones wrote:
This is really much easier than it seems, and actually a
couple of weeks ago I got a couple of people at Hotwax
started working on some themes and some HTML/CSS enhancements
to make the skinning more flexible.
The plan we're thinking of is to use the existing the
ProdCatalog stylesheet field to change the stylesheet, and
possible extend that to support multiple stylesheets. With
this approach all you have to do to add a theme is add a hot-
deploy component that contains your CSS and image files in a
webapp, and some data file with the ProdCatalog records that
would probably be the same as the main demo ProdCatalog and
be attached to the same store and categories, but with a
different stylesheet. In this way you could also have
different sets of products though, which would allow you to
easily do some cool demo catalogs/sites for different sets
and types of products.
-David
On Jul 11, 2008, at 9:20 AM, Adrian Crum wrote:
At the last developers conference, I had suggested to David
Jones that we have a "CSS Style Sheet Shootout" - where
different OFBiz developers could submit their themes to Jira
and we could vote on them. The one with the most votes would
get committed to the project. At the time there was too much
embedded styling in the project - so it wouldn't work and,
consequently, nothing was done. Things are different now and
changing the style of the whole project is easier. So, I'm
in agreement with that aspect of this thread.
Where I have a problem with this thread has already been
mentioned - having multiple themes in the trunk will become
a support nightmare. My preference would be to have the
*capability* to switch themes built into the framework, but
only have one theme in the trunk. Anyone wanting to supply
additional themes could do so on their own. It could even
develop into a cottage industry.
-Adrian
Ashish Vijaywargiya wrote:
+1
On Fri, Jul 11, 2008 at 4:21 AM, Jacques Le Roux <
[EMAIL PROTECTED]> wrote:
Bruno, Ashish,
Having them in separated directories, why not introduce a
property in
general.properties file (or somewhere else) to select the
theme at will,
default being the one we use currently ?
Jacques
From: "Bruno Busco" <[EMAIL PROTECTED]>
Ashish,
thank you for your comments.
Well, of course if the themes are taken from the gallery
there should be a
information on the theme that tells you with which
release of Ofbiz it can
be used (now we could go with the SVN rev until we have
the next release).
For the file overwritting we could think to have the
theme in a special
folder (this is how many CMS do, for example Drupal).
So for example we could have:
/framework/images/webapp/images/themes/theme1/maincss.css
/framework/images/webapp/images/themes/theme2/maincss.css
the themesX folder should never be committed. And then
have a UI that let
us
specify which theme between the availables must be used
(this, as
suggested,
could be in the user preferences).
-Bruno
2008/7/11 Ashish Vijaywargiya <[EMAIL PROTECTED]
>:
Sorry for writing again on this.
But I see a loopwhole in this.
Suppose you are creating new maincss.css file.
Someone has downloaded your file and kept your file in
images directory
and
removes the old one.
Now if user take update of Ofbiz on regular basis or we
can say after
certain duration of time.
And if someone introduce a new class in Stylesheet file
and uses it
extensively in some section so in this
case your file(maincss.css created by you) might not be
having those new
classes entries.
So the layout will not be consistent.
What do you think about it Bruno ?
--
Ashish
On Fri, Jul 11, 2008 at 1:49 AM, Ashish Vijaywargiya <
[EMAIL PROTECTED]> wrote:
Bruno,
I like your idea.
--
Ashish
On Fri, Jul 11, 2008 at 1:37 AM, Bruno Busco <[EMAIL PROTECTED]
>
wrote:
Hi devs,
I am writing a new maincss.css file and I will submit
when finished.
I think that several other users/developers will write
(or have
already)
their .css files.
Since the graphical theme is something very subjective
it will be
difficult
to agree with a unique theme and have it committed on
SVN.
So I propose to open a OFBiz Theme Gallery on
confluence where all
users
can
upload their own theme with a little screenshot.
All users could then browse the available theme,
download it and copy
on
their ofbiz installation.
The standard theme format to uploaded could be a
folder that contains
the
maincss.css file and relative gif files.
What do you think about?
Many thanks,
Bruno