Re: How to edit dexterity types without needing to know about their behaviors
Sean Upton <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <CANjV-2Pe+okE3_i+F+NFJHSgweZL=x5C7oQ9q8Q0m4kmGDC8Qw@mail.gmail.com> |
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? 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 ------------------------------------------------------------------------------ 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