topic Re: WYSIWYG website editing with Browser XForms in Alfresco Archive

WYSIWYG website editing with Browser XForms

damonsmith — Tue, 10 Feb 2009 16:47:16 GMT

Hi all, This is unrelated to the other recent WYSIWYG thread. Having looked at web forms, they seem to inflexible and hard to develop for what I need. To get around that, I've built a prototype that uses the mozilla XForms plugin instead, some javascript to display and update the web page inline,

Re: WYSIWYG website editing with Browser XForms

tommorris — Thu, 19 Feb 2009 08:43:12 GMT

Hello Damon,

I hope things are okay with you.

What you've done sounds very interesting. Can you elaborate a little more please?

Tom

Re: WYSIWYG website editing with Browser XForms

damonsmith — Thu, 19 Feb 2009 15:08:01 GMT

Glad you asked Tom

We don't use Alfresco to serve site content, only to deploy it where our content server app can read it. This content server is a java app that "includes" template files together to make pages, and overrides files for different languages and regions to provide the option of minor or complete customisation of the site for regions and locales, while still falling back to the default site for non-overriden bits.

I was considering how to make editing the content in this system easier, and came to the conclusion that if the browser could identify each file fragment in the generated page, I could write some javascript to overlay editors on the content, and then post the changes back to Alfresco. We've already built the content server app which uses velocity. We have a velocity macro to do the file inclusion so I added an edit-mode for that macro where it marks editable file fragments with surrounding tags and comments. These tags and comments are picked up by the editor javascript, which adds mouseovers and options for editing the content inline in the page.

These changes can then be posted back to an Alfresco web script which updates the AVM. This on it's own is quite useful, but then if I load the app into the Alfresco preview server in edit-mode, all of a sudden the process for editing the website becomes:
1. Login to Alfresco and find your web project
2. Click on preview in your sandbox
3. Find the part of the site you want to edit
4. Click on the edit tab and change it.
5. When you're happy, hit the submit changes button
6. Go to Alfresco web project page and hit submit all

There's a config file for matching editor types up to file fragments and templates, and a few different editor types to use. I think the template editor is very useful, but the user has to install the firefox XForms plugin to use them. (You could also build an HTML forms based editor that converted things to XML, or templated some other way, as long as it generates some text.)

Does that make sense?

Re: WYSIWYG website editing with Browser XForms

pmonks — Thu, 19 Feb 2009 17:34:42 GMT

Nice!

FWIW this is quite similar to the architectural model that Web Studio (http://wiki.alfresco.com/wiki/Web_Studio) uses, although there are some minor variations in the details (eg. the use of the browser-side XForms). In fact Alfresco (not to mention the wider community) are increasingly moving in this direction, where the main Alfresco server becomes a "headless" content repository, and multiple use-case-specific UIs (Share, Web Studio, Flex Spaces, …) interact with that repository via REST.

Cheers,
Peter

Re: WYSIWYG website editing with Browser XForms

tommorris — Mon, 23 Feb 2009 15:58:44 GMT

Is it this that you're using?
http://www.mozilla.org/projects/xforms/

This sounds like a good idea when there's a need to write a highly tailored (probably limited-functionality) web-interface for WCM content authors.

I like it.

Do you use CSS 'class' attribute values to identify editable portions?

Re: WYSIWYG website editing with Browser XForms

damonsmith — Tue, 24 Feb 2009 16:58:02 GMT

Yeah that's the XForms plugin. It's pretty awesome for generating complicated forms quickly and plugging in other XML data models from web scripts, like "all images in folder x" or "all files with extension y"

To define editable areas, I just wrapped the content fragments in tags, so each editor has a configurable start and end marker. That works for almost all content, except for things like the text inside a title. There are so many ways of marking things though, and it doesn't have to be start and end tags, it could be ids or tag types. Anything really.