Plone 2.1 compatibility deferred until 0.6 release

[Jason McVetta]

Today or tomorow I will be releasing EventRegistration 0.5.  It's mostly a code cleanup & minor bugfix release,  plus two new fields in the Event schema, removal of the redundant effective/expiration date controls from the Event edit screen, & substantially improved documentation in README.txt. 

Since I have not had time enough to test ER against Plone 2.1, release 0.5 will not be marked compatible with that.  Tested compatibility with 2.1 is still a big priority, so I am planning that as the major feature of release 0.6.

Anyone who can help by testing ER with Plone 2.1, please do so, and post your results to this list. 

Sebastien Douche has reported problems with 2.1 -- before the mailing list was created.  Sebastien, when I release 0.5, will you try it out and see if it gives you the same probs, then report your findings to the list?  Registrant's parentTitle() method has been rewritten, and should work right (or at least better) now.  The title problem you were having, using accented characters, may be more an issue with internationalization than with 2.1 compat. 

[Sebastien Douche]

On 8/9/05, Jason McVetta <jason....@gmail.com> wrote:
> Today or tomorow I will be releasing EventRegistration 0.5. It's mostly a
> code cleanup & minor bugfix release, plus two new fields in the Event
> schema, removal of the redundant effective/expiration date controls from the
> Event edit screen, & substantially improved documentation in README.txt.

I don't think override event type is a good solution. Plone 2.1 comes
with a new event type (with vcal & ical export, new skins, ...), so
users that install ER lose 2.1 functionnality.

> Anyone who can help by testing ER with Plone 2.1, please do so, and post
> your results to this list.
>
> Sebastien Douche has reported problems with 2.1 -- before the mailing list
> was created. Sebastien, when I release 0.5, will you try it out and see if
> it gives you the same probs, then report your findings to the list?

Yes, I will do it. I *need* Plone 2.1.

> Registrant's parentTitle() method has been rewritten, and should work right
> (or at least better) now. The title problem you were having, using accented
> characters, may be more an issue with internationalization than with 2.1
> compat.

I don't know, very strange problem. Title is a computed field and I
don't find another computed field for a comparison.


--
Sébastien Douche <sdo...@gmail.com>

[Jason McVetta]

On 8/9/05, Sebastien Douche <sdo...@gmail.com> wrote:

I don't think override event type is a good solution. Plone 2.1 comes
with a new event type (with vcal & ical export, new skins, ...), so
users that install ER lose 2.1 functionnality.

Overriding  the default Event type is bad only if  the Event type provided by ER is missing some features of the default type.  So probably the right solution to this is to base a new version of our Event type on ATCT's Event type.  I haven't yet looked at how ATCT does Event, so I can't say whether that will be easy or difficult.

[Justin Ryan]

Probably most appropriate would be to have a subclassed ATEvent with
an option somewhere to override default 'Event' type or, alternately,
have a RegisterableEvent type. Different sites will have different
workflows.

At the very least, you want an option when you create an 'event' that
says whether or not registration is available / relevant.

On 8/9/05, Jason McVetta <jason....@gmail.com> wrote:

--
"A very large field came into existence as a function of the
correctness of Richard Stallman's ideas"
-Eben Moglen, Head Counsel for the Free Software Foundation

[Jason McVetta]

On 8/9/05, Justin Ryan <just...@gmail.com> wrote:

Probably most appropriate would be to have a subclassed ATEvent with
an option somewhere to override default 'Event' type or, alternately,
have a RegisterableEvent type.  Different sites will have different
workflows.

Agreed about the subclassing.  But can we inherit from both the AT Event class and a folderish class?  A quick glance at the ATCT code didn't show me any reason why not; but it still sounds likely to be fraught w/ probs. 

At the very least, you want an option when you create an 'event' that
says whether or not registration is available / relevant.

Already we have a "handle registration?" checkbox on the event edit screen.  If it is unchecked, the registration features are disabled for that event.  Do you think there is a better way to do that?

[Justin Ryan]

you should specifically be able to subclass an ATEvent and a Folderish
class, i.e. ATFolder.. This is somewhat the design of Archetypes as I
understand it..

You will also have to implement some code for a folderish class to
work just like a folder in Plone 2.1, because there are nifty new
features.. :)

On 8/9/05, Jason McVetta <jason....@gmail.com> wrote:

No.

[Jason McVetta]

On 8/9/05, Justin Ryan <just...@gmail.com> wrote:

You will also have to implement some code for a folderish class to

work just like a folder in Plone 2.1, because there are nifty new
features.. :)

In fact, I don't want my Events to act at all like a folder.  They are folderish only so they can store their associated Registrant objects.  Do you know of a more elegant way to store a group of associated objects within an object?

[Sebastien Douche]

On 8/10/05, Jason McVetta <jason....@gmail.com> wrote:
> In fact, I don't want my Events to act at all like a folder. They are
> folderish only so they can store their associated Registrant objects.

You can choose types to store in folderish objects. Global
configuration in plone 2.0, for each instance of folderish objects in
Plone 2.1


--
Sébastien Douche <sdo...@gmail.com>

[Justin Ryan]

It's also possible to hide some of the public interface of the folder,
but it is best to have these objects be Folderish for many reasons,
the most prevalent of which in my mind is currently easy data recovery
or manipulation of child objects. You need to get at them some how,
and a folder is about the simplest container there can be.

On 8/10/05, Jason McVetta <jason....@gmail.com> wrote:

[Jason McVetta]

On 8/10/05, Sebastien Douche <sdo...@gmail.com> wrote:

You can choose types to store in folderish objects. Global
configuration in plone 2.0, for each instance of folderish objects in
Plone 2.1

Right.  But does plone have to think of an object as folderish for me to be able to store a group of objects in some way attached to it?  For instance, could the object have a property that is a tuple of Registrant objects?  That would be better, in as much as an event isn't actually a folder-type-thing. 

[Jason McVetta]

On 8/10/05, Justin Ryan <just...@gmail.com> wrote:

It's also possible to hide some of the public interface of the folder,
but it is best to have these objects be Folderish for many reasons,
the most prevalent of which in my mind is currently easy data recovery
or manipulation of child objects.   You need to get at them some how,
and a folder is about the simplest container there can be.

Valid point.  Reinventing the wheel is wasteful.

[Justin Ryan]

The problem is that you can't easily get at this tuple via ZMI or
cut/paste content to/from it, etc... A folder is simply a generic
parent object which can have an arbitrary number of children, so
inasmuch as you want to store several objects 'within' another object,
it should be Folderish. This also implies acquisition, although you
should be able to block that quite easily.

On 8/10/05, Jason McVetta <jason....@gmail.com> wrote:

[Sebastien Douche]

On 8/10/05, Jason McVetta <jason....@gmail.com> wrote:

> Right. But does plone have to think of an object as folderish for me to be
> able to store a group of objects in some way attached to it? For instance,
> could the object have a property that is a tuple of Registrant objects?
> That would be better, in as much as an event isn't actually a
> folder-type-thing.

Another solution is to use reference, with ATReferenceWidget. You
create a Registrant and you choose a event in a folder


--
Sébastien Douche <sdo...@gmail.com>

[Justin Ryan]

This is a good point, although I still think it's cleaner to go folderish.. :)

On 8/10/05, Sebastien Douche <sdo...@gmail.com> wrote:
>

[afd]

>
> Anyone who can help by testing ER with Plone 2.1, please do so, and post
> your results to this list.
>

I've tried ER with Plone 2.1, with the following results (it requires a
few steps to make it work)

1. ExportRegistrants and Mail Registrants won't work because of the
changes to getFolderContents(). The problem was resolved after I've
added metadata in the catalog for all the fields referenced in the page
template. There's an option for AT to register the field as metadata,
with index="FieldIndex:Schema" defined in the schemata of the fields.
I didn't try this though so I may be wrong :-).

2. The line 195 title = 'Register for %s' %
self.REQUEST.PARENTS[1].title from Registrant.py gives an error. I've
commented this and enable the following line and then it worked

Mostly these are the issues. Thanks for a great product! Keep up the
good work

Tiberiu Ichim

[Jason McVetta]

On 8/12/05, afd <tiberi...@gmail.com> wrote:

I've tried ER with Plone 2.1, with the following results (it requires a
few steps to make it work)

1. ExportRegistrants and Mail Registrants won't work because of the
changes to getFolderContents(). The problem was resolved after I've
added metadata in the catalog for all the fields referenced in the page
template. There's an option for AT to register the field as metadata,
with  index="FieldIndex:Schema" defined in the schemata of the fields.
I didn't try this though so I may be wrong :-).

You needed to add metadata for every field, or just some?  Let me know, and I'll try adding it in the schema.
 

2. The line 195    title = 'Register for %s' %
self.REQUEST.PARENTS[1].title   from Registrant.py gives an error. I've
commented this and enable the following line and then it worked

Are you using the most up-to-date version of EventRegistration, either release 0.5 or svn trunk (there's no diff right now)?   Fairly recently the title setting function was changed to call parentTitle() rather than calculate its own value..  and I thought I had parentTitle() working okay. 

Mostly these are the issues. Thanks for a great product! Keep up the
good work

Thanks for the feedback!

[afd]

The metadata is needed for all the fields referenced in, for example,
export_registration.pt. So that would be honorific, first_name,
last_name, etc.