in content_admin
hook_widget_setting op=form is invoked with $field['widget']
hook_widget_settings op=validate and op=save are invoked with $field.

I personally think we should just pass in the widget to help enforce a clean seperation of data layer and input, however, the additional context could be useful for developers. Any opinions before I roll a patch tomorrow.

CommentFileSizeAuthor
#2 108491.patch735 bytesdopry

Comments

yched’s picture

yched commented

I think http://drupal.org/node/93704 is related to this.

I guess theoretically I'm also inclined towards clean concepts separation, but It is more a feeling than a strong opinion.

PS : your fix for this sneaked in the patch you submitted in the 'formatter matrix' thread, I removed it in the last version I submitted :-)

dopry’s picture

dopry commented
StatusFileSize
new 108491.patch735 bytes

I decided the full field context is consistent with the other two module invokes, and we need a simple way for fields to share data/context with widgets. Some widgets may need some updating.

dopry’s picture

dopry commented
Status: Active » Needs review
yched’s picture

yched commented

I'm for harmonizing this per se, problem is it will break all the current hook_widget_settings('form') implementations out there...

Maybe we should keep that for later ?

yched’s picture

yched commented

BTW, it's surprising to see that despite the difference in the argument between ops 'form' and 'validate',
text_widget_settings does handle the $widget argument the same way in it's 'form' and 'validate' ops...
(text.module is one of the only modules that actually implements 'validate' for hook_widget_settings)

dopry’s picture

dopry commented

Karen, Yched,
How do you guys feel about this patch? Should I go ahead and roll it for all the field modules?

yched’s picture

yched commented

"All field modules" : do you mean also contrib field modules ?

Not sure about that - I guess my comment in #4 still stands...

Since branch 5 was officially released, we sticked to _adding_ things to the API and not actually changing the existant one... Do we consider OK to have rules like 'contrib_field 1.4 requires CCK 1.5 which works best with Views 1.6 etc...' ?

Well, with 'update status' module being there now, maybe it can be acceptable to say 'latest version of A.module work with latest versions of the related B.modules' ? I just want to check we're OK with this.

I got almost flamed the other day about 5 secs after entering #drupal IRC for my first time ever because webchick thought we had changed the db scheme yet again. They were looking for you, guys, I never hang out there ;-)

(i posted something similar in http://drupal.org/node/136697#comment-233215 - after saying amen to the commit)

karens’s picture

karens commented
Status: Needs review » Closed (won't fix)

The D5 version is no longer being supported. Sorry.