The Plone Collective

Mario Moran wrote:
> Hi,
> 
> While trying to add version information to a document in Plone with CMF 
> Editions I get the following error:
> 
> 
> Error Type
>     UnpickleableError
> Error Value
>     Cannot pickle objects Request made at
>     2005/05/17 14:37:56.826 US/Central
> 
> 

nasty acquisitionwrapper error!Thanks Mario!

Yes. Latest version that worked with Plone 2.0.x was ATCT 0.2.

On Sun, 08 May 2005 17:10:22 +0200, Gr=E9goire Weber <gregweb@...>=
 =20
wrote:

> Hi All,
>
> try to get my CMFEditions sandbox working again.
> Is it to be expected that the ATContentTypes 1.0.0 branch doesn't work =
=20
> with Plone 2.0.x?
>
> Gregoire
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events=
, =20
> 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20



--=20
_____________________________________________________________________

      Alexander Limi =B7 Chief Architect =B7 Plone Solutions =B7 Norway

  Consulting =B7 Training =B7 Development =B7 http://www.plonesolutions.c=
om
_____________________________________________________________________

       Plone Co-Founder =B7 http://plone.org =B7 Connecting Content
   Plone Foundation =B7 http://plone.org/foundation =B7 Protecting Plone

=?ISO-8859-15?Q?Gr=E9goire_Weber?= wrote:

> try to get my CMFEditions sandbox working again.
> Is it to be expected that the ATContentTypes 1.0.0 branch doesn't work 
> with Plone 2.0.x?
> 

Yes, and a real pain it is too.

BTW, we will need CMFEditions to continue working with Plone 2.0.x since 
the work involved in moving our setup to Plone 2.1 is obviously going to be 
pretty major so we won't be doing it immediately.

On Mon, 09 May 2005 11:08:37 +0200, Duncan Booth =20
<duncan.booth@...> wrote:

> =3D?ISO-8859-15?Q?Gr=3DE9goire_Weber?=3D wrote:
>
>> try to get my CMFEditions sandbox working again.
>> Is it to be expected that the ATContentTypes 1.0.0 branch doesn't work
>> with Plone 2.0.x?
>>
>
> Yes, and a real pain it is too.
>
> BTW, we will need CMFEditions to continue working with Plone 2.0.x sinc=
e
> the work involved in moving our setup to Plone 2.1 is obviously going t=
o =20
> be
> pretty major so we won't be doing it immediately.

It *is* possible to get ATCT 1.0 working with Plone 2.0.x, but it will =20
require some fixes to 2.0.x, which we are not actively working on any =20
longer. If you're interested, Tiran has the details - I'm not sure it is =
a =20
lot of work, it's more that he wants to use his spare time to work on the=
 =20
2.1 integration than supporting the previous release of Plone.

Branching 2.0.x to apply these fixes is definitely an option if you need =
=20
it.

--=20
_____________________________________________________________________

      Alexander Limi =B7 Chief Architect =B7 Plone Solutions =B7 Norway

  Consulting =B7 Training =B7 Development =B7 http://www.plonesolutions.c=
om
_____________________________________________________________________

       Plone Co-Founder =B7 http://plone.org =B7 Connecting Content
   Plone Foundation =B7 http://plone.org/foundation =B7 Protecting Plone

Hi All,

I'd like to set a deadline for that discussion to not loose to much time:

    Evening (CET) of 4 may 2005

That means everything in our inboxes Thursday morning (CET, +0200) will=20
be thought about.

Gregoire


Gr=E9goire Weber schrieb:
> Hi Everybody,
>=20
> Some time ago Vincenzo set the goal to get out the 1.0-final at the end=
=20
> of may.
>=20
> So let's start the discussion about the features that should belong to=20
> such release.
>=20
>  From an IRC session of today we (Vincenzo, Alberto and I) identified=20
> the following main features for discussion:
>=20
> - Archetypes Reference handling
>=20
>   CMFEditions architecture is prepared to handle AT references but this
>   isn't implemented yet. As first task we should agree on how those
>   references shall be treated on a retrieve.
>=20
> - Folderish objects handling
>=20
>   There are currently one or more bugs preventing the folderish FAQ
>   content type from being working. There exist unit test showing that
>   bug.
>=20
> - Versioning backend (or storage)
>=20
>   The default storage backend is a ZVC storage with a wrapper around
>   abstracting a lot of ZVC specific stuff. There is a need of a simple
>   ZODB based storage.
>=20
> - AT compatibility
>=20
>   Q: Which version(s) of AT shall we support?
>=20
> - Name of CMFEditions
>=20
>   It may make sense to name CMFEditions differently. We should not flam=
e
>   war over this but it would make sense to have a name that is better
>   suited for marketing purposes. Possibly there is a need to split the
>   product into two (or more).
>=20
>=20
> Please add your suggestions and Questions.
>=20
> Vincenzo, Alberto, Gregoire
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events=
, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Collective-versioning mailing list
> Collective-versioning@...
> https://lists.sourceforge.net/lists/listinfo/collective-versioning
>=20

=?ISO-8859-15?Q?Gr=E9goire_Weber?= wrote:

> - Archetypes Reference handling
> 
>    CMFEditions architecture is prepared to handle AT references but
>    this isn't implemented yet. As first task we should agree on how
>    those references shall be treated on a retrieve.

That is the one I put at highest priority. I don't particularly care how 
the references are handled on a retrieve so long as the result is 
consistent. The sensible thing to my mind would be to roll back the 
references then correct the reference catalog to match.

Longer term there is an argument for marking some references to be 
versioned and others to not be versioned, but I'm not sure if this is 
really specific to references or applies equally to all fields.

I'm also not sure about what should happen if I just want to view a 
previous version without rolling back. This is currently implemented by 
creating an object which behaves like the original object and is used as 
the context when rendering an appropriate template. Since the references 
are handled partly inside the object and partly in the reference catalogue 
I can't really see how we can provide a consistent environment while 
invoking the display template without updating the catalogue, rendering and 
then restoring the catalog which sounds messy.

> - AT compatibility
> 
>    Q: Which version(s) of AT shall we support?
> 
Probably the currently released one 1.3.x. Is there a case for 'out-of-the-
box' support for ATCT also? In which case I would guess that should be for 
the version of ATCT that will ship with Plone 2.1 or as near as we can get 
given it still seems to be in flux.

> - Name of CMFEditions
> 
>    It may make sense to name CMFEditions differently. We should not
>    flame war over this but it would make sense to have a name that is
>    better suited for marketing purposes. Possibly there is a need to
>    split the product into two (or more).
> 
I'm not going to lose any sleep over the name.

Duncan Booth wrote:

>=?ISO-8859-15?Q?Gr=E9goire_Weber?= wrote:
>  
>
>>- Archetypes Reference handling
>>
>>   CMFEditions architecture is prepared to handle AT references but
>>   this isn't implemented yet. As first task we should agree on how
>>   those references shall be treated on a retrieve.
>>    
>>
>
>That is the one I put at highest priority. I don't particularly care how 
>the references are handled on a retrieve so long as the result is 
>consistent. The sensible thing to my mind would be to roll back the 
>references then correct the reference catalog to match.
>
>  
>
yes, while deletting those that are invalid,  e .g. pointing to non 
existent object, just to start. Next we should think how might  be 
handled a more complex behavoir, like rollbacking all the referenced 
content objects, but this is really a matter of how define and manage 
site (or type, or location, or..) policies that define specialized 
behaviors for the most common use cases. Maybe an initial implementation 
of these policies can be something like a list of modifiers to be run 
when some criteria (ala ATTopic) matches.. but it's just a.... "draft2"? 
Or maybe  a mixin for AT  (like TemplateMixin) which manages the 
reference creation process instantiating a version aware reference 
instead of the plain AT one still when some policy criteria matches. 
With such approach both administrators and developers have a way  to 
define the (default) behavior for a given content type or whatever.

>Longer term there is an argument for marking some references to be 
>versioned and others to not be versioned, but I'm not sure if this is 
>really specific to references or applies equally to all fields.
>  
>
all fields can benfit from versioning, don't you think? However for 1.0 
i think ref handling is a good target. Fields are versioned, even if 
"blindly", if their storage is in the instance, like in 
AttributeStorage. The problem arises for SQL fields, but probably not 
for APE storage based types, as all APE does is at a lower level when 
it's used as ZODB storage backend.
 About the implementation, is reasonable to think to something like a 
proxy storage that sits between the field and the real storage and that 
has it's hown configuration coming coming from schema but is connected 
to the site policy manager?mmm...

>I'm also not sure about what should happen if I just want to view a 
>previous version without rolling back. This is currently implemented by 
>creating an object which behaves like the original object and is used as 
>the context when rendering an appropriate template. Since the references 
>are handled partly inside the object and partly in the reference catalogue 
>I can't really see how we can provide a consistent environment while 
>invoking the display template without updating the catalogue, rendering and 
>then restoring the catalog which sounds messy.
>
>  
>
this is a severe issue...until the reference will be aware of the 
versioning stuff in some way ...

>>- AT compatibility
>>
>>   Q: Which version(s) of AT shall we support?
>>
>>    
>>
>Probably the currently released one 1.3.x. Is there a case for 'out-of-the-
>box' support for ATCT also? In which case I would guess that should be for 
>the version of ATCT that will ship with Plone 2.1 or as near as we can get 
>given it still seems to be in flux.
>
>  
>
yes,  AT 1.3 and ATCT 1.0 codeline

>>- Name of CMFEditions
>>
>>   It may make sense to name CMFEditions differently. We should not
>>   flame war over this but it would make sense to have a name that is
>>   better suited for marketing purposes. Possibly there is a need to
>>   split the product into two (or more).
>>
>>    
>>
>I'm not going to lose any sleep over the name.
>  
>
me too, but as i said., it can be useful to put all AT stuff into it's 
own product that can be named like... ATVersioning?
Vincenzo, what's your name here?:)

ciao

Alberto

Hi all,
it seems we all agree on most of the topics, so I would like to start
sceduling development and define deadlines.

Could you please tell us your availability in the next three weeks?
So we can define how do what and when we want to be ready.

Thanks,
	vds



On Tue, 2005-05-03 at 21:24 +0200, Alberto Berti wrote:
> Duncan Booth wrote:
>=20
> >=3D?ISO-8859-15?Q?Gr=3DE9goire_Weber?=3D wrote:
> > =20
> >
> >>- Archetypes Reference handling
> >>
> >>   CMFEditions architecture is prepared to handle AT references but
> >>   this isn't implemented yet. As first task we should agree on how
> >>   those references shall be treated on a retrieve.
> >>   =20
> >>
> >
> >That is the one I put at highest priority. I don't particularly care how=
=20
> >the references are handled on a retrieve so long as the result is=20
> >consistent. The sensible thing to my mind would be to roll back the=20
> >references then correct the reference catalog to match.
> >
> > =20
> >
> yes, while deletting those that are invalid,  e .g. pointing to non=20
> existent object, just to start. Next we should think how might  be=20
> handled a more complex behavoir, like rollbacking all the referenced=20
> content objects, but this is really a matter of how define and manage=20
> site (or type, or location, or..) policies that define specialized=20
> behaviors for the most common use cases. Maybe an initial implementation=20
> of these policies can be something like a list of modifiers to be run=20
> when some criteria (ala ATTopic) matches.. but it's just a.... "draft2"?=20
> Or maybe  a mixin for AT  (like TemplateMixin) which manages the=20
> reference creation process instantiating a version aware reference=20
> instead of the plain AT one still when some policy criteria matches.=20
> With such approach both administrators and developers have a way  to=20
> define the (default) behavior for a given content type or whatever.
>=20
> >Longer term there is an argument for marking some references to be=20
> >versioned and others to not be versioned, but I'm not sure if this is=20
> >really specific to references or applies equally to all fields.
> > =20
> >
> all fields can benfit from versioning, don't you think? However for 1.0=20
> i think ref handling is a good target. Fields are versioned, even if=20
> "blindly", if their storage is in the instance, like in=20
> AttributeStorage. The problem arises for SQL fields, but probably not=20
> for APE storage based types, as all APE does is at a lower level when=20
> it's used as ZODB storage backend.
>  About the implementation, is reasonable to think to something like a=20
> proxy storage that sits between the field and the real storage and that=20
> has it's hown configuration coming coming from schema but is connected=20
> to the site policy manager?mmm...
>=20
> >I'm also not sure about what should happen if I just want to view a=20
> >previous version without rolling back. This is currently implemented by=20
> >creating an object which behaves like the original object and is used as=
=20
> >the context when rendering an appropriate template. Since the references=
=20
> >are handled partly inside the object and partly in the reference catalog=
ue=20
> >I can't really see how we can provide a consistent environment while=20
> >invoking the display template without updating the catalogue, rendering =
and=20
> >then restoring the catalog which sounds messy.
> >
> > =20
> >
> this is a severe issue...until the reference will be aware of the=20
> versioning stuff in some way ...
>=20
> >>- AT compatibility
> >>
> >>   Q: Which version(s) of AT shall we support?
> >>
> >>   =20
> >>
> >Probably the currently released one 1.3.x. Is there a case for 'out-of-t=
he-
> >box' support for ATCT also? In which case I would guess that should be f=
or=20
> >the version of ATCT that will ship with Plone 2.1 or as near as we can g=
et=20
> >given it still seems to be in flux.
> >
> > =20
> >
> yes,  AT 1.3 and ATCT 1.0 codeline
>=20
> >>- Name of CMFEditions
> >>
> >>   It may make sense to name CMFEditions differently. We should not
> >>   flame war over this but it would make sense to have a name that is
> >>   better suited for marketing purposes. Possibly there is a need to
> >>   split the product into two (or more).
> >>
> >>   =20
> >>
> >I'm not going to lose any sleep over the name.
> > =20
> >
> me too, but as i said., it can be useful to put all AT stuff into it's=20
> own product that can be named like... ATVersioning?
> Vincenzo, what's your name here?:)
>=20
> ciao
>=20
> Alberto
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Collective-versioning mailing list
> Collective-versioning@...
> https://lists.sourceforge.net/lists/listinfo/collective-versioning
>=20

Vincenzo Di Somma wrote:

>Hi all,
>it seems we all agree on most of the topics, so I would like to start
>sceduling development and define deadlines.
>
> =20
>
Uh, isn't a bit too earlu I've proposed some  paths to follow and Duncan=20
and I agree on most points, but i would be glad also to know what's your=20
(and the one of Gr=E8goire, Duncan, Riccardo and Kapil, if he is reading=20
this list) "vision" of the AT support in CMFEditions, which is the best=20
approach for you?
I do not mean having all details clear right now, but we need to have an=20
idea of how will be the future devel of the ATSupport in CMFEditions,=20
milestone by milestone. I has not to be hard written on the rock, but i=20
tend to avoid develeping a "blind" support for 1.0 target that  we need=20
to completely replace  after that  release (even if certain amount of=20
refactoring is always a good thing).

what do you think?

alberto

Sorry for the delay.

I also agree on everything said. But we have to tailor down the work to=20
be done a little more precise to be able to estimate more or less accurat=
e.

You'll hear more detailed stuff from me this weekend.

Gregoire

Alberto Berti schrieb:
> Vincenzo Di Somma wrote:
>=20
>> Hi all,
>> it seems we all agree on most of the topics, so I would like to start
>> sceduling development and define deadlines.
>>
>> =20
>>
> Uh, isn't a bit too earlu I've proposed some  paths to follow and Dunca=
n=20
> and I agree on most points, but i would be glad also to know what's you=
r=20
> (and the one of Gr=E8goire, Duncan, Riccardo and Kapil, if he is readin=
g=20
> this list) "vision" of the AT support in CMFEditions, which is the best=
=20
> approach for you?
> I do not mean having all details clear right now, but we need to have a=
n=20
> idea of how will be the future devel of the ATSupport in CMFEditions,=20
> milestone by milestone. I has not to be hard written on the rock, but i=
=20
> tend to avoid develeping a "blind" support for 1.0 target that  we need=
=20
> to completely replace  after that  release (even if certain amount of=20
> refactoring is always a good thing).
>=20
> what do you think?
>=20
> alberto
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events=
, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Collective-versioning mailing list
> Collective-versioning@...
> https://lists.sourceforge.net/lists/listinfo/collective-versioning
>=20

Hi everybody,

I think we all mostly agree on the issues to be handled till a 1.0 final.

Below I just resume what I see as outcome of the discussion of last week 
  mixed with my own comments.

At the end of that lengthy e-mail I tried to start a task list.

Reference handling
------------------

The goals for the 1.0-final:

- Consistency, consistency, consistency, ...
- Simple policy (simple to implement)
- Simple policy (simple to understand for users)

In details:

1. Consistency on revert: This is a must. This includes in particular

    a. Ref Catalog has to be in sync with refs in content object.
       Shouldn't a reindex of the object help on the revert
       (rollback) case?
    b. References to deleted object shall be deleted also
       (this is consistent if we just declare all AT reference for
       now as outside references). Let's just define this behavior
       as 1.0-final default policy. Ok?
    c. side note about terminology: I changed the method name from
       ``rollback`` to ``revert`` but perhaps we should change that
       back to ``rollback``.

2. Consistency on retrieve: This is a must also.

    a. I didn't yet analyze the problem but I understand the
       implications.
    b. The ref catalog "issue" just shows a general problem with the
       current implementation. Probably the the modifiers have to be
       informed what operation will be carried out on retrieve (retrieve
       or revert (rollback)).
    c. As we already put the retrieved object in the current working
       copies context **and** container we also can add a special
       temporary ref catalog to the context just managing the retrieved
       AT references correctly and delegating requests to unknown refs to
       the real ref catalog (by acquisition). The special ref catalog
       (just) has to know how to resolve the referenced objects.


Versioning or not versioning references
---------------------------------------

The question arised what to version and what not. The following two
points are important here:

The use cases decide what to version really. I'd propose that the
default modifiers version everything (at save time). We're currently
able to filter out parts of the information on retrieve.

This way one may some years later decide to retrieve information that
wasn't retrieved before if necessary.


Dependencies
------------

Just a side note. I couldn't ATCT get working with AT 1.3.3 on Plone 
2.0.5. Seems that Plone 2.0.x compatibility on the 1.0.0-branch of
ATCT is lost.

I may be wrong. Please correct me in that case.

Shall we work on top of a stable Plone 2.0.x or (a feature unstable) 
Plone 2.1?

We have to check and agree on that.


Non-Attribute-Storages
----------------------

We have to think about that more deeply. In general a AT modifier should
be able to know how to read data from different storages to be able to
save them to the storage.

There is a open question anyway (and the use cases may dictate that) if
data store in a SQL table shall be versioned in the ZODB or not.

We should perhaps add a file named ARCHITECTURAL_DISCUSSION.txt and put
such issues there so the ideas won't get lost.

I'd like to put this at lower prio.


Topics
------

azazel: Not sure if I got this right.

Uhhh, it may be necessary to have a special topic modifier just saving
version aware refs to all search results on save.

But this depends on where the focus is for the user: version the search
term only or also the results? Seems to be similar to the folder versus
FAQ stuff.

I'd like to put this at lower prio.


Tasks for 1.0-final
-------------------

The risky part (should be done first)

1. Understand the CMFEditions/AT reference issue and draft possible
    solutions.
2. Write use cases for retrieving and reverting to (rolling back)
    referenced stuff.
3. Implement the reference stuff.

Less risky:

4. Get the folderish stuff working. I have some code of Varun that I
    should have a look at (there seems to be something wrong with the
    current implementation).
5. Decide upon the dependencies we like to base on (we all shall work on
    the same sandbox!)
6. Collect other issues. We need a collector perhaps. or do we have one
    already?

Gregoire

Hi Pico,

please note that this is an international mailing list, thus if you want
to have a chance to get an answer you'd better post in english :)

Il giorno lun, 02-05-2005 alle 12:33 +0200, PiCo ha scritto:
> Salve,
> ho istallato da poco il prodotto e devo dire che ci vedo delle =20
> potenzialit=E0.
> Una prima OSSERVAZIONE (non so che impatto ha...) =E8 questa:
> Il controllo delle versioni di un documento dovrebbe anche prevenire da=
 =20
> eventuali ERRORI di editing non voluti e quindi consentire di riportars=
i =20
> alla vecchia versione.

It is always possible to rollback to an earlier saved version of a
document;=20

> Pertanto credo che ogni qual volta si prema il tasto SALVA (su un ogget=
to =20
> sottoposto a CONTROLLO) si dovrebbe in automatico generare una nuova =20
> versione dell'oggetto, OBBLIGANDO l'autore a descrivere le modifiche =20
> apportate.

this is an "use-case" matter. Depending on the system (document
management in intranets, portals, etc.) the use case changes a lot. In
general it's good to leave to the authors the freedom to choose what
they want to save as a new version and when.

Please do not forget that to avoid typos, etc. the author can use the
standard "undo", there is no real need for a new version, which would
generate an "overpopulation" of versions and fill the disk space ;)=20

cheers,
francesco.

>=20
> Che ne dite???
>=20
> Comunque bel prodotto.. Buon LAvoro!
>=20
>=20
>=20

In any case it would be trivial to modify, as a customization, the
editing script to save a version each time you edit a document.

	vds


On Mon, 2005-05-02 at 14:34 +0200, Francesco Ciriaci wrote:
> Hi Pico,
>=20
> please note that this is an international mailing list, thus if you want
> to have a chance to get an answer you'd better post in english :)
>=20
> Il giorno lun, 02-05-2005 alle 12:33 +0200, PiCo ha scritto:
> > Salve,
> > ho istallato da poco il prodotto e devo dire che ci vedo delle =20
> > potenzialit=E0.
> > Una prima OSSERVAZIONE (non so che impatto ha...) =E8 questa:
> > Il controllo delle versioni di un documento dovrebbe anche prevenire da=
 =20
> > eventuali ERRORI di editing non voluti e quindi consentire di riportars=
i =20
> > alla vecchia versione.
>=20
> It is always possible to rollback to an earlier saved version of a
> document;=20
>=20
> > Pertanto credo che ogni qual volta si prema il tasto SALVA (su un ogget=
to =20
> > sottoposto a CONTROLLO) si dovrebbe in automatico generare una nuova =20
> > versione dell'oggetto, OBBLIGANDO l'autore a descrivere le modifiche =20
> > apportate.
>=20
> this is an "use-case" matter. Depending on the system (document
> management in intranets, portals, etc.) the use case changes a lot. In
> general it's good to leave to the authors the freedom to choose what
> they want to save as a new version and when.
>=20
> Please do not forget that to avoid typos, etc. the author can use the
> standard "undo", there is no real need for a new version, which would
> generate an "overpopulation" of versions and fill the disk space ;)=20
>=20
> cheers,
> francesco.
>=20
> >=20
> > Che ne dite???
> >=20
> > Comunque bel prodotto.. Buon LAvoro!
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, =
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Collective-versioning mailing list
> Collective-versioning@...
> https://lists.sourceforge.net/lists/listinfo/collective-versioning
>=20