Import/Export Fork

Topics: General
Editor
Feb 10, 2012 at 1:41 PM
Edited Feb 10, 2012 at 1:47 PM

Hi Piotr,

So I started a fork for adding the import/export capability: http://orchardmenu.codeplex.com/SourceControl/network/Forks/kevink/OrchardMenuImportExport.

One thing to note is that I also reorganized the migrations in this fork. I changed it so that the Create method sets up everything as it should be in it's final state, and then have it return the migration number of the last update. So new installations will only run the Create method and have everything created by that, while people on older versions who update will still have the updates run. This is the model Sebastien tends to use and one that I've started to adopt also. It simplifies new installations quite a bit, especially when your history of updates starts getting complex with adding/dropping/changing database elements.

Anyway, the import/export functionality for menus, menu items, widgets and styling is there and working. You can put Szmyd.Orchard.Modules.Menu in the Features section of a recipe, along with Orchard.ImportExport, and have menus, menu items and widgets in the Data section that get automatically imported when you setup the site. It's nice.

However, I'm not submitting a pull request yet because there's one issue I don't know how to handle. I had to comment out the MenuFeatureEvents class in my fork for now. The problem is that the FeatureEventHandlers get run as soon as the feature is enabled by the recipe, which happens before the import step. So the handler creates the default 'main' menu, which then causes a problem when importing the menus specified in the recipe. Ideally, we would not want the event handler to run at all if there are menus specified in the recipe, but I don't know how we can determine that at the time it's running. Ideas?

Kevin

Coordinator
Feb 11, 2012 at 11:09 AM

Thanks for refactoring the Migrations - the way Sebastien handles that is definitely a way to go. I'll think about the events-related issue and keep you posted.

Editor
Feb 17, 2012 at 2:10 PM

I've pushed a few more changes, including import/export for the Breadcrumbs widget. I also went ahead and put the Events code back in. The answer (at least for me) for now is to not name any menus in your recipe as "main", since the FeatureEventHandler is going to create one named "main". That just means I need to delete the "main" menu after running my recipe to setup my site. A bit annoying but not too bad.

I had an idea to handle this situation by also adding a new command to delete a menu. I committed that change too, although it doesn't currently work for this scenario. The command itself works. You can launch an Orchard.exe session and run "menu delete 'main'" and it will delete the menu. So my thought was to just run this command in the recipe.

The feature would be enabled, which creates the "main" menu. Then the commands run, so I would delete the "main" menu that way. Then the data import runs and imports the menus that I specify. The problem is that when this all happens as part of one recipe it doesn't work because when the command queries for a menu named "main" (using the AdvancedMenuService, which uses ContentManager) it doesn't find one. Even though the Events code has created it. I assume this is because it's all part of one transaction and the one created in Events hasn't been committed yet?

Anyway, it's close to a good solution. If you can figure that last part out I think it would a good solution overall. I'll go ahead and send a pull request for the changes I've made so far.

Coordinator
Feb 17, 2012 at 6:05 PM
Thanks, that's great!

Will try fixing those things you mentioned and integrate your pull request during the weekend.

All the best,
Piotr

2012/2/17 kevink <notifications@codeplex.com>

From: kevink

I've pushed a few more changes, including import/export for the Breadcrumbs widget. I also went ahead and put the Events code back in. The answer (at least for me) for now is to not name any menus in your recipe as "main", since the FeatureEventHandler is going to create one named "main". That just means I need to delete the "main" menu after running my recipe to setup my site. A bit annoying but not too bad.

I had an idea to handle this situation by also adding a new command to delete a menu. I committed that change too, although it doesn't currently work for this scenario. The command itself works. You can launch an Orchard.exe session and run "menu delete 'main'" and it will delete the menu. So my thought was to just run this command in the recipe.

The feature would be enabled, which creates the "main" menu. Then the commands run, so I would delete the "main" menu that way. Then the data import runs and imports the menus that I specify. The problem is that when this all happens as part of one recipe it doesn't work because when the command queries for a menu named "main" (using the AdvancedMenuService, which uses ContentManager) it doesn't find one. Even though the Events code has created it. I assume this is because it's all part of one transaction and the one created in Events hasn't been committed yet?

Anyway, it's close to a good solution. If you can figure that last part out I think it would a good solution overall. I'll go ahead and send a pull request for the changes I've made so far.

Read the full discussion online.

To add a post to this discussion, reply to this email (orchardmenu@discussions.codeplex.com)

To start a new discussion for this project, email orchardmenu@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com




--
Piotr Szmyd
There's no place like 127.0.0.1...

Editor
Feb 17, 2012 at 7:24 PM

Cool. Let me know if there's any adjustments you'd like me to make.

Also, since I sent the pull request I've committed a couple of more features. They really should have been in a separate fork, so that I could send a separate pull request, but I was too lazy.  :-)  Actually, I needed these features, along with the import/export stuff for the project I'm working on, so I just did them in the same fork. If you pull the current request, I can send another one for these other features.

The new features are both new options on the menu item. The first allows the user to choose whether to show the menu item to any user (the default), only anonymous users, or only authenticated users. The second feature allows the user to check a box to include a ReturnUrl query string parameter on the menu item url. Both of these are useful for the scenario where you have Login/Logout items in a menu, and I suppose could potentially be useful in other scenarios as well (especially the first one).