We are currently trying to get our head around the exapnsive amount of functions available within uCommerce and looking at the XSLT demo store example and trying to look at the functions in order to convert them to razor.
Would we still use UCommerce.XSLT to call some functions like 'Library.EditBillingInformation'?
I have also seen in some examples using UCommerce.EntitiesV2 - is this more used for calling product information etc?
And finally UCommerce.Runtime seems to be used for things like basket totals?
Is this correct and are we on the right path or have we missed something? We would prefer to create our macros from Razor files as we are more comfortable with Razor than XSLT.
I was just coming to this forum to ask a similar question:
For instance, I've still found I have to use UCommerce.Xslt.Library.GetNiceUrlForCategory to get the URLs for a list of categories. This doesn't really "feel" right. Is there a better way? Ideally it would be nice if the Category class had a URL method.
If we still have to use UCommerce.Xslt.Library then perhaps it could be aliased in another more meaningful namespace?
Also, is there a better way of initialising entities from the values passed in the query string? At the moment I'm doing something like this:
int catalogId;
ProductCatalog catalog = null;
if (int.TryParse(Request.QueryString["catalog"], out catalogId))
{
catalog = ProductCatalog.Get(catalogId);
}
Is there a better way than this? I was going to make my own library, but wanted to check I wasn't reinventing the wheel.
@Kenny: Using the XSLT functions will in many cases save you some time as they deal with the underlying objects for you. So all in all much easier to work with. You can of course drop down a level and work with the objects themselves. This is pretty common to do if you need to override specific behaviors in the API.
@Dan:
Regarding the URL you can use the XSLT library, but also you can leverage our DI container directly:
var urlService = ObjectFactory.Instance.Resolve<IUrlService>(); urlService.GetUrl(catalog);
The way you're loading objects is just right. We tend to use extension methods and hook them up on the CatalogContext, so you can go
The extension method essentially encapsulates the code you posted, but saved some duplication and makes it a little simpler to work with. Here's what the extension method looks like:
public static ProductCatalog(this ICatalogContext target) { string catalogIdStirng = Request.QueryString["catalog"]; int catalogId;
ProductCatalog catalog = null;
if (int.TryParse(catalogIdString, out catalogId))
{
catalog = ProductCatalog.Get(catalogId);
}
throw new ConfigurationErrorsException(string.Format("Catalog with id {0} not found", catalogIdString)); }
Razor Functionality
Hi Guys,
We are currently trying to get our head around the exapnsive amount of functions available within uCommerce and looking at the XSLT demo store example and trying to look at the functions in order to convert them to razor.
Would we still use UCommerce.XSLT to call some functions like 'Library.EditBillingInformation'?
Example:
using UCommerce.Xslt;
protected void btnContinue_Click(object sender, EventArgs e)
{
Library.EditBillingInformation(txtFirstname.Text, txtSurname.Text, txtEmail.Text, txtTelephone.Text, txtMobile.Text, txtCompany.Text, txtAddress1.Text, txtAddress2.Text, txtPostcode.Text, txtCity.Text, txtCounty.Text, "", Convert.ToInt32(ddlCountry.SelectedValue));
}
I have also seen in some examples using UCommerce.EntitiesV2 - is this more used for calling product information etc?
And finally UCommerce.Runtime seems to be used for things like basket totals?
Is this correct and are we on the right path or have we missed something? We would prefer to create our macros from Razor files as we are more comfortable with Razor than XSLT.
Any help greatly appreciated!
Thanks
Kenny
I was just coming to this forum to ask a similar question:
For instance, I've still found I have to use UCommerce.Xslt.Library.GetNiceUrlForCategory to get the URLs for a list of categories. This doesn't really "feel" right. Is there a better way? Ideally it would be nice if the Category class had a URL method.
If we still have to use UCommerce.Xslt.Library then perhaps it could be aliased in another more meaningful namespace?
Also, is there a better way of initialising entities from the values passed in the query string? At the moment I'm doing something like this:
int catalogId; ProductCatalog catalog = null; if (int.TryParse(Request.QueryString["catalog"], out catalogId)) { catalog = ProductCatalog.Get(catalogId); }Is there a better way than this? I was going to make my own library, but wanted to check I wasn't reinventing the wheel.
@Kenny: Using the XSLT functions will in many cases save you some time as they deal with the underlying objects for you. So all in all much easier to work with. You can of course drop down a level and work with the objects themselves. This is pretty common to do if you need to override specific behaviors in the API.
@Dan:
Regarding the URL you can use the XSLT library, but also you can leverage our DI container directly:
The way you're loading objects is just right. We tend to use extension methods and hook them up on the CatalogContext, so you can go
The extension method essentially encapsulates the code you posted, but saved some duplication and makes it a little simpler to work with. Here's what the extension method looks like:
Brilliant, thanks Soren! I find it always best to get a bit of expert advice before embarking too far down the road.
Thanks Soren!
is working on a reply...