Some tips on using our Umbraco DocType Mixin package

Posted on 16 September 2011 by Pete Duncanson Tweet

We wrote a nice little package for helping create Doc Types in Umbraco a while back and now we've been using it a while we've come up with some tips on how best to use it to stop things getting confusing.

I might add to this page as and when we come up with some more tips but initially this is just a short little post to show you some of the tips/best practises we've adopted and why.

When I talk about We here that includes the lovely Matt Brailsford as well as the "Royal we" of Offroadcode :)

Naming conventions

When you install the package it creates for you a nice Mixin doctype that you should create your Mixin's under to keep them grouped together. This works well enough in the UI of Umbraco but breaks down when you start trying to create content items and having to select a Doc Type from a drop down list. Remember nested document types have been supported/allowed for ages in Umbraco but the support for them in the UI are quite new features as the use of them has increased. The doc type selection drop downs and structure check boxes are still aimed at the old non-nested style so don't show you your doc type hierarchy.

To get around this we've taken to simply starting all our mixin names with "Mixin - " so they are all grouped together in the drop down out the way. Its not rocket science or anything but it works. If you want to get fancy you could call it "zMixin - " so they will always get rendered at the bottom of lists out the way.

Ideally we are going to add this into the Mixin package itself in the next release so it will just be done for you.

Tab orders

When you create a Mixin you can create tabs too and these will be copied over to the doc types you apply the mixin to. Its recommended to set a tab order for all the mixin tabs so that they don't get inserted as the first tab. By default they will have a tab order of 1 and when copied over they can over rule any existing tab order and muscle their way to the front of your tab list, not something you might want to happen. We've started giving them a high number so they always get added last (ish) to the tabs. You can insert any number you like my the way, should be safe up to 250 ish as I'm not sure what data type they are saves as in the DB. I often us 99 and it works just fine. You can set all your mixin tabs to 99 and they will just have to fight it out as to who gets what order or if you are feeling smart you can give each one a unique number so the order will always be the same.

Again this might be a nice one to add to the package but it has some dangers and some head scratching to get it working, will have to see how much time we have free.

Check you spellings

Before you press that save button on your mixin just double check everything, twice. Currently you loose some of the goodness of Mixin's if you mess up a field name as you have to go in and manually change them all and thats what it was meant to prevent in the first place. If you have messed them up it can be quicker and safer to just delete the miss spelt fields rather than rename them, change the spelling in the Mixin and then re-apply it by saving it again.

Also it is a good idea to apply it to just one target doc type first rather than all of them. That way you limit any work you have to do should you have made a typo. Once happy then you can apply it to any other doc types you might like to decorate.

You can't override data types

Currently you can't change the data type of a field, if the field already exists then our package will leave it be. This is a simple security feature, you might have data in there and if we change it you'll loose it. That would be bad. However when you are first building the doc types for a site and getting the fields you need and the data structures there is likely to be a need for some quick changes and changes of mind or new information. As it stands there is not much you can do about it, again, deleting the fields from the targetted doc types is the quickest way of clearing out incorrect fields and then reapplying the mixin with another save. This keeps all those changes in one place (the mixin) rather than risking a typo in a field name which will bite you later.

We are hoping to fix this one into the next release too at some point by hopefully allowing you to force the mixin to be able to override existing settings. You will be able to disable this setting once you've done your inital setup its hoped to again avoid any problems with accidental data loss.

That is about it. Hope its helped a little. If you've not tried Doc Type Mixin's yet give is a whirl on your next project. Its not for ever situation but it can be handy to have around. If you have any more suggestions/best practises let me know in the comments.

Cheers

Pete