Daniel Varela Santoalla wrote:
>
> We've been using XXE Pro quite extensively here in the last weeks and we
> found some small "glitches", so I will enumerate them for you:
>
> - ********************************************************************
> - We have a date-field in a CSS, defined as follows, and we found that
> sometimes a valid date doesn't get internally converted into an ISO date
> as it should upon leaving the field. The probability of this happening
> seems to be higher if you edit (type) very fast... Then there is a
> validation error, of course, though the date may look like a perfectly
> valid one, which utterly puzzles the users.
>
> CSS:
> pr|estimation {
> content: paragraph(content(date-field(columns, 10,
> pattern, "dd/MM/yyyy",
> background-color, #ffffe0,
> color, black),
> " (dd/mm/yyyy): "));
> }
>
> Schema:
> <xs:complexType name="ReadyBy">
> <xs:sequence>
> <xs:element name="estimation" type="xs:date"
> maxOccurs="unbounded" minOccurs="1" ></xs:element>
> </xs:sequence>
> </xs:complexType>
I was not able to reproduce this problem on V2.3p1 (no matter how fast I
type the date; and even with directly pasting the date in the text field
and immediately pressing tab after that).
I recommend that you use V2.3p1 if it is not already the case. In V2.3,
parsing of dates was ``lenient'' which was counter intuitive and error
prone.
The behavior you describe can be reproduced using other methods. May be
your users in fact do this:
[1] They type an invalid date.
[2] They click on the validate button at the bottom of the window (or
simply save and exit the application). That is, they leave the field but
also the whole document view.
By doing this, it is possible to create documents containing an invalid
date.
> - ********************************************************************
>
> The search feature doesn't seem to look into the contents of
> text-fields. This makes it less useful when you have a very long form
> and you want to locate some data.
This is quite hard to implement.
> - ********************************************************************
>
> In some cases the whole XXE interface was stuck after pasting data from
> OpenOffice. Selecting another window and then XXE again (forcing a
> screen repaint...) seems to solve the problem, just to be repeated when
> pasting again. This behaviour is not consistent, but once it starts, it
> doesn't stop till you close the document and open it again.
This looks like a Java problem. We'll investigate about it as soon as
we'll install KDE 2.2/OpenOffice (next week).
> - ********************************************************************
>
> Then, as the last thing, it would be nice to be able to set an option
> somewhere to prevent users from saving invalid documents, or at least to
> show a very visible warning. Due to the problem with dates we had some
> invalid document saved and then the only effect is that we get funny
> results, being difficult to spot.
>
> Ideally this option should be set on a document-type basis....
For now, see option 'Automatically show Validity tool' in the Save tab
of Options|Options. We'll think about implementing an even more severe
option.
