""" One class of user that I need to serve is someone who likes to tweak site design. This is mostly HTML tweaking, but does involve some TAL and simple Python expressions, pulling information out from an underlying application. It's a limited experience that you could consider to fit your "by the book" approach, but they do seem to need certain things that Zope 3 currently doesn't offer them."""
I've actually thought quite a bit about this. The challenge is to give these kinds of folks an appropriate but limited amount of power; enough power to make simple changes but not complete control. You want to limit their power due to security concerns and encourage them to learn more about views if they want more power.
One way to do this is to not use TAL. Instead, use something like PyMeld to give people the opportunity to change the behavior of something in very limited ways. The template could live on a filesystem, and they could change it via Dreamweaver. Or, because its power is so limited, they could always change these kinds of things through the web without requiring a restart and without any special security wrappers or anything. A section of the template might look like this:
They could change "name" to "description", "date", and so on. The designer could insert whatever happened to be anticipated by the view logic. All templates would be a complete HTML page and would work in WYSIWYG tools. They wouldn't need to know any Python. They couldn't effect the performance of the site, because the site performance is basically fixed to view speed. You could provide them documentation in the form of what kinds of names are available to them in which places.
I suspect people will say that this is too limited. But it does provide a reasonable answer to allowing tweakers to have control of what is shown during a rendering without extending arbitrary power to them. If they needed more power, they could gradually be introduced to Python and views.
""" Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five. """
I've noticed that a lot of my customers (which of course is a limited sample of people; I don't mean to suggest it's a comprehensive set) don't really want to do editing via a TTW interface. They only use it because it's the only way to do it. They'd much rather use a WYSIWYG HTML editor against files on a filesystem, because they've had experience doing this before. I'd actually usually (and do) rather just give them a Samba mount to the directory that contains a checked out version of a set of templates. Since Five templates are reloaded in debug mode, they'd be able to preview their work immediately. Since they'd be working in a checkout, you could later come along and see just what they did using svn or cvs or whatever and check in what's appropriate. This tends to service a good 90% of my customers' customization requirements; the other 10% they need to get me involved in or they need to learn how to write product code or complicated TAL. I've also had a bit of success here by giving them GUI frontends to CVS so they can see what they've changed (even if they can't or don't want to check it in).
Other folks may have different needs obviously; there is apparently this mystical "scripter" person hanging around who wants more control but doesn't want to pay for that control with the overhead of a version control system. I suspect that providing him this kind of power isn't always a really good thing to do. "I want it" isn't a compelling reason as far as I'm concerned, because whenever I come across such a site designed via spurious customization hacks, I almost always need to suggest we throw it away and start over. Their dependence on this kind of power ends up hurting them (and Zope) as a result.
If there is some class of people that doesn't care about what happens tomorrow and just needs to "fix it" today, then fine. Go nuts. Have at it. TTW customization out the yang. The limiting factor is really just how long will it be before someone *else* needs to look at that and make it actually work outside of a toy environment. Often this is sooner than later. I'd rather be compassionate about it and take them in a sane direction to start with. I think they can be enouraged to do the right thing using "project code generation" to a large degree.
""" I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer. """
Restarts are indeed a problem, even if you're a pretty experienced coder. We should think about making that better. But the kinds of folks who want to control both the look and feel and have arbitrary power to change logic without any version control overhead also tend to be the people that want this kind of coding cycle. I won't pretend that it doesn't frighten me, but I will concede that it works for some definition of works for a certain class of people. I just don't want to "sell" Zope proper based on this kind of coding cycle... if a third-party tool serviced this goal, that'd be fine. Maybe something that hooked up external editor or a textarea to allow for the direct editing of filesystem templates?
interesting comments
Posted byfaassenat
2005-12-21 04:27 PM
Just wanted to drop in a note to thank for this extensive, almost hidden, comment. I just commented on the previous article you wrote but I see you already answered some of my concerns here.
I'm googling for PyMeld right now to see what that is about. I'm also curious the way you work with Samba mounts -- I presume you have customers mount a checkout remotely and edit through the filesystem? If this works for you, perhaps we can document this pattern somewhere as it may mitigate some of the issues.
Agreed by the way that TTW is not the focus of this issue -- the issue is customization, easy and remote customization, not the particular way this is done, such as TTW. The one benefit TTW editing has is that it's very easy to deploy and start using, but perhaps your Samba approach offers an alternative model with similar benefits.
samba...
Posted bychrismat
2005-12-21 05:07 PM
"""I presume you have customers mount a checkout remotely and edit through the filesystem? If this works for you, perhaps we can document this pattern somewhere as it may mitigate some of the issues. """
Yes, I've done this in the past. Unfortunately due to linefeed differences between UNIX and DOS, it can happen that files added to the samba mount by a remote Windows machine can have the wrong line endings if the users don't configure their tools to use UNIX line endings, which confuses the heck out of (at least) CVS. So I usually just run those files through dos2unix before checking them in. It's a real pain. It might be a good idea to have a commit hook that does this.
I haven't had much luck in providing CVS frontends *over* samba for the same sorts of reasons. But a few Windows customers I've been able to persuade to move to MacOS, and that makes life oh so much easier because they can actually run the appserver, edit files, and use CVL on their local machine without much drama.
I've actually thought quite a bit about this. The challenge is to give these kinds of folks an appropriate but limited amount of power; enough power to make simple changes but not complete control. You want to limit their power due to security concerns and encourage them to learn more about views if they want more power.
One way to do this is to not use TAL. Instead, use something like PyMeld to give people the opportunity to change the behavior of something in very limited ways. The template could live on a filesystem, and they could change it via Dreamweaver. Or, because its power is so limited, they could always change these kinds of things through the web without requiring a restart and without any special security wrappers or anything. A section of the template might look like this:
<table meld:id="thetable">
<tr meld:id="thetr">
<td meld:id="name"/>
</tr>
<table>
They could change "name" to "description", "date", and so on. The designer could insert whatever happened to be anticipated by the view logic. All templates would be a complete HTML page and would work in WYSIWYG tools. They wouldn't need to know any Python. They couldn't effect the performance of the site, because the site performance is basically fixed to view speed. You could provide them documentation in the form of what kinds of names are available to them in which places.
I suspect people will say that this is too limited. But it does provide a reasonable answer to allowing tweakers to have control of what is shown during a rendering without extending arbitrary power to them. If they needed more power, they could gradually be introduced to Python and views.
""" Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five. """
I've noticed that a lot of my customers (which of course is a limited sample of people; I don't mean to suggest it's a comprehensive set) don't really want to do editing via a TTW interface. They only use it because it's the only way to do it. They'd much rather use a WYSIWYG HTML editor against files on a filesystem, because they've had experience doing this before. I'd actually usually (and do) rather just give them a Samba mount to the directory that contains a checked out version of a set of templates. Since Five templates are reloaded in debug mode, they'd be able to preview their work immediately. Since they'd be working in a checkout, you could later come along and see just what they did using svn or cvs or whatever and check in what's appropriate. This tends to service a good 90% of my customers' customization requirements; the other 10% they need to get me involved in or they need to learn how to write product code or complicated TAL. I've also had a bit of success here by giving them GUI frontends to CVS so they can see what they've changed (even if they can't or don't want to check it in).
Other folks may have different needs obviously; there is apparently this mystical "scripter" person hanging around who wants more control but doesn't want to pay for that control with the overhead of a version control system. I suspect that providing him this kind of power isn't always a really good thing to do. "I want it" isn't a compelling reason as far as I'm concerned, because whenever I come across such a site designed via spurious customization hacks, I almost always need to suggest we throw it away and start over. Their dependence on this kind of power ends up hurting them (and Zope) as a result.
If there is some class of people that doesn't care about what happens tomorrow and just needs to "fix it" today, then fine. Go nuts. Have at it. TTW customization out the yang. The limiting factor is really just how long will it be before someone *else* needs to look at that and make it actually work outside of a toy environment. Often this is sooner than later. I'd rather be compassionate about it and take them in a sane direction to start with. I think they can be enouraged to do the right thing using "project code generation" to a large degree.
""" I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer. """
Restarts are indeed a problem, even if you're a pretty experienced coder. We should think about making that better. But the kinds of folks who want to control both the look and feel and have arbitrary power to change logic without any version control overhead also tend to be the people that want this kind of coding cycle. I won't pretend that it doesn't frighten me, but I will concede that it works for some definition of works for a certain class of people. I just don't want to "sell" Zope proper based on this kind of coding cycle... if a third-party tool serviced this goal, that'd be fine. Maybe something that hooked up external editor or a textarea to allow for the direct editing of filesystem templates?
I'm googling for PyMeld right now to see what that is about. I'm also curious the way you work with Samba mounts -- I presume you have customers mount a checkout remotely and edit through the filesystem? If this works for you, perhaps we can document this pattern somewhere as it may mitigate some of the issues.
Agreed by the way that TTW is not the focus of this issue -- the issue is customization, easy and remote customization, not the particular way this is done, such as TTW. The one benefit TTW editing has is that it's very easy to deploy and start using, but perhaps your Samba approach offers an alternative model with similar benefits.
Yes, I've done this in the past. Unfortunately due to linefeed differences between UNIX and DOS, it can happen that files added to the samba mount by a remote Windows machine can have the wrong line endings if the users don't configure their tools to use UNIX line endings, which confuses the heck out of (at least) CVS. So I usually just run those files through dos2unix before checking them in. It's a real pain. It might be a good idea to have a commit hook that does this.
I haven't had much luck in providing CVS frontends *over* samba for the same sorts of reasons. But a few Windows customers I've been able to persuade to move to MacOS, and that makes life oh so much easier because they can actually run the appserver, edit files, and use CVL on their local machine without much drama.