auto-generate entity forms

Great idea. I suspect that what you say is right - try to make a best reasonable guess based on datatype (I guess most things will end up being textfields with maybe the right validations).

On a related note I've been thinking of auto generating code for entities - a lot of the code is really repetitive (including of course forms) - and personally I would prefer to able to quickly generate a module and then go in to edit stuff rather than altering forms that are generating automatically. But that is just me and automatic form generation has its use cases as well.

The main thing is making sure we're using the proper widget for collecting property data. I'm guessing the relevant Rules code pertains to the different types of callbacks available to Rules condition / action parameters that let you specify widgets and option lists. Maybe hook_entity_property_info() would just need to be expanded to allow the inclusion of widget callbacks (for example, using a node type named-based "Author" textfield w/ autocomplete to handle input of a uid property).

The idea seems reasonable enough, though. It might even be expanded to include bundle add / edit forms.

subscr

I think the idea has a great potential. We basically should build form elements / widget per data type that work solely on the specified property info.

The code I mentioned in Rules, are the data-type specific direct input forms located in the ui/ui.data.inc file. It basically implements the type specific form elements, which then are used by rules to generate the forms. Ideally, they should be just regular form elements though, I guess.

I fear we are going to overlap with field API widgets though. The problem with field-API widgets is, they aren't reusable else. I'd like to see that improved for d8 though (see here).

somehow related issue #1196456: provide a harmonized entity_form() function

The suggestion of #3 - widget callbacks - make much sense too. Maybe, just a 'widget' => 'form element' property would do it, while we could use a type specific default.

@#9:
Some thoughts on the patch (of course open for discussion):

1) What about doing form elements for all basic data types + building upon that. I've not done so in Rules as it wasn't really necessary. It still isn't, but once we want to bake this in a proper, generally useful API I think it makes sense.
So what about doing form elements like "entity_duration", "entity_text", "entity_token", .. ? Then we could have a helper function that return the form element for a given property info array, such that label, description and such are properly pre-filled for the "widget".

2) We need to put the element info hook in the main module. Then I'd suggest adding a process callback (also living in the module file) to each element. The callback then can use form_load_include() to add/load the include file.

3) What about renaming "entity.property_ui.inc" to "entity.element.inc" and put all the form element callbacks there? Once we revert to form elements, most of the code should be just generally useful form elements anyway.
Maybe we'd just keep the helper in entity.propert.inc then, e.g. entity_property_form_element($name, $info)?

4) The question though is, how we handle option lists best. In the end options list are the same for each data type, so a select is already very close to what we want. So maybe just use "select" as widget/form element in this case + let the helper care about populating #options?

5) The arguments or rules options list callbacks and entity property callbacks are different. So we need to change the code to match the entity API arguments, see EntityMetadataWrapper::optionsList().

+  // @fago Why do we need this if it's already defined in entity_element_info()?
+  $form[$name]['#after_build'][] = 'entity_property_ui_element_duration_after_build';

Because the "text" widget already adds an after build callback, what causes the defaults to be not applied. That's a known odd FAPI behaviour :(

Thoughts?

sub

subscribe

I am not an expert on the Field API, but wouldn't it be possible to reuse a lot of its mechanisms by writing a field_storage for properties?

Ok, I gave this a stab. I guess the patch is a little bit more general than form auto-generation, since you can define formatters and widgets to be display together in one view, but the idea of giving something useful from property_info data still holds. I kind of ignored the whole elements thing, but it could definitely be integrated with this code, and I also added a menu item (/entity-node-display-example) where you can go to see the code in action. For the example to work you need to have at least one node with id:1.

Let me know what you think.

Oops, forgot the patch

Re-rolled to correct various whitespace and formatting errors.

Better interdiff.

The 6 year old patch in #18does not apply to the latest entity 7.x-1.x-dev.

Checking patch entity.module...
Hunk #1 succeeded at 1195 (offset 74 lines).
error: while searching for:
      $entity_info[$type]['configuration'] = !empty($info['exportable']);
    }
  }
}

/**

error: patch failed: entity.module:1348
error: entity.module: patch does not apply

Checking patch includes/entity.wrapper.inc...
Hunk #1 succeeded at 283 (offset 15 lines).
Hunk #2 succeeded at 599 (offset 12 lines).
Hunk #3 succeeded at 904 (offset 55 lines).
Checking patch modules/node.info.inc...