Congratulations on G2 beta3 - pretty sleek. *Very* smooth installation!
Great functionalities.
IMHO, customization is the weakest point in G2. Despite past experiences with templating systems (XSLT, smarty, etc.) I've found it difficult to achieve the results I wanted. Main problem was figuring out what file was responsible for what aspect of the presentation - tree structure is a little odd.
I've tried to capture some of my problems below:
Documentation, naming concerns:
- clear explanation of roles of themes vs layouts vs templates.
Roles of hemes and layouts seem fairly trivial now.
But still not too sure about templates. Would be nice to address this in doc.
- I would avoid re-using same names across themes and layouts (ex: matrix).
This adds to confusion. Using color-related names for themes (ex: CoolBlue) and function-related (ex: Public-Gallery-No-Login) names for layouts might help.
Organizational problems:
- layout.inc:
I went into customization with expectation of having to copy an existing directory and modifying a bunch of template files. Unfortunately the layout.inc got in the way.
I suspect that this is the main obstacle to people packaging their own layouts and
sharing them with the user community. Looks like most people take the quick and
dirty route of modifying "matrix" rather than building a new layout.
- layouts vs templates vs themes
Let's look at the tree structure;
layouts\
+-- classic\
| +-- locale\
| +-- po\
| +-- templates\
+-- matrix\
| +-- locale\
| +-- po\
| +-- templates\
templates\
themes\
+-- matrix\
+-- mblue\
+-- veloria\
- UI only shows control for Layouts and Themes.
So what are templates? How is a template different from a layout?
Do templates need to have an existence outside of a layout?
- there is a "templates" dir at top level.
A "templates" dir under each layout
Potentially a "local" dir within each of these.
What is the relationship bw all these?
If it was just a matter of re-organizing files (I doubt it's so easy!) here's what I would suggest:
presentation\
+-- layouts\
| +-- ClassicGalleryAllFeatures\
| +-- PublicGalleryNoLogin\
| +-- _MASTER\
+-- themes\
+-- CoolBlue\
+-- RedHot\
1/ consolidation of all customizable files under one single dir ("presentation")
2/ drop top level "templates"
use "layouts/_MASTER" instead
3/ Set a clear order of precedence between directories:
templates are read
- in enabled layout dir first (if present)
- in _MASTER layout dir otherwise
("local" directories wouldn't really be necessary if duplicating a layout
was just a matter of copying full directory).
4/ themes are absolutely independent from layouts.
I know that all this is easier said than done.
Take this as some (hopefully) constructive feedback as a payback for the great software.
Keep up the good work!
d3m
Posted: Tue, 2005-05-24 23:57
Posts: 7994
This is great feedback. I read it when you posted it, but haven't had a chance to reply until just now.
There are a variety of reasons why we have our current structure. The main reasons are that we try to preserve modularity and independence between our various themes, layouts and modules without having to duplicate too much code between them. So each module has to have its own set of templates in order to render its HTML. And layouts are a collection of templates that it can choose to show at the appropriate time.
The top level templates directory is for theming the entire app, independent of what modules, layouts and themes you use. Since we have lots of similarities between layouts, we've chosen to move some of the common code up to the master template, like sidebar.tpl.
I'm working on a change that will let us move the common code back down into layouts and simplify what's at the templates dir. I agree that it would be nice to have a layouts/_MASTER (or equivalent) directory where we can put anything common across layouts -- but the more that I think about it the more I'd rather that we just duplicate it inside each layout so that the layouts can be wholly independent. And do the same for themes -- once we get close enough to release there's no reason to leave that stuff up at the top level -- we can put a copy inside each theme and let them each go their own way.
Stay tuned -- we're working on it!
Posts: 808
Bharat,
Is that the only thing with the layouts and templates that is changing is the location of the files in /gallery2/templates. I'm going to be updating my layout and theme but I want to make sure the whole system isn't going to be changed the day after I do it.
Posts: 4
This is what I figured - but the fact is that most users end up modifying sidebar.tpl and it's ugly to do this outside of a customized layout. Ideally users shouldn't touch any of the shipping layouts - simply edit a local copy.
That would work great. And would make it easy to package and exchange layouts. I could see people providing layouts for many different types of galleries/usages: marketplaces, individual photo albums, community albums, etc.
Thinking about my earlier post, and my struggle with layout vs templates vs themes. Would it be over-simplifying to say that:
* layout = functional
What features do you want to expose and where?
Do you want to provide your users with an "add to cart" link? etc.
* theme = cosmetic
This is where you define your color schemes, fonts, etc.
* templates = (hmmm, still not sure how to summarize their role)
Thanks for the reply - greatly appreciate you taking into consideration some of the previous comments!
Posts: 808
You've got it.
As far as templates go they define the elements for each module that goes in the layout. So if our Gallery site is made of legos the templates would be the blocks the layout is how the blocks fit together and the themes are what color they are.
Posts: 4
I think you need to put that lego analogy in the doc :lol:
Thanks.