Mailing List Archive: Zope: CMF

IndexableObjectWrapper

1 2 3

View All

Index | Next | Previous | View Threaded

miles at jamkit

Mar 9, 2009, 12:21 PM

Post #1 of 60 (2273 views)
Permalink

IndexableObjectWrapper

Hi,

Can anyone tell me if it is possible to register an adapter to provide a
different IndexableObjectWrapper class from the stock CMF one? There's
some sort of framework code that hints that it ought to enable this, but
I can't see how!

The code still seems to instantiate the wrapper directly using the
class, rather than looking it up via the component architecture.

Can anyone explain what's going on? I've drawn a blank from googling
for examples.

Thanks,

Miles

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 9, 2009, 2:28 PM

Post #2 of 60 (2195 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 9, 2009, at 21:09 , Miles wrote:

> Can anyone tell me if it is possible to register an adapter to
> provide a
> different IndexableObjectWrapper class from the stock CMF one?
> There's
> some sort of framework code that hints that it ought to enable this,
> but
> I can't see how!
>
> The code still seems to instantiate the wrapper directly using the
> class, rather than looking it up via the component architecture.
>
> Can anyone explain what's going on? I've drawn a blank from googling
> for examples.

You already noticed that the wrapper is instantiated directly, so
that's what's going on. No magic, no component architecture.

Whether that is good or bad or should be changed is a different issue.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm1igUACgkQRAx5nvEhZLLXDgCgkfCiB2OLW/G2LxT1JVBOtGJJ
b3gAniLMUd22poUykxudnvXA5ibaK2hO
=GZpO
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 9, 2009, 2:47 PM

Post #3 of 60 (2198 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Previously Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Mar 9, 2009, at 21:09 , Miles wrote:
>
> > Can anyone tell me if it is possible to register an adapter to
> > provide a
> > different IndexableObjectWrapper class from the stock CMF one?
> > There's
> > some sort of framework code that hints that it ought to enable this,
> > but
> > I can't see how!
> >
> > The code still seems to instantiate the wrapper directly using the
> > class, rather than looking it up via the component architecture.
> >
> > Can anyone explain what's going on? I've drawn a blank from googling
> > for examples.
>
> You already noticed that the wrapper is instantiated directly, so
> that's what's going on. No magic, no component architecture.
>
> Whether that is good or bad or should be changed is a different issue.

Martin Aspeli implemented an adapter based index wrapper for Plone 3.3.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 9, 2009, 3:15 PM

Post #4 of 60 (2197 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 9, 2009, at 22:47 , Wichert Akkerman wrote:

> Previously Jens Vagelpohl wrote:
>> On Mar 9, 2009, at 21:09 , Miles wrote:
>>
>>> Can anyone tell me if it is possible to register an adapter to
>>> provide a
>>> different IndexableObjectWrapper class from the stock CMF one?
>>>
>> You already noticed that the wrapper is instantiated directly, so
>> that's what's going on. No magic, no component architecture.
>>
>> Whether that is good or bad or should be changed is a different
>> issue.
>
> Martin Aspeli implemented an adapter based index wrapper for Plone
> 3.3.

It's nice to see that Plone has it, but that doesn't help anyone
working off the CMF itself. I wish there was more communication to
determine where improvements fit best. Not knowing how Plone
implemented it I would make a guess this one small item would have
been better off in the CMF itself.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm1lR8ACgkQRAx5nvEhZLJJvQCgnWpvHGu9TUCWOI5kmOzhRWAv
X8kAnAvVgxARYBlafyTF9FbosZZgO2Nn
=b1rx
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 9, 2009, 3:38 PM

Post #5 of 60 (2192 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Previously Jens Vagelpohl wrote:
> It's nice to see that Plone has it, but that doesn't help anyone
> working off the CMF itself. I wish there was more communication to
> determine where improvements fit best. Not knowing how Plone
> implemented it I would make a guess this one small item would have
> been better off in the CMF itself.

It is an extension of the ExtensibleIndexableObjectWrapper Plone has had
for a long time, so I can't blame Martin for doing the work in Plone
instead of CMF.

The proposal can be found here in the Plone roadmap at
http://plone.org/products/plone/roadmap/239 , and the review buildout
is located at http://svn.plone.org/svn/plone/review/plip239-indexer/

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude+lists at gmail

Mar 9, 2009, 7:28 PM

Post #6 of 60 (2193 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Miles wrote:
> Hi,
>
> Can anyone tell me if it is possible to register an adapter to provide a
> different IndexableObjectWrapper class from the stock CMF one? There's
> some sort of framework code that hints that it ought to enable this, but
> I can't see how!
>
> The code still seems to instantiate the wrapper directly using the
> class, rather than looking it up via the component architecture.
>
> Can anyone explain what's going on? I've drawn a blank from googling
> for examples.

In plain CMF, probably not. In Plone, we have a custom CatalogTool which
does let you provide a new wrapper wholesale based on object type.

In Plone 3.3, we'll *also* have a means of providing individual
*attributes* of the wrapper via adapters. See
http://pypi.python.org/pypi/plone.indexer. This package should work with
stock CMF (though you'll need to wire it into the catalog tool yourself).

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude+lists at gmail

Mar 9, 2009, 7:33 PM

Post #7 of 60 (2192 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Mar 9, 2009, at 22:47 , Wichert Akkerman wrote:
>
>> Previously Jens Vagelpohl wrote:
>>> On Mar 9, 2009, at 21:09 , Miles wrote:
>>>
>>>> Can anyone tell me if it is possible to register an adapter to
>>>> provide a
>>>> different IndexableObjectWrapper class from the stock CMF one?
>>>>
>>> You already noticed that the wrapper is instantiated directly, so
>>> that's what's going on. No magic, no component architecture.
>>>
>>> Whether that is good or bad or should be changed is a different
>>> issue.
>> Martin Aspeli implemented an adapter based index wrapper for Plone
>> 3.3.
>
> It's nice to see that Plone has it, but that doesn't help anyone
> working off the CMF itself. I wish there was more communication to
> determine where improvements fit best. Not knowing how Plone
> implemented it I would make a guess this one small item would have
> been better off in the CMF itself.

Point taken!

Back in the day (before Plone 3.0), Alec Mitchell and I implemented a
simple wrapper adapter that lets you look up a different version of the
IndexableObjectWrapper. However, this wasn't terribly useful, because it
seems what people want is not to replace the wrapper wholesale, but to
provide different 'indexers' for specific catalogued attributes on a
per-type basis.

Even before that, Plone had its own ExtensibleIndexableObjectWrapper
that let you add 'getters' for attributes on the wrapper via module
level imports. This has worked well, except that there's no way to make
particular indexers work only on one particular content type.

In Plone 3.3, with the plone.indexer package, we've changed this so that
you can add new 'getters' to the standard IOW via adapters. This is in
the plone.indexer package: http://pypi.python.org/pypi/plone.indexer

This should work with plain CMF and be simple to hook into the catalogue
tool. There are some discussions about licensing going on with the Plone
Foundation, but chances are good that it can be licensed in such a way
that CMF could adopt it you want. Doing so should be simple, even, and
I'd be willing to help make this happen.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 10, 2009, 12:38 AM

Post #8 of 60 (2194 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 10, 2009, at 03:33 , Martin Aspeli wrote:

> There are some discussions about licensing going on with the Plone
> Foundation, but chances are good that it can be licensed in such a way
> that CMF could adopt it you want.

IMHO the licensing issue is of general interest beyond this one
software bit. If there are any changes to Plone licensing I'm sure
people on this list would be happy if you or someone else could
provide some summary, if and when something is being changed :-)

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1
H90AoIEzoTI2kkYlTq/dX483KZFsFBnc
=8P7y
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

r.ritz at biologie

Mar 10, 2009, 1:14 AM

Post #9 of 60 (2193 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Jens Vagelpohl wrote:
>

Hi Jens,

> IMHO the licensing issue is of general interest beyond this one
> software bit. If there are any changes to Plone licensing I'm sure
> people on this list would be happy if you or someone else could
> provide some summary, if and when something is being changed :-)
>

Some people including Wichert and Martin are pushing the Plone
foundation to allow for an alternative license for Plone packages
that are more of a underlying "framework/library nature" on
request.

As I see it, chances are good that we'll see this changing within
the next few month even. At the moment, the discussion is about
whether we (the Plone foundation) should generally allow one
or several alternative licenses (-> one seems to be the current
favorite) and whether this one (if so decided) should be
LGPL or BSD(-like).

If there would be a strong preference from the CMF community
here I'm sure this would be honored in our discussion.

Opinions anyone? (ideally including a reasoning beyond
"I want ZPL because that's what Zope itself uses") ;-)

Raphael

> jens
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1
> H90AoIEzoTI2kkYlTq/dX483KZFsFBnc
> =8P7y
> -----END PGP SIGNATURE-----
> _______________________________________________
> Zope-CMF maillist - Zope-CMF [at] lists
> http://mail.zope.org/mailman/listinfo/zope-cmf
>
> See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
>

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie at begeistert

Mar 10, 2009, 1:34 AM

Post #10 of 60 (2187 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Am 10.03.2009 um 09:14 schrieb Raphael Ritz:

> If there would be a strong preference from the CMF community
> here I'm sure this would be honored in our discussion.
>
> Opinions anyone? (ideally including a reasoning beyond
> "I want ZPL because that's what Zope itself uses") ;-)

Actually that is itself a very valid opinion - any company that is
interested in software licences prefers as few of them as possible. My
preference is always for a no-strings attached licence (ZPL, modifieid
BSD, Apache).

It's nice to hear that there is some discussion within Plone about
licensing.

If there is framework code in Plone that might be better placed lower
down the stack in CMF then the sooner the better. There is a heap of
stuff that could do with refactoring and reengineering along component
architecture principles. It is not a little ironic in an open source
context that the next release of Plone "requires" a new release of CMF
to which it itself has (hardly?) contributed. This may often be
unintentional as Plone developers write libraries for Plone unaware of
the problem of backwards licence incompatability - the wrapper for
z3c.forms springs to mind - but it is a problem just the same.

Concentrating on a content management framework for Zope as the basis
for Plone and other approaches is a good thing IMHO.

Charlie
--
Charlie Clark
Helmholtzstr. 20
D�sseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 10, 2009, 1:36 AM

Post #11 of 60 (2196 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 10, 2009, at 09:14 , Raphael Ritz wrote:

> Opinions anyone? (ideally including a reasoning beyond
> "I want ZPL because that's what Zope itself uses") ;-)

In general, commercial adoption of a software stack is made easier if
it is not accompanied by a whole soup of different licenses. The fewer
licenses, the better. I'm sure that issue is on your radar already.

As you know, all code you'd like pushed down the stack into the CMF or
Zope must be licensed under the ZPL. That's also a prerequisite for
being stored in the Zope Foundation repositories (a.k.a. svn.zope.org).

In the end I hope that whatever decision is being made does not serve
to widen the distance between the Plone community and the rest of the
Zope universe.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm2JqkACgkQRAx5nvEhZLJNMACeJvlVOK8y1hxx5dkyP1pmwP/M
fqAAoJXXclf5a7Gy0tDiAhH5db0oCJLU
=mIFf
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 10, 2009, 2:01 AM

Post #12 of 60 (2192 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Previously Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Mar 10, 2009, at 09:14 , Raphael Ritz wrote:
>
> > Opinions anyone? (ideally including a reasoning beyond
> > "I want ZPL because that's what Zope itself uses") ;-)
>
> In general, commercial adoption of a software stack is made easier if
> it is not accompanied by a whole soup of different licenses. The fewer
> licenses, the better. I'm sure that issue is on your radar already.

It is, which is why the ZPL has already been rejected as an option: it
is pretty much equivalent to the BSD license, which is much more widely
accepted. The ZPL is a Zope Foundation-only license, while one goal of
this push in Plone is to encourage wider adoption of generic components,
even outside of the Zope community where possible.

The debate is currently focusing on GPL versus BSD license. Any opinions
on a choice between those two would be very welcome.

> As you know, all code you'd like pushed down the stack into the CMF or
> Zope must be licensed under the ZPL. That's also a prerequisite for
> being stored in the Zope Foundation repositories (a.k.a. svn.zope.org).

I do not think the Plone Foundation board is willing to consider
donating some of its intellectual property to the Zope Foundation. I am
already happy they are willing to consider selective relicensing.

But that does not need to be a problem: reusable packages such as
plone.indexer can be used by CMF even if they are not covered by the ZPL
or managed in svn.zope.org, as long as there is the license is
acceptable.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 10, 2009, 2:01 AM

Post #13 of 60 (2191 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

charlie at begeistert

Mar 10, 2009, 2:17 AM

Post #14 of 60 (2193 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Am 10.03.2009 um 10:01 schrieb Wichert Akkerman:

> The debate is currently focusing on GPL versus BSD license. Any
> opinions
> on a choice between those two would be very welcome.

Speaking as someone who hasn't written a whole lot of code: BSD.

I have a real dislike of the GPL because I think it fails to emphasise
the real benefits of open source and it is a real pain if you wish to
integrate with other non-GPL stuff whether it's commercial or not. The
same discussion came up for Trac a few years ago because of the desire
for closer integration with subversion.

Charlie
--
Charlie Clark
Helmholtzstr. 20
D�sseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 10, 2009, 2:34 AM

Post #15 of 60 (2191 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote:

> Previously Jens Vagelpohl wrote:
>> In general, commercial adoption of a software stack is made easier if
>> it is not accompanied by a whole soup of different licenses. The
>> fewer
>> licenses, the better. I'm sure that issue is on your radar already.
>
> It is, which is why the ZPL has already been rejected as an option: it
> is pretty much equivalent to the BSD license, which is much more
> widely
> accepted.

If they are equivalent, why not dual-license?

> The debate is currently focusing on GPL versus BSD license. Any
> opinions
> on a choice between those two would be very welcome.

The discussion has been rehashed in several places, but given a choice
between pretty much anything and the GPL I'd vote "-1" on the GPL.

>> As you know, all code you'd like pushed down the stack into the CMF
>> or
>> Zope must be licensed under the ZPL. That's also a prerequisite for
>> being stored in the Zope Foundation repositories (a.k.a.
>> svn.zope.org).
>
> I do not think the Plone Foundation board is willing to consider
> donating some of its intellectual property to the Zope Foundation. I
> am
> already happy they are willing to consider selective relicensing.

To me this really sounds like the rift has widened, by a whole lot. It
reads like "we're happy to base our stuff on yours, but we really
don't want to give back". I'm sure it's not meant that way, but it
reads like that.

> But that does not need to be a problem: reusable packages such as
> plone.indexer can be used by CMF even if they are not covered by the
> ZPL
> or managed in svn.zope.org, as long as there is the license is
> acceptable.

That's not the issue I was trying to address. I was specifically
talking about putting functionality in the most appropriate part of
the stack, meaning moving it further towards the core. If there are
bits and pieces that make more sense in the CMF then saying "well,
just install our package" may satisfy users, but developers will
continue wasting time maintaining different implementations.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm2NA8ACgkQRAx5nvEhZLLy0wCfehi6WBVBHEcwJZXORFpM2tx4
aD4Anip87gouzSsnK/o4jI57ibOjt3YS
=dvw+
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 10, 2009, 2:49 AM

Post #16 of 60 (2191 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Previously Jens Vagelpohl wrote:
> On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote:
> > Previously Jens Vagelpohl wrote:
> >> In general, commercial adoption of a software stack is made easier if
> >> it is not accompanied by a whole soup of different licenses. The
> >> fewer
> >> licenses, the better. I'm sure that issue is on your radar already.
> >
> > It is, which is why the ZPL has already been rejected as an option: it
> > is pretty much equivalent to the BSD license, which is much more
> > widely
> > accepted.
>
> If they are equivalent, why not dual-license?

What would the advantage be? The ZPL is an exercise of license
proliferation and as far as I can see gives no benefits over BSD.

> > The debate is currently focusing on GPL versus BSD license. Any
> > opinions
> > on a choice between those two would be very welcome.
>
> The discussion has been rehashed in several places, but given a choice
> between pretty much anything and the GPL I'd vote "-1" on the GPL.

I made a typo there: the discussion is focusing on LGPL versus BSD. I
suspect that will not change your vote though :)

> >> As you know, all code you'd like pushed down the stack into the CMF
> >> or
> >> Zope must be licensed under the ZPL. That's also a prerequisite for
> >> being stored in the Zope Foundation repositories (a.k.a.
> >> svn.zope.org).
> >
> > I do not think the Plone Foundation board is willing to consider
> > donating some of its intellectual property to the Zope Foundation. I
> > am
> > already happy they are willing to consider selective relicensing.
>
> To me this really sounds like the rift has widened, by a whole lot. It
> reads like "we're happy to base our stuff on yours, but we really
> don't want to give back". I'm sure it's not meant that way, but it
> reads like that.

It is not that way at all. Plone does want to give back, and by
relicensing components does exactly that. If the BSD is chosen you can
do anything you want with that Plone code, except upload it to
svn.zope.org since that implies transferring ownership, which is not
allowed. This is no different than Zope policies: you can not
copy code from svn.zope.org to the plone repository either. Or move code
from Repoze to Zope, from Zope to FSF, etc. etc. The license is
not the limiting factor there, but the surrounding policies are.

> > But that does not need to be a problem: reusable packages such as
> > plone.indexer can be used by CMF even if they are not covered by the
> > ZPL
> > or managed in svn.zope.org, as long as there is the license is
> > acceptable.
>
> That's not the issue I was trying to address. I was specifically
> talking about putting functionality in the most appropriate part of
> the stack, meaning moving it further towards the core. If there are
> bits and pieces that make more sense in the CMF then saying "well,
> just install our package" may satisfy users, but developers will
> continue wasting time maintaining different implementations.

Why would there be multiple implementations if they can just use the
existing one? I do not see that. I do agree that work should be in in
CMF itself, and this particular instance of the indexable wrappers is an
excellent example of that. I hope that in the last few years we have
already demonstrated that we really do want to work closer with the
CMF and Zope communities.

Perhaps in the future the Plone Foundation would be willing to donate
code to the Zope Foundation. At this moment that is a bridge too far,
and I fear that as soon as I suggest that at this point in time the
entire relicensing movement will die in a never-ending debate. Lets
save that one for a later day.

Wichert.

--
Wichert Akkerman <wichert [at] wiggy> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

wichert at wiggy

Mar 10, 2009, 2:49 AM

Post #17 of 60 (2191 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

optilude+lists at gmail

Mar 10, 2009, 3:08 AM

Post #18 of 60 (2193 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Jens Vagelpohl wrote:

> That's not the issue I was trying to address. I was specifically
> talking about putting functionality in the most appropriate part of
> the stack, meaning moving it further towards the core. If there are
> bits and pieces that make more sense in the CMF then saying "well,
> just install our package" may satisfy users, but developers will
> continue wasting time maintaining different implementations.

I think we all agree on this. In retrospect, it would've been a better
idea to push for plone.indexer to be a part of CMF. However, I
implemented it driven by Plone's release cycle and feature proposal
process, which is why it ended up as it did. *I* want this feature for
Plone, but it'd be even better if others could benefit.

Of course, it's not too late for that. If the license issue can be
overcome (and I'm pretty sure that it will by April/May), then CMF can
depend on plone.indexer if it so wants, and I'm willing to help make
that possible if it means changing plone.indexer or helping with the CMF
level implementation.

In the future, it may be that we can meet in the middle on this. When
the PLIP process kicks off, it'd be good if the CMF developers had a
look in as well. We should probably be better at announcing the various
deadlines and proposals on this list, but if you guys see something that
you feel would be a good fit further down, it doesn't hurt to raise
that, lest the developer hasn't thought about it.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Mar 10, 2009, 3:20 AM

Post #19 of 60 (2190 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 10, 2009, at 11:08 , Martin Aspeli wrote:

> I think we all agree on this. In retrospect, it would've been a better
> idea to push for plone.indexer to be a part of CMF. However, I
> implemented it driven by Plone's release cycle and feature proposal
> process, which is why it ended up as it did. *I* want this feature for
> Plone, but it'd be even better if others could benefit.

IMHO the release cycle argument doesn't wash. We've always had CMF
releases in preparation for important Plone releases, and I'm happy to
continue that.

> Of course, it's not too late for that. If the license issue can be
> overcome (and I'm pretty sure that it will by April/May), then CMF can
> depend on plone.indexer if it so wants, and I'm willing to help make
> that possible if it means changing plone.indexer or helping with the
> CMF
> level implementation.

Thanks, I appreciate that.

Generally, I think now that the ZF has cleared up the remaining issues
about code ownership etc. we finally have two entities, the ZF and the
Plone Foundation, that are the perfect platform for "official" issues
like code donations, or for coordinating other cooperation issues. I
can't judge how the Plone Foundation acts within the Plone community,
but as far as the Zope Foundation goes, Martijn has been doing a lot
of work to make it more relevant and an important player in the actual
software development process.

> In the future, it may be that we can meet in the middle on this. When
> the PLIP process kicks off, it'd be good if the CMF developers had a
> look in as well. We should probably be better at announcing the
> various
> deadlines and proposals on this list, but if you guys see something
> that
> you feel would be a good fit further down, it doesn't hurt to raise
> that, lest the developer hasn't thought about it.

Is there any kind of low-traffic announcement list for things like
PLIPs? I'm not subscribed to any Plone list because of (for me at
least) signal to noise ratio fears.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkm2PwIACgkQRAx5nvEhZLJs8QCfYsGqkD63R9+isOhA0nXzeWy+
IgoAoJ8xfUzIMdGmlOSXUEreYgF7ErI+
=owJ7
-----END PGP SIGNATURE-----
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2009 at wcm-solutions

Mar 10, 2009, 4:17 AM

Post #20 of 60 (2198 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Hi!

Wichert Akkerman wrote:
> Previously Jens Vagelpohl wrote:
>> That's not the issue I was trying to address. I was specifically
>> talking about putting functionality in the most appropriate part of
>> the stack, meaning moving it further towards the core. If there are
>> bits and pieces that make more sense in the CMF then saying "well,
>> just install our package" may satisfy users, but developers will
>> continue wasting time maintaining different implementations.
>
> Why would there be multiple implementations if they can just use the
> existing one? I do not see that.

For the CMF project it is essential to have full control over its own
layer of the stack and to participate in the development of the Zope
layer. Using packages from the Plone repository means either using them
as a black box or joining the Plone Foundation to participate in their
development. IMO both options are not acceptable.

> I do agree that work should be in in
> CMF itself, and this particular instance of the indexable wrappers is an
> excellent example of that. I hope that in the last few years we have
> already demonstrated that we really do want to work closer with the
> CMF and Zope communities.

For technical reasons this collaboration is asymmetric. Plone is built
on top of Zope and CMF, not the other way round. If you want to work
really close with these communities, you have to be part of them and use
their repository.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2009 at wcm-solutions

Mar 10, 2009, 5:56 AM

Post #21 of 60 (2191 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Hi!

Miles wrote:
> Thanks for the clarification. The bits that confused me were:
>
> class IndexableObjectSpecification(ObjectSpecificationDescriptor)
> ...
>
> class IndexableObjectWrapper(object):
>
> implements(IIndexableObjectWrapper)
> __providedBy__ = IndexableObjectSpecification()
>
> What does this code actually achieve (I get the implements bit, obviously)?!

This makes the wrapper transparent, allowing the index to look up
adapters for the interfaces of the object. TextIndexNG3 works that way.

>> Whether that is good or bad or should be changed is a different issue.
>
> I will write up a short proposal.

AFAICS wrapping the object before looking up adapters is unnecessary.
The catalog should do the lookup directly and the existing features
provided by IndexableObjectWrapper should be reimplemented as adapters.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie at begeistert

Mar 10, 2009, 6:01 AM

Post #22 of 60 (2189 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Am 10.03.2009 um 10:49 schrieb Wichert Akkerman:

> Perhaps in the future the Plone Foundation would be willing to donate
> code to the Zope Foundation. At this moment that is a bridge too far,
> and I fear that as soon as I suggest that at this point in time the
> entire relicensing movement will die in a never-ending debate. Lets
> save that one for a later day.

I suspect you're right on that and that we on this list can all say
that, with hindsight, the licence debate should never have happened.
Let's hope it can be resolved in the future. I hope this will become
easier as development moves to a more library-based approach -- all
hail TurPlango!

What we cannot (dual-)license for the CMF but think we need for the
CMF we will have to reimplement. I have to agree with Jens that saying
something was added to Plone rather than the CMF because of the Plone
release cycle is disingenuous. As long as I have been following the
list the CMF releases have been timed for Plone. It would be good to
see this change from now on as I suspect the number of core developers
on both projects is limited and both projects would benefit from
effectively pooled resources and clear ideas of what goes where.

I also have to agree with Jens that the Plone mailing lists are way
too noisy.

Charlie
--
Charlie Clark
Helmholtzstr. 20
D�sseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude+lists at gmail

Mar 10, 2009, 6:16 AM

Post #23 of 60 (2187 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

yuppie wrote:
> Hi!
>
>
> Wichert Akkerman wrote:
>> Previously Jens Vagelpohl wrote:
>>> That's not the issue I was trying to address. I was specifically
>>> talking about putting functionality in the most appropriate part of
>>> the stack, meaning moving it further towards the core. If there are
>>> bits and pieces that make more sense in the CMF then saying "well,
>>> just install our package" may satisfy users, but developers will
>>> continue wasting time maintaining different implementations.
>> Why would there be multiple implementations if they can just use the
>> existing one? I do not see that.
>
> For the CMF project it is essential to have full control over its own
> layer of the stack and to participate in the development of the Zope
> layer. Using packages from the Plone repository means either using them
> as a black box or joining the Plone Foundation to participate in their
> development. IMO both options are not acceptable.

You don't need to join the Plone Foundation to develop packages in
svn.plone.org. You *do* need to sign a contributor agreement granting
some IP rights over that code to the Plone Foundation, in return for a
promise that it will always be available under an open source license.
There are no limits on who can sign that agreement or for what purpose
they choose to work with the code in that repository.

Of course, the same goes for svn.zope.org: you need to sign a document
and grant certain rights over your work to the Zope Foundation.

If CMF really cannot use packages not in svn.zope.org, then that's a bit
sad and will invariably lead to a lot of re-invention rather than
re-use. I don't really understand why it is "essential" to have this
level of control over every line of code you use. This is entirely a
self-imposed restriction.

>> I do agree that work should be in in
>> CMF itself, and this particular instance of the indexable wrappers is an
>> excellent example of that. I hope that in the last few years we have
>> already demonstrated that we really do want to work closer with the
>> CMF and Zope communities.
>
> For technical reasons this collaboration is asymmetric. Plone is built
> on top of Zope and CMF, not the other way round. If you want to work
> really close with these communities, you have to be part of them and use
> their repository.

I wrote a package that, I hope, is useful. I am pretty sure it'll work
with "plain CMF" and therefore with other consumers of the CMF, and if
doesn't, I'd consider that a bug and fix it. I'm willing to work to make
that package a part of the CMF platform, whether optional or fully
integrated.

To a certain extent, it already is: someone suing the CMF can choose to
use plone.indexer in their own project, though they'll need to install
it themselves. I don't quite see how this is asymmetric. Rather, it is
an outcome of the evolution of this particular package.

It's up to the CMF maintainers to decide whether it is desirable to
actually adopt this package as part of a standard release.

It's not always going to be appropriate (or even if it is, it's not
always going to be the case) for every new line of code that *could* be
useful to all/most CMF consumers to be built as part of the CMF itself
from the outset. If the CMF project has no model for incorporating code
from outside its (rather small) community, then I think that is more to
the detriment of CMF than to those who created those packages and chose
to put the effort in to reduce their dependencies and make them more
generally useful.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

miles at jamkit

Mar 10, 2009, 6:20 AM

Post #24 of 60 (2197 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Thanks!

> You already noticed that the wrapper is instantiated directly, so
> that's what's going on. No magic, no component architecture.

Thanks for the clarification. The bits that confused me were:

class IndexableObjectSpecification(ObjectSpecificationDescriptor)
...

class IndexableObjectWrapper(object):

implements(IIndexableObjectWrapper)
__providedBy__ = IndexableObjectSpecification()

What does this code actually achieve (I get the implements bit, obviously)?!

> Whether that is good or bad or should be changed is a different issue.

I will write up a short proposal.

Miles

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

miles at jamkit

Mar 10, 2009, 6:20 AM

Post #25 of 60 (2204 views)
Permalink

Re: IndexableObjectWrapper [In reply to]

Thanks

>>>>> Can anyone tell me if it is possible to register an adapter to

<snip>

> This should work with plain CMF and be simple to hook into the catalogue
> tool.

(For me) this is the root of the problem - it can only be hooked into
the catalog by subclassing at the moment, there is no other mechanism to
use different implementations. If there was, then plone.indexer (or
whatever) could be used directly.

Therefore, can I make a proposal (which I am happy to carry out), as I
think this is a desirable change?

PROPOSAL: Use CA to look up the indexable object wrapper

PROBLEM: It is not possible to provide alternative implementations of
the IndexableObjectWrapper class at the moment - this prevents
customising the indexing process.

SOLUTION: Look up the IndexableObjectWrapper using the Component
Architecture. The catalog tool will look up a named utility that
creates a wrapped object suitable for indexing.

The default implementation of the utility will return the object
wrapped using the current IndexableObjectWrapper.

If required, Local Site configuration can be used to provide different
implementations as needed.

BACKWARDS COMPATIBILITY: Any catalog implementation that used a
different wrapper class would have to subclass the main catalog and
override the relevant function, so will be unaffected by the change.

Any thoughts?

Miles

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads