You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2012/08/01 14:53:45 UTC
Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Hi
2012/7/31 Gerhard Petracek <ge...@gmail.com>:
> hi leo,
>
> no - we don't need a compromise just for testing this feature. it's really
> an important feature also for v2.0.x and v2.1.x!
> i explained all the advantages (for users of myfaces-core v2.0.x and v2.1.x
> and also tomee) in the first mail of this thread - please read it again.
>
I'm not proposing to do not do it for 2.0.x / 2.1.x . Instead, I'm
proposing to start implementing the javadoc proposed in the early
draft review :
http://jcp.org/en/jsr/detail?id=344
Later, when we have a clear idea about how the implementation should
work, we can think about how to do a backport for 2.0.x / 2.1.x.
> if you have objections concerning the initial stability of the myfaces
> specific api, it's also fine to start with a prototype in a separated
> branch.
>
I think a good plan is:
1. Create a 2.1.x branch (2.1.x-client-window), set versions to
2.1.9-CLIENT-WINDOW-SNAPSHOT and work in a implementation, following
JSF 2.2 early draft javadoc, taking as base what we have in MyFaces
CODI and previous discussions in the wiki.
2. Try it, create examples and see how it works and correct what's necessary.
3. Only when the implementation is clear, propose a backport to be
included in 2.1.x .
In this way, we minimize the effort involved, because the code in the
branch could be easily included later in MyFaces 2.2, and we ensure
the implementation in 2.1.x is aligned with the spec (test this stuff
will take some time, and if another draft of the spec is out in that
time, we can check it and synchronize it with our code).
If no objections I'll start with the necessary steps.
regards,
Leonardo Uribe
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi Gerhard
>>
>> In my opinion, start with 2.1.x is the wrong way to do it. Sounds
>> better to create a branch, do the necessary changes (including modify
>> javax.faces.* classes to match the spec draft, but only the necessary
>> for windowId feature), and then if that is not enough do the backport.
>>
>> The whole point of this is provide "something" to try windowId feature
>> and check if everything is correct before JSF 2.2 is out, right?. In
>> that sense, I think do a milestone release is a good compromise. When
>> JSF 2.2 is out, we can do an official release and applications using
>> these artifacts will just jump to 2.2.
>>
>> In my opinion, there are still many things to make clear before try a
>> backport. How the implementation should behave? there are many ways to
>> do it and each one with different trade-offs.
>>
>> I'm still worried about create some classes in MyFaces, tell people to
>> use them and later change them without warning just because something
>> needs to be fixed. With a milestone release, the message is clear:
>> "... this is just JSF 2.1 + windowId proposal for JSF 2.2, so the
>> implementation here is not final and can change at any moment ...".
>>
>> ... Easy to do, hard to correct ...
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
>> > hi leo,
>> >
>> > i'm not sure if we really need such releases.
>> > if it is easier for you to start with the official api of v2.2 and to
>> > backport it afterwards, it's imo also ok to create a branch for it.
>> > in this case we might have to drop (or refactor) this branch later on,
>> > because the final ClientWindow implementation for v2.2 should just
>> > delegate
>> > to the myfaces specific api (if possible) to allow an easier sync.
>> >
>> > regards,
>> > gerhard
>> >
>> > http://www.irian.at
>> >
>> > Your JSF/JavaEE powerhouse -
>> > JavaEE Consulting, Development and
>> > Courses in English and German
>> >
>> > Professional Support for Apache MyFaces
>> >
>> >
>> >
>> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>> >>
>> >> Hi
>> >>
>> >> There is an alternative to do it for 2.0.x / 2.1.x . We can create a
>> >> temporal 2.2.x branch that will only contain JSF 2.1 + JSF 2.2
>> >> windowId API and then we do milestones releases, which does not
>> >> require to be official (no TCK), with some additional identifier. For
>> >> example myfaces-bundle-2.2.0-mr-1w.jar or something like that.
>> >>
>> >> In this way, we can just implement the proposal we have for JSF 2.2,
>> >> and people could try it, but we avoid the overhead involved in
>> >> implement myfaces specific hacks for 2.1. Later, we can backport it to
>> >> JSF 2.1(optional), but only after we have a clear idea about how the
>> >> implementation should work, and how we can backport it. Does that
>> >> sounds reasonable?
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> 2012/7/23 Gerhard Petracek <ge...@gmail.com>:
>> >> > hi @ all,
>> >> >
>> >> > if there are no objections, i'll create a jira ticket for it
>> >> > tomorrow.
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> > http://www.irian.at
>> >> >
>> >> > Your JSF/JavaEE powerhouse -
>> >> > JavaEE Consulting, Development and
>> >> > Courses in English and German
>> >> >
>> >> > Professional Support for Apache MyFaces
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > 2012/7/20 David Blevins <da...@gmail.com>
>> >> >>
>> >> >>
>> >> >> On Jul 19, 2012, at 2:49 AM, Mark Struberg wrote:
>> >> >> > The internal API will be 1:1 sync with the proposed javax.faces
>> >> >> > API -
>> >> >> > we
>> >> >> > are just not allowed to do it directly in javax.faces before it's
>> >> >> > official.
>> >> >>
>> >> >> Sounds great. Only reason I ask was the TCK gets cranky when you
>> >> >> change
>> >> >> the API signatures. But this proposed approach sounds like a nice
>> >> >> compromise.
>> >> >>
>> >> >> Very workable.
>> >> >>
>> >> >>
>> >> >> -David
>> >> >>
>> >> >
>> >
>> >
>
>
Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have created the following branch:
http://svn.apache.org/repos/asf/myfaces/core/branches/2.1.x-client-window/
And committed an implementation of JSF 2.2 early draft api for
windowId, as suggested. The patch is available too in MYFACES-3588.
Inside the branch I created a simple test application too:
http://svn.apache.org/repos/asf/myfaces/core/branches/2.1.x-client-window/client-window-example/
copying the tests we have for Flash object.
The code has two implementations for ClientWindow: the one in CODI
(default) and the one using only the url query param. It is just
necessary to set the param:
<context-param>
<param-name>javax.faces.CLIENT_WINDOW_MODE</param-name>
<param-value>default</param-value>
</context-param>
I also fixed Flash scope to use ClientWindow instead a cookie, and
when server side state saving is used, the window id is used to keep
track of the last key used in the window, solving the problem that
makes expire views of different views with GET-GET navigation. To do
that, it is just necessary to set these two params:
<context-param>
<description>Only applicable if state saving method is
"server" (= default).
Defines the amount (default = 20) of the latest views are
stored in session.</description>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>20</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION</param-name>
<param-value>5</param-value>
</context-param>
In this case 20/5 = 4 are the number of windows that can be created in
a browser and the algoritm will keep 5 slots into the state per
window.
Now, it is necessary to define if the implementation in CODI is good
enough, or if somebody wants to provide another implementation for
this feature.
Suggestions are welcome.
regards,
Leonardo Uribe
2012/8/1 Bernd Bohmann <be...@atanion.com>:
> +1
>
> On Wed, Aug 1, 2012 at 4:05 PM, Gerhard Petracek
> <ge...@gmail.com> wrote:
>> hi leo,
>>
>> since the goal is that the myfaces specific api should be aligned with the
>> jsf 2.2 api, the only difference should be the package and the lookup e.g.
>> of ClientWindow
>> -> there isn't a big difference at all. which means in return: there's also
>> no issue with starting with the jsf 2.2 api -> just continue, if you prefer
>> it that way.
>>
>> regards,
>> gerhard
>>
>> http://www.irian.at
>>
>> Your JSF/JavaEE powerhouse -
>> JavaEE Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2012/8/1 Leonardo Uribe <lu...@gmail.com>
>>>
>>> Hi
>>>
>>> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
>>> > hi leo,
>>> >
>>> > no - we don't need a compromise just for testing this feature. it's
>>> > really
>>> > an important feature also for v2.0.x and v2.1.x!
>>> > i explained all the advantages (for users of myfaces-core v2.0.x and
>>> > v2.1.x
>>> > and also tomee) in the first mail of this thread - please read it again.
>>> >
>>>
>>> I'm not proposing to do not do it for 2.0.x / 2.1.x . Instead, I'm
>>> proposing to start implementing the javadoc proposed in the early
>>> draft review :
>>>
>>> http://jcp.org/en/jsr/detail?id=344
>>>
>>> Later, when we have a clear idea about how the implementation should
>>> work, we can think about how to do a backport for 2.0.x / 2.1.x.
>>>
>>> > if you have objections concerning the initial stability of the myfaces
>>> > specific api, it's also fine to start with a prototype in a separated
>>> > branch.
>>> >
>>>
>>> I think a good plan is:
>>>
>>> 1. Create a 2.1.x branch (2.1.x-client-window), set versions to
>>> 2.1.9-CLIENT-WINDOW-SNAPSHOT and work in a implementation, following
>>> JSF 2.2 early draft javadoc, taking as base what we have in MyFaces
>>> CODI and previous discussions in the wiki.
>>> 2. Try it, create examples and see how it works and correct what's
>>> necessary.
>>> 3. Only when the implementation is clear, propose a backport to be
>>> included in 2.1.x .
>>>
>>> In this way, we minimize the effort involved, because the code in the
>>> branch could be easily included later in MyFaces 2.2, and we ensure
>>> the implementation in 2.1.x is aligned with the spec (test this stuff
>>> will take some time, and if another draft of the spec is out in that
>>> time, we can check it and synchronize it with our code).
>>>
>>> If no objections I'll start with the necessary steps.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> > regards,
>>> > gerhard
>>> >
>>> > http://www.irian.at
>>> >
>>> > Your JSF/JavaEE powerhouse -
>>> > JavaEE Consulting, Development and
>>> > Courses in English and German
>>> >
>>> > Professional Support for Apache MyFaces
>>> >
>>> >
>>> >
>>> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>>> >>
>>> >> Hi Gerhard
>>> >>
>>> >> In my opinion, start with 2.1.x is the wrong way to do it. Sounds
>>> >> better to create a branch, do the necessary changes (including modify
>>> >> javax.faces.* classes to match the spec draft, but only the necessary
>>> >> for windowId feature), and then if that is not enough do the backport.
>>> >>
>>> >> The whole point of this is provide "something" to try windowId feature
>>> >> and check if everything is correct before JSF 2.2 is out, right?. In
>>> >> that sense, I think do a milestone release is a good compromise. When
>>> >> JSF 2.2 is out, we can do an official release and applications using
>>> >> these artifacts will just jump to 2.2.
>>> >>
>>> >> In my opinion, there are still many things to make clear before try a
>>> >> backport. How the implementation should behave? there are many ways to
>>> >> do it and each one with different trade-offs.
>>> >>
>>> >> I'm still worried about create some classes in MyFaces, tell people to
>>> >> use them and later change them without warning just because something
>>> >> needs to be fixed. With a milestone release, the message is clear:
>>> >> "... this is just JSF 2.1 + windowId proposal for JSF 2.2, so the
>>> >> implementation here is not final and can change at any moment ...".
>>> >>
>>> >> ... Easy to do, hard to correct ...
>>> >>
>>> >> regards,
>>> >>
>>> >> Leonardo Uribe
>>> >>
>>> >> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
>>> >> > hi leo,
>>> >> >
>>> >> > i'm not sure if we really need such releases.
>>> >> > if it is easier for you to start with the official api of v2.2 and to
>>> >> > backport it afterwards, it's imo also ok to create a branch for it.
>>> >> > in this case we might have to drop (or refactor) this branch later
>>> >> > on,
>>> >> > because the final ClientWindow implementation for v2.2 should just
>>> >> > delegate
>>> >> > to the myfaces specific api (if possible) to allow an easier sync.
>>> >> >
>>> >> > regards,
>>> >> > gerhard
>>> >> >
>>> >> > http://www.irian.at
>>> >> >
>>> >> > Your JSF/JavaEE powerhouse -
>>> >> > JavaEE Consulting, Development and
>>> >> > Courses in English and German
>>> >> >
>>> >> > Professional Support for Apache MyFaces
>>> >> >
>>> >> >
>>> >> >
>>> >> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>>> >> >>
>>> >> >> Hi
>>> >> >>
>>> >> >> There is an alternative to do it for 2.0.x / 2.1.x . We can create a
>>> >> >> temporal 2.2.x branch that will only contain JSF 2.1 + JSF 2.2
>>> >> >> windowId API and then we do milestones releases, which does not
>>> >> >> require to be official (no TCK), with some additional identifier.
>>> >> >> For
>>> >> >> example myfaces-bundle-2.2.0-mr-1w.jar or something like that.
>>> >> >>
>>> >> >> In this way, we can just implement the proposal we have for JSF 2.2,
>>> >> >> and people could try it, but we avoid the overhead involved in
>>> >> >> implement myfaces specific hacks for 2.1. Later, we can backport it
>>> >> >> to
>>> >> >> JSF 2.1(optional), but only after we have a clear idea about how the
>>> >> >> implementation should work, and how we can backport it. Does that
>>> >> >> sounds reasonable?
>>> >> >>
>>> >> >> regards,
>>> >> >>
>>> >> >> Leonardo Uribe
>>> >> >>
>>> >> >> 2012/7/23 Gerhard Petracek <ge...@gmail.com>:
>>> >> >> > hi @ all,
>>> >> >> >
>>> >> >> > if there are no objections, i'll create a jira ticket for it
>>> >> >> > tomorrow.
>>> >> >> >
>>> >> >> > regards,
>>> >> >> > gerhard
>>> >> >> >
>>> >> >> > http://www.irian.at
>>> >> >> >
>>> >> >> > Your JSF/JavaEE powerhouse -
>>> >> >> > JavaEE Consulting, Development and
>>> >> >> > Courses in English and German
>>> >> >> >
>>> >> >> > Professional Support for Apache MyFaces
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > 2012/7/20 David Blevins <da...@gmail.com>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Jul 19, 2012, at 2:49 AM, Mark Struberg wrote:
>>> >> >> >> > The internal API will be 1:1 sync with the proposed javax.faces
>>> >> >> >> > API -
>>> >> >> >> > we
>>> >> >> >> > are just not allowed to do it directly in javax.faces before
>>> >> >> >> > it's
>>> >> >> >> > official.
>>> >> >> >>
>>> >> >> >> Sounds great. Only reason I ask was the TCK gets cranky when you
>>> >> >> >> change
>>> >> >> >> the API signatures. But this proposed approach sounds like a
>>> >> >> >> nice
>>> >> >> >> compromise.
>>> >> >> >>
>>> >> >> >> Very workable.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> -David
>>> >> >> >>
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Posted by Bernd Bohmann <be...@atanion.com>.
+1
On Wed, Aug 1, 2012 at 4:05 PM, Gerhard Petracek
<ge...@gmail.com> wrote:
> hi leo,
>
> since the goal is that the myfaces specific api should be aligned with the
> jsf 2.2 api, the only difference should be the package and the lookup e.g.
> of ClientWindow
> -> there isn't a big difference at all. which means in return: there's also
> no issue with starting with the jsf 2.2 api -> just continue, if you prefer
> it that way.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2012/8/1 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi
>>
>> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
>> > hi leo,
>> >
>> > no - we don't need a compromise just for testing this feature. it's
>> > really
>> > an important feature also for v2.0.x and v2.1.x!
>> > i explained all the advantages (for users of myfaces-core v2.0.x and
>> > v2.1.x
>> > and also tomee) in the first mail of this thread - please read it again.
>> >
>>
>> I'm not proposing to do not do it for 2.0.x / 2.1.x . Instead, I'm
>> proposing to start implementing the javadoc proposed in the early
>> draft review :
>>
>> http://jcp.org/en/jsr/detail?id=344
>>
>> Later, when we have a clear idea about how the implementation should
>> work, we can think about how to do a backport for 2.0.x / 2.1.x.
>>
>> > if you have objections concerning the initial stability of the myfaces
>> > specific api, it's also fine to start with a prototype in a separated
>> > branch.
>> >
>>
>> I think a good plan is:
>>
>> 1. Create a 2.1.x branch (2.1.x-client-window), set versions to
>> 2.1.9-CLIENT-WINDOW-SNAPSHOT and work in a implementation, following
>> JSF 2.2 early draft javadoc, taking as base what we have in MyFaces
>> CODI and previous discussions in the wiki.
>> 2. Try it, create examples and see how it works and correct what's
>> necessary.
>> 3. Only when the implementation is clear, propose a backport to be
>> included in 2.1.x .
>>
>> In this way, we minimize the effort involved, because the code in the
>> branch could be easily included later in MyFaces 2.2, and we ensure
>> the implementation in 2.1.x is aligned with the spec (test this stuff
>> will take some time, and if another draft of the spec is out in that
>> time, we can check it and synchronize it with our code).
>>
>> If no objections I'll start with the necessary steps.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> > regards,
>> > gerhard
>> >
>> > http://www.irian.at
>> >
>> > Your JSF/JavaEE powerhouse -
>> > JavaEE Consulting, Development and
>> > Courses in English and German
>> >
>> > Professional Support for Apache MyFaces
>> >
>> >
>> >
>> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>> >>
>> >> Hi Gerhard
>> >>
>> >> In my opinion, start with 2.1.x is the wrong way to do it. Sounds
>> >> better to create a branch, do the necessary changes (including modify
>> >> javax.faces.* classes to match the spec draft, but only the necessary
>> >> for windowId feature), and then if that is not enough do the backport.
>> >>
>> >> The whole point of this is provide "something" to try windowId feature
>> >> and check if everything is correct before JSF 2.2 is out, right?. In
>> >> that sense, I think do a milestone release is a good compromise. When
>> >> JSF 2.2 is out, we can do an official release and applications using
>> >> these artifacts will just jump to 2.2.
>> >>
>> >> In my opinion, there are still many things to make clear before try a
>> >> backport. How the implementation should behave? there are many ways to
>> >> do it and each one with different trade-offs.
>> >>
>> >> I'm still worried about create some classes in MyFaces, tell people to
>> >> use them and later change them without warning just because something
>> >> needs to be fixed. With a milestone release, the message is clear:
>> >> "... this is just JSF 2.1 + windowId proposal for JSF 2.2, so the
>> >> implementation here is not final and can change at any moment ...".
>> >>
>> >> ... Easy to do, hard to correct ...
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
>> >> > hi leo,
>> >> >
>> >> > i'm not sure if we really need such releases.
>> >> > if it is easier for you to start with the official api of v2.2 and to
>> >> > backport it afterwards, it's imo also ok to create a branch for it.
>> >> > in this case we might have to drop (or refactor) this branch later
>> >> > on,
>> >> > because the final ClientWindow implementation for v2.2 should just
>> >> > delegate
>> >> > to the myfaces specific api (if possible) to allow an easier sync.
>> >> >
>> >> > regards,
>> >> > gerhard
>> >> >
>> >> > http://www.irian.at
>> >> >
>> >> > Your JSF/JavaEE powerhouse -
>> >> > JavaEE Consulting, Development and
>> >> > Courses in English and German
>> >> >
>> >> > Professional Support for Apache MyFaces
>> >> >
>> >> >
>> >> >
>> >> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
>> >> >>
>> >> >> Hi
>> >> >>
>> >> >> There is an alternative to do it for 2.0.x / 2.1.x . We can create a
>> >> >> temporal 2.2.x branch that will only contain JSF 2.1 + JSF 2.2
>> >> >> windowId API and then we do milestones releases, which does not
>> >> >> require to be official (no TCK), with some additional identifier.
>> >> >> For
>> >> >> example myfaces-bundle-2.2.0-mr-1w.jar or something like that.
>> >> >>
>> >> >> In this way, we can just implement the proposal we have for JSF 2.2,
>> >> >> and people could try it, but we avoid the overhead involved in
>> >> >> implement myfaces specific hacks for 2.1. Later, we can backport it
>> >> >> to
>> >> >> JSF 2.1(optional), but only after we have a clear idea about how the
>> >> >> implementation should work, and how we can backport it. Does that
>> >> >> sounds reasonable?
>> >> >>
>> >> >> regards,
>> >> >>
>> >> >> Leonardo Uribe
>> >> >>
>> >> >> 2012/7/23 Gerhard Petracek <ge...@gmail.com>:
>> >> >> > hi @ all,
>> >> >> >
>> >> >> > if there are no objections, i'll create a jira ticket for it
>> >> >> > tomorrow.
>> >> >> >
>> >> >> > regards,
>> >> >> > gerhard
>> >> >> >
>> >> >> > http://www.irian.at
>> >> >> >
>> >> >> > Your JSF/JavaEE powerhouse -
>> >> >> > JavaEE Consulting, Development and
>> >> >> > Courses in English and German
>> >> >> >
>> >> >> > Professional Support for Apache MyFaces
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > 2012/7/20 David Blevins <da...@gmail.com>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Jul 19, 2012, at 2:49 AM, Mark Struberg wrote:
>> >> >> >> > The internal API will be 1:1 sync with the proposed javax.faces
>> >> >> >> > API -
>> >> >> >> > we
>> >> >> >> > are just not allowed to do it directly in javax.faces before
>> >> >> >> > it's
>> >> >> >> > official.
>> >> >> >>
>> >> >> >> Sounds great. Only reason I ask was the TCK gets cranky when you
>> >> >> >> change
>> >> >> >> the API signatures. But this proposed approach sounds like a
>> >> >> >> nice
>> >> >> >> compromise.
>> >> >> >>
>> >> >> >> Very workable.
>> >> >> >>
>> >> >> >>
>> >> >> >> -David
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Posted by Gerhard Petracek <ge...@gmail.com>.
hi leo,
since the goal is that the myfaces specific api should be aligned with the
jsf 2.2 api, the only difference should be the package and the lookup e.g.
of ClientWindow
-> there isn't a big difference at all. which means in return: there's also
no issue with starting with the jsf 2.2 api -> just continue, if you prefer
it that way.
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2012/8/1 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
> > hi leo,
> >
> > no - we don't need a compromise just for testing this feature. it's
> really
> > an important feature also for v2.0.x and v2.1.x!
> > i explained all the advantages (for users of myfaces-core v2.0.x and
> v2.1.x
> > and also tomee) in the first mail of this thread - please read it again.
> >
>
> I'm not proposing to do not do it for 2.0.x / 2.1.x . Instead, I'm
> proposing to start implementing the javadoc proposed in the early
> draft review :
>
> http://jcp.org/en/jsr/detail?id=344
>
> Later, when we have a clear idea about how the implementation should
> work, we can think about how to do a backport for 2.0.x / 2.1.x.
>
> > if you have objections concerning the initial stability of the myfaces
> > specific api, it's also fine to start with a prototype in a separated
> > branch.
> >
>
> I think a good plan is:
>
> 1. Create a 2.1.x branch (2.1.x-client-window), set versions to
> 2.1.9-CLIENT-WINDOW-SNAPSHOT and work in a implementation, following
> JSF 2.2 early draft javadoc, taking as base what we have in MyFaces
> CODI and previous discussions in the wiki.
> 2. Try it, create examples and see how it works and correct what's
> necessary.
> 3. Only when the implementation is clear, propose a backport to be
> included in 2.1.x .
>
> In this way, we minimize the effort involved, because the code in the
> branch could be easily included later in MyFaces 2.2, and we ensure
> the implementation in 2.1.x is aligned with the spec (test this stuff
> will take some time, and if another draft of the spec is out in that
> time, we can check it and synchronize it with our code).
>
> If no objections I'll start with the necessary steps.
>
> regards,
>
> Leonardo Uribe
>
> > regards,
> > gerhard
> >
> > http://www.irian.at
> >
> > Your JSF/JavaEE powerhouse -
> > JavaEE Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
> >>
> >> Hi Gerhard
> >>
> >> In my opinion, start with 2.1.x is the wrong way to do it. Sounds
> >> better to create a branch, do the necessary changes (including modify
> >> javax.faces.* classes to match the spec draft, but only the necessary
> >> for windowId feature), and then if that is not enough do the backport.
> >>
> >> The whole point of this is provide "something" to try windowId feature
> >> and check if everything is correct before JSF 2.2 is out, right?. In
> >> that sense, I think do a milestone release is a good compromise. When
> >> JSF 2.2 is out, we can do an official release and applications using
> >> these artifacts will just jump to 2.2.
> >>
> >> In my opinion, there are still many things to make clear before try a
> >> backport. How the implementation should behave? there are many ways to
> >> do it and each one with different trade-offs.
> >>
> >> I'm still worried about create some classes in MyFaces, tell people to
> >> use them and later change them without warning just because something
> >> needs to be fixed. With a milestone release, the message is clear:
> >> "... this is just JSF 2.1 + windowId proposal for JSF 2.2, so the
> >> implementation here is not final and can change at any moment ...".
> >>
> >> ... Easy to do, hard to correct ...
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2012/7/31 Gerhard Petracek <ge...@gmail.com>:
> >> > hi leo,
> >> >
> >> > i'm not sure if we really need such releases.
> >> > if it is easier for you to start with the official api of v2.2 and to
> >> > backport it afterwards, it's imo also ok to create a branch for it.
> >> > in this case we might have to drop (or refactor) this branch later on,
> >> > because the final ClientWindow implementation for v2.2 should just
> >> > delegate
> >> > to the myfaces specific api (if possible) to allow an easier sync.
> >> >
> >> > regards,
> >> > gerhard
> >> >
> >> > http://www.irian.at
> >> >
> >> > Your JSF/JavaEE powerhouse -
> >> > JavaEE Consulting, Development and
> >> > Courses in English and German
> >> >
> >> > Professional Support for Apache MyFaces
> >> >
> >> >
> >> >
> >> > 2012/7/31 Leonardo Uribe <lu...@gmail.com>
> >> >>
> >> >> Hi
> >> >>
> >> >> There is an alternative to do it for 2.0.x / 2.1.x . We can create a
> >> >> temporal 2.2.x branch that will only contain JSF 2.1 + JSF 2.2
> >> >> windowId API and then we do milestones releases, which does not
> >> >> require to be official (no TCK), with some additional identifier. For
> >> >> example myfaces-bundle-2.2.0-mr-1w.jar or something like that.
> >> >>
> >> >> In this way, we can just implement the proposal we have for JSF 2.2,
> >> >> and people could try it, but we avoid the overhead involved in
> >> >> implement myfaces specific hacks for 2.1. Later, we can backport it
> to
> >> >> JSF 2.1(optional), but only after we have a clear idea about how the
> >> >> implementation should work, and how we can backport it. Does that
> >> >> sounds reasonable?
> >> >>
> >> >> regards,
> >> >>
> >> >> Leonardo Uribe
> >> >>
> >> >> 2012/7/23 Gerhard Petracek <ge...@gmail.com>:
> >> >> > hi @ all,
> >> >> >
> >> >> > if there are no objections, i'll create a jira ticket for it
> >> >> > tomorrow.
> >> >> >
> >> >> > regards,
> >> >> > gerhard
> >> >> >
> >> >> > http://www.irian.at
> >> >> >
> >> >> > Your JSF/JavaEE powerhouse -
> >> >> > JavaEE Consulting, Development and
> >> >> > Courses in English and German
> >> >> >
> >> >> > Professional Support for Apache MyFaces
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2012/7/20 David Blevins <da...@gmail.com>
> >> >> >>
> >> >> >>
> >> >> >> On Jul 19, 2012, at 2:49 AM, Mark Struberg wrote:
> >> >> >> > The internal API will be 1:1 sync with the proposed javax.faces
> >> >> >> > API -
> >> >> >> > we
> >> >> >> > are just not allowed to do it directly in javax.faces before
> it's
> >> >> >> > official.
> >> >> >>
> >> >> >> Sounds great. Only reason I ask was the TCK gets cranky when you
> >> >> >> change
> >> >> >> the API signatures. But this proposed approach sounds like a nice
> >> >> >> compromise.
> >> >> >>
> >> >> >> Very workable.
> >> >> >>
> >> >> >>
> >> >> >> -David
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>