nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

UserTask w.form:best practice to define the custom attribute

udoderk

Hello everybody, I try the currently described here steps for development of the user tasks with custom GUI mask elements with validators.
It seems to work when the custom form type/Custom form renderer not needs the additional informations to validate. However, if I need such additional informations to validate (for example, to validate the length of the input symbols. The max length must be determined into BPMN xml file within "formProperty" element) , currently i looking at the best practicies to implement it without deep changing of the original Activiti Explorer sources.
I have some idea with deep changing: e.g.
1. extend the schema definition for activiti-bpmn-extensions (activiti-bpmn-extensions-5.10.xsd file) : define additional attribute "settings" with type "string"
2. Serialize the JavaBean, that contains needed information for validation and set it to "settings"
3. and then patch/extend the formTypes class (parseFormPropertyType() method to desirialize the JavaBean from parsed "settings" string and to initialize the custom form type with those JavaBean.
…

But such solution is not a lightweight solution :roll: (imho)
I'm seeking for best practices to realize it.

Thank You for goood ideas 8-)

Find more posts tagged with

Comments

jbarrez

Did you check the org.activiti.explorer.form.UserFormType example.
I'm not 100% sure, but I do seem to remember it supports validation through exceptions.

udoderk

Did you check the org.activiti.explorer.form.UserFormType example.
I'm not 100% sure, but I do seem to remember it supports validation through exceptions.

Hi jbarrez,
Thank You for feedback:-)
i checked UserFormType / UserFormRenderer and some other types. But i need anyway the parameters, that determine for example the MAX or MIN bounds and that are not a fix values (In other word i could not that "hardcoded" define it into Validator class of Activiti )
Currently i use the "name" attribute to transfer the JSON serialized JavaBean as XML escaped string, that is desirialized on Activiti side….The steps, that described on start-topic are too heavily fo me

jbarrez

Probably a better solution would be to enhance the form property with a 'validation expression' or a 'validation Java class'.
However, the question is: what would the engine then do upon entering the form properties? Would it simply throw an exception?
In nowadays web apps, you want the validation to be instant, so you'd need a duplication of those validation on the client side anyway …
But it might be a good addition to the form api, nonetheless …

udoderk

Hi jbarrez,

Of course, the better solution is to extend the form property with the additional attributes/subelements. Such solution would be the really clean solution.

In such case, it's needed to enhance both XSD and to define a new Java interface, or to extend the existing FormProperty interface (Late solution that can be employed, however, only when a new release with incompatible changes would). (For example the new Getter would be "getAdditionalAttribute"
So that method could be used within the mehtod "Field getPropertyField(FormProperty formProperty)" of the custom renderer, that inherits the AbstractFormPropertyRenderer. Thus it woulde be possible, to transfer the needed for validation parameter into the custom validator.
Furthermore, the custom validator would be used that transfered parameters within isValidString() method during parsing of input value. If not valid value would be entered, so the isValid returns the "false", and the InvalidValueException with given message would be thrown.

The AbstractFormType must not have the additional methods, because the it is quite enough, throw the exception in custom form type, if the wrong type is used.

The problem of such clean solution, however, is that the core API must be adapted. If this is done not in the context of extensions through "standard" activiti team, so it must always do the merge. if, the new relase of activiti comes….

jbarrez

yup, I agree with what you're saying.

Reviewing the forms is something that we plan to do in the near future. And validation will indeed be an important part of it.

ronald_van_kuij

Finally… XForms….

jbarrez

I just knew that one was coming 😉

Actually, I checked out Orbeon last week. But I wasn't convinced: the syntax feel heavy and the editors don't seem to be mature.
If anything like http://wufoo.com/ existed in open source … I would be sold immediately!

udoderk

yup, I agree with what you're saying.

Reviewing the forms is something that we plan to do in the near future. And validation will indeed be an important part of it.

Thanks for the info :ugeek:

udoderk

I just knew that one was coming 😉

Actually, I checked out Orbeon last week. But I wasn't convinced: the syntax feel heavy and the editors don't seem to be mature.
If anything like http://wufoo.com/ existed in open source … I would be sold immediately!

You've already done a lot, as you have used the Vaadin framework to develop the Activiti Explorer webapp.
P.S. The simple forms can already created with the Vaadin Visual Editor.

jbarrez

Absolutely, but I'm no fan of visual tools (call me old fashioned), but I see people being productive in them so I might need to revise that stand 😉