This content has been marked as final. Show 8 replies
Thanks for the reply. I know a client side validation could mask the problem, but it wouldn't solve it.
So what I'm really looking for is the best technical server side solution
apodictus wrote:So what is the read-only condition? Why doesn't it check that the end date correctly terminates the subscription?
I'm pulling my hair over validation vs conditional read only behaviour.
I have a detail form on a subscription record.
All fields on the form are "display only" except for the end date of the subscription. The whole purpose a the form is to fill in an end date when the subscription expires. Of course you can end a subscription only once. So after I put in a read only condition on the end date. If a users selects a record that is already ended the form is read-only
All is well until, except when a user make a mistake enters a valid date, which is logically wrong (like a end date before the start date)
An item validation kicks in telling the user the date is wrong. But because of the way apex is working. After this page validation the page is reloaded. Session state now contains the wrong date thus the read only condition is met and validation error is displayed while the date is now read only. Now the users knows he's done something wrong but he can't change it. It's a bit chicken and the egg. If I take out the condition on everything works, but then the form remains updatable. (hence you can alter the end date and save again). After a subscription has ended you should not be allowed to change it again.
I can fix the problem with a solution like changing the read only condition to look at the actual database value instead of the item value. However this will effectively caused the record to be pulled from the database twice. Once by apex for the entire record and then again for the condition.
The problem seems like such basic behaviour. I can't believe there isn't a more easy way like my original approach. Which would have worked like a charm if I did not need validations.
I'm such a Newbie that I'm really confused now. I would think there is still going to be a client-side validation in addiiton to anything/everything you do on the server side. How (what feature/code?) are you making the field display (or read-only) now? We'd really like that to be conditioned on the field passing the validation, right? You've obviously wrestled with this a lot. So is there no way to make it read-only only if it's a valid date?
You can still have a before update trigger that validates that the subscription date hasn't been manipulated if the client-side code has indeed failed.
Whether you double up validation by doing them both client side and server side is a choice.
Coding both ways take extra time thus money. Since I must use server side for security I only double up and use client side validation, when it adds extra "usability".
Of course I can make a client or server side validation which does the trick.
My point is that is takes more effort than I want it to cost.
When the page is reloaded after validation fails. The record is fetched from the database. This will still return a null end date.
Only when loading it the values into session state APEX retains the value still in session state and acts on it as it were loaded form the record itself.
Causing my form to behave as it were loaded from the record itself.
My current resolution is as I wrote. I fetch the record a second time from the database, but I simply which I could more cleverly act on the information already has.
The fact that the actual record value is null and only the value in session state is user input.
Apex now mingles them.
apodictus wrote:It's not simply a case of it having a value or not, it has to be a valid value. The read-only condition should include the required validation:
The page item with the end date (let's say P1_END_DATE) is of display type "DATE PICKER"
The item also has the a readonly condition :P1_END_DATE is not null.
Which renders the datepicker as read only when a the item has got a value and renders it as datepicker when the item does not have a value
or whatever the required validation is.
to_date(:P1_END_DATE) > to_date(:P1_START_DATE)
I see what you mean. In the simplified example with only 1 validation it would probably be a good approach. Al tough I guess an actual bad date like 32-1-2013 would break the read only condition. So I'd probably have to write some extra code to avoid that from happening. But I guess in an easy example with a simple validation that would be a good approach
However in my real application the validation of the end date has 7 much more complex validations. Each of which I would have to duplicate/sum up in the read only condition of the item.
Of course I could move all my validation code into single packaged function which I could then call from both the validation and the condition to avoid code duplication. But when doing that the database impact of running all the validations for each page display is far greater than my current less then perfect solution described earlier. That's why I'd rather have the approach of testing for null (the result of the validation)
If only apex would allow me to differentiate between values fetch from session state and values fetched from record...
I guess for now I will have to accept that i'm fetching the record twice :)
thanks for your input