My latest commit:
http://drupalcode.org/project/inline_entity_form.git/commitdiff/c6d28dd?...
attempts to make the table (listing the already referenced entities, and providing the edit / delete links) more flexible.
The table is now auto generated, and the entity type implementation just has a "default fields" callback that returns which fields should be displayed, and in which order. If the fields are provided by Field API, the formatter can be selected and configured as well (so you can say "show the base price" instead of "show the calculated price" for price fields, for example).
If someone wants to modify the logic (add his own field, for example), there are two ways to do that:
1) Implement hook_inline_entity_type_info_alter(), swap out the "default fields" callback for a custom one. (The custom one can then call the original one and override certain values, or just start from scratch).
2) Provide the settings in the same way when creating a field (or update the instance from code).
So if $widget['settings']['field'] has a fields structure, it will be used instead of the one provided by the "default fields" callback.
This allows install profiles to easy configure the look of the table.
Is this enough?
I've also been thinking of providing a custom UI, a "Inline Entity Form" tab shown when editing the reference field, that would have a table similar to the one from "Manage Display" (drag & drop, formatter settings), showing properties added through hook_field_extra_fields() such as Title and SKU, and also showing all fields that are common to all selected bundles. So for line items you could add (and configure) the total field, etc.
Does that sound desirable?
Comment | File | Size | Author |
---|---|---|---|
#34 | 00000210.png | 212.42 KB | bryancasler |
#33 | mymodule.zip | 2.38 KB | msh2050 |
#33 | 6.jpg | 88.39 KB | msh2050 |
#33 | 7.jpg | 64.12 KB | msh2050 |
#29 | ief-content-elements-test-rendered.png | 1.08 MB | derjochenmeyer |
Comments
Comment #1
joachim CreditAttribution: joachim commented> Implement hook_inline_entity_type_info_alter(),
AFAICT this has gone, presumably as part of the refactoring to use a controller.
Should we replace it with a hook_inline_entity_form_fields_alter()?
> Provide the settings in the same way when creating a field (or update the instance from code).
That seems a bit fiddly for site builders. I guess you can hack the settings into your Feature by hand...
> I've also been thinking of providing a custom UI, a "Inline Entity Form" tab shown when editing the reference field, that would have a table similar to the one from "Manage Display" (
Could that be done within the field admin page? EntityRef module has a UI within that for choosing entity properties for labelling and sorting.
Comment #2
bojanz CreditAttribution: bojanz commentedYep, so the solution now is to inherit the controller and replace it through hook_entity_info_alter(), just like with any other controller.
Yeah, I was thinking of a tab when editing the reference field.
The whole approach has many edge cases and adds a ton of complexity, so I'm not rushing to do it. Might just prove unnecessary, we'll see if more people request it.
Comment #3
joachim CreditAttribution: joachim commented> Yep, so the solution now is to inherit the controller and replace it through hook_entity_info_alter(),
But what if you want to tweak the fields for an entity that's not yours?
Say, for example, commerce products. I've seen the impressive screenshots of this used for Commerce Kickstart 2, with the product images shown in the IEF table. How are you achieving those? Subclassing the controller for that seems a bit wrong to me.
Comment #4
bojanz CreditAttribution: bojanz commentedThat's done by IEF by default (CommerceProductInlineEntityFormController::defaultFields()).
It's not wrong, but it is cumbersome.
The main complexity with adding the new UI is the fact that multiple bundles might be supported, so you need to add fields belonging to each one...
So it's basically a copy of the existing "Manage display" code, but saving to IEF settings, and supporting multiple bundles.
Comment #5
rcross CreditAttribution: rcross commentedI have 2 thoughts on this:
1) Define a render/display mode for entities, and then you could just use the drag/drop ui of the "manage display fields". This could potentially allow for the use of Display Suite to configure the display in a more general sense.
2) Use views to define the table. Then adding or reordering fields would just be a matter of overriding a default view.
I think either of these options also have the possibility of reducing the complexity and need for a controller for each entity.
I haven't dug into the code yet to see which of these options might be the most feasible, but conceptually I don't see a strong reason we couldn't use one of these approaches even if they might require a few workarounds.
Comment #6
bojanz CreditAttribution: bojanz commented1) Keep in mind that IEF might be showing entities of multiple bundles at the same time. So if you have a view mode for each bundle, what happens
if the fields aren't the same? Plus, changing the IEF table in that case means you need to go to the "Manage Display" form for each bundle.
That's why my idea in this issue was to provide a custom "Manage Display"-like form that works for all allowed bundles for that IEF field.
2) Using a View in a form context is hard and makes the code almost unmaintainable. I've been done that road with Entityreference View Widget, and have had only bad experience.
Comment #7
rcross CreditAttribution: rcross commentedI'm not sure how common the case will be that multiple types of entities will be referenced, so I"m not sure we should optimise/cater for it.
One work around would be to group by different types of entities, so that you can have multiple tables with different fields. Alternatively, you could just leave the cells blank for the columns/fields that the entity doesn't have. We could also have an configurable option to show only common fields or show all fields with empty cells.
If we use the entity render approach, you could just have a simple list of the rendered entities instead of using tables and a row for each entity. If we use the views-based approach, views already has code to handle different entities with different fields.
Some thing else to think about is that people might prefer to have something else besides a table-based layout. For example, maybe someone might want a simple grid layout of product images with edit/delete links under each image.
2) I'm aware that views in forms is not very nice. I would probably expect that the form editing space would be separate to the rendered view space to help with this, but obviously you would have more experience in this.
It might also be worth looking at http://drupal.org/project/editablefields (D7) and http://drupal.org/project/editview (D6 only)
Comment #8
rcross CreditAttribution: rcross commented@bojanz - have you thought about this any more?
Comment #9
bojanz CreditAttribution: bojanz commentedMy points in #6 still stand.
Supporting entities of multiple bundles is vital for use cases such as line items (product line items, shipping line items, etc).
We already optimize & cater for it.
Comment #10
m42 CreditAttribution: m42 commented@bojanz:
Thank you so much for this module, I was trying to implement something equivalent before I found yours !
As I'm very new to entities, I don't understand your solution to add an existing field to the array. Can you please provide any piece of code about how to do that ?
Thank you in advance !
Comment #11
kirie CreditAttribution: kirie commented@hwold - did you figure it out?
Comment #12
m@rtijn CreditAttribution: m@rtijn commentedI would love to see this functionality added to the Inline Entity Form module.
Comment #13
m42 CreditAttribution: m42 commented@kirie: I finally found the trick (the solution was 75% in the module's files, I just had to copy/paste then adjust to my needs). But I didn't try to filter the columns as I needed them all.
If someone is interested by the way I did it (which is, I repeat ot, definetely not THE way), just ask ! ;)
Comment #14
eme CreditAttribution: eme commentedIndeed, you can post it here, and maybe it'll help coding the functionality cleanly.
Comment #15
kirie CreditAttribution: kirie commented@hwold - thanks for replying back! I haven't gotten around to looking through the relevant files yet, but, as @eme said, a little code pasted here would be much appreciated!
Comment #16
m42 CreditAttribution: m42 commentedSo, here is what I did :
1. Create your custom module, then a folder named "includes" (or whatever you want) intended to contain your classes.
2. In this folder, place the following into a file named NodeCustomController.php
3. Add this on top of your .module
module_load_include('inc', 'your_module_name', 'includes/NodeCustomController');
4. Still in your .module, add the following :
This will make every content type referenced through an EntityReference field use your custom class to decide which fields are printed.
Hoping this helps.
Comment #17
kirie CreditAttribution: kirie commented@hwold - woha - thank you very much - that piece of code got me up and running in almost no time - thank you!
Just some additional info - there are probably someone else struggling with this :)
I am using the module to manage Commerce products with the Product Display node type - and as such, my use case was a bit different. Instead of extending the NodeInlineEntityFormController class, I did the CommerceProductInlineEntityFormController (I only implemented the
defaultFields($bundles)
function).My module file thus contains this code:
Also, at first I had the problem that my controller would not be loaded - and it turned out to be a module weight issue (i.e. my module's hook_entity_info_alter was called before the hook in inline_entity_form - this the module altered my alter) - the solution was to add a couple of lines to my module's install file to increase the weight of my module (i.e. making the system call my hook_entity_info_alter after the inline_entity_form's hook):
Nitpicks:
- It might be a better practice to include the controller file in the module info file instead of inside the module itself, just add this line to the info file:
files[] = includes/MY_MODULE_commerce_product.inline_entity_form.inc
- I generally like to keep the naming scheme of the inc file begin overridden/extended - i.e. MY_MODULE_commerce_product.inline_entity_form.inc - but thats a purely personal taste :) You could also leave it the same as the original (no, there won't be a naming conflict - as long as your class name is not the same, of course)
Hope this helps anybody :)
Comment #18
temkin CreditAttribution: temkin commented@bojanz, First of all thanks a lot for the efforts you've put on this!
Regarding your question:
That will be very helpful. Let me know if it's still on your list and if I can help somehow with that. Thanks!
- Artem
Comment #19
agileadamWhen I implemented #16 my "Image" (image) and "Caption" (long text) columns appeared, but they didn't show any data. So, I made a few changes:
Also, like kirie says in #17, I renamed the .inc file and added it to mymodule.info. When I added this code to a Feature I had to implement hook_install() to fix module weights too. Thanks Kirie!
Thanks a lot hwold for showing your code.
For anyone else looking to implement defaultFiles() overrides like this, have a look at inline_entity_form README file.
Comment #20
m42 CreditAttribution: m42 commentedYou may have noticed that, using our approach, the columns and their values do appear, but in some random order.
To restablish the appropriate one (the order you set in your content type definition), you just need a few changes.
Starting from agileadam's code :
Thus, pay attention to the fact that the controller sets title field's weight to 1, which might not be the real value. So you just can set the appropriate weights in your content type (the easiest solution), or you can try to write (yet another) patch that will always be welcome ! :)
Comment #21
pzerimars CreditAttribution: pzerimars commentedHey guys, I was just working on this was really bugging me.
I'm using IEF for products. In a custom module, I define:
And finally the controller. This controller makes the table appear exactly as defined in (Entity Type) -> Manage Display -> Inline Entity Form. Weights and visibility are accounted for.
I'll write up a generic patch later
Comment #22
pzerimars CreditAttribution: pzerimars commentedweird dup post. Sorry about that.
Comment #23
rogical CreditAttribution: rogical commentedAs this isn't available right now, I created a module for showing referenced entities http://drupal.org/sandbox/rogical/1880826 References Thumbnail.
Comment #24
philipz CreditAttribution: philipz commentedThank you very much @kirie and @hwold! The weight of my custom module did matter a lot in my case and now it's working perfectly :)
Comment #25
ruben_vreeken CreditAttribution: ruben_vreeken commented@pzerimars, thanx for the code, it works great on my nodes too!
In case it helps anyone, to apply pzerimars's solution to nodes, just modify the hook_entity_info_alter implemenation to something like this:
Comment #26
Summit CreditAttribution: Summit commentedHi, I am not a programmer, but is with these solutions also possible to filter a producttype before the exisiting producs are shown? It seems they show a table, but already after the product autocomplete field? Sorry If this issue is completely different from this usecase, but I thought they where related and I can't find a way to get this working. Greetings, Martijn
Comment #27
dmiric CreditAttribution: dmiric commentedpzerimars solution works great only problem I have is with ECK entites it dosent accept formater settings. For example I can use Image formater for image field but it dosent accept thumbnail setting.
Anyone got around to solove this problem ?
Never mind it was easy to solove for anyone else having this problem find in controler and add last line
$fields[$field_name] = array(
'type' => 'field',
'settings' => array(),
'visible' => $is_visible,
'formatter' => $display_settings['type'],
'settings' => $display_settings['settings'],
Comment #28
dmiric CreditAttribution: dmiric commentedI'm trying to use pzerimars controler from #21 to extend EntityInlineEntityFormController and it works perfectly exept that it somehow looses title property on the entity form. So the title shows in table where you choose which row you want to edit but on form it self it dosent. Can someone point me in the right direction how to add ECK title property to the form.
Comment #29
derjochenmeyer CreditAttribution: derjochenmeyer commented#7 by rcross
Outside of Drupal Commerce this could become a very common usecase. Our customers often ask for an intuitive way to create pages and articles with: text, images, galleries, media elements. Right now there are lots of different approaches with WYSIWYG, Insert, Insert video, Image Resize Filter, Image Assist, ...
A different approach are "content elements" like in TYPO3. Site builders could create "content elements" of different types all with different sets of fields like text, text with image (float left or right), image, image gallery, video, audio, advertisement, related articles, etc... Entity Construction Kit (ECK) makes it easy to create and customize such "content elements".
There is a sandbox project by Dave Reid: Inline entity form rendered.
I think the most flexible way is to let users chose which view mode should be used per type. Here is an example how this could look like (modified the "Inline entity form - Multiple values" widget settings page:
This is how an article form could look like
And here how it could look like with rendered entity types
Created with sandbox project by Dave Reid: Inline entity form rendered
Comment #30
bojanz CreditAttribution: bojanz commentedA lot of time has passed and a lot of feedback was gathered.
I have decided not to implement any kind of UI, because all options have been confusing (we'd basically need a "Manage fields" UI that supports field instances from multiple bundles).
I am adding an alter hook in #2032155: Rename the defaultFields() controller method to tableFields(), introduce an alter hook. which will make it easy for developers to change the fields returned (so commerce_stock can always add a stock field, and users can tweak what they want as well).
I also like Dave Reid's approach of showing an entity in a specific view mode.
I can't do that in the existing widgets because it would be too big of a change, but I think it makes a lot of sense to have that either as a separate module or inside IEF itself as a new widget.
Comment #32
_vid CreditAttribution: _vid commentedHi bonjanz,
Would it be more appropriate to change the status to "closed (won't fix)"
Comment #33
msh2050 CreditAttribution: msh2050 commentedI try pzerimars's module in #21
and I delete the commerce code witch is :
then I replace the code of ruben_vreeken "in post #25 "to use it for all of content type...witch is:
(I have tender content that have an Entity Reference to tender_detail content type .... the mymodule folder is attached ...)
I add new tab in display manager but unfortunately I can not add or edit any content that use inline entity form
I see that the development is done before 6-7 months why they did not include this in module releases as stable or development release so it will be easier to setup and use??(Just download and extract)
I open an issue(modifying the Inline entity form listed fields and I try many solution witch is did not work to modify the list or title of the fields even it did not hide the title...
hope I can find easy solution.. or we can see an update for the inline entity form or other module that will add new features..
regards..
update:-
I try with fresh installation(to check if it cause be in compatibility with some patches that I apply) of api and inline entity form with application of pzerimars's module in #21 only...
but I get the same issue and if I disable the new custom module it will be Ok but as the stock module ...
Comment #34
bryancasler CreditAttribution: bryancasler commentedIn the interim I used the Entity Connect module and modified it a little to look like this...
Comment #35
bojanz CreditAttribution: bojanz commented@animelion
That looks really nice, seriously.
Comment #36
bryancasler CreditAttribution: bryancasler commentedThanks Bojanz, it was basically this and a lot of jquery. If anyone is interested in making a proper patch, I'd be more than happy to help with what I can.
Comment #37
bryanmanalo CreditAttribution: bryanmanalo commentedAfter much fiddling around I was able to make it work.
#16 is very helpful. But there were things that I changed to make it work:
(I am not using drupal commerce but just inline entity form)
1.) #17, the module weight is very important make sure that your module is loaded after inline_entity_form
2.) module_load_include('inc', 'your_module_name', 'includes/NodeCustomController'); the controller class should be .inc (instead of .php) for this line of code to work.
3.) Inside NodeCustomController, defaultFields method is not existing in the parent class, you need to override tableFields method instead.
Hope this helps someone.
Let us build the community
Comment #38
bendiy CreditAttribution: bendiy commentedI've created a patch to Dave Reid's sandbox for Inline Entity Form Render module that adds support for #29 and #34 to that module. Please check it out.
#2119791: Rerolled and Updated module code
Comment #39
OnkelTem CreditAttribution: OnkelTem commented@bojanz
Unfortunately, the situation is not appropriate yet: Dave's module was not promoted to a full project, it doesn't work out from the box and you need to apply a patch. Also emerged a module https://www.drupal.org/project/inline_entity_form_preview which makes pretty much the same. But still, there is no way to just allow IEF to add fields to the table!
I haven't read the whole discussion and maybe missing some important issue but let me quickly explain what UI would be just fine and not confusing from my point of view.
1) On the widget settings form could be a fieldset with ALL fields from ALL the bundles checked out.
2) The list could be provided as a sortable table so you can reorder fileds
3) Near the table could be a dropdown list of available view modes.
That's all. Now, when you build a list of table columns in
EntityInlineEntityFormController::tableFields()
, you just add configured fields in the proper order with proper settings from their display view modes.Profit!
Or I'm missing something?
Comment #40
mnico CreditAttribution: mnico as a volunteer and at TIFON commentedHi @OnkelTem, I created a module that could help you. Still in development version but is a full project. There is https://www.drupal.org/project/ief_table_view_mode . This allow you to add fields to the table using Field UI.
Regards