[Zope3-dev] scripter/designer concerns

[Jeffrey P Shell]

On Sunday, September 7, 2003, at 08:54  AM, Stephan Richter wrote:

> On Friday 05 September 2003 17:47, Jeffrey P Shell wrote:
>> I'm very very afraid.
>
> As Jim said, 'Don't be afraid!' :-) The things you are afraid about 
> will never
> cross your way.

I am often both developer and scripter.  The scripting side is very 
important to me, as I often work with HTML designers and plug in some 
scripting code and the TAL display logic to work with what they give 
me.  This is another reason why I prefer separate Python Script type 
code - it keeps the amount of 'noise' those designers have to see as 
they continue to tweak elements of the design to a minimum, and it lets 
me edit Python happily in Emacs without affecting their designs.

>> This is one of the features about Zope that I can sell over and over
>> again - 'HTML is HTML and SQL is SQL and code is code is code, and
>> never should they meet.'  ZPT in Zope 2 brings an insane amount of joy
>> to my life.
>
> Yes, since you are a developer this is true. But a scripter thinks 
> differently
> about that. The more functionality he has available in one place, the 
> happier
> the scripter is.

Personally, I don't agree.  Even if you work with ASP.NET's WebMatrix 
tool, they go through pains to keep the script code separate from the 
HTML level code.  (There is a view where you can see the whole thing 
combined, but it gives considerable preference to the other views).  I 
think that helps ASP.NET developers get comfortable separating their 
Code from their HTML objects.  Physically, they're stored in the same 
.aspx file (I think that's the extension), but they try to treat them 
as separate.

So they're going through hoops to do what we currently do, and we're 
going through hoops to do what they used to do...

>> I hope all of these things are add-ons.  And I hope they are add-ons
>> which cause painful physical electrical shocks upon using :).
>
> SQLExpr is an add-on. You have to install a Zope 3 product to use them.
>
> <script> could not be an add-on, because it adds functionality to the 
> TAL
> Generator and Interpreter as well as the HTMLTALParser. However, as 
> Jim and
> the news item clearly said, this support is only activated for 
> Content-space
> "Templated Pages" (ZPT Pages) in content space. If you design your site
> correctly you probably will never use Templated Pages much. 
> Furthermore, you
> have to go to a separate screen (tab) to activate this feature. Try it!

How does one design a site correctly in Zope 3?  I see now how to make 
applications like the bug collector in Zope 3, but I don't how to make 
a site that's almost all templated pages that might still require some 
code.

What concerns me is that say I have the following pages:

- license.html
- faq.html
- shows.html

If I were to want to make some of them really smart and dynamic, do I 
have to completely move them over into a ++etc++shudder folder?  
Because I am more of a  developer than a scripter.  What then do I tell 
my designers?  "Some of your pages are here, some are here"?  (and I 
still would prefer not to be having to tell them to go to url's with 
++'s in them).  If I move shows.html to the ++etc++shudder folder, do I 
have to then always refer to it as @@shows.html?  Where are they 
getting their standard template from?  Common images?  We usually have 
one or more images/ folders, and the standard template I usually tweak 
with a regex to ensure that all <img> tags refer to the image absolute 
url's.  I'm not sure how all this works in Zope 3 - is the images 
folder in ++etc++special place?  Is the 'standard_template.pt' 
equivalent in that space?  Will I still be able to open 
'standard_template.pt' via WebDAV in Adobe GoLive and have it load up 
all the images and other sources like it currently does?  Will my 
designers?

In a typical pattern, we usually have a 'site' folder which contains 
all of the public templates and scripts.  It's similar to "content 
space" in Zope 3.  A majority of what's in 'site/' is not dynamic 
(aside from dynamic navigation/menu sections, usually kept in the 
standard template).  But some pages are frightfully so.  I'm not sure 
what to do with those pages.  I love being able to edit them right now 
in GoLive, which has an excellent WebDAV browser.  When you open a 
page, it loads up all images and other resources, like the style sheet, 
so I can still see how the page might look when the TAL code executes, 
thus ensuring that I'm keeping the vision of the designers intact.  And 
again - the designers like this because they can either update many of 
the pages themselves, or they can send me the updates in the same (or 
similar) structure as the actual site, making it easy for me to update 
particular pages and images.

This is a common pattern for us.  Most of the heavy code is in other 
portions of the root application folder, which I *guess* is similar to 
the ++etc++site local configurations.  There's very little business 
logic in the site/ area - it just needs to be nimble enough to respond 
to new changes in design or application flow.

So, I'm unsure how the things I'm worried about will "never cross my 
way".