While working on customer side during last week, we got a requirement to render table records and conditionally prevent editing based on history column. Its quite common requirement, and there are many ways in ADF to implement it. You can generate separate button for each row and conditionally disable it, but from user perspective it is far from the best approach. Don't forget that ADF allows to override standard methods, where we can customize behavior. One of those methods - isAttributeUpdateable(), you can override it in EO implementation class, use this method to enable conditional disable property rendering.
Download sample application - IsUpdateableByDate.zip. This app implements simple table:
We can insert new records:
Business rule says - record should be editable only when HireDate attribute value is in range of 20 days before current day. Example of editable newly inserted records (12/4/2009 and 12/1/2009):
If I will change HireDate attribute value to older date:
Record automatically will become disabled:
How it is implemented? Simply you need to define EO implementation class:
Create new transient attribute on EO level - EmployeeEditIndicator:
This attribute can be based on Groovy expression, and is used to calculate the difference between adf.currentDate and HireDate attribute. Make sure you check for null value, otherwise it will not work for newly created record:
Finally, our isAttributeUpdateable() method is overridden to compare the difference in days:
7 comments:
Is there a reason why you prefer to create a transient attribute containing a groovy expression instead of just writing the check in the isAttributeUpdateable method?
Yes, because API methods for oracle.jbo.domain.Date didn't worked as expected. There is one method to calculate difference in days, however it throws internal error (at least for me).
Regards,
Andrejus
Hey.. is there any alternate for the isAttributeUpdatable(). if EO contains 50 attributes, this method will execute 50 times(also the if() statement) which will cause performance overhead.
From my experience, this doesnt cause any performance issue. This is just one additional check on top of API.
Thanks for your reply..!
But I want to know is there any alternate for isAttributeUpdatable()[new mandate in my product not to use isAttributeUpdatable()!].
My test case is: start date should be enabled only for the future dates.
I would use isAttributeUpdatable. No reason not to use it. This is best way, I dont think there is other way as good as this one.
Andrejus
Hi ,
I am unable to download the zip, can you please check and share the new link.
Post a Comment