That also doesn't capture it. Here's just a few reasons why: - The current implementation tries to "hide" the actual /control request flow by creating a set of internal forwards based on a fixed category or product path (using a filter). It doesn't really fix it, it just works around it - It neither fixes the flow for all other pages outside of categories or products (as can be seen here http://demo-trunk.ofbiz.apache.org:8080/ecommerce/control/main), nor does it actually handle the request flow correctly. - It is also ubiquitous with regards to the url structure, while trying to identify categories and products by "-p" and "-c" respectively. - It isn't configurable. Any change to the url (in particular a removal of "-p") has to be hardcoded into CatalogUrlFilter - It creates duplicate entries, which is just a bad idea: https://demo-trunk.ofbiz.apache.org:8443/ecommerce/products/WG-1111 vs https://demo-trunk.ofbiz.apache.org:8443/ecommerce/micro-chrome-widget-WG-1111-p - It relies on the use of an additional "alternative content url" stored in table, which makes it pretty difficult to be used in live applications with many entries and where batch imports are common. Products or categories without those entries, will not be captured correctly.
-- View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-URL-Generation-Changes-tp4639289p4639293.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
