Fields, the chicken-egg scenario duex.
Posted 27 May 2012 - 06:25 PM
Field options, valid for only a specific field type.
how does one add said function at this point?
A: Library hook onto cp_skin_database_fields, add form HTML conditionally on field type and only on edit.
B: Action overload the save method in admin_ccs_database_fields, do mojo, return parent, again, only on edit.
C: Library hook onto cp_skin_articles, to add further HTML for here... again, only edit.
D: Action overload admin_ccs_articles_fields, do more mojo conditionally based on the saved field type, return parent.
E: overload admin_ccs_ajax_fields.php to correctly add the html on that ajax swap there.
These 5 steps are all AFTER having made the field source in whole, simply to add desired admin configurations.
The worst of it?
We have that self-same ACP chicken-egg scenario, in that the user must add, then edit the field to see one field's valid options, as adding options for the save is entirely infeasible while allowing natural hook flow(as in returning the parent).
The field ACP options direly need to be abstracted out to control at the field source level for these reasons in my humble opinion.
Posted 28 May 2012 - 02:31 AM
Basically, the problem in a nutshell is one data hooks attempt to address... I say attempt as this is quite rarely implemented in the ACP, and when it is, usually on the "content" inserts, and almost never the "container" and "field" levels.
Is quite literally the inability to add additional data to be saved on addition cleanly.
Posted 29 May 2012 - 05:44 AM
it would be the most longterm universal solution in all of this to be able to parallel-access the $vars set within action methods being overloaded by hook, it is the frustration at the head.
One Can see the data set up in the source, but cannot access it within these methods, and that could be put to an exhausting amount of usage where data hooks are added now...
Simply thoughts..... yours?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users