Sunday, October 30, 2011

Common Multi-Configuration Question Popup

While this might not be the most common use-case, but it is still quite interesting and the month is about to end - so I gotta post something cool for a change right? Hehehe.

Let's say you are in a complex editable form where after clicking the big Save/Confirm button, you would like to ask some follow up questions to the user.
  • Do you want to apply changes?
  • Are you sure?
  • Choosing OK will change X data.
Along with these questions, there are even scenarios (rare) where you need to ask questions next to each other.

Because of these scenarios, I designed a simple demo in the power of ADF declarative components. (note: if there is a design flaw in my implementation as well as class handling, I wouldn't mind suggestions or feedback on it. Feedback is highly encouraged "woooot".

Oh, before I forget, a small constraint that I had to go through is having the button (SAVE/CONFIRM) which triggers the launching of popup will be coming from the the consuming project. So what does this mean? This basically means that the caller or the starting event to launch this question popup will not be part of the component itself. The reason behind this is because the Popup Question might be used by not just a button. It might be a link, a selection event or can even be as simple as a client/server event. So because of this constraint, I had to leave the trigger to be outside of the bean and the component itself will just offer hooks, lots of them if needed.

Starting with our declarative model, let's design an iterator based set of questions where each question has the possibility of having 3 types of answers.

A quick explanation of the output:
  • Display All questions as left aligned
  • Display Confirm/Reject response on the right side
The component bean for this component is as follows.
The only implementation this bean directly calls is the reset, which is called on every popupLaunch, and the onConfirm, which is called during the confirmation.

Next come the bread and butter which gets this thing going. contains all the accessors needed for the generation of the dynamic question/answers. The main thing to note down for this bean is the abstract methods which will make sure that the consumer will have to code those implementation for handling the questions as well as answers where events starts to manipulate.
Let's start with playing with this starting with our fragment.

Take note how I kept the items in the pageFlow scope, for longer life in its context.

The launch method in this class is the entry point of calling the component.
All the hooks are implemented here.

  • initializeItems - This is where I insert question data
  • onConfirm - I check for at least one affirmative answer before I return a yey' to the super class
  • configureAnswer - Just an extra hook before setting the values (think of it as setAttributeInternal :) )
  • resetItems - I directly set the answers back on their initial state which is unanswered.

So let's start putting it to the test.

Kudos to declarative components.

Sunday, October 9, 2011

Remote Task Flow as a List-of-Values (LOV) Selection Dialog

Remote Task Flow = RTF

I'd like to share a small demo in using a remote task flow configuration to be used as my list-of-input-values. Along with this demo, I'll present it while taking templates as well as a generic wrapper task flow. The generic wrapper task flow is only needed to allow us to directly expose the RTF to be configured as a NON-Page Fragment task flow. More explanations later on.

RTF is a pretty cool ADF feature which is presented in one of ADF Code Corner's presentation:

#43 How-to integrate remote task flows in your ADF applications (POJO DC Example)

So to start with, let me create my template project with my URL LOV Task Flow template as well as my wrapper task flow. Ow, also there is my LOV Page Template.


url-lov-util.xml - I'd like to point out how I'm transferring the return parameters of the RTF to the wrapper's pageFlowScope.

url-lov-util.xml - InputParameters
url-lov activity's task flow configuration. Take note, this part is exactly what the code corner article will teach you :)

Here's my project structure for the LOV Dialogs. Only thing you definitely need for this project is the template project (mentioned above). For my sample, I'll be creating two kinds of LOV, Locations and Departments, care of HR Schema.

TaskFlow design for both are pretty much the same so I'll just describe the Department scenario.


Couple notes to explain the functionality. The base class simply enforces a signature as well as a utility to directly throw parameters to the PageFlowScope starting with suffix "A". The taskflow is based on the taskflow template thus consuming taskflow would already expect the output parameters. (which really is the wrapper taskflow anyway). Besides that, everything else is still quite in the realm of adf :)

Next step is the consuming page as well as the usage of the wrapper taskflow.

Consuming Project
main-index.xml - departmentsLov activity parameters

Let's go for testing already!

And here's Location:

And that's the beginning of October.