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?
re: more q's
Posted byksmith99at
2005-12-24 05:00 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.
np
> 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 can arbitrarily add #block's and they're corresponding #def's, although not ideal, it's easier to digest than ZPT macros
> 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?
they can use wysiwyg tools, I found this http://www.oreillynet.com/cs/user/view/cs_msg/50296 so code looks like this
<!-- #for $myObj in $objList #-->
<tr>
<td>$myObj.attr1</td><td>$myObj.attr2</td>
</tr>
<!-- #end for #-->
> But the designers don't check any of their code changes in, right,
> because they edit code that's in the ZODB?
yup
> 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.
There is a preview feature. Yes, there is definately a danger of breaking the site and grinding the site to a halt, but should that happen they can fall back to a previous skin. The current method is to copy an existing skin, tweak it, preview it, set it for the next issue date.
> 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?
Yes. they do there own q&a
> 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. ;-)
:)
> :-( 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.
yes, I've seen your work on that
>If it's
> not you, which specific person at your company are you trying to help
> with a *TTW* product installer?
It's a multi-purpose person
> On which systems would it be used at
> your company? Would you expect people to know how to use it after it
> got installed?
yes
> 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?
This is probably more the realm of the GoldEgg project. Is it reasonable? Depends, I think it's doable. What if we called them plug-ins?
> 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?
yes. isn't it possible? webmin does quite complicated installation. download egg. install product. product appears in the admin. configure product. create instance. add to public site.
> 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?
No, I don't expect it out of the box from Zope. TTB is in response to agile content. Agile content blurs alot of the distinctions in roles. Zope3 blurs alot of distinctions, , especially since most of the CMF has been absorbed into the base Z3 infrastructure. But I do expect it from the GoldEgg project or projects similar to it.
> 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?
I haven't checked pysubversion yet, but ideally i'd love to check-in versioned code and content directly into svn transparently.
> 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?
if it was largely the same experience, *yes*. lets see the code ;-) Ideally I'd like to see a product/skeleton that mimicked some of the behaviour of CherryPy, Phillip has a great post that uses decorators to replace <browser:page.
Wish I could chat more, but hopping on a plane to Rochester. Have a great holiday.
Kevin
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?
> questions follows; I hope you'll be patient, I really want to
> understand where you're coming from.
np
> 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 can arbitrarily add #block's and they're corresponding #def's, although not ideal, it's easier to digest than ZPT macros
> 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?
they can use wysiwyg tools, I found this http://www.oreillynet.com/cs/user/view/cs_msg/50296 so code looks like this
<!-- #for $myObj in $objList #-->
<tr>
<td>$myObj.attr1</td><td>$myObj.attr2</td>
</tr>
<!-- #end for #-->
> But the designers don't check any of their code changes in, right,
> because they edit code that's in the ZODB?
yup
> 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.
There is a preview feature. Yes, there is definately a danger of breaking the site and grinding the site to a halt, but should that happen they can fall back to a previous skin. The current method is to copy an existing skin, tweak it, preview it, set it for the next issue date.
> 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?
Yes. they do there own q&a
> 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. ;-)
:)
> :-( 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.
yes, I've seen your work on that
>If it's
> not you, which specific person at your company are you trying to help
> with a *TTW* product installer?
It's a multi-purpose person
> On which systems would it be used at
> your company? Would you expect people to know how to use it after it
> got installed?
yes
> 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?
This is probably more the realm of the GoldEgg project. Is it reasonable? Depends, I think it's doable. What if we called them plug-ins?
> 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?
yes. isn't it possible? webmin does quite complicated installation. download egg. install product. product appears in the admin. configure product. create instance. add to public site.
> 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?
No, I don't expect it out of the box from Zope. TTB is in response to agile content. Agile content blurs alot of the distinctions in roles. Zope3 blurs alot of distinctions, , especially since most of the CMF has been absorbed into the base Z3 infrastructure. But I do expect it from the GoldEgg project or projects similar to it.
> 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?
I haven't checked pysubversion yet, but ideally i'd love to check-in versioned code and content directly into svn transparently.
> 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?
if it was largely the same experience, *yes*. lets see the code ;-) Ideally I'd like to see a product/skeleton that mimicked some of the behaviour of CherryPy, Phillip has a great post that uses decorators to replace <browser:page.
Wish I could chat more, but hopping on a plane to Rochester. Have a great holiday.
Kevin