I know this is not a feedback forum but I don’t know what is the correct way submit feedback to IBM. Can somebody tell me (and I mean a way that does not cost me money :)?
Anyway the feedback is this: @ThisName should definitely work in “HTML Attributes” of a field. It would be very very useful when combined with @Eval.
In my current development case, I have a big form with lots of mandatory fields. I want to show the mandatory fields not filled with a colored background if the user tries to submit the form without filling all mandatory fields.
If @ThisName would work, I could store this formula to a CFD field and refer to it with @Eval from all my mandatory fields:
@If( @IsMember(@ThisName; RequiredEmptyFieldsTX); “style="background-color:#FFE1DC"”; “” )
Because @ThisName does not work, I have to write this same formula 40 times and change the field name to each formula.
Subject: Feedback to IBM about @ThisName
Why do you not just use Javascript and DHTML instead of taxing the server with 40 computations?
Subject: I could, that’s a good idea
We want the document to be saved even if the validation fails (it’s just not sent for approval). I could still use JS to change field colors after the server side validation.
I guess I’m so much of a Domino guy that I prefer to use Domino stuff (@formulas) instead of DHTML. This application is not so much used that the server-side computation and server load caused by it would be a problem.
Nowadays people tend to think that the client always has a lot of processing capacity as a PC usually has. As a result applications are written to rely heavily on Javascript. But at least in my case the client can also be a mobile phone with very limited capacity. The app runs much faster on mobile devices when the processing is done on the server side.
Subject: Why not use a style sheet and assign a class?
Wouldn’t that work?
Subject: RE: Why not use a style sheet and assign a class?
That’s not quite the dynamic solution wanted here (the class should change depending on whether the form was submitted with the field empty or filled). Personally, I wouldn’t send the document back to the server for empty-field validation, since that can be easily accomplished client-side in JavaScript, but I can see the use for @ThisName in all formula-driven field objects.
Subject: See my reply above and
also generally field validation should be done on the server side because an advanced user can easily tamper with the Javascript. Also there might be a browser or browser version where JS validation does not work.
Of course this depends on how important the validation is for your app. If it’s OK that unvalidated docs go thru from time to time then it’s certainly OK to use Javascript.
Subject: RE: See my reply above and
Actually validation, as a “best practice”, should occur at the client end and not the server end. yes there are challenges such as the scenario you describe, but…
See:
“Better Compliance through Lotus Notes/Domino Coding:Learn how to rethink data validation to support business control objectives in your IBM Lotus Notes/Domino applications.” in Lotus Advisor:
http://lotusadvisor.com/doc/14900
Perhaps AJAX is the solution…
Subject: RE: See my reply above and
Yes, you should also be doing server-side validation, not INSTEAD of client-side validation, but in addition to client-side validation. JS validation should not be something you think of as “okay” to use, but something you think of as essential, both for the usability improvements it provides to the user and for the scalability it will afford at the server. Neither the delay in reporting problems to the user nor the additional, unnecessary request at the server should be considered acceptable.
Subject: Who wants to write and maintain two validation routines?
You’ve got a point but as I said: “We want the document to be saved even if the validation fails”. That is one reason I don’t want to use JS in this case, at least not before the save.
I have never seen a user complain about 1 sec server round trip. But I’ve seen users complain about unsaved data much too often.
Of course it all depends on the specific needs of the application in question. In my opinion it very seldom makes sense to write and maintain two validation routines.
Subject: I do (was: Who wants to write and maintain two validation routines?)
I look at it this way – my server seems faster, my app can run bigger on smaller hardware resources and my users are happier if I use JS, and the devs, admins and IT types in the server room don’t have nearly as much work to do if I have solid server-side validation that prevents bad data from doing damage. More work? Maybe a little, over the short term, but a lot less in the long run.
Subject: Not in my case
As I said in my case the user is happier if the data is always saved when she sends the doc for approval. She may have spent hours filling out the doc and the last thing she wants to experience is losing that data (which may happen if I’d have JS validation).
Docs are sent to approval only a few times a week so there is no effect in server performance.
You’ve got good points but each app is different. Using always the same approach is easy for the developer but bad for users.