Hi,
On Wed, Oct 26, 2011 at 6:42 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
  Hi Guillaume,
 Thanks for your feedback,
 On Wed, Oct 26, 2011 at 7:06 PM, Guillaume Lerouge <guillaume(a)xwiki.com>
 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 <
 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. 
 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
 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
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
  _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs