Spin-off from: #1263478: Identify pieces of Drupal that could be replaced by Symfony code
Reasons
Converting the form system seems to make sense for several reasons:
1) less code to maintain,
2) one less drupalism,
3) decreased memory footprint [based on some basic comparisons]
4) lazy loading due to class loader
Details
- Symfony form component documentation - http://symfony.com/doc/current/book/forms.html
- Currently, the FAPI and render API are similiar, but not entirely the same. In order to use symfony2 form component the render API will need class components as well that will probably stay Drupal specific and simply work together with form API. Otherwise I suppose we would have to use templates for everything, unless there is some other existing mechanism to mimic the render API in symfony.
Tasks
- Determine what parts of the render API need to be mimicked as classes
- Evaluate wrapping Symfony validation and submit handlers with Drupal hooks vs using directly
- Work on a prototype
Comment | File | Size | Author |
---|---|---|---|
#17 | 1447712_17.patch | 468 bytes | chx |
#12 | symfony2-form-vs-drupal-form-api.pdf | 2.82 MB | effulgentsia |
Comments
Comment #1
webmozart CreditAttribution: webmozart commentedI'm the maintainer of the Symfony Form component. Is there any way in which I can help with its evaluation or integration?
Comment #2
sunbtw, I spent some time tinkering about this, and I believe that Symfony's Form component would rather map to Drupal's Field API concept of field types/widgets/formatters, instead of Drupal's pure Form API.
@yched was or is working on converting Field API to the new unified plugin system though, which isn't based on any Symfony components AFAIK. (Some details in http://groups.drupal.org/node/195618)
Overall, however, I still think this is too much for D8.
(Although, admittedly, it slightly depends on the Twig template system implications and consequences on Drupal's theme system, render system, and thus also form system - if that's going to happen.)
Comment #3
webmozart CreditAttribution: webmozart commentedWhy is that? As I don't know the Drupal Form API very well, which are the significant things you see missing? I'd be very interested in hearing your ideas about what should be improved.
I quickly read through the Form API Quickstart and the Form API Reference and found the general ideas behind Drupal's and Symfony's form system very similar:
A list of Symfony's interesting features for Drupal might be:
.
After two years of intensive development, the main Form API becomes stable in Symfony 2.1 which will be released soon. The documentation unfortunately does not reflect all of its capabilities, but I want to work on this during the summer and I can personally give support should you have any doubts.
Comment #4
Crell CreditAttribution: Crell commentedI suspect it's the data binding logic in the Form component that sun is referring to, since Drupal has no such automatic equivalent at this point except the Widget portion of the Field API.
Comment #5
webchickDavid Strauss was talking about this this weekend, worrying that at issues related to CMI I18N we are adding an awful lot to Drupal's form API that's already in Symfony's. I haven't evaluated either those patches or Symfony Form API to be able to comment on this, but figured I would raise it.
Comment #6
Crell CreditAttribution: Crell commentedThis is probably worth a BoF in Munich, especially if we can coax some Symfonians into attending. Maybe we can sneak someone in the back door just for a few BoFs? :-) I know Nils will be there, but he's a PHPBB guy primarily (which is also adopting Symfony).
I don't know either system well enough yet to have an opinion on the matter, other than it is worth considering, but would be an OMG huge change.
Comment #7
webmozart CreditAttribution: webmozart commentedDepending on the specific date of that BoF I could attend it to give you some insight into Symfony Forms.
Comment #8
Crell CreditAttribution: Crell commentedDrupalCon Munich is August 20-24: http://munich2012.drupal.org/ Monday the 20th is a training day, but there are some side sprints being planned. Tuesday-Thursday is the conference, lots of of sessions and also lots of BoFs. Friday is a sprint day.
Technically only registered attendees can be on-site for Tuesday-Thursday, but the sprint day (and anything extra happening Monday besides trainings) is open to all. (If you want to register, tickets are still available! :-) )
Comment #9
webchickOk, it's official: https://groups.google.com/forum/?hl=en_US&fromgroups=#!topic/symfony-dev...
Symfony has classified this as a component that they can't guarantee backwards-compatibility for 2.3 (the LTS release Drupal 8 will be relying on), which means this needs to be postponed until Drupal 9.
Comment #10
webchickIncidentally, this was discussed here: #1451056-17: [policy] How to handle unforeseen diversion of Symfony code in stable/API-locked Drupal core?
Comment #11
webchickAlso, I know there was some kind of meeting that happened at DrupalCon Munich with the creator of the Symfony Form component. Is there a write-up of that somewhere that could either be pasted or linked to from here?
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedHere's the slides that Bernhard presented. There's no write up of the discussion we had that I'm aware of, but these slides are a very good start. Perhaps we can add more comments to this issue as we remember things from the discussion.
Comment #13
David StraussThis comparison document is great. I think it makes a good case for moving to Symfony 2's form system as the natural, object-oriented successor to Drupal's Form API.
Comment #14
tim.plunkettComment #15
XanoI suggested something similar at DrupalCon Chicago, but the major criticism was a lack of flexibility. Now we can easily change a form element to another type by changing its #type property (and perhaps a few extra properties that are specific to the element type). With classes we'll have to throw away the existing object and create a new one. IMHO this might actually be a cleaner approach, but I believe performance was another objection.
Comment #16
webmozart CreditAttribution: webmozart commentedThese problems are solved in Symfony2. Each type has a name (e.g. "text") and a corresponding object (e.g. TextType) that exists exactly once in your application (performance++). You have different alternatives for augmenting a type:
1. and 2. are good ways of changing all fields using a given type. 3. and 4. are the preferred options if you want to change only specific fields.
Comment #17
chx CreditAttribution: chx commentedI did a search on one word in this issue and in the PDF and having not found it, here's a patch to get you started. This will be my only contribution to this travesty.
That word, obviously, is "security". CSRF protection and the options checker should've been the first things to verify they survive, perhaps even improve. That noone here even mentions them shows priorities crystal clear.
Comment #18
stevectorDoes anyone have the expertise/desire to submit this topic as a Drupalcon Portland Core Conversation? And potentially answer Chx's security concern?
Heyrocker is asking for D9 topics: http://portland2013.drupal.org/news/drupalcon-portland-call-core-convers...
Comment #19
David StraussI've submitted a proposal for Core Conversations for this discussion.
Comment #20
webmozart CreditAttribution: webmozart commentedGreat! Unfortunately I won't be there, but I will support you as good as I can. Maybe you can also get a hold of Fabien who will be there.
Comment #21
Crell CreditAttribution: Crell commentedI'd love to see Fabien in the Core Conversation track. He's already written more Drupal code than Lukas, who was in Core Conversations a year ago. :-)
Comment #22
stevectorDavid, your proposal isn't showing up at http://portland2013.drupal.org/program/sessions/proposed?field_experienc...
Did you submit it already?
Comment #23
David StraussI absolutely submitted it. This is the URL for me to see my submission (apparently not publicly available):
http://portland2013.drupal.org/node/3518/submission/1753
Comment #24
catchThis would need actual review before there's anything to do. Last time I looked at Symfony forms (which was a while ago), it wasn't an improvement. I think we'd be better off with 'OOP render API' and applying that to our own form systm.
Comment #25
webmozart CreditAttribution: webmozart commentedIf there's anything I can do to help or clarify your doubts, let me know.
Comment #26
sinasalek CreditAttribution: sinasalek as a volunteer and commentedThis is certainly an interesting change, i used symphony form quite some time and it's truly a modern form API which makes maintaining and developing Drupal Form API pointless.
I disagree with @catch because that's awful lot of work implementing something similar from scratch, but agree about the actual reviews, i read the issue from top to bottom and does seem fully clear whether it's possible to use symfony form in Drupal core in a practical way or not, and the issue itself is pretty much outdated.
Considering the provided document by @webmozart, great deal of my questions are answered, so think the main question now is how i can be implemented in core, what are the obstacles and limitations that need to be addressed
Comment #27
catchWe have a form/render API that's been used in production for years, and have already moved most of the processing code from procedural code to services. It also supports the full set of features we need (apart from things it doesn't, for which there are open issues). Modernising an existing system is not the same thing as 'implementing from scratch'.
With the routing system, while much was made of how much code was shared, we had to port Drupal 6/7's actual routing algorithm because there was no scalable equivalent in Symfony, not to mention problems with access checking, link generation etc. which took months to resolve. The entire start to finish of the router conversion (once you include link generation, menu links) took nearly the entire 8.x cycle. Much of this was because there was an initial assumption that current routing had to be replaced wholesale, and a lack of attention to the features that the system as a whole needs to support, so that many were 'forgotten' and had to be re-introduced much later on.
We've generally done quite well out of low-level components like YAML parsing, or very specific things like serializers. Anything central to Drupal as an application like routing and forms needs to be approached much more critically.
Comment #28
dawehnerYeah like the idea to move as much as possible to twig template just doesn't work with the way how Drupal deals with really generic forms. Drupal is not just a developer tool,
but also something for sitebuilders, which need additional abstractions. Just take config as example. In an ideal world we would just have everything in code, done. Sadly config and its capability to load more code after deploying configuration makes things more complex than an "unopinionated" component, like some of the symfony ones, can handle out of the box.
The form component itself is even more tricky because we partially have coupled the form system to the render system, so it can be really tricky.
Comment #29
sinasalek CreditAttribution: sinasalek as a volunteer and commented@catch
That's true, but we're still using big arrays for creating forms.
I understand that Drupal has a lots of specific things that are considered unrelated to Symfony forms. But we don't have to use the Symfony form as it's. We can either extend it and add Drupal specific requirements or patch it to make it more extensible, that way we can inject Drupal specific requirements without having to directly extends it and then use it as a service. One of the examples is binding to an entity, which apparently works in a very different way that Drupal does.
My point is it might be better to offload maintaining form API of core maintainers shoulders :)
i think it's great that people like @webmozart with good knowledge about symfony forms are willing to help, we can certainly leverage that.
So what would be the next step for this? i think having a list of major roadblocks would help people join in, maybe someone can comeup with a solution that addressed your concerns, what do you think ?
Comment #30
AaronMcHaleMore relevant discussion in that issue.
I was going to post something here but seemed better to post on that issue, comment #29 was roughly what I was going to post here.
Comment #31
xjmUnder our continuous upgrade path and deprecation policy, feature and API additions should be added with backwards compatibility in minor releases, so moving to 8.8.x.
This would be especially difficult to solve given how intrinsic the form API is to Drupal core, but we'd have to come up with a way to ship both APIs at once for a major, or to allow FAPI as an alternative way to use the component, or something. I also remember that the component was not nearly as fully-featured as we needed, at least previously. In any case, it would have to be solved as a backwards-compatible API addition with the old API being deprecated somehow.
Comment #32
hchonovIf we were to touch the form API then let's ensure we have common grounds for the form API and and for decoupled Drupal. I really like the suggestion from #2913372: Allow forms to be defined in three segments: schema, UI, data:
Everyone would profit from such an architecture. The backend developers will then be defining forms for the Drupal form API and for decoupled clients the very same way!
Therefore they will be able to ship a different schema while leaving no work for the frontend, as with such an architecture it should be possible for it to use the corresponding components according to the schema.
This is going to simplify the form handling in a great way.
One of the firsts steps would be to first adapt our current form API to build forms out of such definitions. Afterwards a transition to another form builder whether from symfony or somewhere else should be rather easy.
Thoughts on that?
Comment #33
David StraussSince this is active again (and it's been seven years), I think we should also examine options with rich support for automatically saving work-in-progress and other modern functionality. I'm particularly interested in looking at the capabilities of AMP forms, which are being decoupled from dependence on actually running on AMP pages (as part of Bento AMP) and support more modern user interaction patterns (via XHR-style data-bound controls) than FAPI or Symfony forms (AFAIK).
I'm particularly curious if there's an elegant integration of Symfony forms with AMP form components. They're mostly distinct in what they handle, except for the data binding.
Comment #35
Chi CreditAttribution: Chi commentedDrupal Form API hasn't got much attention since the issue has been created 8 years ago. Nowadays it seems very outdated. However migrating to Symfony Forms or to any other form component seems not realistic as it requires a huge amount of efforts. For the record, FormStateInterface consists of 92(!) methods. Also replacing Form API implies a major BC break. Looks like we have reached an impasse.
Comment #36
tim.plunkettCreate/introduce a new API alongside the existing one. Deprecate the existing one. Remove it in a future version.
Which is how we do all changes now in D8/D9+.
Comment #37
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSince it will be a new API, 9.1 is now the earliest branch this can go into, so updating the Version field accordingly. That doesn't mean planning can't start/continue in the meantime. This will be a lot of work, so even if it's started now, I wouldn't expect patches to be ready for commit before 9.1 or later anyway.
Frankly, I'm not convinced that a major rewrite of Form API onto Symfony forms is worthwhile, but that's just my current opinion, and I'm happy to be convinced otherwise, or for others to take on the bulk of the work if they find it worthwhile.
In the long run (Drupal 10? Drupal 11?), I think we should replace our Form and Render APIs with JavaScript (Node.js), as I wrote about in #2645666: [policy, no patch] Require Node.js for a future Drupal major version and rewrite some of Drupal's UI code from PHP to JS. Perhaps that was premature then, and maybe still is, but I still think that at some point, the time will be right for that, and I think Drupal's more or less existing Form API can get us through in the meantime.
I'm very much in favor of #2913372: Allow forms to be defined in three segments: schema, UI, data though, as that would be beneficial for both the PHP API and the eventual JS API. I don't think that issue requires the Symfony form component, but if the Symfony form component makes that issue easier to implement, then great!
Comment #39
Chi CreditAttribution: Chi commentedActually, that applies to Symfony Form as well. It is quite complex and looks outdated. The only benefit of using it is built-in integration with Twig and a few other Symfony components that we are already using (Http Foundation, Validator, Event Dispatcher).