Hi Guillaume, Thanks for your feedback,
On Wed, Oct 26, 2011 at 7:06 PM, Guillaume Lerouge <[email protected]> wrote: > 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. Well, the question was: On the long run, is it worth keeping two class editors? If not, then is it ok to have a class editor that works only with JavaScript enabled? (assuming we choose to keep only the editor used by the Application Within Minutes) > > (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. I don't plan to make the green check mark save the class. I plan to make the Save & Continue work so that you can choose to save whenever you want, whatever changes you want. > > (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. I prefer to have the Save & Continue working. > > (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. Indeed, but I think some server side checks are still needed so I need to handle server side errors even when live validation is on. > > (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! Thanks! What did you think about the in-place editing of the field pretty name? (same for the hint) Is it intuitive enough? Do you think users might miss it? Thanks, Marius > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
