Hi, As of late I and a few others have been doing a lot of work on the upgrade to E-Commerce to Drupal 4.7. One part does have me stumped in that I am not sure how I am going to do the checkout process. So far I have fudged it in that I am not using the _validate() and _submit() formapi hooks. Basically what happens in this process is that the user is sent to cart/checkout where the first form is created. This is then posted back and then if all goes well the second form is rendered, and so forth. Now because of the way that the formapi works in that it renders the form and then the _validate() and _submit are called. This means that by the time I know that everything is OK it is too late to create the next form. One idea I did have is that I could to a drupal_goto() to start again, but this is quite and expensive operation when I am already there. Of the formapi gurus are there any ideas on how I can get around this. Any ideas would be much appreciated. Thanks in advance. Gordon.
Gordon Heydon wrote:
Of the formapi gurus are there any ideas on how I can get around this.
Would the "multipart" example module help? It shows how to setup a wizard style form, perhaps you could do something like that where the entire form is already setup, but hidden/shown depending on where you are in the process? Its in contributions/tricks/multipart HTH Simon
Hi, Thanks for this, but it is not really what I am looking for, and it does the drupal_goto() for refresh the page after the submit. Thanks Gordon. On Tue, 2006-02-07 at 10:40 +1030, Simon Lindsay wrote:
Gordon Heydon wrote:
Of the formapi gurus are there any ideas on how I can get around this.
Would the "multipart" example module help? It shows how to setup a wizard style form, perhaps you could do something like that where the entire form is already setup, but hidden/shown depending on where you are in the process?
Its in contributions/tricks/multipart
HTH
Simon
!DSPAM:1000,43e7e7e252918460975785!
On 06 Feb 2006, at 4:35 PM, Gordon Heydon wrote:
Thanks for this, but it is not really what I am looking for, and it does the drupal_goto() for refresh the page after the submit.
it shouldn't be doing that. =) I have a patch that I am nursing to remove all drupal_goto's from _submit functions. i myself am not a fan of how the checkout works on ecommerce at the moment either. I'll chat to chx (who wrote the multipart form) and matt westgate (who originally wrote ecommerce) about it in the next few days, and see if we can figure out an optimal way to accomplish this. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hi, On Mon, 2006-02-06 at 16:50 -0800, Adrian Rossouw wrote:
On 06 Feb 2006, at 4:35 PM, Gordon Heydon wrote:
Thanks for this, but it is not really what I am looking for, and it does the drupal_goto() for refresh the page after the submit.
it shouldn't be doing that. =)
Sorry, my mistake. this is right at the end. I need to look at it more, but I can see that all fields exist before the multipart form is started.
I have a patch that I am nursing to remove all drupal_goto's from _submit functions.
i myself am not a fan of how the checkout works on ecommerce at the moment either.
I'll chat to chx (who wrote the multipart form) and matt westgate (who originally wrote ecommerce) about it in the next few days, and see if we can figure out an optimal way to accomplish this.
Thanks this would be great, as I would like to know so I can clean this area up. Gordon.
On 06 Feb 2006, Adrian Rossouw wrote:
Thanks for this, but it is not really what I am looking for, and it does the drupal_goto() for refresh the page after the submit.
it shouldn't be doing that. =)
I have a patch that I am nursing to remove all drupal_goto's from _submit functions.
Any hints on how to achieve the same result? I have a handful of forms related to voting that use this to refresh the page and recalculate voting results after a vote is cast. I'd like to get rid of it, but there doesn't seem to be a clean way to do it. Am I missing something? --Jeff
On 27 Dec 2005, at 9:09 PM, Jeff Eaton wrote:
Any hints on how to achieve the same result? I have a handful of forms related to voting that use this to refresh the page and recalculate voting results after a vote is cast. I'd like to get rid of it, but there doesn't seem to be a clean way to do it. Am I missing something?
i have an in-progress patch which removes the drupal_goto from all _submit functions, and instead makes it return the page to refresh to. this means you can have multiple _submit functions stacked on top of each other. The system was designed for that, but the drupal_gotos mess up a lot of what should be possible. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hi, On Mon, 2006-02-06 at 22:57 -0800, Adrian Rossouw wrote:
On 27 Dec 2005, at 9:09 PM, Jeff Eaton wrote:
Any hints on how to achieve the same result? I have a handful of forms related to voting that use this to refresh the page and recalculate voting results after a vote is cast. I'd like to get rid of it, but there doesn't seem to be a clean way to do it. Am I missing something?
i have an in-progress patch which removes the drupal_goto from all _submit functions, and instead makes it return the page to refresh to. this means you can have multiple _submit functions stacked on top of each other.
The system was designed for that, but the drupal_gotos mess up a lot of what should be possible.
This sounds great in principle, can I get a link to the patch so I can take a look. Thanks in advance. Gordon.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
!DSPAM:1000,43e846aa95919119242804!
hi guys, I wrote a module to allow administrators to specify a certain session timeout for each role in drupal site. If the user stop interacting with site for the specified time or longer... the site will ask the user for his/here user name and password.... If any one is interested i can send the module to the list or otherwise upload it to cvs. Ahmad
On Tue, 07 Feb 2006 00:26:35 +0100, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
As of late I and a few others have been doing a lot of work on the upgrade to E-Commerce to Drupal 4.7.
One part does have me stumped in that I am not sure how I am going to do the checkout process. So far I have fudged it in that I am not using the _validate() and _submit() formapi hooks.
Hm, I should chime in, right? I am no guru, but I maintain that thing. I think you may want to look into http://drupal.org/node/48918 to check out how I removed POST from poll. Regards NK
Hi, Thanks for this, I will take a look. Gordon. On Tue, 2006-02-14 at 05:41 +0100, Karoly Negyesi wrote:
On Tue, 07 Feb 2006 00:26:35 +0100, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
As of late I and a few others have been doing a lot of work on the upgrade to E-Commerce to Drupal 4.7.
One part does have me stumped in that I am not sure how I am going to do the checkout process. So far I have fudged it in that I am not using the _validate() and _submit() formapi hooks.
Hm, I should chime in, right? I am no guru, but I maintain that thing. I think you may want to look into http://drupal.org/node/48918 to check out how I removed POST from poll.
Regards
NK
!DSPAM:1000,43f16292286571224237084!
Gordon, When I made/committed the start of the cart.module upgrade, I took a long look at the whole checkout process, and eventually decided that it was simply way beyond me. I think this may well be one of the most complex multi-part forms in any 4.7 module, so we're going to need help from the biggest formAPI gurus around. One resource that may be of help: did you catch merlinofchaos's multi-part form solution which he blogged recently? http://www.angrydonuts.com/multi_page_forms I don't know if this sessions-based approach will actually work for the cart module, but it's worth looking into. Jaza.
Hi, On Thu, 2006-02-16 at 16:30 +1100, Jeremy Epstein wrote:
Gordon,
When I made/committed the start of the cart.module upgrade, I took a long look at the whole checkout process, and eventually decided that it was simply way beyond me. I think this may well be one of the most complex multi-part forms in any 4.7 module, so we're going to need help from the biggest formAPI gurus around.
One resource that may be of help: did you catch merlinofchaos's multi-part form solution which he blogged recently?
http://www.angrydonuts.com/multi_page_forms
I don't know if this sessions-based approach will actually work for the cart module, but it's worth looking into.
I am not too sure, but I did see that there has been some work on sessions and anonymous users will not get a full session so that may store this from working. I think at this stage that this is beynd the current formsapi. I think what needs to happen is a method in the formapi so that you can throw an error in which you can tell the form process to build a completely new form and $POST will be reset. I do have it working but it is ugly. I was hoping that it could be done is use the _validate() and _submit which will be very sexy. Gordon.
Gordon Heydon wrote:
Hi,
On Thu, 2006-02-16 at 16:30 +1100, Jeremy Epstein wrote:
Gordon,
When I made/committed the start of the cart.module upgrade, I took a long look at the whole checkout process, and eventually decided that it was simply way beyond me. I think this may well be one of the most complex multi-part forms in any 4.7 module, so we're going to need help from the biggest formAPI gurus around.
One resource that may be of help: did you catch merlinofchaos's multi-part form solution which he blogged recently?
http://www.angrydonuts.com/multi_page_forms
I don't know if this sessions-based approach will actually work for the cart module, but it's worth looking into.
I am not too sure, but I did see that there has been some work on sessions and anonymous users will not get a full session so that may store this from working.
I think at this stage that this is beynd the current formsapi. I think what needs to happen is a method in the formapi so that you can throw an error in which you can tell the form process to build a completely new form and $POST will be reset.
anonymous users can get a full session at any time someone sets the $_SESSION variable for them. It means, though, that the optimizations for anonymous users without sessions disappear when this form is used. For something like the cart, I think that is perfectly fine.
One resource that may be of help: did you catch merlinofchaos's multi-part form solution which he blogged recently?
I am not too sure, but I did see that there has been some work on sessions and anonymous users will not get a full session so that may store this from working.
anonymous users can get a full session at any time someone sets the $_SESSION variable for them. It means, though, that the optimizations for anonymous users without sessions disappear when this form is used. For something like the cart, I think that is perfectly fine.
I agree with Earl here. Session optimization can be overridden by modules who need it, and ecommerce is a valid reason for this.
complex multi-part forms in any 4.7 module, so we're going to need help from the biggest formAPI gurus around.
I think we have a new solution for multipart. I spent an ungodly amount of time with the (seemingly simple) problem: removing $_POST from poll. I have written at least three different solutions with input from Adrian and webchick (I love live coding runs). None of them cut it. The current solution is, which I think is very clean (and Adrian shares this): call form_builder from poll_form. The patch is already in the queue and if Dries also thinks so, it'll be in core. http://drupal.org/files/issues/poll_post.patch You could do the same. Create a hidden element which tells you which stage you were at. Define the buttons in advance as well. Use #weight and #theme to move these elements to where they should be visible. Call form_builder on the elements. Now you have #value. Based on it, you can make decisions about which form you want to define. Regards Karoly Negyesi
participants (9)
-
Adrian Rossouw -
Ahmed Al-Obaidy -
Earl Miles -
Gordon Heydon -
Jeff Eaton -
Jeremy Epstein -
Karoly Negyesi -
Khalid B -
Simon Lindsay