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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>
>>
>
>
