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