[
https://issues.apache.org/jira/browse/OFBIZ-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942419#comment-13942419
]
Paul Piper commented on OFBIZ-5312:
-----------------------------------
Anil, I am sorry that I have to say that, but please continue reading after my
first sentence. I said "you can ignore the part about the META-Data and such.
Though it is correct, all options here rely on HTML-Templates for that - since
it is a different topic altogether and you probably already have your own, we
left it out of this picture."
This means: Yes, content is also part of the onpage-optimisation efforts. Your
"meta-data" are part of that, and added through your templates. This ticket is
simply not about any of that.
{quote}
Potentially duplicate content
Anil> With CMS approach you don't have this issue.
{quote}
That is simply not the case. The OFBiz controlservlet handles all requests in
the end. What you fail to mention is that the ofbiz cms integration works as
follows:
1) Request-Redirect Request to "cms" request map, as in:
{code}
<request-map uri="main">
<security https="false" auth="false"/>
<response name="success" type="request" value="cms"/>
</request-map>
{code}
2) Handle Request in CMS Event
{code}
<request-map uri="cms">
<event type="java" path="org.ofbiz.content.cms.CmsEvents" invoke="cms"/>
<response name="success" type="none"/>
<response name="error" type="view" value="error"/>
</request-map>
{code}
3) Set response within the CMS event:
{code}
if (statusCode == HttpServletResponse.SC_OK || hasErrorPage) {
// create the template map
MapStack<String> templateMap = MapStack.create();
ScreenRenderer.populateContextForRequest(templateMap, null,
request, response, servletContext);
templateMap.put("statusCode", statusCode);
// make the link prefix
ServletContext ctx = (ServletContext)
request.getAttribute("servletContext");
RequestHandler rh = (RequestHandler)
ctx.getAttribute("_REQUEST_HANDLER_");
templateMap.put("_REQUEST_HANDLER_", rh);
response.setStatus(statusCode);
{code}
This does not (!) override or change the normal behavior of the OFBiz
Controlservlet or other servlets in place. OOTB OFbiz has one other servlet
that handles product and catalog data:
{code}
<servlet-mapping>
<servlet-name>CatalogUrlServlet</servlet-name>
<url-pattern>/products/*</url-pattern>
</servlet-mapping>
{code}
these calls will remain unless you remove them. The same applies to all
/control/* calls handled by the controlservlet. So unless you rework the entire
way ofbiz handles requests, you are stuck with potentially duplciated content
-> precisely at /control/* and /products/*, not even mentioning the filters.
{quote}
No historisation of former URLs
Anil > WebsitePathAlias entity keeps all valid URLs. When a URL no more exists,
you can forward request for a path alias to something else by setting aliasTo
field.
{quote}
That is not a historisation - a historisation is the storage of former urls and
redirect of those to the new urls if they changed. It could be implemented
using the CMS entities, but currently they do not exist and you would also
require a filter to handle these request-redirects.
{quote}
No automatic generation of URLs for Products
Anil > Automatic URL generation is bad idea but if needed, Simple eca can be
put in place to maintain pathAlias field value e.g When Product name is
modified.
{quote}
ECAs may not be a solution for bulk data. In your demo you only serve less than
25 products per store. I have worked on implementations with up to 1.6 Mio
products. It simply may not be feasible to keep this overhead on store.
{quote}
Increases DB (Database entries)
Anil > I am surprised this is a bad thing.
{quote}
Again - the further you move away from the "few items per store" example, the
more reasonable it becomes to store less. Databases typically still don't
perform all that well with large indices and performance goes out the window
{quote}
Requires additional manual work for all entries --> potentially risky when used
by non-tech people
Anil > Maintaining Content data is not much different from maintaining Product
data. With right scripts data maintenance is not that hard.
{quote}
You are a developer, you may be able to handle 4 entries per product. Your
average customer won't ... you can trust me on this.
> Proposal: URL-Generation Changes (mostly for SEO reasons but not only)
> ----------------------------------------------------------------------
>
> Key: OFBIZ-5312
> URL: https://issues.apache.org/jira/browse/OFBIZ-5312
> Project: OFBiz
> Issue Type: New Feature
> Components: specialpurpose/ecommerce
> Affects Versions: SVN trunk
> Reporter: Jacques Le Roux
> Assignee: Jacques Le Roux
> Priority: Minor
> Labels: changes, ecommerce, friendly, seo, url
> Fix For: SVN trunk
>
> Attachments: OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 -
> ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312
> - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch,
> OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 -
> ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312
> - ofbiz-ecommerce-seo.patch, OFBIZ-5312 - ofbiz-ecommerce-seo.patch,
> OFBIZ-5312 - ofbiz-ecommerce-seo.patch, OFBIZ-5312 -
> ofbiz-ecommerce-seo.patch, OFBiz-5312-product-ecommerce-seo-20131031.patch,
> OFBiz-5312-product-ecommerce-seo-for-seo-branch.patch,
> OFBiz-5312-product-ecommerce-seo.patch, SeoContextFilter.java.patch
>
>
> [This was proposed by Paul Piper in Nabble 7 months
> ago|http://ofbiz.135035.n4.nabble.com/Proposal-URL-Generation-Changes-td4639289.html].
> Here is quoted Paul's proposal
> {quote}
> 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
> {quote}
> There is even a patch, mostly done by Jinghai Shi, that I attach here. Even
> if it has been already used in [Syracus|http://syracus.net/] since early this
> year, some help would be needed to test it thoroughly in OFBiz.
> Then we should discuss if it's the way to go. I believe it is. Who needs a
> /control/ or /main by default in ecommerce urls? Would you not prefer
> http://localhost:8080/ecommerce/ over
> http://localhost:8080/ecommerce/control/main ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
