{"action":"created","issue":{"url":"https://api.github.com/repos/concrete5/concrete5/issues/2717","repository_url":"https://api.github.com/repos/concrete5/concrete5","labels_url":"https://api.github.com/repos/concrete5/concrete5/issues/2717/labels{/name}","comments_url":"https://api.github.com/repos/concrete5/concrete5/issues/2717/comments","events_url":"https://api.github.com/repos/concrete5/concrete5/issues/2717/events","html_url":"https://github.com/concrete5/concrete5/issues/2717","id":93756641,"number":2717,"title":"Symfony forms integration","user":{"login":"ahukkanen","id":864340,"avatar_url":"https://avatars.githubusercontent.com/u/864340?v=3","gravatar_id":"","url":"https://api.github.com/users/ahukkanen","html_url":"https://github.com/ahukkanen","followers_url":"https://api.github.com/users/ahukkanen/followers","following_url":"https://api.github.com/users/ahukkanen/following{/other_user}","gists_url":"https://api.github.com/users/ahukkanen/gists{/gist_id}","starred_url":"https://api.github.com/users/ahukkanen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ahukkanen/subscriptions","organizations_url":"https://api.github.com/users/ahukkanen/orgs","repos_url":"https://api.github.com/users/ahukkanen/repos","events_url":"https://api.github.com/users/ahukkanen/events{/privacy}","received_events_url":"https://api.github.com/users/ahukkanen/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/concrete5/concrete5/labels/accepted:info%20needed","name":"accepted:info needed","color":"bfe5bf"},{"url":"https://api.github.com/repos/concrete5/concrete5/labels/type:enhancement","name":"type:enhancement","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":31,"created_at":"2015-07-08T10:27:02Z","updated_at":"2016-03-01T09:20:59Z","closed_at":null,"body":"I'd like to hear some thoughts on whether we could introduce [Symfony forms](https://symfony.com/doc/current/book/forms.html) into concrete5.\r\n\r\nThis would really make it easier to build forms on single pages and why not everywhere else as well. It would also generalize e.g. form validation, display of form errors specifically to some field, make the developers write code with less bugs (as we could use generalized components), handle automatically CSRF validation, and probably many other benefits as well. And of course, make the code more testable.\r\n\r\nAnd now that we have the possibility to use Doctrine entities, they can be easily mapped into Symfony forms, so building CRUD interfaces for Doctrine entities would become quite much easier than it is today, almost automatic.\r\n\r\nBasically all the bigger and widely used frameworks provide something similar to this, so this is really an important feature for most developers choosing a good framework to build something bigger.\r\n\r\nAs a reference implementation, here's an example I put together:\r\nhttps://github.com/mainio/c5_symfony_forms_example\r\n\r\nIt relies on a couple of composer packages that I also put together to make this all work within c5.\r\n\r\nIt also uses twig templates not necessarily because I'd want to use them but I realized the twig bridge for the form component is quite much lighter in terms of included packages than the alternative PHP version. If we wanted to use the PHP version, we would need to include quite many composer packages we don't really need or only need a very small portion of it. That's the reason for using the twig bridge there. Or other option is also writing our own bridge for the form component.\r\n\r\nOn the other hand, introducing twig as well into c5 might not be that bad idea either. It seems to have catched up quite well and it's already used by Drupal and it's the default template engine in Symfony, so it's not going anywhere any time soon. And the default engine in Symfony means that all the Symfony documentation provides twig examples as the primary examples of anything related to the views. Other advantages would include enforcing people to keep business logic out of the view layer and also cleaner views in general.\r\n\r\nAny thoughts? Are you open to the idea? How about the twig issue then?"},"comment":{"url":"https://api.github.com/repos/concrete5/concrete5/issues/comments/190629503","html_url":"https://github.com/concrete5/concrete5/issues/2717#issuecomment-190629503","issue_url":"https://api.github.com/repos/concrete5/concrete5/issues/2717","id":190629503,"user":{"login":"ahukkanen","id":864340,"avatar_url":"https://avatars.githubusercontent.com/u/864340?v=3","gravatar_id":"","url":"https://api.github.com/users/ahukkanen","html_url":"https://github.com/ahukkanen","followers_url":"https://api.github.com/users/ahukkanen/followers","following_url":"https://api.github.com/users/ahukkanen/following{/other_user}","gists_url":"https://api.github.com/users/ahukkanen/gists{/gist_id}","starred_url":"https://api.github.com/users/ahukkanen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ahukkanen/subscriptions","organizations_url":"https://api.github.com/users/ahukkanen/orgs","repos_url":"https://api.github.com/users/ahukkanen/repos","events_url":"https://api.github.com/users/ahukkanen/events{/privacy}","received_events_url":"https://api.github.com/users/ahukkanen/received_events","type":"User","site_admin":false},"created_at":"2016-03-01T09:20:59Z","updated_at":"2016-03-01T09:20:59Z","body":"I think the requirement for using the homebrew validation layer with Symfony forms is kind of a showstopper for this since I don't think it would be possible easily. Or alternatively, we would end up rewriting some internal parts of the Symfony forms which would leave very little benefit in using it at all since I think the biggest advantage/difference it has over the other libraries is exactly the validation.\r\n\r\nAlso, I checked about the `symfony/translation` requirement and it seems that these are not only used in the view layer but these are also a direct requirement by the `symfony/form` component because the library is also used for the validator translations. The component also ships with the XMLs containing these translations.\r\n\r\nThe translator could of course be overridden (through implementing own version of the TranslatorInterface) to use the concrete5's own translation layer but it would not get rid of the `symfony/translation` requirement.\r\n\r\nSo even if we rewrote the translator and the templating layer dependencies, we could not get rid of those packages as a couple of interfaces would still be required from each of them.\r\n\r\nI think the other points might be possibly solvable but it's starting to seem it would be wasted effort to investigate those.\r\n\r\nIt's a shame since I really think this makes building dashboard interfaces really fast and enjoyable, avoiding writing the same code over and over again (view layer, validation and assigning the values to the data object). Shipping with these in packages is really tough since all packages need to be essentially using the same version of the libraries and it adds up quite a lot to the package size."}}