On 12 Dec 2007, at 8:16 PM, Adam R. Maxwell wrote: > > On Wednesday, December 12, 2007, at 09:44AM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> On 12 Dec 2007, at 6:03 PM, Adam R. Maxwell wrote: >> >>> >>> On Dec 12, 2007, at 5:18 AM, Christiaan Hofman 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. >>> >>> Didn't know that; I've never changed a field name or looked at that >>> code, so I'm not sure what the implications are. >>> >>> The delete should just delete the selected row, I think (and be >>> disabled for un-deletable rows). I'd use that action regularly >>> except >>> that it's so annoying to go through the sheet/popup for each >>> one...so >>> I end up leaving RIS imports with a bunch of junk fields. >>> >> >> It's not a question of what field to delete, but what "deleting a >> field" means? A field displayed in the editor may now already be nil, >> so deleting it would do nothing. > > If I select the Year field for a journal, the "Delete Field" option > should be disabled. Likewise, it should be disabled for required/ > optional/user-defined default fields. > >> The same for add: a field not >> displayed in the editor may actually be non-nil. In those cases >> addField: and removeField: do not work properly, because they assume >> that the field was nil or non-nil respectively. > > Under what circumstances do you have a non-nil field that isn't > displayed in the editor? >
that's my question: should we have those or not? My point is that now that we don't enforce a relation between (non)-nil fields and standard fields through makeType, a value of @"" should be equivalent to a value of nil. So as custom nil fields are not displayed, also custom empty fields should not be displayed. Otherwise empty strings can be added from switching types, as we don't remove those anymore. >>>> 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:. >>> >>> Yes, that does sound annoying >>> >>>> So should we display empty values? Note that those could be left >>>> over >>>> from type changes (or not?) >>> >>> I thought the datasource rebuilt every time the type >>> changed...should >>> have looked closer to see what's going on. I'd rather not see empty >>> values. >> >> Well, it rebuilds, but the question is: how should it rebuild? Should >> it include empty (but non-nil) custom fields or not? > > My answer is a qualified no, because I'm not sure how fields are > set to the empty string. So that answers your question above. 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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
