Not sure whether this is even possible, in any case I can't see it.

I need to create a select box, but rather than supply the values for the dropdown, I would like the list to be a list of existing nodes.
I imagine this would be similar to how a CCK node-reference functions.
[You can specify which node types are allowed to be in the list, and even better, you can specify a view which holds the list of nodes, allow a better filter]

So is it possible?

Regards
Alan

Comments

quicksketch’s picture

No this isn't possible at this time. Someday I'd like to make a replacement module for webform that utilizes the CCK elements, but until then there is no solution for this. Patches to add this functionality would still be accepted :)

RayZ’s picture

A CCK-based webform replacement sounds sweet! Sounds like a good direction to me.

BioALIEN’s picture

Title: Select box filled with Node titles » Webform module rewrite
Category: support » task

+1 to this concept.

We have an in house developer working on the webform module. The plan is to merge CCK (and its database structure) along with anything helpful from the Profile module into the webform module. The end result is something like like the behavior of webform but with the power and flexibility of CCK/Profile module.

Does anybody else want to contribute to this or have any ideas on the best approach forward? Maybe quicksketch can outline the vision for this module and how you plan to integrate it with CCK?

Some of the things we are planning are:
1) Create a database tables for each webform content type (ala CCK & Profile).
2) Each form component will have its own attribute in the database - unlike the current db structure. This will make the module scale nicely with 100,000+ entries. (ala CCK).
3) Keep the existing structure of webform with the component (plugin) directory - allows the creation of additional components in the future with specific validation e.g. US telephone number, CA zip code component etc.
4) Specify inline or under option (ala CCK)
5) Separate field Title and database field ID to allow inclusion of duplicate Titles in multiple nodes without breaking the module (ala Profile)
6) Component dependency? E.g. if component1.value=2 show component3.name
7) Display of statistics and form submits?

Maybe there should be a group on g.d.o for this module to discuss such topics?

BioALIEN’s picture

This is a good reference for the functionality and field types the webform module should support:
http://www.formassembly.com/form-builder/

One thing stands out is the conditional validation. But playing around with it reveals many more ideas under the hood.

yojoe’s picture

subscribing to this topic

RayZ’s picture

Title: Webform module rewrite » CCK-based rewrite of webform module

Marked http://drupal.org/node/134051 as a duplicate of this.

mlsamuelson’s picture

BioALIEN,

I see a lot of "ala CCK"s in your comment. Sounds like you-all are working on replicating CCK's way of doing things? Why not just tap into CCK? Since you can control access by node type, it's not too far-fetched to create a content type and then use the node/add page as your form.

Of interest on this topic: http://groups.drupal.org/node/3705

mlsamuelson

dolittle’s picture

I`m not talking about cck just another possible solution for the original request.

Is it possible to use a template file and fill the options list? http://drupal.org/node/143936
If this could be done I`ll appreciate some guidance for this approach.

Is it possible to allow php code inside the options list field?

alvarezrilla’s picture

Subscribing

lefnire’s picture

Version: 5.x-1.x-dev » 5.x-2.0-beta3

All you gotta do is remove everything "webform" except the part that aggregates all node submissions (webform_submit) under a single node, and the reporting services. Then just plug that on CCK, tag on a checkbox that designates each content type as "webform" or not, and you have all the functionality of webform, but with the flexibility of CCK.

Drop the logic, post-validation & submission, emailing services, etc... let workflow-ng (which already plugs into cck) handle that. Drop the fields, that's part of cck. Really, I see 2 points that make webform a better solution than cck in certain circumstances:
1) it aggregates submissions under a single node, without cluttering the interface with 1000 nodes representing 1000 user submissions. reporting, csv export, etc.
2) it's got a slicker interface than cck. nicer component-creation tool, page break, etc.

looking at the code, it seems all you have to do is drop that superfluous functionality, write a few lines of gluecode to make it work on top of cck, and sit back as all your maintenance tasks and todo's of keeping up with cck fade away. You've already written the code that will make this a handy cck plug, and everything else you write would simply make it a frustrating cck competitor.

momper’s picture

subscribe

ttaylor797’s picture

subscribing

gracearoha’s picture

subscribing

gcassie’s picture

Off the top of my head, mightn't it be possible to pair a CCK content type with a webform node? You could present the form as a node creation form, then use nodeapi to let the content type def do all the validation and redirect the input to the webform's save function.

alanburke’s picture

It looks like a pretty big re-write to move to a CCK based webform.

However, the new fields API slated for Drupal 7 would change the ground rules.

If it makes it into Drupal 7, the both Webform and CCK could rely on this core Fields API.

Lets hope it makes it in

Summit’s picture

Subscribing,
greetings, Martijn

SeanBannister’s picture

sub

tandersonmd’s picture

Subscribing

dhestlund’s picture

Subscribing

mojzis’s picture

subscribing

any news thus far ?

wuf31’s picture

Interesting.. Subscribe ::

elally’s picture

Subscribing

grey_’s picture

Subscribing

cdale’s picture

I'm currently working on something like this for D6. I was hoping to make it a patch, but it's looking like a full rewrite just about. I'll post more info here as I get it. It's more of a feasibility approach at the moment. Not sure if it would fit better as webform V3 or a completely separate module. Lets see what I can come up with first. :-)

quicksketch’s picture

Version: 5.x-2.0-beta3 »

Yep, this certainly will be an entirely new version of Webform. It will not be implemented for Drupal 5. In Drupal 7 we now have fields in core, which in theory could be used with Webforms rather easily. However, every Webform field would get it's own database table. I've seen some pretty crazy webforms, so this approach would lead to literally thousands of database tables. I'm not sure if it's the path we want to take or not.

SeanBannister’s picture

Sorry I don't understand why "every Webform field would get it's own database table".

quicksketch’s picture

Because that's the way CCK works in Drupal 7. Every field gets it's own database table.

SeanBannister’s picture

That seems awfully strange, hope that was well thought out.

dakku’s picture

subscribing

shaneforsythe’s picture

subscribe

Dane Powell’s picture

+1 subscribing. Sounds very useful (and logical really- Webforms is already duplicating a lot of the functionality provided by CCK)

joachim’s picture

How about a different approach:

Instead of being a node, a webform is just a detached thing -- so instead of nid being the key to the various webform tables, we have a wfid.
An optional webform_node module keeps the old functionality of tying webform creation to node creation.
An optional webform_cck module lets you load in an entire webform into a node -- basically just a numeric field for the wfid that displays the form.
Other modules can then use webforms to allow admins to create forms and collect data, without the slightly convoluted stuff that webform_associate has to do.

quicksketch’s picture

joachim, what you've described sounds a lot like #510256: Allow webforms on any content type, which I am planning on including.

At this point a CCK/Field-based version of webform seems very, very unlikely. In D7, Fields-in-core creates a *table for EVERY field*. Considering I've seen sites that have 300+ fields on a SINGLE webform, that would mean 300(!) tables for that webform alone. This would also mean it would 300 JOINs to retrieve the results, or 300 individual selects to get a single result. Basically, a CCK-based Webform would be impossible from an efficiency standpoint and will likely never happen at this point.

gcassie’s picture

I think there's some work being done to address the huge JOIN concerns: http://groups.drupal.org/node/18302

quicksketch’s picture

As noted in that issue, the only thing that pbs.module does is create *more* tables:

Again, I am not replacing per-field storage for anything. All fields are stored in per-field tables. pbs.module provides per-bundle storage in addition.

So what you'd really end up with is 300 and one tables, however, 300 of the tables would never be used for SELECT statements. So it would solve the performance problem, but just be wildly inefficient about it, since now your data is stored in two places. :P

Dane Powell’s picture

We can certainly debate the merits of fields-as-tables, but I think the point is that pbs.module would solve the performance problem that you are worried about with a marginal amount of overhead :)

Jeff Veit’s picture

As I understand it fields has a pluggable engine which lets you replace the standard storage model with one of your choosing. Webform could use its traditional storage format together with fields.

However, even if you use the standard storage engine, does it matter if there are hundreds of tables, if they are managed? It's not like they are touched by human hand. Yes webforms can have many fields and joins could be an issue. for node though, it's turned out to be much less of an issue than it could be because a cached version is created on read, I think.

And if I'm wrong there, the PBS module solves the join problem.

The benefits of using fields will be enormous - hundreds of interesting widgets and probably a standardised UI for creating forms versus only a few widgets and maintaining your own UI.

Remon’s picture

+1

rickvug’s picture

subscribe.

varunity’s picture

+1
subscribing

quantumized’s picture

sub

selinav’s picture

subscribing

Jackinloadup’s picture

subscribe

Weka’s picture

+1
The Webform documentation states:

In fact, you can even combine CCK and Webform to add additional fields to webform nodes!

Is that correct? Does anyone know how to do that?

joachim’s picture

Of course you can; just be careful what you mean by 'fields'!

You can use CCK to add *displaying fields* to a webform node. Not *webform fields*.

Weka’s picture

Thanks for clarifying that feature, Joachim. I was hoping to use FileField as a Webform field because of its progress bar support.

rmh3093’s picture

Version: » 6.x-3.x-dev

Any update on the CCK front?

rickvug’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev

@rmh3093 Don't expect anything to happen for D6. For D7, it sounds like 3.x will be a port of what 3.x is now for D6. D7 has a new Field API that may have the flexibility needed to pull this off. Wether or not it is even a good idea to make Webform use this new API is a good question. I'd imagine that any work here would need to start off as a proof of concept in a separate project or 4.x branch. I wouldn't hold your breath.

jennycita’s picture

+1

AlfTheCat’s picture

+1

Silicon.Valet’s picture

Version: 7.x-3.x-dev » 6.x-3.x-dev

Wondering if this will fill the need for folks? Something I whipped up for a charity event. Uses any content type as a webform. New version coming soon.

http://drupal.org/node/854640

John Pitcairn’s picture

Subscribe

datarazor’s picture

subscribe

sabrawy’s picture

sub

sabrawy’s picture

interesting

joachim’s picture

Actually, I had a play with CCK last week, and found that you can fairly easily use a CCK field module to add elements to your own form. You need to feed it a faked-up $field array, but it all works, even the 'add more' button! So in theory, it would be possible for webform module to act as an alternate base to CCK's field modules, make the forms, and handle saving what the CCK field widgets return. Not a simple job, but doable I think.

rickvug’s picture

Rather than focus on D6 and CCK the focus here should be on D7 and Field API. Field API was built from the start to make any entity fieldable. I imagine that the approach for a webform type module would be to define a new "fieldform" entity where each form is a bundle. This would allow fields to be configured on a per form basis. As mentioned elsewhere on this thread, there is also the problem of webform's unique field storage requirements. Field storage is pluggable, but I have no clue if it could be made suitable for webform.

Summit’s picture

Hi, I think the focus should first be D6 and CCK because on D6 this functionality is needed, and lot's of people still have D6 (like myself), because of the fact that lot's of custom modules are not D7 ready.
greetings, Martijn

Jackinloadup’s picture

@Summit I believe the issue is that we dont have API's like entities in D6. Which I believe means that unless such functionality is back-ported it would be close to impossible to implement Webform CCK fields. Its quite unfortunate because we all know how useful that would be.

joachim’s picture

> Which I believe means that unless such functionality is back-ported it would be close to impossible to implement Webform CCK fields

I don't think it's impossible -- you just have to do it differently.

I've been playing around with this, and you can use *just* the field widget and formatter to add fields to a form. You then need something to take the place of content.module to handle a UI to add fields, and store and retrieve data. So not a simple job, and it would be a wholly different thing to entities, but you'd effectively have all the fields that modules in the CCK ecosystem define at your disposal.

quicksketch’s picture

At this point there no need to worry about D6-only or D7-only functionality. Webform is going to be using it's own APIs and not using Fields or CCK any time in the foreseeable future. See #33.

joachim’s picture

quicksketch -- I reckon there's mileage in using the various field modules as mere suppliers of widgets and data storage models. Like I say, I did a bit of exploration in this recently and it seems doable to me.

Summit’s picture

Hi Joachim, looking forward to your solution on this, would be great to have webform possibilities in cck!
greetings, Martijn

joachim’s picture

Heh -- I said I can see how this is doable, not that I had spare time to work on it, sorry :/

Summit’s picture

OK, sorry to misinterpret your remarks. Bitty you do not have the time. Greetings, Martijn

AlfTheCat’s picture

[..] and even better, you can specify a view which holds the list of nodes, allow a better filter

In between all the CCK challenges, how about views? As @alanburke describes in the original post, views integration could address a formidable portion of the desired functionality.

I'd just thought to raise the thought, however likely it is that this was already considered before...

Balbo’s picture

+1

sabrawy’s picture

What about integrate webform module with token module this will be better than only thinking integrate with cck

strellman’s picture

I found this http://drupal.org/project/webform_viewreference
Will that do what you are looking for?

sabrawy’s picture

@ #69 Thank you very much now i don't need Token this will be fine for passing any data as a component

Thank you strellman

sabrawy’s picture

@ #69 i tested the module it's not a good module just not enough to replace token

1- first you are only can choose views working on node.
2- you are only allowed to get node titles


What makes it not good. because we can't use any views user or taxonomy views, and also we can't passing with specific field not node title only. that's too limited.


i don't recommended this module @ this point i can pass node id to a webform component without i have to do views and install a module to do it for me.


i will recommended if the module will allow working with all kind of views (node, taxonomy, user) and if it can read the all the cck fields from the views.

Frans’s picture

I have started with a Fieldable Entity as Form for D7
http://drupal.org/node/1044608

I agree with quicksketch that there are issues with this approach (61 max joins in mysql for example...) but that is more a Fields API problem imho then a Webforms problem.

Feel free tot test the D7 module and comment...

joachim’s picture

> I have started with a Fieldable Entity as Form for D7

The problem with that is to have different form fields on different webform nodes, you need to have one entity bundle *per node*.

I think what is needed here is a way of having fields defined per entity, rather than per bundle. This is the same as what I was talking about further up about repurposing CCK field definitions: both CCK and FieldAPI really have two layers: field definitions, and using those definitions to store data. So what I'm suggesting is an alternative second layer which allows a field per entity. This would also enable us to do fields that users add on the fly - like Wordpress does.

Frans’s picture

> The problem with that is to have different form fields on different webform nodes, you need to have one entity bundle *per node*.

I don't see the problem... probably because i don't understand what you say.

The Entity here is FormSubmission, bundled by a Form. To use the good-old D6 node structure analogy: Forms are the node types and FormSubmissions the nodes.

> So what I'm suggesting is an alternative second layer which allows a field per entity. This would also enable us to do fields that users add on the fly - like Wordpress does.

I just don't understand what you are saying... We then end up with multiple Entities right? That could not be what you mean... (I hope).

joachim’s picture

> Forms are the node types

Precisely. That's going to be a LOT of types!

Frans’s picture

> Precisely. That's going to be a LOT of types!

That depends isn't it?
The sites we build have normally max 10 frontend forms. When we make the CCK/Fields based Forms module a little smarter, then we only have to have a bundle per layout of the form. We can always create something like 'instances' of the form.
For example, a signup form for an event has a name and an emailaddress. Say we have 10 events to promote, we can create 10 'instances' of the same form. (and not 10 forms == bundles)

I don't think this Fields/Entity based is the perfect solution for all use cases, but it is very tempting because it can catch 80% of all use cases... (and you get all the benefits for free (views, rules, fields))

rickvug’s picture

Title: CCK-based rewrite of webform module » Field API based rewrite of webform module

As noted elsewhere in this thread Field API storage is pluggable. See http://drupal.org/project/pbs for per bundle storage which is similar to CCK's field storage. Granted this storage is in addition to the table per field storage but I really don't see why this needs to be the case. A "Fields Form" type module could define its own field storage or otherwise have a dependency on a suitable storage backend. I also don't know of any arbitrary limit on the number of bundles per entity. Having a form entity type with each form as a bundle sounds perfectly reasonable.

I personally haven't dug into any of this but I don't see a problem based on everything I've read about Entities and Field API. The best way forward is to work on a proof of concept and it looks like VDMI.Frans is doing that.

I'd also note that it doesn't make sense for this to be a Webform issue at this point. Webform is a fantastic mature module purpose built for what it does. It can co-exist with a Field API based form module should one exist.

Frans’s picture

> Webform is a fantastic mature module purpose built for what it does.

I couldn't agree more with you!

> It can co-exist with a Field API based form module should one exist.

I'm not so sure about that. I have the feeling that it is a waste of energy and confusing for everyone to have 2 frontend forms modules.

I will finish that Forms module for a project i have right now; it will need some love to bring it to contrib afterwards. But first things first... let's see if this beast can come alive...

quicksketch’s picture

Granted this storage is in addition to the table per field storage but I really don't see why this needs to be the case. A "Fields Form" type module could define its own field storage or otherwise have a dependency on a suitable storage backend.

Unfortunately the Field storage system is all-or-nothing. You can't specify a different storage mechanism for each entity type and you can't disable the default storage mechanism anyway. If you use something like pbs module it will affect all entities on your entire site, regardless of their entity type.

rickvug’s picture

@quicksketch - What about this issue (pointing to Dries' commit): http://drupal.org/node/443422#comment-2087418? Also from http://api.drupal.org/api/drupal/modules--field--field.module/group/fiel...

storage (array) A sub-array of key/value pairs identifying the storage backend to use for the for the field storage.

I haven't worked with Field API so I can't say with any authority what is possible but this does point to per field storage being possible. I hope that you don't point out that I'm actually mistaken here!

Sheldon Rampton’s picture

Hm, it seems to me that there are a few ways to go with this that don't necessarily entail fieldifying webforms directly:

(1) Instead of field-enabling webform, try to make fields behave more like webforms. There are some nice UI enhancements to webforms that enable drag-and-drop additional and positioning of individual form elements. If we could get that kind of UI working for adding fields to nodes and user profiles, users could just create new content types in some (but of course not all) of the situations where they are now creating webforms.

(2) Augment the webform API for retrieval of submission results. Right now webform has the webform_get_submissions() function that can be used to retrieve results, but it's not as flexible as I think it ought to be. I'd like to see something with more options, e.g., a signature such as:

webform_retrieve_submissions($filters = array()) { ... }

where $filters could include the following:

  • nid => an individual nid or an array of nids
  • uid => an individual nid or an array of nids
  • sid => an individual sid or an array of sids
  • start_sid => a minimum sid to be returned
  • end_sid => a maximum sid to be returned
  • start_date => a minimum submitted date
  • end_date => a maximum submitted date
  • limit => a maximum number of results to be returned
  • fields => an optional array of fieldnames specifying which formfields should be returned

I'd also suggest adding a wraparound function which can simplify the structure of returned submission results, e.g., a function named webform_submission_values(). Calling webform_submission_values($submission) would return a simple array that looks like this:

array( fieldname1 => value1, fieldname2 => value2, fieldname3 => value2, ...)

These could then be used to quickly and easily write webform integration modules that could expose submission results via Views and Services, and also enable importing webform results into nodes or users via the Feeds module. If this sort of integration was easier, I think there would be less demand to make Webforms behave like CCK/Fields.

rogical’s picture

I think the rewrite in D7 is more easible, to be an entity.

tim.plunkett’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev

Couldn't it at least re-use the widgets and formatters and field types and not the storage? I attempted at least the widget part with #1268662: Provide a Media component for Webform.

joachim’s picture

Yup, that's my point from way back :)

A field type defines: which columns you need to store data, a formAPI widget, and a formatter. The field engine itself handles the actual table creation and data storage and output. Another engine built into webform could use those same field type definitions and do its own thing with tables and storage and output.

gagarine’s picture

webform should not be a node on D7. Node are good to store webpage content that's all. By being a "content", webforms are not exportable with feature or we do not have access to all type of field, ..

Like OG weform has to move to a fieldable entity http://www.archive.org/details/OrganicGroups7.

You create new form by creating new bundle. If you want two time the same webform you can create "instance" of this bundle. Instance have an URL and store the result.

But perhaps this should be a new project.

Sheldon Rampton’s picture

I think so many people are using webform as it currently designed that major changes to module architecture will be difficult to make without breaking functionality that existing users depend on. A forms creation module that creates forms as fieldable entities would be a good idea, and I think it would also be a good idea to have a forms module whose fields are based on the Field API, but it might be better to build that as a new Drupal module rather than try to rework the webform module to do this.

quicksketch’s picture

@gagarine: There are still many modules that people use in conjunction with Webform that depend on webforms being nodes. Some examples:

Scheduler: To schedule publishing/unpublishing of Webforms
Node access modules (Taxonomy Access, Node Access, OG Access): To restrict access and administrative control of Webforms
Node clone: Cloning webforms
Node export: Import/export/templating of webforms

Now most of these could probably be adapted to being entity-based, but for the time being right now everyone is mostly daydreaming about Webforms being fields and/or some other entity. It's a massive amount of work and not likely to happen any time in the immediate future (at least as part of the Webform project).

Sheldon Rampton’s picture

I think the best way to proceed would be for someone to start an entirely new webform-like module and create all new functionality from scratch. The existing webform module is very useful as proven by the large number of websites that have installed it, but in some ways it is a prisoner of past design decisions that were made at a time when Drupal didn't have entities or CCK/Fields or the Forms API. I can imagine in theory a cleaner, better module that would incorporate these newer elements of Drupal's architecture, but after spending some time mucking around trying to hack some things in the Webform module, I think it would be very difficult now to refactor the existing code to accomplish that.

When I say I can imagine a better module, I mean no disrespect to the creators of the existing webform module. It does a lot of stuff really well, and we're fortunate that it exists. (Of course, there was a time when I would have had similar praise for the flexinode module.)

Is there interest in starting a Drupal group to scope out some specs that should go into a new webform module?

lsolesen’s picture

+1

Frans’s picture

I have a Forms as Entity project in my sandbox:
http://drupal.org/sandbox/frans/1072426

A little rough edges, but it is already used on some projects with success. It has all the disadvantages as describe above, but sometimes Views support is a must have. Please give feedback via the issue queue. ... i mean the issue queue of the sandbox project ....

webankit’s picture

One more project is similar to #90, http://drupal.org/project/webform_entity
Frans can you explain differences

Frans’s picture

Pedro Lozano’s picture

It doesn't make any sense to move the webforms to a new entity type.

What it does really makes sense is to make the submissions entities, kind of what the webform_entities did, but integrated into the webform module.

The way I see it working would be this:

* There is a new entity type called webform_submission (aka: Submission) and the user can create different bundles of this entity (aka: Submission types).
* Each of these submission types is a different kind of webform.
* The user can add fields to these submission types.
* When the user creates a webform node, what they do is to just select one submission type.
* The fields from the submission type are added to the page when the webform is viewed (like the webform_entity module does).
* When any user submits the webform, an entity is created with the values submitted.

Advantages:
* Use any kind of field the Field API provides.
* Use standar entity hooks to develop custom functionality.
* Use of views to display submission. This has several advantages over the patch #680386: Views integration for the webform_submitted_data table. Field API views handlers are a more advanced that the ones webform is going to provide. For example, you can have exposed filters as select boxes.

Well, I'm sure you people can think of a lot more..

They development steps to do this would be:
* Create the new entity type 'webform_submission' with UI to manage bundles and fields.
* Add a selectable field in webform content types that allows the user to select a submission type when creating a webform node.
* Embed the form into the webform nodes and create an entity when submitted (like webform_entity module).
* Rewrite the analysis pages to work with the data stored in the entities, maybe some parts of this can be done using default views. (cons: this would add a dependence on views).

@quicksketch do you see this approach as something that could be accepted into webform? maybe for a new 4.x version?

Comments? cons?

Frans’s picture

Pedro Lozano’s picture

Thanks Frans, very useful.

rogical’s picture

Entityforms seems to be a better substitution.

lsolesen’s picture

@rogical what do you base that on?

rogical’s picture

I've tested a bit on entityforms:
1.Of coure it is an entity, a druplizer way of good data structure
2.Can easily custom submit path and retreive data via views.
3.no own fields anymore, and you can almost build the same function as webform does.

lsolesen’s picture

@rogical - is that compared to fse?

rogical’s picture

Sorry, I haven't tested FSE yet, just comparing to 'Field API based rewrite of webform'

sonicthoughts’s picture

Wow - I wish there were some convergence between webforms and entityforms such that with one tool you could store data in drupal fields / content type or as a fieldset like webform . It would certainly reduce the challenge I have choosing which module to use all the time!

Kristen Pol’s picture

Status: Active » Postponed

Webforms is good if you are worried about performance and have a ton of forms. Entityforms is good if you don't have those constraints and want to use the Field API. I would imagine this issue should be "closed (won't fix)", but I'll mark "postponed" for now.

sonicthoughts’s picture

Thanks for clarifying the choice involved, but my point is: why force the choice! There are many webform related modules avail, not to mention legacy forms created. We are using civicrm-webform integration, so a switch to entityforms is just not feasible .... likewise, entities provide a fantastic eco-system.

I'm sure there are many in this situation - I realize it is not an easy ask, but perhaps there is an opportunity for some middleground rather than an either/or choice. thanks for not closing the issue :).

quicksketch’s picture

Version: 7.x-3.x-dev » 7.x-4.x-dev

I'd like to see this issue continue kicking around. At this point, I'm thinking we'll probably revisit this topic in the Drupal 8 release cycle, where all the fields provided by Webform (i.e. Link, E-mail, Date) are now all provided by core. One of the pillars of Webform has always been, "does what you want, without additional modules", and in D8, no additional modules would be needed. So long term I'd like to see Webform use an approach similar to Entity Forms, but with all the built-in functionality of Webform.

DanChadwick’s picture

Issue summary: View changes
Status: Postponed » Closed (won't fix)

This is being considered for Drupal 8 only. Also see entityform module.