Problem with <xforms:group> inside a Table with 3.7.1

Hi,

I have been experiencing some issues with using <xforms:group> inside a table. This used to be working in 3.6 and I have been seeing problems when I upgraded to 3.7.1. The problem seems to be in the formatting of the cells in the table. I have three rows that are conditionally shown in the table using <xforms:group>.
If I select the condition for the first group, the row displays correctly. However, If I enable the condition for a subsequent group, while keeping the first group disabled, then the formatting in the table becomes skewed to the left. If I enable the conditions in a linear fashion, first condition #1, then condition #2 and finally condition #3, then the table layout shows as expected.

There seemed to be a similar issue in a previous post referenced here:

href="http://www.nabble.com/Problem-with-TR-inside-a-group-td24038009.html#a24038009">http://www.nabble.com/Problem-with-TR-inside-a-group-td24038009.html#a24038009

I have tried the recommended workaround, but was unable to fix my problem in the same manner.

my page layout looks like the following:


<some input controls>


<xhtml:table>

    <xforms:group ref=[condition #1 controlled by controls above] >


    <xforms:group ref=[condition #2 controlled by controls above] >       <------ if either group 2,3 is                                  
                                                                                                            enabled before group 1
                                                                                                            then table layout is
                                                                                                            skewed
    <xforms:group ref=[condition #3 controlled by controls above] >

</xhtml:table>some_assessment.xhtml


I have attached a sample page which demonstrates this problem. This is reproducible running in the Orbeon Sandbox.  

Murray M wrote

I have attached a sample page which demonstrates this problem. This is reproducible running in the Orbeon Sandbox.  

I have your example running, but what should I do in that example to reproduce the issue you are describing?

Alex

First of all, for me it's working with IE but not with FireFox.
If you change something in the "Age related hazards" select, the table gets messed up.

Antoine

-----Original Message-----
From: Alessandro Vernet [mailto:[hidden email]]
Sent: Friday, June 26, 2009 10:20 AM
To: [hidden email]
Subject: [ops-users] Re: Problem with <xforms:group> inside a Table with 3.7.1



Murray M wrote:
>
> I have attached a sample page which demonstrates this problem. This is
> reproducible running in the Orbeon Sandbox.  
>

I have your example running, but what should I do in that example to
reproduce the issue you are describing?

Alex

-----
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
Personal Blog: http://avernet.blogspot.com/
Twitter - http://twitter.com/avernet
--
View this message in context: http://www.nabble.com/Problem-with-%3Cxforms%3Agroup%3E-inside-a-Table-with-3.7.1-tp24207940p24216637.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

I also have this problem - http://www.nabble.com/Orbeon-3.7.1-bugs-td24053183.html, and already attached screencast and sandbox example.




--
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

Hi Alex,

Sorry for the confusion in the example, I could've simplified it a bit more to be more clear. But as it is, here are the instructions...

Of the three input controls, selecting a value other than "Not Assessed" or "Not a Problem" will conditionally activate some groups in the table at the bottom of the page.

If you enable the groups in the table starting with input control 1, then input control 2, then input control 3, then the table layout looks good and has no issues.

However, if you FIRST enable either the 2nd group or the 3rd group in the table ( by selecting a value from the corresonding input control ), the table layout becomes skewed and you can start to notice the problem.

I will simply the example if this is still confusing and difficult to reproduce.

Many Thanks,
Murray

Alessandro Vernet wrote

Murray M wrote

I have attached a sample page which demonstrates this problem. This is reproducible running in the Orbeon Sandbox.  

I have your example running, but what should I do in that example to reproduce the issue you are describing?

Alex

Murray,

Murray M wrote

However, if you FIRST enable either the 2nd group or the 3rd group in the table ( by selecting a value from the corresonding input control ), the table layout becomes skewed and you can start to notice the problem.

I must be missing something. Here is what I did, selecting the 2nd, then 3rd, then 1st item and don't see the "layout becoming skewed". Am I missing something? See:

http://screencast.com/t/ZaSSBjOjp

Alex

Hi ,

Can anybody helpme as iam facing problem with xs:decimal which is removing trailing zeros

This is my code

<xforms:setvalue ref="node1" value="xs:decimal('14.00')"/>

Result is

14

Expected output

14.00

 

Thanks in advance.

 

Regards,

Gopi

 

 

 

 

 


This e-mail (and any attachments), is confidential and may be privileged. It may be read, copied and used only
by intended recipients. Unauthorized access to this e-mail (or attachments) and disclosure or copying of its
contents or any action taken in reliance on it is unlawful. Unintended recipients must notify the sender immediately
by e-mail/phone & delete it from their system without making any copies or disclosing it to a third person.


--
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

Raitis,

Raitis wrote

I also have this problem -
http://www.nabble.com/Orbeon-3.7.1-bugs-td24053183.html, and already
attached screencast and sandbox example.

Looks like I missed your other message! I posted a response in that thread you point to, and hopefully this is the same issue Murray has been mentioning here.

Alex

Hi Alex,

Here is the sample application running in the Orbeon Sandbox ( I used the online version just to confirm it is not my environment setup ). The difference between your video clip is that the table rows should not be showing until the input control activates that specific row/group in the table. If the table rows are already showing, then the behaviour works as expected. It seems to be the conditional display of the rows that is causing this problem.


http://www.screencast.com/users/murraymaleschuk/folders/Jing/media/dcbb8794-8cd3-47c5-b6bc-13d1b79ed991


Thanks again for your help with this issue.
-Murray

Alessandro Vernet wrote

Murray,

Murray M wrote

However, if you FIRST enable either the 2nd group or the 3rd group in the table ( by selecting a value from the corresonding input control ), the table layout becomes skewed and you can start to notice the problem.

I must be missing something. Here is what I did, selecting the 2nd, then 3rd, then 1st item and don't see the "layout becoming skewed". Am I missing something? See:

http://screencast.com/t/ZaSSBjOjp

Alex

Gopi,

Reddy, Gopikrishna wrote

<xforms:setvalue ref="node1" value="xs:decimal('14.00')"/>

Result is

14

Expected output

14.00

This is just the way it is in XPath. If you convert 14.00 to a decimal, and then convert it back to a string, you get just 14. You can use the XSLT 2.0 function format-number() to format a number the way you want (see: http://www.orbeon.com/ops/doc/reference-xforms-functions#d9e94).

Alex

Murray,

Murray M wrote

Here is the sample application running in the Orbeon Sandbox ( I used the online version just to confirm it is not my environment setup ). The difference between your video clip is that the table rows should not be showing until the input control activates that specific row/group in the table. If the table rows are already showing, then the behaviour works as expected. It seems to be the conditional display of the rows that is causing this problem.

Removing the colspan="35" on the cell that contains "Focus Areas" solves the problem for me. Now, I am not sure why the colspan="35" does not takes effect in Firefox if you show the first group first; the inconsistency looks like a bug to me. Was there any reason to have that colspan="35" there?

Alex

Hi Alex,

I tried your suggestion and this did not fix my problem. I will of course agree with you that the colspan=35 doesnt need to be there.

I think this fix is subtle enough that it might be browser dependent. I didn't see this problem at all in IE v6. I am using Firefox/2.0.0.20 and it still seems to be a problem regardless of removing the colspan attribute.

Alessandro Vernet wrote

Murray,

Murray M wrote

Here is the sample application running in the Orbeon Sandbox ( I used the online version just to confirm it is not my environment setup ). The difference between your video clip is that the table rows should not be showing until the input control activates that specific row/group in the table. If the table rows are already showing, then the behaviour works as expected. It seems to be the conditional display of the rows that is causing this problem.

Removing the colspan="35" on the cell that contains "Focus Areas" solves the problem for me. Now, I am not sure why the colspan="35" does not takes effect in Firefox if you show the first group first; the inconsistency looks like a bug to me. Was there any reason to have that colspan="35" there?

Alex

Murray,

Murray M wrote

I tried your suggestion and this did not fix my problem. I will of course agree with you that the colspan=35 doesnt need to be there.

True, I am trying this again re-applying the change to the file you attached earlier in the thread and it isn't working for me either. So when I had it working on my machine, I either made some other change, or I dreamed (hopefully it was the former!). I'll need to investigate this further, but am not sure when I'll have the time to do it. Let us know if you find the solution in the meantime.

Alex

Murray & all,

Alessandro Vernet wrote

True, I am trying this again re-applying the change to the file you attached earlier in the thread and it isn't working for me either. So when I had it working on my machine, I either made some other change, or I dreamed (hopefully it was the former!). I'll need to investigate this further, but am not sure when I'll have the time to do it. Let us know if you find the solution in the meantime.

This isn't a fresh thread anymore, so let's start with a summary of the issue:

* Murray reported a problem which can be reproduced by running the following XHML+XForms in the XForms sandbox: http://www.nabble.com/file/p24207940/some_assessment.xhtml
* Murray also posted a screencast showing the issue: http://www.screencast.com/users/murraymaleschuk/folders/Jing/media/dcbb8794-8cd3-47c5-b6bc-13d1b79ed991
* This is only an issue on Firefox 3, not on IE6/IE7.
* The rows are not aligned with  http://screencast.com/t/3idzgbK9H

This is a Firefox issue. A work-around is to add the following to your CSS:

.xforms-disabled { display: none; }

I created a bug for this where I put the information above. You can see the bug at:

http://forge.ow2.org/tracker/index.php?func=detail&aid=314236&group_id=168&atid=350207

Alex