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

[Paul Everitt]

Jim Fulton wrote:
> Stephan Richter wrote:
> 
> ...
> 
>> What I noticed is that we will have an awesome system for people that 
>> know Python and understand the CA.
>>
>> On the other hand we will loose about 70-80% (wild guess) of the 
>> current Zope 2 TTW developers, who do not know any Python and have 
>> difficulties to understand it.
> 
> 
> That is a wild guess. I wish I knew what the real numbers were.
> 
> One wonders what they *do* know, if not Python .... of course,
> you answer that below....
> 
>  > I am pretty sure that there are many, many sites out there
> 
>> that are written using one of the following two options:
>>
>> 1.) They only use the standard Content Objects that are provided by 
>> default in Zope 2 (maybe they download another product or two). Then 
>> they use ZPT and DTML to do all the logic. Note: I do not think that 
>> much Python Script is used unless someone on the mailing list gave it 
>> to them.
> 
> 
> So they don't know Python, but they *do* know dtml and zpt.  Certainly,
> they have to *learn* these to use Zope.  Of course, we're being pretty 
> vague
> about what we mean by logic.

I think one point is that dtml and zpt resemble patterns and syntax they 
might already know (if it's a CFML or PHP refugee).

> Any non-display logic in DTML or ZPT is Python, so they are probably 
> using some Python
> anyway. But maybe you are talking about people who just do simpler 
> interaction,
> conditionals and data insertion.

Right.  And as pointed out elsewhere (Jon from Detroit), they get to 
that point gradually, after they've started doing the familiar part 
(tag-oriented "programming").

> I think that this group of users is best served by content-space scripts 
> and pages.

Yes, I agree.  This will be what they expect, and following expectations 
is always a good start.  We don't have enough vacancy at the 
Re-education Center. :^)

>> 2.) They use ZClasses (because they understand sort of OO programming) 
>> and use scripts often DTML and ZPT, but maybe already some very small 
>> Python scripts to do the logic.
> 
> 
> Well, if they use ZClasses, they are forced to deal with class, products,
> methods, and either Python, or some hairy DTML or ZPT logic.

Right.  I think this would be a good topic for an IRC appointment or a 
separate thread, calling in people *not* in zope3-dev:

   "If your first stop in Zopeland was with ZClasses, and they seemed
   to fit your brain, we're interested in learning more...about your
   brain."

There seems to be a meme like this: "ZClasses fit my brain, but their 
implementation ultimately left me stranded."

I have some theories about why ZClasses fit people's brain, and some 
conclusions from those theories.  But I want to make sure these theories 
are valid.

>> Advanced Zope developers use:
>>
>> 3) They write their own Python products, but develop most of the look 
>> and feel using the ZMI and therefore ZPT and DTML that lives in the ZODB.
>>
>> While I think that group 3 is addressed nicely, Group 1 and 2 are not.
> 
> 
> I don't think your group 2 is well served by ZClasses. I think that they
> are better served with something like the system I've sketched out.
> If they don't need any Python logic, or insist on only using Python
> scripts in their templates, they can work solely with ZPT (or DTML if we
> decide we need that).

Agreed.  This is, essentially, bringing a two-tier PHP/ASP/JSP model to 
Zope.  You have a page, and it talks to the "system".

> If they do need Python, they's be much better off creating modules.
> Modules are pretty simple, after all.

As long as the gulf in between these two paragraphs can be addressed. 
For instance, if I want to do Shane's Photo scenario, I shouldn't have 
to write a module.  I should fill in a form.

>  > The
> 
>> current versions of ZPT Page and DTML Page are too weak (as intended 
>> when originally implmented) to satisfy group 1, since you do not have 
>> access to some of the interesting methods.
> 
> 
> What methods to they not have access to? Could you be more specific?
> 
> 
>> Example: I want to create a menu quickly. What I did on one site was 
>> to simply take an OrderedFolder and put other OrderedFolder objects in 
>> it having a senible title. Then I just called 
>> "of.objectValues('Ordered Folder')" and displayed the titles of the 
>> sub-folders an voila I had my menu. This was a 2-minute task. How 
>> would I do that in Zope 3?
> 
> 
> We don't have an API like objectValues, that filteres items that have a 
> particular
> type.  If all of the items in the outer folder were known to be ordered 
> folders,
> you could just use the values method: "of.values()", or, better yet: 
> "of/values"
> 
> If people need an API like that (I'm a bit skeptical), then someone could
> certainly provide one.
> 
>> Addressing Group 2, let's say I want to quickly create a NewsItem 
>> object that has a couple of properties and methods. In Zope 2 I would 
>> just create a ZClass, add all the properties and create a couple of 
>> scripts for the methods and I am done. If ZClasses weren't so 
>> unpredictable, this should be a 10-minute task. How would I do that in 
>> Zope 3? Note that writing a Python module is **not** an option.
> 
> 
> Could you explain why creating a module is not an option? If people are
> using Python anyway, wouldn't it make more sense to have them create 
> something
> familiar, like a Python class in a module?
> 
>> What I want to do is:
>>
>> 1. Create ContentObject that inherits from this and that.
> 
> 
> Like what and which? Do you really think the non-advanced user
> cares that much about inheritence?

They might not care about the word "inheritance".  But imagine this 
scenario:

1) I wake up one morning and head immediately to ZopeZen, like all good 
Zope folks.

2) I read about the new release of Shane's exceptional Photo 
package/product/component/distribution.

3) I think: "I like that" and install it in my Zope 3.

4) I think: "Hmm, I'd also like to track the "Trip" where a photo was 
taken."  I create PaulPhoto *based on* ShanePhoto, using a web 
interface, never seeing Python.

Not inheritance, but inheritance.

>> 2. Create properties in Content Object.
> 
> 
> These are most simply done in a Python module.


>> 3. Create methods in Content Object.
> 
> 
> Ditto
> 
>> 4. Define security.
> 
> 
> You'll be able to do that with content configuration in a way that's
> *much* simpler than ZClasses.
> 
>> 5. Register the Content Object.
> 
> 
> Yes, this too will be much cleaner than with ZClasses.
> 
>> A more Zope3ish way would be to define the interface doing step 1-3 
>> and then autogenerate the Content Object skeleton. 
> 
> 
> We could certainly provide a tool like this.  Steve and Martijn
> are working on a system for generating content types from schema.
> 
> Their system generates Python modules that implement the schema.

Can't wait!

--Paul