Thursday, May 1, 2008
The latest release included many API updates that weren't detailed in the original announcement. Here is a run-down of what's changed for developers. If you haven't checked it out lately, see the reorganized wiki site and associated parts of the JavaScript API for more information.
You can now have multiple EditMeScriptEvents pages. Any scripted page with a name starting with EditMeScriptEvents will be processed like the EditMeScriptEvents page. This allows modules and applications to each have their own event handlers without over-writing eachother. See Event Model for more information.
The Page and Attachment create/update/delete events are also now implemented. It's possible that the VIEW events for pages and attachments will never be implemented as caching makes doing so unreliable at best.
Page and attachment versions are now accessible with the following methods:
Change history information is accessible with the following methods:
The site.getPage(name) method returned a page with its content set to what you see in the browser. In other words, [[DoubleBracketLinks]] and [[include:tags]] were already processed. This means if you modified the page content and called save(), these changes were saved permanently. A new method has been added to provide the source content of the page so that it can be modified and saved without losing double bracket tags.
Other methods that return unsaveable pages will now throw an exception if page.save() is called on them. The message is fairly self-explanatory, indicating that the getPageForEdit method should be used if the page will be saved.
Previously, EditMe wouldn't allow most DOCTYPE tags at the top of a Layout. While they still can't be placed where they're supposed to, a work-around allows them to be added to a CDATA node in the document HEAD, and the Layout engine puts it at the top of the page when the Layout is rendered. See this page for full details.
The DataViewer script that was provided as a sample program using the Data class is now available for easily installation as a module. This is a very handy scripts for managing data entries during development.
Previously the API did not provide a way to get or set the security setting for pages. The security setting over-rides the site-level Page Security setting at the invidual page level. It can be set to one of six constant values, or assigned to a Policy object. See the PageSecurity class documentation for details. Additionally, the previously undocumented site.policies property is now documented.