[Zope] Zope support through the community: sorting

[Dieter Maurer]

Brian Lloyd writes:
 > > There seems to be danger that this great support through a community
 > > member will have a fate similar to Tino's "in" patch:
 > > 
 > >   that the incorporation into the Zope core is far too long
 > >   delayed because important DC people fear "feature bloat".
 > 
 > It is not "feature bloat" in this case that is the main issue, 
 > it is (as stated in my comments in the proposal) the complexity 
 > this adds.
But the added complexity is really small: about 10 to 15 lines
of description:

   Instead of "sort=col,col,col,..."
   you now have "sort=colsort,colsort,colsort,..."
   with "colsort" either

     * col
     * col/compare
     * col/compare/direction

 > Please understand that we are sometimes put in a 
 > difficult position - we get beaten up all the time about "zope 
 > being too complex", then get beaten up by other folks when we 
 > question a feature because we don't want to add to the 
 > complexity :)
I think, I have addressed this in a proposal comment:

 * high level sort support adds (a bit of) complexity

 * if you need advanced sorting (and already case-insensitve sort
   is currently advanced!) then, without high level sort support,
   you need a very complex solution (in Python).

 * many Zope users need better sort support - e.g. case insensitive
   sort (--> mailing list archives), locale aware sorts (--> users
   in South America, Europe, Asia).

   They either are/get advanced Python programmers or feel that
   Zope is far too complex, because simple things are not
   easy to get.

Accepting the patch will not increase but decrease the complexity
for all people that need better sort support. I think this
is the majority.

 > ....
 > > DM:
 > >   In my view
 > >   
 > >     * bug fixing patches should always be accepted
 > >       unless the patch is not easily understandable.
 > > 
 > >     * feature patches should be accepted, if it
 > >       makes Zope more consistent (as
 > >       the upcoming "urlparam_expr" patch)
 > >       or easier to use (as Oleg's sorting patch
 > >       or Tino's in patch).
 > > 
 > >   Great reluctance towards these contributions risks Zope
 > >   to lose community support.
 > BL:
 > I agree with the first point, and it is generally true though 
 > there is often currently too much lag time. There will be 
 > good news forthcoming that will help that significantly soon.
 > 
 > The second point is subjective - what is "more consistent" to 
 > one is sometimes "more inscrutible" to others.
Yes, sometimes. But often, it should be easy to come to an
agreement.

For example:
  Zope DTML attributes often come in two variants:
  "branches/branches_expr", "type/type_expr", "sort/sort_expr",....
  It has a reason that this is so...
  Sometimes, only a single attribute is there. This can
  have two reasons: the second one is not needed
  or it was forgotten or not implemented due to resource
  shortage at the time of implementation.
  Now, people stumble against that lack (me, for example
  against the missing "urlparam_expr").
  They may say, hay, I could help to make Zope better
  (I did not, in this case, but used a cookie - with a comment
  about the badly designed "urlparam" in the source of my code)
  and file a patch into the Collector.
  It should not be difficult to see that Zope gets more consistent
  with such a  patch.

  I think, it should be easy, too, for Oleg's patch:
  The usefulness/complexity ratio is extremely good.
  Nevertheless, I expected it would make problems
  and adviced him to make his features alvailable in
  an easy to use external method such that the Zope
  community is less dependent on DC in this respect.

 > BL:
 > The whole point 
 > of the Fishbowl is to help us all come to smart decisions and 
 > reasonable compromises on such things.
In my view, the Fishbowl should be used only for big things.

  I can understand, that projects like Tino's patch or
  "Administration and Configuration" go through the Fishbowl.
  Everything, that has either big impact or requires extensive
  resources with DC.

  I would be seriously concerned, if there would be
  an "urlparam_expr" project in the Fishbowl before
  this patch could be accepted.

  I would also not have expected a Fishbowl project for
  Oleg's patch. The patch is local, finished.
  Everything DC needs to do is apply it (I know, this is
  already done in CVS) and add
  a dozen lines in the Online Help and the Zope book.
  The resource consumption with the Fishbowl project
  is one to two orders of magnitude larger than this.

 > > DM:
 > >     I still advice people to file bug reports and patches into
 > >     the Collector, but personnaly I already start to think
 > >     whether it is worth the effort....
 > 
 > BL:
 > It is worth the effort.
 > ....  resource shortage to sweep the Collector ....
 >
 > That will be changing.
Good!

I will be (a bit) patient.

 > ....


Dieter