This issue is about not optimal code patterns being used in the actions system. I'll try to make a little introduction to the issue.
Certain actions can have parameters, which are stored as serialized data in a "parameters" field in the table.
When dealing with actions, the current approach in core is to directly select actions from the actions table and deal with the rows directly. This means manually unserializing the "parameters" field each time you get a row from the actions table.
Current code also provides an actions_load($aid) function which consists of just a db_fetch_object/db_query call. This function is used only once in all the core codebase.
This patch suggests the introduction of a new function called actions_unpack($action) which takes an $action database object and unserializes the parameters field. It also corrects the code in actions.inc and system.module to conform to this new change.
The pro's for this patch are:
* a little cleaner code throughout core;
* the actions_unpack function could be easily extended with a hook to be able to manipulate actions parameters and for example, make them language-aware (see #340657: Save actions settings by locale for details)
Comment | File | Size | Author |
---|---|---|---|
#5 | improve_actions_code.patch | 3.36 KB | flevour |
#2 | improve_actions_code_D7.patch | 3.41 KB | flevour |
#1 | improve_actions_code.patch | 3.31 KB | flevour |
Comments
Comment #1
flevour CreditAttribution: flevour commentedI attach a patch rolled against Drupal 6 just as an example.
Comment #2
flevour CreditAttribution: flevour commentedRolled against D7. In system.module it saves the rewrite of a query too :)
Comment #3
snufkin CreditAttribution: snufkin commentedThe code itself does look cleaner, but it could be more.
It introduces two new functions, actions_load and actions_unpack. The only purpose for actions_unpack is to unwrap the parameters field, and thus it is used when actions are loaded in actions_do.
Implementing an actions_load is a great idea, but lets go one step further! The idea in these load functions is to separate the SQL handling into one function, and let the rest of the code just do its stuff. Doing so we can get rid of the actions_unpack, since its functionality would only be needed in actions_load, moreover we could also remove the SQL from actions_do. This needs an extension to actions_load, some way to pass those WHERE conditions into the loader.
Comment #4
flevour CreditAttribution: flevour commentedHi snufkin, thanks for the review.
The purpose of having actions_load separated from actions_unpack is there are scenarios where you want to _unpack an actions db row that doesn't come out of an actions_load. For example in the patch you can see the first hunk using action_unpack while looping through a "SELECT * FROM actions" db result.
Does this make any sense?
One more possibility would be to make a refactored actions_load which can take as argument either an $aid (or an array of $aids, as node_load) or nothing and return the selected actions or all the actions respectively. This way actions_load could contain the logic that I have put in the actions_unpack function.
Cheers,
Francesco
Comment #5
flevour CreditAttribution: flevour commentedRe-rolling against head, chx spotted a construct error.
Comment #6
snufkin CreditAttribution: snufkin commentedYes, i completely understand, my suggestion was to remove the need to have a "SELECT * FROM actions" db result at all, and be able to load the actions fully with actions_load.
Comment #7
Jooblay.net CreditAttribution: Jooblay.net commentedWhat is the status of this ticket:) Can we close this...