Pierstoval commented 8 years ago

Hi guys, I started looking at all labeled issues and I think we can prepare specific issues to be developed in EasyAdmin 2.0.

This 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.

I 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 :) .

Here'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).

Obviously, 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.

Versioning and BC breaks policy

Related issue:

180 BC breaks policy

I 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).

Plus, I think EasyAdmin 1 should support Symfony from 2.3 to 2.8, and EasyAdmin 2 to support Symfony 3 only. A 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.

The 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. The 2.x branch would contain all new features.

Now that after almost a year the bundle grew up in something bigger and more performant, we can have more "security" in our versioning process. We 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. Still it's behind SonataAdmin, but only because it's younger. It'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).

So, I'd suggest then to make EasyAdmin 2.0 compatible with any other EasyAdmin 2.x feature in ALL terms. It 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. I 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". As 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.

Sorry for insisting :smiling_imp: :smiley:

File upload

Related issues:

398 Upload file in form

576 As vich uploader integrate with easy admin to edit the option to display the image.

275 File upload support?

File 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. Many 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:

"Bundled" solution, I mean EasyAdmin proposes a real toolbox for the file form type to allow easier handling of files, just in configuration. 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).
"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. And then, a simple suggest in the composer.json, and a Third-party Bundles bridges documentation would help the users in these cases.
Doctrine ODM (and maybe PHPCR) support

Related issue:

127 Using Doctrine ODM and other object managers

This one is a very tough one, because it would need MUCH refactoring. But, it's possible.

In theory, it would need some new services in the bundle to be working:

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). 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.
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...

In 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.

Show/Edit/New fields optimization

Related issues:

292 Will there be multi-language function?

364 SF1 AdminGenerator fields inspiration

335 Allow to add arbitrary extra fields on `show` and `list` views for entities

Actually 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). Plus, 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. So, 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). In 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 )

I 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. Nesting 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...

Ajax support

Related issues:

365 Inline edit in list view

601 Ajax integration

It's very popular now to inline-edit, and also to rely on single-field edition with AJAX. Plus, updating an entity field-by-field is a good starting point to create web-services usable by other services. Obviously, many bundles implement automatic webservices for entities, I created one some time ago (OrbitaleApiBundle which is not finished because I don't have time, heck). But 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. It's not "that" hard to create something standard.

Here is my "conceptual" proposal: A javascript implementation could be used based on data- fields. All 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. When clicking/touching(mobile/tablet) the html element, the element is hidden and the input appears, and switch back on input blur. And 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).

Behind, 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)". Now 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:

EDIT: @ogizanagi proposed to add a modal as the edit action:

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.

Search engine

Related issues:

369 Merge `list` and `search` actions.

525 Index page filter feature

465 Search on column from related table

Search 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.

Actually, in EasyAdmin 1, we could already add a more performant search engine like the one present in SonataAdmin or other backends. But I'd like to propose something more concrete, in order to let people debate about this with concrete arguments.

Here is what I propose:

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.
For each field, set/detect the searchable type: number, string, date, entity (others?) and show a convenient <input> or <select> html tag for this.
For each field, set the search logic:
- exact/different/superior/inferior for numbers
- exact/different/like/regexp for strings
- exact/different/from/before for dates
- and/or for entities

Given 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. It 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).

Third-party bundle support cookbooks

It 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.

We 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.

Templates structure

I 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.

Batch actions

Many other backends support batch actions, it should be considered too for EasyAdmin. Mostly about deletion, we could support custom actions too by adding a custom configuration for batch actions, meaning the selection of one or more objects in the list could be sent to a custom action specified by the user.

PHP Version

Actually, PHP 5.3 is going to be dead soon, and Symfony3 requires PHP 5.5, so I guess we could make EasyAdmin 2 require PHP 5.5 too.

Conclusion

Obviously 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.

javiereguiluz commented 8 years ago

@Pierstoval thanks for bringin up this discussion and for the time it took you to summarize everything. My first impression about the main topics:

Yes: file uploads integration, confg optimization, search improvement.
Maybe: create a 1.x branch compatible with PHP 5.3 and Sf 2.3 to 2.8 to fix bugs, but not to backport new features.
No: ODM, PHPCR, Ajax.

Pierstoval commented 8 years ago

I'm glad to know the features to which you say "no" are also the ones I dislike :smile: (even though simple ajax property/value inline edit could be great).

I also would like to wait some time until the "team" and the users discuss about this. Is there a possibility to "pin" the discussion on top of the issues in Github?

mkalisz77 commented 8 years ago

I would like to propose following future: Adding possibility to set Security/ROLES in config file for single entity properties.

Eg. easy_admin: entities: User: label: entity.user class: AppBundle\Entity\User edit: fields:

{ property: 'username', label: 'db.user.username', roles: ['ROLE_ADMIN'] }
show: fields:
{ property: 'username', label: 'db.user.username', roles: ['ROLE_ADMIN','ROLE_1'] }

It will be great to have this kind of functionality. Now we can only have security for entities and actions using standard Symfony Access Control functionality

{ path: ^/easyeadmin_url$, roles: ROLE_X }

Pierstoval commented 8 years ago

@mkalisz77 In your example, the role would have its place in the action itself, not in the field metadata. Creating a simple CRUD was the goal of EasyAdmin, but creating a deep CRUD over fields is very hard.

As @javiereguiluz said in other issues since he started developing this bundle, security is different for each backend, roles are different. Managing security roles is easy to do, you can override any action and add an if ($this->entity['name'] === 'MyEntity') { $this->denyAccessUnlessGranted('ROLE_CUSTOM'); }

I deliberately did not talk about security for these reasons :)

ogizanagi commented 8 years ago

Plus, I think EasyAdmin 1 should support Symfony from 2.3 to 2.8, and EasyAdmin 2 to support Symfony 3 only.

Just a side-note about that: I think you meant EasyAdmin 2 should support Symfony LTS (2.7 and 2.8) without BC support) and Symfony 3. Supporting Symfony 3 is basically the same as supporting 2.8 without BC. However 2.7 will still need some work to keep it compatible regarding symfony/form for instance. But we should keep supporting LTS. I don't know if once the 2.8 is released we could afford dropping the 2.7 support ? :/

A 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.

That's right, but that's not only about clients and money :moneybag: . In fact the most important dead-end here might be bundles :skull: . Fortunately, a lot of work has already be done in most popular ones, but still, it can cause issues if you worked with less popular ones still not supporting 3.0. And that's not simply about time, but also dev experience :/

We 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.

:sparkles: :tada: However I don't know what's the opinion of @javiereguiluz about this, but I'm not sure we can say the bundle v1 is "finished" yet. But I'd love to see a new 2.0 branch where we could review some architectural decisions to keep enhancing the bundle in the future and make it more extensible :smiley: I'm thinking about data providers, more powerfull custom actions, batch actions, etc... I particularly hate having to override so much things like Twig templates, which is a PITA for maintainability. Fortunately, as you said, the bundle has gained maturity on many aspects, but still lacks some extension points over overwriting.

About features now:

File upload

:+1: for a VichUploader bridge. it also acts as an example on how properly use EasyAdmin with third party libraries.

Doctrine ODM (and maybe PHPCR) support

NO about support. YES about reviewing and streamlining the current system. Taking example on the DunglasApiBundle which supports any data source (ORM, ODM, Elasticsearch, PHPCR, ...) but only provides an ORM implementation, I think it's totally reasonable for EasyAdmin to propose something similar with:

Data providers, with initial ORM support. Other data providers could be registered in userland or third-party bundles.
Our own set of metadata. It'll basically represent the current configuration of our entities, but will allow to tweak some of them by calling proper loaders.
Metadata loaders allowing to tweak the metadata that needs some extra infos (PhpDoc, ORM, ODM, ...). As you said, it needs a lot of work to rationalize EasyAdmin needs in order to extract metadata. But I'd love to see EasyAdmin usable with Elasticsearch or ODM.

Ajax support

I also think inline-edit would not be that hard, especially because we can reuse everything defined in the editAction as it is by simply adding a check for ajax requests and returning another view. BUT, I do not like per-field inline editing. That's my opinion, but 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.

:-1: :-1: :-1: for per-field inline editing
:+1: for embedding the whole form in a modal, allowing to edit a row without exiting the list view.

Also, per-field inline editing has a big issue for complex forms: it cannot handle dynamic fields having dependencies between them or it might lead to unexpected behaviors.

Search engine

That's definitively something that can be improved more easily if we had data providers and extensions support.

javiereguiluz commented 8 years ago

@ogizanagi I hope you have some free time to discuss these topics in person next week during SymfonyCon or the Hackday. (When I say "discuss these topics", I really mean "please show me those cool DunglasApiBundle examples and explain me your ideas"). I'm looking forward to it. Thanks!

ogizanagi commented 8 years ago

@mkalisz77 : I think you should have a look to this http://alexandre-salome.fr/media/formulaires-symfony2.pdf Particularly the SecurityTypeExtension which will allow you to remove some fields depending on user's roles.

@javiereguiluz : unfortunately, I will not be present at SymfonyCon :cry: But I guess we can talk about it in another way. Currently, I haven't well thought this yet, and I guess it'll need some POC, but I totally think it is achievable. The interfaces exposed by the DunglasApiBundle are very simple and well-thought, so it can easily be understood just by giving a look at the code :smile: . But in our case, it'll certainly be more complex :/

@Pierstoval : about your https://github.com/javiereguiluz/EasyAdminBundle/issues/603#issuecomment-160291512 and security purposes: I think we should avoid having this in the controller now, by simply creating a request listener with this check:

if (!$this->request->attributes->has('easyadmin')) {
   return; // Do not execute this listener on non-easyadmin pages
}

The best would be to have the possibility to add extra custom keys to the easyadmin conf:

easy_admin:
    entities:
        User:
            label: entity.user
            class: AppBundle\Entity\User
            roles: [ROLE_VIEWER] # <-- Custom extra key
            edit:
                roles: [ROLE_AMIN] # <-- Custom extra key

Then, it could be used by injecting the easyadmin configuration in the listener. If I'm right, for now we allow extra keys, but they won't be preserved in the entity configuration ?

Maybe this would deserve a "cookbook" entry.

Pierstoval commented 8 years ago

Thanks a lot @ogizanagi for your feedback! :smiley:

About security, I don't remember but I think that extra keys are preserved in entity configuration, it needs testing, but if they're preserved, it's an "edge case" because one day we might remove this feature if @javiereguiluz finds a way to add "more" caching solutions for the whole configuration.

ogizanagi commented 8 years ago

You're right, as for now it is probably not considered as a feature. But even if a caching solution is established, it isn't a no-go for keeping this behavior, as it remains static metadata, and is pretty useful. :smile: (By cheaply allowing to extend bundle's configuration capabilities on userland, without having to create a second configuration tree).

I know I had similar use cases with the FOSElasticaBundle where the settings node of each indexes and properties are variable nodes, and allow to add features this way.

Pierstoval commented 8 years ago

Even if I did not mention it, I still think that the easyadmin route should have a /{entity}/{action} pattern to make sure that everything can be configured under access_control in security.yml :laughing: But it has been refused many times so I don't want to push on this :smile: (even though a simple cookbook might do it).

romaricdrigon commented 8 years ago

What about supporting Symfony 3.0 right now? Is there anything retaining us from making 1.6 Symfony 3.0 compatible?

ogizanagi commented 8 years ago

@romaricdrigon : Actually, we already support Symfony 3. Unless you encountered any issue ?

The only thing is that we still support 2.3, 2.7, 2.8 and 3.0, which requires some BC layers that we can drop later.

romaricdrigon commented 8 years ago

I was mislead by this spreadsheet: https://docs.google.com/spreadsheets/d/1GOxJ2lNpLxN12YyZ87Bhsxb0iLAQ7e4UDZbJSly8Sy8/edit#gid=0 I'm updating it then.

reypm commented 8 years ago

Perhaps this is madness but I will like to see:

internal libraries configuration such as setup tags: true, tokenSeparators: [',', ' '] and any other config options for Select2 or any other libraries used here
a few docs about integrate with other bundles like for example FosJsRoutingBundle (I did it but customizing layouts)
support for composite keys and entities using inheritance (not supported in current)

@Pierstoval @javiereguiluz sorry for the little hijacking but if you will start a fresh Symfony app, will you use 2.8 or 3.0 and why? I still using 2.8 but mostly because it's a LTS version, what is your advise on this?

Pierstoval commented 8 years ago

@paquitodev Thanks for all these suggestions! I'll add them to the list in the first post :)

Also, for entities with inheritance, what kind of feature would you like to see?

Customizing select2 widget sounds like a 1.x feature, so it does not seem to be a problem for now, we may do it soon :)

And for the fresh app, I'd start it with SF2.8 because some community bundles are not supported yet, and it can be tricky if your app needs some, so I'd start it in 2.8 :)

javiereguiluz commented 8 years ago

About entity inheritance, please forget about that. Even Doctrine creators strongly recommend to avoid it at all costs. Please, never use inheritance. It complicates everything for no real benefit. This comment by Stof says the same: https://github.com/symfony/symfony-demo/issues/21#issuecomment-126923645

mkalisz77 commented 8 years ago

One nice feature published on symfony.com blog http://symfony.com/blog/new-in-symfony-2-8-dx-improvements.

Filter Results the same way in Easy Admin list view it will be very nice feature in EA 2.0.

Pierstoval commented 8 years ago

@mkalisz77 this is related to the search engine, but I don't know if I'd like this feature :confused: Actually, either we create a powerful search engine (like the ones proposed by SonataAdmin for instance), or we use the actual one and add these kind of "inline" filters, but implementing everything would be a mess IMO :confused:

reypm commented 8 years ago

@Pierstoval nvm, @javiereguiluz just said that forget about it since it's not recommended even by Doctrine creators so leave inheritance out of my suggestions. By the way @javiereguiluz what is the best way to achieve my first point now? I want to add some configs to Select2 but can't find how to do this, could you point me on the right direction?

@Pierstoval on the meantime, since you mention libraries config is a 1.x stuff, how I can achieve that? Could you give me some tips? And I ask because you're talking to made 2.x Symfony3 only and I want to keep track on this project by using latest so it's not funny to start on 2.8 and then get ride of support on newest EasyAdmin 2.x because it will be build only for SF3.0 perhaps I am wrong you tell me

Pierstoval commented 8 years ago

EasyAdmin 2.0 is not decided yet, this issue is here only to talk about what we would like to have for EasyAdmin 2.0 if it is released. Obviously, as Symfony 2.3 will reach end of life and now that Symfony 3 is released, we have to think about the future. What I'd ideally like is to maintain a 1.x branch for Symfony 2.3+ and a 2.x branch for Symfony 3.0+, but it's not decided.

What you want for the select2 plugin can be easily achieved on the actual EasyAdmin version without any BC break on people using lower versions of EasyAdmin or Symfony that may upgrade their versions. If it's a configuration parameter, you may create a custom config option in the extension by adding a new option in the Configuration class, that would have default values, and that would allow custom values or custom implementations. As I don't use select2 daily, I don't know its configuration options so I don't want to work on this because someone may have a better knowledge of it and may know exactly the select2 API, so I'd leave the task for them :D. Feel free to work on this and submit a PR if you like ;)

reypm commented 8 years ago

@Pierstoval I don't use it daily also but now I am involve on this and need this. If you can teach me how to achieve this I will be glad to work in a PR but I still need your assistance, can you guide me trough this? If so I will start a new issue regarding this topic

Pierstoval commented 8 years ago

There's a PR pending about how to contribute, even if it's not finalized you can check it out: https://github.com/javiereguiluz/EasyAdminBundle/pull/644/files?short_path=6a33714#diff-6a3371457528722a734f3c51d9238c13

reypm commented 8 years ago

@Pierstoval lol, I know the rules what I don't know is what to do regarding your previous comment on the config option and so

Pierstoval commented 8 years ago

@paquitodev It's gonna be the subject of another issue/PR then because it's not about 2.0 :)

I would also suggest, because it's a big BC break and I want BC breaks for 2.0, 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, what do you think? /cc @javiereguiluz @ogizanagi

ogizanagi commented 8 years ago

@Pierstoval : I was thinking the same actually. :+1:

Pierstoval commented 8 years ago

@ogizanagi , @javiereguiluz , I had no answers about my ideas under the Show/Edit/New fields optimization section. This is an important feature to me because I have backends that require to duplicate tons of code just because one field is present in new and not in edit (like a slug that should be immutable for SEO reasons, for example), and even if it changes the paradigm of the actual backend ‒ and it'll need a lot of refactoring ‒ we could fit a more "field-based" system, that sounds better to me than a "action-based" system.

ogizanagi commented 8 years ago

@Pierstoval : you'll don't like my suggestion, but if you don't like the action base configuration in some situations, 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 feature. It 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.

Of course, it does not replace the EasyAdmin native config, but will allow to handle the most annoying issues & limitations you can encounter.

I'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 :/

mkalisz77 commented 8 years ago

Another proposal for 2.0 version of EA is mass delete possibility. Add checkbox in first column and action for mass delete/update checked records.

ogizanagi commented 8 years ago

Batch actions capabilities in general should be considered IMO (and ability to add custom batch actions).

Pierstoval commented 8 years ago

Added batch actions to the list of desired features :)

javiereguiluz commented 8 years ago

In case is useful to make decisions about dropping PHP support, SonataAdmin run an interesting survey:

sonata_php_version

PHP 5.3 support can safely be dropped ... but 50% of people still use PHP 5.4 or 5.5!!

Pierstoval commented 8 years ago

Added PHP version to the list :smile:

mkalisz77 commented 8 years ago

My proposal for EA 2.0 is easy out-of-the-box Dependent fields functionality.

Many times we have dependent list of values eg. State/Province. Now it can be done this way: http://symfony.com/doc/current/cookbook/form/dynamic_form_modification.html

But maybe in EasyAdmin it could be done easy only by configuration. What do you think about this feature ?

ogizanagi commented 8 years ago

@mkalisz77 : I don't see how we can extract a generic configuration for this. IMHO that's something that should rely on userland, or in a dedicated bundle providing a configurable form type with this feature, but it'll stay very specific to the needs.

Pierstoval commented 8 years ago

I agree with @ogizanagi : it should be configurable with a FormType, and/or directly in the controller by overriding the createEntityFormBuilder method for your entity.

Glideh commented 8 years ago

Advanced search fields is a must have IMHO. I naively imagine something like

easy_admin:
    entities:
        User:
            class: AppBundle\Entity\User
            search:
                grouped: false            # default: true
                fields: ['firstname', 'lastname', 'enabled']
            list:
#              ...

This would render these 3 inputs separately with the related widget type.

Glideh commented 7 years ago

Here is another way how it could be configured:

easy_admin:
    entities:
        User:
            class: AppBundle\Entity\User
            search:
                fields: [firstname, lastname, {separated: true, property: enabled}]

Any separated search field would generate a dedicated search input with the guessed formtype.

sr972 commented 7 years ago

Whishlist for 2.0

ACL / ROLE_* support down to field level and based on actions
Based upon ACL / ROLE_* support an integrated login system, out of the box
Beautify URLs / Move GET parameters to POST or session or any other way SF provides (e.g. to the user object)

Pierstoval commented 7 years ago

Based upon ACL / ROLE_* support an integrated login system, out of the box

Login system is dependant of your application, so EasyAdmin can just guess what you have in your Security configuration, that's all :confused:

Beautify URLs / Move GET parameters to POST or session or any other way SF provides (e.g. to the user object)

You already can override this behavior, especially to beautify URLs :smile: (using session or POST makes no sense to me, because it breaks the history)

jazithedev commented 7 years ago

Beautify URLs / Move GET parameters to POST or session or any other way SF provides (e.g. to the user object)

I also think, that this is very unneeded.

sr972 commented 7 years ago

You already can override this behavior, especially to beautify URLs

Would you be so kind and give me a hint / link where i can find something about this?

Pierstoval commented 7 years ago

Would you be so kind and give me a hint / link where i can find something about this?

There are some examples here: https://github.com/javiereguiluz/EasyAdminBundle/issues/915

You can also search in the different issues :)

Glideh commented 7 years ago

I've been thinking a lot about advanced searching. Individual search fields are precise and straightforward to use, but I think the unique search input (Google style) remains the user friendlier way.

criteria1: search string criteria2: other search string

I did an extension to the current one in that spirit. (Blue buttons are custom batch actions that I implemented too)

Clicking on criterias adds them to the input and focuses it so the user can enter a string to search for each:

Related configuration:

easy_admin:
    entities:
        Item:
            label: 'admin_crud.item.title'
            class: AppBundle\Entity\Item
            search:
                fields:
                    -   property: 'serialNo'
                        label: 'admin_crud.item.list.serialNo'
                        search_label: 'serial'
                    -   property: 'imei'
                        label: 'admin_crud.item.list.imei'
                        search_label: 'imei'
                    -   property: 'projectCustomerSite.project.name'
                        label: 'admin_crud.item.list.project'
                        search_label: 'project'
                # ...
            list:
                actions: ['production']
                title: 'admin_crud.item.title'
                fields:
                    -   property: 'id'
                # ...

Also allowing to search on linked entities as you can see.

Pierstoval commented 7 years ago

@Glideh Your method is seducing me, I love how it works :smile: But unfortunately we should also be able to provide "many-inputs" classic search system, I've experienced many users don't know the google-search syntax and that wouldn't understand it without explanations. And most of the time, if non-experienced users are using your backend, you should focus on UX rather than DX :smile:

Glideh commented 7 years ago

I see, that's why I've put the helper dropdown to allow users to select their criterias rather than typing them. But indeed some users might not understand still.

zergu commented 7 years ago

Django-like filters would be awesome. When entity has a datetime field you get calendar widget; when it has linked entity you get dropdown or autocomple; if field is textual you get regular input for narrowing results by that field.

Pierstoval commented 7 years ago

@zergu This is already the case: when you have a related entity, EasyAdmin generates a select2 html/js widget on which you can "query" (this is not a real query because every element is rendered in the page and select2 only introduces the widget). For the case of datetime, I don't remember if we have a datepicker, but we may, I don't remember 😕

zergu commented 7 years ago

@Pierstoval Yeah, I know, but I meant automatically generated filters here. Like this one for dates: https://raw.githubusercontent.com/silentsokolov/django-admin-rangefilter/master/docs/images/screenshot.png

This could appear from config like that:

entites:
  Item:
     filter:
       - created_at

javiereguiluz commented 7 years ago

I'm closing this issue because it's already too long and it's impossible to follow all the discussions. Besides, we now have a list of future features of this bundle so we can discuss about individual features/changes in separate issues and add them to the list. Thanks!

maathieu commented 4 years ago

Hello,

Why "-1 -1 -1 for per-field inline editing" ? This would actually be very useful for backends that are bound to replace Excel spreadsheets.

EasyCorp / EasyAdminBundle

Towards EasyAdmin 2.0 #603

Versioning and BC breaks policy

180 BC breaks policy

File upload

398 Upload file in form

576 As vich uploader integrate with easy admin to edit the option to display the image.

275 File upload support?

Doctrine ODM (and maybe PHPCR) support

127 Using Doctrine ODM and other object managers

Show/Edit/New fields optimization

292 Will there be multi-language function?

364 SF1 AdminGenerator fields inspiration

335 Allow to add arbitrary extra fields on `show` and `list` views for entities

Ajax support

365 Inline edit in list view

601 Ajax integration

Search engine

369 Merge `list` and `search` actions.

525 Index page filter feature

465 Search on column from related table

Third-party bundle support cookbooks

Templates structure

Batch actions

PHP Version

Conclusion

File upload

Doctrine ODM (and maybe PHPCR) support

Ajax support

Search engine

EasyCorp / EasyAdminBundle

Towards EasyAdmin 2.0 #603

Versioning and BC breaks policy

180 BC breaks policy

File upload

398 Upload file in form

576 As vich uploader integrate with easy admin to edit the option to display the image.

275 File upload support?

Doctrine ODM (and maybe PHPCR) support

127 Using Doctrine ODM and other object managers

Show/Edit/New fields optimization

292 Will there be multi-language function?

364 SF1 AdminGenerator fields inspiration

335 Allow to add arbitrary extra fields on show and list views for entities

Ajax support

365 Inline edit in list view

601 Ajax integration

Search engine

369 Merge list and search actions.

525 Index page filter feature

465 Search on column from related table

Third-party bundle support cookbooks

Templates structure

Batch actions

PHP Version

Conclusion

File upload

Doctrine ODM (and maybe PHPCR) support

Ajax support

Search engine

335 Allow to add arbitrary extra fields on `show` and `list` views for entities

369 Merge `list` and `search` actions.