Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input? eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself). If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know. Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea? On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards Graeme McKibbin Software Developer
Graeme, please refer to the Forms API Quickstart Guide : http://api.drupal.org/api/file/developer/topics/forms_api.html/5 On 2/6/08, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
Thank you, I've been looking for that! On 06 Feb 2008, at 9:59 PM, Oleg Terenchuk wrote:
Graeme, please refer to the Forms API Quickstart Guide : http:// api.drupal.org/api/file/developer/topics/forms_api.html/5
On 2/6/08, Graeme McKibbin <gmckibbin@iburst.co.za> wrote: Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
Have a look at the Views Theme Wizard. In recent versions, it is a multi-step form that uses the values from step 1 to generate form step 2. Step 2 (or sometimes step 3) has no submit buttons on it, but its content is the result of the previous steps. The last step then is the display, and there's no reason why you can't use form fields of #type markup to show just HTML that was built off of the previous steps. --Larry Garfield On Wed, 6 Feb 2008 21:53:47 +0200, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
Ok thanks... But does that include building a SELECT query in php and displaying the results in a table? (The reason I want to do that is because the Inventory field does not appear in the Views field list) On 06 Feb 2008, at 10:58 PM, Larry Garfield wrote:
Have a look at the Views Theme Wizard. In recent versions, it is a multi-step form that uses the values from step 1 to generate form step 2. Step 2 (or sometimes step 3) has no submit buttons on it, but its content is the result of the previous steps. The last step then is the display, and there's no reason why you can't use form fields of #type markup to show just HTML that was built off of the previous steps.
--Larry Garfield
On Wed, 6 Feb 2008 21:53:47 +0200, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
I believe this discussion is more suited for http://drupal.org/forum On 2/6/08, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Ok thanks... But does that include building a SELECT query in php and displaying the results in a table?
(The reason I want to do that is because the Inventory field does not appear in the Views field list)
On 06 Feb 2008, at 10:58 PM, Larry Garfield wrote:
Have a look at the Views Theme Wizard. In recent versions, it is a multi-step form that uses the values from step 1 to generate form step 2. Step 2 (or sometimes step 3) has no submit buttons on it, but its content is the result of the previous steps. The last step then is the display, and there's no reason why you can't use form fields of #type markup to show just HTML that was built off of the previous steps.
--Larry Garfield
On Wed, 6 Feb 2008 21:53:47 +0200, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
It certainly could. You could easily theme a table and then stick the rendered result in a markup form value, and you're done. It has nothing to do with Views, really. The Theme Wizard is just an example of it that I remember writing. --Larry Garfield On Wed, 6 Feb 2008 23:08:31 +0200, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Ok thanks... But does that include building a SELECT query in php and displaying the results in a table?
(The reason I want to do that is because the Inventory field does not appear in the Views field list)
On 06 Feb 2008, at 10:58 PM, Larry Garfield wrote:
Have a look at the Views Theme Wizard. In recent versions, it is a multi-step form that uses the values from step 1 to generate form step 2. Step 2 (or sometimes step 3) has no submit buttons on it, but its content is the result of the previous steps. The last step then is the display, and there's no reason why you can't use form fields of #type markup to show just HTML that was built off of the previous steps.
--Larry Garfield
On Wed, 6 Feb 2008 21:53:47 +0200, Graeme McKibbin <gmckibbin@iburst.co.za> wrote:
Not sure if I'm on the same page as you, but I need to have a form that has some input fields and a submit button, and when it's clicked, the form passes the input to itself (or another page) and then displays a table of results from a query (that I've created). Any idea?
On 06 Feb 2008, at 8:59 PM, Ivan Sergio Borgonovo wrote:
Maybe there is a clean way to recycle most of FAPI if you don't need to save anything in _submit but if you'd just like to produce some output based on form input?
eg. you've 2 fields and the form "landing" page should display the product (the landing page may still be the form path itself).
If there is such a technique that let you intercept $form_values and $form_id outside _submit _validate and display output accordingly I'd be glad to know.
Otherwise I'd really enjoy to see a _display hook that in spite of showing the form or redirecting somewhere else would just have access to $form_id and $form_values as _validate and _submit but would output something else other than the form.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
Kind Regards
Graeme McKibbin Software Developer
On Wed, 6 Feb 2008 19:49:12 -0600 Larry Garfield <larry@garfieldtech.com> wrote:
It certainly could. You could easily theme a table and then stick the rendered result in a markup form value, and you're done.
It has nothing to do with Views, really. The Theme Wizard is just an example of it that I remember writing.
Thanks. Emanuele Quinto wrote me about a similar solution for D6 and finally I had the chance to see View Wizard. I find this solution convoluted. At a first sight furthermore putting stuff in #markup will end up in stuff being nested in <form>. Anyway this approach incur in another problem... what if your form is in an area and your results have to be displayed in another and you still need the form? OK hook_display won't solve this problem as well but at the end the problem is that $form_values/$form_status is not available outside the FAPI while $_POST/$_GET are... but well using $_POST/$_GET means you're not using FAPI. I saw some global in FAPI... and well I think somewhere there should be something like $forms[$form-id]. At the end of drupal_get_form $form_values/status should be fully populated[1] so you could access it through such a global... but beside the fact that we would be adding one more global (just something to reflect on, not a dogma), even if I'd find such kind of beast in FAPI... it is not documented and not part of the advertised FAPI. That means that virtually it doesn't exist. Not being advertised Karoly would be absolutely free to change its name or structure for a bug fix. And yeah it's better it doesn't get into the "public" FAPI but I'd be better to have some king of encapsulated access to $form_values/status outside drupal_get_form. FAPI is doing a lot of good work around $_POST that can not easily be recycled outside of drupal_get_form. Not only it validate the form but _validate hook can change values, so that $form_values/status is actually more valuable than $_POST. And there are other interesting data in $form_values/status too. Even stuff that use the _submit hook to really save stuff on DB force you to read the DB to see what was sent from the form. [1] that actually poses another problem if you need $form_values/status in more than one place -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Feb 7, 2008 9:24 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 6 Feb 2008 19:49:12 -0600 Larry Garfield <larry@garfieldtech.com> wrote:
It certainly could. You could easily theme a table and then stick the rendered result in a markup form value, and you're done.
It has nothing to do with Views, really. The Theme Wizard is just an example of it that I remember writing.
Thanks.
Emanuele Quinto wrote me about a similar solution for D6 and finally I had the chance to see View Wizard.
I find this solution convoluted.
At a first sight furthermore putting stuff in #markup will end up in stuff being nested in <form>.
Using form '#prefix' or '#suffix' you can solve this plain html outside of <form> tag.
Anyway this approach incur in another problem... what if your form is in an area and your results have to be displayed in another and you still need the form?
On the _validate you can do whatever you want: save values with set_variable or global variable (I know, I know...) or in a table. In principle you don't have to wait the _submit.
At the end of drupal_get_form $form_values/status should be fully populated[1] so you could access it through such a global...
$form_status['values'] is populated (in D6): * if you set $form_status['rebuild'] (in _validate) * if you set some value in $form_status['storage'] They are available in a _form_alter hook where you can change the apparence of the form. You can also use #pre_render (http://api.drupal.org/api/file/developer/examples/multipage_form_example.mod...): The #pre_render of a form allows us to make changes AFTER validation (unlike hook_form_alter()), but BEFORE the form has actually been displayed. We use it to control which form elements are shown, which are hidden, and which values to set based on... ema -- Emanuele Quinto - www.kronstadt.it ------------------------------------------------------------------------------------------------------------------ My mother used to say to me, "Elwood" - she always called me Elwood - "In this world, Elwood, you must be oh-so smart, or oh-so pleasant." For years I was smart. I recommend pleasant, and you may quote me. ------------------------------------------------------------------------------------------------------------------
On Thu, 7 Feb 2008 10:30:12 +0100 "emanuele quinto" <emanuele.quinto@gmail.com> wrote:
On the _validate you can do whatever you want: save values with set_variable or global variable (I know, I know...) or in a table. In principle you don't have to wait the _submit.
Yep... but somehow you're just making a copy (a global one) of something that should be already there and accessible as much as $_POST is. FAPI does a lot of valuable work that is hard to take out unless you use some not really clean technique that mix form processing, rendering and stuff related to value passing.
At the end of drupal_get_form $form_values/status should be fully populated[1] so you could access it through such a global...
$form_status['values'] is populated (in D6): * if you set $form_status['rebuild'] (in _validate) * if you set some value in $form_status['storage']
They are available in a _form_alter hook where you can change the apparence of the form.
Somehow... in this use case... form is gone, it already finished its task, it checked for spoofing, filled and validated the submitted data and they are in $form_status. All these techniques look like getting in the FAPI from the back door to steal what you need and make it available to other parts of your code. eg. I could just write a function that get called from whatever hook FAPI is going to call that call another function with a static member to take a snapshot of $form_status and then I can call the same helper function to get back a copy of the $form_status... but still, that's like stealing, not asking. Of course this doesn't solve the problem to know when $form_status is ready... that's why we have hooks... etc... etc... Every module writer could do the same and we will end up with 20 copies of $form_status and 20 similar thief functions. I don't think that using validated data without pushing them to the DB or session in more than one place is something unusual. Maybe part of drupal_get_form could become a sort of hook that process $_POST before anything else get called, you could book $_POST processing in menu hook and drupal_get_form should just render the form.... but well this looks pretty radical and maybe completely wrong since I don't know enough about FAPI internals. -- Ivan Sergio Borgonovo http://www.webthatworks.it
FYI: Another technique I've used is to call my form function myself. It adds an extra call but here's an example: function non_form_func() { $output = drupal_get_form('myform'); $output .= 'some html outside of the form.' $form = myform(); // If you want you can call the drupal form alter hook functions here to // make sure you get modifications from other modules, but I don't have that code here if ($form['somefield']['#default_value'] == 'someother value') { // do some stuff specific to forms here } return $output; } On Feb 7, 2008, at 3:17 AM, Ivan Sergio Borgonovo wrote:
On Thu, 7 Feb 2008 10:30:12 +0100 "emanuele quinto" <emanuele.quinto@gmail.com> wrote:
On the _validate you can do whatever you want: save values with set_variable or global variable (I know, I know...) or in a table. In principle you don't have to wait the _submit.
Yep... but somehow you're just making a copy (a global one) of something that should be already there and accessible as much as $_POST is. FAPI does a lot of valuable work that is hard to take out unless you use some not really clean technique that mix form processing, rendering and stuff related to value passing.
At the end of drupal_get_form $form_values/status should be fully populated[1] so you could access it through such a global...
$form_status['values'] is populated (in D6): * if you set $form_status['rebuild'] (in _validate) * if you set some value in $form_status['storage']
They are available in a _form_alter hook where you can change the apparence of the form.
Somehow... in this use case... form is gone, it already finished its task, it checked for spoofing, filled and validated the submitted data and they are in $form_status.
All these techniques look like getting in the FAPI from the back door to steal what you need and make it available to other parts of your code.
eg. I could just write a function that get called from whatever hook FAPI is going to call that call another function with a static member to take a snapshot of $form_status and then I can call the same helper function to get back a copy of the $form_status... but still, that's like stealing, not asking. Of course this doesn't solve the problem to know when $form_status is ready... that's why we have hooks... etc... etc...
Every module writer could do the same and we will end up with 20 copies of $form_status and 20 similar thief functions.
I don't think that using validated data without pushing them to the DB or session in more than one place is something unusual.
Maybe part of drupal_get_form could become a sort of hook that process $_POST before anything else get called, you could book $_POST processing in menu hook and drupal_get_form should just render the form.... but well this looks pretty radical and maybe completely wrong since I don't know enough about FAPI internals.
-- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (6)
-
David Metzler -
emanuele quinto -
Graeme McKibbin -
Ivan Sergio Borgonovo -
Larry Garfield -
Oleg Terenchuk