cancel
Showing results for 
Search instead for 
Did you mean: 

Extending the formProperty with access to te rawValue

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
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) Smiley Very Happy  :lol:  8-)

Cheers,

Ronald
7 REPLIES 7

tombaeyens
Champ in-the-making
Champ in-the-making
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
Star Contributor
Star Contributor
Exposing the value as a FormValue pojo with string/raw value and meta-data accessors looks like a good solution to me. +1 Smiley Wink

tombaeyens
Champ in-the-making
Champ in-the-making
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
Champ on-the-rise
Champ on-the-rise
Ok, will make a patch… but are you sure to change it this fundamentally? I agree it is cleaner though

tombaeyens
Champ in-the-making
Champ in-the-making
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
Champ in-the-making
Champ in-the-making
Nice improvement !

njames
Champ in-the-making
Champ in-the-making
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.
Getting started

Tags


Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.