[xwiki-devs] Application Within Minutes - Class Editor Prototype
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-applicationWithinMinute... ) 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. (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. (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 (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. (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). (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'). I'm waiting your feedback. Thanks, Marius
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-applicationWithinMinute... ) 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 [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
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-applicationWithinMinute... ) 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)
(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.
(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 [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
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-applicationWithinMinute...
) 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
Very nice Marius. This is great progress. I found a bug with ListClass items and some escaping issue. You can see the issue by editing the default XWiki.XWikiUsers class Ludovic 2011/10/26 Marius Dumitru Florea <[email protected]>
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-applicationWithinMinute... ) 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.
We have a no-JS compatible editor. This one does not need to. You can have a fallback to standard class editing
(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.
You could indeed save on each click on confirming a field
(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
Correct it's useless here. Now when embedded in the AppWithinMinutes app this will be even more relevant.
(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.
You could add it in JS dynamically
(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).
You should have JS validation indeed
(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').
You'll probably need some JS controls of what's allowed and not. That could include field conversions (allowing to convert a field if there is no data yet) Ludovic
I'm waiting your feedback.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
participants (3)
-
Guillaume Lerouge -
Ludovic Dubost -
Marius Dumitru Florea