English > Feature Suggestions

Default values

<< < (3/3)

patch:

--- Quote from: rick.ca on June 25, 2010, 03:01:37 pm ---It seems clear to me that if the edit bar existed (including the ability to save edits) and we were considering your suggestion, the response would be, "Why don't you just use the edit bar?

--- End quote ---
Having an efficient means of editing is different from having a field for which a default value other than null is most efficient.
That is why "seen" is implemented that way. The concept can be generalized.
Editing needs to be done every time a record is created (batched or not), unlike the value of a useful default which should rarely need changing (but may occasionally need to be altered after importing on a per record basis).


--- Quote from: buah on June 25, 2010, 12:08:50 pm ---
--- Quote from: patch on June 25, 2010, 10:47:04 am --- The harder question is does the utility justify the programming effort?

--- End quote ---

Knowing nostra so far, the only question is if he likes the idea or not, regardless needed effort. ;D

--- End quote ---
I believe nostra has a very long todo list and is aware he is a limited resource, so is going to daily pass over good ideas in favor of ones that uses his time more efficiently.

rick.ca:

--- Quote ---That is why seen is implemented that way. The concept can be generalized.
--- End quote ---

Thanks for clarifying, but I believe I understand the issue. If there were other fields like Seen and Wish for which defaults would be useful, I would readily agree. But it's in the generalization of the concept that it becomes apparent the same approach will not work as well as a more flexible one. Yes, some users will add custom fields which are very similar to Seen in this regard, and would therefore benefit from the ability to set a default. But if we're generalizing—and I would argue we have to if there's any point to this—then what about fields for which the defaults vary (like the majority of buah's examples). These need an efficient way to change the defaults on-the-fly. If they have to be set as a usual configuration setting, it becomes more trouble than it's worth (because of always having to check and adjust the defaults). But regardless of how it works, if the defaults have to be set (or even just checked to verify they're set correctly), then it's more effective and efficient to simply set the values using an edit tool.


--- Quote ---Editing needs to be done every time a record is created (batched or not), unlike the value of a useful default which should rarely need changing (but may occasionally need to be altered after importing on a per record basis).
--- End quote ---

While we're being redundant...I don't disagree—if the default value rarely needs changing. But this is not an appropriate solution to buah's use-scenario where most of the fields do change according to the type of item being added. In fact, I think that was the main point of his suggestion—that when a batch of like items are being added, it would be convenient to be able to set defaults.

rick.ca:
Consider this an aside, not an alternative solution to the issue...

It occurs to me the setting of default values could also be accomplished by using a script. This would be less efficient than a direct edit of multiple files, but it would be easier to build into a work flow. Such a script could be included in a batch file and subject to field overwrite settings, providing some flexibility over the outcome. Different versions of the script could be used for different default "sets."

What I'm thinking of is a script where the default values are set directly in the script using statements such as...

AddFieldValue(mfMPAA, 'Not rated'); and
AddCustomFieldValueByName('Collections', 'Criterion');

...but despite the fact that has to be dirt simple, I can't figure out how to do it.  ::)

BTW, if a script is being used anyway, the setting of any never-changing default values can be done directly by that script.

Navigation

[0] Message Index

[*] Previous page