GREY Proposal for an improved Form moduleGREYAllow building web applications with a better, more flexible form module in Magnolia. NEEDS REVIEW
Rationale
Forms before Magnolia 4 are very basic. The 4.0 release of Magnolia adds a form module with some added functionality, however it is still a basic form handler aimed to send emails.
An extended form handler should allow a content editor and a developer to create a form based application within Magnolia and then tie the application to a backend for further application handling. This type of form building should allow Magnolia to break out of the web content management into a content platform targeted for easy web application building.
Goals of an advanced form module:
- multi page form handler (support of rules to enable pages in a flow)
- multiple forms per page support
- conditional fields (enable/disable fields based on other fields or conditions)
- choices driven from repository (data or configuration), adapters or inline data
- a form is considered one paragraph and edited at once (easier editing)
- drag and drop form creation (multi row capable)
- file upload is working even if there is an error (direct upload, tracking of time to upload)
- AJAX support for related changes on the screen according to a selection
- wysiwyg multiline text editing
- error messages customized per field
- row based and field/label based rules
- simple data structure for rendering purpose with different frameworks
- list editing (repeating sections for multi row data entries)
- client and server side field validation
The form handling is intended to provide an abstract base for any type of module needing forms on a website. An example module could be a contact module logging and reporting all contacts in the data module and preparing the information for reporting and export (emails for mailing list for example).
The ideas listed above are taken from the work that went intohttp://www.cbciplan.comand other form based projects implemented with Magnolia. The form handling within the exposed web site should be at least as good if not better than the form handling used within the management console for the CMS.
Overview
Content Tools
11 Comments
Boris Kraft
Actually, the 4.0 Form module is not restricted to send emails. It has a pluggable processor that allows you to do anything with the submitted form values (like adding them to Salesforce, maybe?). The current implementation uses the mail module to send mails, and/or logs the data using standard logging.
However, that is still a long way off from what you describe.
Magnolia International
Yup, a processor that pushes stuff to salesforce should be doable; i assume they have a decent api
A bunch of the features described above are, it seems, clear improvements or additions on the existing (new) form module; others are more novel. It would help to sort those out and somehow investigate what would be needed for both.
Ruben Reusser
It may help if we go with a set of requirements for a target application - so here we go with a couple of apps one might want to write in magnolia, maybe we can agree on what we shold be able to build in magnolia and then derive the requirments from that:
These are all use cases from a website visitors perspective, not from an editor or administrators perspective that uses magnolia and is familiar with it.
Magnolia International
forum and public user registration modules: well, that's simply historical, they were created long before the form module.
Ruben Reusser
would be nice to 'practice what you preach' for consistancy reasons
Magnolia International
that is planned; time isn't elastic in here. Feel free to jump in.
Ruben Reusser
If only things would not change every time a major release comes out - what's the best strategy to contribute something that will be still working in 5 and be alligned with the basic concept of 5?
Jan Haderka
It's not like everything changes between the releases. The API changes are deprecated in one major release and removed only in another. Besides it was 9 months between first final of 3.6 and first final of 4.0 releases, with plenty of milestones and RCs before so you could see what is coming.
If you contribute something back to modules maintained by us, then we make sure when changing anything we apply the changes across other modules before releasing them.
If you want to build your own module and keep it in sync, then have an automated build, that will rebuild your module against latest trunk code of Magnolia on every commit or at least once a day. This way you can see the changes coming in small increments and it is easy to apply the changes as they come.
Ruben Reusser
I actually was not talking so much about the code but about the best practice on how to use magnolia and keeping up with it - in order to contribute a good form module to magnolia it would have to be a first class citizen in an upcoming magnolia (such as 5). If we would go with a drag and drop editor for the forms it probably would be good to use the same technology as Magnolia 5 will use. And it probably should be done with the same templating language as the STK. From a users perspetive magnolia is great but the paradigms that are pushed seem to shift quite a bit from major release to major release.
Philipp Bärfuss
The 'old' forms were bare samples and in reality not that useful so we dared to replace them with something more decent. By default we deliver the following processors: email, confirmation email, logging. The newsletter module (not released yet) uses this form module exemplarily.
The module is not at all a replacement for using spring or similar frameworks and hence limited to the basics:
Ruben Reusser
Thank you very much for the assessment. The question becomes: would magnolia be interested to have a more complex form infrastructure - we have our current solution that we use for some of our sites. We are thinking of adding a wysiwyg editor to our form module to make it easier to configure and at the end of the day are willing to contribute that code to magnolia. The question becomes - what approach should be taken and is there interest/other needs that we do not currently handle in our solution or is magnolia prefering this to be handled in 3rd party frameworks such as spring.