In the following examples I assume you have a reference to the editor (ed). This may be as simple as getting the activeEditor.
var ed = tinyMCE.activeEditor;
Unlike the insertion of content at the current cursor position, which simply uses the selection object
ed.selection.setContent("some content");
insertion of content into other parts of the document require the dom object.
Let’s start with inserting into the end of the document. Fortunately TinyMCE provides a dom api call to add an element. So, if we provide a reference to the document using ed.getBody(), we can insert a new element. For example
ed.dom.add(ed.getBody(), 'p', {}, “some content”);
inserts a new paragraph at the end of the document.
Inserting content at the beginning of the document however is a bit more tricky. In this case, there isn’t a helper, so we need to first create the new element, and then insert it before the first child of the document. Again, there is a dom helper to assist in the creation
var el = ed.dom.create('p', {id : 'test', 'class' : 'myclass'}, 'some content');
We then use the insertBefore() method providing a reference to the firstChild of the document.
ed.getBody().insertBefore(el, ed.getBody().firstChild);]]>
The test platform is Windows XP running JRE6u7 with Java Accessibility Bridge 2.0.1 and JAWS 10.0.1139 installed.
When JAWS was activated after installing the Bridge, the screen reader output the details as I navigated around the Java Applet. So it read the menu names, dialog fields, the keys entered while typing etc.
When I upgraded JRE to JREu11, not only did JAWS no longer read out the menu and field names but cursor movements no longer work at all. That is to say, you can no longer navigate through the entered content in the editor. It appeared as if the cursor events were not being passed to the Applet and JAWS was not being passed the accessibility details back.
I then upgraded to JREu14 beta to see if this resolved the issue. It didn’t.
It was recently suggested that the upgrade to the JRE may have blasted the accessibility.properties file so the Access Bridge no longer gets loaded. To test this theory I reinstalled the Java Accessibility Bridge and JAWS now responds appropriately.
So, if you have JAWS and a JRE pre-update 10, you might want to reinstall the Java Accessibility Bridge after you upgrade your JRE.
]]>"Publishing now belongs to the community"
I completely agree. The problem I see however is that the content authored, while mostly aimed for publishing on the web, is authored or stored as "Wiki Text". Like Doug, I'm amazed that wiki markup is not seen as "arcane" in the same way as the original layout languages.
Prior to starting at Ephox, I introduced a simple wiki (JSPWiki) to the company I was working with. While there was some initial enthusiasm, it really didn't take off.
When I came to Ephox I again introduced the wiki to the team as I was still convinced that it was a great way to communicate and collaborate. We immediately replaced the simple text area and Wiki-markup1 with our editor and HTML. The explosion of content has been amazing. Everyone from Sales to the Office admin have authored content.
By allowing any person to create new content and edit existing content the wiki definitely puts the power of content publishing in the hands of the community. By adding the ability for the authors to create the content in a simple, user friendly and most importantly "arcane language" free way, I believe you truly give the power to publish rich content to the authors.
1 – JSPWiki supports storage in HTML instead of Wiki-Markup.↩
]]>In my lead-up reading, everything pointed to using an established framework, so I chose Script.aculo.us as a starting point. After an hour of playing I had lost all my awe of the drag-n-drop and roll-up type effects I had seen. With a good framework these become so simple. The challenge then, is to use the effects wisely 🙂
I then spent some time with the product managers looking at what we could apply to our demos framework to enhance the experience.
The time I spent this week, while giving me some hands-on insight into the AJAX frameworks also reminded me how much I enjoy development. In addition, the best way to understand a new technology is to get your hands dirty. As an Engineering Manager I think it's important to stay in touch with the technologies and architectures of your field.
So, if it's been a while since you last "tinkered" with some code, go spend an hour getting dirty. It keeps you in touch with what your team is doing daily and you might just have some fun 🙂
]]>The underlying technology of AJAX has been around for a while, but what's interesting is the amount of buzz surrounding it now. The danger with this sort of buzz is both engineers and business people alike can get caught up in it and make decisions based on the hype, instead of what is the right solution to a clients problem.
As Chris puts it
When you make decisions, one strong cognitive bias is the bandwagon effect, a well-known psychological phenomenon.
Don't get me wrong, there are still plenty of good business reasons to do something even if it's a "bandwagon" idea, for example to get press interest or attract VC. But the real challenge is to overcome the "bandwagon" impulse of a new technology and identify what technical benefits are to be gained by using it.
As I see it, part of the role of engineering is to cut through the hype surrounding a technology, understand what the pros and cons are of it, identify how it can best be utilised to solve a problem and provide an unbiased recommendation of it's potential use in the business.
Of course, engineers aren't immune to hype either, so part of the role of the engineering manager is to remind everyone that the technology is just a tool and ask the questions "what are the real problems with using it?" and "how and where could we use it?".
]]>