26 Oct
2011
26 Oct
'11
6:42 p.m.
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:
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)
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
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.
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.
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
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