Closed gyalamanchi closed 10 years ago
lsmith77
commented
10 years ago The relevant code is here: https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/blob/master/Tree/PhpcrOdmTree.php#L262
And yes .. its all unfortunately a bit iffy and we are not at all happy with the solution we currently offer. see also https://github.com/symfony-cmf/TreeBrowserBundle/pull/38
dbu
commented
10 years ago hi @gyalamanchi
i think the issue is that you also need to declare rows for the types of blocks that you want to appear in the tree. if you just add them as valid children, this is only used in the context menu when you right click on a tree node. to have them show up themselves in the tree, you need to put entries like
sonata_doctrine_phpcr_admin:
document_tree:
Symfony\Cmf\Bundle\BlockBundle\Doctrine\Phpcr\ReferenceBlock: ~but you where close to the solution: they do have to be mapped, and they do have to be in the list of valid_children to be able to display.
if i guessed correctly, i would be happy for suggestions where in the doc we could explain that better as i have to admit its not too obvious how this works.
gyalamanchi
commented
10 years ago I am guessing this below is that mapping:
Symfony/Cmf/Bundle/ContentBundle/Resources/config/doctrine-model/StaticContent.phpcr.xml: child name="additionalInfoBlock"
So they have to be both mapped and in the list of valid_children to be able to display. This really makes it tough for the existing tree to be entirely dynamic in that regard.
I have tried adding also children using code similar to the ContainerBlock and adding that as mapped
dbu
commented
10 years ago the ModelManager would be a piece of sonata admin? why would that come into play here, did you also add it to a form?
if you do a field $children and have getChildren the tree should be fine.
for the dev usability of all this: there was discussion of having a mode that shows all children regardles of whether they are mapped or not. but there is also a discussion about using a different js library and refactoring everything, but neither happened yet and i am not aware of anybody currently working on it. i hope it eventually will happen.
dantleech
commented
10 years ago I made a big start on the TreeUiBundle, but I became lost in complexity..
Potentially having a bundle which could act equally as a frontend filesystem, media, PHPCR or ODM browser through MacOSX sliding interface, ElFinder or JsTree frontends -- this is mainly why I came up with the concept of the satelite packages (one package per frontend/backend for the core - enabling each to have its own release cycles - decoupling maintenance etc.)
There is also still the whole issue of packaging javascript in a nice way - I was using the rob loach installer for this bundle.
It also supported Annotations (and, with drivers, XML and YAML)for mapping node meta data - I believe the mapping was open by default so all nodes are displayed.
Another thing was that if PHPCR-ODM allowed mapping node type metadata we could infer the tree structure from that (which nodes are allowed under which nodes) - as it is you would make a whole load of TreeUi mappings with annotations, but this information applies equally to contexts which are not TreeUi - e.g. the SonataAdmin interface. I think this information belongs primarily to PHPCR-ODM where it would be mapped to PHPCR node types, providing some base structural integrity.
But maybe I could reduce the scope and roll out a PHPCR and JS LibraryX implementation with annotation mappings. I just wish I had more time ...
On Thu, Jan 16, 2014 at 06:32:38AM -0800, David Buchmann wrote:
the ModelManager would be a piece of sonata admin? why would that come into play here, did you also add it to a form?
if you do a field $children and have getChildren the tree should be fine.
for the dev usability of all this: there was discussion of having a mode that shows all children regardles of whether they are mapped or not. but there is also a discussion about using a different js library and refactoring everything, but neither happened yet and i am not aware of anybody currently working on it. i hope it eventually will happen.
— Reply to this email directly or [1]view it on GitHub.
References
Visible links
gyalamanchi
commented
10 years ago I did find a workable solution without modifying the PhpCrOdmTree (except to show longer labels--yet entirely another discussion).
To get all child blocks to work, I modified StaticContent as dbu suggested. StaticContent.phpcr.xml:
I replaced this child...
<child name="additionalInfoBlock">
<cascade><cascade-persist /></cascade>
</child>
With this element....
<children name="children">
<cascade>
<cascade-all/>
</cascade>
</children>
Then in StaticContent, I added /* * @var ChildrenCollection / protected $children;
Using the implementation from the ContainerBlock class.
Now to allow for Static Content to be nested inside other nested content to appear in the tree... Symfony\Cmf\Bundle\ContentBundle\Doctrine\Phpcr\StaticContent: valid_children:
Finally resulting in my desired results....
So this approach worked for me, if anybody has a better suggestion I would appreciate it.
I would like to know how to make the /cms/media/ children appear as well.
dbu
commented
10 years ago Symfony\Cmf\Bundle\ContentBundle\Doctrine\Phpcr\StaticContent:
valid_children:
- allshould work too. otherwise this is how things work atm. i would however be ok to merge a PR that enables a config option and the implementation in the tree to make the tree alternatively use DocumentManager::getChildren to not rely on mappings. we could also have an option to not filter the children by valid - but that has some major drawbacks as it also controls where you can add what, so i think its not a good idea.
dbu
commented
10 years ago regarding /cms/media: did you create any content there? if so, did you declare the types of that content in your tree config?
dbu
commented
10 years ago regarding the tree labels, this is fixed in the current master with https://github.com/symfony-cmf/TreeBrowserBundle/pull/55 but there is no stable release of that yet.
gyalamanchi
commented
10 years ago dbu, thanks regarding the Media items. I did get them to appear by adding.. those configs in the tree:
Symfony\Cmf\Bundle\MediaBundle\Doctrine\Phpcr\Directory:
valid_children:
- all
Symfony\Cmf\Bundle\MediaBundle\Doctrine\Phpcr\File:
valid_children:
- all
Symfony\Cmf\Bundle\MediaBundle\Doctrine\Phpcr\Image:
valid_children:
- all
Symfony\Cmf\Bundle\MediaBundle\Doctrine\Phpcr\Media:
valid_children:
- all
Do you know how I would allow on the admin side to just click on image and see it? Or to be able to add an image to Directory. I know I can do it thru the front end tool and createjs, which opens a helper popup to upload images. To do this on the admin side would be great.
BTW, thanks for making the CMF and your help so far.
dbu
commented
10 years ago great!
about an admin, this is currently missing. see https://github.com/symfony-cmf/MediaBundle/issues/61 and https://github.com/symfony-cmf/MediaBundle/issues/80 - we either could build one, or better build integration with SonataMediaBundle to get a lot of additional features when needed.
thanks for the praise, glad to hear you like the cmf :-) as you noticed, we still have rough edges but we are working on it. and we rely on user contributions to the doc and the code to make things less painful or more powerful each time somebody runs into problems...
gyalamanchi
commented
10 years ago Yes, I see one would have to have a MediaBundle admin on the Sonata side. I made a small workaround for this by just creating custom block in the sonata admin and just adding a link to the elfinder route. I think I now have an end-to-end solution for really building a strong multisite CMS.
For the very custom solution I needed, CMF was the answer for me. My content pages aren't really heavily driven content pages but just phpcr content objects where I can attach child content to and pass on to a specific Controller action. I even have forms and validations in the actions I forward the content Document into. I cant imagine how I could have done all this with Drupal 8 based on where it is at the moment but i did evaluate that product-- but my site is not about menus, and blogs, and posts... it is about a business logic driven site where I need to overlay content into the regular application logic of customers entering data, making purchases. Anyways, I don't mean to sound so opinionated but for my purpose the CMF was the means and the ends.
Thanks again.
dbu
commented
10 years ago you are welcome, glad if things work for you. let us know if you blog about it or if you have any code contributions you would like to do or such things :-) don't apologize, i have nothing against being opinionated that the cmf is useful for you :-) its exactly what we built it for, being flexible for the non-standard content use cases.
ok if we close this issue?
gyalamanchi
commented
10 years ago Yes that is fine
Richtermeister
commented
10 years ago @dbu Sorry to resurrect this issue, but I came across it with the same problem.. Children of StaticContent nodes do not appear in the Tree. Looking at the code I understand that this is because there is no children mapping on that node.. why is that?
dbu
commented
10 years ago the reason is that we usually not need them. we had the argument with @lsmith77 before - i am more open to map a lot of things in those documents, but he is afraid of the overhead we introduce for people not needing something.
it is very simple to just extend StaticContent in your project and add a field with a children mapping (and configure ContentBundle to use your document class). if you want to contribute a general solution, i would favor an idea we discussed but never did (just created an issue so there is a proper place to discuss): https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/issues/265
Does anybody know how I can make all child blocks show up on the CMF Tree in the Sonata Admin for the StaticContent class? The way our system uses the Symfony\Cmf\Bundle\ContentBundle\Doctrine\Phpcr\StaticContent class is to just use it as a content document that we can attach other blocks to. I thought that was the purpose of the ContentBundle. Instead only blocks inside of this additionalInfoBlock container block appear in the tree. Unless I am doing something wrong.
I have looked at Symfony/Cmf/Bundle/ContentBundle/Resources/config/doctrine-model/StaticContent.phpcr.xml:
There has to be way to get all the child blocks show. I just dont want to start hacking the PHPCRTree class to do this. Do I extend StaticContent and hopefully it will show all children? How do I go about this if that is the answer. Or is there another setting.
See this image below of what I can see in jackrabbitexplorer vs what is in the CMF Tree in the Sonata admin
I have tried from other posts changing the configuration settings:
I first tried....
sonata_doctrine_phpcr_admin: document_tree_defaults: [locale] document_tree: Doctrine\ODM\PHPCR\Document\Generic: valid_children:
No luck so I tried....
sonata_doctrine_phpcr_admin: document_tree_defaults: [locale] document_tree: Doctrine\ODM\PHPCR\Document\Generic: valid_children:
Also, no luck.
I think it has to do with StaticContent or the json being returned as children which are just those additionalInfoBlock but not all children of StaticContent.