I have here one ADF exercise:
An application module is named MyAppModule. No Java component is defined for
the module but the application does define a base class that extends oracle.jbo.server.ApplicationModuleImpl.
Which two statements are true in this scenario?
A. Code In the base class will only be implemented if MyAppModuleAppl.java extends the base class.
B. Any code in the base class will be implemented by MyAppModule.
C. No code in the base class will be implemented because an application-specific Java component named MyAppModuleImpl.java does not exist.
D. Any code in the base class will be implemented by MyAppModuleDefimpl.java.
E. The MyAppModule. xml definition will include a reference to the base class.
The first issue here is, if is it possible to ADF Model objects to extend custom classes without defining Java "components". Short answer is: yes, it is.
Mpre info about extending ADF Bussiness Components functionality you can find in Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. The chapter 36.1 says:
"One of the powerful features of framework-based development is the
ability to extend the base framework to change a built-in feature to
behave differently or to add a new feature that can be used by all of
your applications."
To create your own extension you should create custom Java class which extends selected ADF Business Components component class, by example oracle.jbo.server.ApplicationModuleImpl.
But Developer's Guide says:
"After creating a new framework extension class, it will not
automatically be used by your application. You must decide which
components in your project should make use of it."
What should be done is select extension class. Every ADF Business Components wizard and editor displays the same Class Extends button on the Java page. Here you can select class which you want extend.
Backing to our test, we have proposed answers from A to E, but which are correct?
A. Wrong, what is " MyAppModuleAppl.java"? Or there is an error in the proposed answer, cause if we will replace MyAppModuleAppl.java with MyAppModuleImpl.java, the answer will be correct.
B. Wrong answer.
C. Correct answer.
D.Also wrong answer, cause our base class extends oracle.jbo.server.ApplicationModuleImpl, and not oracle.jbo.server.ApplicationModuleDefImpl.
E. This is not true, wrong answer.
What do you think about my answers?
Thursday, May 29, 2014
ADF how to: What effect does setting ChangeEventPolicy property to ppr
In this article I would like to solve one of the many issues regarding ADF: what effect does setting ChangeEventPolicy property to ppr.
In the Internet you can find following issue:
You select a binding in the page definition file and set the ChangeEventPolicy property to ppr.
What effect does this action have on the way the page is rendered?
A. It allows a component to partially refresh another component whose partialSubmit property is set to true.
B. When a user selects a new value In a field, the portion of the page where that component resides is redrawn.
C. It enables you to add a component as a partial target for an event, so that when that event is triggered, the partial target component is refreshed.
D. Components whose values change as a result of back-end logic are automatically repainted.
Cause I found many different solutions, I decided to provide my own:)
Ok. Let's start. In the Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (chapter 22.4.3) you can find following text:
"When you create a form, setting up PPR to work for all the components in the form can be time consuming and error prone. To alleviate this, you can set the changeEventPolicy attribute to ppr on value bindings. Doing so means that anytime the associated component's value changes as a result of backend business logic, the component will be automatically rerendered. You can also set an iterator binding's changeEventPolicy to ppr. When you do this, any action or value binding associated with the iterator will act as though its changeEventPolicy is set to PPR. This allows entire forms to use PPR without your having to configure each component separately."
I think there is not any surprise here. The changeEventPolicy=ppr denotes that when the associated component's value changes the component will be added to list of components provided to partial refresh.
But when partial refresh will happen? The answer we can find in the same tutorial. We can read in the same chapter:
"When you drop a form and elect to include navigation controls, JDeveloper automatically sets the changeEventPolicy attribute on the associated iterator to ppr. JDeveloper also sets each of the navigation buttons' partialSubmit attribute to true. This is how command components notify the framework that PPR should occur."
and next:
"When you set the navigation command components' partialSubmit attribute to true and you set the iterator's changeEventPolicy to ppr, each time a navigation button is clicked, all the components in the form that use the iterator binding are rerendered."
It seems that each partial submit forces also reload of components with changed values and ChangeEventPolicy set to ppr. In other words: to effective use of automatic PPR caused by ChangeEventPolicy we need also any action component with partialSubmit set to true.
OK. We can return to our issue:
A. Key here is the phrase: "refresh another component whose partialSubmit property is set to true". A Partial Submit is a method of form submit that does not require a page refresh and only updates components in the view that are referenced from the command component PartialTriggers property. PartialSubmit property should be set to true on the component, action on which should partially submit a form. Setting PartialSubmit property on component which should be refreshed does not make sense. So answer 'A' is wrong.
B. Answer B also does not make sense.
C. Hmm. I think also wrong, answer cause of phrase: "it enables you to add a component as a partial target for an event". As documentation says the component associated with the attribute (or iterator) "will be automatically rerendered", so if automatically, you shouldn't "add a component (manually) as a partial target".
D. My favourite answer is D. Especially because of this sentence in Developer's Guide: "you can set the changeEventPolicy attribute to ppr on value bindings. Doing so means that anytime the associated component's value changes as a result of backend business logic, the component will be automatically rerendered":)
In the Internet you can find following issue:
You select a binding in the page definition file and set the ChangeEventPolicy property to ppr.
What effect does this action have on the way the page is rendered?
A. It allows a component to partially refresh another component whose partialSubmit property is set to true.
B. When a user selects a new value In a field, the portion of the page where that component resides is redrawn.
C. It enables you to add a component as a partial target for an event, so that when that event is triggered, the partial target component is refreshed.
D. Components whose values change as a result of back-end logic are automatically repainted.
Cause I found many different solutions, I decided to provide my own:)
Ok. Let's start. In the Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (chapter 22.4.3) you can find following text:
"When you create a form, setting up PPR to work for all the components in the form can be time consuming and error prone. To alleviate this, you can set the changeEventPolicy attribute to ppr on value bindings. Doing so means that anytime the associated component's value changes as a result of backend business logic, the component will be automatically rerendered. You can also set an iterator binding's changeEventPolicy to ppr. When you do this, any action or value binding associated with the iterator will act as though its changeEventPolicy is set to PPR. This allows entire forms to use PPR without your having to configure each component separately."
I think there is not any surprise here. The changeEventPolicy=ppr denotes that when the associated component's value changes the component will be added to list of components provided to partial refresh.
But when partial refresh will happen? The answer we can find in the same tutorial. We can read in the same chapter:
"When you drop a form and elect to include navigation controls, JDeveloper automatically sets the changeEventPolicy attribute on the associated iterator to ppr. JDeveloper also sets each of the navigation buttons' partialSubmit attribute to true. This is how command components notify the framework that PPR should occur."
and next:
"When you set the navigation command components' partialSubmit attribute to true and you set the iterator's changeEventPolicy to ppr, each time a navigation button is clicked, all the components in the form that use the iterator binding are rerendered."
It seems that each partial submit forces also reload of components with changed values and ChangeEventPolicy set to ppr. In other words: to effective use of automatic PPR caused by ChangeEventPolicy we need also any action component with partialSubmit set to true.
OK. We can return to our issue:
A. Key here is the phrase: "refresh another component whose partialSubmit property is set to true". A Partial Submit is a method of form submit that does not require a page refresh and only updates components in the view that are referenced from the command component PartialTriggers property. PartialSubmit property should be set to true on the component, action on which should partially submit a form. Setting PartialSubmit property on component which should be refreshed does not make sense. So answer 'A' is wrong.
B. Answer B also does not make sense.
C. Hmm. I think also wrong, answer cause of phrase: "it enables you to add a component as a partial target for an event". As documentation says the component associated with the attribute (or iterator) "will be automatically rerendered", so if automatically, you shouldn't "add a component (manually) as a partial target".
D. My favourite answer is D. Especially because of this sentence in Developer's Guide: "you can set the changeEventPolicy attribute to ppr on value bindings. Doing so means that anytime the associated component's value changes as a result of backend business logic, the component will be automatically rerendered":)
Subscribe to:
Posts (Atom)