Hello Volunteers,
While I would much rather this issue be dealt with entirely in the MVC
spec, it is clear that our community wants JSF to do something about URL
mapping in 2.3.
Here are some points from other emails that I'd like to corral into this
thread.
AT> I do have to stress that the proposed /views folder is -an- enabler,
AT> but I'm of course open to explore other options to reach the same
AT> goal (prevent source code exposure and determine if a Facelet is a
AT> top-level view or not).
FC> Id like to go with the facelet scanning.
FC> I have another point about extensionless mapping. If the main
FC> purpose is SEO, than this only helps for english web sites. Most
FC> projects I have seen In Germany usually use english as the technical
FC> language. So all facelets have english names. But for SEO they need
FC> german URLs. I believe it is the same for many other countries. Are
FC> there any other use cases for extensionless mapping?
AT> For extensionless mapping it's kinda important to know which things
AT> are views, and which things are not views.
FC> I still think, scanning all facelets on startup and looking for an
FC> f:view tag is an option to find all views. I have a project with
FC> more than 1300 facelets doing this. It takes about a second.
>>>>> On Mon, 2 Mar 2015 22:32:02 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> I know we already took 3 steps back from the original proposal, but
AT> maybe we should take yet another step back.
AT> What if we started with *only* specifying that if a user manually
AT> mapped the Faces Servlet using an extensionless "exact mapping"
AT> (according to the definition of the Servlet spec), that this works?
AT> E.g. given
AT> <servlet>
AT> <servlet-name>facesServlet</servlet-name>
AT> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
AT> <load-on-startup>1</load-on-startup>
AT> </servlet>
AT> <servlet-mapping>
AT> <servlet-name>facesServlet</servlet-name>
AT> <url-pattern>/foo</url-pattern>
AT> <url-pattern>/bar/kaz</url-pattern>
AT> </servlet-mapping>
AT> A request to
http://host.net/foo should then resolve to the Facelet
AT> /foo.xhtml and
http://host.net/bar/kaz should resolve to
AT> /bar/kaz.xhtml
AT> This is a necessary step anyway, and at this point no scanning of view
AT> files or /views folder or anything are necessary yet.
FC> Maybe we can have a Java-API. E.g. Application.addView(String mapping,
FC> String faceletPath), which is automatically called by JSF with the
FC> discovered (no matter how they are discovered) views and the default
FC> mapping, which is the extensionless facelet path. This can be overridden by
FC> the developer to change the mapping.
AT> Might be a good idea to look in such an API indeed. This could also be
AT> handy for resource handlers that get their views from a special
AT> location where JSF normally can't look directly. Programmatic exact
AT> mappings for the FacesServlet can only be done at startup time (this
AT> is a Servlet restriction), so this is something that has to be taken
AT> into account.
FC> IMO it is important to design new features as generic as possible and let
FC> developers customize them.
AT> True, best case would be IMHO to have a generic base version in JSF to
AT> which I can re-base the existing OmniFaces feature (which offers more
AT> options than what will likely be acceptable for JSF core).
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 3 days til DevNexus 2015
| 13 days til JavaLand 2015
| 23 days til CONFESS 2015