Stupid forms/node API question
I've been fighting this one for seven hours straight, and have read every bit of documentation I can find. I *know* I'm overlooking something really simple. Please help! Here's what I need to do in the edit handling of a custom node: 1. On initial entry to node/#/edit, I need to load values from the database using hook_load() and stuff them into the $node object. This is working perfectly, and the value from the databse loads into the visible form and displays correctly. 2. When a preview is submitted, I need to take the value that comes from $_POST and edit it before the form is generated. This is where things are breaking down. I can "validate" the value, issuing errors if I don't like it, but I can't seem to *change* it under programmatic control. I have tried changing $node->(my custom field) in nodeapi:validate, and in nodeapi:prepare, and even in hook_form. The thing is, I'm putting the modified value into the '#default_value' element of the appropriate part of $form, but somehow it's getting set back to the original $_POST contents from that field, between when I build the $form array and when that array is turned into HTML. I've been all over the code, but I can't seem to find where that's happening. Can someone help? Thanks! Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Just another interested listener. I've ran into this same issue, asked on #drupal and in this ML, but so far, no luck. I've come to beleive its no longer possible, but please prove me wrong. Ber On Sat, December 10, 2005 23:18, Syscrusher wrote:
I've been fighting this one for seven hours straight, and have read every bit of documentation I can find. I *know* I'm overlooking something really simple. Please help!
Here's what I need to do in the edit handling of a custom node:
1. On initial entry to node/#/edit, I need to load values from the database using hook_load() and stuff them into the $node object. This is working perfectly, and the value from the databse loads into the visible form and displays correctly.
2. When a preview is submitted, I need to take the value that comes from $_POST and edit it before the form is generated. This is where things are breaking down. I can "validate" the value, issuing errors if I don't like it, but I can't seem to *change* it under programmatic control.
I have tried changing $node->(my custom field) in nodeapi:validate, and in nodeapi:prepare, and even in hook_form. The thing is, I'm putting the modified value into the '#default_value' element of the appropriate part of $form, but somehow it's getting set back to the original $_POST contents from that field, between when I build the $form array and when that array is turned into HTML.
I've been all over the code, but I can't seem to find where that's happening.
Can someone help? Thanks!
Scott
-- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
--
On Sat, 10 Dec 2005 23:18:11 +0100, Syscrusher <scott@4th.com> wrote: First. The subject is wrong, there are no stupid questions. We all learn.
displays correctly.
Good!
2. When a preview is submitted, I need to take the value that comes from $_POST and edit it before the form is generated. This is where things are breaking down.
Not good.
$form, but somehow it's getting set back to the original $_POST contents from that field, between when I build the $form array and when that array is turned into HTML.
I've been all over the code, but I can't seem to find where that's happening.
Can someone help? Thanks!
Well, the actual value is calculated from $_POST['edit'] values and #default_value . If there is a _POST value, then it overwrites the #default_value . There are at least two solutions: a) You change $_POST b) You add a #value to the form element in this case. Have you read the documentation that you should never use #value? This is the exception. However, be extremely cautious what you set here, it'll be sent back to the user. Regards NK Ps. Ber, if I have not answered you, then sorry! I missed your letter.
Please make note of this in the docs somewhere. I was just banging my head against the same wall. On 12/10/05, Karoly Negyesi <karoly@negyesi.net> wrote:
On Sat, 10 Dec 2005 23:18:11 +0100, Syscrusher <scott@4th.com> wrote:
First. The subject is wrong, there are no stupid questions. We all learn.
displays correctly.
Good!
2. When a preview is submitted, I need to take the value that comes from $_POST and edit it before the form is generated. This is where things are breaking down.
Not good.
$form, but somehow it's getting set back to the original $_POST contents from that field, between when I build the $form array and when that array is turned into HTML.
I've been all over the code, but I can't seem to find where that's happening.
Can someone help? Thanks!
Well, the actual value is calculated from $_POST['edit'] values and #default_value . If there is a _POST value, then it overwrites the #default_value .
There are at least two solutions:
a) You change $_POST b) You add a #value to the form element in this case. Have you read the documentation that you should never use #value? This is the exception. However, be extremely cautious what you set here, it'll be sent back to the user.
Regards
NK
Ps. Ber, if I have not answered you, then sorry! I missed your letter.
On Saturday 10 December 2005 18:24, Karoly Negyesi wrote:
On Sat, 10 Dec 2005 23:18:11 +0100, Syscrusher <scott@4th.com> wrote:
First. The subject is wrong, there are no stupid questions. We all learn.
Kindly and wisely spoken. Thanks. :-)
I've been all over the code, but I can't seem to find where that's happening.
Can someone help? Thanks!
Well, the actual value is calculated from $_POST['edit'] values and #default_value . If there is a _POST value, then it overwrites the #default_value .
I accept and believe what you're saying. For the sake of my greater understanding, though, can you point me to the specific module and function to look at, so I can see it in the code? Again, I do believe you...but I want to seize the "learning moment", as it were. :-) I did a search on "POST" in node.module and form.inc, but wasn't sure which of the occurrences was "the one" where the anomaly happened. Nota bene #1: The existing documentation on the forms API is *terrific*. The existing documentation on the node API is *wonderful*. However...there seems to be a bit of a gap talking about how they integrate with one another, that is, how the node API uses the forms API, and what functions in what order for typical node ops. I realize all of this is new, but I'd love to see (when time permits) a brief overview of that aspect. Nota bene #2: Here's my contribution of a tip, which I *think* isn't in the docs yet, but maybe I just overlooked. I was wondering why there are both node_invoke() and node_invoke_nodeapi() functions that appear to do almost the same thing...and in fact are called right in sequence from most of the node.module places that use them. I thought one of them might be a deprecated form, for legacy modules, and was wondering which was the preferred approach. But after examining the node.module code (yeah for Open Source!!!!), I found that they do serve different functions: * node_invoke() + Only invokes hooks for the node handling module of the current type + Invokes the hooks of the form $type_$hook() where $type is "story", "page", etc., and $hook is "load", "delete", "form", etc. * node_invoke_nodeapi() + Invokes the hook_nodeapi() implementation in all functions that have defined it. + Invokes $type_nodeapi(&$node, $op, ...etc....) where $op is the semantic equivalent of $hook from node_invoke() I may have just overlooked this differentiation in the docs, but I didn't see it this explicitly stated. When I finally figured it out, it was a real "slap on the forehead" moment for me. :-) If this is in the docs, tell me to shut up and go away, but if not, then I'll be glad to write something up as a doc contrib if you want.
There are at least two solutions:
a) You change $_POST b) You add a #value to the form element in this case. Have you read the documentation that you should never use #value? This is the exception. However, be extremely cautious what you set here, it'll be sent back to the user.
Yes, I saw that documentation that said #value should not be used for anything the user was allowed to change. Ironically, I originally had thought about using #value in this situation, then saw that in the docs, and assumed I shouldn't. :-) I'll give that a try. I thought of the modification of $_POST, but considered that to be a no-no. If #value doesn't work, I'll try the other approach. Many thanks for the response, Karoly! I'll post to the list tomorrow after I've had a chance to try your suggestions. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
I accept and believe what you're saying. For the sake of my greater understanding, though, can you point me to the specific module and function to look at, so I can see it in the code? Again, I do believe you...but I want to seize the "learning moment", as it were. :-) I did a search on "POST" in node.module and form.inc, but wasn't sure which of the occurrences was "the one" where the anomaly happened.
It's in form_builder but that function especially this part of the function needs a very good understanding of forms, especially that forms are trees. With that said, read the form.inc code from $edit = $posted ? $_POST['edit'] : array(); Here is a deal for Scott or anyone: come to IRC/MSN/Skype (for the MSN/Skype handler, mail me in private), type your questions which you think are missing from the form API docs, I answer them and in return you enhance the docs. Regards NK
On Sunday 11 December 2005 03:31, Karoly Negyesi wrote:
I accept and believe what you're saying. For the sake of my greater understanding, though, can you point me to the specific module and function to look at, so I can see it in the code? Again, I do believe you...but I want to seize the "learning moment", as it were. :-) I did a search on "POST" in node.module and form.inc, but wasn't sure which of the occurrences was "the one" where the anomaly happened.
It's in form_builder but that function especially this part of the function needs a very good understanding of forms, especially that forms are trees.
With that said, read the form.inc code from $edit = $posted ? $_POST['edit'] : array();
Thanks.
Here is a deal for Scott or anyone: come to IRC/MSN/Skype (for the MSN/Skype handler, mail me in private), type your questions which you think are missing from the form API docs, I answer them and in return you enhance the docs.
I accept that offer! As a professional writer, I'll be happy to contribute some documentation. Besides, I don't like to point out problems without being willing to help with the solution. I don't use any of the three IM tools you list; my company mandates AIM. But I've got an IRC client (never used it, but it's installed). OTOH, maybe email is best because then I have time to formulate questions more carefully. I'd suggest that as first choice but hold IRC as a backup plan in case we need something more interactive than email. Does that work for you? Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Saturday 10 December 2005 18:24, Karoly Negyesi wrote:
There are at least two solutions:
a) You change $_POST b) You add a #value to the form element in this case. Have you read the documentation that you should never use #value? This is the exception. However, be extremely cautious what you set here, it'll be sent back to the user.
BINGO! I changed #default_value to #value, and it works like a charm. I was so happy I didn't even care that a seven-hour debugging session was cured by a one-line code change. I have another module that needs to sort an array of values, and possibly even delete one or more of them entirely, rather than just changing one string. I think I'll *have* to resort to changing $_POST. But that's okay, now that I know it's a viable option. Thanks kindly for the response. As soon as I have my code working, I'll submit a documentation note (probably review it with you, Karoly, for technical accuracy first, if you don't mind). Scott Doing the happy dance since his module's working now! -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Op zondag 11 december 2005 00:24, schreef Karoly Negyesi:
Ps. Ber, if I have not answered you, then sorry! I missed your letter.
My wordig was very clunky, and that mail was send in That Time Where All The FAPI stuff went on. aka the week after oct6 :) No problem, I found ways around it, by rearchitecturing stuff. -- [ Bèr Kessels | Drupal services www.webschuur.com ]
participants (4)
-
Ber Kessels -
Earl Dunovant -
Karoly Negyesi -
Syscrusher