Proposal: Establish a naming convention (and/or enforce one, but that probably won't be so popular...) so that all form definition functions in core are whatever_form(). This would make all validate/submit functions are whatever_form_validate/submit() and all form theme functions theme_whatever_form().
Pros:
a) Makes it easy to tell at a glance what functions are related to forms and belong together.
b) No more searching API functions and coming across something like system_modules() and thinking it does something entirely different from what it actually does.
c) Consistency!
Cons:
Absolutely none! ;) Unless someone has any objections. :)
Comments
Comment #1
sun.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commented+1
(I always wanted to do that one day)
Comment #3
sunTagging for feature freeze.
Comment #4
sun@webchick: Is this too API-changish or can we still quickly squeeze this in?
Comment #5
webchickNope.
Comment #6
mbrett5062 CreditAttribution: mbrett5062 commentedI am wondering if a naming convention for all functions would not be more useful. I.E. extend this to everything Drupal.
Why just Forms, why not Files and Fields, and everything.
I see all over different naming conventions.
I would propose that we follow the same structure throughout.
whatever_thing_function
more concisely (In what context are we working)_(what are we working on)_(what do we want to do with it)
ie
file_extensions_validate ------ (currently = file_validate_extensions) -1
file_data_save ------------------- (currently = file_save_data) -1
file_content_headers_get ---- (currently = file_get_content_headers) -1
file_usage_delete --------------- (currently = file_usage_delete) +1
node_type_save ----------------- (currently = node_type_save) +1
node_body_field_add ---------- (currently = node_add_body_field) -1
node_content_build ------------ (currently = node_build_content) -1
node_search_admin ----------- (currently = node_search_admin) +1
drupal_form_submit ----------- (currently = drupal_form_submit) +1
form_cache_set ----------------- (currently = form_set_cache) -1
drupal_form_process ---------- (currently = drupal_process_form) -1
drupal_form_validate --------- (currently = drupal_validate_form) -1
form_select_process ---------- (currently = form_process_select) -1
As you can see from the very few examples, we have no consistency anywhere, -1 being different to how I feel it should be done.
Of course this is just my opinion, how this would be ordered is for the team to decide, but consistency is key I believe.
Hope this is of some use to someone who would like to champion this. @webchick :)
Comment #7
TravisCarden CreditAttribution: TravisCarden commentedThis problem behind this issue has been solved now that forms are defined as classes. (Yay OOP!)
Comment #8
sunI don't think that is true. Some form constructors were moved into classes, but their form IDs did not change.
In fact, inconsistent and weirdly named form IDs are even more confusing now that the form ID is buried somewhere in a method of a class, whereas the containing class has a different name. → We have a new discovery DX problem in addition to inconsistent form IDs now.
I don't know what we can do about this, but discovering the form ID (and code) of a form to integrate with or alter requires you to grep the code base now, in order to find the containing class, and in order to find the internal form ID.
Any ideas anyone?
Comment #9
webchickEver since #2109035: Make access checkers (much) easier to find went in, I've been wondering if we could use something similar for form IDs, too. However, Crell didn't approve, I think because it would couple form IDs to a route definition. Though I suppose the method would still exist for those forms that weren't defined by routes (search form block, for example).