[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