Skip to main content

Uniface 9: Maintaining a DTD/XML driven client server environment

  • November 19, 2018
  • 8 replies
  • 0 views
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

8 replies

Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Hi Iain,

have I understood the assignment correct when I say you need:

a tool which compares your DTDs with entities looking for missing fields?

But where do you make the link between entities and DTDs, via name?

Think it should not be too much of a problem to get the fieldnames out of a simple DTD definition
same goes for getting the fields of an entity out of the repository.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Well, the entity name is included in the DTD definition as well.

It's more a discussion to see what strategies people who have taken on the XML client server development strategy are currently using to maintain their data integrity.


Author: Iain Sharp (i.sharp@pcisystems.co.uk)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Hi Iain,

from my point of view (formely known as dITo),
all we need is some specification how to build which DTD (using a * to denote "all fields".

Then we can implement a tiny DTD Generator tool transfering this information
with the help of the current state of datamodel held in the repository
into a DTD.

All we need is to compare the generated DTD with the DTD held in the uniface repository.
If there are differences, we have already the text as it should be and can take the necessary actions.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

True, and also my likely course of action if this discussion does not produce a working strategy someone else is already using. I'm trying to see what other people are already doing in this area, so they can tell us all of the pitfalls and traps to be avoided...


Author: Iain Sharp (i.sharp@pcisystems.co.uk)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

in the das of CHUI, they had in "the lab" a tool called "UniTest" to quickly generate test forms based on a frame-in-frame script.

Their DomainSpecificLanguage (DSL) is capable to handle hierarchies and had a very simple syntax
"levelno"  :  entity  .  list-of-fields

so an example may look like

0:ONEENTITY.MODEL1:PK,TEST2
1:MANYENTITY.USYS:*
0:Anothertopone.xxx;JUSTAFIELD

Perhaps a base for a "croud-ware" type of defining a tool ???

 

Uli

 


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Iain,

The problem is is what do you mean by "Is the DTD up to date to the component?".

If you want to check that DTD contains all defined entities and field on a component, then you have to write a program that interprets the DTD in UDEFINITION.UCDTYPE.DICT. Make a list of all fields (mapping via UDEFMAP.UCDTYPE.DICT) and check them against the collection of UXFIELD.DICT belonging to the component and vice versa.

You still have to repair the DTD by hand though. Although a colleague of mine wrote a program to repair the DTD as far as I remember. A change in the data dictionary creates always changes in the depending DTDs! It is one of the things on your to do list and a pain in the ass.

Fields in the xml that can not be loaded bij XMLLOAD, are listed in the log.

For the other way in a XMLSAVE you could with defines create a test version of your component. In this test version you let every format trigger register its call when an XMLsave is performed. In the PostSave trigger you can check this list with the ALLFIELDS list of the entity. This is something I've never done though.

Kind regards Frank Sjoukes 


Author: Frank Sjoukes (frank.sjoukes@sogeti.com)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Well, given that the default for services is now 'All fields' and that, according to the documentation, a down entity MUST have all the fields filled in by the xmlload or the data is cleared from the database, it's more whether the down entities are entirely populated from the model to the DTD.

I am fairly sure I can write something from the dict model to disassemble the DTD and determine if all the fields from the model are included. I was just hoping there was something I missed.


Author: Iain Sharp (i.sharp@pcisystems.co.uk)
Jan Cees Boogaard

Maintaining a DTD/XML driven client server environment

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When we're setting up a DTD/XML client server application, the situation is relatively easy. We can use load fields to populate the DTD.

But, let's say we're six months down the line, we've multiple DTDs set up for multiple different scenarios (particularly on tables viewed as 'intersection entities') and we want to add a field or two.

How do you keep your DTDs in line? Missing this field can have massive complications if the entity is a down entity on the service (it blanks out the pre-existing data on update to that occurrence...), and there's no way of specifying 'all the fields in this entity'.

Is there a tool for identifying where DTDs are obsolete?

Hi,

not sure if this helps. I like to use the define trigger for definitions of DTD and Mapping, so changing model or DTD you can easy change the define.

But still, there are some problems for evaluations:

a) Default-Mapping versus Proc-Mapping,

b) Uniface-DTD versus normalized DTD (without Dots),

c) complete field-list versus single use

d) dummy-fields and model-definition

So I believe it is quite complex to write an own analyze (possible, but complex)

So the best is, to have a good standard and than check if this standard is used.

Best regards

Thomas

P.S.

Sample-Code for general model-definition (but it will be become complexe if you use relationsship in your DTD):

#define myDtd = <$tablename>.<$modelname>

#define myDtdFields = Field1, Field2, Fieldx

#define myDtdMapping = <$tablename>.<$modelname>= <$entnname>.<$modelname>

#for myDtdField = (<myDtdFields>)

#define myDtdMapping= <myDtdMappin>; <myDtdField>.<$tablename>.<$modelname>= <myDtdField>.<$entname>.<$modelname>

#endfor


Author: Thomas.Young (thomas.young@young-consulting.de)

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement