Hi Thomas

TA>> AFAIR now, your solutions seems to be just a replacement for f:viewAction
TA>> + allow different handlers via URL parameters.
TA>> Its sound really lightweight and easy actually :)
TA>> Does it cover all our requirements from the earlier mails?
TA>>

I think so, but we need to write some examples to be sure that the syntax cover
all cases.

Instead put a Front Controller on top of the lifecycle, we can go with
this approach
and provide some methods to call JSF algorithm inline. We already have some
code in VDL.createComponent(...) that does inline compilation, so it
is not really
hard to write the necessary lines to do so (if the code is properly implemented
of course). The idea could be provide something like:

JSFUtils.generatePage("/mypage.xhtml", ....)

and internally we call the algorithm, and deal with the potential problems.

So, if the user really wants to go with a MVC framework and use JSF as template
engine, it will be as simple as write the adapter for the framework.
We should not
reinvent the wheel in this case. So, all other cases not supported by
f:viewAction/f:viewParam, which should be very, very few, should be done writing
a servlet or using an MVC framework like JAX-RS, and if necessary calling
JSF at render time.

The nice part about reuse f:viewAction logic is that is something
proved, everybody
knows how it works, we are just extending the syntax to define f:viewAction in
a more familiar way. In practice we need to write a custom component extending
UIViewAction, but that's something easy, I have already done it and it works.

That should cover most of the cases. There are other cases that are indirectly
related to this one, but after some review, it doesn't seem to be so interesting
or useful, or can be too complex to implement properly, so we need to
wait and push
it into the next spec. Sometimes less is more. Let's see what happen.

>> Whats the syntax for multiple params? ->
>> params="action=exportExcel&someOther=string"?
>> Maybe we could think about a more typesafe and readable way. e.g.
>>
>> @ViewAction(value="my.xhtml", params = {
>>      @ViewParam(name="action", value="exportExcel"),
>>      @ViewParam(name="someOther", value="string")
>> })

I was thinking about this:

    @ViewAction(value="/sayhello.xhtml", params="action=exportExcel")
    public void method3(@ViewParam String param1,
@ViewParam("someOther") Integer param2)
    {

The method has two parts: one define the parameters that should be present
and the other define the activation conditions, in this case, when
action=exportExcel. Please note to make @ViewParam("someOther"), we
need to associate value to the key name. So we could do something
like this:

    @ViewAction(value="/sayhello.xhtml",
                          params= {
                               @ViewParam(name="action",
expectedValue="exportExcel")
                          })
    public void method3(@ViewParam String param1,
@ViewParam("someOther") Integer param2)
    {

I think in this way it looks better. Thanks for the suggestion.

regards,

Leonardo

Reply via email to