ognl or binding issue like, everything, following, something

amy

I have got everything setup in 2.0 and I am very excited to use flow inheritance and many of the other new things added. I did notice something that seemed a little strange and wanted to mention it to see if anyone had any insight as to why this would be happening.

All of my inputs for a page have a path similar to the following:

Code:
lt;form:input path=quot;w[${key1}][${key2}].valuequot; /gt;
That worked fine before the upgrade. Now if I keep it like that I get the following error:

Code:
- [EvaluationAttempt@15cd9a expression = w[PRI][XT_HOME_TYPE].value, context = FormData] failed - make sure the expression is evaluatable in the context provided
org..binding.expression.PropertyNotFoundException: [EvaluationAttempt@15cd9a expression = w[PRI][XT_HOME_TYPE].value, context = FormData failed - make sure the expression is evaluatable in the context provided       at org..binding.expression.ognl.OgnlExpression.getValue(OgnlExpression.java:89)       at org..webflow.mvc.view.BindingModel.getFormattedValue(BindingModel.java:138)       at org..webflow.mvc.view.BindingModel.getFieldValue(BindingModel.java:118)
I played around with it and got it to work as long as I put single quotes around the keys as follows:

Code:
lt;form:input path=quot;w['${key1}']['${key2}'].valuequot; /gt;
This works fine. The problem is all my javascript now needs to be re-written because if I put the single quotes in the source looks like this:Code:
lt;input id=quot;w'PRI''XT_NAME'.valuequot; name=quot;w['PRI']['XT_NAME'].valuequot;...
instead of this (the way it used to look when I didn't have the quotes and didn't upgrade)Code:
lt;input id=quot;w[PRI][XT_NAME].valuequot; name=quot;w[PRI][XT_NAME].valuequot; ...
I am using the same ognl jar that I had before the upgrade (ognl-2.6.9.jar). Perhaps one of the jars I am using has a different ognl jar...but I don't know why that would be, here are the other jars in my lib dir (org..binding-2.0.0.RELEASE.jar, org..js-2.0.0.RELEASE.jar, org..webflow-2.0.0.RELEASE.jar, spring.jar, spring-webmvc.jar)

Does anyone have any ideas?

This is most likely due to different semantics between OGNL and Spring's BeanWrapper. In Spring Web Flow 1.0.5, Spring's BeanWrapper machinery was used for data binding.  In Spring Web Flow 2, it is still used when using the old-style FormAction, but for the new (and now recommended) style of declarative model binding/validation, the underlying EL is used for binding--OGNL in your case.

I'm curious to hear more about how come you're having to change all your javascript.  Would it be better to set a logical id for those DOM form elements in the long term?

Keith

As usual thanks for the quick response Keith. Originally Posted by Keith DonaldThis is most likely due to different semantics between OGNL and Spring's BeanWrapper. In Spring Web Flow 1.0.5, Spring's BeanWrapper machinery was used for data binding.  In Spring Web Flow 2, it is still used when using the old-style FormAction, but for the new (and now recommended) style of declarative model binding/validation, the underlying EL is used for binding--OGNL in your case.

I want to use the new and now recommended style, so if I understand you correctly OGNL would have never let me use:
Code:
lt;form:input path=quot;w[${key1}][${key2}].valuequot; /gt;
and it only worked because the BeanWrapper was not as strict?

Originally Posted by Keith DonaldI'm curious to hear more about how come you're having to change all your javascript.

Currently, depending on the circumstance we use either document[formName][objName] or document.getElementById(objId) to get the form element. Either way it will be different if I have to add single quotes to the fields.Originally Posted by Keith DonaldWould it be better to set a logical id for those DOM form elements in the long term?

Please explain what you mean by quot;set a logical id for those DOM form elementsquot;. It seems logical to me, but I am VERY open to suggestions. Our form backing object has a HashMap of HashMap of elements. The first HashMap 'w' is a map of containers of data. Each container is a map that holds different inputs from the user. The inputs change from time to time and therefore can't be you typical simple bean properties. Perhaps I am just misunderstanding what you mean by logical id. Let me know.

I want to use the new and now recommended style, so if I understand you correctly OGNL would have never let me use:
Code:
lt;form:input path=quot;w[${key1}][${key2}].valuequot; /gt;
and it only worked because the BeanWrapper was not as strict?

Yes, you said it.  Would you mind creating a JIRA so we can be sure to add a note about this to the migration guide for 2.0.1?

I've pointed Jeremy to this thread to take a look at your Javascript issue - lets see if we can make some suggestions there.

Keith


Originally Posted by Keith Donald

Would you mind creating a JIRA so we can be sure to add a note about this to the migration guide for 2.0.1?

Done SWF-670Originally Posted by Keith DonaldI've pointed Jeremy to this thread to take a look at your Javascript issue - lets see if we can make some suggestions there.

Do you know of a different EL parser that might work? Just curious if OGNL tends to be more strict than others.

You might want to consider moving to the Unified EL syntax. However, the only Unified EL implementation suitable for SWF's needs and available at present is jboss-el.  When you do include that jar in your classpath, it'll get used automatically...

In general, I think the Unified EL syntax is the future for a base EL syntax.  Spring EL will also be around the corner fully supporting it and providing several nice extensions... watch for that.

Keith

It sounds to me like the simplest thing in the short term, to avoid having to change your JavaScript code (especially since things could get really ugly if you've got single quotes in the form element id's) would be to explicitly set the id attribute on each tag.  The path expression is the only one that uses the binding machinery (and thus OGNL) for resolution.  If you had a similar expression in the id attribute, you would not need the single quotes because JSP's EL will be doing the evaluation in that case, and only the delimited parts will be evaluated.  So you could potentially use:Code:
lt;form:input id=quot;w[${key1}][${key2}].valuequot; path=quot;w['${key1}']['${key2}'].valuequot; /gt;
Then your JavaScript would not have to change, though you would have to go through and do this for each form element.  

Ultimately, I would recommend keeping the element id's a bit simpler.  I would tend to prefer something like:Code:
lt;form:input id=quot;w_${key1}_${key2}quot; path=quot;w['${key1}']['${key2}'].valuequot; /gt;
Which would still give the elements unique id's that match up logically to your backing HashMap structure but would be a bit cleaner to work with in JavaScript.

I agree about the id format, but the majority of our javascript uses document[formName][objName] in order to get the correct object from a form element. Is it possible to remove the single quotes from the name field when printing them out to the page. It seems like you wouldnt want to have the quotes in the forms name field anyway. What do you think?

Jeremy? Is there any reason to keep the single quotes in the name of the form element? I can't think of a reason (but that certainly doesn't mean there isn't one), it just seems cleaner to me not to have them.

I agree, it would be cleaner on the client-side.  Unfortunately I don't believe the Spring form tags allow you to explicitly set the name.  This makes sense actually, because the name is what determines the request parameter used to submit the form value back to the server.  I believe the binding machinery needs this parameter to be the same as the path so that it can bind correctly.