Multiple forms on a screen ?

Hello,

This is a bit of a novice question I think: I have a common web block that will be appearing on a few different standard create / update pages and I am not sure how to combine the web block with the form on these pages given that they will both have different source aggregates.  If I were placing the input fields on the page without using the web block I would just have them in the form and would add the additional source with joins into the aggregate.  But then I would have to repeat all the logic associated with these related fields on each of the pages, hence the use of the web block.

Should I have two forms on the page, one with the original data and the other with the web block data, or should I just put the web block in the form and populate it through the web block preparation and not be concerned that it is not part of the source aggregate for the form, or is the solution something different ?

Finally a related question: I know there is a function to check if a form is valid before saving the data, but is there a function to check if a form has changed or would this need to be checked attribute by attribute ?

Cheers, Richard.

Solution

Hello Richard,

Working with Forms and Web Blocks have some caveats.

#1 Form Initialization.

Forms are initialized ONLY on page loading. So, if your web block with a form inside is not visible at the time the screen is called, next time you build the web block the Form will be empty. This requires you to add an extra assign in the preparation and force the content inside the Form record.

#2 Form Validation.

If you have a Form in the Screen and a Form in a Web Block (no matter if the WB is inside or outside the Screen Form), the validation will be independent.
The problem is very easy to spot with Client & Server validation. If you submit the PAGE form, only the PAGE Form will be validated. If you submit the WEB BLOCK Form, only it will be validated.

If you submit the PAGE Form using SERVER validation, you will have direct access only to the page form controls & record. Again, no validation will be done to the Web Block Form controls.

This will require you to refresh the web block in a way that you validate the Form IN the preparation, with some extra logic associated to it (the web block content shouldn't be lost in a submit or ajax submit). Another alternative is to click in a hidden button in the Web Block using JavaScript, and here the order of things may have an impact.

#3 Saving Data

Saving data will be a problem. As the Page and the Web Block will be isolated, you will be required to have some sort of workaround when saving data if they must be saved "at the same time, from a unique button/link". Alternatives include using Ajax Refresh refresh the Web Block passing as input parameter information if it is time to save the data, using the "hidden" button to submit the web block form, etc.

But as those actions will be executed from a different request, they will be in a different transaction and this also can be a problem.

The alternative I saw most of the time is to send data from the web block to the parent through notify / event and let the parent validate and save the data. But this has also its own problems and difficulties to deal with.

Conclusion

So, in the end, a lot of factors must be weight before deciding if this approach is really worth (using the web block), or if you can live with some duplication of code and use everything from the page instead of using the Web Block. 

One of the most important factors is probably: "how often will you change this information structure/logic" that makes it easier to keep it in a Web Block (with all the problems related) instead of duplicating the code?

Solution

Regarding your second question.

I am not aware of a function that is able to identify if a form has changed.

The solution that I saw being used is usually the use of JavaScript to identify when an input is changed and keep this information in a hidden input associated with a boolean variable.

You can use this approach both to enable/disable a button as well as to identify if it is necessary to save/update the record.

Cheers.

Eduardo Jauch wrote:

Hello Richard,

Working with Forms and Web Blocks have some caveats.

#1 Form Initialization.

Forms are initialized ONLY on page loading. So, if your web block with a form inside is not visible at the time the screen is called, next time you build the web block the Form will be empty. This requires you to add an extra assign in the preparation and force the content inside the Form record.

#2 Form Validation.

If you have a Form in the Screen and a Form in a Web Block (no matter if the WB is inside or outside the Screen Form), the validation will be independent.
The problem is very easy to spot with Client & Server validation. If you submit the PAGE form, only the PAGE Form will be validated. If you submit the WEB BLOCK Form, only it will be validated.

If you submit the PAGE Form using SERVER validation, you will have direct access only to the page form controls & record. Again, no validation will be done to the Web Block Form controls.

This will require you to refresh the web block in a way that you validate the Form IN the preparation, with some extra logic associated to it (the web block content shouldn't be lost in a submit or ajax submit). Another alternative is to click in a hidden button in the Web Block using JavaScript, and here the order of things may have an impact.

#3 Saving Data

Saving data will be a problem. As the Page and the Web Block will be isolated, you will be required to have some sort of workaround when saving data if they must be saved "at the same time, from a unique button/link". Alternatives include using Ajax Refresh refresh the Web Block passing as input parameter information if it is time to save the data, using the "hidden" button to submit the web block form, etc.

But as those actions will be executed from a different request, they will be in a different transaction and this also can be a problem.

The alternative I saw most of the time is to send data from the web block to the parent through notify / event and let the parent validate and save the data. But this has also its own problems and difficulties to deal with.

Conclusion

So, in the end, a lot of factors must be weight before deciding if this approach is really worth (using the web block), or if you can live with some duplication of code and use everything from the page instead of using the Web Block. 

One of the most important factors is probably: "how often will you change this information structure/logic" that makes it easier to keep it in a Web Block (with all the problems related) instead of duplicating the code?

Thanks for the reply, Eduardo.  Just to be clear, in both the alternatives I put forward I was thinking of putting the web block inside the form, not the form inside the web block.  Not sure if this will make any difference ?

Cheers, Richard.


Hi Richard,

If you have a Form inside the Web Block, no difference.
If the web block does not contain a form itself, it will be harder to validate (Form helps a lot to do this). 

Also, any link/button submitting from inside the block, if set to Client & Server validation, will validate the Page Form, but not the widgets inside it.

In the end, all the problems I pointed before will probably rise in the same.

Cheers.

Hi Eduardo,

I quickly checked out what you were saying by adding the web block to the form and as you said, although it displays and functions just fine (and with correct data) on the screen, when it comes to validation and saving the data the web block fields are not visible to the parent form and save actions.

It is a shame that this capability is not available for web blocks because it would provide a very useful reusability capability.  For now I will just duplicate all the fields, the preparation, and the four 'on change' actions that I had created for the web block.

Cheers, Richard.

Yes. 

It is understandable, for a number of reasons, and I already see this requirement a lot of times. 

People usually use some tricks to be able to use the blocks anyway, but this always make things more complex. Sometimes it is mandatory. 

Cheers 

Hi just a suggestion can't you replicate the form in all the places you need and use a server action to do the server logic in all of the forms when submitted? Instead of encapsulate the form, you encapsulate all the logic behind it.


Just an ideia.

Hi Carlos,

The main point here is that usually what is done in the Screen Action is the validations (business logic should not be tied to the interface anyway). 

Passing the values to server actions to be validated creates a different problem: how to set the inputs Valid / ValidationMessage when the validation failed?

In the end, you will get more code, instead of less code. 

I would say that it is possible to do it with JavaScript and other techniques, but then you are increasing the application complexity for something that is not really worth the effort (usually).

Cheers.

Eduardo Jauch wrote:

Hi Carlos,

The main point here is that usually what is done in the Screen Action is the validations (business logic should not be tied to the interface anyway). 

Passing the values to server actions to be validated creates a different problem: how to set the inputs Valid / ValidationMessage when the validation failed?

In the end, you will get more code, instead of less code. 

I would say that it is possible to do it with JavaScript and other techniques, but then you are increasing the application complexity for something that is not really worth the effort (usually).

Cheers.

Yes you are correct i am sorry i was trying to avoid the webblock problem and forget that you need input validation.


No problem :)

There are alternatives, like have the web block with a hidden link to save data, with a class that you use JavaScript to hit from outside. The same just to check if the inputs are valid.

The problem is always that this will be done in different requests (and transactions).
If one can live with that, it's ok. 

Another way is to use the same technique to "alert" the parent about the data. So you keep the data in the parent. But the validations are still done in the web block.

Cheers.

Hello Richard,

Even some late you can show the Event System ecosystem from forge.

I'm doing some tests with it with some success in these challenges.

Hope it can help you.