[Zope3-dev] IMPORTANT RFS: Through the Web Site Development

[Jeffrey P Shell]

*whew*  it's 4:00 in the morning as I'm wrapping this up.

On Monday, January 13, 2003, at 06:20  PM, Gregoire Weber wrote:

> Hi all!
>
> I'd like to focus a little on the difference in brain structures
> between long term programmers (as we are) and non programmers.
>
> Here (my) two thesis about non programmers
> ------------------------------------------
>
>    1. Structure is magic for non programmers!
>
>       Non programmers using Zope do not care about Structure,
>       separation of abstract things like concerns,
>       logic/presentation, etc. They even do not what these
>       concepts are usefull for.

Then what are they using Zope for?  Are they just using Zope itself or 
custom solutions built by Zope Application Developers?

>       They're not interested in file system package stuff and
>       do not know what all these directories are for and why some
>       things are living in one directory and other things in other
>       directoreis. So they won't be able to figure out why they
>       should place what code in which directories to write a python
>       product.

Again, then why are they using Zope?  It's like a Visual Basic 
developer who thinks that just by laying out an interface, they'll have 
an application without realizing that there still needs to be some code 
to glue it together.  There is a structure, it does matter, it has to 
matter.  Why?  So that it's not a shock to them later when they try to 
do something *with* structure.

>       So they never would write a python product!

They would never write a Java bean.  But they'd sure like to use one.  
So those beans better be easy for bean authors to write and distribute.

>    2. The mixing of HTML and TAL in ZPT is magic also! DTML is
>       separated much clearer from the HTML code!

It's well documented, making it not magic.  The rules are clearly 
spelled out.

StructuredText is magic because you don't know what you're going to get 
(ie - try starting a StructuredText line as "p. s., I forgot to tell 
you...").  reStructuredText has very clear rules - no alarms, no 
surprises, no magic.  The spec came (and still comes) before code.

Python?  Little or no magic.  Compare that the joys of $_ in that other 
P-language :).

>       Think about what is easier to understand for an non
>       Programmer? Yes they begin with code like that!
>
>          a) Hello <b><dtml-var name></b>, how are you?

You do know that this very code example will blow up in DTML, don't 
you?  Because - thanks to shortcuts - <dtml-var foo> is really 
<dtml-var name="foo">; DTML will see this above code and try to find a 
value for the "name" parameter.  It's the same as trying to get away 
with <dtml-var expr> or <dtml-var fmt>, which we're less likely to do.  
Oops.  DTML just blew up, and you don't know why because you've never 
seen it mentioned that <dtml-var name> should really say <dtml-var 
name="name">.  And lets not forget the differences between <dtml-var 
foo> and <dtml-var "foo">.  Have you every had to explain to someone 
why their DTML statement was getting funny results in two different 
situations - one where they used quotes, one where they didn't?  Ever 
tried to explain to someone the differences between:

   <dtml-let foo1=bar
             foo2="bar"
             foo3="'bar'"> ?

>          b) Hello <b tal:content="name">name</b>, how are you?
>             (question that possibly arises: why is there two times
>              something like a 'name' variable?)



>       As you can see in the examples above the the DTML tags are
>       separated from HTML tags. While programming DTML you can
>       easily print "the source" and then mark the DTML parts
>       with a marker.

But can you spot where all the names are coming from?  In ZPT, every 
name definition and lookup is very explicit and well defined.  In DTML, 
it can come from almost anywhere.  Besides - the DTML tags are not 
separated from the HTML tags.  They look like html tags - they start 
and stop with < >.  Is it that much easier to say "well yes - these 
special html tags get changed before they go to the browser" than it is 
for "these special attributes operate on the HTML tags and change them 
on the way to the browser?"

In both BBEdit and Adobe GoLive's source mode, TAL statements are easy 
to pick out - and they don't blow up the text editor's ideas of what 
HTML should look like.  DTML would always through a colorizing engine 
off.  We've got a designer who doesn't know TAL, but he knows to keep 
Dreamweaver in split mode (visual/source) when we've got TAL statements 
in there and how to watch out for them, and he hasn't broken anything 
that we've given back to him based off of his designs.  So here's a non 
programmer who knows enough about TAL to keep his dynamic pages 
working.  That's quite a bit different from when we'd take his code, 
chop it into hundreds of little DTML pieces, and he couldn't look at it 
again in his tool of choice.

>       In ZPT you have to mix HTML with TAL-Expressions. If the
>       page doesn't render correctly you have to fight with HTML
>       and TAL in parallel.

In DTML, you mix lots of tiny little parts to weave a page together, 
and due to the namespace soup you can get wild and unpredictable 
locations just by using <dtml-var part>.  I can't remember what it was 
now, but there used to be an object you could add to a folder in Zope 
that would break manage_tabs in a humorous way.  I think it might be 
'target'.

>
> Solutions that possibly motivate non programers to use Zope3
> ------------------------------------------------------------
>

This should not come at the expense of motivating programmers to NOT 
use Zope 3.

>    1. Adopt the MS Macro programing paradigm!
>
>       I think Jim is right with the follwoing statements:
>
>       At 17:59 13.01.2003 -0500, Jim wrote:
>> My point was that for simple scripts and templates, they
>> won't have to deal with modules or packages.
>
>       ... and which files get saved wherea nd why. They get
>       simply saved!

"simply" is an overused word.  If you don't know where things are, how 
are you ever going to use them?

>       At 17:36 13.01.2003 -0500, Jim wrote:
>>> Is there no middle-ground, or hybrid, between these
>>> two things?
>>
>> Well, actually, there is.  We will provide the ability
>> to define new content types with a GUI that lets you define
>> a schema for the content type and then have a module
>> generated for you. The module will contain the shema
>> definition and the definition of a class that defines the
>> schema.
>
>       If I understood correctly you like new content types being
>       created in a similar manner you program a macro in MS Word
>       or MS Access. I know of non programmers programming MS Access.
>       They first record macros by clicking around in the GUI. Then
>       they look at the Visual Basic code and change it smoothly
>       during the macros lifetime. They're programming in a editor!

And eventually causing people like me to be hired to come in and clean 
up the mess because they can't figure out how to get 
${programmer_who_quit}'s program to be able to work online.  *Shudder*.

Is it good that they're programming in an editor?  Yes.  It's good that 
the tools are letting them get their job done.  But just because you 
can click some things together in Access does not mean you can maintain 
an Oracle database.  There's a big scary leap between even Access and 
SQL Server that most users don't care to cross - from either side of 
the platform.  Things are made to appear so easy on one side that 
there's still that steep technology learning curve on the other.

Somehow Python seems to avoid that curve (unless you get into exploding 
head stuff like metaclass hooks ;).

I stand by my earlier assertions that if the Python code required to do 
most things in Zope 3 relating to custom objects is...well, Pythonic 
and not Zope 2ish, Python won't be so intimidating.  Even if you don't 
learn how to program a Java class or bean, you still have to learn some 
java syntax to use JSP's.

>       So Zope3 should allow non programmers to click together a kind
>       of skeleton. Zope3 should then take care of bilding a correct
>       structure and saving this to the correct place. The source code
>       should then be editable in a easy way (TTW) not confronting the
>       non programer with things like structure and code locations.
>
>       side note: That was what I suggested Zope1's and Zoep2's ZClasses
>       to be before I've done my first (and last) ZClass of my life.
>
>       Because the skeleton is the same for all these "clicked together
>       code products" they can easily copy code fragments from other
>       products written by more advanced "click together code and
>       extend in editor" programmers.

>       People then would be very proud having programed Zope3! :-)
>       They'll be very motivated to deepen their knowledge and flud
>       the mailing lists ...
>
>       From "our" point of view the resulting code has correct
>       structure, lives in editable files, is expandable and debugable
>       by an expert, etc.)!
>
>    2. Let non programers do their stuff in DTML!
>
>       This way we have the chance to get all these PHP/ASP people on
>       board.

DTML is foreign to PHP/ASP people.  The only people it might really 
make sense to is Cold Fusion people, because they had the custom tags.  
PHP and ASP people are used to having a full programming language at 
their disposal that they jump into at any time.  DTML is a micro 
programming language in its own right, which is what made things so 
complicated.  <dtml-in> is not a for loop.  (It's potentially made even 
worse because DTML allows things that not even Python has, such as a 
'with' statement).

DTML as a template language...not bad.  DTML as a programming 
language...bad.  You end up with more bad habits than good ones.

But ASP.NET, and Taglib-using JSP looks a lot closer to ZPT.  The 
difference?  ZPT is much lighter weight, and I think easier to grasp.  
But TAL wouldn't be too hard to explain to people who are getting used 
to seeing things like::

<xyz:data-table source="iterator" id="beanname">
<tr>
<td><jsp:getProperty name="beanname" property="prop" /></td>
</tr>
</xyz:data-table>

You can even get TAL to look like that!

<tal:loop repeat="beanname container/iterator">
<tr>
<td><tal:display replace="beanname/prop" /></td>
</tr>
</tal:loop>

:)

ASP.NET has <asp:Repeater>, which is similar.

>       The only thing we have to do is to write documention with
>       titles like "How to convert your DTML code into Zope Page
>       Templates" or "Migration path from DTML to ZPT". Give this
>       part of documentation a non restrictive License (not GPL)
>       which allows book writers to copy&paste without beeing forced
>       to deal with copylefts and license issues.

If they have to migrate, they won't do it.   Why learn something when 
you know you're going to have to learn something completely different 
not too far down the road?

>       Important: DTML should not be more powerful that ZPT to ease
>       the migration path!

DTML is more powerful than ZPT, but not in a good way.

I again point to ASP.NET.  I was showing a Windows developer friend of 
mine some ZPT code and he said "that's a lot like ASP.NET", because 
ASP.NET uses XML namespaces aggressively.  And it aggressively promotes 
"code behind" page development, where there is a more explicit 
separation of the logic - even something like a Page_Load handler - 
from the page.  (Usually in ASP.NET, a page posts to itself and its 
Page_Load handler inspects the request and decides to move on).  So 
ASP.NET is now catching up to many of the ZPT+Python Script concepts.  
Now that the rest of the world is catching up to where WebObjects was 
in 1996, where Bobo was in 1996/1997, and where ZPT+PythonScripts got 
us back to in 2000/2001, why leave it behind?

I think that the .NET model already makes it easier for people to make 
redistributable ASP.NET components - much easier than it was to do with 
classic ASP + COM components.  And I think it's because they have a 
simplified and more unified development model.

>
> Graphical Component Aggregation Tool
> ------------------------------------
> (day dreams)
>
>    Because the component architecture builds on the same principles
>    like LEGO are built there should be a graphical editor where sytem
>    integrators can click together Zope and third parties components
>    like they were LEGOs.

I think this could happen - but in order for this to happen, we need to 
take care of the component developers first so that they can write the 
components that are supposed to snap together.

>    I know of a 55 year old electronic engineer which began to program
>    C with LabView not realizing doing that. LabView is a tool that 
> helps
>    you program automated hardware production tests in a graphical 
> manner.
>    Behind the scenes the graphical program gets converted to C.
>
>    I think, that would attract a lot of people using Zope.
>
> Sorry the mail got longer than expected :-(
>

Same with my response :\.  It's now way too late for me to be up.