Re: [Zope-dev] Comments on ZPatterns
Ty Sarna wrote:
>
> In article <[EMAIL PROTECTED]>,
> Chris Withers <[EMAIL PROTECTED]> wrote:
> > 1. Too much jargon... by far... Lots of complicated words that are
> > meanlingless to the layman and don't help to convey the concepts. This
>
> Can you point out some examples of which ones you think are especially bad?
Just everything in general... ;-)
The Glossary Wiki I mentioned would help lots...
...also, can you send the list a copy of your recommended books in this
area?
> Naming has been a struggle. It's hard to come up with descriptive names
> for these things. Part of the confusion is that some things have been
> renamed in an effort to make the meanings clearer in the long term. But
> short term, it's confusing and it seems like there are lots of new
> concepts, when in fact there are just several names for the same concept
> (Implementor -> Specialist, Rack-mountable -> DataSkin, etc).
I know, hence the glossary suggestion :-)
> I'll also
> admit that Rack-mountable was a clearer name, but it was no longer
> accurate. We tend to err on the side of a name that doesn't clearly
> describe something instead of a name that clearly describes something,
> but describes it *wrong* so that you think you understand something and
> really don't. ("Well, at least the name tells you that you don't know
> what it is!", as I've said :-)
Fair enough, but then they really need to be explained for us mortals...
> You mention in another post that you feel lots of unnecessary features
> have been added -- can you give some examples of which ones you feel are
> extraneous?
Probably me just misreadign the new terms popping up all the time :-)
> There has been only one major feature added in ZPatterns
> 0.4.0, which is the ability to have Rack-mountable-like things that
> don't live in racks. This is important for PTK-like applications where
> you don't want to lump everything into one container, but would instead
> like to have it distributed between member's folders, for example. I
> think it was worth it.
So do I, I just didn't understand it ;-)
> The PlugIns stuff is indeed separate, and is not really a part of
> ZPatterns as much as it's stuff that we wrote to make ZPatterns and
> other Zope products easier to write.
Maybe split it into a seperate product then? It might make learning
ZPatterns easier since this area won't get dragged into it...
> You can pretty much ignore it if
> you won't be writing python products or working in ZPatterns internals.
I will on the first count, hence the interest. Squishdot PTK is looming
ever closer now...
> 0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they
> *are* alphas, after all. You were warned :^)
Any idea on a beta or final release schedule?
> What, you want something that's *not* based on any theory, just random
> ideas? :^)
No, but maybe the percieved pretentiousness upsets some people?
> As someone who used Zope for quite a while before it was
> even called that, and spent much time banging my head against the wall,
> I'm guessing I have a pretty good idea of how you feel. I've gained a
> new sympathy for DC.
heh ;-)
> and it's hard to find time right now to work on things in
> ZPatterns that don't directly affect our paid work. (Much the same
> situation DC is in a lot of the time, I suspect).
Maybe try and leverage the community liek DC too? How about a ZPatterns
fishbowl? *grin*
> So, in summary, please bear with us.
...will do, keep up the great work, we may bitch now but will probably
aprpeciate it in the long run :-)
cheers,
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Comments on ZPatterns
In article <[EMAIL PROTECTED]>,
Chris Withers <[EMAIL PROTECTED]> wrote:
> 1. Too much jargon... by far... Lots of complicated words that are
> meanlingless to the layman and don't help to convey the concepts. This
Can you point out some examples of which ones you think are especially bad?
> is compounded by the standard Zope problem of minimal documentation
> aimed at the advanced developer. Can someone who understadns this all
> take the time to write a ZPatterns guide to compliment the Wiki and
> maybe simplify or explain in great detail all the terms (especially the
> new ones that have popped up in the last few weeks)?
Naming has been a struggle. It's hard to come up with descriptive names
for these things. Part of the confusion is that some things have been
renamed in an effort to make the meanings clearer in the long term. But
short term, it's confusing and it seems like there are lots of new
concepts, when in fact there are just several names for the same concept
(Implementor -> Specialist, Rack-mountable -> DataSkin, etc). I'll also
admit that Rack-mountable was a clearer name, but it was no longer
accurate. We tend to err on the side of a name that doesn't clearly
describe something instead of a name that clearly describes something,
but describes it *wrong* so that you think you understand something and
really don't. ("Well, at least the name tells you that you don't know
what it is!", as I've said :-)
> 2. Feature runaway. It seems every day something new (and more
> confusing) has been added to ZPatterns. I think ZPatterns will only work
> if it is kept as simple and functional as possible. My view (bearing in
You mention in another post that you feel lots of unnecessary features
have been added -- can you give some examples of which ones you feel are
extraneous? There has been only one major feature added in ZPatterns
0.4.0, which is the ability to have Rack-mountable-like things that
don't live in racks. This is important for PTK-like applications where
you don't want to lump everything into one container, but would instead
like to have it distributed between member's folders, for example. I
think it was worth it.
Part of the percieved feature runnaway I think is due to the renaming
issue described above. Also, a lot of what looks like adding of
features is actually reorganization and simplification of features that
were already there. There's no need now for SQL Racks vs. LDAP Racks
vs. ZODB Racks, for example. New features were added, but mainly to
avoid the need for other features to even exist. In a lot of ways, the
code keeps getting simpler and shrinking (as an example, look at the
early LoginManager releases vs what's there now -- the code shrank
considerably and got much clearer!)
Future versions will follow this trend. For example, we're probably
going to introduce a simple language to replace Generic Attribute
Providers, Generic Triggers, and such. This actually will end up
eliminating stuff from ZPatterns and making it clearer, as there will be
less types of objects. It should also help the "I have to visit 4
different menus to set up one simple thing" problem. It will keep more
of the configuration together so you can see exactly what is going on.
I think it will be easier to explain and document as well.
> mind my limited understanding ;-) would be to concentrate on Containers,
> Container Groups and Plugins on the one front and Racks, Specialists and
> the various providers and agents on the other.
The PlugIns stuff is indeed separate, and is not really a part of
ZPatterns as much as it's stuff that we wrote to make ZPatterns and
other Zope products easier to write. You can pretty much ignore it if
you won't be writing python products or working in ZPatterns internals.
> PS: The main reason I'm writing this is because I think ZPatterns are
> very very cool but may well get ignored because no-one understands them
> and they're too buggy and complicated to get working :/
0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they
*are* alphas, after all. You were warned :^)
>From the unattributed mail you posted from someone else:
> > P.S. ABout ZPatterns: everyone I spoke to was thought the basic idea
> > behind ZPattern was good and sound and nice and so on. But _everyone_
> > complained about it being too pretentious (with all the computer science
> > claims and theory behind it)
What, you want something that's *not* based on any theory, just random
ideas? :^)
> > and introducing too many unnecessary new
> > concepts (racks, specialist and what have you). All this is very
Racks and Specialists are key concepts. Saying that they're unecessary
and should be eliminated is like saying OO programming would be simpler
if they got rid of all the extra ideas like classes and objects. Probably
so, but what would be left???
ZPatterns is new, and it can be confusing, and there is not enough good
documentation (or working examples -- I'm
[Zope-dev] Comments on ZPatterns
> > "Phillip J. Eby" wrote: > > > At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote: > > > >I believe I have come to understand the basics of ZPatterns and would > > > >like to be sure I understand correctly, as well as help others > > > >understand also. Feel free to flame me if I've got this wrong, but: I've read all the ZPatterns Wiki and I'm just taking tentative steps to playing with LoginManager. I think the concepts are very cool but I see two problems: 1. Too much jargon... by far... Lots of complicated words that are meanlingless to the layman and don't help to convey the concepts. This is compounded by the standard Zope problem of minimal documentation aimed at the advanced developer. Can someone who understadns this all take the time to write a ZPatterns guide to compliment the Wiki and maybe simplify or explain in great detail all the terms (especially the new ones that have popped up in the last few weeks)? 2. Feature runaway. It seems every day something new (and more confusing) has been added to ZPatterns. I think ZPatterns will only work if it is kept as simple and functional as possible. My view (bearing in mind my limited understanding ;-) would be to concentrate on Containers, Container Groups and Plugins on the one front and Racks, Specialists and the various providers and agents on the other. Comments always welcome, cheers, Chris PS: The main reason I'm writing this is because I think ZPatterns are very very cool but may well get ignored because no-one understands them and they're too buggy and complicated to get working :/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
