[xwiki-devs] [proposal] Develop form, field, and validation constraint classes and abandon the practice of storing form information in the class.
Hi, I would like to propose a change in direction. I think the practice of marrying form fields to class properties should be discontinued. Including form information in the class property makes certain jobs easier but XObjects do not always represent forms and marrying something as high level as forms with something as low level as objects makes code maintenance exceedingly difficult, not to mention the general ugliness of code in xwiki-core which generates HTML. I would like to start development of 3 new XWikiDocuments: XWiki.FormClass, XWiki.FormFieldClass and XWiki.FormFieldConstraintClass. Much of the code in XWiki.Registration will be ported to these classes. The fields will be validated twice, once at the client side with LiveValidation, and once at the server side. I would then like to deprecate the use of the display related settings in the class editor and eventually remove them from the class editor entirely. I envision a form being made and fields added similar to the way we add objects to a document. Likewise, each field will be defined by selecting a display type from a predefined list then adding validation constraint objects to the field. I have not started development on this and I am sure there will be plenty more to discuss later. What I want to know is whether people think this is the right direction. WDYT? Caleb
Hi, On Wed, Sep 8, 2010 at 14:18, Caleb James DeLisle <[email protected]>wrote:
Hi, I would like to propose a change in direction.
I think the practice of marrying form fields to class properties should be discontinued. Including form information in the class property makes certain jobs easier but XObjects do not always represent forms and marrying something as high level as forms with something as low level as objects makes code maintenance exceedingly difficult, not to mention the general ugliness of code in xwiki-core which generates HTML.
I would like to start development of 3 new XWikiDocuments: XWiki.FormClass, XWiki.FormFieldClass and XWiki.FormFieldConstraintClass. Much of the code in XWiki.Registration will be ported to these classes. The fields will be validated twice, once at the client side with LiveValidation, and once at the server side.
I would then like to deprecate the use of the display related settings in the class editor and eventually remove them from the class editor entirely.
I envision a form being made and fields added similar to the way we add objects to a document. Likewise, each field will be defined by selecting a display type from a predefined list then adding validation constraint objects to the field.
I have not started development on this and I am sure there will be plenty more to discuss later. What I want to know is whether people think this is the right direction.
WDYT?
Sounds interesting to me. However it represents a very big change with how things are done right now. How would backwards compatibility be handled? Guillaume Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Guillaume Lerouge wrote:
Hi,
On Wed, Sep 8, 2010 at 14:18, Caleb James DeLisle <[email protected]>wrote:
Hi, I would like to propose a change in direction.
I think the practice of marrying form fields to class properties should be discontinued. Including form information in the class property makes certain jobs easier but XObjects do not always represent forms and marrying something as high level as forms with something as low level as objects makes code maintenance exceedingly difficult, not to mention the general ugliness of code in xwiki-core which generates HTML.
I would like to start development of 3 new XWikiDocuments: XWiki.FormClass, XWiki.FormFieldClass and XWiki.FormFieldConstraintClass. Much of the code in XWiki.Registration will be ported to these classes. The fields will be validated twice, once at the client side with LiveValidation, and once at the server side.
I would then like to deprecate the use of the display related settings in the class editor and eventually remove them from the class editor entirely.
I envision a form being made and fields added similar to the way we add objects to a document. Likewise, each field will be defined by selecting a display type from a predefined list then adding validation constraint objects to the field.
I have not started development on this and I am sure there will be plenty more to discuss later. What I want to know is whether people think this is the right direction.
WDYT?
Sounds interesting to me. However it represents a very big change with how things are done right now. How would backwards compatibility be handled?
I think the best option is to just phase the old method out slowly. Once the new method is working and ready for prime time, we can deprecate the old method. After a deprecation period, I would favor removing the controls from the class sheet but leaving the underlying code until the next big change of the object model and database schema (hopefully the change where the database code moves outside of xwiki-core). Caleb
Guillaume
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Sep 8, 2010 at 14:18, Caleb James DeLisle <[email protected]> wrote:
Hi, I would like to propose a change in direction.
I think the practice of marrying form fields to class properties should be discontinued. Including form information in the class property makes certain jobs easier but XObjects do not always represent forms and marrying something as high level as forms with something as low level as objects makes code maintenance exceedingly difficult, not to mention the general ugliness of code in xwiki-core which generates HTML.
Uge +1 on this, I never liked theses display properties that has nothing to do with datas. It should be client job to decide how best displaying/editing datas like we do with the macros and WYSIWYG. IMO it's very important that at some point we have the same kind of descriptors for macro, objects and any other entity with configurable typed parameters. For constraints I wrote some quick design some time ago for the WSIWYG needs on http://dev.xwiki.org/xwiki/bin/view/Design/Propertiesdisplayers.
I would like to start development of 3 new XWikiDocuments: XWiki.FormClass, XWiki.FormFieldClass and XWiki.FormFieldConstraintClass. Much of the code in XWiki.Registration will be ported to these classes. The fields will be validated twice, once at the client side with LiveValidation, and once at the server side.
I would then like to deprecate the use of the display related settings in the class editor and eventually remove them from the class editor entirely.
I envision a form being made and fields added similar to the way we add objects to a document. Likewise, each field will be defined by selecting a display type from a predefined list then adding validation constraint objects to the field.
I have not started development on this and I am sure there will be plenty more to discuss later. What I want to know is whether people think this is the right direction.
WDYT?
Yep this is the right decision and we already started to go this path on the rendering/WYSIWYG side so +1 ;)
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Sep 8, 2010 at 15:24, Thomas Mortagne <[email protected]>wrote:
On Wed, Sep 8, 2010 at 14:18, Caleb James DeLisle <[email protected]> wrote:
Hi, I would like to propose a change in direction.
I think the practice of marrying form fields to class properties should be discontinued. Including form information in the class property makes certain jobs easier but XObjects do not always represent forms and marrying something as high level as forms with something as low level as objects makes code maintenance exceedingly difficult, not to mention the general ugliness of code in xwiki-core which generates HTML.
Uge +1 on this, I never liked theses display properties that has nothing to do with datas. It should be client job to decide how best displaying/editing datas like we do with the macros and WYSIWYG.
Caleb and Thomas, I completely follow you on these points, you have my big +1 as well.
IMO it's very important that at some point we have the same kind of descriptors for macro, objects and any other entity with configurable typed parameters. For constraints I wrote some quick design some time ago for the WSIWYG needs on http://dev.xwiki.org/xwiki/bin/view/Design/Propertiesdisplayers.
I would like to start development of 3 new XWikiDocuments: XWiki.FormClass, XWiki.FormFieldClass and XWiki.FormFieldConstraintClass. Much of the code in XWiki.Registration will be ported to these classes. The fields will be validated twice, once at the client side with LiveValidation, and once at the server side.
This is exactly what I thought when I have first seen that code, that it was more generic than for what it have been written initially. It will require some more tuning and discussion later, but it is a very good starting point for me.
I would then like to deprecate the use of the display related settings in the class editor and eventually remove them from the class editor entirely.
Deprecation will have to be slow to avoid disruption of legacy code, and IMO should not happend until we have a new object Model replacing the old one. Denis
I envision a form being made and fields added similar to the way we add objects to a document. Likewise, each field will be defined by selecting a display type from a predefined list then adding validation constraint objects to the field.
I have not started development on this and I am sure there will be plenty more to discuss later. What I want to know is whether people think this is the right direction.
WDYT?
Yep this is the right decision and we already started to go this path on the rendering/WYSIWYG side so +1 ;)
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (4)
-
Caleb James DeLisle -
Denis Gervalle -
Guillaume Lerouge -
Thomas Mortagne