Hi
AT>I agree with this. The pattern where meta data is specified with the
AT>artifact to which it applies instead of in some central file certainly
AT>looks to be the most popular way now (see also my recent mail to this
AT>list regarding 1196-faceletTagConveniences). Just think of the URL
AT>specified in @WebServlet for Servlets or @Path for JAX-RS.
There are some problems with this I would like to mention:
1. There is no way to know which files generate view definitions in java,
which ones generate components and which ones are templates.
2. Performance: Precompile every single view in the app on startup, even
if it is only to get metada information could take some time. 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. I foresee applications that take several minutes to be loaded.
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.
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.
Is this url pattern - view id bidirectional mapping an attribute of the view?
or is this a configuration param of the JSF Front Controller? I would say
the second, because this is something you want to customize in a
per module base, along with the navigation and the flow definition.
I like more the idea of define this in a bean like JSF does with
@FlowDefinition annotation.
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.
In my opinion the problem has two critical points:
1. Map urls to views, so when the url is passed, the request could be
redirected to the right view.
2. Use the mapping pattern to render every link that points to a view
with that mapping in a transparent way.
JSF should be always in control of how the link or url is generated,
otherwise things like portlets that rewrite the urls too will just not
work. It is also a problem about reutilization. Once you have hard
coded urls in you page, you cannot change or move those urls,
and at the end it becomes a pain to assemble multiple modules
together.
AT>Yet, as with almost all such meta data, an override in a central (XML)
AT>file should be possible as well. And of course this very same file can
AT>also be the primary source of the mappings; it should not be required
AT>that it has to override an existing meta data section in a view. I
AT>think that with such setup we can address both Kito's and Frank's use
AT>case, can't we?
Yes. In fact the same idea worked with <f:view contracts="..."/>, we can
define it in faces-config.xml and with the view. But I'm afraid in this case
it doesn't fit well, by the reasons previously exposed. Even if it could
come in handy, in my personal opinion from implementation perspective
and from design perspective is too inconvenient.
FC>But I haven't seen an answer yet to the question about how to handle
FC>views that are resolved via a ResourceHandler. Any ideas how to do
FC>that?
To be clear about how ResourceHandler.createViewResource(...) works
right now in JSF 2.2:
- A view resource never has an associated library name (this was done
to keep simplicity).
- A view resource can be inside a resource library contract
(META-INF/contracts).
- A view resource could be internationalized in the same way a normal resource.
- A view resource can be created from the webapp root folder, a normal
resource cannot.
- A view resource cannot be created from /resources or META-INF/resources.
- A view resource can be inside a flow (META-INF/flows).
Please note with resource library contracts is you can override view
resources and normal resources.
I think the idea is allow users to change the webapp root folder to some other
location.
regards,
Leonardo Uribe
2014-11-03 17:13 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Mon, Nov 3, 2014 at 9:57 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
>> yes scanning is needed, but IMO no problem. This is a minimal performance issue, because you do it only once.
>
> Indeed, I don't really worry about that either.
>
> But I haven't seen an answer yet to the question about how to handle
> views that are resolved via a ResourceHandler. Any ideas how to do
> that?
>
> Kind regards,
> Arjan
>
>
>
>>
>> Ciao Frank
>>
>> Am 02.11.2014 um 23:16 schrieb Leonardo Uribe <leonardo.uribe_at_irian.at>:
>>
>>> Hi
>>>
>>> Try something like <f:view id="bookDetails" pattern="/books/{bookId}"
>>> ...> could cause a problem, because this requires to compile and scan
>>> every jsf page to build the mapping logic. The reason is JSF needs to
>>> know where the mapping goes to on the incoming request. If that logic
>>> is on a faces-config.xml or a bean annotated class sounds better.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2014-11-02 16:32 GMT-05:00 Cagatay Civici <cagatay.civici_at_gmail.com>:
>>>> Hi,
>>>>
>>>> We should also consider mapping multiple patterns to the same page, having a
>>>> single pattern attribute might not allow this. f:pattern maybe?
>>>>
>>>> Also a faces-config.xml based configuration could be an alternative, maybe
>>>> both where faces-config takes precedence.
>>>>
>>>> Regards,
>>>>
>>>> Cagatay Civici
>>>> PrimeFaces Lead
>>>> PrimeTek Informatics
>>>> www.primefaces.org
>>>>
>>>> On Sunday 2 November 2014 at 18:38, Frank Caputo wrote:
>>>>
>>>> Hi Experts,
>>>>
>>>> the idea was to define the url directly in the markup and reuse as much as
>>>> possible from JSF:
>>>>
>>>> <f:view id="bookDetails" pattern="/books/{bookId}">
>>>> <f:metadata>
>>>> <f:viewParam name="bookId" value="#{books.bookId}" required="true"/>
>>>> </f:metadata>
>>>> </f:view>
>>>>
>>>> Using the f:viewParam here has the advantage of getting validation and
>>>> converters from JSF. If validation fails, I sent a 404. One drawback is that
>>>> you might need the parameters right after the ApplyRequestValuesPhase, so
>>>> validation and model updates must be done immediately in the
>>>> ApplyRequestValuesPhase.
>>>>
>>>> The id of the view was registered in the navigation handler, so that you
>>>> could use:
>>>>
>>>> <h:link outcome="bookDetails">
>>>> <f:param name="bookId" value="147"/>
>>>> The book
>>>> </h:link>
>>>>
>>>> Comments are welcome.
>>>>
>>>> Ciao Frank
>>>>
>>>> Am 14.10.2014 um 19:28 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>>>>
>>>> Hi Cagatay,
>>>>
>>>> I'd also like to see some url mapping stuff as a big ticket. I've done this
>>>> for a customer and it is really not so complicated to implement. I will
>>>> share the ideas (which are basically borrowed from PrettyFaces) after my
>>>> holidays in 2 weeks.
>>>>
>>>> Ciao Frank
>>>>
>>>> Great, looking forward to hearing your feedback.
>>>>
>>>> Cagatay Civici
>>>> PrimeFaces Lead
>>>> PrimeTek Informatics
>>>> www.primefaces.org
>>>>
>>>> On Tuesday 14 October 2014 at 20:25, Frank Caputo wrote:
>>>>
>>>> Hi Cagatay,
>>>>
>>>> I'd also like to see some url mapping stuff as a big ticket. I've done this
>>>> for a customer and it is really not so complicated to implement. I will
>>>> share the ideas (which are basically borrowed from PrettyFaces) after my
>>>> holidays in 2 weeks.
>>>>
>>>> Ciao Frank
>>>>
>>>> Am 13.10.2014 um 15:37 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> We need 2 or 3 big ticket features in JSF 2.3.
>>>>
>>>> My big ticket offer would be related to url mapping.
>>>>
>>>> For example app/user/ maps to WEBAPP/pages/userpages/user.xhtml
>>>>
>>>> I don’t think it is very hard to do in terms of implementation as well.
>>>>
>>>> Would be good to have a configuration by exception just like the rest of
>>>> Java EE by following a certain convention of mapping.
>>>>
>>>> Regards,
>>>>
>>>> Cagatay Civici
>>>> PrimeFaces Lead
>>>> PrimeTek Informatics
>>>> www.primefaces.org
>>>>
>>>> On Monday 13 October 2014 at 16:22, Bauke Scholtz wrote:
>>>>
>>>> Hi,
>>>>
>>>> How about a native push component using websockets which is new since Java
>>>> EE 7?
>>>>
>>>> Cheers, Bauke
>>>>
>>>> On Oct 13, 2014 3:00 PM, "Josh Juneau" <juneau001_at_gmail.com> wrote:
>>>>
>>>> I listened to the audio from the expert group meeting at JavaOne. I
>>>> apologize again that I could not make it due to one of my talks being
>>>> scheduled at the same time. That said, it seemed as though the meeting went
>>>> very well, and I was happy to hear that there are others (Neil in
>>>> particular) that also would like to see at least one big ticket item for JSF
>>>> 2.3.
>>>>
>>>> I feel that it is important to have at least one feature that will catch the
>>>> attention of the community...mainly because such features help to maintain
>>>> the visibility of technologies. If there are no big ticket items in 2.3,
>>>> then it may be overlooked by some, making it look like JSF is becoming a
>>>> waning technology...falling to the single-page frameworks, or being pushed
>>>> aside for the MVC initiative. We all know that JSF is still widely used and
>>>> excellent at what it does, but I think JSF needs to remain highly visible
>>>> with the 2.3 release as the leading server-side web framework for Java EE,
>>>> especially given that there are a couple of years between each release.
>>>>
>>>> Maybe the big feature could be the "decorate response" phase that was
>>>> mentioned in the meeting, or even "increased support for HTTP 2.0", covering
>>>> the dispatch priority concerns. Perhaps better integration with single-page
>>>> frameworks, as addressed in Ian's presentation?
>>>>
>>>> Thanks for your time, I appreciate it.
>>>>
>>>> Josh Juneau
>>>> juneau001_at_gmail.com
>>>> http://jj-blogger.blogspot.com
>>>> https://www.apress.com/index.php/author/author/view/id/1866
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>