tallence / core-forms Goto Github PK

Hi, ich habe den Form Editor auf CM9 1804.1 integriert und bekomme einen Fehler, wenn ich das Studio Plugin baue.
Anscheinend gibt es enableFocusableContainer nicht mehr, habe es durch das Property focusableContainer ersetzt. Kenne mich leider zu wenig aus um zu wissen was es ausmacht 8 )

Use the following icons for the document type "Formeditor":
https://www.dropbox.com/s/j5w9zfk4ewu66rz/formeditor-icons.zip?dl=0

if you submit a form with some bogus content ids you will get the following npe:

2020-07-24 03:50:11 - [ERROR] org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/blueprint].[dispatcherServlet] [] - Servlet.service() for servlet [dispatcherServlet] in context with path [/blueprint] threw exception [Request processing failed; nested exception is java.lang.NullPointerException] with root cause (http-nio-42180-exec-11) java.lang.NullPointerException: null
at com.tallence.formeditor.cae.FormFreemarkerFacade.parseFormElements(FormFreemarkerFacade.java:48)
at com.tallence.formeditor.cae.handler.FormController.getFormElements(FormController.java:161)
at com.tallence.formeditor.cae.handler.FormController.socialFormAction(FormController.java:100)
...

the FormEditor object is null in that case

This might be useful in many cases especially for the requirements related to gdpr.
The element should render a CheckBox and an explanation text + an optional link.
The field can be mandatory

Hi, I am integrating core-forms-cmcc-11-2301.1.tar.gz into a workspace with cm11 2301.1 and a postgresql 42.5.1 database for the repository. After adding the extension and starting the content-server, I get the following error:

content-management-server | [ERROR] (Init Process) hox.corem.server.Server [] - Cannot startup due to malformed document type definition: Invalid names in document type definition: spamProtectionEnabled, reason is: Invalid property type name: spamProtectionEnabled, aborting

The Content Server Manual, 4.1. states:

Caution

The name can have a maximum length of 18 characters (DateProperty field names only 15 characters) and must not contain umlauts or other special characters ("§", "&", ...). Two fields in a content type different only in upper or lower case are not allowed. Furthermore, a name's last character must not be an underscore, since these field names are reserved for CoreMedia.

"spamProtectionEnabled" is 21 chars long, "pageableFormEnabled" 19 chars, which is too long in both cases. This may work with some databases, but apparently not with postgresql.

As a workaround, I am changing them locally to "spamProtection" and "pageable", since the "Enabled" is implicated in the boolean value... (Replace all in project, preserve case: spamProtectionEnabled -> spamProtection,, pageableFormEnabled -> pageable, don't forget to rebuild studio-client after change - no longer integrated with maven)

Error: Cannot handle multiple versions of the same package in one workspace! Please check dependencies.

core-forms\apps\studio-client\apps\main\form-editor-studio-plugin\package.json
core-forms\apps\studio-client\shared\js\form-editor\package.json

needs Coremedia-Version 2201.2.0 and jangaroo-Version 1.1.1

Should serializeValue() escape Strings that are submitted to the system before sending it out via email?

Just honestly wondering if this is a real issue and if yes where to deal with it. I tested submitting a textfield with html formatted text (<hr>, <a href="test.com">bla</a>) and the (html) email that came back to me, where I just dump the string from serializeFormElements(...) had those elements formatted. Thus I thought huh, someone might put malicious stuff in there and trick my admins/editors receiving the same mail.

I was thinking that serializeValue() for every FormElement should take care to escape the value, since this method is specifically there to serialize for Email usage.

I would probably store the data un-escaped in my DB and deal with escaping when rendering the info on my administration view.

edit: hm lol have to explicitly escape my examples here.. (does that mean it's generally harmless? or does github filter html that's a non-issue..)

Based on the workaround in 3082794

Option of a fields with options (e.g. RadioButton) are serialized in the struct-property in this way:

• The options displayName is used as the name of the structProperty
• The default-behaviour-CheckBox and the optional technicalValue of an option are serialized as Boolean- and String-Properties, below the struct-Property

This has historical reasons and is obviously not good: The options displayValue might contain a lot of characters and (which is the worst) might contains dots. This will lead to a bug: the whole option cannot be edited anymore.

A quick solution could be: Escaping the dot
A better solution would be: serializing the displayName in a stringProperty. The old structure must still be readable, otherwise each project has to perform a content-migration...

Hello @timolemke .

First of all, thanks for your great work and for providing this cool extension in 2301.1 already.

I've tried to merge your current master branch into our project-specific clone and got some merge conflicts regarding the version numbers.

CoreMedia upstream uses version number without minor versions (e.g. 2301.1) for maven dependencies, but with minor versions (e.g. 2301.1.0) for studio modules.

Example:
from https://github.com/tallence/core-forms/blob/master/apps/studio-client/shared/js/form-editor/package.json:

"@coremedia/studio-client.base-models": "2301.1"

vs. https://github.com/coremedia-contributions/coremedia-blueprints-workspace/blob/cmcc-11-2301/apps/studio-client/apps/main/blueprint-forms/package.json:

"@coremedia/studio-client.base-models": "2301.1.0"

What's the idea behind it? Why are you using shorter version numbers than coremedia. Does this work in your environment?

The logic is currently placed in the cae-modules -> It can't be used in the headless-server or the studio-validators. The logic should be moved to a shared-module, which can be used outside the cae.
Dependencies to the contentBeans can be replaced with content-ojects

When expanding the collapsiblePanel of a FormElement the width of the collapsiblePanel might increase. The browser reacts with inserting a horizontal scrollBar into the area with applied formElements. which is not wanted here.

This seems to happen, when there are some more applied formElements which increases the height of the area of applied formElements so that a vertical scrollBar is visible.

See this screenshot:

The Maven command to enable the extension uses the wrong parameter. Instead of -Denable=formeditor-extension it needs to use the folder name used for the git submodule initialization, i.e. -Denable=core-forms

Example:

The extension has to be migrated to the latest CM version, currently: 18.07

The code is currently mostly, but not completely formatted according to the CoreMedia CodeStyle.

There is no Unit Test for the com.tallence.formeditor.cae.handler.FormController.
It can use the already setUp Test infrastructure used for the FormElementFactory Test

If the document is checked out by another user, the forceReadONlyExpression is not evaluated by the formElements CollapsiblePropertyContainer, which can still be dragged. The drop leads to an error, of course.

I wonder if we should add some kind of mechanism to prevent form data from ever being logged (for compliance reasons, if a users needs/wants that).

Dependant Fields are currently restricted to the scope of a single page: a field can be shown depending on another fields value, only if the other field is placed on the same page.

It would be better to remove this restriction as there are many use cases for it.

It would also be nice to be able to make the visibility of pages depend on fields. It would enable editors to hide or show a complete page only if a specific choice was made by the user in the form.

As described here, the manifest.xml is only needed for components which expose as an API to other components. This is not required for this extension -> the manifest.xml can be removed.

See: #9 the comment of @fwienber

Based on the workaround in 9997d73
If an options technical- or displayValue changes, the potential dependant field config of another formElement must be updated accordingly!

The problem:

• A dependant field might reference another field with options (e.g. RadioButtons). If so, it will be visible, if the referenced fields value matches exactly the value which was configured in the dependant field.
• If the options technical- or display-Value of the referenced field is changed by the editor, but the dependant field is not updated, the dependantField will never be shown in the frontend, because the required value cannot be selected by the user.

the regexp validation string entered by editors in studio should be validated. If not validated successful a readable warning or error message should be presented to the editor

In the german form in the tab "Formular Konfiguration" the property group "Formlar-Ziel" is misspelled.

It would be helpful if there was an contextual sorting of input fields.
Text and number are already there but alphabetically sorted they are in different places in list.
It would be more simple to use if every kind of field was sorted together.

My proposal:

• Field - Text
• Field - Number
• Field - EMail
• Field - Phone
  … etc.

So maybe you could sort it after context "field" to have it more easy to find the right component in list. (Especially if the list is getting longer with next versions, hopefully. ;-) )

Thank you very much.

Mit der Umstellung auf Java Configuration anstelle der XML Konfiguration sind die Unittests kaputtgegangen. In diesen wird noch das component-forms.xml referenziert:

Hab ich mir schon eingebaut, aber habe gerade keine Resourcen für Studio um etwas sinvolles als PR bereitzustellen...

in den cae-application.properties ins readme aufnehmen