[Zope-dev] ZTK community packages

[Christophe Combelles]

Hanno Schlichting a écrit :
> Hi.
> 
> On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles <ccomb at free.fr> wrote:
>> I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet (and
>> many others) are among the most important packages. I wonder why they are not
>> included in the ZTK? I always end up using them, I believe they should even be
>> part of the core ZTK.
> 
> We have written down some definition of what constitues a core library
> at http://docs.zope.org/zopetoolkit/about/coreextra.html. That
> document is outdated to some degree, and likely the "steering group"
> should now be replaced by the "release team".

I understand the principle of "extra" packages. They are not part of the core, 
but they use the core, and they may be part of the core in the future.
That's a good thing, but looking at the zopetoolkit package, there is no such 
list yet. I really think we should track such packages in an "extra.cfg" file.

I think it has some advantages for everyone:

For the extra packages:

- they can benefit from the buildbot infrastructure
- it increases their visibility
- it encourages their maintainers to support and release new versions
- they can more easily find a place in the large version set of all packages

For the core:

- it gives an easy access to many more third-party tests that can help find bugs 
in the ztk core or improve it.
- it helps selecting future candidates for inclusion in the core

> 
> Nevertheless the criteria given in that document are still sensible in
> my opinion. z3c.form might at some point become part of the ZTK. But
> right now none of the major projects includes it in its core. The

Regarding z3c.form, it will be at least part of Plone, via the Dexterity content 
type library. And I suppose that many zope 3 projects are using it.


> other z3c libraries you mention, I have never heard of or wouldn't
> know what they did. They sound to me related to a specific way of
> constructing user interface related code. I think there's many
> different approaches to that and only very few can claim to be used by
> multiple of the major projects.

z3c.pagelet is the best way I've seen to create really redistributable browser 
page templates, because they are not linked to any macro or master template. 
They basically are both browser pages and content providers, and they can choose 
themselves their content template and layout template from bottom up. Among 
other advantages, they benefit from the 2-way update/render pattern of the 
content providers or viewlets.

z3c.macro is an easy way to register macros in zcml, then use it with 
use-macro="macro:somemacro" without the burden of creating a view dedicated to 
macro retrieval.

z3c.template can make content templates and layout templates context-dependent. 
They are registered separately from the views.

Not mentionning z3c.formjs, which is a good jquery-based library on top of 
z3c.form to create javascript-enabled forms.

> 
>> If they are not part of the core, I would like them to be part of a
>> *community.cfg* list. There already is a community.cfg list in BlueBream, but I
>> don't like having many foobartoolkit in the wild, with many package lists to
>> maintain. It's already difficult enough to maintain just 1 list for the
>> zopetoolkit. Let's focus on it.
> 
> What you are describing is similar to the idea of the "extra" concept
> we have defined for the ZTK. It has at this stage no manifestation in
> any code, version list or process around it.

Ah ok, if this is already defined, but just missing an implementation, I will 
help with implementing it.

> 
> At this stage I would prefer to focus on the ZTK as a
> least-common-denominator of the major projects. And only if we are
> actually able to agree on such a set, should we try to extend it. This
> is going to be hard enough and extending the set of packages won't
> make it any easier.

Sure, it should not block or even delay the ZTK release. We can even release a 
ZTK with failing tests on the extra packages. I'm confident that these failures 
will be fixed much quicker in they are visible to everyone ;)

Christophe

> 
> That doesn't mean you shouldn't go forward with your idea. I just like
> to have it separate from the ZTK.
> 
> Hanno
> 
>