New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

language independent field definitions for dexterity #170

Open
agitator opened this Issue Dec 5, 2014 · 17 comments

Comments

Projects
None yet
4 participants
@agitator
Member

agitator commented Dec 5, 2014

No description provided.

@agitator

This comment has been minimized.

Member

agitator commented Dec 5, 2014

could somebody look at 55917b9

@agitator agitator changed the title from language independent field for dexterity to language independent field definitions for dexterity Dec 5, 2014

@agitator

This comment has been minimized.

Member

agitator commented Dec 13, 2014

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

This comment has been minimized.

Member

datakurre commented Dec 13, 2014

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

This comment has been minimized.

Member

agitator commented Dec 13, 2014

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

This comment has been minimized.

Member

datakurre commented Dec 13, 2014

@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

This comment has been minimized.

Member

agitator commented Dec 14, 2014

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

self.field.default is None

@datakurre

This comment has been minimized.

Member

datakurre commented Dec 14, 2014

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

This comment has been minimized.

Member

agitator commented Dec 14, 2014

ipdb> self.field.defaultFactory
ipdb> 

there, but also None

@datakurre

This comment has been minimized.

Member

datakurre commented Dec 14, 2014

@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

This comment has been minimized.

Member

agitator commented Dec 15, 2014

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

This comment has been minimized.

Member

datakurre commented Dec 15, 2014

@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

This comment has been minimized.

Member

thet commented Dec 15, 2014

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

This comment has been minimized.

Member

datakurre commented Dec 15, 2014

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

This comment has been minimized.

Member

agitator commented Jan 26, 2015

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

@datakurre

This comment has been minimized.

Member

datakurre commented Jan 26, 2015

@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

This comment has been minimized.

Member

agitator commented Jan 26, 2015

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

This comment has been minimized.

Member

datakurre commented Jan 26, 2015

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment