split sonata admin bundles

[David Buchmann]

hi,

some of you brought that topic up a couple of times and i was always
against it. but lukas convinced me that we should start doing this as of
2.0 versions of the bundles. not everybody uses sonata, and its
difficult to sync things with sonata admin so we would be better of
separating them into separate bundles. i propose we do that when working
on 2.0 versions, so for now that would be a CmfMenuSonataAdminBundle

what do others think?

david

[Wouter de Jong]

I do not like the idea of one integration bundle per CMF bundle. Imagine the

developer experience when using CmfMenuBundle with SonataAdmin and

Doctrine PHPCR:

Before

new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),

After

new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),

new Symfony\Cmf\Bundle\MenuSonataAdminBundle\CmfMenuSonataAdminBundle(),

new Symfony\Cmf\Bundle\MenuDoctrinePHPCRBundle\CmfMenuDoctrinePHPCRBundle(),

Now, imagine this not only for one bundle but for like 4 (routing, content, menu, core),

things will already pretty hard to manage.

Imo, we should introduce the bridging system that Symfony uses and create

CmfSonataAdminBridge, with all the admin classes. We can then let each bundle

register the admin when this bridge is available and use_sonata_admin is auto/true (or we

use a CmfSonataAdminBundle to do it, based on the registered CMF bundles).

This brings back the other common CMF topic: To maintain this, we should use subtree

splits (maybe Sensio's perfect split system can help us here) and create a symfony-cmf/bundles

(or the like) repository.

david

--
You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gmx Privat]

Wouter i like your bridge idea. 

One question about your subtree thing in bundles: is that a step into a monolythic repository? Saw some interessting Talks about that Last year. 

Mit freundlichen Grüßen

Maximilian Berghoff

---------------------------------------

Maximilian Berghoff

Wiesenstraße 44

91617 Oberdachstetten 

Mail: Maximilia...@gmx.de

Mobile: +49 151 64825096

[Lukas Kahwe Smith]

On 18 Dec 2015, at 20:08, Wouter de Jong <jong.de...@gmail.com> wrote:

I do not like the idea of one integration bundle per CMF bundle. Imagine the

developer experience when using CmfMenuBundle with SonataAdmin and

Doctrine PHPCR:

Before

new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),

After

new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),

new Symfony\Cmf\Bundle\MenuSonataAdminBundle\CmfMenuSonataAdminBundle(),

new Symfony\Cmf\Bundle\MenuDoctrinePHPCRBundle\CmfMenuDoctrinePHPCRBundle(),

Now, imagine this not only for one bundle but for like 4 (routing, content, menu, core),

things will already pretty hard to manage.

Imo, we should introduce the bridging system that Symfony uses and create

CmfSonataAdminBridge, with all the admin classes. We can then let each bundle

register the admin when this bridge is available and use_sonata_admin is auto/true (or we

use a CmfSonataAdminBundle to do it, based on the registered CMF bundles).

This brings back the other common CMF topic: To maintain this, we should use subtree

splits (maybe Sensio's perfect split system can help us here) and create a symfony-cmf/bundles

(or the like) repository.

The reason why I do not think this is a good idea (then again maybe I did not understand it properly) is that with Sonata we have a very complicated dependency as they do not follow semver. Furthermore I think we have to drop the idea of highly synced CMF Bundle releases. We simply do not have the resources to do this and the result of this is that we effectively always release with huge delays and things seem to be getting worse rather than better.

As a result I think we need to look at each Bundle somewhat independently.

regards,

Lukas Kahwe Smith

sm...@pooteeweet.org

[Daniel Leech]

We discussed this in March:

https://github.com/symfony-cmf/symfony-cmf/issues/216

I like the idea of having a single SonataAdminBundle.

On Sat, Dec 19, 2015 at 11:00:21AM +0100, Lukas Kahwe Smith wrote:
> On 18 Dec 2015, at 20:08, Wouter de Jong <[1]jong.de...@gmail.com>

> [2]sm...@pooteeweet.org

>
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [3]symfony-cmf-de...@googlegroups.com.
> For more options, visit [4]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:jong.de...@gmail.com
> 2. mailto:sm...@pooteeweet.org
> 3. mailto:symfony-cmf-de...@googlegroups.com
> 4. https://groups.google.com/d/optout

[Lukas Kahwe Smith]

> On 19 Dec 2015, at 15:51, Daniel Leech <dan...@dantleech.com> wrote:
>
> We discussed this in March:
>
> https://github.com/symfony-cmf/symfony-cmf/issues/216
>
> I like the idea of having a single SonataAdminBundle.

But how will this work out in practice when we have some Bundles getting minor updates, some major updates. Some working or even requiring newer versions of Symfony/Sonata, some requiring older versions?

I think this new Bundle will end up being quite messy and/or limit the combinations

[David Buchmann]

can't bundles now specify related bundles that should be instantiated
automatically? i thought there was discussion about that.

my worry is that with menu bundle moving towards 2.0, but routing bundle
not, a single bridge bundle could head into a really confusing and hard
to maintain situation.

On 18.12.2015 20:08, Wouter de Jong wrote:
> I do not like the idea of one integration bundle per CMF bundle. Imagine the
> developer experience when using CmfMenuBundle with SonataAdmin and
> Doctrine PHPCR:
>

> *Before*

> new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),
>

> *After*

> new Symfony\Cmf\Bundle\MenuBundle\CmfMenuBundle(),
> new Symfony\Cmf\Bundle\MenuSonataAdminBundle\CmfMenuSonataAdminBundle(),
> new Symfony\Cmf\Bundle\MenuDoctrinePHPCRBundle\CmfMenuDoctrinePHPCRBundle(),
>
> Now, imagine this not only for one bundle but for like 4 (routing,
> content, menu, core),
> things will already pretty hard to manage.
>
> Imo, we should introduce the bridging system that Symfony uses and create
> CmfSonataAdminBridge, with all the admin classes. We can then let each
> bundle
> register the admin when this bridge is available and use_sonata_admin is
> auto/true (or we
> use a CmfSonataAdminBundle to do it, based on the registered CMF bundles).
>
> This brings back the other common CMF topic: To maintain this, we should
> use subtree
> splits (maybe Sensio's perfect split system can help us here) and create
> a symfony-cmf/bundles
> (or the like) repository.
>
> 2015-12-18 17:45 GMT+01:00 David Buchmann <da...@liip.ch

> <mailto:da...@liip.ch>>:

>
> hi,
>
> some of you brought that topic up a couple of times and i was always
> against it. but lukas convinced me that we should start doing this as of
> 2.0 versions of the bundles. not everybody uses sonata, and its
> difficult to sync things with sonata admin so we would be better of
> separating them into separate bundles. i propose we do that when working
> on 2.0 versions, so for now that would be a CmfMenuSonataAdminBundle
>
> what do others think?
>
> david
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to symfony-cmf-de...@googlegroups.com

> <mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-de...@googlegroups.com

> <mailto:symfony-cmf-de...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Liip AG // Agile Web Development // T +41 43 500 39 80
CH-8005 Zurich // PGP 0xA581808B // www.liip.ch

[Lukas Kahwe Smith]

> On 19 Dec 2015, at 15:54, David Buchmann <da...@liip.ch> wrote:
>
> can't bundles now specify related bundles that should be instantiated
> automatically? i thought there was discussion about that.

still under discussion:
https://github.com/symfony/symfony/pull/15011

[Daniel Leech]

On Sat, Dec 19, 2015 at 03:52:55PM +0100, Lukas Kahwe Smith wrote:
>
> > On 19 Dec 2015, at 15:51, Daniel Leech <dan...@dantleech.com> wrote:
> >
> > We discussed this in March:
> >
> > https://github.com/symfony-cmf/symfony-cmf/issues/216
> >
> > I like the idea of having a single SonataAdminBundle.
>
> But how will this work out in practice when we have some Bundles getting minor updates, some major updates. Some working or even requiring newer versions of Symfony/Sonata, some requiring older versions?

Well the single bundle would, I think, simply *load* the DI config from
one of the components, so coupling could be kept to a minimumum (we just
couple to the bundle/compoennt class FQN.

The dependency constraints would be in the hands of the component (the
CmfSonataAdminBundle would just suggest the components).

{
"name": "symfony-cmf/sonata-admin-bundle",
"requires": {
"sonata-project/sonata": "xxx"
},
"suggests": {
"symfony-cmf/sonata-admin-routing",
"symfony-cmf/sonata-admin-menu",
"symfony-cmf/sonata-admin-content"
}
}

Just an idea..

> I think this new Bundle will end up being quite messy and/or limit the combinations
>
> regards,
> Lukas Kahwe Smith
> sm...@pooteeweet.org
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[gmx Privat]

But we still have our SonataPHPCRAdminBundle to maintain an keep in line with all the others, right?
It is really hard to decide on the one hand we will keep wach bundle decoupled in the use of an own Sonata version. But on the other hand, WE need to allign all of them in the Sonata Version to let them Play together. And it really feels like maintaining address Data in a separate Table as an OneToOne relation.

Max

[Maximilian Berghoff]

So as it is one of the goals for the following release: do we have a common mindset for that discussion? Or can we get one?

I am for putting all SonataAdmin stuff into one CmfAdminBundle. Doing that we will have one dependency line into Sonata in that bundle. In our bundles we can use different versions of CmfAdminBundle.

greets max

[Daniel Leech]

Hi,

- I think we should move all the Sonata-specific stuff into a SonataAdminBundle.

- I don't think "our" bundles should have dependencies on any admin
bundles (including any generic CmfAdminBundle).

I am planning to start a SyliusAdminBundle for 2.0.

I am hoping it will be very lightweight and maybe even non-existent if
it can be accomplished only via. documentation.

Not sure how much could / should be shared between that and any
CmfSyliusAdminBundle, but I would vote for just creating a dedicated
Sonata bundle and see how that works out.

Cheers,

Dan

> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [1]symfony-cmf-de...@googlegroups.com.
> For more options, visit [2]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:symfony-cmf-de...@googlegroups.com
> 2. https://groups.google.com/d/optout

[David Buchmann]

> - I think we should move all the Sonata-specific stuff into a SonataAdminBundle.

that is not possible. the SonataAdminBundle is generic admin things. the
SonataDoctrinePhpcrAdminBundle is the PHPCR-ODM binding.

the code we have for admin is definitions of admins, and admin
extensions, for example for routeable documents or documents that can
have menu items attached.

> - I don't think "our" bundles should have dependencies on any admin
> bundles (including any generic CmfAdminBundle).

i agree that the cmf routing/content/core whatever bundles should not
depend on CmfAdminBundle. but we can have a CmfAdminBundle (or rather
CmfSonataAdminBundle) that depends on the sonata admin and provides
those extensions and admins for all the bundles. meaning if you don't
use e.g. menu, you will have some unused admins and extensions in your
project, but that should be ok.

cheers,david

[Maximilian Berghoff]

Am Mittwoch, 8. Juni 2016 12:46:02 UTC+2 schrieb dantleech:

Hi,

- I think we should move all the Sonata-specific stuff into a SonataAdminBundle.

:+1:

 

- I don't think "our" bundles should have dependencies on any admin
  bundles (including any generic CmfAdminBundle).

You are right, i forgot that. What do we do with the sonata configuration stuff we have in each bundle? It's moslty some `use_sonata` flag what will be replaced by a direct `composer require symfony-cmf/sonata-admin`. I there something more?

What about the hierarchy stuff of the treebrowser/SonataDoctrinePhpcrAdminBundle?

 

I am planning to start a SyliusAdminBundle for 2.0.

nice and cool!!

 

I am hoping it will be very lightweight and maybe even non-existent if
it can be accomplished only via. documentation.

Not sure how much could / should be shared between that and any
CmfSyliusAdminBundle, but I would vote for just creating a dedicated
Sonata bundle and see how that works out.

Cheers,

Dan

On Wed, Jun 08, 2016 at 03:16:08AM -0700, Maximilian Berghoff wrote:
>    So as it is one of the goals for the following release: do we have a
>    common mindset for that discussion? Or can we get one?
>    I am for putting all SonataAdmin stuff into one CmfAdminBundle. Doing that
>    we will have one dependency line into Sonata in that bundle. In our
>    bundles we can use different versions of CmfAdminBundle.
>    greets max
>
>    --
>    You received this message because you are subscribed to the Google Groups
>    "symfony-cmf-devs" group.
>    To unsubscribe from this group and stop receiving emails from it, send an

>    email to [1]symfony-cmf-devs+unsub...@googlegroups.com.

>    For more options, visit [2]https://groups.google.com/d/optout.
>
> References
>
>    Visible links

>    1. mailto:symfony-cmf-devs+unsub...@googlegroups.com
>    2. https://groups.google.com/d/optout

[Wouter de Jong]

I think the CMF core bundles should provide form types for the documents they provide. An

admin panel is nothing more than many forms anyway.

These forms can then be very easily used to configure a sonata admin panel, a kunstmaan

admin panel, or anything a user ever wish to use. We can create a CmfSonataAdminBundle

that will just provide the sonata admin intergation (which will be not much more than setting the

form types provided by the core bundles).

We can always start creating some sort of custom CMFAdminBundle. I'm in fact working

on making an in-site admin bundle for the CMF, which should replace the CmfCreateBundle

with Neos/Next Drupal like admin features. But this is all in a very pre-alpha state and improving

the current bundle set is way higher on my list.

Removing the dependency on Sonata from the bundles would help a lot with development. It's

the only major vendor dependency we don't have control of in at least some way. This is slowing

done quite some things (although there activity is way better at the moment).

>    email to [1]symfony-cmf-de...@googlegroups.com.

>    For more options, visit [2]https://groups.google.com/d/optout.
>
> References
>
>    Visible links

>    1. mailto:symfony-cmf-de...@googlegroups.com
>    2. https://groups.google.com/d/optout

--
You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Maximilian Berghoff]

Hi @all,

i started to work on that theme by creating an CmfSonataAdminBundle at: https://github.com/ElectricMaxxx/sonata-admin-bundle . I wanted to directly move that bundle to the symfony-cmf organisation or simply create it there, but i have no admin rights there :-(

Base files are on  master. The first PR (except some bundle specific stuff) should show what would be moved when starting with the SeoBundle.Lokaly i still have removed that stuff. When That bundle lives in our organisation and i did the seo PR i will open a third one on the sandbox to see if it works.

greets max

[David Buchmann]

> I think the CMF core bundles should provide form types for the documents
> they provide. An
> admin panel is nothing more than many forms anyway.

true, forgot that we already discussed it like that. so lets create
forms where they are missing, and move sonata integration into the
combined cmf sonata admin bundle that max started.

regarding the naming, its currently CmfSonataAdminBundle and would be at
symfony-cmf/sonata-admin-bundle. i feel that is kind of non-obvious and
looks almost like we forked sonata admin bundle..

what about sonata-admin-integration-bundle and
CmfSonataAdminIntegrationBundle ? its longer, but its more clear what
this is about: it integrates the cmf with sonata admin.

[GMX - Maximilian Berghoff]

:+1: and it will open a naming schema like Cmf*AdminIntegration for
other ideas.

[Ben Glassman]

Is this similar to what Symfony refers to as a Bridge?

[Daniel Leech]

On Thu, Jun 09, 2016 at 04:14:48PM -0400, Ben Glassman wrote:
> Is this similar to what Symfony refers to as a Bridge?

CmfSonataAdminBridgeBundle sounds OK to me.

> On Thu, Jun 9, 2016 at 11:43 AM, GMX - Maximilian Berghoff
> <[1]maximilia...@gmx.de> wrote:
>
> Am 09.06.2016 um 17:17 schrieb David Buchmann:
> >> I think the CMF core bundles should provide form types for the
> documents
> >> they provide. An
> >> admin panel is nothing more than many forms anyway.
> > true, forgot that we already discussed it like that. so lets create
> > forms where they are missing, and move sonata integration into the
> > combined cmf sonata admin bundle that max started.
> >
> > regarding the naming, its currently CmfSonataAdminBundle and would be
> at
> > symfony-cmf/sonata-admin-bundle. i feel that is kind of non-obvious
> and
> > looks almost like we forked sonata admin bundle..
> >
> > what about sonata-admin-integration-bundle and
> > CmfSonataAdminIntegrationBundle ? its longer, but its more clear what
> > this is about: it integrates the cmf with sonata admin.
> :+1: and it will open a naming schema like Cmf*AdminIntegration for
> other ideas.
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [2]symfony-cmf-de...@googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [4]symfony-cmf-de...@googlegroups.com.
> For more options, visit [5]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:maximilia...@gmx.de
> 2. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 3. https://groups.google.com/d/optout
> 4. mailto:symfony-cmf-de...@googlegroups.com
> 5. https://groups.google.com/d/optout

[GMX - Maximilian Berghoff]

So we have 2 Suggestions:

1. CmfSonataAdminIntegrationBundle
2. CmfSonataAdminBridgebundle

what to take now, can i have a short vote of all?
I whant to change the name (incl. namespaces) before moving the budle to
the symfony-cmf organisation.

Other:
I have got a first working POC in the sandbox:
https://github.com/symfony-cmf/cmf-sandbox/pull/332
there i use a WIP PR on seo-bundle where removed the admin stuff and the
new bundle (currently live in my space).

greets Max

[David Buchmann]

> 1. CmfSonataAdminIntegrationBundle

+1

> 2. CmfSonataAdminBridgebundle

+0
(to me a bridge would be if it just integrates features from one library
into another library. what this thing does is provide admin classes to
edit cmf documents in sonata admins. that seems more than merely
bridging the two.)

[Maximilian Berghoff]

Hi,

i did it ...

I transfered the bundle from my repos to the symfony-cmf organisation. So lets say hello to https://github.com/symfony-cmf/sonata-admin-integration-bundle

Travis and packagist is working. I think (I hope) StyleCI to.

With the open Seo-PR the bundle works for SeoBundle. You should see all of the changes on the sandbox PR: https://github.com/symfony-cmf/cmf-sandbox/pull/332 (Todo for me: change repository there)

On the sandbox PR you can see an ideal triangle for the extraction: one PR on the related Bundle, One on the integration-bundle and the change on the sandbox. I think that way we will see it working and we will see possible parrallel work.

So the routing-bundle is my next item, both PR's still exsists and i still need to create the form types on routing-bundle.

greets max