[albatross-users] Re: Python embedded like PHP

Duncan Booth duncan at NOSPAMrcp.co.uk
Mon Mar 25 09:38:51 EST 2002


Dave Cole <djc at object-craft.com.au> wrote in 
news:m3663k69rr.fsf at ferret.object-craft.com.au:

> Duncan> I agree with you here up to a point. I would break down the
> Duncan> roles into html developer who needs to know some ZPT,
> Duncan> presentation developer who just needs to know what not to
> Duncan> touch, and content developer who just needs to know which
> Duncan> parts of the page require content.
> 
> Are you suggesting that there are three different people would work on
> the same template file?

> 
> IMO there would be some sort of graphic design done which may not
> necessarily produce useful HTML - that design would be taken by the
> content developer who would then build the template.

You have someone who does the graphical design, not necessarily in HTML. 
You have someone who converts that into a template (hopefully only one) for 
the entire site. Then there is someone who does the logic for querying 
databases etc. Then there is someone who updates the actual information 
that goes on the pages. Some of these jobs will be done by the same person, 
but say I want to add a new press release onto my site, then I don't want 
whoever does that to need to know HTML.

I know of one company (Jamkit) near me that uses Zope+CMF to produce 
websites for businesses and charities. They produce the page layout from 
the information given them by the graphical designers, and I guess the 
logic is much the same for most of the sites. I believe they also set up 
the initial content, but after that the customers can edit their own pages, 
and even add new pages or move them around within the site structure.

The critically important step in this is separating the content from the 
presentation.

> Duncan> In particular the CMF skins help a lot.
> 
> I haven't looked at CMF skins.

Basically you have a set of folders containing templates. Each template 
builds on the other templates, but the folders are searched in order for 
each template. So for example a form might be defined in news_edit_form in 
the folder zpt_generic, but that calls main_template. main_template is also 
defined in zpt_generic, but if I add a mysite folder before zpt_generic in 
the skin then main_template from mysite would be used instead. So simply 
adding a new main_template instantly changes the appearance of every other 
template in the system.

The presence of the skin folders is invisible to the templates, which are 
written as though all of the templates were in the current folder.

You can define several skins, so for example you might have another skin 
which has a 'printable' folder early in its search containing a simplified 
main_template for formatting printable pages.

For one site I have been playing with recently I have a folder 'ieeditor' 
which defines a wysiwyg editor for IE and changes a couple of the other 
templates to use it. The end user can choose between the plain html forms 
or the fancy (but slower) HTML editor by changing skins. (The end user 
never sees the skin folders, only a choice of skins).

Python scripts also live in skin folders, so again you can customise 
behaviour by changing the scripts in an earlier folder without having to 
change the original.
 
-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?



More information about the Python-list mailing list