: > it might be worth considering a new @attribute for <fields> to indicate : > that they are going to be used purely as "component" fields (ie: your : > first-name/last-name example) and then have DIH pass all non-component : > fields along and error if undefined in the schema just like other updating : > RequestHandlers do. : > : > either that, or require that people declaure indexed="false" : > stored="false" fields in the schema for these intermediate component : > fields so that we can properly warn then when DIH is getting data it : > doesn't know what to do with -- protecting people from field name typos : > and returning errors instead of silently ignoring unexpected input is : > fairly important behavir -- especially for new users.
: Actually it is done by DIH . When the dataconfig is loaded DIH reports : these information on the console. though it is limited , it helps to a : certain extent Hmmm. Logging an error and returning successfully (without adding any docs) is still inconsistent with the way all other RequestHandlers work: fail the request. I know DIH isn't a typical RequestHandler, but some things (like failing on failure) seem like they should be a given. -Hoss
