So currently I would like to just pass in the ids instead. Otherwise we have worry about things like & in a Category name for example and how we work with this ideally . I would like to
So I could pass the last two bits through a bit of code to get rid of any dangerous characters and poor formatting and not have to worry about it breaking my url write as I would be using int for a key.
This would give maxium flexibility on URL write and reduce the overhead and the complexity of it in an installation.
Any chance that this will be the case for future releases?
From a SEO point of view the optimum way of doing URLs would be to include as much keyword rich information as you can. Lasse's article is written with this in mind.
However, you can do what you're after with the current release of uCommerce with categories at least. There are XSLT APIs which will access categories by id and the id is part of the XML output as well.
If you're working with .NET you have complete freedom to work your URLs however you want.
This is the first request I've seen for working exclusively with id's for products and catalogs, so it's not on the roadmap for now. We're open to making the change, but it's really only necessary for the XSLT API.
If you can add it to the road map that would be great. I am pretty sure I am using Encoding and Decoding.. But not in front of the code base, will post when I am to show you my problem.
The main reason for ids though is that you can also mix up your URL without any connection to your data format underneath. For example I might want to give my URL name a totally different naming set to what is on the catlog or more likely an connecting words to the page. Either way IDs give maxium flexibility and surely most be more efficent way to call the catergoies and the products ? As they must be primay keys and unqiue indexed in the system?
I agree that the ids makes for the most flexible solutions. We chose the names to make the API more friendly to work with.
You're absolutely right about the performance implications when you query based on strings. Although with the caching introduced in uCommerce 1.3 you'll probably not even notice.
Are you working with the APIs using XSLT or .NET by the way?
Working with the API in XSLT currently, tbh think working with names although may appear more friendly to a developer will cause major dramas for supportability and also when you have large scale ecommerce. i.e What happens if a user changes a catlog name it likely to break host of stuff.
Is there some better options in .net ?
Any chance I can extend you framework i.e inherit it or override ? So I can get the process of working with a ID going ?
There's not really a difference between using an id over a name. Essentially the name or name will never be hardcoded but rather loaded at runtime and added where needed, but that aside you can of course override the default and work with ids.
You will have to drop into .NET to do it as the XSLT library is currently wired to work off of the names and SKUs of catalogs and products. For categories you can work with ids purely as it stands today.
What you can do is build your own extension to render a catalog and product as XML. All the pieces are in there for you to use. The new extension would grab the id from URL or something context and use our built in XML renderer to render output to XSLT.
Every object in uCommerce has an XmlRenderer associated with it, which will do the job for you. Take a look at ProductCatalogGroupRenderer, ProductCatalogRenderer, and ProductRenderer found in the UCommerce.Xslt.Renderings and UCommerce.EntitiesV2.Spike.Renderings namespaces.
I've got some good news for you. As of uCommerce 1.4 you'll be able to use name/id interchangably for APIs requiring a name today. The support was added for the new nice url generator, which will use a scheme much like the one you describe in your first post.
UrlRewrite and Passing IDs instead of names
Hi,
I would like to urlrewrite without having to worry about names in URL.
http://blog.lasseeskildsen.net/post/Setting-Up-Simple-URL-Rewriting-In-uCommerce.aspx
So currently I would like to just pass in the ids instead. Otherwise we have worry about things like & in a Category name for example and how we work with this ideally . I would like to
http://myshop.com/12/123/catlogName/Productname.aspx
So I could pass the last two bits through a bit of code to get rid of any dangerous characters and poor formatting and not have to worry about it breaking my url write as I would be using int for a key.
This would give maxium flexibility on URL write and reduce the overhead and the complexity of it in an installation.
Any chance that this will be the case for future releases?
Cheers,
James
From a SEO point of view the optimum way of doing URLs would be to include as much keyword rich information as you can. Lasse's article is written with this in mind.
However, you can do what you're after with the current release of uCommerce with categories at least. There are XSLT APIs which will access categories by id and the id is part of the XML output as well.
If you're working with .NET you have complete freedom to work your URLs however you want.
This is the first request I've seen for working exclusively with id's for products and catalogs, so it's not on the roadmap for now. We're open to making the change, but it's really only necessary for the XSLT API.
BTW if you make sure to do a UrlEncode on the way out and a decode on the way you should be covered as far as unwelcome characters are concerned.
Hi Soren,
If you can add it to the road map that would be great. I am pretty sure I am using Encoding and Decoding.. But not in front of the code base, will post when I am to show you my problem.
The main reason for ids though is that you can also mix up your URL without any connection to your data format underneath. For example I might want to give my URL name a totally different naming set to what is on the catlog or more likely an connecting words to the page. Either way IDs give maxium flexibility and surely most be more efficent way to call the catergoies and the products ? As they must be primay keys and unqiue indexed in the system?
Cheers,
James
I agree that the ids makes for the most flexible solutions. We chose the names to make the API more friendly to work with.
You're absolutely right about the performance implications when you query based on strings. Although with the caching introduced in uCommerce 1.3 you'll probably not even notice.
Are you working with the APIs using XSLT or .NET by the way?
Hi Soren,
Working with the API in XSLT currently, tbh think working with names although may appear more friendly to a developer will cause major dramas for supportability and also when you have large scale ecommerce. i.e What happens if a user changes a catlog name it likely to break host of stuff.
Is there some better options in .net ?
Any chance I can extend you framework i.e inherit it or override ? So I can get the process of working with a ID going ?
Cheers,
James
There's not really a difference between using an id over a name. Essentially the name or name will never be hardcoded but rather loaded at runtime and added where needed, but that aside you can of course override the default and work with ids.
You will have to drop into .NET to do it as the XSLT library is currently wired to work off of the names and SKUs of catalogs and products. For categories you can work with ids purely as it stands today.
What you can do is build your own extension to render a catalog and product as XML. All the pieces are in there for you to use. The new extension would grab the id from URL or something context and use our built in XML renderer to render output to XSLT.
Every object in uCommerce has an XmlRenderer associated with it, which will do the job for you. Take a look at ProductCatalogGroupRenderer, ProductCatalogRenderer, and ProductRenderer found in the UCommerce.Xslt.Renderings and UCommerce.EntitiesV2.Spike.Renderings namespaces.
I've got some good news for you. As of uCommerce 1.4 you'll be able to use name/id interchangably for APIs requiring a name today. The support was added for the new nice url generator, which will use a scheme much like the one you describe in your first post.
is working on a reply...