Re: How to edit dexterity types without needing to know about their behaviors

On Fri, 2014-03-21 at 16:16 -0600, Sean Upton wrote:
> Also, can we move the tz stuff in an data_postprocessing() event
> handler to a z3c.form data converter?  Is there some obstacle I am
> overlooking to giving this a try?

You are right and it looks like we only need the data converter to fix
that. Here is my rough plan:

Based on three quite safe assumptions:

- Only datetime and no DateTime instances are used to set dates.

- Timezone naive datetime instances' value represent the date/time the
user meant to describe, without any timezone information.

- Timezones are still set via the timezone field and not extracted from
any timezone information from datetime instances.


These are the changes:

- A z3c.form data converter only applies a FakeZone, if the datetime
instance is timezone naive (no timezone present). This makes it possible
to compare the value one already stored on the object (when editing),
which always does have the timezone UTC. In that case, the comparison
will always result in different values, as the FakeZone is removed in
the data_postprocessing step.
If there is already a timezone information on the datetime instance, the
data converter should do nothing.

- For the EventBasic behavior class, the _prepare_dt_set can be removed.
The _prepare_dt_get is converting the UTC datetime to the target event's
timezone, which might make sense. I think the timezone setter can also
be removed, but that's something the tests hopefully will show us
(what's the behavior when editing an event?).

- The data_postprocessing step shouldn't need any changes.
The _fix_zone method is already removing the FakeZone and applying the
real zone or - if there is a real timezone present, converting this real
zone (including UTC) to the event's timezone.
Then, the start and end times are set according to the whole_day and
open_end setting. After that, all datetimes are converted to UTC and
saved back to the object. Awesome.

- Altough, one change is needed in data_postprocessing: any millisecond
information on datetime instances should be removed. Before, this was
done at the _prepare_dt_set method.


Before, any datetimes set on the event object were treated as if they
were timezone naive, just because of reasons related to the form widget.
This is kind of silly, I admit.
After this change, when setting the dates, any timezone information on
datetime instances will be respected.
If you get the start/end dates directly from the context, you will get
UTC values. If you adapt to the IEventBasic behavior, you will get the
start/end dates converted to the event's timezone. Same behavior as now.

That's it. Feel free to make a pull request, otherwise I hope to fix
that at next weekend's "Wine and Beer Sprint".

Cheers, Johannes

> That might be a win to make the requirements more plain WRT what we
> need the IEventAccessor adaptation for (and can we just make the event
> objects provide that interface without adaptation)?
> 
> I may be able to carve some time to look at experimenting with some of
> these things on a branch in coming weeks.
> 
> Sean
> 
> On Fri, Mar 21, 2014 at 4:04 PM, Sean Upton <[email protected]> wrote:
> > On Fri, Mar 14, 2014 at 2:32 AM, Johannes Raggam <[email protected]> wrote:
> >> i'll fix that, probably at the wine and beer sprint. but then you'll
> >> still always get UTC datetime values instead of localized ones, if you
> >> get the start/end attributes directly from the context.
> >
> > UTC should IMHO be the programmatic interface of dates/times always,
> > inasmuch as that is possible.
> >
> > I always just assumed that in the best-case the behaviors could be
> > used factory-less without requiring adaptation, but the whole (and
> > only really substantial) justification for adaptation was to have one
> > interface for dealing with both AT and DX types.  If neither AT
> > support nor non-UTC setting/getting is a requirement for Plone 5, what
> > avenues exist to (mostly or completely?) avoid adaptation to the
> > accessor interface?
> >
> > Sean

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
plone framework  team  member
mail: office-//[email protected]
web:  http://programmatic.pro
      http://bluedynamics.com

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlMtZHoACgkQW4mNMQxDgAcMPgCfYixtkY+hHbuNJIV857IQk/uy
YO4AnjAY3RPcpqjrAsV1LI4buolupTWv
=6YCT
-----END PGP SIGNATURE-----