@tisto
Hi Tisto,
I've created a thread for Form Generator in Angular 2 as we have discussed earlier in the GSOC - progressive web app thread. Last couple of days I've worked with Plone installation and familiarized with basic activities with the CMS. However I couldn't install the addons that you mentioned during the discussion.
The error seems to be a compatibility issue and that has been discussed in the following thread.
I'm also getting the same error mentioned above. Can you please show me a way to overcome this.
Their code is Open Source and it works with Angular 2. So it might be worth checking that out. Please keep in mind that we currently do not have a backend implementation on plone.restapi for this. Therefore your proposal would also need at least a specification of how a possible backend could look like. I'm happy to help with the backend implementation. Though, we need a basic idea how this is going to work.
Thank you so much @tisto. I have worked some time with PloneFormGen and easyform addons and I continue the work with them while observing the functionalities, pros and cons on them. I think, I can build an Angular 2 web application with a restAPI to integrate with Plone as a newer Form generator addon. However need some guidance with the backend developments. Since this idea is not mentioned in the idea list, I have limited direction on that. If you can direct me to some references(plone.restapi) I can find a way to develop the backend as well.
How far do I have to describe the backend developments in the proposal.
I think that is something, should the front-end aspects of your proposal be well-thought-out, that mentor(s) and community would be eager (or at least responsive and willing) to help provide consistent direction on.
Much of my Plone work in the past 5 years has been on user-facing form-generation tools used for multi-organization data-collection, storage, and reporting. I am working on a (slightly stalled) project to move most of my form rendering to the client-side, and can offer some anticipated areas of concern/interest:
Determining how field data (and configuration metatdata) is communicated to each widget? Is this something you pass in HTML on a field-by-field basis, or do you send field schema from server to front-end independent of configuration (e.g. use radio widget for single-choice-field 'foo' and select for single-choice-field 'bar').
To what degree do you use, re-use (existing), or re-think just-in-time validation (e.g. AJAX validation prior to submit)?
How do you implement multi-fieldset schemas in JavaScript? At least such that you could have parity with a form designed using plone.schemaeditor (see Dexterity type editor in control panel for example).
How do you represent data in JSON for which native Python/JS serializations don't ship something or agree? E.g. date/datetime.
How do you pass form data on load to a form; and on save? For example, we can assume that on load JSON for data, JSON for schema, and JSON for configuration could be passed into the HTML of a newly-loaded page (each in hidden form inputs). How do you handle saving, normalizing, validation errors?
Do you use local storage for save management to allow retrying a failed save to the server a second time (my users have this because I did not like being the guy responsible for their lost hours of data-entry when their form POST hit the one server instance getting restarted by memmon).
(optional, if you are taking a layout-centric approach to forms)... Can you generate a schema (for storage) from a form designed in a different paradigm (e.g. a visual form editor)? On the server-side, we care so much less about form layouts, but you do need to extract both: (a) a way to save data; (b) a format to persist your layout.
A few key things you would need to get comfortable with:
Writing "browser views" and understanding how they work.
Understanding the relationship (quantities, qualities) of what happens to your data in relation to Plone's content model. Is a content object merely a design for a form and a place to enter+broker it (as in the PFG-inspired model)? Or do you have a single form definition/design used across multiple content items that store your saved data?
Python serialization and marshalling (date/datetime, JSON, collection types).
zope.schema and z3c.form, for reference of what's happening in the server-side world of Plone, a world you hope to supplant somewhat.
I guess the basic idea would be that the backend provides json-schema to auto-generate the form. The plone.restapi @types endpoint already provides json schema.
Vocabularies and/or source info (enumerate static, describe AJAX to get dynamic).
Fieldset groupings.
Layout:
Generated layout (proprietary to some layout engine)
Widget configuration (per field)
Non-field layout components (e.g. rich text instructions in form).
Saved data (to load into widgets).
Other configuration state (e.g. "disable or omit field for this user", date ranges for calendar widget, batching configuration for fields with large vocabularies).
Slightly OT: I would be concerned that JSON Schema is not sufficiently rich enough to have parity with what we can describe in plone.supermodel XML (or some JSON equivalent of this). Having written or maintained two zope.schema knock-offs in JavaScript, I would want to make absolutely sure that JSON Schema was up to each task assigned for serialization/description.
You should also look at plomino with the new advanced_ide branch. Its built in angular 2 and is a full WYSIWYG form editor. The most advanced in plone.
JSON schema is definitely not enough, we either need to enhance the standard (as we already do in plone.restapi and angular2-schema-form) or create a separate "layout" structure/definition as react-jsonschema-form does:
In any case, if we do this as a GSoC project we would have to explore and evaluation the different options. Ideally, that would be included in the student proposal.
Thank you @seanupton for the elaborated explanation on the form generation tools. Most of the things mentioned up there are quite new to me. However it provides me a guidance to dig in deep. [quote="tisto, post:9, topic:3900"]
JSON schema is definitely not enough, we either need to enhance the standard (as we already do in plone.restapi and angular2-schema-form) or create a separate "layout" structure/definition as react-jsonschema-form does:
[/quote]
JSON schema is something I familiar with the Angular 2 developments as well. But if we want to extend the standard or separate the layout structure, it is needed some study on this. I believe in the planning and initiation phase of the project can be dedicated to understand evaluate the best option for the implementation.
Thank you @djay and @petri for the suggestions. I think plomino is a good place to get some idea as it is built with Angular 2.
Since we are so close to application deadlines I'm looking forward to know in what extent should I explain the technical details in my proposal. Though I was little late to join with the community, I believe the time prior to coding phase also can be allocated to understand Plone Rest API developments. @cewing@tkimnguyen@tisto Any advice on proposal preparation?
While understanding how the plone backend works, I have prepared a high level architecture with my Angular knowledge.
Form Generation Process
I propose a drag and drop components module which is something similar to collective.EasyForm add-on. Each components may have different type of validation criteria user will allow to customize the validation according to their preferences (eg: text field in to email validation, select option in to IsChecked validation etc.). Once it is done and hit the save button will create a JSON schema of the field set along with the validation criteria. This schema will send to DB through rest API. Rest API will pass the data into relavant end points.
Rendering the created form
Once the form generation is done the site has to render the form from the front end. So the rest API will call the relevant forms from the DB and based on the JSON schema, controllers will generate specific HTML components and pass them to view for rendering. So the form is created according to the user preference and validations are also set accordingly. When the real end users work with the form, a real time validation will be done.
@nick_mib -- a few quick thoughts for you to ponder before the application deadline:
What you have proposed thus far gets you to round trip of persisting the definition of the form, and its display, but some thought should be put into how the data of said form is used by persons entering data:
How is saved state (partially completed or previously saved form) loaded from server into this displayed form?
How is such state represented internally in JavaScript (e.g. the object model for the data, not the form).
How are types not natively handled in JSON represented in transit for the data (e.g. date/datetime)?
Is is possible to support vocabularies where values are distinct from displayed labels (for choice / radio / select fields)? Or is this beyond the scope of trying to handle? The usual case for something like this might be i18n (however, i18n of field labels is often not something needed in many/most user-generated forms, which are usually single-language).
How could saved data be stored in some format that is not JSON? That is: is the only intended target of saving form data to store a blob of JSON or is there intent to create a mapping to server-side (structured) schema?
Can we map certain widget types (client-side, persisted in form definition) to zope.schema field type equivalents? This allows our Python-based server-side storage ideology (if you want to call it that) to play nice with a widget/disiplay-centric form's data, round-trip. Even if this mapping from client-side-widget to server-side-field is not bijective, it seems we might want something that makes the data persist (or be able to be persisted/mapped to) in native Python data structures and types.
ploneconf2017 sprint (21st and 22nd october 2017) I am going to start working on this addon.
My plan will be start making an addon which has basic drag drop support to add different fields in a form. And when done it will save a json schema (similar schema that is useable by angular2-schema-fom). As phase 2 it should render the form using some rest service in angular app.
App will call rest service to get the schema.
App will render using angular2-schema-form.
Please do not kill me if the idea sounds insane!
See you in sprint
Tareq
