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 <
mariusdumitru.florea(a)xwiki.com> 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-applicationWithinMinut…
 ) 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
 devs(a)xwiki.org
 
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