Hi, On Wed, Oct 26, 2011 at 6:42 PM, Marius Dumitru Florea < [email protected]> wrote:
> 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) > The old version will always work as it does now without JavaScript, I don't see anything in the new implementation that would break the old one or prevent from using as a fallback when JS isn't enabled. > > (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. > That's another option. What I like with background saving is that it removes some cognitive workload off the user (they don't have to think explicitly about saving anymore). > > (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. > See my answer above. > > (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. > Yes, both are needed. What's important is that the user doesn't lose any data even if the submitted form has some incorrect values. > (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? > I missed at first but tried double-clicking on it and saw it worked, so to me it was intuitive enough. Guillaume 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
