In this second last chapter of this wonderful journey aka the
Christmas Calendar 2009 it's the final touch - what it's all about:
Create new blog posts. Easier.
While Umbraco's UI makes it a breeze to manage and edit content
it's still a multi step process to create a blog post. And while
Blog 4 Umbraco automatically generates a content channel so you can
edit with Microsoft Word, Live Writer or any other 3rd party that
supports MetaBlogAPIs that might not be an option either. All we
want is to login to Umbraco, write a post and click Publish. And
that while still having full support for any dynamic changes to our
document type.
The Dashboard and the DataType APIs to the rescue - and
a lot of hacks
Once again the solution is the easy to config and extend
dashboard in Umbraco. We'll simply place a "Create Blog post"
control on the dashboard and make the control visible when you
login. Like this:
Notice how the edit controls looks exactly as when we edit the
blog post normally. This is because we're reusing the settings on
the document types and uses the DataType APIs to fetch all the
metadata on the properties. This means that if you add additional
properties to the blog post document type or if you change the
existing ones, they'll automatically be updated. It's very simple
and the exact same technique used by AutoForm or Doc2Form (and the
standard edit content page, btw). And it's really simple - if it
weren't because the Rich Text Editor and the Tagging datatypes are
the two most advanced and both have horrible design decisions - I
couldn't get the toolbar icons from the Rich text editor appearing
and I got weird exceptions in the tagging datatype.
Luckily Umbraco is open source are we can actually find the
reason why all this is happening. The Rich Text Editor couldn't
understand where it was, it was neither on a standard edit page
(such as edit content, member or media) and it wasn't in live
editing either. So it couldn't find anywhere to place the toolbar
icons. Luckily it's fully configurable and we're able to tell it by
accessing the Config collection in the tinymce class. Problem
solved. Only thing that needs polish is the 140px left padding, but
that's a job for a jQuery hack later :-)
It was a bit harder for the tagging datatype. You see, to find
out which tags is already selected for the item you're editing it
uses a weird technique of either calling the request collection for
an id (when editing on a standard edit page) or using the node
factory when editing live. This is probably legacy as data types
have an easy way of getting the current id of the item edited, but
that doesn't help us when it's already done wrong. Luckily we can
use reflection to modify the request collection (now that's a
hack!) to add the id and voila, the tagging control worked too.
All in all it was a little harder than it ought to and once
again this process reveals areas where Umbraco can easily be made
better. But at the same time, I was very satisfied with the end
result and think it's a very handy technique for improving the
editor experience in an Umbraco implementation. This technique
could easily be used to news editors or other types of create tasks
where users often create the same types of documents. This really
speeds up the workflow.