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

[Gregoire Weber]

Hi all!

I'd like to focus a little on the difference in brain structures=20
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,=20
      logic/presentation, etc. They even do not what these=20
      concepts are usefull for.

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

      So they never would write a python product!

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

      Think about what is easier to understand for an non=20
      Programmer? Yes they begin with code like that!

         a) Hello <b><dtml-var name></b>, how are you?

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

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

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


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

   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=20
      > won't have to deal with modules or packages.

      ... and which files get saved wherea nd why. They get=20
      simply saved!

      At 17:36 13.01.2003 -0500, Jim wrote:
      > > Is there no middle-ground, or hybrid, between these=20
      > > two things?
      >
      > Well, actually, there is.  We will provide the ability=20
      > to define new content types with a GUI that lets you define=20
      > a schema for the content type and then have a module=20
      > generated for you. The module will contain the shema=20
      > definition and the definition of a class that defines the=20
      > schema.

      If I understood correctly you like new content types being
      created in a similar manner you program a macro in MS Word=20
      or MS Access. I know of non programmers programming MS Access.=20
      They first record macros by clicking around in the GUI. Then=20
      they look at the Visual Basic code and change it smoothly=20
      during the macros lifetime. They're programming in a editor!

      So Zope3 should allow non programmers to click together a kind=20
      of skeleton. Zope3 should then take care of bilding a correct=20
      structure and saving this to the correct place. The source code=20
      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=20
      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=20
      products written by more advanced "click together code and
      extend in editor" programmers.

      People then would be very proud having programed Zope3! :-)=20
      They'll be very motivated to deepen their knowledge and flud=20
      the mailing lists ...=20

      From "our" point of view the resulting code has correct=20
      structure, lives in editable files, is expandable and debugable=20
      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=20
      board.=20

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

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


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=20
   integrators can click together Zope and third parties components=20
   like they were LEGOs.

   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=20
   you program automated hardware production tests in a graphical manner.=20
   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 :-(

Gregoire
_____________________________________
Gr=E9goire Weber
mailto:gregoire.weber@switzerland.org