Re: [ADF EMG] Selectively disable validation in ADF

[Saif Kamaal]

Well i think if you short circuit the jsf life cycle your issue will be resolved. And we can short circuit the life cycle using immediate attribute

Regards
Saif Kamaal
-sent from note

On Nov 14, 2012 3:24 PM, "Ciprian Iamandi" <ciprian...@gmail.com> wrote:

Hi!

I am facing the following challenge.

I am building the taskflow for a BPM Human Task. In this taskflow I have a page where I display an editable form with information from a custom db schema.

Some of those fields have validation rules (e.g. a date field value must be less than the current date)

After the user edits those fields, there are 2 possible actions: click on "Save" button, or "Save and Continue" button.

The "Save and Continue" button will call Commit on the DataControl, and then the pass the control to the BPM Process. If there are validation errors, the user is notified and requested to fix the errors before committing. So far, nothing special.

The "Save" button should only save the information in the db, skipping the validations. I'm thinking there will still be some minimal validations for the correct data type to go into the tables. But no business validation.

How do you think I can achieve this?

I am also flexible on where to put the business validation: on EntityObject level, on pageDef level or on JSF level. 

However, I didn't have any success so far with any of these approaches.

The main problem comes from the fact that the validation step in ADF page lifecycle is executed before the event triggered by the button is processed. So, by the time that I know which of the buttons was pressed, the validation had already happened.

The most promising solution was to use pageDef level validation and disable or enable the ADF Model validation by using a router and 2 method calls (like I saw in one ofi Frank Nimphius' examples with a train taskflow). However, validation at the pageDef level has limited capabilities. For example, I can only compare a field with a literal value. In my case (validating a date is less than today), it doesn't work.

Another solution that I'm thinking to explore right now would be to use immediate="true" on the Save button and somehow simulate the Update Model Values step when processing the button's actionListener. But I don't know if that's feasible.

I'm also thinking about using I SavePoints. I never used them in my projects so far. Do you think I can achieve something like this using a SavePoint? Or are the validations triggered as well when creating a savePoint? I also know that a savePoint has a limited validity time (24h by default, if I'm not mistaken). I would need the information to be stored indefinetly because in this project, the BPM process can take months or years to finish and we also need to be able to access that temporary information at any given time as read only.

Do you have any suggestions or leads that I can explore in order to do this?

Has anyone faced this kind of challenge before?

Thank you very much!

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Sveinn Halldór Oddsson Zoëga]

I have done such validations by having a boolean attribute at entity level which says whether to do do validation or not and then having a Entity Validator with Conditional Execution Expression as the name af the attribute. 

When I want to save (but not continue) the attribute's value is false (it is by default) but when I save and continue I set the attribute to true and the entity validators kick in.

Kveðja.
Sveinn H. Oddsson Zoëga
sve...@gmail.com
s. 862-3538

[Ciprian Iamandi]

Hi Saif,

Thanks for the answer. So, you're suggesting that using immediate="true" will work.

I would use a backing bean for the page to access the fields values, then programmatically update the ViewObject's attributes with those values and then call commit. Is that correct?

Would this allow me to put the business validation on the Entity Object? I would prefer having the validations at that level, if possible.

                                                                                                                                         

Ciprian Iamandi

Freelance Consultant & Developer

Java, Oracle ADF and Webcenter

Mobile (BE): +32 483 08 17 56

Mobile (RO): +40 724 31 81 95

Email: ciprian...@gmail.com

LinkedIn: http://www.linkedin.com/in/ciprianiamandi

[Steve Muench]

I don't recommend a strategy of conditionalizing validations. If you short-circuit validation by making your validation rules conditionally allow incorrect data, then you will save invalid data to the database. The next time you requery it, ADF considers that data valid and will not revalidate it automatically.

Using a passivation snapshot (or Row.writeXML()) to persist the current state of the transaction (or a single row, if more appropriate) would be a better strategy.

[Sveinn Halldór Oddsson Zoëga]

Conditional validations can be a valid use case, e.g. when a single db table row will change statuses during it's lifetime. May for example have a status of draft, for approval and final. Different validation rules may apply to different row statuses. But this requires the data model to handle that and all application referencing the data.

Kveðja.
Sveinn H. Oddsson Zoëga
sve...@gmail.com
s. 862-3538

[Steve Muench]

I didn't mean by my comment that having validations with conditional logic was inappropriate, but I can see how it could have been misinterpreted that way. I intended to say that short-circuiting all validation logic in order to temporarily save invalid data -- that I was assuming was not really ready to be persistently saved in the actual DB tables yet -- might come back to bite you, and wanted to highlight the role that our passivation snapshots could play as a generic facility to save the state of a transaction not yet ready to commit.

[Steve Muench]

In the end, you can get almost anything to work with iteration and testing. However, what I look for is the strategy that will cause the least amount of extra work around the rest of the system. If you have a special DATA_INVALID column whose value of "Y", for example, marks a row as invalid, then anytime you query your underlying table you have to remember to filter out WHERE DATA_INVALID='N' so you don't end up counting your invalid data that you allowed to get into the database.

At what moment do you toggle the DataInvalid flag to "N" to cause the "real" validations to be re-evaluated? Whenever you query up a row, as soon as you modify any attribute of the row you would need to toggle this DataInvalid flag to "N" so that the rest of your validations would get re-evaluated correctly. You'd also need to trigger every attribute's re-assignment to itself in order to trigger attribute-level validations that you might have previously short-circuited. Remember, when queried all attributes are presumed to have valid values if they came from the database.

It just sounds like a lot of extra work to me, where any bug in your "allow invalid data now" logic might result in incorrect data being saved to the table.  Depending on your application's purpose, that could be totally harmless, or it could inadvertently deprive a patient in need of an organ transplant from a life-saving procedure (in an extreme case). We built the ADF passivation snapshot mechanism (and then layered the ADF Controller "Save for Later" feature on top of it) to provide a generic mechanism to allow saving partially-complete data entry for later completion. This mechanism keeps the incomplete data out of your "live" data tables until it's actually meant to be there.

Of course, each developer will need to weigh the pros and cons of all the available approaches for his/her own application before picking one. The help we can provide here is to make sure you have not missing taking into account some pros or cons that you might not have thought about.

On Thu, Nov 15, 2012 at 8:31 AM, Saif Kamaal <saifk...@gmail.com> wrote:

Hi,

@Steve: I echo with your thinking, but in this case the data needs to be saved without validation when clicking on 'Save'. Now if the data is saved and the user next time presses "Save and Continue" the validations will fire to validate the data. I don't see a problem here.

However i liked the other approach of having an attribute at EO level and flag it for checking when to validate. Looks a clean approach.

Regards,

Saif Kamaal.