Entity CRUD generic UI

Can't entity API can leverage CTools, with it's export-UI?

The entity API defines its own (ctools compatible?) exportables - as it makes more sense to me to export on the entity level instead of the database table schema level. So you get a CRUD api (=entities) + optionally ctools exportables taken to the entity level. Thus exportables are integrated in the entity controller, what means entity_load() returns defaults from code too.

Also for the UI I think building upon entities makes sense, as we have stuff like entity labels and uris we won't have for ctools exportables - so using the ctools export-UI wouldn't fly here. Anyway I don't like introducing a ctools dependency for the entity API either - as it is usually already the dependency itself. Additionally I've not seen any usable d7 ctools code we could build upon now... ;)

We had a short look at the export UI code but as someone that hasn't worked much with the ctools stuff the code flow is hard to follow. Of course we'd very much appreciate your insights/input :)

@fago,
I think that, as we talked in Copnehagen, currently entity-API and CTools are having some stuff in common, and it would be best to join forces.

Since we are dealing here with the UI, and not the API itself, I think it would be ok to have a dependency in CTools.

> as we have stuff like entity labels and uris we won't have for ctools exportables - so using the ctools export-UI wouldn't fly here

I'm not very clear about what exactly is needed, but I guess that if we take the CTools path we can work it out. Since I'm familiar with the export-UI I can say it is very extendable (and I'd be of course happy to proivde guidance if needed).

> as we have stuff like entity labels and uris we won't have for ctools exportables - so using the ctools export-UI wouldn't fly here

Yikes! ;) AFAIK, there was a code sprint to port CTools and sdboyer should work on it from the 27th SEP.

> We had a short look at the export UI code but as someone that hasn't worked much with the ctools stuff the code flow is hard to follow

Check out the Message module (Dev version) to see a "simple" imlementation of the plugin, and mini-panels for a more complicated one. From a quick look at the patch it looks very similar to exort-ui (only more hardcoded to the "entity").

>Since we are dealing here with the UI, and not the API itself, I think it would be ok to have a dependency in CTools.
Not ideal either, but I think we could live with that.

>I'm not very clear about what exactly is needed, but I guess that if we take the CTools path we can work it out. Since I'm familiar with the export-UI I can say it is very extendable (and I'd be of course happy to proivde guidance if needed).

Sounds good. We'd definitely subclass it + provide entity based defaults for access. Not sure how we could bake entity_uri() + entity_label() in, so we could need your help there.

> We had a short look at the export UI code but as someone that hasn't worked much with the ctools stuff the code flow is hard to follow
Thanks. I looked at message, now I also looked at mini-panels. That helped a bit :) Still I'm a bit worried about the complexity of wizards and all that stuff that is built in. Is that all optional? I don't really like people having to learn new APIs just to make some small adaptions to the generated API.

>Yikes! ;) AFAIK, there was a code sprint to port CTools and sdboyer should work on it from the 27th SEP.
Sounds good too. klausi said he postpones working on this for a week, so let's see where ctools is then.

> provide entity based defaults for access

There is a possibility in export-UI to set access for each menu item .

> Not sure how we could bake entity_uri() + entity_label() in ...

you mean that in the exported code you would like to see something like

$export->label = 'foo'

where foo is the outcome of entity_label()?

> Still I'm a bit worried about the complexity of wizards and all that stuff that is built in. Is that all optional?

Yes, the wizard is optional. As you've seen in message module, one can implement a plugin with very few lines of code.

>There is a possibility in export-UI to set access for each menu item .
hm, I cannot override what the system returns to hook_menu ?

@label:
No, we have entity_export() for generating the export already. I'd utilize label + uri to generate labels in the listings + to optionally link to the entity.

subscribe

Subscribe. Would be great to use this in the upcoming Party module.

How much of the UI does this provide -- does it give you the equivalent of /admin/content/node, for example?

@klausi,

> ctools wants the wizard stuff and extensive support for all kind of features. entity wants just a simple, clean, generic, basic, D7 powered UI for the most wanted operations.

I agree that CTools uses more code, like for the Wizard stuff, but a lot of it's code is to make it flexible. The strings for example are not hard coded (e.g. "Are you sure you want to revert..."), so an implementing module can override the strings/ operations/ top header etc'.
With power comes code ;)

My biggest concern isn't actually export-ui vs entity-ui, but the fact that we have two parallel "exportable" systems, each with it's own goodies - that don't connect. In fact I think it will be pretty easy (and less code) to turn your current patch into a CTools export-ui plugin. Of course we have to wait for CTools7....

IMO, the real work - and fago already started it #681362: d7: Support exportable entities - is to allow CTools interact with entities.

Anyway -- I'm starting to have a look at the patch - I wasn't able to see it in work. Apart of enabling Rules module do I need to do anything else?

From a quick look at the patch the only major issue that needs to be fixed, is that a token needs to be added to the revert/delete links to prevent CSRF.

>IMO, the real work - and fago already started it #681362: d7: Support exportable entities - is to allow CTools interact with entities.
Agreed. However, the work has been already done, exportable entities are there (here ;). Whether people wanna pick it up is another story.

>From a quick look at the patch the only major issue that needs to be fixed, is that a token needs to be added to the revert/delete links to prevent CSRF.
I think those a confirm_forms()? thus CSRF attacks would fail.. :)

I worked today on that. The results seem to work already pretty good, so I've gone ahead and merged the UI branch. I also updated the wsclient ui. I'll work on profile2 using this tomorrow.

Let's do follow-up issues for the remaining stuff.

Ugh. This should have been a separate entity_ui sub-module.

>Ugh. This should have been a separate entity_ui sub-module.
Why?

Is this in now? I looked at Entity module last weekend and couldn't see anything about this. How does it work?

Thanks!

Admittedly I have a cold so may be doing something stupid, but I can't get this to work. From what I can tell, 'path' is the minimum I need, but this isn't adding anything to {menu_router}:

      'admin ui' => array(
        'path' => 'admin/content/party',
      ),

Huh. Now it works; I just cleared my cache a few extra times.

Though I'm getting an 'access denied' on the new page -- surely that should be impossible if I'd uid 1?

@joachim: On #24, see #981990: Fall back for entities that don't explicitly define an access callback