Looks like you're a "scripter" (or a person that helps manage scripters). Woo hoo! Excellent! I have a bunch of questions for you. ;-)
""" TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain. """
You say "content entry" above so I assume this means that you want your applications to continue to be web apps. No disagreement from me. I don't want to make fat client GUI apps with Zope. I might consider creating a fat client GUI app to manage Zope configuration (e.g. a ZCML inspector) but content entry people would never see that.
""" Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP. """
A litany of questions: How many designers are there? Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it? Do they change it or just work around it? If they do change Cheetah logic, to what extent do they make change? 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)? How much traffic do the sites that you have this on get? Is performance adequate? Who gets the phone call when performance becomes inadequate? Do you have a process for isolating performance problems?
"""
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
"""
Do they make changes directly to the live site or is there a staging process? If there is a staging process, how do the changes make it to the live site? 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?
"""
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
"""
"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. ;-)
For production sites? Who's the actor here? Under what circumstances would product-installation-via-a-shell-prompt be less than adequate? Do you use ZEO? Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
"""
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
"""
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? Have you used any Zope 3 or Five stuff yet?
"""
* Seperate admin, public and preview skins - not one template fits all like Plone
"""
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?
"""
* User, group and role administration
"""
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?
RE: In the Flesh
Posted byksmith99at
2005-12-24 01:29 PM
> 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.
""" TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain. """
You say "content entry" above so I assume this means that you want your applications to continue to be web apps. No disagreement from me. I don't want to make fat client GUI apps with Zope. I might consider creating a fat client GUI app to manage Zope configuration (e.g. a ZCML inspector) but content entry people would never see that.
""" Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP. """
A litany of questions: How many designers are there? Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it? Do they change it or just work around it? If they do change Cheetah logic, to what extent do they make change? 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)? How much traffic do the sites that you have this on get? Is performance adequate? Who gets the phone call when performance becomes inadequate? Do you have a process for isolating performance problems?
"""
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
"""
Do they make changes directly to the live site or is there a staging process? If there is a staging process, how do the changes make it to the live site? 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?
"""
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
"""
"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. ;-)
"""
* TTW installable products (like a combination QuickInstaller/egg downloader)
"""
For production sites? Who's the actor here? Under what circumstances would product-installation-via-a-shell-prompt be less than adequate? Do you use ZEO? Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
"""
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
"""
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? Have you used any Zope 3 or Five stuff yet?
"""
* Seperate admin, public and preview skins - not one template fits all like Plone
"""
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?
"""
* User, group and role administration
"""
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?
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
Replies to this comment