I want to have part of my form be a CRUD for a taxonomy that will be initialised within the module. Therefore I need something similar to the taxonomy editing built-in to BD, including the drag/drop js to handle weights/parents. Is there an example of this somewhere? I have tried dissecting the taxonomy module, but it's spread over a lot of files, so was opaque. I looked at some D7 examples, but everything I tried to copy there threw weird PHP errors.
Most helpful answers
And if I implement things in this manner, is there a parent-child ajaxian form demonstration (ala taxonomy creation)?
Not sure exactly what you have in mind, but all layout settings forms are dialogs that are invoked from within the main layout form. It can be tricky. In a nutshell, you need to "ajaxify" a form element (e.g. a checkbox) (there are examples of this in the Examples for Developers module), which will build another form for you and send it back to the browser as a dialog. Upon submission of that form (the submit element of this child form needs to be ajaxified too) it will return the submitted form structure back to your ajax callback (specified within the #ajax property of the submit button). And here's the tricky part. Your form and form_state structures do not contain the values of the parent form, so you need to provide ajax commands to modify an element of the original form in the browser's DOM of the original form, for example, modify a select option to insert the id of the new term and select it.
@onyx. We have config_clear() that should do what you are after.
Comments
If I'm understanding correctly, you want to provide the ability to create a Taxonomy Term. Have you looked into using Entity Connect? That's a great little module that provides CRUD capabilities within the form.
- A few caveats: you'll need to use a Entity Reference field to reference the taxonomy term (not the core term reference field)
- The widget will redirect you to the core term creation/editing form, and then redirect you back to the original form. This may create some workflow issues if you are dealing with a multistep form (I think)
@argiepiano
Further to this, I see too many issues using Taxonomy to do what I want. So I'm considering how to make a similar situation with config_set variables.
I see config_del is not yet available. Any idea how far away that is?
And if I implement things in this manner, is there a parent-child ajaxian form demonstration (ala taxonomy creation)?
@onyx. We have config_clear() that should do what you are after.
And if I implement things in this manner, is there a parent-child ajaxian form demonstration (ala taxonomy creation)?
Not sure exactly what you have in mind, but all layout settings forms are dialogs that are invoked from within the main layout form. It can be tricky. In a nutshell, you need to "ajaxify" a form element (e.g. a checkbox) (there are examples of this in the Examples for Developers module), which will build another form for you and send it back to the browser as a dialog. Upon submission of that form (the submit element of this child form needs to be ajaxified too) it will return the submitted form structure back to your ajax callback (specified within the #ajax property of the submit button). And here's the tricky part. Your form and form_state structures do not contain the values of the parent form, so you need to provide ajax commands to modify an element of the original form in the browser's DOM of the original form, for example, modify a select option to insert the id of the new term and select it.
Rather than the tricky route, I went for MVP;
Now what I'd like to understand, is how to make these Statuses available as a Field and thereby within Views?
They are being saved in the settings json file of my module, like this:
"appstatus": [
{
"id": "1",
"name": "New",
"order": "1",
"parent": ""
},
{
"id": "2",
"name": "Contacted",
"order": "2",
"parent": ""
},
{
"id": "3",
"name": "Awaiting processing or training",
"order": "3",
"parent": ""
},
{
"id": "4",
"name": "Declined by organisation",
"order": "4",
"parent": ""
},
{
"id": "5",
"name": "Declined by volunteer",
"order": "5",
"parent": ""
},
{
"id": "6",
"name": "Placed",
"order": "6",
"parent": ""
},
{
"id": "7",
"name": "Finalised",
"order": "7",
"parent": ""
},
{
"id": "8",
"name": "No response from coordinator",
"order": "8",
"parent": "7"
},
{
"id": "9",
"name": "No response from volunteer",
"order": "9",
"parent": "7"
}
]
Views, in essence, is a wrapper around a database querying layer, combined with a display/templating layer. A views "field" is basically a reference to a query/display handler that adds joins, sortings and conditions to a database query, and then grabs the results and displays them in certain ways.
So, it's very difficult (if not impossible) to create Views fields for things that are not stored in the database. In your case, I think you are storing these in files. So, I think you'll have a difficult time making those "fields" available in views.
You could, however, write a views field handler that overrides the query() method with an empty method, and that retrieves the values from the config file within the render() method. It would not be very efficient, especially if the view is displaying more than, say, 100 rows, but it should be fairly easy to do. You'd need to include the new handler definition within a hook_views_data_alter() implementation, and then extend and override the class views_handler_field() with your handler's class.
As for displaying this as a field when a node is viewed (for example), you need to implement hook_node_view_alter() and add your "field" as markup to the render array. You may also implement hook_field_extra_fields() to create a definition for the display of the pseudo field, to allow the Manage Display UI to show your "field" and allow you to rearrange it in relation to the other fields within the display. You'll need to be sure that the key for the markup render array in hook_node_view_alter matches the key of your pseudo field in hook_field_extra_fields().
Views, in essence, is a wrapper around a database querying layer, combined with a display/templating layer. A views "field" is basically a reference to a query/display handler that adds joins, sortings and conditions to a database query, and then grabs the results and displays them in certain ways.
So, it's very difficult (if not impossible) to create Views fields for things that are not stored in the database. In your case, I think you are storing these in files. So, I think you'll have a difficult time making those "fields" available in views.