In a flow definition, I am trying to access a bean that has a dot in its ID
(example: <evaluate expression="bus.MyServiceFacade.someAction()" />
However, it does not work. SWF tries to find a bean "bus" instead.
Initially, I got over it by using a helper bean to load the required bean, but the solution is inelegant and uncomfortable. The use of alias'es is also out of the question since the beans are part of a large system and I cannot tamper with them.
In a nutshell, none of the solution allowed me to refernce the bean directly by using its original name. Is that even possible in the current SWF release?
I was able to do this by using both the bean accessor (#) symbol and single-quotes around the name of the bean.
Using your example: #{#'bus.MyServiceFacade'.someAction()}
This is a restriction of the EL parser (generally either OGNL or jboss-el for Spring Web Flow). EL uses dot notation for parsing the navigation chain,causing the initial behavior you describe (attempting to find the "bus" bean).
Try:
['bus.MyServiceFacade'].someAction()
or
'bus.MyServiceFacade'.someAction()
This may work, or it may not...but similar things are used in the Expression Language for JSPs.
In my experience, anything with a getter method can be accessed via dot notation. In your example, whatever object is being represented by the bus bean needs to have a getServiceFacade method and that the object returned by getServiceFacade would need to have a getSomeAction method.
Related
to use some browser's capability to "autofill" (like "Ah, this input is called 'firstname', let me offer my user all the firstnames he entered elsewhere"), we would like to at least (since the id is random anyway) set the name attribute of the input fields. Unfortunately, the documentation of InputElement.setName says...
Don't use this method if your
application is purely based on ZK's
event-driven model.
So, big question: Will this cause somehow troubles if I use this method? Or is there another way to put the name of the input element into the resulting html?
I think the warning in the API is meant to tell you, that ZK does not consider this attribute except of setting it into the rendered html.
Maybe it's there to prevent developers from using name instead of ZK's id property and thus failing to correctly bind components.
I never encountered a problem when using it.
I am new to Spring framework learning Spring mvc and spring web flow . I came across an evaluate expression in action state
<evaluate expression = " requestParameters.ishotelbooking" result="flowScope.hotelbooking" />
Couldn't able to figure it out what is actually happening ?? And one more thing i understand that we are assigning flow scope for hotelbooking object but how the framework understands the hotelbooking is the object of hotel class ie how we can understand the type of object here .. can someone guide me .. Thanks in advance 😊
This evaluate expression is taking the "isHotelBooking" request parameter and copying it into a variable "hotelBooking" that will be available in the entire flow (flowScope)
So when the action state is called, probably after a transition, in a request like "flowTransition?isHotelBooking=true" the request parameter "isHotelBooking" is only available in the request. So the evaluate element is copying that into another variable available in the entire flow.
Basically extending the scope of the variable from request to flow scope
FYI this could be replaced by
<set name="flowScope.hotelBooking" value="requestParameter.isHotelBooking"/>
[UPDATE]
For the type, the evaluate element has a result-type attribute that can be used to further define the type of the result. if not specified Webflow assumes it is of type Object.
The class/type is not always important since evaluation is done at runtime and using EL. Although it is useful if you are using an IDE (like IntelliJ or STS) so you can take advantage of auto-completion.
I was reading the Jersey docs about bean validation. The ParameterNameProvider example shows how to define parameter names for a method. However, the implementation looks like this will have to be done for each and every method which obviously doesn't scale. The example is basically useless as is.
Is there a smarter way to do this? Couldn't Jersey infer the name from #QueryParam or #PathParam annotations?
Take a look at the answer in my question here. It should do exactly what you want.
Can I change the property path in a ConstraintValidator for Method arguments?
If you copy my code and run it through a debugger you will see that it is only evaluated once for each method for which it is used. Then during normal running of your app the names will not need to be resolved again.
The Jasper Reports docs is silent on this issue and the JRDataSource interface is not explicitly allowing the access to the current bean. The current bean handle is very useful if you want to call some non property method.
The only solution I've found so far looking in the jasper reports sources is to use a _THIS field in the report and invoke the desired method on it:
${_THIS}.computeSomeValue()
Is there a better, more standard approach?
I usually use a custom_Scriptlet extending the JRDefaultScriptlet (if i ever need any other method calls pertaining to my bean). A better approach i think will be just to gather all data you will ever need (either in your bean as an instance variable with a setter/getter method or passed as a parameter when you fill your report).
This way you can leave the property bean methods take care of the rest.
Try:
$P{REPORT_DATA_SOURCE}.getData().get($V{REPORT_COUNT} - 1)
I got pretty big webflow definition, which I do not want to copy/paste for reusing. There are references to action bean in XML, which is kind natural.
I want to use same flow definiton twice: second time with actions configured differently (inject different implementation of service to it).
Is there easy way to do this?
Problem is I want to use same flow with different beans at once, in the same app. Copy/Paste is bad, but I dont see other solution for now.
You could try creating a new flow that extends the "pretty big one" and adding flowExecutionListeners to it.
The interface "FlowExecutionListener"defines methods for the following events in flow execution:
requestSubmitted
requestProceessed
sessionCreating
sessionStarting
sessionStarted
eventSignaled
transitionExecuting
stateEntering
viewRendered
viewRendering
stateEntered
paused
resuming
sessionEnding
sessionEnded
exceptionThrown
You can write a handler that injects the required resources to your flow (and use different handles with different flows) by storing it in the RequestContext, where you can access it in your flow definition.
Note that in that case you would still have to modify the "pretty big flow" to use those resources instead of referencing the beans directly.
I'm in the same fix that you're in...i have different subclasses which have corresponding action beans, but a lot of the flow is the same. In the past we have just copied and pasted...not happy with that!
I have some ideas I am going to try out with using the expression language. First, I came up with an action bean factory that will return the right action bean to use for a given class, then i can call that factory to set a variable that i can use instead of the hard-coded bean name.
Here's part of the flow:
<action-state id="checkForParams">
<on-entry>
<set name="flowScope.clientKey" value="requestParameters.clientKey"/>
<set name="flowScope.viewReportBean"
value="reportActionFactory.getViewBean(reportUnit)"/>
</on-entry>
<evaluate expression="viewReportBean"/>
The evaluate in the last line would normally refer directly to a bean, but now it refers to the result of the "set" I just did.
Good news--the right bean gets called.
Bad news--anything in the flow scope needs to be Serializable, so I get a NotSerializableException--arggh!
I can try setting something on a very short-lived scope, in which case it will need to get called all the time...or I can figure out some kind of proxy which holds the real bean as a proxy declared "transient".
BTW, I am using Spring 2.5.6 and webflow 2.0.7. Later versions may have better ways of handling this; in particular, EL's have gotten some attention, it seems. I'm still stuck with OGNL, which is the Spring 1.x EL.
I'm sure some webflow guru knows other ways of doing things in a less clunky fashion...
I don't think you can use the same webflow definition with the actions configured in two different ways.
If you want to use different actions you'll either have to reconfigure your action beans then redeploy your app or create a separate webflow definition with the differently configured beans.
This is a great Spring WebFlow resource.
Try to refactor the common configurable part in a subflow, and call the subflow from the different main flows where you want to reuse it.
Pass parameters to the subflow to configure it in any way needed, using the spring expression language to pass different spring beans, etc.