Add/Create records form for entities

Changing this to a feature request.

Well there's already a form, just that it expects to have an existing Data entity to edit.

Most entity types use the same form for add and edit, and just wrap it up for the add page with something that creates a new entity (but doesn't save it) for the form to work with.

The same pattern should be doable here.

Anyone working on this? We have situations where we would like to avoid importing via feeds when we only have a few rows to add.

The way things usually work is that if someone were working on this, they'd probably post here to say so. If you need this feature, perhaps you can work on the patch?

Yes building a patch or custom module is what's next. Just asking if anyone has found a way to insert rows using another modules UI.

I made a patch to provide a form to add items. See attachment.

Great, we are working on a custom module which uses Sheetnode to manage the table. Using the Data Module view we can filter the table and with the Sheetnode display we are able to manage the data within the table. Edit,Delete,Modify,Add to Data table. I will report back if anyone finds this interesting.

Thanks for the patch (remember to set to 'needs review'). A few unrelated changes though -- maybe you should try using a git local branch to keep separate the changes for different issues you're working on?

1. +++ b/data_entity/data_entity.pages.inc
   @@ -5,6 +5,13 @@
   + * Form wrapper to add data entities
   + */
   +function data_entity_entity_add_form($form, &$form_state, $table, $data_entity = NULL) {
   ...
   +}
   +
   

   I'm not sure why we need a wrapper form here. Can't we just use data_entity_entity_edit_form as the form builder in hook_menu(), and pass it the $table param?

2. +++ b/data_entity/data_entity.pages.inc
   @@ -14,26 +21,39 @@ function data_entity_entity_edit_form($form, &$form_state, $table, $data_entity
   +  if (!is_null($data_entity)) {
   ...
   +  else {
   

   It's more readable to avoid a negative if() clause if you also have the else -- flip them round. Though you can also just say if($data_entity) ad rely on PHP type juggling and keep the two clauses in the same order.

   Either way, a comment at the top of each block to explain which scenario we're in (editing vs add) would be good.

3. +++ b/data_entity/data_entity.pages.inc
   @@ -14,26 +21,39 @@ function data_entity_entity_edit_form($form, &$form_state, $table, $data_entity
   +
      $form['#entity'] = $data_entity;
    
      $form['data'] = array(
        '#tree' => TRUE,
        '#weight' => -100, // Ensure this goes above fields.
      );
   +
   

   Please avoid whitespace changes!

4. +++ b/data_entity/data_entity.pages.inc
   @@ -43,7 +63,7 @@ function data_entity_entity_edit_form($form, &$form_state, $table, $data_entity
   -      $description .= t('The id field can not be edited.');
   +      $description .= $description_id_field;
   

   I don't understand this change.

5. +++ b/data_entity/data_entity.pages.inc
   @@ -77,8 +98,9 @@ function data_entity_entity_edit_form($form, &$form_state, $table, $data_entity
   -  $data_entity = $form['#entity'];
   -  $entity_type = $data_entity->entity_type;
   +
   +  //$data_entity = $form['#entity'];
   +  $entity_type = $form['#entity_type'] ;
   

   Why is this being commented out?

6. +++ b/data_entity/data_entity.pages.inc
   @@ -109,8 +129,19 @@ function data_entity_entity_edit_form_submit($form, &$form_state) {
   +  if ($form_id == 'data_entity_entity_edit_form') {
   +    $record = $form_state['values']['data'];
   +    drupal_write_record($table->name, $record, $table->table_schema['primary key']);
   +    // Save additional fields provided by users through UI.
   +    field_attach_update($entity_type, $pseudo_entity);
   +  }
   +  elseif ($form_id == 'data_entity_entity_add_form') {
   

   Don't really like using form_id to change logic.

   I forget, are we depending on Entity API? That adds an $entity->is_new property to use for this sort of thing.

   Or you can check for the presence of an entity ID to see if this is an insert or an update.

7. +++ b/data_entity/views/data_entity.views.inc
   @@ -35,6 +35,14 @@ function data_entity_views_default_views_alter(&$views) {
   +
   +      /* Header: Global: Unfiltered text */
   +      $handler->display->display_options['header']['area_text_custom']['id'] = 'area_text_custom';
   +      $handler->display->display_options['header']['area_text_custom']['table'] = 'views';
   +      $handler->display->display_options['header']['area_text_custom']['field'] = 'area_text_custom';
   +      $handler->display->display_options['header']['area_text_custom']['label'] = 'add_link';
   +      $handler->display->display_options['header']['area_text_custom']['content'] = l('Add item', 'admin/content/data/entity/' . $table_name . '/add', array('query' => array('destination' => 'admin/content/data/view/' . $table_name)));
   +
   

   Not sure what this change is about.

I have modified the code according your suggestions.
The last part (7) adds a link for "adding items". See attachment.

Needs review

That's looking much better thanks!

I'm still not quite sure this is the best way to be handling both cases in the form.

1. +++ b/data_entity/data_entity.module
   @@ -181,7 +191,7 @@ function data_entity_permission() {
   -      'title' => t('Edit data in the %table_name table', array('%table_name' => $table->title)), 
   +      'title' => t('Edit data in the %table_name table', array('%table_name' => $table->title)),
   

   Still got this unrelated change, and a whitespace change too.

2. +++ b/data_entity/data_entity.pages.inc
   @@ -12,23 +12,29 @@ function data_entity_entity_edit_form($form, &$form_state, $table, $data_entity
   +  if (is_null($data_entity)) {
   

   I suspect that leaving the entity as NULL will cause problems with things like field_attach_form().

   It would be better, and more consistent with other entity type modules, to use entity_create() and create a new, blank entity. For that you need to define an entity create callback.

3. +++ b/data_entity/data_entity.pages.inc
   @@ -95,22 +101,28 @@ function data_entity_entity_edit_form_validate($form, &$form_state) {
   +    $record = $form_state['input']['data'];
   +    drupal_write_record($table->name, $record);
   +    field_attach_insert($entity_type, $pseudo_entity);
   

   How will $pseudo_entity get its ID? field_attach_insert() needs it to save field data. Surely you need to be passing that to drupal_write_record(), so it then gets the ID populated.

This would be a great feature for a lightweight database without the usual field overheads.

Would it be worth hooking into Entity API's CRUD UI? #920546: Entity CRUD generic UI

Related D6 Data issue: #524270: CRUD UI for DataTable data

Entity Admin UI Documentation

perhaps its just me, but I can't get the patch in #12 to apply correctly. It tells me that Hunks 1 and 3 fail, at 107 and 191 respectively.

I'm having a look at this and have refactored the original plan a bit, but am having problems with the Edit link in the view. Currently the base_field is the primary key when in this case it really should be the entity ID.

These are separate and can be different.

Here it is. There are a couple of changes to current behaviour. The entity ID and primary key(s) can be different and because we're dealing with entities here we should probably use the entity ID.

1. The edit link now uses the entity ID instead of the base_field (primary key?)
2. drupal_write_record() uses the entity ID, which isn't editable, instead of the primary keys, which are, as the primary key when updating

Our PK and Entity ID are different and it didn't work until we made these changes. I'm not sure what ramifications these have but it seems to be working well for us.

Future feature requests

• Cancel button on Edit/Add page
• Delete link or button

Use empty() to properly check for is_new.

Guys,

Could you please explain how can I get the form which is seen on 3.png (#12)?
I have applied the patch and created a table via data table gui...

BR

Go to Content -> Data Tables and click on the table name.

There's also a handy content link in the text above the list of tables under Structure -> Data Tables.

Thanks, but still nothing... I am using Commerce Kickstarter, but I do not see how could this affect it.
I have applied the patch to data-7.x-1.x-dev.

Are there any other requirements, such as, does the new created table has to be marked as an entity?

The 'edit item' link was not present on my View so I added it, but alas it doesnt link to a form, only to the page with data tables.
Sorry, I think I understand what to do, but I still need the path and name where I should link to (and combine it with a replacement to identify the row).

This is a notice I get: Notice: Undefined property: stdClass::$IDAccess in data_entity_views_handler_field_edit_link->render() (line 28 of /home/theorich/public_html/sites/all/modules/data/data_entity/views/data_entity_views_handler_field_edit_link.inc).

As said , I have added the 'edit link'- field myself in the View, but I do not see that field on the Configure Views page (with all the handlers).

> Notice: Undefined property: stdClass::$IDAccess in data_entity_views_handler_field_edit_link->render() (line 28 of /home/theorich/public_html/sites/all/modules/data/data_entity/views/data_entity_views_handler_field_edit_link.inc)

It would help if you pasted the code at that line. I don't see any mention of IDAccess in the patch, so as such I'm not sure how this is relevant here.

Patch? I havent patched. IDAccess is the primary-key field of my adopted table. I know this thread is for a large part about a patch, but also about the 'edit item'- link in the View which is my problem.

Ah, I've only just see that you changed the title of this issue back in December. I'm changing it back, as that changed the scope of this issue. This issue is about adding a form to create new entities. If you have problems with the edit link, that's not related to this and should not be discussed here.

Sorry. I wasnt aware that I changed the title of this thread. I have no idea how to do it, but apparently it is very easy. I'll start another thread.

The patch in #21 applies cleanly on 1.0-alpha7 (but not on 1.x-dev).

Couple of notes:
- Re #22-24: if the table (and therefore the view) already existed, you have to revert the view so the "Add item" link is added to it. Not sure if this should be done in the patch, someone might have customized the view already?
- The table must be declared as entity. Then you have to also "Configure entity form" (newly added tab after declaring as entity type).
- The primary key of the table must be set to auto_increment (which you can't do from the UI directly, I think).

Thanks, it's working nicely!

Thanks for the review! Sounds like this needs work.

Thanks @ar-jan.

- Re #22-24: if the table (and therefore the view) already existed, you have to revert the view so the "Add item" link is added to it. Not sure if this should be done in the patch, someone might have customized the view already?

The link could potentially be added to an existing view with a views alter hook.

The primary key of the table must be set to auto_increment (which you can't do from the UI directly, I think).

The primary key doesn't need to be auto_increment, the entity ID field does. These can be different fields.

The easiest way to get this working is to create a Serial field within the UI and set it as the entity ID field.

Ah you're right of course, I had made the primary key the entity ID (and used integer because it uses less storage space than serial). Just wanted to document this for others.

@ar-jan, I misread the existing view problem in #31. I'm not sure the module should force revert the view. Any changes made to the view outside the module would be overwritten.

The change is already in an alter hook, and from memory I didn't need to revert anything. Clear cache perhaps?

I've added an update hook to add the link to existing views. I haven't tested it yet.

2 minor style fixes.

Thanks, the patch works as expected.

+1 works

Correcting 1 line that was causing the entity to not save.

There appears to be an issue with regards to saving "fields" attached to the custom table entity.
They do not get saved when creating a new record. however, on editing the same record and saving, they are saved.

updated patch.

Another patch for the remaining functionality - delete entity.

Arguably minor, but: data_entity_update_7001() in #43 (note #43 and #44 are separate patches) needs to end with a call to views_invalidate_cache(), to make the link actually show up.

I'll see if I can come back to this later and do a proper review, but for now this is a quick hit-and-run partial review while testing. (Otherwise I'll forget this. Current workload / number of patches I'm juggling doesn't allow for being more organized, sorry.)

Hmmm that may not be true. Reverting status.

The reason an "add" link was not showing up in the table (which is still empty, which I have just created an hour ago and done nothing with except turning "entity-ness" on in admin/structure/data/edit/TABLE/entity-type)... is that CTools/Views has saved the definition to the database. So we'd need to actively revert the view.

I'm not sure if it is the business of this module/update hook to automatically revert views. OH! this discussion has already been had in #35 and before...

The change is already in an alter hook, and from memory I didn't need to revert anything. Clear cache perhaps?

Nope, doesn't work (for me). It will only show up if the view is reverted, or explicitly edited - because somehow the CTools/Views definition already ended up in the database.

I am also not sure if it is the business of the update hook to revert the view (ONLY if there is no difference between the database/overridden version and the code version before-addding-the-link).

Need to think it over. We might need a warning in a README / update hook text about reverting your views. However, that warning is not unique to this patch... the same issue is there if you enable the data_entity module after having created tables already: then the "edit" links don't show.

Please ignore my previous messages. (Default views vs. saved views vs. cached default views and other things were confusing me.)

The actual reason that an "add" link was not showing up on my view, was that the so-far-untested update function (which is a good idea, and I opened #3144433: Entity-fying a table should add edit/add/delete links to the view to expand on it)... wasn't working. This is fixed now.

I've properly reviewed the patch now, and it's fine except... maybe the edit link changes. I believe all Joachim's earlier concerns are addressed. What I've changed (in the interdiff) is:

• Fixed the update function. (A view returned from views_get_view() apparently has a different structure than a view passed to hook_views_default_views_alter(): it has no handler class inside the display object. We apparently need to modify the display directly. Also, don't modify/save the view if it's not saved in the database yet, because the default in-code object already gets the modificatons. Also we don't need to use by-reference assignment per se, because we're modifying an object, which goes fine.)
• Added an extra permission. IMHO we should do (partly) the same as e.g. nodes, and add separate permissions for editig/adding/deleting records. Renamed the existing "Edit" permission description slightly now that there are going to be more permissions. (Structured like the description for node permissions.)
• Renamed the header area. It was called "area_text_custom" but we should give it our own name to distinguish it from whatever custom area a user may have added - which we don't want to overwrite in the update hook.
• Added styling to the "Add" link. Unfortunately there's no theme function for this, because the styling for the "Add content/user" buttons is in a template. Does anyone mind the HTML added directly to the area?

...Plus, I backed out the changes to the edit link:

+++ b/data_entity/views/data_entity_views_handler_field_edit_link.inc
@@ -22,10 +22,14 @@ class data_entity_views_handler_field_edit_link extends views_handler_field {
-    $base_field = $this->view->base_field;
+    $entity_type = 'data_' . $table;
+    $entity_info = entity_get_info($entity_type);
+    $entity_id_field = $entity_info['entity keys']['id'];
+    $entity_id_field_alias = $this->view->field[$entity_id_field]->field_alias;
+    $entity_id = $values->$entity_id_field_alias;

Re. #19:

(...)because we're dealing with entities here we should probably use the entity ID.

The edit link now uses the entity ID instead of the base_field (primary key?)

We should likely do the reverse: make sure the base_field is equal to the entity ID.

• The base field is currently one of the primary key fields, and I fail to see what function that has.
• There's already a patch in #2673132: views base key should respect settings from data entity which does this, OK'ed by Joachim, which has more applications. (Fixing entityreference fields which also cannot work with the old base_field.)
• It saves me from thinking further about whether someone could have redefined the {$entity_id_field} to be something else :) ...which I don't know the answer to.

For the rest:

I thought a little about the naming of "Add" vs "Create" and "Item" vs "Record", and I think it's fine as-is.

We still have the separate patch in #44, for the "delete" link. I didn't want to roll it into this one, because it's big enough. That patch is good, except it needs a similar field addition as we have in data_entity_update_7001(), and (if my changes get reviewed/approved/RTBC'ed) an extra "delete" permission.

We still have the separate patch in #44, for the "delete" link. I didn't want to roll it into this one, because it's big enough. That patch is good, except it needs a similar field addition as we have in data_entity_update_7001(), and (if my changes get reviewed/approved/RTBC'ed) an extra "delete" permission.

Oh, also:

• Needs to reference base_field rather than $this->view->field[$entity_info['entity keys']['id']]->field_alias, in the handler, ifmy changes get reviewed/approved/RTBC'ed
• Docblock for data_entity_entity_delete_form_submit() needs editing
• And the analogue of what I said in #2990954: Make (views) edit link (field) text configurable about the edit link (again, depending on which version of that fix gets committed).

One more change: we should not use $entity->entity_type where we can avoid it, because it's not standard. (The data module 'invented' it with a reference to its absence being a WTF, but there's consensus in #1042822: Developers need an $entity->entity_type property that this is just the way it is.)

Also: the submit function's usage is now consistent with the validate function's usage.

FYI: ...now... the work done in this issue is also in #2744843: Remove Entity ID field requirement.

Because that re-does much of the edit screen (in order to be able to edit non-entities), it didn't make sense to not include the code to make "Add item" work.

patch appears to work for creating new entities