[Zope3-dev] Zope3 comments and questions.
Jim Fulton
jim@zope.com
Tue, 11 Dec 2001 11:02:29 -0500
Here's a different suggestion.
Let's recommend that people provide a ZopeProducts
directory somewhere in their path.
I'll take the name simplification out of the tutorial
and we can see then if we feel that simplification is needed.
I suspect we will, but I'm willing to see how the
tutorial works without the simplification.
Jim
Jim Fulton wrote:
>
> Lennart Regebro wrote:
> >
> > This is the comments and questions I have after going through the
> > PythonProgrammerTutorial/Chapter1. Excellent tutorial by the way, and Zope3
> > looks and feels mostly excellent too!
> >
> > 1. Zope.Products.foo.foo.foo = .foo
> > Having "smarts" that remove an amount of typing can make things more
> > confusing. Saying not having to specify Zope.Products is good, but not
> > specifying repeating elements is a bit too much magic. A new user will have
> > trouble understanding why ".Contact" works but ".People" doesn't, when they
> > are both specified in the same module, or both modules in the same
> > directory, since you mostly learn what to do and how to write things by
> > mimicking others, instead of RTFT as you should.
> >
> > "Smarts" should be rather obvious. Like that you don't have to care if a
> > form used POST or GET. That a dot in the beginning may expand to three
> > repeats is not that obvious.
>
> I came up with this scheme based on feedback that it was too cumbersome
> to do configuration and that this was exacerbated by long names. I also
> find the common repeats I encounter to be annoying, as I think
> others do.
>
> Also, In many cases, I, as a programmer really would like to hide
> some of the internal package structure that the repeated names
> expose.
>
> How's this for a compromise and hopefully a clarification. We don't
> repeat by default. If the name ends in a dot, we repeat the last name
> as many tmes as we need until we find an object that isn't a module.
> Then we'd have ".foo.". The dots on either end indicate that the name
> is being extended.
>
> > 2. Clearer structure
> > lib/python/Zope/Products is not the most place to put a product for
> > newbies. It's no problem having products that are a part of the Zope
> > distribution there, but new additional products, both downloaded and
> > self-developed, should probably go into a Products folder in the root
> > installation. That will make it MUCH easier for Zope newbies to
> > understand whats going on.
>
> I don't see how this really impacts understandability. Some general
> comments:
>
> - We want to get away from adding a lot of names to the Python path.
> This makes integration with other things harder. One way to avoid this
> would be to add a ZopeProducts, which is less likely to conflict with
> other modules.
>
> - We probably will enourage people not to put custom products in the
> Zope software area. Of course, this is consistent with your suggestion. :)
>
> - It really doesn't matter where people put their software as Zope will
> no longer automatically configure products (except for legacy products).
> Configuration is done by configuration file. Configuration files can point
> anywhere. Of course, it does affect the meaning of the leading dot.
>
> Let me think about this.
>
> > 3. Protection of interfaces.
> > I dont understand why extended interfaces can't be protected (step 4):
> > "Note that we protect the 'update' method by name, rather than by
> > interface. We can't protect the 'IContactEdit' interface because
> > 'IContactEdit' extends 'IContactInfo', which is protected by a
> > different permission."
>
> We can't use different protection for the extended interface and the
> interface it extends as that would lead to inconsistent assertions.
> IContactEdit includes all the methods of IContactInfo. If we say that
> IContactEdit is protected by ManageContacts, then we're saying that,
> for exampe, the email method is protected by ManageContacts, but
> we also say that email is protected by View. We can't have it both ways.
>
> > 4. Assertions in the interface definitions
> > Why assert in the interface definition in the Tutorial? It's not intuitive
> > to me. Shouldn't the class specify the interface it implements with
> > __implements__ ?
>
> It depends. If you don't have the ability to change the class, for example
> if you got the class from someone else, then making the assertion in the
> interface is better.
>
> > 5. container vs here
> > How come the edit presentation uses "container" where the view
> > presentation uses "here"?
>
> That's a bug. They should both use 'here'.
>
> > 6. Marker interfaces
> > Why create "marker interfaces?
>
> Interfaces can be used for classification. A marker
> interface classifies all the objects that implement it
> together.
>
> > Couldn't you just specify the class directly
> > instead of creating and essentially empty and rather useless interface?
>
> No, for two reasons:
>
> - A class is not an interface. :)
>
> - We might concievably want to mark multiple classes
> with the same marker interface. Marker interfaces keep
> that option open while allowing us to be more specific
> is we want to.
>
> > "The tabs are defined using a new 'IContact' interface, defined in
> > the 'IContact' module. This is a "marker" interface. It doesn't
> > actually specify any contacts but provides a way of very
> > specifically tagging certain classes (usually one). We do this for
> > tabs because we usually want very specific control over the tabs
> > that a content object displays."
>
> It might be cleaner if IContact extended all the other interfaces.
> This is an area that probably needs more refinement.
>
> > So, now I'm ready to start trying to make my first Zope3 product I guess.
> > Any suggestions?
> > I was thinking about redoing my EasyImage object, since I'm familiar with
> > that code...
>
> Cool. I suggest you wait a little longer, both to let us put some
> more infrastructure in place and to let the dust settle from the many
> good suggestions.
>
> Jim
>
> --
> Jim Fulton mailto:jim@zope.com Python Powered!
> CTO (888) 344-4332 http://www.python.org
> Zope Corporation http://www.zope.com http://www.zope.org
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (888) 344-4332 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org