Hi,
On Tue, Nov 4, 2014 at 5:50 AM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> 1. There is no way to know which files generate view definitions in java,
> which ones generate components and which ones are templates.
So that's where the dedicated views folder comes in. Every file in
there is by definition a view.
Alternatively (or in addition to that) you can let the user specify a
pattern. In OmniFaces we do both.
> 2. Performance: Precompile every single view in the app on startup, even
> if it is only to get metada information could take some time.
Yes, it definitely takes some time, but as I mentioned I don't think
we should be too afraid of this.
Users who don't mind an additional second or so when starting up
(depending on the size of their app and performance of their hardware)
could use the metadata. Users in more constrained systems could
disable scanning (or not opt-in to it, depending on what will be the
default) and use a centralized approach in faces-config.xml.
The arguments are not that different from what CDI extensions do. The
CDI runtime scans through an amazing amount of classes and calls an
arbitrary amount of extensions, potentially for each and every class
encountered. Extensions may do expensive and time consuming things
like scanning for custom annotations and accessing things via
reflection.
I have to agree that my first reaction back in 2008 or so was; this
can't possible work! This will add minutes to the startup time and
servers will run instantly out of memory after indexing so many
classes as Beans.
Yet, it somehow worked.
> This is an issue
> for cloud environments like Google Application Engine (GAE) and it is
> also a memory issue, because once compiled, the views stays in
> memory until the app is undeployed. We are talking about parse dozens
> or hundreds of .xhtml files at once, not without decompress .jar files
> and so on.
Dozens or hundreds is not really that much compared to the thousands
or maybe then thousands of classes that CDI may scan, and many are in
jar files as well. As long as the facility is optional I don't think
this particular aspect (fear of long startup times and high memory
consumption) should hold us back.
> 3. Resource scanning: Each time we need to do some kind of scanning,
> we need to provide an SPI interface for that, because the application
> server could require override this part. This requeriment will make
> ResourceHandler.createView(...) and ResourceResolver useless,
> because we need something that could scan for the views available,
> so we will be forced to include a new interface, breaking backward
> compatibility.
I largely agree with this. If anything, this would be a much bigger hurdle IMHO.
With JDK 8 default methods it might not be required to break backward
compatibility. This JDK 8 feature was specifically introduced for
involving interfaces and could play to our advantage here.
Maybe something like ResourceHandler.listViews could be added, with a
default method that just returned an empty list.
It could well be that some ResourceHandlers simply can't support
listing their views. In that case the user would just not be allowed
to map those views. That would then simply be the limitation of this
feature.
> 3. Modularity: One possible use case is load views from a database. For
> cases where the views are loaded from different locations, it would not
> work, so we could have cases where use the attribute in f:view will just
> not work.
I'm not really sure how this is different from the case above. If
views are loaded from a database, and the ResourceHandler is enhanced
with the ability to list the views it provides, then wouldn't this
just work? Databases are especially easy to query.
> The idea of hold metadata with the data has sense, the only problem
> is this is not metadata information of the view, it is information about
> the relationship between the views and the url mappings. In other
> words, the views should still work without the view-url mapping
> information.
It's a good question of whether the original (default) view mapping
would still be available.
E.g. by default [web root]/foo.xhtml can be requested using say
http://localhost:8080/app/foo.jsf
If there's a mapping available for [web root]/foo.xhtml, would the
above URL still be valid, or will the new mapping override the default
one?
In OmniFaces we had a similar issue and provided a switch where the
user can chose to either hide the original mapping (404) or respond
with a redirect to the new mapping.
Kind regards,
Arjan Tijms