[TreeManagerType] create/edit_in_overlay shows layout
This switch seems to display the entire sonata admin interface in the overlay - it would seem that what is needed is only the form.
Is this a known problem, or could it be local to my setup?
afaik @elHornair did this, and we said rather have poor UI than nothing at all. so we would want to strip things from the layout that are not needed if possible, but just had not time to do it. certainly room for improvement. (note that this is probably more a sonata phcpr admin thing than tree browser thing to fix)
I will have a look and see if we can fix this by using the sonata admin form types. I'm not sure it's possible to tie that logic to the tree but will have a go at it.
Hello,
I'm working on the PrestaCMS, and I'm trying to manage a menu tree in the website admin like describe in https://github.com/prestaconcept/open-source-management/issues/2
I would like to execute each node actions (create, edit, delete) in a modal. Then I try to use the "doctrine_phpcr_odm_tree_manager" field type with "create_in_overlay", and "edit_in_overlay" options but they use an iframe with a complete layout.
@sjopet did you find something on this problem, how can I help?
@rande I would like to render an admin action without layout but I'm not in Ajax context but iframe. I proprose to add a test in the CRUDController#getBaseTemplate() on a param "has_layout" with the isXmlHttpRequest(). I can PR this today and patch cmf.
What do you think about this ?
Hi, I had a look at this.
Ajax mode does not fit cause there is no css an js loaded so form does not render correctly.
I think the best is to add a mode "iframe", and add it as a parameter when we call the action.
If iframe mode is on, we hide the main menun the get back to list and add button.
Then update just show the form again with the successfull message and use can close the iframe by clicking on the close.
What do you think about this idea ?
But by the wy if we PR sonata admin we gonna face the problem that phpcr admin is fixed on : "sonata-project/admin-bundle": ">=2.2.7,<2.2.9" ?
what should we do to be on 2.2.* ?
i am no frontend guru, if the iframe scenario is the best option and works more or less reliably then yes, lets do that. does the orm do something similar already? i would expect it to be a common problem for sonata.
regarding the versions: the problem is that the admin bundle does not follow semver (so a dot version can BC break completely). this happens with 2.2.9, we can't support both <2.2.9 and >=2.2.9 in the same code as namespaces changed without keeping a BC class in place or anything. we said that for the 1.1 release, we lock to the old version, and right afterwards i will update master to alias 1.2.x and merge https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/pull/219 and bump the requriement to the newer sonata admin. so this feature could only work in the upcoming version.
Oh yes I agree sonata versionning is a pain (but project is great so ;-)
Right now I did PR on sonata admin when I was working with the translationbundle so I didn't figure out that the code I need in sonata won't be available in 2.2.8.
As I plugged my PrestaCMS on sonata translation, now I'm a little embarrassed. So if people really need this 1.1 locked, why don't we branch and work on 1.2 now ?
And the same for block bundle ?
yeah, if i would not like what sonata provides, i would not care about the versioning pain and simply ignore it :-)
about working on 1.2, that would be a bit weird because 1.1 is not even released yet. we have a discussion if we emergency-style bump everything to the newer versions, but if we do that somebody needs to volunteer to invest the time these days to get it right. releasing a half-backed breaking thing would suck - and we are already 2 months behind our plan to release a month after sf 2.4 came out, so we don't want to delay further. if you don't mind working on dev instead of stable releases, we plan to switch the projects depending on sonata to the newer versions immediately after the release and start working on that. but until those are tagged stable, it will probably be june.