Inconsistent naming of fields

[hvelarde]

Archetypes-based version	Dexterity-based version
startDate	start
endDate	end
wholeDay	whole_day
openEnd	open_end
timezone	timezone
	sync_uid
recurrence	recurrence
location	location
attendees	attendees
contactName	contact_name
contactEmail	contact_email
contactPhone	contact_phone
eventUrl	event_url
eventUid
text

with this kind of design decisions you're making the life of add-on developers and integrators hard.

how we can solve that?

[thet]

The reasoning was to have more Pythonic names and leave the legacy naming convention behind.
Maybe this was not the best decision, but plone.app.event always provided support for AT and DX.

Dexterity behaviors have to be treated different from Archtype content anyways, e.g because DX behaviors have to be adapted with the content object before accessing attributes. The decision to use behaviors was done to be able to provide Event functionality for any content type. E.g. you should be able to add the IEventBasic behavior to INewsItem content types.

To make AT and DX available under one interface the IEventAccessor wrapper was created. That way we are able to use e.g. the same browser views and templates for AT and DX. Please note, that AT support was removed since p.a.e 2.0.

If that is not enough, I could imagine that a Behavior could help, which provides a behavior class, which itself provides the old attribute names which get the values from adapting the original p.a.e behaviors with the content object.
Just an idea.

[hvelarde]

well, we created a hell of a problem for add-on developers just to have more pythonic names: there's no easy way to maintain compatibility with both, Archetypes and Dexterity now.

just look at what I had to do just to create a single Event on my tests: collective/collective.cover@5686e17

dropping support for Archetypes is fine; but we must have a clear path for migrations; by not providing it, dozens of people will have to spend dozens of hours solving a problem we have created.

this was a very bad decision, IMO.

[thet]

@hvelarde do you have a suggestion on how to make it easier for developers to support AT and DX, Plone 4 and Plone 5? Otherwise we could close this issue.

Regarding supporting AT and DX support in plone.app.event: IIRC, this was the first project which supported both content type frameworks equally. It was a proof of concept and I think the way it's done there is not so bad. If you make use of the awesome feature of behaviors, you'll have to treat attribute access to DX different from AT anyways. plone.app.event shows how (via IEventAccessor) and how to write the same test cases for AT and DX.

IMO the biggest point is lack of documentation. I'll see if I can contribute some of my experiences to it,

[hvelarde]

@thet so, if I don't have an answer to the question I'm asking you will close the issue? what's the point on asking then?

[hvelarde]

I took a look at the both, the PLIP and the package documentation (specially, the Development design choices) and found not a single trace of thoughts about this.