Re: FWT meeting notes 2013-06-25

On Fre, 2013-06-28 at 15:21 +0200, Philip Bauer wrote:
> Am 28.06.2013 um 14:05 schrieb Johannes Raggam <[email protected]>:
> 
> > On Fre, 2013-06-28 at 12:16 +0200, Philip Bauer wrote:
> >> - We have more issues with plone.app.event since it is still under heavy development. It not as production-ready as I'd like it to be. It might be a good idea to deprecate the Archetypes-flavor of plone.app.event and focus only on dexterity. That would make the installation and testing much easier.   
> > please give some feedback about the problems you have with
> > plone.app.event. either here or as tickets in
> > https://github.com/plone/plone.app.event/issues?state=open
> > this will me help to understand whats still missing or wrong.
> 
> Surely. For once we realized yesterday that the dx-version is broken since 1.0b8 (the trunk too): 
> https://github.com/plone/plone.app.event/issues/79 

thanks for reporting. you can blame me for this bug, it's related to the
OccurrenceTraverser fix to support the plone.app.imaging's image
traverser. i'm going to fix it today.

besides of this, i'll focus this week on failing tests and missing
documentation to bring it closer to a 1.0 release. helping hands are
welcome!

> > 
> > i'm using plone.app.event (AT, mainly) since 1.5 years in production
> > without any big issues. sure, i have fixed a lot of issues since then
> > and brought it to a state where from my point of view it's production
> > ready and a 1.0 release not far away.
> 
> > regarding a merge with plone.app.contenttypes - i'm -1 * (10 + thet's
> > bias) for this because:
> > 
> > - for me, plone.app.event is more a framework than just two content
> > types. you can build upon plone.app.event's ATEvent or it's dexterity
> > behaviors, create own views or portlets, etc.
> > 
> > - a seperated, uninstallable plone.app.event package was one design
> > goal. i guess, that there are a lot of use cases, where calendaring
> > functionality isn't used at all. for those, plone.app.event can be
> > simply left out from the installtion.
> > 
> > - the AT and DX related code is again completly seperated within
> > plone.app.event and each of it optional.
> > 
> > - it's developed with encapsulation and separation of concerns in mind,
> > e.g. event the controlpanel and portlets are defined within
> > plone.app.event instead of having such dependencies spread over dozens
> > of packages.
> > 
> > - there is really a lot of functionality and code which belongs only to
> > calendaring and event related stuff. merging it into
> > plone.app.contenttypes will multiply it's codebase.
> 
> Sounds reasonable. What I want is a stable default-dx-event that will be installed by all people installing plone.app.contenttypes until 5.0 hits the shelves. I don't really care if the codebase of p.a.c grows as long as the at-version of events is not part of it. I think it's safe to assume that people want events in their sites by default. If someone wants to uninstall the package that provides them they can go ahead. What I don't want is people having a choice between at and dx. the at-flavour should be deprecated fast and we need migrations for ATEvent -> plone.app.event.dx and plone.app.event.at -> plone.app.event.dx 

the dx event was not even in plone.app.event's original scope, but added
as we'll just need it. i agree, we could peel out the archetypes code
and move it into a seperate package. but i wouldn't merge everything of
plone.app.event's generic code in plone.app.contentypes. as i said,
plone.app.event is not just another content type, it's a calendaring
framework. everything except the .at and .dx subpackages are independent
from any content type implementation.

regarding migrations - i'm pro for having migrations but i don't expect
them to be universally applicable, as discussed at the last FWT meeting.
in my experience, i have really ofter custom archetype content types -
e.g. subclassed by collective.folderishtypes and schema extended by
collective.contentleadimage. in such cases, default migrations would
just fail. but let's see, what the implementations bring us.

> One problem we have at the moment is millions of conditional adapters (just look at Solgema.fullcalendar) that are ugly and hard to maintain since they have to deal with tiny differences between at- and dx-version of folders and collections and three types of events. 

i disagree. i've introduced the IEventAccessor concept in
plone.app.event to unify access to .at, .dx or any other content type
implementation - for an example just look at
plone.app.event.browser.event_view. for the accessor implementations
refer to plone.app.event.dx.behaviors.EventAccessor or
plone.app.event.at.content.EventAccessor.
without too much effort, much of plone.app.event's code could be moved
to the generic plone.event package and used in Pyramid too (but don't
panic, thats out of scope for now).

don't compare the codebase with Solgema.fullcalendar. this package is
totally usefull but an architectonical mess as it's grown by too many
hands and too much usecases. it had legacy concepts in it before the
plone.app.event support was added. if you'd ask me and give me enough
budget, i would refactor it completly. i use it just for one project and
it's working quite good there.

for (IMHO) better examples on how to work with plone.app.event, look at
collective.folderishtypes (AT only) and collective.venue (DX type with
support for references in AT objects).


johannes

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlHRSLUACgkQW4mNMQxDgAeHSACfV/QSZ5WzcuJmYTUXjrjfgd+N
TSgAn1BNs6HbWzJqyGUquRTiWGWzPabu
=iQk7
-----END PGP SIGNATURE-----