Lennart Regebro wrote:
> I don't think it's about saving lines, but about saving headaches. ;-)

Having to remember how all of the mentioned directives work *does* give me a
headache. I actually remember quite well how the utility and interface
directives work and they are the replacement for most of the directives to be
deprecated. I assume most people are like me in that respect, at least that's
the assumption this proposal is based on.

> > > I think that goal is misguided, as
> > > it would require you to make longet ZCML files with more basic
> > > statements. This in  turns means you need to understand more of what
> > > you are actually doing.
> >
> > Well, how much longer would the ZCML files really be?
> The point is that it requires you to understand more of the internals
> of Zope3, making it even harder to use and understand. Which is
> exactly the opposite of what people who try to use Zope 3 say they
> want.

What internals? That a factory is a utility? Well, people have to know that
anyways when they want to look-up a factory. Sorry for nailing it down to that
specific example again, I could say the same about vocabularies or whatever it
is those directives are about.

> And when it comes to step by step, I think we should think about the
> big/basic stuff first, becuase that's what will cause problems if we
> do it.

Then you do it :). I volunteered for this task and I have to do it as I have
time thinking about stuff. Right now I don't have much time but I still want
to get somewhere. If that approach isn't in-line with the community, then I
can't contribute at this point.

That aside, I think even though this is just the beginning it'll make a big
difference. Since I started documenting Zope 3 on a professional basis, I look
at everything with "And how will I explain this to my reader?" in the back of
my mind... When this proposal is through, I can simplify *a lot* in my book.

> Depracating specific statements is comparatively a no-brainer.

Good. I guess then we can drop this discussion and just do it :).

> > The adapter statement is still necessary as an on/off switch. Who says
> > that you
> > always want that adapter? And perhaps you want to override it with a
> > different
> > one. ZCML is good for on/off switches, Python isn't.
> That's a good point. But maybe then it should be made into an
> on-off-switch, instead of a defining switch?

Perhaps. This isn't the scope of my proposal though :).

> > I hope zope.app will go away :). Seriously, I rather have meaningful
> > interfaces
> > with which I register *and* look-up stuff the same way than registering
> > something with a factory directive and looking it up by IFactory. I see no
> > connection obvious connection there. And you will have to remember the
> > interface anyway, whether you use <factory /> or not...
> As noted, I don't have any quarrel with removing the factory
> statement. In fact, I think it is highly obscure, and personally, I
> don't understand what you are supposed to do with it, which is a bad
> indication.


> If you want +/- per statement, then I'm minus on removing
> browser:addform,

This isn't part of the actual proposal but just some random thought. However,
there will be a proposal in the future that'll deal with the form stuff, and
if it's only about getting rid of zope.app.form ;).

> and I'm unsure about the vocabulary statements. (But
> I actually want to get rid och schemas altogether, I think they are
> complicated to use and understand and not good enough, and should be
> replaced with something based on XForms. ).
> The others I'm either +1 on, or don't know anything about.

Great :).

Thanks for your input!


This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to