> A litany of questions: How many designers are there?
1-3
> Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it?
Most anyone can understand $variable, but not <div tal:replace="structure context/variable"> </div>
I altered cheetah to use hide if and for loops in comments, similar to
< !--# for i in range(1,10) -->
$i
< !--# end for -->
> If they do change Cheetah logic, to what extent do they make change?
At this point, they don't make major changes, if any to the logic, mostly the add #block and #def directives and stuff it with new content
> Does it concern you at all that Cheetah puts an unlimited amount of power in the hands of people who might misunderstand it (I make the assumption given that you say these designers can't use Subversion)?
They don't don't have access to the unlimited power, because they don't understand it enough to access it (or should I say they don't have the time). Personally I think subversion should be used for EVERYTHING, but adoption takes time. I like Django templates better, they're more extensible and allow for dynamic #extends.
> How much traffic do the sites that you have this on get? Is performance adequate?
Moderate traffic, with spikes on Thursday (publishing day), on the heavier hit site, they have decent hardware and all I use is a ram cache. On the other site I use wget to create static pages.
> Who gets the phone call when performance becomes inadequate?
Me.
> Do you have a process for isolating performance problems?
Have I used a profiler? No. In general I run ab after each check in.
> Do they make changes directly to the live site or is there a staging process?
Content is added live. Issues have a skin selector. Future issues can be previewed with their selected skin.
> If there is a staging process, how do the changes make it to the live site?
It's time-based. One site uses a cron-job, the other site has a 1 hour ram cache and is based on start date.
> Would the designers be just as comfortable accessing files that actually live on a filesystem over, say, Samba, instead of over WebDAV. If they had an alternate way to perform an undo against files on the filesystem (as opposed to the current ZMI/CMF undo interface), would that service the goal?
This is what I plan to try next. On my the next CMS the plan is to have 5-10 skins with generic names setup on the filesystem. This is much like the system that you have outlined, however, this is not how I'd prefer it.
> "Templating" is a bit of an overloaded word (at least to me). I'd call that "programming", but then again I suspect I'm a bit of a fundamentalist when it comes to this. ;-)
Aah! I'm scripter, and they're programmers!?
> For production sites? Who's the actor here?
Perhaps y'all work for bigger companies than I, but most of us have to wear many hats. A weekly newspaper for instance, isn't going to be able to afford a full time web person.
> Under what circumstances would product-installation-via-a-shell-prompt be less than adequate?
Shell? What's a shell? I think the CLI is way too intimidating for most people. If I don't need to drop to the command line to install SPE, or OpenOffice in Ubuntu, all with myriads of dependencies, why would I to install a simple poll product to my website? Other CMS's offer this.
> Do you use ZEO?
I use ZEO with APE to keep main content areas seperated (the events database, classifieds database and articles database) and to cope with 2gb limit
> Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
Subversion, but mostly I don't need to run multiple clients
> What classes of configuration should be performed via the web?
> Are there any classes of configuration that should be performed via files on a filesystem?
> In the TTB model there's only one skin for very simple database-driven content delivery apps: the public skin. For more complicated apps that require content entry, workflow and so forth, there is the admin skin as well. In the perfect world, I'd suggest separating content entry from delivery entirely (use separate physical systems for entry and delivery). This prevents a certain class of performance issues. Anyway, if the "admin" skin and logic was optional, would that bother you?
This just depends on what's being built for whom. If it was just me, I'd go all file system. But in general I like to build sites, I don't like to maintain them.
> Have you used any Zope 3 or Five stuff yet?
Yes, interfaces and components rock. ZCML sucks.
> Yup, although I suspect a certain class of folks would be just as happy with an LDAP browser or the ability to use MS' built in ActiveDirectory tools or Netware's NDS tools, and so on. Do you think this is a losing proposition?
This sounds like more big company stuff. We're not going to install ldap for 30 people. People are still using Novell??
What I'd like to see is TTB but instead of Samba-ing to a file system, I'd rather see WebDav-ing into the ZODB. Than we get best of both worlds. I haven't checked out Skeletor but IMO this technique is very fragile. Paste uses this technique and I remember the Subway project was a complete mess when they were developing using Paste.
Personally I'm moving to Zope3. It's hard though, because ZCML is hiding how things work. IMO ZCML should be pared down to the include statement and security, all other ZCML should be completely optional, but that's another story.
HTH,
Kevin Smith
more q's...
Posted bychrismat
2005-12-24 03:36 PM
Thanks for the answers! This is very interesting. Another litany of
questions follows; I hope you'll be patient, I really want to
understand where you're coming from.
> At this point, they don't make major changes, if any to the logic,
> mostly the add #block and #def directives and stuff it with new
> content
I don't know any Cheetah, but I just went and read the docs for #def
and #block. Are they just cutting and pasting existing #def/#block
blocks (maybe from other templates) and changing the contents of
static text within those blocks?
> They don't don't have access to the unlimited power, because they
> don't understand it enough to access it (or should I say they don't
> have the time). Personally I think subversion should be used for
> EVERYTHING, but adoption takes time. I like Django templates better,
> they're more extensible and allow for dynamic #extends.
They're OK with not being able to use a WYSIWYG tool to edit the HTML,
given that Cheetah is neither well-formed XHTML or HTML? Or do they
have tools that can deal with it? Do they get mad that they can't use
tools if not?
> Have I used a profiler? No. In general I run ab after each check in.
But the designers don't check any of their code changes in, right,
because they edit code that's in the ZODB? Do you just trust that
whatever they did while changing a template is not too expensive or
didn't break anything because they're knowledgeable? Or do they just
tell you, "hey I made a change" and you go run ab against the live
site? Have you ever run into a situation that when you run ab against
the live site it emits a traceback or causes the CPU to go wild due to
a bad change made by one of the designers? Or do you just run ab
against a development system? If it's against a development system,
do you have some way of merging the changes they made to the live site
back to your development system? Whew that's a lot of questions.
> Content is added live. Issues have a skin selector. Future issues
> can be previewed with their selected skin.
You say content is added live, and that I can understand. Is *code*
(in the form of templates and/or Python code) added/changed on the
live site without being evaluated on a development system first?
> Aah! I'm scripter, and they're programmers!?
Heh. No, of course not, sorry! ;-) This is why the distinction makes
me totally uncomfortable (see
http://www.plope.com/Members/chrism/agile_foo). You're clearly not a
"just a scripter" if you're gluing together Plone and Cheetah. ;-) My
instinct is to call everybody who touches logic a programmer. Some
programmers are more experienced than others (like yourself), but
otherwise, everybody who touches logic is a programmer to me. ;-)
> Perhaps y'all work for bigger companies than I, but most of us have
> to wear many hats. A weekly newspaper for instance, isn't going to
> be able to afford a full time web person.
> Shell? What's a shell? I think the CLI is way too intimidating for
> most people. If I don't need to drop to the command line to install
> SPE, or OpenOffice in Ubuntu, all with myriads of dependencies, why
> would I to install a simple poll product to my website? Other CMS's
> offer this.
:-( I don't understand. You're clearly an experienced programmer and
likely a very good sysadmin, and to be a programmer, you (with a few
notable exceptions) need to understand CLI. You're likely the one
that installs products now, and you know it's not that hard except for
keeping versions straight. We're trying to make that easier in the
context of Zope by allowing products to be packaged as Eggs. If it's
not you, which specific person at your company are you trying to help
with a *TTW* product installer? On which systems would it be used at
your company? Would you expect people to know how to use it after it
got installed? Given that you don't seem to be using "stock Plone"
for content delivery, and given that your designers don't have that
kind of time, is this really a reasonable expectation? Are you
talking about something that would just magically start to work on
your site because you might have prepared it explicitly for this
purpose, but you just want to give people the option to turn it on or
off within your particular templates?
Note that I'm talking about "TTB programming" in the context of Zope
rather than any add-ons. Of course, Zope isn't a CMS (in reference to
your mention of "other CMS's" above), it's an application server.
Plone, OTOH, is a CMS, so I might expect it to offer this kind of
thing, but I wouldn't expect Zope to do it "out of the box". Do you
think this is a bad expectation in the context of Zope?
> What I'd like to see is TTB but instead of Samba-ing to a file
> system, I'd rather see WebDav-ing into the ZODB. Than we get best of
> both worlds. I haven't checked out Skeletor but IMO this technique
> is very fragile. Paste uses this technique and I remember the Subway
> project was a complete mess when they were developing using Paste.
You're OK with the fact that if you or your designers do use DAV to
edit code that lives in the ZODB, that it can't be versioned in the
same way that your other code is via subversion? Likewise, you're OK
with the fact that you can't repeatably deploy a particular set of
code without copying the ZODB over to a new system (or doing "export
surgery")? If you could give them largely the same experience but the
code *was* tracked by a version control system, would that be a good
thing?
1-3
> Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it?
Most anyone can understand $variable, but not <div tal:replace="structure context/variable"> </div>
I altered cheetah to use hide if and for loops in comments, similar to
< !--# for i in range(1,10) -->
$i
< !--# end for -->
> If they do change Cheetah logic, to what extent do they make change?
At this point, they don't make major changes, if any to the logic, mostly the add #block and #def directives and stuff it with new content
> Does it concern you at all that Cheetah puts an unlimited amount of power in the hands of people who might misunderstand it (I make the assumption given that you say these designers can't use Subversion)?
They don't don't have access to the unlimited power, because they don't understand it enough to access it (or should I say they don't have the time). Personally I think subversion should be used for EVERYTHING, but adoption takes time. I like Django templates better, they're more extensible and allow for dynamic #extends.
> How much traffic do the sites that you have this on get? Is performance adequate?
Moderate traffic, with spikes on Thursday (publishing day), on the heavier hit site, they have decent hardware and all I use is a ram cache. On the other site I use wget to create static pages.
> Who gets the phone call when performance becomes inadequate?
Me.
> Do you have a process for isolating performance problems?
Have I used a profiler? No. In general I run ab after each check in.
> Do they make changes directly to the live site or is there a staging process?
Content is added live. Issues have a skin selector. Future issues can be previewed with their selected skin.
> If there is a staging process, how do the changes make it to the live site?
It's time-based. One site uses a cron-job, the other site has a 1 hour ram cache and is based on start date.
> Would the designers be just as comfortable accessing files that actually live on a filesystem over, say, Samba, instead of over WebDAV. If they had an alternate way to perform an undo against files on the filesystem (as opposed to the current ZMI/CMF undo interface), would that service the goal?
This is what I plan to try next. On my the next CMS the plan is to have 5-10 skins with generic names setup on the filesystem. This is much like the system that you have outlined, however, this is not how I'd prefer it.
> "Templating" is a bit of an overloaded word (at least to me). I'd call that "programming", but then again I suspect I'm a bit of a fundamentalist when it comes to this. ;-)
Aah! I'm scripter, and they're programmers!?
> For production sites? Who's the actor here?
Perhaps y'all work for bigger companies than I, but most of us have to wear many hats. A weekly newspaper for instance, isn't going to be able to afford a full time web person.
> Under what circumstances would product-installation-via-a-shell-prompt be less than adequate?
Shell? What's a shell? I think the CLI is way too intimidating for most people. If I don't need to drop to the command line to install SPE, or OpenOffice in Ubuntu, all with myriads of dependencies, why would I to install a simple poll product to my website? Other CMS's offer this.
> Do you use ZEO?
I use ZEO with APE to keep main content areas seperated (the events database, classifieds database and articles database) and to cope with 2gb limit
> Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
Subversion, but mostly I don't need to run multiple clients
> What classes of configuration should be performed via the web?
> Are there any classes of configuration that should be performed via files on a filesystem?
> In the TTB model there's only one skin for very simple database-driven content delivery apps: the public skin. For more complicated apps that require content entry, workflow and so forth, there is the admin skin as well. In the perfect world, I'd suggest separating content entry from delivery entirely (use separate physical systems for entry and delivery). This prevents a certain class of performance issues. Anyway, if the "admin" skin and logic was optional, would that bother you?
This just depends on what's being built for whom. If it was just me, I'd go all file system. But in general I like to build sites, I don't like to maintain them.
> Have you used any Zope 3 or Five stuff yet?
Yes, interfaces and components rock. ZCML sucks.
> Yup, although I suspect a certain class of folks would be just as happy with an LDAP browser or the ability to use MS' built in ActiveDirectory tools or Netware's NDS tools, and so on. Do you think this is a losing proposition?
This sounds like more big company stuff. We're not going to install ldap for 30 people. People are still using Novell??
What I'd like to see is TTB but instead of Samba-ing to a file system, I'd rather see WebDav-ing into the ZODB. Than we get best of both worlds. I haven't checked out Skeletor but IMO this technique is very fragile. Paste uses this technique and I remember the Subway project was a complete mess when they were developing using Paste.
Personally I'm moving to Zope3. It's hard though, because ZCML is hiding how things work. IMO ZCML should be pared down to the include statement and security, all other ZCML should be completely optional, but that's another story.
HTH,
Kevin Smith
questions follows; I hope you'll be patient, I really want to
understand where you're coming from.
> At this point, they don't make major changes, if any to the logic,
> mostly the add #block and #def directives and stuff it with new
> content
I don't know any Cheetah, but I just went and read the docs for #def
and #block. Are they just cutting and pasting existing #def/#block
blocks (maybe from other templates) and changing the contents of
static text within those blocks?
> They don't don't have access to the unlimited power, because they
> don't understand it enough to access it (or should I say they don't
> have the time). Personally I think subversion should be used for
> EVERYTHING, but adoption takes time. I like Django templates better,
> they're more extensible and allow for dynamic #extends.
They're OK with not being able to use a WYSIWYG tool to edit the HTML,
given that Cheetah is neither well-formed XHTML or HTML? Or do they
have tools that can deal with it? Do they get mad that they can't use
tools if not?
> Have I used a profiler? No. In general I run ab after each check in.
But the designers don't check any of their code changes in, right,
because they edit code that's in the ZODB? Do you just trust that
whatever they did while changing a template is not too expensive or
didn't break anything because they're knowledgeable? Or do they just
tell you, "hey I made a change" and you go run ab against the live
site? Have you ever run into a situation that when you run ab against
the live site it emits a traceback or causes the CPU to go wild due to
a bad change made by one of the designers? Or do you just run ab
against a development system? If it's against a development system,
do you have some way of merging the changes they made to the live site
back to your development system? Whew that's a lot of questions.
> Content is added live. Issues have a skin selector. Future issues
> can be previewed with their selected skin.
You say content is added live, and that I can understand. Is *code*
(in the form of templates and/or Python code) added/changed on the
live site without being evaluated on a development system first?
> Aah! I'm scripter, and they're programmers!?
Heh. No, of course not, sorry! ;-) This is why the distinction makes
me totally uncomfortable (see
http://www.plope.com/Members/chrism/agile_foo). You're clearly not a
"just a scripter" if you're gluing together Plone and Cheetah. ;-) My
instinct is to call everybody who touches logic a programmer. Some
programmers are more experienced than others (like yourself), but
otherwise, everybody who touches logic is a programmer to me. ;-)
> Perhaps y'all work for bigger companies than I, but most of us have
> to wear many hats. A weekly newspaper for instance, isn't going to
> be able to afford a full time web person.
> Shell? What's a shell? I think the CLI is way too intimidating for
> most people. If I don't need to drop to the command line to install
> SPE, or OpenOffice in Ubuntu, all with myriads of dependencies, why
> would I to install a simple poll product to my website? Other CMS's
> offer this.
:-( I don't understand. You're clearly an experienced programmer and
likely a very good sysadmin, and to be a programmer, you (with a few
notable exceptions) need to understand CLI. You're likely the one
that installs products now, and you know it's not that hard except for
keeping versions straight. We're trying to make that easier in the
context of Zope by allowing products to be packaged as Eggs. If it's
not you, which specific person at your company are you trying to help
with a *TTW* product installer? On which systems would it be used at
your company? Would you expect people to know how to use it after it
got installed? Given that you don't seem to be using "stock Plone"
for content delivery, and given that your designers don't have that
kind of time, is this really a reasonable expectation? Are you
talking about something that would just magically start to work on
your site because you might have prepared it explicitly for this
purpose, but you just want to give people the option to turn it on or
off within your particular templates?
Note that I'm talking about "TTB programming" in the context of Zope
rather than any add-ons. Of course, Zope isn't a CMS (in reference to
your mention of "other CMS's" above), it's an application server.
Plone, OTOH, is a CMS, so I might expect it to offer this kind of
thing, but I wouldn't expect Zope to do it "out of the box". Do you
think this is a bad expectation in the context of Zope?
> What I'd like to see is TTB but instead of Samba-ing to a file
> system, I'd rather see WebDav-ing into the ZODB. Than we get best of
> both worlds. I haven't checked out Skeletor but IMO this technique
> is very fragile. Paste uses this technique and I remember the Subway
> project was a complete mess when they were developing using Paste.
You're OK with the fact that if you or your designers do use DAV to
edit code that lives in the ZODB, that it can't be versioned in the
same way that your other code is via subversion? Likewise, you're OK
with the fact that you can't repeatably deploy a particular set of
code without copying the ZODB over to a new system (or doing "export
surgery")? If you could give them largely the same experience but the
code *was* tracked by a version control system, would that be a good
thing?
Replies to this comment