Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

[TreeManagerType] create/edit_in_overlay shows layout #33

Open
dantleech opened this issue May 21, 2013 · 8 comments
Open

[TreeManagerType] create/edit_in_overlay shows layout #33

dantleech opened this issue May 21, 2013 · 8 comments
Labels

Comments

@dantleech
Copy link
Member

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?

@dbu
Copy link
Member

dbu commented May 22, 2013

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)

@sjopet
Copy link
Member

sjopet commented Jun 21, 2013

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.

@halundraN
Copy link
Contributor

Hello,

I'm working on the PrestaCMS, and I'm trying to manage a menu tree in the website admin like describe in prestaconcept/open-source-management#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?

@halundraN
Copy link
Contributor

@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 ?

@nicolas-bastien
Copy link
Member

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.* ?

@dbu
Copy link
Member

dbu commented Mar 11, 2014

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 sonata-project/SonataDoctrinePhpcrAdminBundle#219 and bump the requriement to the newer sonata admin. so this feature could only work in the upcoming version.

@nicolas-bastien
Copy link
Member

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 ?

@dbu
Copy link
Member

dbu commented Mar 11, 2014

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants