[Zope3-dev] Need help planning Zope X3 1.0

[Stephan Richter]

On Saturday 07 February 2004 18:23, Jim Fulton wrote:
> Stephan Richter wrote:

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

I think it has been controversial because everyone on the mailing list is not 
in the audience. Both, the SQLExpr and inline Python support came from 
feedback from people that deal with scripters all the time. For the purists 
any scripting support will look like a hack.

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

Oh, I talk about the migration from the Scripter --> TTW developer --> Python 
product developer. I realize that not all people will make the second 
transition, which is fine. But I think that everyone should make the first 
transition at some point.

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

I remember the difficulties I initially had with understanding OO programming 
and the jump from SQL to ZODB was also not that easy. It took me a couple of 
years to completely understand the latter one (otherwise I would have never 
developed SQLObjects).

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

Yes, it is magically used; something that really bugs me about this product. 
But I could just not think of something better. BTW, optionally you can also 
just specify a DA name, but the example was meant to work without any 
additional setup.

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

As Alan had put it: This is the second step. The scripter wants the fastest 
success possible.

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

I totally agree, but it already requires the scripter to be accustomed with 
some of the framework.

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

Yes, I think that would be better. I do not know PTL, but I know something 
like Python Page is needed! I just looked quickly at PTL and it looks pretty 
interesting. In fact, it has the same ideas I had with Python Page but is 
much more developed.

> > This is pretty much everything the scripter needs.
>
> I don't agree. But I also don't know.

What else do you think is needed?

> > - Local Adapter Service: It is already part of the To-Do list.
>
> Yeah, but maybe it shouldn't be.

Based on your other comments, it should not.

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

The base code was actually not that rought at all. What was a bit rough was 
the integration into menus. I had not worked on this, since you said you 
would redo the local menu service. We have similar code that is used 
successfully in the workflow package as well.

> > Issues punted on for 1.0:
> > -------------------------
>   - Testing for TTW

Good point.

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

We should maybe start listing it at this point.

> I suspect we should largely punt on TTW development.

Yep, I get this feeling.

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

Me too.

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