[Zope-PTK] CMF some basic Q

Tres Seaver tseaver@digicool.com
Fri, 16 Mar 2001 23:27:26 -0500


Bill Anderson wrote:
> 
> On 15 Mar 2001 22:22:54 -0500, Jeffrey P Shell wrote:
> > on 3/15/01 8:41 PM, Bill Anderson at bill@libc.org wrote:
> >
> > > On 15 Mar 2001 13:34:04 -0500, Jeffrey P Shell wrote:
> > >> On 3/15/01 2:54 AM, "Bill Anderson" <bill@libc.org> wrote:
> > >>
> > >>> On a related note, is there any way short of a restart of Zoe to refresh
> > >>> the filesystem non-customized stylesheets?
> > >>>
> > >>> The ones provided don't expose enough (select a black background and
> > >>> tell me how well your h[1-n] tags come out, for example ;) , and while
> > >>> building a new one, it sucks to have to restart my zope server to see
> > >>> the effect of moving a margin or two...
> > >>>
> > >>> Bill
> > >>
> > >> Why are you modifying the ones on the file system instead of through the web
> > >> in custom folders?  Whenever I'm doing any experimenting in skins, even in
> > >> something planned to go into the core distribution, I always do it in a
> > >> custom folder so I can see the effects quickly.  If it's something meant to
> > >> go into a distribution, I'll copy my changes to the file system after I've
> > >> tested them this way.
> > >
> > >
> > > Cuz you can't _just_ modify the few options provided, that's why. Much
> > > stuff is still hard-coded, and not accessible in the TTW customize
> > > option.  For example, the color of your the header tags is black.
> > > Period. Looking at the stylesheet from the FS, you can see it is
> > > hard-coded, by not providing an variable to be substituted. No variable,
> > > no TTW customization.
> > >
> > > A few other things are needed occasionally, such as changing padding
> > > sizes, or margins. None of these are available TTW. Sure, I can change
> > > those and make variable for them, but that is -still- changing the file,
> > > and not using a customized instance TTW. It would still require a
> > > restart.
> >
> > Which file are you referring to?  In generic/default_style_sheet.dtml, there
> > is:
> >
> > h1 {
> > font-size: 120%;
> > font-weight: bold;
> > color: &dtml-base_font_color;;
> > }
> 
> I misspoke, that is _still_ the same color as  the rest of the page's
> font. I cannot change _just_ the heading's color, I have to change my
> font color for everything not explicity redefined later. To change it
> -still- requires changing the FS, no? If i want to add a
> &dtml-header-color;, I need to change the FS version (which is cool),
> and restart zope (which is not).

Nope;  customize generic/default_style_sheet (*not* on the file system!
select it in the skin folder and hit the "Customize" button, then edit
a real, live, TTW DTML method!).  **All** the filesystem-based skin objects
are belong to us!  (Well, the ones we ship with the CMF, anyway). You are
*supposed* to either:

 * customize them into TTW versions, which "override" the FS versions
   due to the name lookup precedence given to the 'custom' folder;

 * or else create and register new skins directories (e.g., under a
   product of yours), and arrange for the same-named skins objects to
   be found in your FS-based folders, rather than ours.

> 
> >
> > If you want to change that color with skins, you can do it a couple of ways:
> >
> >  (1) Go to portal_skins/generic/default_style_sheet (in the Zope Management
> >      Interface) and hit 'customize' to copy it into a custom folder.  Go
> >      down to the h1 declaration and change color by hand - not referring to
> >      any DTML variable.

This is the one you missed.

> >
> >  (2) Go to portal_skins/generic/stylesheet_properties in the ZMI and do
> >      a 'customize' on it.  Find the property for 'base_font_color' and
> >      change the property to reflect your desired color.
> 
> And watch the rest of my page (with few exceptions) follow suit). :^)=

Changing the 'base_font_color' is pretty drastic, sure;  if you *don't*
want the H1 rule to use that color name, then customize the stylesheet
to refer to another one!

> >
> >  (c) Do both!  The stylesheet_properties are just an attempt to give
> >      some convenience over having to write\edit stylesheet code just
> >      to change a color, but you should be able to extend the
> >      customized style sheet to either accept more properties or have your
> >      own hardcoded values.
> > With skins, it allows us to distribute the default
> > look and feel in a way that should discourage tinkering with the original
> > sources (the file system DTML), but encourage easy customization by letting
> > the source from the file system be easily copied to a folder in the skins
> > tool which would get name-lookup-precedence over the file system folders.
> > *ALL* of the DTML that is in the file system should customizable through the
> > web.  If this isn't working, it is either a bug in our code, or my fault for
> > not completing my documentation task. :)
> >
> > I'm going to be out for a couple of days (one final ski weekend, hazzah!),
> > but I hope this message helps or someone else on the team can help.
> 
> Right, I understand about the custom  folder and customizing, but that
> _only_ allows you to change the provided property variables.

Nope, you can override any one of the DTML methods, or the property objects,
by creating customized TTW versions which shadow the FS ones.

> Let us
> continue with the example. So headers have the same color as the rest of
> the base color. Say I want my text to be black, and headers to be dark
> blue. I go to the stylesheet, click customize, and change that how? I
> can't, through the web. There is no (on the provided stylesheet objects)
> way to do that through the web.

Please do what you just described, and note what shows up in the browser
when you click the button:  you *were* staring at a read-only rendition
of 'portal_skins/generic/default_style_sheet';  you are *now* staring at
a fully editable ("it walks! it talks!") DTMLMethod copy of it, in
'portal_skins/custom/default_style_sheet'.

> To do that _requires_ a change in
> something on the FS, does it not? Now, if you are saying I could drop a
> ZStyleSheet instance n 'custom' instead, and that should work, woohoo,
> that would be nice.

ZStyleSheets might work in there -- I don't know their semantics.

> Another example is the size of the text in the Actionsbox. To change
> that requires a change in the FS-level. I see that it gives it a
> proportional size, but it seems no matter how LARGE I make the base font
> size, it doesn't change. Mebbe that's a bug, i dunno, but it's annoying
> enough I went to the FS to change it.

Nope, customize it, then edit the TTW version.

> To provide yet another argument for the FSView stuff not mandating a
> restart ...
> Let's say I want ot add a CSS class, or change an existing one. Again,
> to the FS I go.

*I* don't go the the FS for this, nor does anyone else.

> Now, I actually like this myself, as I can use cvs to have control over
> the CSS, use my favourite CSS editor (mmm gvim), and distribute updates
> to a site's default styles using python on the skins tree, along with
> diffs. The problem is I need to restart the site to see the changes, or
> run the site in debug.

This is like reloading ExternalMethods whenever they change;  the cost
of doing that is high ('stat()' is expensive!), and unwarranted on a
"production" site;  while developing the site, run it with '-D' and
reap the benefits.

> Debug is fine _sometimes_, but it is not a good
> default running mode on a production site. Especially when you are
> running ZEO, and many, many zopesites that need to start up when you
> boot the system.  I don't want tracebacks on pages, just the error
> message. Zope' tracebacks throws tables all out of whack, severely
> disrupting the page.

If you are running ZEO, then run only the "private" instance you are
playing with using '-D', and leave the "public" site alone.

> All I am arguing for, is that Filesystem views should auto-update when
> changed, without running debug mode on the server(s).

Won't happen.

> O, one more example for clarity, and perhaps inspiration for some. Here
> is something I am doing. Live examples rule!
> 
> I have a server with multiple portals in it. Each CMF Portal can
> customize the colors/fonts of their default stylesheet. Yet, if I go in
> and change the default_stylesheet.dtml, that change is still propogated
> (all you do when customizing the stylesheet  TTW is change the
> colors/fonts, nothing else).

No, *that* object is the "stylesheet properties" object, which customizes
to a Folder;  the 'default_stylesheet' object customizes to a DTMLMethod,
which you are free to edit TTW.

 In order fo the changes I make to the
> default, the site needs restarted. Not good, IMO. Say I had an h2 tag. I
> need to restart the entire server for an h2 tag addition. Now, as I
> understand it, there is no way for me to add that TTW anyway, and would
> have to do that for several CMF Portals if I could.
> 
> All clicking 'customize' does, AFAICT, is allow you to change the
> provided property values, nohting more.
> 
> IMO, debug is for debugging, not for standard, simple, non-code changes.

Sorry to keep repeating, but you are hammering hard on your mis-
apprehension that the FS DTML can't be customized TTW.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org