Hi Ryan

You should be able to find more information about it in this tutorial http://umbraco.github.io/Belle/#/tutorials/Adding-Configuration-To-Property-Editor and you might also benefit from the angularjs workbook https://github.com/umbraco/AngularWorkbook

I hope this helps.

/Jan

Hi Ryan,

In addition to Jan´s great post I would also recommend you to have a look on Umbraco TV www.umbraco.tv, in there you will find a chapter about property editors and how to create them. http://www.umbraco.tv/videos/umbraco-v7/developer/extending/property-editors/

And there is also a video about the manifest http://www.umbraco.tv/videos/umbraco-v7/developer/extending/property-editors/defining-a-plugin/

If you don´t have access yet to Umbraco TV. you can find the different plans here: http://www.umbraco.tv/plans-signup/

Hope this helps,

/Dennis

Thanks Nathan, assuming that is complete that is exactly what I was looking for.

Ok, so what I'm about to partake in, is extending that schema, App_Plugin\SomePlugin\Package.Manifest.

I do not like using courier to deploy content types, data types, pre values, media types, templates, etc. I feel all of that should be in source control in my visual studio project and the only thing I should be deploying anywhere is content. Also because are sites are deployed via MSDeploy we don't need to push out media files or anything like that either. The only thing I ever have to move from Server A to Server B is Content Nodes and Media Nodes, everything else is the exact same in all environments.

I also find packages like uSiteBuilder to be lacking (no media type creation and to many bells and whistles). Also the umbraco api is tedius for programatically creating document types, data.

We currently use uSiteBuilder and move our media types with courier but I feel this is temporary.

So what I'm planning on doing is adding a schema addition to the package.manifest file which I will use for Meta Data Syncing (refering to Data Types, Pre Values, property editors, Document Types, and Media Types as Meta Data). So you'll be able to define data types, document types, etc in the package.manifest of a plugin and it will create them on Application Start and other specific conditions.

Something like this

{
dataTypes: [
    {
        alias: 'XYZ_DataType_1',
        name: 'Friendly Name',
        prevalues: ...
    }
],
documentTypes: [
    {
        alias: 'XYZ_DocumentType_1',
        canUIDelete: false,
        canUIEdit: false,
        name: 'Friendly Name',
        allowedTemplates: ['Page', 'WikiPage', 'ArticlePage' ],
        container: true, //List View
        allowRoot: true,
        allowedChildren: ['XYZ_DocumentType_2']
    }
],
mediaTypes: [
  ...etc
]

}

I'll also add a custom section for manual syncs where it will go through App_Plugins folders looking for package.manafest and do upgrades. I'll even through some form of versioning in there so it knows what version a data type is and if it needs updated.

Also, the canUIDelete and canUIEdit fields will be handled by a ContentTypeService.Deleting event handler, same thing on DataTypeService.Deleting.. etc so I can block users from making changes to them or deleting them (if they are critical to the plugin.)

And I'll do the same thing on Document Type Properties so a property can be marked as locked (can't be removed/renamed/edited) etc.

I think a package that adds this functionality to umbraco would be extremely ideal. One of my biggest flaws with anything running in umbraco is the ability for the back office user to just bork something. For example take Articulate (Blogs on umbraco). It deploys some document types and if say the project manager decides (for whatever reason) she doesn't like the name of the Authors property and changes it to "Publishers" articulate's views in the theme bomb out.

Not complaining, umbraco is over all great, it just needs some love taps.

is working on a reply...