Re: Tasks

[Martin Aspeli <optilude gmx net>]

Simone Deponti wrote:
> On 12/9/06, *Ricky Zhou* < ricky zhou gmail com 
> <mailto:ricky zhou gmail com>> wrote:
>
>     Also, I'm a bit confused
>     about base.css.dtml in gnome_custom_styles, as I mentioned in
>     HISTORY.txt.  There's a header that recommends against editing it, but
>     some of the rules in it are so general, that they break the current CSS
>     , particularly because I have * { margin: 0; padding: 0; }.
>
>
> There is no holy and uneditable soil, so if you need to tweak base.css, 
> tweak it. My only recommendation is to keep the modularized approach 
> that plone takes, even if sometimes it's simpler to just throw 
> everything in the main_template, you might regret it badly after.

Do *not* edit files inside Products/CMFPlone. It means you are 
effectively shutting yourself off from future upgrades (or at least, 
giving yourself an immense amount of pain doing so).

Your code lives in it own product (Products/GnomeTheme or something) - 
and here you have free reins. If base.css.dtml is in there, then that's 
where you're meant to edit it.

To understand how it works, look at the ZMI (start Plone, go to 
http://mydomain/manage) and find your Plone instance and then the 
portal_skins object. If you look at its Properties tab, you'll see a set 
of properties corresponding to skin names (your currently chosen 
skin/theme should be among them; the default is called Plone Default). 
For each skin, there is a list (just a textbox, one item per line) of 
folder names. The top one should almost always be called 'custom', and 
underneath it, you should have your own skin layers 
('gnome_custom_styles' etc), and finally Plone's own layers.

Now, when Plone looks for e.g. main_template (someone wrote e.g. 
metal:use-macro="here/main_template/macros/main") then it will start at 
the top of that list of folders and move down until it finds an object 
called main_template.

Notice how the folder names correspond to subfolders of portal_skins, 
which in turn are normally just views of a directory on the filesystem. 
Look at Products/CMFPlone/skins/ - and notice how the folders and 
objects there correspond to those in portal_skins.

This is how you customise and override things! If Plone has a template 
(say, document_view) that you want to customise, don't edit 
Products/CMFPlone/skins/plone_content/document_edit.pt; Instead, copy 
this file to Products/GnomeTheme/skins/gnome_templates (I'm guessing the 
path here, but it should be obvious) and then edit it there. If you need 
Plone's default behaviour back, remove/rename the file and all is good.

This approach basically means that nearly all templates, CSS files, 
images, JavaScripts and other resources in Plone can be overridden (a 
bit like inheritance works in OOP). There's a bit more to the story, but 
 if you grasp the skin layer stuff, you'll go far.

> If we really want to go hardcore, we can make some sort of AJAX admin 
> interface that lets the admin move around the boxes of the mainpage, 
> rearranging them to fits his needs, and maybe even specify a stylesheet. 
> It's totally feasible, but for now let's keep it simple :D.

You probably want to look at CompositePack for that use case, but I'd 
wait until you're sure you need it. Start simple and build up!

Martin