{"action":"created","issue":{"url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/603","labels_url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/603/labels{/name}","comments_url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/603/comments","events_url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/603/events","html_url":"https://github.com/javiereguiluz/EasyAdminBundle/issues/603","id":119052585,"number":603,"title":"Towards EasyAdmin 2.0","user":{"login":"Pierstoval","id":3369266,"avatar_url":"https://avatars.githubusercontent.com/u/3369266?v=3","gravatar_id":"","url":"https://api.github.com/users/Pierstoval","html_url":"https://github.com/Pierstoval","followers_url":"https://api.github.com/users/Pierstoval/followers","following_url":"https://api.github.com/users/Pierstoval/following{/other_user}","gists_url":"https://api.github.com/users/Pierstoval/gists{/gist_id}","starred_url":"https://api.github.com/users/Pierstoval/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Pierstoval/subscriptions","organizations_url":"https://api.github.com/users/Pierstoval/orgs","repos_url":"https://api.github.com/users/Pierstoval/repos","events_url":"https://api.github.com/users/Pierstoval/events{/privacy}","received_events_url":"https://api.github.com/users/Pierstoval/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/labels/2.0%20(Symfony%202.8/3.0)","name":"2.0 (Symfony 2.8/3.0)","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":27,"created_at":"2015-11-26T14:13:06Z","updated_at":"2015-12-18T21:59:01Z","closed_at":null,"body":"Hi guys, I started looking at all labeled issues and I think we can prepare specific issues to be developed in EasyAdmin `2.0`.\r\n\r\nThis discussion is here to debate about features that anyone would want/need in EasyAdmin, and that **may introduce BC breaks**. This is why we are talking about `2.0`: to be free of maintaining BC in the bundle, and be free of breaking it entirely in new versions.\r\n\r\nI could search some issues and examples easily in the different opened and closed PRs/issues on Github, thanks to @javiereguiluz who labeled some of them and made them \"easier\" to find :) .\r\n\r\nHere's a list of the issues that I propose to be developed in a BC-breaking `2.0` version of EasyAdmin (list can/will be updated in the future).\r\n \r\nObviously, all of these issues are **proposals**, and are **my opinion**, and this issue is here for anyone to debate about \"general\" EasyAdmin features we want to be much improved.\r\n\r\n## Versioning and BC breaks policy\r\n\r\nRelated issue: \r\n#180 BC breaks policy \r\n\r\nI propose that we keep a 1.x and 2.x branch for BC break reasons, because I'd like EasyAdmin 2 to break BC in many ways in order to improve DX and performances (there are some configuration cases we can remove, for example).\r\n\r\nPlus, I think EasyAdmin 1 should support Symfony from 2.3 to 2.8, and EasyAdmin 2 to support Symfony 3 only.\r\nA lot of companies won't certainly migrate from Symfony 2 to 3, it's their choice, and I know in my agency we have some cases of SF2.3 apps that \"won't\" migrate because of, you know, clients, money, whatever.\r\n\r\nThe 1.x branch would be still maintained only for fixing bugs, because we don't know if there's gonna be some more bugs found in the future.\r\nThe 2.x branch would contain all new features.\r\n\r\nNow that after almost a year the bundle grew up in something bigger and more performant, we can have more \"security\" in our versioning process.\r\nWe cannot tell anymore that EasyAdmin is \"still a young and small project\", especially when I see that EasyAdmin is in the Top 10 of the most used Symfony bundles.\r\nStill it's behind SonataAdmin, but only because it's younger.\r\nIt's not a competition against Sonata, but actually, there are *needs* in a backend generator, and we provide them, but we still *need* more features to be sure everyone's satisfied (as SonataAdmin does too).\r\n \r\nSo, I'd suggest then to make EasyAdmin 2.0 compatible with any other EasyAdmin 2.x feature in ALL terms. \r\nIt means that if we update a twig template, for example, we must make sure that anyone already overriding this template won't have to refactor code after updating the package.\r\nI suggest this because we have an app that have EasyAdmin 1.4 installed on it, not updated for 6 months (because of, you know, clients, money, whatever). Now we have to update it (we really *have to*, it's planned and sold) so there's refactoring to do because EasyAdmin 1.4 was still young while 1.9 has more things in it and has sort of \"maturated\".\r\nAs the bundle is \"stabilized\" now, I don't think there are going to be much BC breaks in the future, but actually we need to think about them **right now**, to be sure we induce ALL BC breaks at the same time and not in a minor-version upgrade.\r\n\r\nSorry for insisting :smiling_imp: :smiley: \r\n\r\n## File upload\r\n\r\nRelated issues: \r\n#398 Upload file in form\r\n#576 As vich uploader integrate with easy admin to edit the option to display the image.\r\n#275 File upload support?\r\n\r\nFile upload is one of the Symfony features that is not easy to do, very criticized (saw on some reddit, stackoverflow and twitter posts...) because it's \"simple\" in theory, and a bit tricky in practice.\r\nMany bundles have \"reinvented\" the wheel to allow developers to handle uploads in a much easier way, and I think we could develop something for it, here are two proposals:\r\n\r\n1. \"Bundled\" solution, I mean EasyAdmin proposes a real toolbox for the `file` form type to allow easier handling of files, just in configuration.\r\n  It could be present in terms of form event callbacks (as I personally usually do with file handling in my FormType classes) or specific methods in the AdminController (which will totally respect the \"config & controller-only\" politics of EasyAdmin).\r\n\r\n2. \"Bridge\" solution, which will only be made of code bridges (compiler passes or something) that will handle solutions for other bundles like VichUploader or others and add configuration/services so the user does not have to handle the whole bundle configuration itself.\r\nAnd then, a simple `suggest` in the `composer.json`, and a `Third-party Bundles bridges` documentation would help the users in these cases.\r\n\r\n## Doctrine ODM (and maybe PHPCR) support\r\n\r\nRelated issue: \r\n#127 Using Doctrine ODM and other object managers\r\n\r\nThis one is a very tough one, because it would need MUCH refactoring.\r\nBut, it's possible.\r\n \r\nIn theory, it would need some new services in the bundle to be working:\r\n\r\n* An `ObjectManager` abstract decorator that would be configurable as in FOSUserBundle or in SonataAdmin, and, just to prepare the field, a `DoctrineOrmDecorator` (and after a `DoctrineOdmDecorator` or `PhpcrDecorator` or `PropelDecorator` or whatever custom one).\r\n  The advantage is that we can delegate all \"database-related\" tasks to the different managers, but also take care of metadatas only in these classes and depending on the specific behavior induced by every object manager. Obviously, metadatas should still be cached in any way because we need performance.\r\n\r\n* Maybe a `ObjectMetadatas` handler, because all ORMs/ODMs can manage metadatas in different ways, and we could then either detect automatically how metadatas should be handled depending on the object manager, or we could do it manually by delegating the task to any solution available, and fallback on errors/workarounds. I'm not very sure about this, but maybe...\r\n\r\nIn practice, obviously it's very hard, but it can be done. Sonata made it with different bundles. We don't have to manage \"all\" things, but at least Doctrine ODM can be fairly enough because it's used in many non-entity document-based backends.\r\n\r\n## Show/Edit/New fields optimization\r\n\r\nRelated issues: \r\n#292 Will there be multi-language function? \r\n#364 SF1 AdminGenerator fields inspiration \r\n#335 Allow to add arbitrary extra fields on `show` and `list` views for entities\r\n\r\nActually this would need some refactoring of the fields system, but as I said in #364, managing fields now is very \"duplicative\". If you need to handle all actions `list`, `show`, `new` and `edit`, then you will have to duplicate field parameters on all of them, therefore having the same label, the same `type`, etc., so this becomes very annoying. Still the same example: my backend that manages more than 10 entities, my EasyAdmin config file is more than 200 lines long, and there is no \"full-config\" yet, as many entities will certainly need some optimization soon because the backend will be multi-language and I need to translate all labels in an optimized and uniformed way (so that the translation files are easier to read).\r\nPlus, when one entity has a very complex feature for `edit` and `new`, but one field is present in `edit` and not in `new` (or vice-versa), duplication is mandatory because we can't use the `form` option that handles both actions.\r\nSo, in the end, config files for complex backends may certainly reach more than 500 lines of configuration, which is a PAIN and very hard to maintain (even in SF1 AdminGenerator, complex backends are really hard to maintain, even if it's a bit more optimized than EasyAdmin).\r\nIn terms of configuration, we could still add specific config for each field in the actions, either by adding an action-specific property in the field itself (like ` { property: slug, edit_action: { specific:code } }` for example) or by overriding them inside the action (one of the two solutions only, or it'll consume much performance :p )\r\n \r\nI was also thinking about adding a tab support, like proposed in #292 for multi-locale fields. This can be done now by adding a `tab` or `section` parameter to all fields, having `default` or `general` as default value.\r\nNesting the tabs manually in the config is also a solution but it can be tricky as our configuration system is VERY flexible, so adding more flexibility might introduce edge-cases...\r\n\r\n## Ajax support\r\n\r\nRelated issues: \r\n#365 Inline edit in list view\r\n#601 Ajax integration \r\n\r\nIt's very popular now to inline-edit, and also to rely on single-field edition with AJAX.\r\nPlus, updating an entity field-by-field is a good starting point to create web-services usable by other services.\r\nObviously, many bundles implement automatic webservices for entities, I created one some time ago ([OrbitaleApiBundle](https://github.com/Orbitale/ApiBundle) which is not finished because I don't have time, heck).\r\nBut a single property/value web service could be good because it would allow us to merge the `show` and `edit` view and allow single-property edit.\r\nIt's not \"that\" hard to create something standard.\r\n \r\nHere is my \"conceptual\" proposal:\r\nA javascript implementation could be used based on `data-` fields.\r\nAll elements having `data-easyadmin-ajaxedit` html parameter would use `data-easyadmin-property=\"\"` parameter to specify the property name, and all these nodes would have an `<input>` hidden by default automatically generated by the js solution.\r\nWhen clicking/touching(mobile/tablet) the html element, the element is hidden and the input appears, and switch back on input blur.\r\nAnd on the input's blur, an AJAX request is made to the server. If it returns an error, a simple error message is shown right after the field so we can know it has a problem (validation error, specificly).\r\n \r\nBehind, the php code would generate a form simply based on one field: the one retrieved from EasyAdmin's config. This would trigger validation as usual and therefore we just need to return a json object with `success: true/false` and `message: \"potential error message(s)\"`.\r\nNow it's implemented without the form component, so some refactoring might be needed for this, but actually this can be handled in a brand new `ajaxEditPropertyAction` :smiley: \r\n\r\nEDIT: @ogizanagi proposed to add a modal as the `edit` action:\r\n> I think a modal with the whole form in it when clicking on `Edit` button is way more efficient (excepts for toggles). And it'll be pretty straightforward to implement, because as I said, it's only about adding a check for ajax request in `editAction`.\r\n\r\n## Search engine\r\n\r\nRelated issues: \r\n#369 Merge `list` and `search` actions.\r\n#525 Index page filter feature \r\n#465 Search on column from related table \r\n\r\nSearch is very important in backends that contains lots of datas. In my \"maps manager\" application, we can have to manage hundreds of markers, routes and zones, and even if they're editable in an interactive JS map, sometimes we just need to rename the marker and we don't know where it is in the map, so this is why managing them in a classic CRUD backend is good. But actually, we sometimes need to perform a \"marker type\" or \"marker name like\" search, and this becomes much harder with EasyAdmin, especially with tons of datas.\r\n \r\nActually, in EasyAdmin 1, we could already add a more performant search engine like the one present in SonataAdmin or other backends.\r\nBut I'd like to propose something more concrete, in order to let people debate about this with concrete arguments.\r\n \r\nHere is what I propose:\r\n* In the app, determine the list of all searchable fields (`searchable: true/false` (true by default, I'd say) in the `list` action, for instance) depending on the metadatas and the easyadmin config.\r\n* For each field, set/detect the searchable type: number, string, date, entity (others?) and show a convenient `<input>` or `<select>` html tag for this.\r\n* For each field, set the search logic:\r\n  * exact/different/superior/inferior for numbers\r\n  * exact/different/like/regexp for strings\r\n  * exact/different/from/before for dates\r\n  * and/or for entities\r\n\r\nGiven this list, we could put it anywhere: on top of each column in the list, or in a specific section above or under the table.\r\nIt could even be in a specific `search` view, different than the `list` one. It's like any \"advanced\" search button in a website: you basically have a search input that will perform a \"basic\" search, and an \"advanced search\" button that allow you to specify specific / per-field advanced search (and in this case I'd put it above the results table).\r\n\r\n\r\n## Third-party bundle support cookbooks\r\n\r\nIt could be good that EasyAdmin itself stores some cookbooks for third party bundles integration, like VichUploader or FOSUser, IvoryCKEditor, or, as suggested by @paquitodev, FOSJsRoutingBundle for example, because these are very common and some users can feel some pain in integrating them.\r\n\r\nWe already have \"linked\" cookbooks on some blogs, but actually, having all docs right here on github is more accessible and easier to find for any newcomer.\r\n\r\n## Templates structure\r\n\r\nI suggest to move ALL `field_*` templates in a proper `fields` directory because it pollutes the \"default\" directory which is about *backend templates* and not about *single field templates*.\r\n\r\n## Conclusion\r\n\r\nObviously there is no conclusion yet because the debate has started, but maybe I'll edit the post in the future to add a summary of all different decisions made throughout the discussions."},"comment":{"url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/comments/165906732","html_url":"https://github.com/javiereguiluz/EasyAdminBundle/issues/603#issuecomment-165906732","issue_url":"https://api.github.com/repos/javiereguiluz/EasyAdminBundle/issues/603","id":165906732,"user":{"login":"ogizanagi","id":2211145,"avatar_url":"https://avatars.githubusercontent.com/u/2211145?v=3","gravatar_id":"","url":"https://api.github.com/users/ogizanagi","html_url":"https://github.com/ogizanagi","followers_url":"https://api.github.com/users/ogizanagi/followers","following_url":"https://api.github.com/users/ogizanagi/following{/other_user}","gists_url":"https://api.github.com/users/ogizanagi/gists{/gist_id}","starred_url":"https://api.github.com/users/ogizanagi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ogizanagi/subscriptions","organizations_url":"https://api.github.com/users/ogizanagi/orgs","repos_url":"https://api.github.com/users/ogizanagi/repos","events_url":"https://api.github.com/users/ogizanagi/events{/privacy}","received_events_url":"https://api.github.com/users/ogizanagi/received_events","type":"User","site_admin":false},"created_at":"2015-12-18T21:59:00Z","updated_at":"2015-12-18T21:59:00Z","body":"@Pierstoval : you'll don't like my suggestion, but if you don't like the action base configuration in some situation, I'll recommend you to give a try into importing a PHP file (similarly to what is done in the `MicroKernel`, using `$container->loadFromExtension`) in your config.yml or the [`prepend extension`](http://symfony.com/doc/current/cookbook/bundles/prepend_extension.html) feature. \r\nIt will allow you to configure directly EasyAdmin using PHP and so optimize anything according to your needs. You could even imagine your own configuration file to load and convert it into EasyAdmin config.\r\n\r\nOf course, it does not replace the EasyAdmin native config, but will allow to handle the most annoying issues & limitations you can encounter.\r\n\r\nI'm not in favor of a \"field-based\" system, because I think the current system is more logical: wider to more precise configuration. IMO it won't read really great with a \"per-field\" system :/"}}