Hi Marius, glad to see progress on this. I just tested it and it's great for a first version :-)
I've been able to add and edit some fields pretty seamlessly, that's very cool! We're moving closer and closer to turning XWiki into the easy-to-use app development platform it longs to be. Please see my other remarks below. On Wed, Oct 26, 2011 at 5:31 PM, Marius Dumitru Florea < [email protected]> wrote: > Hi devs, > > I just committed a prototype of the class editor that will be used by > the Application Within Minutes. If you want to try it out, you can > either checkout the feature-applicationWithinMinutes platform branch > (see > https://github.com/xwiki/xwiki-platform/tree/feature-applicationWithinMinutes/xwiki-platform-core/xwiki-platform-applicationWithinMinutes > ) and build the latest XAR by yourself or you can download the > snapshot I put at http://ubuntuone.com/5dPv28OKz1p3ysY2ypjzrZ . It > requires XWiki Enterprise 3.2+ . Follow this steps after you import > the XAR: > > * choose an existing class or any document if you want to create a new > class > * add an object of type XWiki.DocumentSheetBinding and set the sheet > property to ApplicationWithinMinutes.ClassEditSheet > * edit the class/document in "Inline form" edit mode (simply click on > the Edit button) > > Notes: > > * I only tested the editor on Firefox for now but it should work on > other browsers too > * The "hint" and "required" meta properties are not saved yet. I > included them on the prototype just to show you the direction I'm > going in. > > A few words about the design: > > The class editor is an edit sheet for XWiki documents holding class > definitions. The editor supports only property types described by > FormFieldClass, which are grouped by FormFieldCategoryClass. For > instance ApplicationWithinMinutes.TextArea has an object of type > FormFieldClass which specifies the field icon, category and the list > of meta (configuration) properties that should be displayed. Moreover, > ApplicationWithinMinutes.TextArea holds a class definition with a > single TextArea field that serves as a template for all TextArea > fields added through the class editor. The class editor can store the > default field values in the class template and can generate a basic > class sheet (binding included). > > Open questions and limitations: > > (1) The editor relies heavily on JavaScript. If we're going to replace > the current class editor with the one used by the Application Within > Minutes then we need to decide if it needs to work without JavaScript. > I don't think that's an issue, especially given that users with JavaScript deactivated can always revert to the old interface if needed. The interface is designed as a helper, it does not prevent the core functionality from working so I believe it's an acceptable tradeoff. (2) The editor doesn't save intermediary changes (like the current > editor does when you add a new field or when you delete a field). All > changes are saved when you hit Save. > That's ok for now but I think that for the future it's important that when clicking on the green checkmark a minor save be performed (is that in the plans?). It would be too frustrating to create a long class and have all your work lost due to a browser crash. (3) I don't think the Preview button is really needed because the edit > form already offers a preview of how the sheet will look like > Agreed. (4) The problem with the Save & Continue button is this: the action > servlet filter forwards the request based on the action_* request > parameter. In order to prevent this (because I want to handle the > submit by myself) I renamed the submit buttons to xaction_* but > actionbuttons.js looks explicitly for action_saveandcontinue submit > button, and since it doesn't find it, it doesn't include it in the > POST request parameters, so I don't know the request is a Save & > Continue request. > If step-by-step saving can be implemented (see above), I don't think that's a problem. (5) Because I process the submit myself (i.e. the form action is '') I > need to find a good way to handle errors so that the user doesn't > loose unsaved changes due to an invalid value (e.g. invalid field > name). > Live validation would be a way to achieve that, step-by-step saving as well. (6) Although the UI allows it, you can't really swap the names of two > fields (e.g. rename 'title' to 'description' and 'description' to > 'title'). > Live validation would allow to catch and prevent such cases. Great work! Guillaume > I'm waiting your feedback. > > Thanks, > Marius > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Sales - XWiki SAS Skype: wikibc Office: +33 1 45 42 40 90 Mobile: +33 6 10 79 76 70 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
