From what I can see, the uCommerce out-of-the-box store works by using html forms around all the different blocks of XSLT that provide functionality. For example, to update the cart, it posts to its itself, or in another example the address information form posts to the shipping page.
What's confusing me a little is that, normally I wrap a runat server form around everything, and just group my (server-side) forms together. That way I don't need to put any of my forms in a form tag, i just stick them in an asp:Panel and set a default button or whatever, and have as many on my page from as many user controls as I need. I'm guessing this is fairly standard practice?
I tried chopping out the form declarations from the uCommerce XSLT and just keeping one in my master page, but this breaks any forms that are meant to post to another page. By taking the runat server form out of my master page, I think I run the risk of giving myself problems when it comes to multiple user control forms (contact fields, subscriptions, searches etc) I might have around the place, but I certainly don't want to have to re-code the functionality that the uCommerce Store provides. Or maybe I'm just an idiot and I'm doing something fundamentally wrong here. What's the best practice with uCommerce?
I had a long post written up with pros and cons, but my browser session decided to die on me, so here's the short version:
1) Use jQuery to do AJAX posts instead of the form.
2) Separate master pages for webforms and XSLT pages. One top master page with your common design elements and underneath that two additional masterpages: One with the ASP.NET form and one without. Choose which you want to use on a per page basis.
3) Multiple forms on one page: Have your ASP.NET form on the same page as HTML forms, but avoid nesting them. You'll only be able to use your .NET control in that one form so you'll lose some flexibility.
4) Post to same page using the default ASP.NET form. When a button is clicked the name of the button will be part of the form values so you could check whether the button is of interest to you and handle some areas with XSLT and leave the rest to ASP.NET.
Personally I'd go with option 1. It's the simplest, gives you the flexibility you need, and lets you reuse all the functionality of the uCommerce Store with only minor changes required.
Hmm, interesting options. I'm leaning towards number 1 there, or possibly a combination of 2 and 3.
I had another idea, more of a curiosity really as I'm not sure what it'd break. I keep the ASP.NET form in the master page surrounding everything, remove the forms from the XSLT files, and then use some javascript in the XSLTs to target ASP.NET form and change the action attribute where neccesary (for pages that don't post to themselves, e.g. address > shipping). However I imagine this would break any .NET controls that post on said page (although you could perhaps only change the attribute on button press...). What do you think?
Interesting approach. It would be fun to try, but you're right that it would be pretty prone to errors and you'd have the script to deal with as well. I like option 1 for the simple fact that it's self-contained. That has served me well in the past :)
uCommerce Store forms
Hi guys,
From what I can see, the uCommerce out-of-the-box store works by using html forms around all the different blocks of XSLT that provide functionality. For example, to update the cart, it posts to its itself, or in another example the address information form posts to the shipping page.
What's confusing me a little is that, normally I wrap a runat server form around everything, and just group my (server-side) forms together. That way I don't need to put any of my forms in a form tag, i just stick them in an asp:Panel and set a default button or whatever, and have as many on my page from as many user controls as I need. I'm guessing this is fairly standard practice?
I tried chopping out the form declarations from the uCommerce XSLT and just keeping one in my master page, but this breaks any forms that are meant to post to another page. By taking the runat server form out of my master page, I think I run the risk of giving myself problems when it comes to multiple user control forms (contact fields, subscriptions, searches etc) I might have around the place, but I certainly don't want to have to re-code the functionality that the uCommerce Store provides. Or maybe I'm just an idiot and I'm doing something fundamentally wrong here. What's the best practice with uCommerce?
Hi Zac,
I had a long post written up with pros and cons, but my browser session decided to die on me, so here's the short version:
1) Use jQuery to do AJAX posts instead of the form.
2) Separate master pages for webforms and XSLT pages. One top master page with your common design elements and underneath that two additional masterpages: One with the ASP.NET form and one without. Choose which you want to use on a per page basis.
3) Multiple forms on one page: Have your ASP.NET form on the same page as HTML forms, but avoid nesting them. You'll only be able to use your .NET control in that one form so you'll lose some flexibility.
4) Post to same page using the default ASP.NET form. When a button is clicked the name of the button will be part of the form values so you could check whether the button is of interest to you and handle some areas with XSLT and leave the rest to ASP.NET.
Personally I'd go with option 1. It's the simplest, gives you the flexibility you need, and lets you reuse all the functionality of the uCommerce Store with only minor changes required.
Hmm, interesting options. I'm leaning towards number 1 there, or possibly a combination of 2 and 3.
I had another idea, more of a curiosity really as I'm not sure what it'd break. I keep the ASP.NET form in the master page surrounding everything, remove the forms from the XSLT files, and then use some javascript in the XSLTs to target ASP.NET form and change the action attribute where neccesary (for pages that don't post to themselves, e.g. address > shipping). However I imagine this would break any .NET controls that post on said page (although you could perhaps only change the attribute on button press...). What do you think?
Thanks for your time once again Søren.
Interesting approach. It would be fun to try, but you're right that it would be pretty prone to errors and you'd have the script to deal with as well. I like option 1 for the simple fact that it's self-contained. That has served me well in the past :)
is working on a reply...