assuming thet the only difference between js and @formula posts is the __Click
value (tell me if i'm wrong), i'd like to share my thoughts...
what's in a __Click :
example: e84191ce283d2c58c1256c5a0038f8e5/$Body/0.386E
- the first element is the id of the form (not of the document)
*how can you guess ?*
copy this id and add it behind the db.nsf name in the address bar, followed by
?readForm
- the second element is $Body (guess it says we are talking about the user
interface)
- the third is a code that says which button of the form is called...
so the 2nd is useless and the 3rd will tell the domino server to do a
@command([FileSave]) the same thing a submit() should do.
then why should the id of the form tell domino whether a field was rendered or
not, and whether it needs to be emptied or not if no value is returned ?
In my humble opinion, there is no reason why this information should change the
way the server works.
1st: even when you do a submit domino knows which form was used (because it
will do all the zillions things it always do: fields conversions, check if
there is an unknown field, launch the webQuerySave....)
=> so domino already HAS this form id !
2nd: this information does not give any hint on which fields were rendered or
not (the same form may have hidden fields, computed sub-forms...)! => so domino
knows which field were rendered, but not by using the __click ! (i guess the
user session stores this info and retrieves it with the http_referer and
%%ModDate)
3rd: hey, even if the form id is compulsory, why dont they produce a hidden
field called %%FormUNID anytime they render an edited document ?
=> so, if there is a solution dont blame the browsers !
Ok, i'm just guessing and i may be completly wrong.
i'd really like to know if there is information about how this domino
renderer/document updater works...
But why does it work with a @formula button ?
assuming thet the only difference between js and @formula posts is the __Click value (tell me if i'm wrong), i'd like to share my thoughts...
what's in a __Click : example: e84191ce283d2c58c1256c5a0038f8e5/$Body/0.386E
- the first element is the id of the form (not of the document) *how can you guess ?* copy this id and add it behind the db.nsf name in the address bar, followed by ?readForm - the second element is $Body (guess it says we are talking about the user interface) - the third is a code that says which button of the form is called...
so the 2nd is useless and the 3rd will tell the domino server to do a @command([FileSave]) the same thing a submit() should do.
then why should the id of the form tell domino whether a field was rendered or not, and whether it needs to be emptied or not if no value is returned ?
In my humble opinion, there is no reason why this information should change the way the server works. 1st: even when you do a submit domino knows which form was used (because it will do all the zillions things it always do: fields conversions, check if there is an unknown field, launch the webQuerySave....) => so domino already HAS this form id ! 2nd: this information does not give any hint on which fields were rendered or not (the same form may have hidden fields, computed sub-forms...)! => so domino knows which field were rendered, but not by using the __click ! (i guess the user session stores this info and retrieves it with the http_referer and %%ModDate) 3rd: hey, even if the form id is compulsory, why dont they produce a hidden field called %%FormUNID anytime they render an edited document ? => so, if there is a solution dont blame the browsers !
Ok, i'm just guessing and i may be completly wrong.
i'd really like to know if there is information about how this domino renderer/document updater works...