Re: Xhtml with XForms export from OOo2.0 beta

--=_alternative 00503FB8C1257059_=
Content-Type: text/plain; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable

Lars Oppermann <[email protected]> wrote on 2005.08.10 10:10:52:

> Hi L=E1szl=F3,
>=20
> Your interest is much appreciated. Have you had a look at the XHTML XSL=20
> transformations, that are already part of the filter project? They lack=20
> any support for XForms and they are not even updated to OpenDocument 1.0 =


> yet, but they should be worth a look nevertheless, since they provide=20
> some guidelines on how to handle the OpenOffice XML in XSL

Could you give me an exact link to the filter project?
I've tried to seach it, but a couldn't found it.

Anyway I've checked the files in the share/xslt/export/xhtml folder.
On first look, it is too complicated for me (I'm not an XSL specialist).
So on first try I converting only the form controls.
If it is successful then I'll try to add to the converter into the html=20
filter.

>=20
> I am not sure, whether just exporting the form part will suffice. Would=20
> the user need to recreate everything else, that's in the document?
>=20
> > How to deal with the document text content? I think I'll skip it, and=20
> > only form controls will be exported.
>=20
> As stated above. I would think, that as much of the content as possible=20
> should be preserved. The existing XSL scripts show how it is done.
>=20
First I'll have to find out how.

> While Office has no support for repeatable, you could create a=20
> workaround, that uses a specific style name to tag a repeatable section. =


> Your XSL could then handle that style accordingly and generate the real=20
> repeatable elements.
> Be sure to build this in a way, that can be replaced/taken-out once=20
> OpenOffice has real repeatable support.

Repeating sections:
Could you explain how to assign styles for a group of controls?
I've found no way to do this.
I think it is a better way to give a special name for the group
(the draw:g object's @draw:name attribute) to rigth click on the group,
then "Name object". The group seems a good container for the repeat body.



Finally I've found some new bugs:
(1.9m122 is used)

1.
On my first test I've created an XML document, with two Models.
Each model contains one Instance, and the each instances have
only one data element.
I've pulled (with drag&drop) the data elements to the document,
so finally the document contains two groups, each group contains
a label and a control.
The first control references to Binding1 in Model 1,
the second control references to Binding1 in MODEL 2.
But the UI does not write the xforms:model atribute into the file.
So each control use the first model element (witch is MODEL2 after
reopening the document, see bug#2 for details).

2.
The first (default) model called "Model 1"
then I've created a new model called "MODEL 2" (all uppercase!)
The model selection combobox shows two values:
"Model 1" and "MODEL 2" (in this order)
After closing and reopening the file, the order of the model changes,
because it is written to the file in case sensitive abc order (it's=20
correct).
But when a new model is added (or renamed) the new name is added to the
last position of the combobox.
So the combobox doesn't reflect the real order of the models in the file,
and the order can be change after reopening the document.



I have to write these issues into the bugzilla or this is a good place for =

it?
(I haven't registered jet.)

LML

--=_alternative 00503FB8C1257059_=
Content-Type: text/html; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>Lars Oppermann &lt;[email protected]&gt; wrote
on 2005.08.10 10:10:52:<br>
<br>
&gt; Hi L=E1szl=F3,<br>
&gt; <br>
&gt; Your interest is much appreciated. Have you had a look at the XHTML
XSL <br>
&gt; transformations, that are already part of the filter project? They
lack <br>
&gt; any support for XForms and they are not even updated to OpenDocument
1.0 <br>
&gt; yet, but they should be worth a look nevertheless, since they provide
<br>
&gt; some guidelines on how to handle the OpenOffice XML in XSL<br>
</tt></font>
<br><font size=3D2><tt>Could you give me an exact link to the filter projec=
t?</tt></font>
<br><font size=3D2><tt>I've tried to seach it, but a couldn't found it.</tt=
></font>
<br>
<br><font size=3D2><tt>Anyway I've checked the files in the share/xslt/expo=
rt/xhtml
folder.</tt></font>
<br><font size=3D2><tt>On first look, it is too complicated for me (I'm not
an XSL specialist).</tt></font>
<br><font size=3D2><tt>So on first try I converting only the form controls.=
</tt></font>
<br><font size=3D2><tt>If it is successful then I'll try to add to the conv=
erter
into the html filter.</tt></font>
<br><font size=3D2><tt><br>
&gt; <br>
&gt; I am not sure, whether just exporting the form part will suffice.
Would <br>
&gt; the user need to recreate everything else, that's in the document?</tt=
></font>
<br><font size=3D2><tt>&gt; <br>
&gt; &gt; How to deal with the document text content? I think I'll skip
it, and <br>
&gt; &gt; only form controls will be exported.<br>
&gt; <br>
&gt; As stated above. I would think, that as much of the content as possible
<br>
&gt; should be preserved. The existing XSL scripts show how it is done.<br>
&gt; </tt></font>
<br><font size=3D2><tt>First I'll have to find out how.</tt></font>
<br>
<br><font size=3D2><tt>&gt; While Office has no support for repeatable, you
could create a <br>
&gt; workaround, that uses a specific style name to tag a repeatable sectio=
n.
<br>
&gt; Your XSL could then handle that style accordingly and generate the
real <br>
&gt; repeatable elements.<br>
&gt; Be sure to build this in a way, that can be replaced/taken-out once
<br>
&gt; OpenOffice has real repeatable support.</tt></font>
<br>
<br><font size=3D2><tt>Repeating sections:</tt></font>
<br><font size=3D2><tt>Could you explain how to assign styles for a group
of controls?</tt></font>
<br><font size=3D2><tt>I've found no way to do this.</tt></font>
<br><font size=3D2><tt>I think it is a better way to give a special name
for the group</tt></font>
<br><font size=3D2><tt>(the draw:g object's @draw:name attribute) to rigth
click on the group,</tt></font>
<br><font size=3D2><tt>then &quot;Name object&quot;. The group seems a good
container for the repeat body.</tt></font>
<br>
<br>
<br>
<br><font size=3D2><tt>Finally I've found some new bugs:</tt></font>
<br><font size=3D2><tt>(1.9m122 is used)</tt></font>
<br>
<br><font size=3D2><tt>1.</tt></font>
<br><font size=3D2><tt>On my first test I've created an XML document, with
two Models.</tt></font>
<br><font size=3D2><tt>Each model contains one Instance, and the each insta=
nces
have</tt></font>
<br><font size=3D2><tt>only one data element.</tt></font>
<br><font size=3D2><tt>I've pulled (with drag&amp;drop) the data elements
to the document,</tt></font>
<br><font size=3D2><tt>so finally the document contains two groups, each
group contains</tt></font>
<br><font size=3D2><tt>a label and a control.</tt></font>
<br><font size=3D2><tt>The first control references to Binding1 in Model
1,</tt></font>
<br><font size=3D2><tt>the second control references to Binding1 in MODEL
2.</tt></font>
<br><font size=3D2><tt>But the UI does not write the xforms:model atribute
into the file.</tt></font>
<br><font size=3D2><tt>So each control use the first model element (witch
is MODEL2 after</tt></font>
<br><font size=3D2><tt>reopening the document, see bug#2 for details).</tt>=
</font>
<br>
<br><font size=3D2><tt>2.</tt></font>
<br><font size=3D2><tt>The first (default) model called &quot;Model 1&quot;=
</tt></font>
<br><font size=3D2><tt>then I've created a new model called &quot;MODEL 2&q=
uot;
(all uppercase!)</tt></font>
<br><font size=3D2><tt>The model selection combobox shows two values:</tt><=
/font>
<br><font size=3D2><tt>&quot;Model 1&quot; and &quot;MODEL 2&quot; (in this
order)</tt></font>
<br><font size=3D2><tt>After closing and reopening the file, the order of
the model changes,</tt></font>
<br><font size=3D2><tt>because it is written to the file in case sensitive
abc order (it's correct).</tt></font>
<br><font size=3D2><tt>But when a new model is added (or renamed) the new
name is added to the</tt></font>
<br><font size=3D2><tt>last position of the combobox.</tt></font>
<br><font size=3D2><tt>So the combobox doesn't reflect the real order of
the models in the file,</tt></font>
<br><font size=3D2><tt>and the order can be change after reopening the docu=
ment.</tt></font>
<br>
<br>
<br>
<br><font size=3D2><tt>I have to write these issues into the bugzilla or
this is a good place for it?</tt></font>
<br><font size=3D2><tt>(I haven't registered jet.)</tt></font>
<br>
<br><font size=3D2><tt>LML</tt></font>
<br>
--=_alternative 00503FB8C1257059_=--