Enterprise form pluggable behavior

Hello!

I’m currently developing an enterprise form with a custom, pluggable behavior. It is an implementation of OnValidationSuccessBehavior. The form behaves as expected when mapped to a standalone page via a sitemap item, but if I inject said form into another document using the channel editor, the custom behavior is not called anymore.

I have had a look into the AutoDetectFormComponent, which is used in this scenario, and I have noticed that it has a hard-coded list of behaviors that are then assigned to the form if enabled.

Do you have any recommendations or suggestions for what I might try in order to be able to add a form using the channel editor and keeping all of its behaviors?

Thanks,
Alex

Hi Alex,

You can override protected method
AutoDetectFormComponent#getAutoDetectBehaviors and configure your extension class in the place where AutoDetectFormComponent is.

HTH
Jeroen

Hi @jeroen.hoffman,

Thank you very much for your suggestion. That seems to have done the trick.
However, I’m encountering a different issue now. In my above-mentioned scenario, does the page into which I’m injecting the form need to be mapped to an extension of EformComponent Java class?

EDIT: I have tried extending EformComponent from my main Java component, but to no avail. I am still getting a 404 on the form submission POST request. Any ideas as to why this is happening?

Thanks and regards,
Alex

Hi Alex,
First, I see now that besides extending the AutoDetectFormComponent class you can also add your custom behavior to the component using the ‘behaviors’ HST parameter.

Second, 404 is not expected if you drop AutoDetectFormComponent (or an extension) on the page and use a POST and action URL like so:

<@hst.actionURL var="actionLink"/>
<form action="${actionLink}" method="post">

The URL should map to the existing site map item and trigger the doAction of the component.

Jeroen

Hi Jeroen,

I double checked my configuration. The main component (i.e. the base page into which I’m dropping the form) is NOT extending EformComponent, it is a basic extension of BaseHstComponent. The referenced container item (the form) uses my custom extension of AutoDetectFormComponent. In terms of Freemarker, the form uses the above code you have mentioned for submission.

This is quite similar to the eforms demo project. I have checked with the debugger and the doAction method on my custom extension of AutoDetectFormComponent is not called. I would imagine this is a direct result of the 404. However, the addConfiguredBehaviors method (as are the other “set-up” methods) is called.

I think it’s worth mentioning that my AutoDetectFormComponent extension is only overriding the getAutoDetectBehaviors method. Should I have overridden another one as well?

Thanks,
Alex

Your main (page) component doesn’t need to change it seems.

I was thinking maybe you need to override #getFormBean method but if the doAction doesn’t get called at all that won’t help… That needs to happen so maybe there’s some other component doing a 404? Something in the logs?

Jeroen

No application logs on submission. The only log I see is the 404 on the POST to

http://localhost:8080/site/general/sign-up?_hn:type=resource&_hn:ref=r73_r1_r1_r1&_hn:rid=validation

That is the URL of my main page, into which I’m dropping the form.

You should have _hn:type=action instead of _hn:type=resource! Maybe you’ve used @hst.resourceURL, not actionURL?

(edit) or the validation part can be resource URL, the validation blocks submission

I am using @hst.actionURL for form submission.

But yes, I can see that the validation url uses <@hst.resourceURL escapeXml=false resourceId="validation"/>

Looks like the actionURL POST isn’t done because the validation resourceURL isn’t good, blocking further Javascript executing? Don’t know why. I don’t know your front-end, maybe you can proceed without resourceURLs for validation? Doing that fully client side is also possible.

Good information thanks for sharing
vmware