> 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.
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