Updated: Comment #N
Problem/Motivation
We still have methods like views_form_validate, views_form_submit.
Proposed resolution
Camelize them. I have stuck with viewsForm* as it is then clear that this is invoked in the context of a actual rendered view. we have validateOptionsForm() etc.. already, I'm happy to change to validateForm etc.. but this might be confusing, unless we have any better naming suggestions?
Remaining tasks
Do it
User interface changes
None
API changes
Any views form implementations will need to change their method names.
Related Issues
#2110953: Change record: Convert views_forms() to a classed form - This patch may conflict with that one currently, so get that one in first. This initial patch is what it needs to be in the new viewsForm class methods.
Comment | File | Size | Author |
---|---|---|---|
#5 | 2123843-5.patch | 8.49 KB | damiankloip |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedJust a reroll.
Comment #2
damiankloip CreditAttribution: damiankloip commented*^%#^$%^&$#$####
Comment #3
dawehnerNice work!
Comment #4
webchickNo longer applies.
And... I guess this still makes sense to do, for consistency's sake, so adding the tag. I really would love to see us stop this sort of API polishing soon, though. How many of these camelize things are left until we're done?
Comment #5
damiankloip CreditAttribution: damiankloip commentedThat's a fair point :) This *IS* the last one. I just grepped the codebase to double check and this seems to be the last one in views classes...
There was flawed logic in the creation of the great views camel casing issues of 2013 I'm afraid (I think it was the views plugin base classes that were used, so didn't quite catch all the the things).
Comment #6
damiankloip CreditAttribution: damiankloip commentedSo, based on that - back to RTBC?
Comment #7
dawehner+1 for RTBC, I would not be sure that this is the last one, though there won't be many, this is sure.
Comment #8
webchickOk, cool. Committed and pushed to 8.x. Thanks!