On 12 Dec 2007, at 8:39 PM, Adam R. Maxwell wrote: > > On Wednesday, December 12, 2007, at 11:22AM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> 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. > > I think we have a terminology issue here; what is the scenario for > this? Are you talking about one-off custom fields that are added > with the + button, then the user switches types without setting > that field to a meaningful value? Those seem to be removed when > switching types if the field is empty, and that's expected behavior > as far as I'm concerned.
Any case that adds empty strings as a field value, for a field that at some point is not a standard field. This could be when the type changes. They don't need to be custom fields at the time they're created. E.g. a standard type for one field could be an empty string and is displayed. When you switch type, it may not be a standard field anymore. So should it be displayed? Empty non-standard fields are now not removed anymore, as that was happening in makeType. 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
