Thanks for your quick response. Yes, I'm building a community website for a non profit working in international development. I really like many of the features of Share.ez.no so compliments to the designers and developers! Great work! I look forward to seeing the code when it is available.

Just checking in to see if there was any progress in sharing the code for this site.

At the moment I'm particularly interested in the code behind the "add reply" feature of the forum. I can see that onclick = "return community.newContent(this.form,'new-content')" fires off some custom javascript to load a new content object form into an empty div. It would be great if that were an extension so that it would be easy to use this approach to add new content objects inline - a super useful feature!

To take it one step further it could be integrated with a popup box script so that you could add new content in a popup box like fancybox or colorbox. I've managed to get fancybox working for editing content objects but haven't figured out how to do something similar for creating new content objects because fancybox (and all the others I looked at) require an anchor as the trigger (i.e. <a href=""></a> ).

I'm happy to help pull this together if someone would be willing to help get it started.

I just realised that the add reply technique could also enable inplace editing, which would be very cool. Just trigger the replacement via a double click on the content, and then replace the content with an edit form.

I think you can quite easily implement such functionality using jquery and ezjscore. Maybe you also need the powercontent extension to bypass content/action and create the forum reply object on the fly.

@Fraser : the in-place editing idea is excellent. It is becoming a common feature, we need to have this in eZ Publish.

@Sander, Fraser : no powercontent required here, the trick, in short, is as follows. Let us take the example of the soon-to-come event planner system. The template code below is from the landing page (a folder storing all event objects) :

Thanks for sharing. That's an old trick and very inefficient method! I was hoping for something more lightweight using some neat ezjscore class

Yet performing well and being pragmatic in the sense that it relies on very standard parts of the system. The next step imho is to plug front-ends on the REST api directly, removing the need for intermediate parts

Thanks Nicolas! You guys have done a great job with the design and functionality of the site and I appreciate being able to learn from it. ezPublish has a bit of a clunky UI right out of the box and this site shows how it's possible to work around that and add some nice interactivity and responsiveness. It would be good to have a collection of UI design patterns that are not too difficult for an average ezPublish developer to implement. Then alternative approaches to achieving a certain functionality could be shared.

I had a somewhat radical thought last night about attributes and edit views. I've been working a lot with XForms and I really like the separation of the data model, the controls and the appearance of controls. Define the data model and data type with a schema (eg. xsd:dateTime), decide what kind of control you want (e.g. input, secret, textarea, select, select1, range, upload), and then decide what the rendering appearance of the control should be, possibly based upon the device or interface being used (e.g. full, minimal). So in ezPublish terms, instead of picking attributes that mix data type and presentation, and are therefore inherently limiting, a user would first define the data type (xs:string), then the control (select1) and then the appearance (minimal = combobox). If a select1 was chosen, then the user would be presented with a form to define the source, either entering items, referring to a parent node or referring to a built-in list. An example of a built in list would be countries, languages, etc. This way we wouldn't need so many separate and specific ez data types and would give user much more control over the rendering of the user interface. With consistent markup for the control presentation, it would be easy to skin the controls. Also, a form or attribute could have three different edit modes: new page, in-line (on its own, above or below read only version, or replace read only version), or popup.

Apologies for the tangent, but back on topic, I'm also very eagerly awaiting development of the REST API! This is will open up lots of possibilities to improve the way we can create and edit content on an ez site. Is there a timeline on when it will be possible to create and edit via REST?

@fraser: using different rendering modes for nodes is a central feature of eZ. Applying it to datatypes makes a lot of sense imho, and goes a long shot in the direction you are indicating. But different datatypes are also used to do backend-validation, and not to rely on js / browsers to do it for you

I've had some success with the technique shared above so I thought I would share my results for anyone interested. I also have a couple of questions.

I modified the js code a bit so that I could use the same code for both editing and creating content. To do this I changed the first parameter from formElement to buttonElement. Then in the onclick, I use "this" instead of "this.form". In the js code I use buttonElement.form to get the formElement and buttonElement.name to get the button name for the data.push statement. I also added a hideElementID parameter so I could have control over which part of the interface is hidden.

After publish, the redirect uses the ajax layout instead of the normal layout. How can I correct this?

CSS and Javascript required for some datatypes (e.g. ezImage and ezXMLText) is not loaded so these datatyles don't display properly. I was able to work around this for images by copying the require statements from ezImage gui.tpl to the main template override, but couldn't get the OE rich text editor working for the ezXMLText. How have you achieved that in this site?

Adding css and javascript to the main template to get the loaded datatypes to work properly is probably not a good solution. What if you want to add a new datatype to the edited class that has other requirements? Or if the requirements of the datatype change?

One workaround is to load the content into an iframe instead of inline in a div and include page_head_style.tpl and page_head_script.tpl in the ajax_pagelayout.tpl.

Another is to use the powercontent extension and load the create or edit forms with the rest of the page so the correct css and javascript files will be included automatically.

CSS and Javascript required for some datatypes (e.g. ezImage and ezXMLText) is not loaded so these datatyles don't display properly. I was able to work around this for images by copying the require statements from ezImage gui.tpl to the main template override, but couldn't get the OE rich text editor working for the ezXMLText. How have you achieved that in this site?

Let me take the example of ezoe (aka ezxmltext or online editor), on share.ez.no. On the full view template for a forum topic like this one, when the user is logged-in, he might be willing to reply, in other words create a forum reply object under the current node. A forum reply contains an ezxmltext field, online editor is required.

This information is passed from the full view template to the pagelayout using the persistent variable, in which the following hash is added :

PS : not sure you read French (Google translate can help you with this), but Gilles published a three-part tutorial on how to implement front-end edition (including in-place edition) in eZ Publish. Mootools is used, and the content dates a bit, but i believe this can be a good compliment to the share.ez.no example :

I also tried adding the other scripts that are in ezxmltext_oe.tpl to my full override into which I'm loading the edit form and this didn't help. For example there is a function tiny_mce.init.

Have you initialized the editor in some other way? I hunted through all your code on this site but couldn't find anything. It's still a mystery to me how you've got it working!

Finally, regarding the idea of loading into an iframe, I spent a lot of time trying this and it doesn't work because the ajax response, at least using jquery, doesn't include any of the script tags. It runs the scripts before returning the html as a string. I could use the response to populate the inner html of the iframe documentContent but without the scripts the editor wouldn't work.

I've burned a lot of hours on this and I'm ready to try another approach. Are there any major issues with using the powercontent module?

After much trial and error, the only way I could get the editor to work in the loaded content was to put this init script in both the main page template and the loaded html (ajax_pagelayout.tpl) AND put a text area in the main page template. So, on initial load of the main page template, the unnecessary textarea renders with tinymce, then when the new content is loaded, it also renders with tinymce. But if the script is not in both places, if it does not contain exactly the same options and if there is no textarea in the main template, then tinymce won't render in the loaded html. Very strange. I thought the following would work, but it doesn't:

Actually, because this script is loading tiny_mce.js and I have to load it again in the full template, the two instances were conflicting. When I added this script to the ezjscore require statement along with jquery in both the full template and ezxmltext_ezoe.tpl, the editor worked. Note that it also worked substituting tiny_mce_jquery.js for tiny_mce.js which is more direct and might be preferable, I'm not sure. Both work.

I created an override for ezxmltext_ezoe.tpl, deleted the above script and added it to the require statement:

It's also quite nice to have the remove dialogue in place rather than loading a new page and you can use the same code as above, just add the onclick attribute to the remove button. Also add these redirects:

It turns out that the editor will only load when the site access is set to DevelopmentMode=enabled. I've tried adding {set-block scope=global variable=cache_ttl}0{/set-block} to all the templates involved and that had no effect. In the debug console I get two failed get requests tinyMCE js files, one for the langs and one for the theme. The script is using a base URI that is relative to the page URL rather than the actual location of the files.

Does anyone have any suggestions? I'd rather not leave my site in DevelopMode!