Weird rendering problems in latest nightly build

> converted to '1' such as 10/1/2008 is a problem . This is a known  
> problem in
> 3.7 Beta 1 .
>
> From the discussion group, it seems that the nightly build fixes this
> problem. We tried it out and the date problem above is indeed fixed :)
>
> However, the nightly build that we tried out ...
> orbeon-3.7.0beta1+.200811190222 has some weird rendering problem:  
> For e.g.
> one of the 'select1' tags are being rendered as combo boxes that  
> appear on
> every tab (not supposed to).  Fonts seem to be off. etc.

>
> Erik,
> I think the stylesheets are alright. The fonts are just fine ( I  
> misreported
> earlier). IN fact there is ONLY ONE problem :) (good news!).
> And, I think we might have a clue what area might be causing a  
> problem.
>
> Our complex form is laid out into tabs. Each tab triggers a switch/
> case
> toggle to render that particular tab.
> Two of the 6 tabs have NESTED Switch/case statements to show or hide
> alternate UI elements.
>
> I think that nesting case is causing an extra "leak" of elements  
> showing up
> where they do not belong.
>
> We have divided up our long form into xml fragments that we xinclude .
> Our tabs switch/case looks like this:
> <xf:switch>
>    <xf:case id="buyers-case">
>        <xi:include href="../../crv/tabs/buyers-o.xml"
> xxi:omit-xml-base="true"/>
>    </xf:case>
>
>    <xf:case id="sellers-case">
>        <xi:include href="../../crv/tabs/sellers-o.xml"
> xxi:omit-xml-base="true"/>
>    </xf:case>
> ....
> ....
>
> buyers-o.xml  and sellers-o.xml has the nested xf:switch like this:
> ....
> ....
>           <xf:switch>
>                <xf:case id="show-us-state">
>                    <xhtml:div>
>                        <xf:select1  
> ref="c:LocationStateFIPS5-2AlphaCode">
>                            <xf:label class="fixed-width">State:</
> xf:label>
>                            <xf:itemset model="CRV"
>
> nodeset="instance('RegionStateFIPSCode')/EnumeratedValues/Item">
>                                <xf:label>
>                                    <xf:output ref="Label"/>
>                                    (<xf:output ref="Value"/>)
>                                </xf:label>
>                                <xf:value ref="Value"/>
>                            </xf:itemset>
>                        </xf:select1>
>                    </xhtml:div>
>                </xf:case>
>
>                <xf:case id="show-foreign-state">
>                    <xhtml:div>
>                        <xf:input ref="u:LocationStateName">
>                            <xf:label class="fixed-width">Foreign  
> state or
> province name:</xf:label>
>                        </xf:input>
>                    </xhtml:div>
>                </xf:case>
>
>            </xf:switch>
> ....
> ....
>
> The toggle happens correctly. However the toggled UI element shows  
> up on ALL
> the tabs. And THAT is the problem. I am hoping this behavior has to  
> do with
> some code changes that might have touched the switch/case rendering  
> logic.
> I will try to upload some pictures. You will see it immediately... and
> hopefully will help you zero in in the problem/solution.
>
> http://www.nabble.com/file/p20604956/ui-control-in-wrong-tab.png
>
>
> Erik Bruchez wrote:
>>
>>> The Calendar date problem where 10/31/2008 or any valid '31' date  
>>> gets
>>> converted to '1' such as 10/1/2008 is a problem . This is a known
>>> problem in
>>> 3.7 Beta 1 .
>>>
>>> From the discussion group, it seems that the nightly build fixes  
>>> this
>>> problem. We tried it out and the date problem above is indeed  
>>> fixed :)
>>>
>>> However, the nightly build that we tried out ...
>>> orbeon-3.7.0beta1+.200811190222 has some weird rendering problem:
>>> For e.g.
>>> one of the 'select1' tags are being rendered as combo boxes that
>>> appear on
>>> every tab (not supposed to).  Fonts seem to be off. etc.
>>
>> That sounds like a CSS stylesheet is incorrect or missing.
>>
>> * Did you try with multiple browsers and/or emptying your browser  
>> cache?
>> * If you just drop a plain orbeon.war nightly to Tomcat, do you see
>> the issue with the built-in examples?
>> * How did you upgrade to the nightly build?
>>
>>> Should I wait for a more 'tested' or stable release? Can someone
>>> mention to
>>> be a nightly build that is more stable with the date logic fixed? Is
>>> there
>>> are a page with builds from each day for the past week or something?
>>
>> Each nightly build replaces the previous one. But given a CVS tag,  
>> you
>> could rebuild any nightly.
>>
>>> We are very impressed with Orbeon - the performance, scalability and
>>> completeness is world-class.
>>
>> Thanks!
>>
>> -Erik
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]  
>> mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Weird-rendering-problems-in-latest-nightly-build-tp20590234p20604956.html
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

>
> Erik,
> I shall try. I will try to find time for this.  I am pretty  
> convinced that
> is the cause of the problem ( nested Switch/case/toggle since I did  
> find the
> workaround:
>
> I did find a WORKAROUND:
>
> The experts might laugh at our original solution :) But I realized  
> that we
> really did not need the switch/case/toggle construct. Since the schema
> supports only one of two elements, each of them mutually exclusive,  
> I just
> changed the UI binds take care of the behavior. When the model  
> element does
> not exist, the UI does not show up!
> ....
>           <!--show field dependent on foreign indicator-->
>                <xhtml:div class="inplace-optional">
>                    <xf:select1 ref="c:LocationStateFIPS5-2AlphaCode">
>                        <xf:label>State:</xf:label>
>                        <xf:itemset model="CRV"
>
> nodeset="instance('RegionStateFIPSCode')/EnumeratedValues/Item">
>                            <xf:label>
>                                <xf:output ref="Label"/>
>                                (<xf:output ref="Value"/>)
>                            </xf:label>
>                            <xf:value ref="Value"/>
>                        </xf:itemset>
>                    </xf:select1>
>                </xhtml:div>
>
>                <xhtml:div class="inplace-optional">
>                    <xf:input ref="u:LocationStateName">
>                        <xf:label>Foreign state or province name:</
> xf:label>
>                    </xf:input>
>                </xhtml:div>
> ....
>
> Since the model-correctness guarantees that u:LocationStateName and
> c:LocationStateFIPS5-2AlphaCode are mutually exclusive, only one  
> shows up -
> which meets our needs.
>
> -arun
>
>
> Erik Bruchez wrote:
>>
>> Thanks for looking into this.
>>
>> Is there any way you can create a simple standalone example, running
>> in the XForms sandbox, showing this beahavior?
>>
>> -Erik
>>
>> On Nov 20, 2008, at 8:26 AM, Arun Batchu wrote:
>>
>>>
>>> Erik,
>>> I think the stylesheets are alright. The fonts are just fine ( I
>>> misreported
>>> earlier). IN fact there is ONLY ONE problem :) (good news!).
>>> And, I think we might have a clue what area might be causing a
>>> problem.
>>>
>>> Our complex form is laid out into tabs. Each tab triggers a switch/
>>> case
>>> toggle to render that particular tab.
>>> Two of the 6 tabs have NESTED Switch/case statements to show or hide
>>> alternate UI elements.
>>>
>>> I think that nesting case is causing an extra "leak" of elements
>>> showing up
>>> where they do not belong.
>>>
>>> We have divided up our long form into xml fragments that we  
>>> xinclude .
>>> Our tabs switch/case looks like this:
>>> <xf:switch>
>>>   <xf:case id="buyers-case">
>>>       <xi:include href="../../crv/tabs/buyers-o.xml"
>>> xxi:omit-xml-base="true"/>
>>>   </xf:case>
>>>
>>>   <xf:case id="sellers-case">
>>>       <xi:include href="../../crv/tabs/sellers-o.xml"
>>> xxi:omit-xml-base="true"/>
>>>   </xf:case>
>>> ....
>>> ....
>>>
>>> buyers-o.xml  and sellers-o.xml has the nested xf:switch like this:
>>> ....
>>> ....
>>>          <xf:switch>
>>>               <xf:case id="show-us-state">
>>>                   <xhtml:div>
>>>                       <xf:select1
>>> ref="c:LocationStateFIPS5-2AlphaCode">
>>>                           <xf:label class="fixed-width">State:</
>>> xf:label>
>>>                           <xf:itemset model="CRV"
>>>
>>> nodeset="instance('RegionStateFIPSCode')/EnumeratedValues/Item">
>>>                               <xf:label>
>>>                                   <xf:output ref="Label"/>
>>>                                   (<xf:output ref="Value"/>)
>>>                               </xf:label>
>>>                               <xf:value ref="Value"/>
>>>                           </xf:itemset>
>>>                       </xf:select1>
>>>                   </xhtml:div>
>>>               </xf:case>
>>>
>>>               <xf:case id="show-foreign-state">
>>>                   <xhtml:div>
>>>                       <xf:input ref="u:LocationStateName">
>>>                           <xf:label class="fixed-width">Foreign
>>> state or
>>> province name:</xf:label>
>>>                       </xf:input>
>>>                   </xhtml:div>
>>>               </xf:case>
>>>
>>>           </xf:switch>
>>> ....
>>> ....
>>>
>>> The toggle happens correctly. However the toggled UI element shows
>>> up on ALL
>>> the tabs. And THAT is the problem. I am hoping this behavior has to
>>> do with
>>> some code changes that might have touched the switch/case rendering
>>> logic.
>>> I will try to upload some pictures. You will see it immediately...  
>>> and
>>> hopefully will help you zero in in the problem/solution.
>>>
>>> http://www.nabble.com/file/p20604956/ui-control-in-wrong-tab.png
>>>
>>>
>>> Erik Bruchez wrote:
>>>>
>>>>> The Calendar date problem where 10/31/2008 or any valid '31' date
>>>>> gets
>>>>> converted to '1' such as 10/1/2008 is a problem . This is a known
>>>>> problem in
>>>>> 3.7 Beta 1 .
>>>>>
>>>>> From the discussion group, it seems that the nightly build fixes
>>>>> this
>>>>> problem. We tried it out and the date problem above is indeed
>>>>> fixed :)
>>>>>
>>>>> However, the nightly build that we tried out ...
>>>>> orbeon-3.7.0beta1+.200811190222 has some weird rendering problem:
>>>>> For e.g.
>>>>> one of the 'select1' tags are being rendered as combo boxes that
>>>>> appear on
>>>>> every tab (not supposed to).  Fonts seem to be off. etc.
>>>>
>>>> That sounds like a CSS stylesheet is incorrect or missing.
>>>>
>>>> * Did you try with multiple browsers and/or emptying your browser
>>>> cache?
>>>> * If you just drop a plain orbeon.war nightly to Tomcat, do you see
>>>> the issue with the built-in examples?
>>>> * How did you upgrade to the nightly build?
>>>>
>>>>> Should I wait for a more 'tested' or stable release? Can someone
>>>>> mention to
>>>>> be a nightly build that is more stable with the date logic  
>>>>> fixed? Is
>>>>> there
>>>>> are a page with builds from each day for the past week or  
>>>>> something?
>>>>
>>>> Each nightly build replaces the previous one. But given a CVS tag,
>>>> you
>>>> could rebuild any nightly.
>>>>
>>>>> We are very impressed with Orbeon - the performance, scalability  
>>>>> and
>>>>> completeness is world-class.
>>>>
>>>> Thanks!
>>>>
>>>> -Erik
>>>>
>>>> --
>>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>>> http://www.orbeon.com/
>>>>
>>>>
>>>>
>>>> --
>>>> You receive this message as a subscriber of the [hidden email]
>>>> mailing
>>>> list.
>>>> To unsubscribe: mailto:[hidden email]
>>>> For general help: mailto:[hidden email]?subject=help
>>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Weird-rendering-problems-in-latest-nightly-build-tp20590234p20604956.html
>>> Sent from the ObjectWeb OPS - Users mailing list archive at
>>> Nabble.com.
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the [hidden email]
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]  
>> mailing
>> list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Weird-rendering-problems-in-latest-nightly-build-tp20590234p20608928.html
> Sent from the ObjectWeb OPS - Users mailing list archive at  
> Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws