Investigate joining forces with inline entity form

I would absolutely be open to collaboration. This module would basicly do the same thing as entityconnect if we would implement #1370692: Add javascript graceful degradation when javascript is not enabled, so there's definitely possibilties for collaborating.

I think anything that could be done in terms of collaboration needs to be compatible with the approach of this module though, due to the reasonably high user base of it. We can't very well go ahead and refactor everything as it stands right now. I would be happy to accept a co-maintainer from entityconnect to make that happen.

Hi,

I am the maintainer of entityconnect module.
I will be happy to discuss of the way to collaborate.

I will send you in a minute a mail via the contact form with my contact information.

Yes join your efforts guys!

The whole Community will be grateful to you for this.

Thank you for your precious work.

@jygastaud and @fabsor: any news on this proposal?

I think that joining efforts can do a good sprint to this module development.

Nop no news from fabsor.
I will be happy to discuss.

Sorry you guys - A lot on my mind lately!

@jygastaud I am happy to accept you as co-maintainer of this project if we can agree on a roadmap for going forward. This module needs some love and care in general, and I would gladly accept help.

What I feel we need to agree on is what exactly we should move over from Entity Connect to here in order to cover all the important features of both modules. I suggest we agree on this first and then create issues as we go.

@fabsor when and how you would discuss about it? I will be happy to try to plan a roadmap.

Feel free to contact me by mail first or skype. You should have all information in my previous mail.

Any news?

All is dead here...

@jygastaud: I don't know, may be you could have more success that fabsor notices you if you start resolving issues in this module queue, for example this BIG issue: http://drupal.org/node/1479412

Fabsor and jygastaud: please see http://drupal.org/node/1866812

Good proposal here!

@jygastaud, do you have any detailed points now? The 2 modules actually are quite similar in function, just different on UI.

I'm thinking maybe it's good to merge.

@rogical, you're right. Both modules are quite similar.
Main differences are UI and process to deal with entities.

I would be happy to studiing a merge.
Maybe a good start will be to find all differences between our 2 modules and defines the way we would like to go.

I made that a long time ago: http://drupal.org/node/1547208#comment-5916632
That first thread could be a good start to our work.

I found there're already a 2.x roadmap on entity connect, maybe we can merge reference dialog feature to entity connect 2.x.

Then there can be a setting on fields 'Use popup dialog' to enable dialog.

For both 1.x of these 2 modules, we just keep fixing bugs.

• Entity connect reported installs: 388 sites
• References dialog reported installs: 2974 sites

Please take into account of the above statistics.

Efforts should be concentrated to most installed module.

@MXT, Usage should be considered but, IMHO, should not be the most important datas.
Functionnalities must be first considerated. Which one of that both modules are the most advanced?
Also, we should considered the code quality and which one is the easiest to extend functionnalities?
Then, I think we must look at which way is the easiest to merge, from entityconnect to references dialog or from references dialog to entityconnect?
Or should we create an other module?

One that 4 first questions have an answers, we should be able to find the better way to do these merge.

When I frist think of this, references dialog is not a good name for merging all, entity connect is somehow a good name.

If you have another good name, we can consider too.

For install statistics, we'll keep maintaining the existed versions, merging will only go to a new branch.

BTW, migration guides/solutions can be planned either.

@jygastaud: seems that your first 3 question sounds like rhetorical questions isn't it? I suppose you already know the answer... ;-) Anyway, all 3 are good points, so I completely agree with you.

For political "reasons" I think a new module should be created, and then a good communication on both project pages must be made up to point peoples on new module.

I also agree with Rogical about naming: "entity connect" is more communicative then "references dialog" but, If a new module is the way we'll go, a new name have to be found.

I have a suggestion for that: taking a look on the history for reference dialog, it was born to provide a D7 alternative to Node relationships module. So why not keep this "continuity" and name the new module Entity relationships?

Or "Entity relations": I don't know what's the best for english language, but relations is shorter than relationships and presumable more suitable for SEO and user searches. Moreover, "relations" is more suitable than "connect" in our case because, IMHO, we are relating entities and not connecting them.

To conclude, I think you guys already know Inline entity form module: it works quite well (although limited only to node, taxonomy_term, and other Commerce entities at the moment) and should be take in consideration as inspiration for some functionalities.

So:
taking the best from references dialog +
taking the best from entity connect +
taking the best from inline entity form =
for making a new amazing Entity relations module

;-)

Actually, I have used a lot on inline entity form, but encounters a bug with OG which still not solved yet. #1825312: OG reference field(og_group_ref) is missing in inline entity form

Entity relations is also a good name.

Hi, everyone :)
mansspams pointed me to this issue.

I'm the person behind Inline Entity Form, Entityreference View Widget, and VBO.
I've reviewed the entityconnect and references_dialog codebases (and tested the actual functionality) prior to writing this comment.

General notes:
- I don't like entityconnect at all. The codebase at a glance looks hacky and the interaction (with the redirects back & forth) not very user friendly.
This is just my subjective opinion after a 10min examination, so please don't take any offense.
- References Dialog could really use a README file. I tested with an entityreference autocomplete field, and couldn't figure out how to get the "Search" functionality to show up at all.
- Entityreference View Widget was a mistake. Embedding views exposed filters in a parent form through #ajax is the equivalent of selling your soul to the devil. It is a fundamentally flawed approach, and bugs are unavoidable.
The only reason why it's not marked as "abandoned" is because I have a project that is actually using it successfully.

Inline Entity Form was built primarily for adding / editing / deleting entities. And in that it is vastly superior to other mentioned solutions.
1) No changes are permanent until the parent form is submitted.
2) There is a well defined API for inline entities (a controller class per entity type), with a custom provided form for each entity type.
I strongly believe that it is a mistake to try and reuse the original full form, because the inline context is different and usually warrants less / different information. Implementing support for a new entity type is trivial.
3) There is a controller-level setting for deleting referenced entities when the parent entity has been deleted.
(So for nodes it is a checkbox in the widget edit, but for line items which can't be managed outside the parent form, it is always on and the checkbox is not shown).
4) All entity permissions are respected.
5) There is optional "Reference existing" functionality, showing an autocomplete field (which for entityreference fields should allow fetching from the results of a view as well, but I haven't tested that yet).
If "Reference existing" is enabled, the "Remove" confirmation form asks you whether the entity should be permanently deleted, or just unlinked.

For Inline Entity Form 2.x we want to move the inline forms to modals, see #1881616: Move the inline forms (add, edit, remove, reference existing) to modals.
I believe that it would remove the need for other solutions, and I welcome other contributors.
However, I don't plan on opening the 2.x branch for another few months at least, because 1.x is still not fully formed (We want an optional "clone" button, a better way to specify which columns should be shown in the IEF entity table, fix bugs, etc).

IEF at first is one of my choice, but while I encounter a bug between OG and IEF which still doesn't have any clues, I can only choose this module.

IEF is coded well with classes and hooks etc, I'm going to add (remove, delete(delete source)) buttons to references dialog either.

So we can wait IEF to be formed first, while I keep on improving and enhancing references dialog at this moment.

Changing title on this issue, since this is a more general "Join forces" issue now.

I like the inline entity form solution, even though the name would be kind of misleading if we were to provide dialog functionality in it =)

The main thing that it has which inline entity form hasn't is solid search functionality through views. You can set up a view and attach it to one or more reference fields and then be able to get a dialog for searching for content that you want to reference, which has been a huge usability improvement when working with references in the projects that we have done. Since we open a new dialog we can combine Entity reference view widget and Inline entity form.

When it comes to joining forces, I think the most suitable place to put a solution like this is the Entity reference module itself. That is definitely the most widespread module of them all, and where it would be easiest to maintain since there would be more people looking at the code.

I like the inline entity form solution, even though the name would be kind of misleading if we were to provide dialog functionality in it =)

I think it's still clear enough, if we take inline to mean "from a parent entity form".
By the time the dialog gets implemented IEF will be a household name anyway.

The main thing that it has which inline entity form hasn't is solid search functionality through views. You can set up a view and attach it to one or more reference fields and then be able to get a dialog for searching for content that you want to reference, which has been a huge usability improvement when working with references in the projects that we have done.

Yes, that's a nice feature.

When it comes to joining forces, I think the most suitable place to put a solution like this is the Entity reference module itself. That is definitely the most widespread module of them all, and where it would be easiest to maintain since there would be more people looking at the code.

That will never be accepted by the Entityreference maintainers, and I see no reason for it to be accepted. It just creates a maintenance burden with little gain. People who need inline management of referenced entities will download your module, others who just need entityreference don't need it.

What Fabsor suggests about working directly in Entitiy Reference Module has a vantage at least for SELECTING existing entities.

See the screnshot in attachment for example: with a simply additional option to open the Entityreference view in a modal window, we obtain:

1. The possibility to also use exposed filters in the Entityreference View opened in the dialog window (this should not be subject to complicances described by Bojanz about exposed filters opened in tha same node form)
2. The vantage to use only one view to select entities and not 2 like References Dialog (one for the dialog and one for "entity selection" provided by entityreference)
3. Keeps things simple for usability because we don't need other fieldset in other part of the field admin page, but only we have to add a checkbox to the already existing entityreference settings option.

Did this, the option to CREATE and ADD new entities can be managed as a new big tab inside the modal, like the "old" Node relationships module does (see screenshot 2 and 3)

What do you think about this?

Sorry, First screenshot show actual existing settings, this new one shows the intention.

That will never be accepted by the Entityreference maintainers, and I see no reason for it to be accepted. It just creates a maintenance burden with little gain. People who need inline management of referenced entities will download your module, others who just need entityreference don't need it.

So our new module can be an extension of entityreference called Entityrefence modal ?

;-)

I guess IEF is the module to continue to work on then. This module differs architecturally from the IEF since it uses the actual form of the entity, by basically open for instance node/*/edit in a modal dialog. I think I agree that the approach taken in IEF is a better one, even though it requires slightly more work to integrate a new entity.

That basically leaves the views integration that's part of this module. That could either go into IEF or become a new module altogether with just that functionality that extends IEF.

Yes, the way of rendering entity forms is actually quite different from IEF, as IEF still has a long way to go, we can see when IEF open a new branch for this and how it plans.

However, this modules can be still under maintained and improved.

Agreed. I'm postponing this, let's investigate further when development of the 2.x branch for IEF starts.

Just to gather other opinions and interest and to keep things alive, I've opened a request feature in the Entityreference queue (limiting the request only for search entities and not creating new ones).

http://drupal.org/node/1882954

looking at the functions and features of both modules the best name is inline entity dialogues is proper and correct

While IEF may have a better code architecture (though implementation for new entities is much more involved), references_dialog's Views integration for providing a search dialog and the simple "Create [bundle]" links give a better UX for end users. I look forward to seeing what IEF v2 comes up with but I'll be contributing to references_dialog in the meantime.

IEF has
1.process flow :correct approach in adding a new entity on saving the parent entity.Entity connect and reference dialogue don't have control over this. users can simply create 100 new entities and close the window without completing the original transaction process.

2.cardinality:restrict how many new can be added to "current" reference. you can have control on maximum limited by the child entity cardinality setting
what is expected from the final product of this "Entity reference inline connect dialogue form"
there are two main possible user actions :
1.a raw node/entity "create new"

2. a "select from existing" this should be a view generated by views where user can select existing items.
3.edit, view functions are typically garnishing to this module,so, focus should be on create/add operation for which people want this module.
this form should have field type configurable. autocomplete, select list, checkbox/radio buttons to search existing much like in "entity reference view widget"
all in all it is "Picking list" or "shopping cart" user should be able to pick the product or products(bulk operation)from the "rack" and put in his own shopping cart and doesn't want remove from cart. if the the product is not available in the rack then user should be able to add new product to the "rack" then pick and put in cart.The newly added product should be "really added" to the rack when the "cart is saved" other wise unwanted products will fill the rack.

How we want to display the "rack"? . in modal or in overlay or shadowbox ...or in current page or redirect every thing should be possible as the "modelling" is taken care of by views.
Hope something concrete will evolve out of this

mark, nice post and collaborations here.

Could we update the project page explaining how this module compares to Inline Entity Form and its advantages?

There's this one too: https://www.drupal.org/project/entityconnect