Posted by indytechcook on May 17, 2011 at 12:07pm
5 followers
| Project: | Bean |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | fabsor |
| Status: | closed (fixed) |
Issue Summary
Make Bean Exportable by using ctools export UI
Comments
#1
This has to be next up on my list... Need to get my bean types into my features :)
subs. +1
#2
I don't know much about Entity, ctools, or exportables, but it seems like both provide the same or similar things. You seem to be using a mixture of Entity and Ctools. Why do you think the exports should be done with ctools as over Entity?
#3
Ok, here is my first attempt. It almost works, but...
You'll notice that I'm moved the bean_types table to from the bean_admin_ui module to the main bean module. I think this makes a lot more sense as there should be no need to have the admin_ui enabled or even installed to work with beans.
NOTE: Basically, I just used the example code from entity_test.module as a guide.
#4
Whilst I think of it... What exactly are we getting out of ctools? Entity is providing the Exports, and it seems like entity can do everything that we are using Cools for. I think the thing it gives us is plugin support, but how do you envisage this to be used? Is it needed?
#5
Thanks mrfelton,
The plugin type system is the core of the module. Building the types in the UI is an addition to the core API. The types will be exportable using ctools export and not entity since the types are not entities themselves, nor will they ever become entities.
The real power of this module lies in the plugin system. You can deploy new block types without features, just add a new bean_type plugin. There is an example in the readme. I know there is still alot to workout with this module as well as more documentation and examples.
#6
The admin ui module gives the ability to add bean_types (not beans) view the UI. This will remain separate.
#7
I don't understand the logic behind this. Would would the types never become entities? What is the problem with using entities to provide the exports?
I know that you can deploy beans them without features by adding a plugin, but we would far prefer to use features, so that working with beans follows the same methodology as working with content types. I don't see a huge difference in the concepts. You can have multiple types of each, which are fieldable and exportable.
#8
Shouldn't beans have the ability to have multiple types without the admin_ui?
I think I am missing something about this module concept-wise!
#9
I did module this module after nodes/content types. Content types are not entities. They are bundles of entities. The type level is configuration and not content. Entities should only be content. The features module exposes the content types to be exportable.
Making the types exportable is a matter of adding a few lines of code to the schema definition. I want these to be exportable, but exportable in the right way.
I know the entity module promotes making types into entities but I am fundamentally against making bundle types of any sort into entities themselves. It pollutes the entity type space.
#10
The module is designed API first. The API works perfectly without any interaction from the front end for configuration.
The bean_admin module is an implementation of the API that exposes new bean types to the front it by dynamically adding new bean_types from a table.
The separation of API from implementation is very important, especially in larger, more customized projects.
#11
Ok, that makes perfect sense. I read a few threads, and looked several other modules that seemed to be doing a similar thing and they were al using Entitles to provide the exports. So I read the docs and it sounded pretty simple and just went for it. Would be awesome if you could get it done with ctools though.
#12
mrfelton, I hope I didn't sound mean, I just feel strong about this topic.
We might use the entity module to make the beans exportable themselves.
If you don't want to wait on me (which i totally understand), check out http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-y... and http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-c... for some good information on how to make a table into an exportable.
#13
I didn't get on too well with CTools :( I decided to have a go using the features API, similar to how the Drupal Commerce guys are doing it with Commerce features
http://drupal.org/sandbox/mrfelton/1169160
Seems to work pretty well. Only problem I have is switching out the Delete links with Revert onces for bundles that came from code.
#14
Here is my first attempt at this. This patch uses the CTools Export API to export bean types to code. This makes it very easy to implement exportables, and we don't have to worry about maintaining our own features implementation.
Some notes:
* CTools needs a serial identifier as a primary key, so I had to add one.
* If you have a column name called 'type', CTools, will overwrite it with it's own data so I change the name of the machine name column to 'name'.
* I tried to use the CTools Export UI at first, but it turns out it is very hard to use it in this particular case, since we want to have fields on top of our content, and it is really hard to get that working inside Export UI.
@indytechcook Do we need to be backwards-compatible here? In that case we need to write an update hook for this.
#15
Setting status
#16
I'm also changing the title, since this is about exporting the bundles, not the beans. If I missed the point completely, please feel free to change it back =)
#17
Nah, you're right. Nice work. I'm gonna give this a try in a minute.
#18
@fabsor, I would say that since we have had an alpha out for some time, this will need an update hook. Certainly, I need one so that I can run this on some of the sites that I'm using Bean on.
I have added an update hook to the patch, however I've been unable to run it as I get the following error when visiting update.php or using updatedb with drush:
Fatal error: Call to a member function getLabel() on a non-object in /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/bean.module on line 37
I'm guessing this is because the code has been changed to use the new database structure, which won't actually be available until the database update has run. Bit of a catch 22. Not sure how to get around this.
#19
Here is a patch with a working update hook. However, even after running the update I'm getting WSOD.
Call to a member function values() on a non-object in /Users/tom/workspace/alumni/profiles/alumni/modules/contrib/bean/includes/bean.core.inc on line 54
For some reason, ctools_plugin_load_class() isn't returning anything on line 278 of bean.module which means that the bean type class doesn't get loaded and set in $bean->setPlugin() line 343 of bean.module.
#20
OK. Patch updated with fully working update hook.
However, there are a couple of problems with the export functionality:
1) Fields not included - If you crate a Bean Type and add a couple of fields to it, then create a feature and add your Bean Type to it, the resulting feature module contains only the code to recreate the Bean Type, and does not add any of the fields
2) Name - In the Features admin ui, the bean types appear under a category called Bean Admin UI. A more appropriate name would be 'Bean Types'
#21
Oops, wrong patch. This one has working update hook.
#22
Thanks for fixing the update hook, nicely done!
Here is a patch that adds the fields we attached to a bean type to the feature automaticly. The second complaint however is harder to fix, since features just takes the name of the module as component name, and it doesn't provide a good way of altering that as far as I know.
We might consider breaking out the configurable bean into it's own module so that you don't have to have the UI enabled to actually create your bean types, it feels kind of strange that you would attach that to the admin module, but I would consider that a different patch.
#23
I like that this patch doesn't touch the core UI. Exporting only deals with bundles created in the UI.
As far as separating out the UI from the config, I have no issue with that. In fact, that's a good idea. As long as the core API doesn't change, there isn't much I care about :) I'm only using the core API in our projects.
The UI was more for the masses so if you two (fabsor and mrfelton) want to own the functionality that the bean_admin module adds, please go ahead. Let's just make sure that we don't add anything to the admin module that should be in the core API.
#24
It is actually possible to change the name provided in the features UI. Features allows you to override any one or more of the default features hook implementations, including hook_features_api() which is where the name comes from.
Attached patch implements hook_features_api(), and moves your features pipe alter into a includes/features.inc file
#25
FYI, lok at the top of features.ctools.inc in the features module. Some pretty funky code there to make that possible!
Also, the bit from the features API.txt that explains it:
#26
I definitely agree about moving it out into its own module eventually. The fact that all of this is attached to the admin ui really confused me when I first started to work on the exportable support. We are not exporting admin_ui's - we're exporting bean_types, and you shouldn't need an admin_ui enabled to do that.
#27
I see this !empty($type) in there for bean_get_types(). That shouldn't be possible. What's happening there?
#28
@indytechcook - it's required for the update to function properly. $type can be empty just after you have updated the module code, but before you have run update.php. Because the new codebase is looking at the new database structure to get the plugin/type information and until the update has been run, the new database structure is not in place. See my comments in #18 and #19. You can't even load update.php or run updatedb from drush without those checks in place.
#29
Right, since we changed the name of the type field. That reminds me that we really need better error handling. A try/catch.
#30
Here is a revised patch that actually contains features.inc - missed it out of the last patch. I've also adjusted the hook_features_api() implementation based on the outcome of my discussions in #1193114: Exported DS configs do not include custom styles.
#31
@mrfelton and @fabsor if you are happy with this let's push it up. I want to role a new alpha today. I'll be out of town all weekend.
#32
I haven't fully tested the revert functionality yet. I'll do this in the next couple of hours.
#33
Ever so slightly revised patch attached. Just one small change to the block type listing screen, to ensure that the table display correctly for all override statuses. I think you are good to commit this. It gets the functionality in place. We can move it around in the code later if it makes sense to do so.
#34
Committed and on alpha 3
Let's open new issues against alpha3 as bugs for changes.
#35
Looks like this didn't apply properly. The bean_admin_ui/includes/features.inc is not in the repo.
#36
Odd. I'll try again.
#37
@mrfelton can you roll a new patch against the latest in the branch? I'm not sure what happened and I can't apply the patch anymore.
#38
Added in http://drupalcode.org/project/bean.git/commitdiff/879d4d3?hp=66872c0985a...
#39
I added a new alpha release since this was a pretty big mistake :)
#40
Automatically closed -- issue fixed for 2 weeks with no activity.