nested set for admin bundle

[matteosister]

Hi everybody...

I'm thinking about a support for nested sets in admin bundle. I need
this for an upcoming project...and maybe I could help...

First and must important question:
- are there any implementations already done, or in the making, that I
could join?

Some personal thoughts:
- should obviously rely on Tree behavior and the
StofDoctrineExtensionsBundle
- I think that the way to go is creating a new Admin abstract base
class that extends the main admin class to implement the different
logic. So you can easily switch from a "normal" admin interface and a
nested set one by extending a different base class.
- Edit and creation should be the same. the differences comes in the
list view. For example...no pagination or filter is needed.
- I would like to use the jsTree library. I've already use it for
symfony1, and it's really really great. http://www.jstree.com/
- I think that the work should be done in the sub-bundles
"DoctrineORMAdminBundle" and "DoctrineMongoDBAdminBundle" because the
tree implementation of the orm is redically different in mongodb, and
by now doctrine extensions doesn't support (officially) the odm.

Regards,
Matteo.

[Thomas Rabaix]

On Mon, Dec 5, 2011 at 11:58 AM, matteosister <mat...@gmail.com> wrote:

Hi everybody...

I'm thinking about a support for nested sets in admin bundle. I need
this for an upcoming project...and maybe I could help...

First and must important question:
- are there any implementations already done, or in the making, that I
could join?

No implementation so far. I think the CMF project wants to do something for the PHPCR implementation.
 

Some personal thoughts:
- should obviously rely on Tree behavior and the
StofDoctrineExtensionsBundle
- I think that the way to go is creating a new Admin abstract base
class that extends the main admin class to implement the different
logic. So you can easily switch from a "normal" admin interface and a
nested set one by extending a different base class.

I don't see why you want to create a new Admin class. Can you elaborate a bit more about what you want to achieve ? The first step will be to add a dedicated Form Type.
 

- Edit and creation should be the same. the differences comes in the
list view. For example...no pagination or filter is needed.
- I would like to use the jsTree library. I've already use it for
symfony1, and it's really really great. http://www.jstree.com/
- I think that the work should be done in the sub-bundles
"DoctrineORMAdminBundle" and "DoctrineMongoDBAdminBundle" because the
tree implementation of the orm is redically different in mongodb, and
by now doctrine extensions doesn't support (officially) the odm.

 

Regards,
Matteo.


--
You received this message because you are subscribed to the Google Groups "sonata-devs" group.
To post to this group, send email to sonat...@googlegroups.com.
To unsubscribe from this group, send email to sonata-devs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sonata-devs?hl=en.

--
Thomas Rabaix
http://rabaix.net

[matteosister]

I'm studying the SonataAdminBundle code...I'm just at the
beginning...but I have some time in the next days...
What I want to achieve is to have a list that is a treeview instead of
a list view. With nodes that could be opened/closed, moved around and
deleted. All the "normal" actions like edit/delete should link to the
normal admin interface (with nested set fields like left, right and
level hidden). I want to change the behavior of the "list" part by
overriding the normal behavior of AdminBundle.
The FormType is useful to display this list inside the form, for
example for choosing the parent of a node...but this could be done
later...when I'll have a working implementation of a jsTree based on a
doctrine orm nested set. This is why I'm starting to understand how
AdminBundle handle the list view. How to tell a normal entity and a
nested set one. How to override filters/pagination etc.
Maybe a dedicated NestedSetAdmin class (inside the
DoctrineORMAdminBunlde) that extends the main Admin class (in
SonataAdminBundle) could be great to separate concerns, and to place
the code in the DoctrineORMAdminBundle where it should live. But it's
just an idea.

Anyway the main thing was to know if there was some ongoing projects
to achieve this. I will do my homeworks to understand how adminbundle
works (by the way it's really great) and try to find the correct way
to make it work.

On 5 Dic, 12:12, Thomas Rabaix <tho...@rabaix.net> wrote:

> On Mon, Dec 5, 2011 at 11:58 AM, matteosister <matt...@gmail.com> wrote:
> > Hi everybody...
>
> > I'm thinking about a support for nested sets in admin bundle. I need
> > this for an upcoming project...and maybe I could help...
>
> > First and must important question:
> > - are there any implementations already done, or in the making, that I
> > could join?
>
> No implementation so far. I think the CMF project wants to do something for
> the PHPCR implementation.
>
>
>
> > Some personal thoughts:
> > - should obviously rely on Tree behavior and the
> > StofDoctrineExtensionsBundle
> > - I think that the way to go is creating a new Admin abstract base
> > class that extends the main admin class to implement the different
> > logic. So you can easily switch from a "normal" admin interface and a
> > nested set one by extending a different base class.
>
> I don't see why you want to create a new Admin class. Can you elaborate a
> bit more about what you want to achieve ? The first step will be to add a
> dedicated Form Type.
>
>
>
>
>
>
>
>
>
> > - Edit and creation should be the same. the differences comes in the
> > list view. For example...no pagination or filter is needed.
> > - I would like to use the jsTree library. I've already use it for

> > symfony1, and it's really really great.http://www.jstree.com/

[Lukas Kahwe Smith]

Hi,

for the CMF we are in the early stages:

https://github.com/symfony-cmf/TreeBundle

We are now working on integrating this with SonataAdminBundle:

http://screencast.com/t/w7wqTm7yJgBJ

But its still a work in progress.

Of course this uses PHPCR, which is a "NoSQL database" with native tree support, but the interface provided by TreeBundle could be implemented by anyone. It might in the end make the most sense to move this interface into some library.

regards,

Lukas

[Thomas Rabaix]

Yes, having a common interface will help to provide the same set of features between different implementations ;)

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/sonata-devs/-/mI7sTLE4zcsJ.

To post to this group, send email to sonat...@googlegroups.com.
To unsubscribe from this group, send email to sonata-devs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sonata-devs?hl=en.

[matteosister]

This is great...but...inside the TreeBundle there isn't an interface
right now...only a bunch of js/css/images files...
maybe it's inside a non-public branch?
Anyway I love the idea to use only unobstrusive js implementation
without touching the code. But how do you deal with filters (in a
treeview doesn't make much sense) and pagination (you always need the
full list)?

As a side note I think that this jquery plugin is far more better then
the one used in the bundle:
https://github.com/vakata/jstree

[Lukas Kahwe Smith]

On Dec 5, 2011, at 13:34 , matteosister wrote:

> This is great...but...inside the TreeBundle there isn't an interface
> right now...only a bunch of js/css/images files...
> maybe it's inside a non-public branch?
> Anyway I love the idea to use only unobstrusive js implementation
> without touching the code. But how do you deal with filters (in a
> treeview doesn't make much sense) and pagination (you always need the
> full list)?

Oh sorry. We moved it in the end:
https://github.com/symfony-cmf/symfony-cmf/blob/master/src/Symfony/Cmf/Bundle/PHPCRBrowserBundle/Tree/TreeInterface.php

But this is certainly not the right place for this interface if we want to enable different database backends to use it. Or maybe we can in the end make the browser Bundle more generic.

> As a side note I think that this jquery plugin is far more better then
> the one used in the bundle:
> https://github.com/vakata/jstree

ok noted. i have opened a ticket on the Bundle to evaluate your suggestion:
https://github.com/symfony-cmf/TreeBundle/issues/1

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

[Nacho Martín]

On Mon, Dec 5, 2011 at 1:34 PM, matteosister <mat...@gmail.com> wrote:
> This is great...but...inside the TreeBundle there isn't an interface
> right now...only a bunch of js/css/images files...
> maybe it's inside a non-public branch?
> Anyway I love the idea to use only unobstrusive js implementation
> without touching the code. But how do you deal with filters (in a
> treeview doesn't make much sense) and pagination (you always need the
> full list)?

This would be one of the main features in the PHPCR Admin Bundle.
Right now what is implemented is only the possibility of a js tree
embedded in the list view but without interaction with the Admin
Bundle. We are working on this...

Also we would want to be able to add new fields in a node, which is
something PHPCR allows, but not using PHPCR-ODM, so we can go
different ways:

* Implementing a phpcr-myadmin (like phpmyadmin for mysql) outside
Sonata Admin Bundle, without using the ODM to deal with the specific
features of phpcr.
* Implement that phpcrmyadmin into SAB, but not using the ODM in this part.
* Implement some tree view into SAB, using the ODM, losing some features.

Ideally we would love to have it integrated into the Admin Bundle so
we don't reinvent the wheel for every AB implementation. Then, if we
could agree about the features and interfaces to implement it would be
great.

Nacho

[Lukas Kahwe Smith]

right so in the end it might make sense to move the tree interface into SonataAdminBundle. then again the tree interface is something one might also want to use in the frontend. another option could be to move it into the DoctrineExtensions. of course we could also just have a separate repo for just the interface but this is also painful ..

just blogged about this very problem:
http://pooteeweet.org/blog/2056

[Alain Horner]

I'd suggest the following architecture:

TreeBundle:

On Dec 5, 3:42 pm, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
> On Dec 5, 2011, at 15:17 , Nacho Martín wrote:
>
>
>
>
>
>
>
>
>
> > On Mon, Dec 5, 2011 at 1:34 PM, matteosister <matt...@gmail.com> wrote:
> >> This is great...but...inside the TreeBundle there isn't an interface
> >> right now...only a bunch of js/css/images files...
> >> maybe it's inside a non-public branch?
> >> Anyway I love the idea to use only unobstrusive js implementation
> >> without touching the code. But how do you deal with filters (in a
> >> treeview doesn't make much sense) and pagination (you always need the
> >> full list)?
>
> > This would be one of the main features in the PHPCR Admin Bundle.
> > Right now what is implemented is only the possibility of a jstree
> > embedded in the list view but without interaction with the Admin
> > Bundle. We are working on this...
>
> > Also we would want to be able to add new fields in a node, which is
> > something PHPCR allows, but not using PHPCR-ODM, so we can go
> > different ways:
>
> > * Implementing a phpcr-myadmin (like phpmyadmin for mysql)  outside
> > Sonata Admin Bundle, without using the ODM to deal with the specific
> > features of phpcr.
> > * Implement that phpcrmyadmin into SAB, but not using the ODM in this part.

> > * Implement sometreeview into SAB, using the ODM, losing some features.

>
> > Ideally we would love to have it integrated into the Admin Bundle so
> > we don't reinvent the wheel for every AB implementation. Then, if we
> > could agree about the features and interfaces to implement it would be
> > great.
>

> right so in the end it might make sense to move thetreeinterface into SonataAdminBundle. then again thetreeinterface is something one might also want to use in the frontend. another option could be to move it into the DoctrineExtensions. of course we could also just have a separate repo for just the interface but this is also painful ..

[Alain Horner]

I'd suggest the following architecture:

TreeBundle:

- JS-Stuff for displaying a tree
- TreeInterface
- DoctrinePHPCRTree which implements TreeInterface

DoctrinePHPCRAdminBundle:
- uses DoctrinePHPCRTree
- uses the JS-Stuff from TreeBundle

PHPCRMyAdmin:
- uses DoctrinePHPCRTree

DoctrineORMAdminBundle:
- DoctrineORMTree implements TreeInterface (this could also be
directly in the TreeBundle for consistency)
- uses the JS-Stuff from TreeBundle


Btw I also prefer jsTree over jQueryTreeView. It's well documented and
has many more features (that will also be needed for the AdminBundle),
e.g. distinguishing between leaf and node, renaming a leaf/node, ...

[jakuza]

Hello,

I had already considered http://www.jstree.com/ (aka https://github.com/vakata/jstree) when I started developing the wrapper TreeBundle. At that time overfeaturing was not the main aim, we just needed a proof of concept trying to attract developers in. I'll mostly check whether this library can batter support new tree features we are discussing about.

BTW one way or another, I am willing to further develop the TreeBundle, the PHPCRBrowserBundle, their abstraction and their integration with SAB.

Matteo,

sei italiano, ci vogliamo sentire su Skype?

Nacho,

I need to discuss some SAB details with you to better understand how to serve those bundles.

Ciao!

[matteosister]

volentieri! cerca matteosister su skype!

On 22 Dic, 11:10, jakuza <jro...@gmail.com> wrote:
> Hello,
>
> I had already consideredhttp://www.jstree.com/(akahttps://github.com/vakata/jstree) when I started developing the wrapper

[Nacho Martín]

Nice! I agree, but I think:

- TreeInterface for PHPCR I think would be more flexible if is done
outside Doctrine, so you can add more properties to nodes even if they
are not in the document. At least for the phpcrmyadmin part.
I think the Tree interface could be a place where you specify the
routes for the functionalities: fetch childrens of a node, fetch node
properties, add a node, add property, move node,... and then the js
uses them. If a route is not specified, then you don't have that
functionality (e.g. "add property" makes sense in PHPCR, but not with
other infraestructures).

[David Buchmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

> - TreeInterface for PHPCR I think would be more flexible if is done
> outside Doctrine, so you can add more properties to nodes even if they
> are not in the document. At least for the phpcrmyadmin part.

with the tree interface in TreeBundle, this is how it would happen.
even though for most use cases involving doctrine, adding properties
that are not part of the document makes no sense :-)

but i am pretty sure there are use cases outside doctrine.

> I think the Tree interface could be a place where you specify the
> routes for the functionalities: fetch childrens of a node, fetch node
> properties, add a node, add property, move node,... and then the js
> uses them. If a route is not specified, then you don't have that
> functionality (e.g. "add property" makes sense in PHPCR, but not with
> other infraestructures).

we miss one piece of the puzzle here: the tree controller. the routes
are part of that controller. i think the js tree and the controller are
pretty much generic. the tree interface defines how the controller can
talk with storage. and there we probably need implementations for phpcr
and for phpcr-odm, as well as the other odms and orms.

i wonder if the concept of nodes and properties is not too specific?

maybe we should switch to a concept of getting the children and getting
the edit *form*. then the TreeInterface would know how to build a form
and the controller would just forward to TreeInterface again.

and just something that comes to my mind: when talking about adding
things, we get close to what the VIE / create.js frontend editing does
with the help of backbone.js. if we add backbone.js here, the whole
communication with the backend becomes different again...
but maybe we should just ignore that for now to not overcomplicate things.

cheers,
david

- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk74S3QACgkQqBnXnqWBgIvgAgCfT79fW5nQl98ctre1ilim7zmK
i5QAoLUxBikCbNlbgJh1TSw/bi9ZmRXc
=ZjNX
-----END PGP SIGNATURE-----

[Jacopo Romei]

David,
I already have some code done and I agree with your view. Haven't
pushed that yet because my sandbox doesn't work again after last pull
and I want to see it running before pushing crap code.

I'll ask tomorrow on IRC for some tip.

As a side note: how much do you like couchdb's Futon UI? Its way to
add fields on-the-fly is interesting and plain, don't you think?

--
Jacopo Romei
http://www.sviluppoagile.it/

Inviato da dispositivo mobile.
Sent from mobile device.

[Rob Masters]

Hi, I've just started using the SonataAdminBundle for a new project and have a need to use nested sets...have there been any updates for this in the last few months? It seems a lot of considerations have been flying about here so I'm a little wary to go ahead and make my own implementation. I'd intend to share it with the community, so would like it done right.

I'm using the StofDoctineExtension to mark a "Sections" entity as a nested tree. These sections will need a clean UI to be managed (appending/deleting/re-ordering) and I'll also need a form type to be able to select section(s) for a Story entity, which has a ManyToMany relationship to sectons. The list view for sections should also be a tree rather than a data grid. Is there anything out there that is ready to be used now, or should I work on this myself? Any pointers would be very much appreciated as I'm new to this admin bundle. Thanks.

[Lionel]

Hello,

What's new between SonataAdminBundle and nested set related works? What's the "right" / "common" way to implement this feature?

Regards,
Lionel