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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.