Hi,
On Sun, Mar 1, 2015 at 6:11 PM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> I still think, scanning all facelets on startup and looking for an f:view tag is an option to find all views. I have a project with more than 1300 facelets doing this. It takes about a second.
Scanning Facelets is not the big issue, but not all of the top-level
ones have the f:view tag (at least not in source). If the
assembled/compiled Facelet always does have it when inspecting it, and
if at the same time includes, composites, tag-files etc don't have it,
then this could be an alternative (frankly, I've never checked if this
is the case or not).
As said before, /views is an enabler, not a goal by itself. If the
FacesServlet is by default mapped to *.xhtml AND there is indeed a
guaranteed 100% safe way to determine if a given Facelet is a top
level view or not, then this would both prevent source exposure as
well as allow extensionless mapping.
It does leave us with the tiny technicality that if you indeed use it
this way, your view will be without further action be available via 2
paths. Of course we can return a 404 for the *.xhtml variant, and in
fact this is exactly what OmniFaces does. Only, in OmniFaces we leave
it as a setting to the user as expressed by the following enum:
public enum ExtensionAction {
/** Send a 404 (not found), makes it look like e.g. "foo.xhtml"
never existed and there's only "foo". */
SEND_404,
/** Redirects to the same URL, but with the extension removed.
E.g. "/foo.xhtml" is redirected to "/foo". */
REDIRECT_TO_EXTENSIONLESS,
/** No special action is taken. Both "/foo.xhtml" and "/foo" are
processed as-if they were separate views (with same content). */
PROCEED;
}
As I understood the idea for JSF 2.3 is to have less (new) settings,
so we'd have to choose an option here I guess.
> We can send a 403 if there is no f:view tag in the requested facelet.
A 404 is probably better, as a 403 reveals the existence of the file.
E.g. it lets an attacker find out there's an /admin/panel, which is
information that might be used in other attacks.
> I’d like to go with the facelet scanning.
I'd like to mention that for /views you'd also do "scanning", although
this scanning would be far simpler; just looking at the file listing
that are in the folder and its sub-folders (no need to look at the
content).
> I have another point about extensionless mapping. If the main purpose is SEO, than this only helps for english web sites. Most projects I have seen In Germany usually use english as the technical language. So all facelets have english names. But for SEO they need german URLs.
True, as a Dutch user having previously worked on a product
exclusively targeting the Dutch market we were pretty much in the same
boat.
As a matter of fact the proposed solution is indeed very bare bones.
As I think I mentioned before, I can see how some users may be
disappointed by such an overly simple solution. It's perhaps not
entirely unlike resource contracts which eventually was a rather
watered down version of the initial "promise" of multi-templating and
skinning, but at least we got that (the alternative would be to have
had nothing at all for 2.2).
The point is that obviously big features which require a lot of design
and spec work are hard to get into JSF these days. We're some 7 months
into the 2.3 spec cycle now and there hasn't been much agreement on
any more advanced solution, plus several parties have indicated that
resources are an issue.
This simple solution is not all encompassing, I know that. But it's
something that gets the ball going IMHO and should be relatively
simple to implement and spec. Basic use cases are covered, and users
and/or libraries can then build on it to support more advanced
scenarios.
> I believe it is the same for many other countries. Are there any other use cases for extensionless mapping?
There are quite a lot of websites that appeal to an international
audience, and most if not all of them use extensionless mappings these
days with English URLs:
For example:
* stackoverflow.com/questions
* stackoverflow.com/users/login
* reddit.com/prefs
* reddit.com/message/inbox
* facebook.com/login
* tumblr.com/login
* etc
And of course our own showcase:
* showcase.omnifaces.org/whatsnew
* showcase.omnifaces.org/cdi/Eager
For all these use cases the proposed solution would work fine. For per
region localization of URLs an other solution would have to be used,
e.g. PrettyFaces.
Kind regards,
Arjan Tijms
>
> Ciao Frank
>