[Zope3-dev] Need help planning Zope X3 1.0

Sat Feb 7 08:11:35 EST 2004

On Thursday 05 February 2004 22:12, Jim Fulton wrote:
> Do we need to do more for scripters in release 1.0? If so,
> is anyone willing to provide some leadership?

I think we are in pretty good shape concerning scripter support. We have 
pretty much all the technologies we need in place; they just need some 
polishing and fill-in.

But the point is that we do not want just plain scripter support and that's 
it. We need a migration path for them and I believe I worked on this as well.

Thanks to Alan and other people, I think I have a good idea of what is 
required for the scripter. Here are the levels as I see them and what we need 
to provide:

Level 1: The Scripter
---------------------

Here everything is quick and dirty. Usually people at this level use RDBs to 
store data and will not have the patience to learn the ZODB (or any OODB) way 
of doing things. Therefore it is important to provide them with tools to 
manipulate RDBs (by giving simple access to SQL statements) and to display 
the data nicely. I believe we have most of the required tools in place.

- The SQLExpr product provides the ease required for the scripter to deal with 
SQL, since it allows to embed it directly into templates. There is no need to 
educate the scripter about the software space and how to create connections. 
All that is required is the installation of a database adapter. Here is some 
example code:

<html tal:define="rdb string:PsycopgDA; dsn string:dbi://test">
  <body>
    <ul tal:define="table string:contact">
      <li tal:repeat="contact sql: SELECT * FROM ${table}">
        <b tal:content="contact/name" />
      </li>
    </ul>
  </body>
</html>

In this case we only have to tell the scripter about the various DA names and 
the meaning of DSNs, which is simple in my opinion.

- Inline Python support. As you probably know, we are already able to execute 
Python code from page templates, if a flag is activated. Then the following 
code is possible:

<html>
  <body>
    <script type="text/server-python">
           import time
           global t
           t = time.asctime()
    </script>
    <b tal:content="t" />
  </body>
</html>

Of course, for this example the following should also work (and it does; I 
just tried):

<html>
  <body>
    <b tal:content="modules/time/asctime" />
  </body>
</html>

Additionally to all this, I think Casey's sarcasm brought us another good tool 
for the scripter, namely the Python Page. Python Pages are almost like Python 
scripts, except that they do not take arguments or return something definite. 
They can only output text by printing it. However, you are not required to 
use print statements on triple quotes, so that the following is possible:

"""
<html>
  <body>
"""
import time
"""<b>%s</b>""" %time.asctime()
"""
  </body>
</html>
"""

This is pretty much everything the scripter needs. One other content type that 
would be nice is a "XML Content" object that is accessible via DOM. A lot of 
scripters are familiar with DOM from their browser experiences (i.e. 
JavaScript), so that it would be natural for them. Also, it would be really 
easy to use with TALES and Python code.

Level 2: The TTW Developer
--------------------------

This is the group that will be least addressed in the 1.0 release; however, we 
have some powerful tools pretty much ready to use for them. The most 
important one, in my opinion, is the ability to create TTW schemas and create 
a content type definition that can be used in content space. On top of this 
you can create views and, once the local adapter service lands, adapters. 
This in combination with the scripters tools and the other software space 
functionality provides a nice base for the TTW developer and offers a great 
migration path for the scripter. 

The scripter can start out learning only a few concepts at a time, like 
schemas, and be able to create custom content components. Later he can dive 
deeper into it and discover the concept of views, which are pretty much just 
Page Templates for content components. However, he can also discover views 
first, in the form of views on existing content components. The power of 
adapters s/he will probably discover last, since it depends on an 
understanding of views.

Level 3: Python Developer
-------------------------

We all know what's in the bag for this group. Most of our current 
documentation is aimed at them.

BTW, most of the above is documented in detail in my recipe on the Zope 3 GUI:
http://dev.zope.org/Zope3/DevelCookbook/Zope3GUI

Left To-Dos for 1.0:
--------------------

- TALES Namespaces: While TALES NS are done, there are almost no namespaces 
created. In fact, I think the only one available is the "zope" namespace, and 
even it is not complete. There should be additional namespaces:

+ locale: Here we should allow fast and simple formatting of dates/times and 
numbers. 

+ dc: Here all dublin core meta data should be made available.

+ adapt: I described how "adapt" should work in the referenced recipe.

+ string: This NS should provide simple string manipulation

As people start putting on the scripter hat for testing, I am sure we will 
come up with a whole lot more ideas. This is a part that needs serious work!

- datetime: Currently it is not possible to create new datetime object TTW, 
since we have no way to create security declarations on the method of a class 
(in contrast to instances). Jim knows about the issue and I hope it will be 
fixed in time.

- XML Content: I do not know how far Martijn is here, but it would surely be 
an item nice to have. Not a requirement though.

- Local Adapter Service: It is already part of the To-Do list.

- Schema-based Content Type: This used to work very well and reliably until 
the changes in the CA arrived. Jim, you punted on TTW content types, in your 
outline, but *please* let's not punt on the schema-based version. It is a 
very important part! Once you get the persistence issue fixed with TTW 
Schemas, I will make sure this works for the release.

Issues punted on for 1.0:
-------------------------

- Internationalization for TTW development in general is not an issue we have 
addressed yet at all. Besides that DTML needs a tag for internationalization, 
we also have to develop extraction tools for the local translation service. 
This task should not be too hard, but will require some time.

Okay, that's enough for now.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training