Skip to content
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

ZMI: lines propery type does not render correctly #271

Closed
icemac opened this issue Apr 23, 2018 · 8 comments

Comments

@icemac
Copy link
Member

commented Apr 23, 2018

In #206 lines property types where switched to always store bytes. Since that change they are rendered no longer correctly in the ZMI:

zmi-4 0b4

Saving again adds a new layer of b'' around the values of the lines property.
In contrast the string property type behaves quite the same like the ustring property type.

I checked this against Zope 4.0b3 (before #206 landed on master): there lines and string behave the same like there unicode counterparts.

CC: @witsch @gotcha @hannosch @tseaver @pbauer

@icemac icemac added the bug label Apr 23, 2018

@icemac icemac modified the milestones: 4.0b4, 4.0b5 Apr 23, 2018

@gotcha

This comment has been minimized.

Copy link
Member

commented Apr 23, 2018

I cannot reproduce this when running master.
Are you running an old Data.fs ? iow, would that be a migration issue ?

@pbauer

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2018

I can confirm this in a clean Zope instance.
bildschirmfoto 2018-04-23 um 20 48 26

That values in lines-fields are bytes is the reason why creating a plone-instance fails at the moment.
The issue there is not a broken value like 'b"foo'" but that Plone actually cannot deal with behaviors as bytes:

(Pdb++) pp self.context.portal_types.Document.behaviors
(b'plone.app.content.interfaces.INameFromTitle',
 b'plone.app.dexterity.behaviors.discussion.IAllowDiscussion',
 b'plone.app.dexterity.behaviors.exclfromnav.IExcludeFromNavigation',
 b'plone.app.dexterity.behaviors.id.IShortName',
 b'plone.app.dexterity.behaviors.metadata.IDublinCore',
 b'plone.app.contenttypes.behaviors.richtext.IRichText',
 b'plone.app.relationfield.behavior.IRelatedItems',
 b'plone.app.versioningbehavior.behaviors.IVersionable',
 b'plone.app.contenttypes.behaviors.tableofcontents.ITableOfContents',
 b'plone.app.lockingbehavior.behaviors.ILocking')

The display is the same though:
bildschirmfoto 2018-04-23 um 20 49 58

I'd like to know how I should deal with the issue that all values from lines fields are bytes. Should I

  • change all the code in Plone to expect bytes
  • transform the schema-fields to ulines and write upgrade-steps
  • or?

Before the revert in zopefoundation/Products.GenericSetup@0f131a7 it was possible to creata a Plone instacne and work with it.

@pbauer

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2018

Saving multiple time creates funny results:
bildschirmfoto 2018-04-24 um 06 59 58

@icemac

This comment has been minimized.

Copy link
Member Author

commented Apr 24, 2018

@gotcha I used a freshly installed Zope 4.0b4 and I changed the properties of a PageTemplate object. Which type did you use where this behaviour does not occur?

@icemac

This comment has been minimized.

Copy link
Member Author

commented Apr 24, 2018

@pbauer Using ulines currently seems to be the safest way to deal with this issue.

@gotcha

This comment has been minimized.

Copy link
Member

commented Apr 24, 2018

@icemac My bad :-S
I was using Python 2.7 instead of Python 3.6.
Can reproduce

@dataflake

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

Some data points:

When submitting a value for a string (or lines) property, the converters are applied and at least in manual testing what ends up in the ZODB is correct if bytes is the desired outcome.

Going "the other way", to show the values the DTML-based form calls getProperty, which returns the value unchanged, but the presentation in DTML makes it look wrong.

This is a DTML rendering issue (the Properties tab is DTML-rendered). I have added issue zopefoundation/DocumentTemplate#43 to track it.

@dataflake

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

The culprit is here (and in the C-based equivalent) where the list of rendered values is joined into a single rendered string for serving. It uses Latin-1 as hardcoded character set for decoding strings:

https://github.com/zopefoundation/DocumentTemplate/blob/fe55d7d4f4324d3fed527d76812a2362165504d8/src/DocumentTemplate/_DocumentTemplate.py#L126-L141

Malthe Borch has a PR open at zopefoundation/DocumentTemplate#23, I'll see if I can massage to fit the current master.

@dataflake dataflake closed this in 671c687 Apr 25, 2019

Zope 4 final release automation moved this from To do to Done Apr 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
4 participants
You can’t perform that action at this time.