#12 — "Blankness" of name fields is atomic

by Frank Bennett — last modified Dec 20, 2009 03:50 PM

State	Confirmed
Version:	0.8.0
Area	User interface
Issue type	Bug
Severity	Low
Submitted by	Frank Bennett
Submitted on	May 17, 2006
Responsible	Raphael Ritz
Target release:	—

Return to tracker

This is probably an ATExtensions issue, but since there is no tracker over there, I'll mention it here. If there are two authors of a work, and the first author mentioned is an institution, the user may enter the institutional name in the "last name" field, and the individual's name in a second "first name" and "last name" field. When the form is saved, the first name of the second author is promoted to the first line, as if it were the "first name" of the institution.

Correct behaviour would leave the fields as the user has written them.

Steps to reproduce:: As above.

Added by Raphael Ritz on May 17, 2006 09:05 AM

Issue state: unconfirmed → open

Responsible manager: (UNASSIGNED) → raphael

It's correct that this is an ATE issue but the real bug is in Zope's 'records' packaging directive which simply cannot deal with situations in which the first element of a new record in a list of records is empty.

So to work around this, you have to make sure the first (sub) field is never empty (maybe even a hidden one which only gets populated when any other subfild of that record gets populated - JS anyone?). One way to do so could be to change the oder of the subfields to always start with the last name and to make it required. I'll note in passing that when enabling references for authors (configurable in ZMI) you get around this because the reference subfield is never empty.

Suggestions on how to really fix this welcome!

Added by Tim Hicks on May 18, 2006 09:37 PM

Frank,

From the timing of the checkin, I'm assuming that you are "bierce" and therefore the author of http://svn.plone.org/view/collective/BibFactoryFix/. I haven't tried it out, but from looking at the README, it looks like a candidate for a CMFBib branch (pending approval and merging) rather than a separate product.

Do you or Raphael have any views on this?

Tim

p.s. In case you didn't know, there is a mailing list for discussing CMFBib-and-friends @ https://zaubberer.net/mailman/listinfo/plone-biblio. Hope to see you there :).

Added by Frank Bennett on May 19, 2006 01:33 AM

Tim,

I guess this is about the other issue, but I'll respond here.

No objections to putting BibFactoryFix into a branch, but it raises issues larger than CMFBibliography, and a little product like this helps to illustrate what the problem is, for a wider audience.

There are several use cases where it might make sense to tinker with an object while it is still inside portal factory. For example, one might have a date field, and want (through transactions, not JS) to offer a scrollable calendar from which the user can select a date. To give the user a new calendar view, you need to go through a new transaction, just like you do with the Authors field in CMFBAT.

In default Archetypes processing, the new transaction will finalize the object, which you don't want to do because the user is in the middle of filling out the form for the first time, and there will be empty fields. With the minimal workaround of an override in portal form controller that does a redirect (which is what CMFBAT 0.8.0 does), it still triggers validation, which is not rational.

All you need to make things right is to suspend validation while passing control back to the base_edit form. My patch product does that with (I think) minimal code; but to do so, it skins over validate_base.vpy, from Archetypes itself. The changes made do not affect normal validation processing, but permit suspension for a single transaction -- which is all we need to solve this problem.

So I think this needs to be thought about by the Archetypes people as well. That's the reason for distributing the product as a code sample. That, and it might help people who, like me, are using the current release of CMFBAT.

I'm only trying to help. :)

Added by Raphael Ritz on May 19, 2006 06:56 AM

Thanks for your effort and contribution Frank!

I agree with you that this isn't really a CMFBib issue but rather an Archetypes and ATExtensions one.
As soon as I find some time to look deeper into this I'll apply your patch at least to ATExtensions.
Whether we really have to patch Archetypes as well I don't know yet but if so we'll go for it.

Raphael

Added by Tim Hicks on May 19, 2006 09:05 AM

Frank,

Yeah, sorry, this is attached to the wrong issue, really.

I'll certainly bow to your (and Raphael's) better judgment as to whether this is a CMFBib, AT, or ATExtensions issue. I just wanted to make sure that your code ends up in the place it will make the most difference (wherever that may be). It seems you're already on that case though :).

Thanks for doing this.

Tim

Added by Frank Bennett on May 19, 2006 09:57 AM

Raphael, Tim,

Thanks! I've only recently come back to the console, to start building some tools for use by students next term, and I'm pretty much in awe of the architecture that has emerged from the 2.1 development process. This is really amazing stuff.

As for CMFBibliographyAT, I was a little shocked to find a complete port of the BibTeX types to Plone. Raphael has made things soooo much easier by this offering.

I'll sign up for the mailing list soon, and ... do a bit more studying!

Cheers,
Frank Bennett

Added by Andreas Jung on Dec 20, 2009 03:50 PM

Severity: Medium → Low

No responses can be added.