[FORMDB-5] Form2dbProcessor fails to store form data because of unsupported form parameters set by SendConfirmationEMailProcessor Created: 05/Nov/14  Updated: 18/Dec/14

Status: Open
Project: Form2DB App
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Edgar Vonk Assignee: Marvin Kerkhoff
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2014-11-05 at 12.19.39.png     PNG File Screen Shot 2014-11-05 at 12.24.03.png     PNG File Screen Shot 2014-11-05 at 12.35.48.png    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

In our project the Form2dbProcessor fails to work. The issue seems to be that not all of the form parameters can be transformed into Magnolia properties using PropertyUtil.setProperty. This results in a IllegalArgumentException which is run time exception and is not caught or logged anywhere so is completely lost.

When I look at the list of form parameters there a couple of 'internal / system' parameters not set by our code but I guess by the Magnolia Form Module itself which cannot be converted into properties. The first one of these is a parameter called '_FreeMarkerServlet.Request_'. I have no idea why these parameters are set but I guess this is an internal Magnolia Form Module thing. See screenshots attached.

I guess the solution would be to either first check if a parameter value is of a supported type and if not skip it, or catch the IllegalArgumentException specifically for the call to PropertyUtil.setProperty but that seems a bit dirty to me.

Our form in this case is a (somewhat) custom form that extends from the default /modules/form/templates/components/form. Nothing special there. See screenshot of the form component model configuration. We use Magnolia 5.3.4.

I can hardly imagine that the processor does work for plain Magnolia 5.3.4 forms? I will check.



 Comments   
Comment by Edgar Vonk [ 05/Nov/14 ]

The reason for all those form parameters is that the parameters method argument in #internalProcess is a non-final Map to which other form processors that come earlier in the chain can and do add all sorts of custom parameters (passing on stuff through method arguments is very ugly if you ask me and should be avoided where possible). E.g. we use Magnolia's SendConfirmationEMailProcessor which adds stuff there. E.g.:

  parameters.put("templateFile", PropertyUtil.getString(content, "confirmContentTypepage"));

I have now switched orders of the two form processors that we use so that Form2dbProcessor is processed first (and our customised version of SendConfirmationEMailProcessor comes second) and now the Form2dbProcessor does work.

However I do suggest to make the processor more robust as mentioned above. Ideally you would even want to be able to configure the form2db module (or even your specific form) by being able to specify exactly which form fields (i.e. parameters) should be stored by the module but that would be a new feature request.

Comment by Edgar Vonk [ 05/Nov/14 ]

Sorry my mistake. The workaround that I described in changing the order of the form processors does not work. There is no order I now understand. It was just just by luck that the second time I tried it (after a restart) that the Form2dbProcessor came first and the SendConfirmationEMailProcessor came second. When I completely disable the SendConfirmationEMailProcessor the Form2dbProcessor works fine and the only form parameters present are the form fields themselves (as I would expect).

So you could make a point in saying that the issue is also in the SendConfirmationEMailProcessor which adds a bunch of custom stuff to the parameters Map (undocumented btw) which causes issues for other form processors like yours but it will not be easy to solve that I'm afraid. This seems to be done to pass parameters from the email form processor to the email FTL template. An ugly way to do this if you ask me but maybe done for a reason.

Comment by Marvin Kerkhoff [ 18/Dec/14 ]

I used the module for some of our client projects, also with more complicated modules and file upload. At the moment i never found that issues. Can you explain if you figured out the problem or if it is only a problem of your custom installation?

Generated at Mon Feb 12 01:58:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.