[
Lists Home |
Date Index |
Thread Index
]
>
> What we are doing at Hanse Orga is developing a financial software, where
we
> used xml as a bridge between our backend programmed with COM and our
> frontend developed with XSLT, which transformed the XML-String passed by
our
> ServletEngine (Java) into XHTML combined with CSS and Javascript.
Javascript
> we use for some validations at the client side (IE6). This is a
workaround,
> because our business logic written in Centura/Gupta exists since many
years
> on a windows client/server system.
>
> My first key question is, that i want try to include the XML Schema
linking
> it with my XML Instance String, which are transformed with XSLT in the
above
> mentionred output.
> I know now, that MSXML 4 support the whole W3 Recommendation of XML
Schema.
> Can anyone supplies a working example, how to link this three document on
> the client side?
>
I presume what you want to do is validate XML before you pass it to
XSLT which generates your XHTML. Its simple and probably good
for your initial phase of the project where you might want to trap that
what's coming from the server is compliant with the designated schema.
But once you are convince that the output generating from your server
is stable, you might want to turn validation off as this validation may
become unnecessary. There are loads of examples in the sdk if you
are looking for such simple validation.
> Secondly, from that point i want test, if it is possibly to do some
> validation on the client side, to see if i can validate against the schema
> by checking the user input, instead of using complicated javascripts. I
> imagine for example, if some user put a not valid date format in an input
> field, an alert box pops up with the message "This is not a valid date
> format" . Is this possible to generate with XML Schema ? Or is XML Schema
> designed in mind for software agents, valid data exchange and
documentation
> purpose only ?
You should note these,
1. The error message that you get from DOM does not easily
allow you to pin-point where the offending field is if you are
validating a fully composed XML input (i.e. you piece all the
information into a single XML structure for validation).
Pumping the error message to the user may confuse him or her
and thus not very useful.
You can however use schema to validate field-by-field, you
have to retrieve the corresponding element/type and call isValid().
This will allow you to gain fine control on where errors may
occur and react with the user accordingly. If this is what you
want to do, you will need to understand how to structure your
schema such that such types/element definition are available
globally so as to allow you to conveniently retrieve them for
validation. Also note that schema validate date time against
ISO 8601 format which is a good idea to standardise on but
may not meet your user expectation of how a date time should
be displayed and entered, but its not a problem translating
between the two, but don't expect straightforward validation
just in case that's what you are looking for.
2. Schema validation does not validate application logic. Yes, you
can achieve a first layer of type facets and structural validation thru
the schema but you can't perform application logic related validation.
Unless of course satisfying schema validation also satisfy your
application logics (rare IMO).
Field-by-field schema validation then followed by application
logic validation in Javascript might still be unavoidable but
this 2-layer approach will make your application more robust.
3. IMO, you should probably also use schema validation at the
server-side to trap malformed XML and do script-based
validation at the client end to interact with User's input. This way,
when many developers can work on the UI, you have a central
validator that ensure that what comes in to the server is not
garbage. It will also allow you to use browsers other than IE
to service your users.
Of course, if the data is actually not sent to a server but pumped
into COM at the client side, this "server-side-trap" will still be
useful for the same purpose but it makes code maintenance
messy.
HTH.
|
