Hi,
On Mon, Mar 2, 2015 at 8:54 PM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> reddit is a good example for bad SEO with english URLs in german. If you
> search for "reddit vergoldet“ in german the first hit is some kind of
> comments. The second hit is reddit.com/gilded, which should be the first
> hit.
You're right, of course these URLs don't do much for i18n SEO. But
what I meant is that quite a lot of web sites use extensionless URLs
without having any i18n'ed version of them. The URLs just look cleaner
that way, are easier to print on paper, are easier to type, easier to
remember etc.
Reddit and the other sites mentioned gather to an international
audience and that international audience is apparently fine with using
English, and also predominantly uses English to search for the
features on the site.
Then there are the domestic sites that pretty much target one
language. These can be covered as well, even when the Facelets names
are in English but the URLs are required to be in a domestic language
by using nearly empty Facelets with a domestic language name that
directly includes the Facelet with the English name. If you only
support one language, then link rendering is trivial. If you want to
support URLs that dynamically change based on the language that's
currently used, then something more advanced is needed.
We have extensionless URLs without such advanced language switching
support out for nearly 2 years in OmniFaces, and as far as I can tell
people are happily using it. We had one or two requests for more
advanced functionality, and we simply directed those to
PrettyFaces/Rewrite.
> I’d like to have a solution, which can be easily used by the developer.
I agree ;)
I know we already took 3 steps back from the original proposal, but
maybe we should take yet another step back.
What if we started with *only* specifying that if a user manually
mapped the Faces Servlet using an extensionless "exact mapping"
(according to the definition of the Servlet spec), that this works?
E.g. given
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>/foo</url-pattern>
<url-pattern>/bar/kaz</url-pattern>
</servlet-mapping>
A request to
http://host.net/foo should then resolve to the Facelet
/foo.xhtml and
http://host.net/bar/kaz should resolve to
/bar/kaz.xhtml
This is a necessary step anyway, and at this point no scanning of view
files or /views folder or anything are necessary yet.
> Maybe we can have a Java-API. E.g. Application.addView(String mapping,
> String faceletPath), which is automatically called by JSF with the
> discovered (no matter how they are discovered) views and the default
> mapping, which is the extensionless facelet path. This can be overridden by
> the developer to change the mapping.
Might be a good idea to look in such an API indeed. This could also be
handy for resource handlers that get their views from a special
location where JSF normally can't look directly. Programmatic exact
mappings for the FacesServlet can only be done at startup time (this
is a Servlet restriction), so this is something that has to be taken
into account.
> IMO it is important to design new features as generic as possible and let
> developers customize them.
True, best case would be IMHO to have a generic base version in JSF to
which I can re-base the existing OmniFaces feature (which offers more
options than what will likely be acceptable for JSF core).
Kind regards,
Arjan
>
> Ciao Frank