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? ------------------------------------------------------------------------- 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
