Compact Forms uses ugly inline JavaScript currently. We can do better in Drupal by leveraging Drupal's JS settings.
Attached patch not only implements Drupal.behaviors, but also does a major clean-up of the module's code, especially regarding FAPI and coding standards.
It also removes Windows line-endings in some of the module's files.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | compact_forms-HEAD-settings.patch | 2.19 KB | sun |
| #7 | compact_forms-HEAD.patch | 6.06 KB | sun |
| #6 | compact_forms-404132-2.patch | 8.12 KB | pounard |
| #5 | compact_forms-404132.patch | 8.11 KB | pounard |
| #3 | compact_forms-HEAD.loading.patch | 3.62 KB | sun |
Comments
Comment #1
christefano commentedThis is excellent. The patch is a bit hard to read but that's what happens with a major rewrite.
Comment #2
sunCommitted with slight optimizations/additions.
Comment #3
sunNow let's advance on this. It's completely senseless to load JavaScript settings on pages that do not contain a form that ought to be compacted.
Attached patch implements this.
Comment #4
pounardAlso look at patch at #452170: As I promised! Code cleanup, this patch overrides some things I've done, I think merging both should be good.
Comment #5
pounardAnd I did merged them, see attached patch
Comment #6
pounardMy error, "user-login" is the form when you get to mydomain/user and "user-login-form" is what you get in user login block!
I reverted this change!
My drupal see it as user-login-block indeed, tired to make useless patch, see last one attached and fix if you want:)
Comment #7
sunHm. Ok. I have extracted the usable parts from your patch. Please note that when speaking of "code clean-up", I'm referring to http://drupal.org/coding-standards of Drupal core and proper usage of Drupal core's APIs.
These are needless defines, which are of no value elsewhere. Even if one of them would be of some value, then a define would still be not appropriate. Drupal core is steadily moving away from defines as well (where possible), replacing them with more meaningful string identifiers.
This is a very debatable coding style. Some prefer it, most do not. The reasoning being that if one ever happens to add new array elements, then the entire array needs to be rewritten (bad).
That actually violates coding standards.
Sorry, but no - the condition was correct, because we only need to alter the form when certain configuration values are set. I've rewritten the condition now to clarify that.
Committed attached patch to 6.x (and also to 5.x).
Thanks!
Comment #8
sunOne last minor glitch - the configuration settings use wrong form elements for some options where simple checkboxes would be more appropriate.
Comment #9
pounardI think using constants is a way more consistent because you won't have to lookup why your code isn't working when you mis-typed something, it's old habit. In fact, I use constants every time the same fixed value has to appear more than twice (here, 3 time per value, and they are constants, even if you don't write as constants, they are fixed).
Remove it, keep this code as you prefer.
For the menu, it's still an old habit, sorry :)
The 0 value is inconsistent because of PHP, not because of signification of the option. If you try the !empty($my_value) on a user set value which points to zero, this won't work. PHP and mixed vars comparison is really annoying with this, be carefull when you use 0 value as an option constant. In PHP 0 means "void", and === usage and some other stuff may be really a mess if you give a real signification to 0 (somewhere else than using "real" int values).
I think even for a "void" option, 0 is dangerous, because you won't know if user set it, if your default value has not been set, or even if you are manipulating the right var.
But, thanks for applying! If you need help on some bugfixes/feature, please ask, I will happily apply your coding standards, this module is great :)
Comment #10
sunReverting status.
Note that these are not "my" coding standards, but the standards worked out and defined by the Drupal community for Drupal core.
Comment #11
pounardQuote from Drupal's coding standards:
Their exemple for array don't do such indent, but they don't say its bad neither.
They don't really talk about constants usage more than they have to be uppercased neither.
Comment #12
sunThere was actually more to improve... committed changes to all branches. Will publish new releases now.