[Zope3-dev] Need help planning Zope X3 1.0

Jim Fulton jim at zope.com
Sat Feb 7 18:23:04 EST 2004 

Stephan Richter wrote:
> 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.

I don't agree.  I don't think this has been well thought out
and what has been done is controversial.

> 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.

A migration path?  What sort of migration path? From Z2->Z3? From scripter to
developer? From other systems to this one?

> 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.

I don't agree with this assessment, but that doesn't matter. I certainly agree
that what you want is worthwhile.

 > 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.

This looks interesting. I don't understand how the adapter is connected to the sql.
You define an rdb variable, but don't use it. Is the rdb variable magically used
by the expr?

I'd rather focus on making it easier to define database adapters, including
a default one.

In any case, while this proposal is interesting, I think it needs more thought.

I also think that the separation of sal and template code has been very successful,
perhaps even for the scripter. We certainly still have sql scripts and I assume
that they work.

> - 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>

While I know this is controversial, I do still think that this is
worthwhile.

> 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>

Of course, this is better for this example.

I also think we *need* PythonLibraries.

> 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>
> """

No. Forget it. This will never be part of the core. :)

If we were going to do something like this, I'd much rather
pick something from another successful Python project. Perhaps
PTL.

> This is pretty much everything the scripter needs.

I don't agree. But I also don't know.

 > 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.

Another good idea.

I'd like to put more thought into scripter support.  More thought
than we might want to take time for before 1.0.


> 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.


Yeah, but I'm not sure that what we have now is solid enough yet.
I think it is at an experimental state.

 > On top of this
> you can create views and, once the local adapter service lands, adapters.

Yes, and persistent modules, which we should be able to make accessable
in content space.

> 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.

Yes. We'll want to flesh this out a bit.

I think we should scale back out expectations in this area.  Perhaps, for
1.0 we should label oll of the TTW development bits as experimental.

When we get closer to the release, we'll need to figure out what's in,
what's out, what's configured and what's not. It would be helpful to
be able to label features as experimental somehow.


> 
> 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

I'll look at that.

> 
> 
> 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!

What we *really* need is to get Evan Simpson's ZPT adapter work into
Z3 ZPT.


> - 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.

Probably not, but the workaround is trivial.

> - 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.

Not for 1.0.


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

Yeah, but maybe it shouldn't be.

> - 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.

I will fix what broke it, but I'm still not comfortable with including it in
Z3.  Your idea of working well and mine are different.  I found it rather
rough.

> 
> 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.

  - Testing for TTW

But there's much more we'll punt on.

I suspect we should largely punt on TTW development.

But, I'd love to get lots of input on this.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org

More information about the Zope3-dev mailing list