Hi Marcus,

Due to inactivity, I am closing the ticket and the respective PR.
Please feel free to reopen it in case of questions or you want to continue to work on.

Best regards,
Yana

Hi Yana,
Please reopen the ticket. I'm working on some other things right now, but I'm going to try your suggestion after that and follow up on the result.
Regards, Marcus

Hi Marcus,

Great to hear, please let me know in case you have issues/questions.

Best regards,
Yana

Hi Yana,

Your suggested workaround does indeed work. I've created a pull request: https://github.com/camunda/camunda-bpm-platform/pull/496.

Regards, Marcus

Hi Marcus,

Thank you for your contribution.
I assume you were able to build the wanted custom form handler, am I right?
I will check the provided PR and merge it in case all look good.

Best regards,
Yana

Hi marcusk,

I merged the provided PR.
Do you still have some questions regarding the topic or we can close the ticket?

Best regards,
Yana

Hi Yana,

Indeed, in combination with the workarounds this enables us to use our custom form handlers. Thank you!

However to be totally honest with you I am a bit disappointed in how this issue was handled. My impression is that we agree on the shortcomings of the old (/current) implementation. Still, I sense a lot of resistance to just fixing these problems, and I don’t understand why. Instead we have workarounds now, and I’m happy these worked for us, but the end result is a situation that is still not very intuitive nor maintainable. Your reasons for not accepting the more structural solution I offered earlier are not clear to me. You said previously it’s about “structure and pattern”, but this is exactly the area that it would improve, in my opinion. I do understand the concern of changes having unintended consequences to existing users, which is why I'd be happy to extend my unit tests with additional verifications.

I have put quite some effort into trying to communicate my experience with using a feature of Camunda (in this case: custom form handlers) from a fresh perspective. Such a perspective can be valuable because as developers we risk becoming so deeply entrenched in our system that we can lose sight of how unintuitive some parts of it may be. When that happens feedback from someone else could be used to ultimately everyone's benefit. At this point, I’m not sure how to proceed with the next issue I find (in fact I’ve already found a fairly obscure one). Should I report it and try to fix it, or just look for a workaround?

What is your perspective on this? Is there anything I should do differently next time?

Best regards, Marcus

Hello Marcus,

We are sorry for any frustration the handling of your contribution may have caused. When we make changes in the product, we often face the decision between a small fix and a larger fix that may introduce more structure. Usually we make these decisions very carefully, taking into account factors such as backwards compatiblity of our API, behavioral compatibility of non-API extension points, complexity of implementation, benefits of introducing new concepts, etc.

In the case we have discussed here, we are talking about extension points of the process engine that are not part of the public API. That means, these hooking points are not guaranteed to remain backwards compatible, are not as extensively tested, and we do not guarantee a particular, documented behavior. In this light, all solutions discussed in this ticket are generally valid. In order to decide for the best solution, we must take the factors mentioned above into account.

In the case of BPMN parse listeners, the principle we want to maintain is that the parse listener has the "last say" on a parsed element. That means, in the first step the Camunda parser does its thing and then a parse listener can modify the parsed element. The Camunda parser should then no longer overwrite any of that.

This was previously not the case for start events, but is now thanks to your pull request https://github.com/camunda/camunda-bpm-platform/pull/496. However, we decided against the bigger implementation provided in https://github.com/camunda/camunda-bpm-platform/pull/444, because it somewhat violates this principle. With the proposed change of PR 444, at the time of invoking the parse listener, the form handler would not yet be fully initialized (since #parseConfiguration is not yet called).

We see two use cases for parse listeners here:

1. The use case discussed in this ticket: Replacing the form handler and then have the #parseConfiguration method be called by the parser.
2. A parse listener that wants to modify a form handler defined in a BPMN model.

In our opinion, these two use cases collide. Use case 2 requires that the form handler is already fully initialized at the time when the parse listener is invoked, if the parse listener depends on the configuration in the BPMN. In consequence, we preferred to keep the existing behavior to avoid breaking such use cases and to stick with the above-mentioned principle.

All that said, we agree that form handling, as well as the parse listener and the parser itself have room for improvement. They are software components that have grown over the years, and being non-API code, have had not such a strong conceptual foundation as other parts of our software have. We are open for suggestions and want to encourage you to raise them. Even if we do not immediately go for a bigger change, it is important for us to be aware of your use cases. For example, if we gather evidence that this is relevant for more people, we would be more confident in making bigger changes, or could even consider creating an API feature with a more solid design and the corresponding guarantees.

I hope our position is understandable. Please let us know if you have further questions or remarks. Once more, we are sorry for any disappointments you have experienced.

Best regards,
Yana & Thorben

Thank you Thorben and Yana for your comprehensive and clear explanation! I can see now that your decision was indeed careful and well thought-out.

You are right. I had not fully considered the 2nd use case. For both use cases to work, it seems to me that the form handler must be initialised (through #parseConfiguration) _before _the parse listeners are invoked (as is done currently) and then once more when it is detected that the parse listener has replaced it, which would become rather complicated.

I also had not realised this functionality was not considered part of the public API.

Best regards, Marcus

Hi Marcus,

It's great that we were able to clarify everything.
Hereby I am closing the ticket.

Best regards,
Yana