[Zope3-dev] zc.table and zc.resourcelibrary feedback

[Gary Poster]

On Mar 13, 2006, at 10:59 AM, Martijn Faassen wrote:
[...]

Thanks for looking into this Martijn.  We have some internal versions  
of a sortable zc.table factory that take a different approach, and  
are not using the client-side part of the zc.table code much at all.   
If you're willing to look at it and consider integrating it into  
zc.table, one of us will send you the files privately.  You up for that?

BTW, I think I listed in the release announcement that both of these  
packages could use some TLC.  Thank you generally for considering  
giving them some!

I would love to see resourcelibrary developed in these directions, fwiw:

- pluggable insertion, to address one of the concerns in your  
original message.  I don't remember exactly what Benji and I talked  
about.  Maybe the resources would not be snippets but callable  
transformations.  Maybe we could provide a factory for one kind of  
transformation which could be combined to effectively get the same  
behavior as our current transformation?  A piece of code could  
request a transformation, which might depend on other  
transformations?  Maybe this is too general.

- order-aware dependency insertion: IIRC, the algorithm for gathering  
the necessary dependencies doesn't honor order, which may be a  
problem in some cases.  order-aware could get fragile, though--for  
instance, if one resource says it depends on A and then B, and  
another says it wants B then A, what to do?  Maybe it's necessary to  
have one spelling for order-unaware dependencies, and another for  
order-aware dependencies; maybe that itself is insufficient...

- lighter-weight insertion into the publishing framework.  No one  
(including myself) has followed up materially on Jim's old discussion  
of in-Zope publication pipelines.  The request approach is heavy, and  
maybe a WSGI pipeline element is too heavy also.  It would be nice to  
resolve this, though: replacing the request factory is a bit crazy.

It's not a priority for us to work on these things right now, but we  
open-sourced some of the less-polished packages in hopes that others  
would see their possibilities, as you did, and be intrigued. ;-)

Gary