Now the editor and the item disagree of the fields of an item, leading to
inconsistencies (e.g. for field add/del). I propose to let BibItem handle
the equivalence of empty/nil fields. What I propose:
- Never return nil from valueOfField: (i.e. return @"" for unset fields).
- Ditch addField:/removeField:, always use setField:toValue: (so the Editor
supplies the initial value).
- When setting a field to an empty string, remove it from pubFields.
- Only a BibItem change notification, no Add/Del Field notification.
- Let the Editor decide whether fields have to be setup. When either old or
new is empty, setup the fields, and let setupFields return a BOOL, doing
nothing when the fields stay the same.
- In allFieldNames, return standard + nonempty field names (as the fields
array in the Editor), as the keys in pubFields have basically lost their
meaning.

What about this?

Christiaan

On Dec 12, 2007 2:18 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote:

> Now that you've removed makeType:, how should we handle empty fields
> in the editor? Right now things are inconsistent, as in some places
> empty strings are equivalent to nil, and in other places they're not.
> For example, adding, removing, and changing a field name still assume
> that non-displayed fields are empty and displayed fields are not
> empty, which now is wrong. It's a bit annoying to add explicit checks
> for empty strings, as +isEmptyString does not work correctly for
> complex strings. Perhaps we should have an +isEmptyAsComplexString:.
> So should we display empty values? Note that those could be left over
> from type changes (or not?)
>
> Christiaan
>
>
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop

Reply via email to