language independent field definitions for dexterity

[agitator]

No description provided.

[agitator]

could somebody look at 55917b9

[agitator]

it seems that language independent fields don't support default values ...

default_start is not called and events created show the first possible date, in this case a date in feb 2004

https://github.com/plone/plone.app.event/compare/1.1.x-lang-independent-fields
with
https://github.com/plone/plone.app.multilingual/tree/datakurre-lif

@datakurre @jensens @thet @rnixx any ideas?

[datakurre]

Is the default value missing already from the add-form? Does it affect only p.a.event or all language independent fields? Please, file an issue for p.a.m. And if you have resources, a failing test would be great. It might be possible that the code, which looks lif value from existing translations fails to fallback to the default value when no translations exist yet.

agitator kirjoitti la joulukuuta 13 11:28:51 2014 GMT+0200:

it seems that language independent fields don't support default values ...

default_start is not called and events created show the first possible date, in this case a date in feb 2004

https://github.com/plone/plone.app.event/compare/1.1.x-lang-independent-fields
with
https://github.com/plone/plone.app.multilingual/tree/datakurre-lif

@datakurre @jensens @thet any ideas?

---

Reply to this email directly or view it on GitHub:
#170 (comment)

[agitator]

yes, on creation of the first object, no other langs exist.
and yes the fallback to the default value doesn’t work when no other langs available.
no idea how to write a test for that, sorry

[datakurre]

@agitator Would you have time to debug (wih pdb), why LIF-defaultvalueprovider does not fallback to the field's default value? The relevant code is

https://github.com/plone/plone.app.multilingual/blob/datakurre-lif/src/plone/app/multilingual/dx/form.py#L45

It should, unless the field is somehow initialized before that's called.

[agitator]

ipdb> self.field.title
u'label_event_start'
ipdb> isLanguageIndependent(self.field)
True
ipdb> self.field.default

self.field.default is None

[datakurre]

Does the field have defaultFactory? Maybe support for that is what is missing from p.a.m.

agitator kirjoitti su joulukuuta 14 13:22:13 2014 GMT+0200:

ipdb> self.field.title
u'label_event_start'
ipdb> isLanguageIndependent(self.field)
True
ipdb> self.field.default

self.field.default is None

---

Reply to this email directly or view it on GitHub:
#170 (comment)

[agitator]

ipdb> self.field.defaultFactory
ipdb> 

there, but also None

[datakurre]

@agitator @thet Ok, I'm sorry that I misunderstood the issue. It seems that multilingual supports the normal schema default values, but apparently it's p.a.event does something else (non standard?) that I don't understand. So, I guess, this is p.a.event issue after all.

[agitator]

it seems that the adapter for default_start isn't called

def default_start(data):
    return default_start_dt(data.context)
provideAdapter(ComputedWidgetAttribute(
    default_start, field=IEventBasic['start']), name='default')

[datakurre]

@agitator Ok, now that make sense and restores this to p.a.m issue.

p.a.m. registers its own default adapter, which overrides your adapter. p.a.m support zope.schema defaults, but not custom z3c.form defaults (because it overrides them).

Please, file an issue for p.a.m. Fix should be possible, but maybe not trivial, because it would require some ZCA-tricks for getting the adapter, which the language independent field default adapter hides.

[thet]

i don't have much resources to dive into this issues, but maybe this gives some hints?

in plone.app.event 1.x we set the default values like so:

from z3c.form.widget import ComputedWidgetAttribute
from zope.component import provideAdapter
def default_start(data):
    return default_start_dt(data.context)
provideAdapter(ComputedWidgetAttribute(default_start, field=IEventBasic['start']), name='default')

vs in plone.app.event 2.x (master branch):

https://github.com/plone/plone.app.event/blob/master/plone/app/event/dx/behaviors.py#L56

from zope.schema.interfaces import IContextAwareDefaultFactory
from zope.interface import provider
@provider(IContextAwareDefaultFactory)
def default_start(context):
    return default_start_dt(context)

plone.app.event 2.x doesn't have a custom behavior factory and IIRC, the IContextAwareDefaultFactory way doesn't work with behaviors with custom behavior factories.

[datakurre]

plone.dexterity = 2.2.4 might support zope.schema context aware default
factories for behaviors with custom factories, so that could be another
solution.

Johannes Raggam wrote:

i don't have much resources to dive into this issues, but maybe this
gives some hints?

in plone.app.event 1.x we set the default values like so:

|from z3c.form.widget import ComputedWidgetAttribute
from zope.component import provideAdapter
def default_start(data):
return default_start_dt(data.context)
provideAdapter(ComputedWidgetAttribute(default_start,
field=IEventBasic['start']), name='default')
|

vs in plone.app.event 2.x (master branch):

https://github.com/plone/plone.app.event/blob/master/plone/app/event/dx/behaviors.py#L56

|from zope.schema.interfaces import IContextAwareDefaultFactory
from zope.interface import provider
@Provider(IContextAwareDefaultFactory)
def default_start(context):
return default_start_dt(context)
|

plone.app.event 2.x doesn't have a custom behavior factory and IIRC,
the IContextAwareDefaultFactory way doesn't work with behaviors with
custom behavior factories.

—
Reply to this email directly or view it on GitHub
#170 (comment).

[agitator]

context aware adapters work, but still fighting timezone problems with post_processing

[datakurre]

@agitator Nice to hear. @thet might be interested in discussing about post_processing; If I remember correctly, the post processing was almost done in the behavior adapter at one point, but it was later refactored into z3c.form event handler. One main issue has been that post_processing can only truly happen after all field values are known.

[agitator]

talked to him at the aplinecitysprint, dug further into it, seems to be connected with the special post processing of dates within plone.app.event

[datakurre]

@agigator

Yes, there's event handler, which is only called after successful
z3c.form POST submission with the saved values. It's far from perfect
solution, but the problem has been hard and we haven't figured out a
better yet :(

Probably it should somehow be refactored back to behavior adapter, so
that it would be z3c.form independent.

agitator wrote

talked to him at the aplinecitysprint, dug further into it, seems to
be connected with the special post processing of dates within
plone.app.event

—
Reply to this email directly or view it on GitHub
#170 (comment).