Include webform support

I'd like this in salesforce module too, however, as one of the maintainers of sf_webform I should point out it's not actually abandoned and updating for the latest version of salesforce_api is something we will be working on over the coming month - for D6 anyway, as for D7, depends on what way salesforce module goes.

This could possibly make sense, but not in the short term. We would want to do it in a way that avoids making the Suite too bloated though.

@stella: Any interest in taking my sandbox of the D6 salesforce_webform and applying it to the actual module? That way, the longstanding issue on compatibility could be closed.

Could someone help me out by determining how Webform 3.0 works in Drupal 7, so I could see how hard this would be to add to the 7.x suite?

It's now worth noting that some additional work has been done to the code in Evan's sandbox project which may be useful to those needing a D6 integration solution. However, I'm not sure how portable the current state of the code is for D7... it's looking like some more notable architectural changes are still needed.

http://drupal.org/sandbox/evandonovan/1198324

I would like to keep this as a separate module from the Suite in 7.x. I want to keep the Suite lean.

My basic thoughts on the 7.x Suite stack, as it should be:

1. API interface (authentication, SOAP/OAuth) - DONE
2. Field/object mapping (+ UI) - DONE
3. Entity import/export handlers - DONE
4. Queueing (inbound - DONE & outbound - TODO)
5. Matching logic - TODO
6. Conditional field export/import, a la Springboard - TODO

Everything above that should be in separate contribs.

Due to demand, I'm reconsidering this. Webform support is a fairly core functionality, and there is already a working sandbox version for 6.x which needs to be ported to 7.x. The simplest way to maintain that will probably be as part of the Suite.

Linking to related issue on the Salesforce Webform Integration module issue queue: #790690: Move Salesforce Webform Integration into project/salesforce; deprecate project/sf_webform.

I second that perspective. When working with, and talking to, a number of contacts about common Drupal-Salesforce integration needs, webform integration has often come up. It would be awesome to see it as part of the actual suite.

Of course it's easy to say that, but it's also worth noting that the working D6 version of that code (in the sandbox) is due for some additional architectural work. As you recall I was working on that code a bit several months ago, but my time only allowed me to ad-hocishly work-in some improvements without changing the overall structure.

So I guess my general point is that there will probably be a bit more to the effort than just porting the D6 code to D7.

It should be mentioned that there's a temporary solution in the Salesforce Web-to-Lead Webform Data Integration module which has a D7 port effort underway at #1338834: d7 port of Salesforce Web-to-Lead Webform Data Integration (acrollet provided a working patch).

My latest assessment of the "state of the art" here is at #790690-12: Move Salesforce Webform Integration into project/salesforce; deprecate project/sf_webform. It seems like there are 4 potential bases: 1) Salesforce Webform for 6.x, via my port, 2) Springboard's integration, 3) Salesforce Webform Data Integration, 4) Salesforce Web-to-Lead Webform Data Integration. It would be great if we could standardize this, but I think each person did development as needed for their use case at a given time. (I know I did.) It's a question of who would be willing to fund the time for the "base" work to get done I think.

From a user and site-builder perspective, having this as part of the suite seems like the only way to go. To date I have not encountered a Salesforce integration project where webform support is the only need, as there has always been the need to also manage syncing of user accounts and other Drupal objects to create a full integration workflow (and ensure that all the object mappings are aware of each other). So leveraging the suite, and the API it provides, seems like the best way to standardize. I can only speak from my experience though, so others may disagree.

What's interesting is that the non-suite projects have a lot of activity (hundreds of active installs) while the suite-compatible version is only in a sandbox state. I'm wondering if this means that the average need for webform integration is not so complex, and people don't want to mess around with the full suite?

From a developer perspective, though the 6.x sandbox project already makes use of the suite's API, it might actually be easier to start from scratch for a D7 version. What are your thoughts on that Evan? You obviously know that code better that I do, and you know the changes between the D6 and D7 suite/API extremely well (weren't you heading up the initial development of the D7 port of the suite?).

It would be interesting to hear from the maintainers of the other 3 projects about what their own interests are in the suite, and also if there are lots of users out there that need more than stand-alone webform integration support. Without these other maintainers invested I suppose it could be quite hard to get the resources needed for this, barring some sponsored development.

I have a current project that just needs Webform integration - i.e., replacing the Salesforce default Web-to-Lead form with a native Drupal form. I think there may be others with similar needs.

I think part of the problem with the Suite is that it had so many layers of development, so it's more complex from both a DX and UX perspective. Also, the Webform integration Salesforce modules don't use the Suite's mapping interface, but use Webform's, which is much more familiar to end users.

It may be easier to start from scratch on a D7 version for the Suite, as you suggest, especially because Webform for D7 is significantly different from D6, as far as I know. However, I am not currently working on any projects that require the full Suite functionality, so I don't have the time to work on this necessary initiative.

Agreed, the stand-alone options probably have historically led to better adaptation (at least for webform support). On the other hand though, there does seem to be a growing trend toward module "frameworks" in Drupal (e.g. an API module that's a dependency for all kinds of other feature-specific modules). I'm thinking of things like the Date API, Search API, Voting API, etc. I don't have empirical evidence for this trend, but it seems that way from observation. My guess is that this approach offers better scalability (common robust API) and wider-reaching features (more distributed dev efforts), though there are certainly downsides as well. Anyway, I'm no expert in distributed software development strategies, these are just some observations.

Thanks so much for your efforts with the D7 suite! My own projects (at least the SF integration ones) are only just now coming around to D7, so I'm looking forward to learning the changes (both functionally and under the hood).

Might it instead be better to focus this effort on improving the (deep breath) Salesforce Web-to-Lead Webform Data Integration module, which already has a D7 port?

Hi Damien,

What would be your reasons, besides the fact that there is already a D7 port in development, for focusing more energy on the Salesforce Web-to-Lead module over other webform integration options? I'm not disagreeing, I'm just wondering what factors might be at play with the the "non-suite-compatible" modules (that, btw, I am not personally very familiar with).

My guess is that if a webform module was introduced into the D7 Salesforce suite there would probably still be a need/demand for a stand-alone (and simple) webform-salesforce integration module. On the other hand however, I'm not sure that any of the stand-alone webform-salesforce integration modules can meet the needs of more complex integration scenarios (where other types of Drupal object data must also be part of the integration, etc.).

@rjacobs: I was thinking from the POV of saving development effort, if possible. At the very lease you could try contacting them, see if there's at least ways of sharing configuration settings, etc, maybe to make the transition from one to the other easier.

Yes, I think having the other maintainers weigh-in on this is a next step indeed. Any thoughts on the best way to do that? I'd be happy to open a "task" issue in each of the others' projects that links here. Perhaps this would garner attention from the right people and focus it in one place (this thread). Does that seems like a good start?

Or perhaps groups.drupal.org?

I also want to be careful to keep myself as a participant in this conversation as opposed to a facilitator (I'm certainly not the most qualified person to facilitate the process at the moment). Anyway, at the very least it would be quite useful to know if those involved with non-suite projects have been harboring any interest in working with the suite.

I'm happy to do what I can to help move things along.

I'm planning on writing a blog post shortly to explore the possibilities at length. Then I can link back to that here, and possibly on g.d.o as well. Hopefully, that will get some attention in the community (via Drupal Planet, etc.)

Sounds good, thanks for that initiative Evan. When a central message is ready we can all try to "spread the word" a bit.

By the way, here is my blog post: http://pingv.com/blog/drupal-salesforce-integration-state-of-union-pt-1. Sorry for not linking sooner - it's been a busy few months in my non-Drupal life. I hope to have pt. 2 soon, where I briefly discuss some non-Drupal alternatives and then go into more detail about what we could learn from them.

I don't think this will be added to 7.x-2.x. I'm not interested in adding this feature to 7.x-3.x, in my opinion it should be a separate project. @levelos do you have thoughts on this?

@kostajh, agreed, definitely a separate contrib module and not on our radar either. FWIW, Entity Form will work as is with 7.x-3.x.

For those searching for an appropriate contrib module, there is now a comparison page.

Please update it if you have any additional info.