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.

Extending the formProperty with access to te rawValue

ronald_van_kuij

As requested by Tom I discuss here why I submitted http://jira.codehaus.org/browse/ACT-602, a request to ADD a getter and setter for the raw value of the formproperty.

Toms first remark was that not all web-ui frameworks can use the java objects. I fully understand this and never said that it should replace the getter and setter of the string typed value. It should be an addition.

Secondly he mentioned that I could use the value of the variable directly. If I do just that and do not use the FormProperty, then I miss all readonly, write only and more things. Besides that, how should I know which value to retrieve since the FormProperty can have a variable reference where the name of the property is different to the name of the variable. So I'd have to use the form property anyhow. And in addition I'd have to write code to parse the variable reference expression etc… I'm totally not in favour of doing all this additional work where it is already done for me in the formProperty handler, the only thing that is missing is exposing this raw value (it is called modelValue internally).

I personally think my arguments are valid hope everybody agrees. I do not want to have to fork the Activiti-engine for this (like the designer)

8-)

Cheers,

Ronald

Find more posts tagged with

Comments

tombaeyens

never said that it should replace the getter and setter of the string typed value. It should be an addition.

That made me see at least a possibility that we can explore further:

Instead of Strings for the form property values, we could expose FormValue objects that contain these properties:
* Object getValue()
* String getTextValue()
* FormProperty getFormProperty() to get the type and other metadata related to the property

Does anyone else have thoughts around this?

frederikherema1

Exposing the value as a FormValue pojo with string/raw value and meta-data accessors looks like a good solution to me. +1

tombaeyens

Ronald, voor ons is t ok om t zo te doen, maar het heeft geen hoge prioriteit. Dus als je t wil, zou jij hiervoor een patch kunnen maken en aan een jira hangen? Je mag em aan 5.4 hangen. Volgende maand kan ik dat nakijken en mergen op trunk als je wil. Aangezien t public API is en dat ook de impact op de huidige form handling ge-impacteerd kan zijn wil ik het zelf nakijken.

ronald_van_kuij

Ok, will make a patch… but are you sure to change it this fundamentally? I agree it is cleaner though

tombaeyens

yes i agree with this change. it's a good improvement. it's not fundamental. we can do it backwards compatible. we can just leave the existing methods and add the methods to expose the PropertyValue.

stroobat

Nice improvement !

njames

Hi,
Did this patch ever get done?
I have the same issue, in that I have some FormProperty variables that are of type date. I am building a REST Web service, sending these FormProperty values as XML. Unfortunately, their String representation from Activiti is *not* in the correct (ISO 8601) form for xsd:dateTime, so I have to parse them using a SimpleDateFormat, then allow JAXB to serialize them correctly. This would be *much* more efficient if I could find a way to access the underlying Date object.