On 12 Dec 2007, at 9:38 PM, Adam R. Maxwell wrote: > > On Wednesday, December 12, 2007, at 11:58AM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> 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. > > If I hit cmd-n for a new @article, then click the + button to add a > custom field called "Test" it's filled in with some default > values. If I switch the type to @book, the Test field is > preserved. All non-book empty fields are gone. If I delete the > content of the Test field and commit the edit, it's still present. > If I switch back to @article, the Test field is gone. So what case > adds empty strings to a field value?
That's because I explicitly have implemented it that way now (see the extra argument to the AddField macro). My question is: should I have done it that way 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://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
