Turning webform components into objects / plugins is one of the first things I would do to make webform Drupal 8 ready.

I've begun work on that and hereby open the discussion on how to do it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

torotil’s picture

Here is the first draft version. It's not functional at this point. It's only a partial port, but I think it's enough to see where I'm headed.

The following tasks are completed:

  • Define the WebformComponentInterface.
  • Implement a WebformInvokeComponent to support legacy components.
  • Turn webform_component_invoke() into methods of WebformComponentInterface.
  • webform_component_feature() -> WebformComponentInterface::hasFeature()

There is still many places where the $component array is used directly. For those there is 3 options:

  1. If $component is used a lot within one function this is a severe hint that at least part of the function should be implemented as a method of the component object.
  2. Extend the interface to make the data available from outside.
  3. Avoid using the attribute.

One open design question at point is how to deal with the component tree. Should make all components nodes in that tree? Should the nodes be separate objects?

The patch is still D7 compatible. At the moment I don't see why we shouldn't do a 7.x-5.x and a 8.x-5.x with very similar (if not identical) API on the webform side.

fenstrat’s picture

Thanks for your work here @torotil. However while I can't speak for @DanChadwick nor @quicksketch as 7.x-4.x maintainers I'd say making stuff object oriented for the sake of it doesn't seem like a good use of resources. 8.x-4.x will be undergoing significant refactoring just to get 7.x-4.x functionality working with D8 API's (which is the goal). If you're interested in refactoring please do come work on the 8.x-4.x branch.

torotil’s picture

As said elsewhere: I'd much prefer to have a D7 version of webform that has the same interface (in terms of plugins and especially for webform components) as the D8 will have. This would save me a lot of work. Doing the refactoring as long as 8.x-4.x hasn't moved too far from 7.x-4.x would make the overhead negligible. I'd even say that 8.x-4.x would benefit from splitting refactoring and porting into two phases (either way around) instead of doing it at once. Refactoring first would pull the benefits of that into D7 too.

The patch works for 8.x-4.x as is btw.

DanChadwick’s picture

Here's a talk on plug-ins, for those who might find it helpful: https://amsterdam2014.drupal.org/session/overview-drupal-8-plugin-system

I wish I could look into the webform crystal ball and see what the webform-related module landscape will look like. We have just released a stable 7.x-4.x and there are an alarming number of add-on modules which are still not compatible with 4.x, despite years of lead time. Assuming that (slowly) these related modules are updated to support the -4.x API's, is it reasonable to expect them to support a 7.x-5.x branch with yet-again new API's?

I can see a big advantage to component module authors to having a consistent API between webform D7 and D8 components. But this history of module development is that at some point in time, development for the old/boring/moldy version of Drupal stops and new features only go into the new version. We have this now. 7.x-4.x (and the embryonic 8.x) get new features, whereas 7.x-3.x and 6.x-3.x don't.

I would tend to think that a 7.x-5.x isn't going to happen. I'd rather see the effort put into new features into 7.x-4.x and 8.x-5.x (or whatever the semantic version would be).

torotil’s picture

Assuming that (slowly) these related modules are updated to support the -4.x API's, is it reasonable to expect them to support a 7.x-5.x branch with yet-again new API's?

On the contrary. My motivation to port webform-based modules to newer versions would be a lot better if there were any API improvements. If there was a 7.x-5.x with an up-to-date API I would gladly skip porting to 7.x-4.x and port to 7.x-5.x directly. Porting from 7.x-3.x to 7.x-4.x is more like porting from one "moldy" API to another.

The only real benefits I get from porting to 7.x-4.x are the bug-fixes that haven't made it into 7.x-3.x for more than half a year without a real reason because of lack of resources. (e.g. #2215947: "Previous" button on multistep forms breaks the form when a webform is panelized)

But this history of module development is that at some point in time, development for the old/boring/moldy version of Drupal stops and new features only go into the new version.

The point of refactoring is _not_ adding new features, but to make adding new features easier. Some parts of webform - and especially the components system - feel like they have skipped that task for a long time.

And again, there is real benefits from doing the refactoring before the port to D8:

  1. The refactoring can be tested isolated from the D8 port and faster, by more people.
  2. There is no real overhead involved as long as the D8-version has not moved too far from the D7-version.
  3. It makes life easier for those having to maintain D7 sites for some time.
  4. It makes 1. possible for webform-based modules as well.

The current patch still applies to 7.x-4.x and 8.x-4.x without any changes. So there is no "waste" going on here at the moment.

At the moment I don't have the resources to port anything to D8 yet - apart from the fact that it would involve the very same tasks.

fenstrat’s picture

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

Interesting points here.

I have to say @torotil you're the exception to the rule in terms of module maintainers willing to keep up with new webform-7.x branches. I honestly cannot see a 7.x-5.x branch getting off the ground let alone getting support in the webform contrib world. With our limited resources I feel these refactorings should happen in 8.x.

Your work here certainly won't be in vain, I'll revisit it once 8.x-4.x starts shaping up and we start looking at components.

torotil’s picture

I think doing the refactoring first in D7 and then move to D8 could even be the faster path to a stable D8 version. But then again: I'm not the one to decide that. Good luck!

sumitmadan’s picture

Title: Turn webform components into objects. » Turn webform components into plugins

+1 for Drupal 8. I think we should start on this. :)

fenstrat’s picture

Title: Turn webform components into plugins » Turn webform components into objects
Status: Active » Closed (duplicate)

This is actually a duplicate of #2293945: Convert components to plugins.