ContentBox

Wow, yesterday was awesome! My sessions went well (at least I think so), and I’ve received a lot of positive feedback from the discussions.

For everyone who attended, thanks very much for your participation…it definitely means a lot and I hope the sessions were as informative as they were fun to create.

If you didn’t get a chance to attend, the sessions recordings have been posted (see links below).

ColdBox Developers Week is not over, though–there are still a TON of great sessions through the remainder of the week, so be sure to check out the lineup and attend as many as you can. I promise you will not be disappointed!

If you haven’t already (what, you haven’t? FOR SHAME!), be sure to register for ColdBox Developer Week, starting…well…today! This is a great week of really great sessions covering ColdBox, ContentBox, WireBox, AOP, ORM…phew!

Even if you don’t use ColdBox (yet…), I’d still encourage you to check out some of the sessions. It will give a you a good insight into what you’re missing out on

I’m particularly exited about this CBW, as I have the privilege of presenting two sessions!

With ColdBox’s CriteriaBuilder, you can build powerful and dynamic Hibernate criteria queries with very little code. But does it work in real life? To put that question to the test, we’ll explore some real life scenarios and see how CriteriaBuilder can help us

In this session, we’ll learn how to extend CKEditor within ColdBox to provide rich, custom content editing capabilities. We’ll also explore how custom CKEditor plugins can be integrated with ColdBox modules to take content editing to the next level.

In my last post, I showed how it’s not only possible, but also pretty dang easy to make a custom CKEditor plugin that can interact seamlessly with a module. While it worked pretty well in modern browsers, it completely bombed on older versions of Internet Explorer (surprise, surprise).

The main *problem* with older IE support is the use of a custom html tag (<fiddle>) to store the complex data type in CKEditor. Not only does CSS styling on this unknown element fail in <IE8, but it’s insertion into CKEditor also fails completely, presumably because of the old DOM implementation.

While annoying, this is hardly a deal killer. The choice to use a “fiddle” element was hardly required…I did it because I wanted to. However, in the spirit of backward-compatibility, I’ve updated the plugin to work with a plain-old <div>.

I recently developed a simple module for ContentBox called jsFiddle. Basically, it allows you to insert “fiddles” from the excellent http://jsfiddle.net into your posts and pages. In developing this module (and CKEditor plugin), I wanted to be able to insert complex data into the content editor, but then be able to re-edit that content after insertion. I’m pretty happy with how it turned out.

In the following paragraphs, I’m going to walk through the process of developing a ContentBox module that includes a CKEditor plugin which is capable of content re-editing. Hopefully this will inspire some others to develop some killer new ContentBox modules with helpful CKEditor plugins.

NOTE: In this walkthrough, i will include snippets of code, but most of them will be severely trimmed for the purposes of this post. If you really want to follow along with the full code, please grab it from the GitHub repo. Furthermore, I’m not advocating that this is the “best” or “only” way to accomplish this. My only intention is to share some ideas about things that have worked for me. So if you have corrections or suggestions for how things can be done better, I’m always ready and willing for civil, constructive feedback

Over the last two days, I’ve been playing around alot with a new plugin that I’ve been working on for inclusion in CKEditor, expressly for the purposes of creating a very handy way of inserting snippets of code, decorated by Syntax Highlighter, into ContentBox‘s content editor.

Some of the functionality I’ve been playing around with is the different ways in which you can trigger “edit” events on elements in CKEditor, primarily for the purpose of opening a modal window and allowing for editing of the element’s properties (such as href, title, class, etc.). This weekend, I brought the options in the new plugin I’m working on up to the following:

Via link in context menu

Double-clicking the element

And the most interesting…using jQuery to help overlay an inline-tooltip (see below)

In my next post, i’ll describe how to do this…just wanted to put out a teaser before I sleep and prepare for the new week!

Allow user to act on inserted content–particularly, be able to edit all the properties of the content that were configured pre-insert

The first two are really easy. If you look at the source of the PasteBin module, you’ll see really quickly how to do those, so I’m not going to dwell on that. In this post, however, I do want to show how simple it is to make inserted content regions richly editable, treating them like complex data, rather than just simply strings.

NOTE: In the following, I include code-snippets, but often omit unimportant or redundant bits. Be sure to grab the entire source to see everything in its full context

As you’re developing ContentBox modules, you will certainly come to a point where you’ll want to be able to extend the Page/Entry editor. Whether you need to add a custom section to the options sidebar, or add some functionality beneath the main content editing area, ContentBox makes it incredibly easy to add your own custom functionality/views via interceptors.

In what follows, I’ll share an example of a module I recently developed and show how simple it is to add your own custom functionality to the ContentBox page/entry editor.

Some Context

Before we begin, let me describe what we’re building. My module is called “Super Menu”, and allows users to not only create custom menus from page/post content (as well as custom links), but also allows users to apply these custom menus to individual pages and entries. Because of this, my module needs to have a “section” in the page/entry editor that allows users to choose from a drop-down of menu names. For my module, I decided to place it in the “Page Details” sidebar. At the end, it should look something like this (notice the custom “Super Menu” section at the bottom):

And, of course, when the form itself is submitted, I’ll want to More >