You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Joseph Rozier <jo...@gmail.com> on 2006/09/13 22:27:55 UTC
Pending PDA Patches
Hello,
The following two JIRAs have patches waiting to be reviewed/committed.
https://issues.apache.org/jira/browse/ADFFACES-167
Add 'autoSubmit' support for basic input components on PDAs
https://issues.apache.org/jira/browse/ADFFACES-110
Add Agent for BlackBerry Browser 4.0
(this has a fix to the original patch)
Would it be possible to get these two patches committed?
We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
but they have dependencies on these patches.
Also, for the future, what is the protocol for submitting patches that
have dependencies on earlier patches that have not yet been committed.
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I can see how that would make patch reviewing a headache, but we're
running into the issue where a lot of the PDA patches have dependences
on earlier patches and it typically takes several days to get even
minor changes reviewed and committed.
Thanks,
Joey
Re: Pending PDA Patches
Posted by Piyush Hari <pi...@oracle.com>.
Hey Joey,
I just realised that I had submitted patches for panelradio and panelChoice
which had dependencies on other issues being commited. I cancelled those
patches after I read Jeanne's and your e-mails.
Thanks,
Piyush
----- Original Message -----
From: "Joseph Rozier" <jo...@gmail.com>
To: <ad...@incubator.apache.org>
Sent: Thursday, September 21, 2006 6:52 PM
Subject: Re: Pending PDA Patches
> On 9/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>> Hi Joey,
>> I haven't had time to respond.
>> I don't know what the dependency method should be.
>> Your suggestion:
>> Is it acceptable to locally apply the earlier patch that has not yet
>> been committed and, in effect, include that patch in a new patch?
>>
>> I think this is acceptable, because I don't think this new patch would
>> get
>> reviewed until the first patch that it depends on gets checked in.
>> So then when we review the second patch, the differences won't be the
>> differences of both patches, just the second patch.
>
> Okay, that's the approach Piyush has been using, and documenting in
> the patch what other patches it is including.
>
> It could be an issue if the earlier patch is rejected or modified in
> some way, so we are trying to limit the dependencies to relatively
> independent patches. (Though that sounds oxymoronic, I suppose.)
>
> Take care,
>
> Joey
>
>>
>> - Jeanne
>>
>> Joseph Rozier wrote:
>>
>> > Hello,
>> >
>> > I'm resending this since there was no response to the first one...
>> >
>> > I'd particularly appreciate a response to what the desired way to
>> > handle patch dependencies is, when one patch is dependent on another
>> > patch that has not yet been committed. (The review/committing of the
>> > outstanding PDA patches would be appreciated as well. :))
>> >
>> > Thanks,
>> >
>> > Joey
>> >
>> > On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
>> >
>> >> Hello,
>> >>
>> >> The following two JIRAs have patches waiting to be reviewed/committed.
>> >>
>> >> https://issues.apache.org/jira/browse/ADFFACES-167
>> >> Add 'autoSubmit' support for basic input components on PDAs
>> >>
>> >> https://issues.apache.org/jira/browse/ADFFACES-110
>> >> Add Agent for BlackBerry Browser 4.0
>> >> (this has a fix to the original patch)
>> >>
>> >> Would it be possible to get these two patches committed?
>> >>
>> >> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
>> >> but they have dependencies on these patches.
>> >>
>> >> Also, for the future, what is the protocol for submitting patches that
>> >> have dependencies on earlier patches that have not yet been committed.
>> >> Is it acceptable to locally apply the earlier patch that has not yet
>> >> been committed and, in effect, include that patch in a new patch?
>> >>
>> >> I can see how that would make patch reviewing a headache, but we're
>> >> running into the issue where a lot of the PDA patches have dependences
>> >> on earlier patches and it typically takes several days to get even
>> >> minor changes reviewed and committed.
>> >>
>> >> Thanks,
>> >>
>> >> Joey
>> >>
>> >
>>
>>
>
Re: Pending PDA Patches
Posted by Joseph Rozier <jo...@gmail.com>.
On 9/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> Hi Joey,
> I haven't had time to respond.
> I don't know what the dependency method should be.
> Your suggestion:
> Is it acceptable to locally apply the earlier patch that has not yet
> been committed and, in effect, include that patch in a new patch?
>
> I think this is acceptable, because I don't think this new patch would get
> reviewed until the first patch that it depends on gets checked in.
> So then when we review the second patch, the differences won't be the
> differences of both patches, just the second patch.
Okay, that's the approach Piyush has been using, and documenting in
the patch what other patches it is including.
It could be an issue if the earlier patch is rejected or modified in
some way, so we are trying to limit the dependencies to relatively
independent patches. (Though that sounds oxymoronic, I suppose.)
Take care,
Joey
>
> - Jeanne
>
> Joseph Rozier wrote:
>
> > Hello,
> >
> > I'm resending this since there was no response to the first one...
> >
> > I'd particularly appreciate a response to what the desired way to
> > handle patch dependencies is, when one patch is dependent on another
> > patch that has not yet been committed. (The review/committing of the
> > outstanding PDA patches would be appreciated as well. :))
> >
> > Thanks,
> >
> > Joey
> >
> > On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
> >
> >> Hello,
> >>
> >> The following two JIRAs have patches waiting to be reviewed/committed.
> >>
> >> https://issues.apache.org/jira/browse/ADFFACES-167
> >> Add 'autoSubmit' support for basic input components on PDAs
> >>
> >> https://issues.apache.org/jira/browse/ADFFACES-110
> >> Add Agent for BlackBerry Browser 4.0
> >> (this has a fix to the original patch)
> >>
> >> Would it be possible to get these two patches committed?
> >>
> >> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
> >> but they have dependencies on these patches.
> >>
> >> Also, for the future, what is the protocol for submitting patches that
> >> have dependencies on earlier patches that have not yet been committed.
> >> Is it acceptable to locally apply the earlier patch that has not yet
> >> been committed and, in effect, include that patch in a new patch?
> >>
> >> I can see how that would make patch reviewing a headache, but we're
> >> running into the issue where a lot of the PDA patches have dependences
> >> on earlier patches and it typically takes several days to get even
> >> minor changes reviewed and committed.
> >>
> >> Thanks,
> >>
> >> Joey
> >>
> >
>
>
Re: Pending PDA Patches
Posted by Joseph Rozier <jo...@gmail.com>.
The rule of thumb we have been using is that if it is a relatively
minor difference when the bulk of the code can be re-used, we prefer
to keep a single renderer.
We also try to use only capabilities instead of is<Agent> type code,
though sometimes it is unavoidable because the agent-specific
difference isn't easily captured by capabilities.
You can see both cases here, where the original Trinidad code had a
"if(isPIE)" block, but the new code is based on capabilities.
There are some cases where the renderers differe, as can be seen in
the table renderers (in
org.apache.myfaces.trinidadinternal.renderkit.core.desktop and .pda).
The rendering logic there is more substantially different.
So far, the fixes we have been making have been of the "minor changes
to existing renderers" variety.
Any other opinions on the approach we should be using?
(And thanks for looking into these!)
Take care,
Joey
On 9/21/06, Jeanne Waldman <je...@oracle.com> wrote:
> I have a question regarding pda code.
> In Faces Major renderers, do we add pda hooks into the renderer, or
> should we have separate pda renderers?
> I was looking at the pda patch for autoSubmit, and I see this code in
> FormRenderer. Do we have a rule as to when we
> should use a pda renderer instead of these hooks? Is it a judgement call
> in how much the code differs?
> Thanks,
> Jeanne
>
> if (isPIE && pprContext == null)
> {
> + //PH: Add hidden elements in the form for enabling PPR on IE Mobile.
> +
> + Object domLevel =
> arc.getAgent().getCapability(TrinidadAgent.CAP_DOM);
> +
> + if(
> + domLevel == null ||
> + domLevel == TrinidadAgent.DOM_CAP_NONE ||
> + domLevel == TrinidadAgent.DOM_CAP_FORM)
> + {
> + FormData formData = arc.getFormData();
> + if(formData != null)
> + {
> + formData.addNeededValue(XhtmlConstants.EVENT_PARAM);
> + formData.addNeededValue(XhtmlConstants.SOURCE_PARAM);
> + formData.addNeededValue(XhtmlConstants.PARTIAL_TARGETS_PARAM);
> + formData.addNeededValue(XhtmlConstants.PARTIAL_PARAM);
> + }
> + }
> +
>
> Jeanne Waldman wrote:
>
> > Hi Joey,
> > I haven't had time to respond.
> > I don't know what the dependency method should be.
> > Your suggestion:
> > Is it acceptable to locally apply the earlier patch that has not yet
> > been committed and, in effect, include that patch in a new patch?
> >
> > I think this is acceptable, because I don't think this new patch would
> > get
> > reviewed until the first patch that it depends on gets checked in.
> > So then when we review the second patch, the differences won't be the
> > differences of both patches, just the second patch.
> >
> > - Jeanne
> >
> > Joseph Rozier wrote:
> >
> >> Hello,
> >>
> >> I'm resending this since there was no response to the first one...
> >>
> >> I'd particularly appreciate a response to what the desired way to
> >> handle patch dependencies is, when one patch is dependent on another
> >> patch that has not yet been committed. (The review/committing of the
> >> outstanding PDA patches would be appreciated as well. :))
> >>
> >> Thanks,
> >>
> >> Joey
> >>
> >> On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> The following two JIRAs have patches waiting to be reviewed/committed.
> >>>
> >>> https://issues.apache.org/jira/browse/ADFFACES-167
> >>> Add 'autoSubmit' support for basic input components on PDAs
> >>>
> >>> https://issues.apache.org/jira/browse/ADFFACES-110
> >>> Add Agent for BlackBerry Browser 4.0
> >>> (this has a fix to the original patch)
> >>>
> >>> Would it be possible to get these two patches committed?
> >>>
> >>> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
> >>> but they have dependencies on these patches.
> >>>
> >>> Also, for the future, what is the protocol for submitting patches that
> >>> have dependencies on earlier patches that have not yet been committed.
> >>> Is it acceptable to locally apply the earlier patch that has not yet
> >>> been committed and, in effect, include that patch in a new patch?
> >>>
> >>> I can see how that would make patch reviewing a headache, but we're
> >>> running into the issue where a lot of the PDA patches have dependences
> >>> on earlier patches and it typically takes several days to get even
> >>> minor changes reviewed and committed.
> >>>
> >>> Thanks,
> >>>
> >>> Joey
> >>>
> >>
> >
> >
>
>
Re: Pending PDA Patches
Posted by Jeanne Waldman <je...@oracle.com>.
I have a question regarding pda code.
In Faces Major renderers, do we add pda hooks into the renderer, or
should we have separate pda renderers?
I was looking at the pda patch for autoSubmit, and I see this code in
FormRenderer. Do we have a rule as to when we
should use a pda renderer instead of these hooks? Is it a judgement call
in how much the code differs?
Thanks,
Jeanne
if (isPIE && pprContext == null)
{
+ //PH: Add hidden elements in the form for enabling PPR on IE Mobile.
+
+ Object domLevel =
arc.getAgent().getCapability(TrinidadAgent.CAP_DOM);
+
+ if(
+ domLevel == null ||
+ domLevel == TrinidadAgent.DOM_CAP_NONE ||
+ domLevel == TrinidadAgent.DOM_CAP_FORM)
+ {
+ FormData formData = arc.getFormData();
+ if(formData != null)
+ {
+ formData.addNeededValue(XhtmlConstants.EVENT_PARAM);
+ formData.addNeededValue(XhtmlConstants.SOURCE_PARAM);
+ formData.addNeededValue(XhtmlConstants.PARTIAL_TARGETS_PARAM);
+ formData.addNeededValue(XhtmlConstants.PARTIAL_PARAM);
+ }
+ }
+
Jeanne Waldman wrote:
> Hi Joey,
> I haven't had time to respond.
> I don't know what the dependency method should be.
> Your suggestion:
> Is it acceptable to locally apply the earlier patch that has not yet
> been committed and, in effect, include that patch in a new patch?
>
> I think this is acceptable, because I don't think this new patch would
> get
> reviewed until the first patch that it depends on gets checked in.
> So then when we review the second patch, the differences won't be the
> differences of both patches, just the second patch.
>
> - Jeanne
>
> Joseph Rozier wrote:
>
>> Hello,
>>
>> I'm resending this since there was no response to the first one...
>>
>> I'd particularly appreciate a response to what the desired way to
>> handle patch dependencies is, when one patch is dependent on another
>> patch that has not yet been committed. (The review/committing of the
>> outstanding PDA patches would be appreciated as well. :))
>>
>> Thanks,
>>
>> Joey
>>
>> On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> The following two JIRAs have patches waiting to be reviewed/committed.
>>>
>>> https://issues.apache.org/jira/browse/ADFFACES-167
>>> Add 'autoSubmit' support for basic input components on PDAs
>>>
>>> https://issues.apache.org/jira/browse/ADFFACES-110
>>> Add Agent for BlackBerry Browser 4.0
>>> (this has a fix to the original patch)
>>>
>>> Would it be possible to get these two patches committed?
>>>
>>> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
>>> but they have dependencies on these patches.
>>>
>>> Also, for the future, what is the protocol for submitting patches that
>>> have dependencies on earlier patches that have not yet been committed.
>>> Is it acceptable to locally apply the earlier patch that has not yet
>>> been committed and, in effect, include that patch in a new patch?
>>>
>>> I can see how that would make patch reviewing a headache, but we're
>>> running into the issue where a lot of the PDA patches have dependences
>>> on earlier patches and it typically takes several days to get even
>>> minor changes reviewed and committed.
>>>
>>> Thanks,
>>>
>>> Joey
>>>
>>
>
>
Re: Pending PDA Patches
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Joey,
I haven't had time to respond.
I don't know what the dependency method should be.
Your suggestion:
Is it acceptable to locally apply the earlier patch that has not yet
been committed and, in effect, include that patch in a new patch?
I think this is acceptable, because I don't think this new patch would get
reviewed until the first patch that it depends on gets checked in.
So then when we review the second patch, the differences won't be the
differences of both patches, just the second patch.
- Jeanne
Joseph Rozier wrote:
> Hello,
>
> I'm resending this since there was no response to the first one...
>
> I'd particularly appreciate a response to what the desired way to
> handle patch dependencies is, when one patch is dependent on another
> patch that has not yet been committed. (The review/committing of the
> outstanding PDA patches would be appreciated as well. :))
>
> Thanks,
>
> Joey
>
> On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
>
>> Hello,
>>
>> The following two JIRAs have patches waiting to be reviewed/committed.
>>
>> https://issues.apache.org/jira/browse/ADFFACES-167
>> Add 'autoSubmit' support for basic input components on PDAs
>>
>> https://issues.apache.org/jira/browse/ADFFACES-110
>> Add Agent for BlackBerry Browser 4.0
>> (this has a fix to the original patch)
>>
>> Would it be possible to get these two patches committed?
>>
>> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
>> but they have dependencies on these patches.
>>
>> Also, for the future, what is the protocol for submitting patches that
>> have dependencies on earlier patches that have not yet been committed.
>> Is it acceptable to locally apply the earlier patch that has not yet
>> been committed and, in effect, include that patch in a new patch?
>>
>> I can see how that would make patch reviewing a headache, but we're
>> running into the issue where a lot of the PDA patches have dependences
>> on earlier patches and it typically takes several days to get even
>> minor changes reviewed and committed.
>>
>> Thanks,
>>
>> Joey
>>
>
Re: Pending PDA Patches
Posted by Joseph Rozier <jo...@gmail.com>.
Hello,
I'm resending this since there was no response to the first one...
I'd particularly appreciate a response to what the desired way to
handle patch dependencies is, when one patch is dependent on another
patch that has not yet been committed. (The review/committing of the
outstanding PDA patches would be appreciated as well. :))
Thanks,
Joey
On 9/13/06, Joseph Rozier <jo...@gmail.com> wrote:
> Hello,
>
> The following two JIRAs have patches waiting to be reviewed/committed.
>
> https://issues.apache.org/jira/browse/ADFFACES-167
> Add 'autoSubmit' support for basic input components on PDAs
>
> https://issues.apache.org/jira/browse/ADFFACES-110
> Add Agent for BlackBerry Browser 4.0
> (this has a fix to the original patch)
>
> Would it be possible to get these two patches committed?
>
> We have fixes for two other JIRAs (ADFFACES-172 and -173) ready to go,
> but they have dependencies on these patches.
>
> Also, for the future, what is the protocol for submitting patches that
> have dependencies on earlier patches that have not yet been committed.
> Is it acceptable to locally apply the earlier patch that has not yet
> been committed and, in effect, include that patch in a new patch?
>
> I can see how that would make patch reviewing a headache, but we're
> running into the issue where a lot of the PDA patches have dependences
> on earlier patches and it typically takes several days to get even
> minor changes reviewed and committed.
>
> Thanks,
>
> Joey
>