|
Hey Everyone,
over at ilscipio (www.ilscipio.com) we developed a set of functional OFBiz changes that we believe the entire community could benefit from. The changes have been implemented in parts in Syracus (www.syracus.net) for a while now, but we figured that some of which are too crucial for ofbiz' success in the long run, so we are considering the contribution (as we did with the SOLR component). As you are probably aware, OFBiz has a pretty uncommon way of generating URLs. Most of this has to do with the fact that OFBiz uses a servlet (ControlServlet) to handle all requests. The servlet is mounted at /control, so that it won't interfere with other servlets. Though functionally valid, this has the sideeffect that all urls are actually created on /control, which is neither pretty, nor good by any measures of SEO. It also means that a few 302 redirects are necessary to forward the user from / to /control/main. It also makes requests more complicated, since many forwards are necessary whenever somebody wants to move away from this implementation. Since this is hurtful to many of the implementers, I wanted to discuss whether or not you guys would be interested in the changes we have made. The functional changes contain: * Removal of /control out of all the urls * SEO-friendly URLS * Configurable product/category and other URLs * Frontpage mapping from /main to / It was tested on our end and contains all necessary improvements (Transforms, Sample Configuration, Servlets & Filters) for it to be applicable. If interested, I would create a new JIRA ticket for this and after a few minor internal discussions, we will gladly provide the rest of you with it. Regards, Paul |
|
better check the trunk version where we already implemented this?
Regards, Hans On 02/09/2013 04:51 PM, Paul Piper wrote: > Hey Everyone, > > over at ilscipio (www.ilscipio.com) we developed a set of functional OFBiz > changes that we believe the entire community could benefit from. The changes > have been implemented in parts in Syracus (www.syracus.net) for a while now, > but we figured that some of which are too crucial for ofbiz' success in the > long run, so we are considering the contribution (as we did with the SOLR > component). > > As you are probably aware, OFBiz has a pretty uncommon way of generating > URLs. Most of this has to do with the fact that OFBiz uses a servlet > (ControlServlet) to handle all requests. The servlet is mounted at > /control, so that it won't interfere with other servlets. Though > functionally valid, this has the sideeffect that all urls are actually > created on /control, which is neither pretty, nor good by any measures of > SEO. It also means that a few 302 redirects are necessary to forward the > user from / to /control/main. It also makes requests more complicated, since > many forwards are necessary whenever somebody wants to move away from this > implementation. > > Since this is hurtful to many of the implementers, I wanted to discuss > whether or not you guys would be interested in the changes we have made. The > functional changes contain: > > * Removal of /control out of all the urls > * SEO-friendly URLS > * Configurable product/category and other URLs > * Frontpage mapping from /main to / > > It was tested on our end and contains all necessary improvements > (Transforms, Sample Configuration, Servlets & Filters) for it to be > applicable. > > If interested, I would create a new JIRA ticket for this and after a few > minor internal discussions, we will gladly provide the rest of you with it. > > Regards, > Paul > > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-URL-Generation-Changes-tp4639289.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
Hi Hans,
this is not about the https://issues.apache.org/jira/browse/OFBIZ-5109, if that is what you are refering to... |
|
No,
Check the alternative url on category, product and content...... On 02/09/2013 05:36 PM, Paul Piper wrote: > Hi Hans, > > this is not about the https://issues.apache.org/jira/browse/OFBIZ-5109, if > that is what you are refering to... > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Proposal-URL-Generation-Changes-tp4639289p4639291.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
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. |
|
Paul please study it more it is extremely flexible, multi-language and
is making full use of the content component... But sure it you know better , improve it! Regards, Hans On 02/09/2013 06:33 PM, Paul Piper wrote: > 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. |
|
@hans: we did and i think we added enough thought to this. I think it is rather time to discuss proper changes than get on the fences about keeping something that is apparently broken... just my two cents
|
|
Administrator
|
I wonder why this message did to reach the dev ML though it was not retained by Nabble. So this reply only to push it to the dev ML... |
|
Administrator
|
To be more clear, this is because I want to clarify this point:
https://issues.apache.org/jira/browse/OFBIZ-5312?focusedCommentId=13799891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13799891 <<Hi Paul, Then we wil need to fix Hans's current implementation, see linked issues... We hoped that replacing it would remove those, anyway we will see then...>> Jacques Jacques Le Roux wrote: > Paul Piper wrote >> @hans: we did and i think we added enough thought to this. I think it is >> rather time to discuss proper changes than get on the fences about keeping >> something that is apparently broken... just my two cents > > I wonder why this message did to reach the dev ML though it was not retained > by Nabble. So this reply only to push it to the dev ML... |
| Free forum by Nabble | Edit this page |
