If at all possible, this module should attempt to use the same form element names and structure that node.module provides. That way, modules like Vertical Tabs and others that work on those options don't need to also write code to deal with the override node options module as well.

CommentFileSizeAuthor
#6 644820-ono-D6.patch24.58 KBdave reid

Comments

dave reid’s picture

dave reid’s picture

I want to write a patch, but I'm not sure which branch I should checkout for Drupal 6. Plus there is a *lot* of messy code. :/

joachim’s picture

The branch hell has been fixed by your good self :)
And as for the messy code (agreed, there's some terrible stuff in there), I've made quite a few commits today towards that. More remains to be done though: see #365570: code style cleanup.

Oh and is this relevant to this issue? #476510: Using just hook_form_alter, getting rid of hook_nodeapi.

joachim’s picture

Just a note to say that I've added tests for this module.
These use the current special form element names, so changes made for this issue will need to alter the tests too. On the plus side though, they should make it much easier to check this sort of deep alteration to the module doesn't break anything!

dave reid’s picture

Please also help review this D7 issue to make this easier: #668806: Include revision form element with access control

dave reid’s picture

Status: Active » Needs review
StatusFileSize
new24.58 KB

Working patch will all tests passing. I appreciate all the work that Joachim put into writing tests, they needed to be simplified, a lot. It's much easier to understand what is going on and work on the tests when we break them up into re-usable chunks, but not-too-general chunks that things don't make sense. Please test and review.

joachim’s picture

You seem to be completely replacing the test file I made.

I understand that it may be harder to grasp initially -- though I did put plenty of comments in. It's actually fairly simple: one big array of settings, and then some classes do all the work. Your own work on this would have been extremely simple, as all you had to change in the .test file was some values in the data array:

        'form_name_override' => 'override_publishing_status', // you've changed this form item name, so change it here too

-- the test classes would have done the rest for you.

The test file could then have been simplified as we no longer needed to work with two different form keys, so could replace 'form_name_override' everywhere with 'form_name_normal'.

If the only problem with my version of this was that you didn't manage to follow what was going on, then I'd rather you'd asked me to deal with the reworking it needed for this issue rather than have it completely changed; it's a little disheartening.

dave reid’s picture

I didn't want or mean to discourage you. I know it's basically replacing the tests that you wrote. :/ I can follow tests pretty well, but the thing is that we don't really do tests this way as has been standardized in core. For instance there's specific things that needed to be tested with authoring information and validation that did not need to be run with other tests, and would not have been possible with the level of generalization that was currently in the tests. It's also much more difficult to debug if things go wrong.

dave reid’s picture

Status: Needs review » Fixed
joachim’s picture

Just took a look at the latest release -- our hook_form_alter is hugely slimmed down and much easier to follow. Nice job all round. And fair enough about the tests. :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.