A Question Abot DIALOGs

[xProgrammer]

Hi James

I am 100% with you on that.

My only point would be that automatic scatter gather means that the UI layer has to be aware of the fieldnames used by the data layer.

Clearly the Read(), Write() and Blank() methods of my classes can be automatically generated from the datafile so hand coding isn't really required. Thereafter you can change fieldnames in just Read() and Write() without any upstream effects. This is just an interim. Ideally your design tool generates both the data table and the above methods for you. And can do more because it knows, for example, which field is a primary key, which are secondary keys, which character fields are codes, which are dates in string format etc. This isn't very hard to do - I have done it in other environments. But I am waiting until I have coded more by hand to better understand what I need to generate and what information I need to do that. I will also be reviewing all your comments as part of that process.

And when I move (regretfully) to SQL (I would really prefer an OO database) I will have to write a Recordset class.

And I will no doubt be doing an XML class - or using xHarbour's inbuilt ones (have just done a bit with them so not too clear there).

And a WPDocument class - which as I will be using OpenOffice and its xml based format will probably be a subclass of my XML class.

And a MedicalReport class - which will be a subclass of a WPDocument.

Regards
Doug

[James Bott]

Doug,

>My only point would be that automatic scatter gather means that the UI layer has to be aware of the fieldnames used by the data layer.

They are.

>Clearly the Read(), Write() and Blank() methods of my classes can be automatically generated from the datafile so hand coding isn't really required...

I see you plan to use a code generator.

And a WPDocument class - which as I will be using OpenOffice and its xml based format will probably be a subclass of my XML class.

>And a MedicalReport class - which will be a subclass of a WPDocument.

I suggest thinking about making reports in XML in the sense that it stores the data for retrieval and uses a separate format file to generate the onscreen or printed report. This is what I am doing with the Operative Report I am currently working on. There are already semi-standards for many medical reports.

James

[xProgrammer]

Hi James

>> My only point would be that automatic scatter gather means that the UI layer has to be aware of the fieldnames used by the data layer.

> They are.

But it would be preferable if they didn't need to be.

> I suggest thinking about making reports in XML in the sense that it stores the data for retrieval and uses a separate format file to generate the onscreen or printed report. This is what I am doing with the Operative Report I am currently working on. There are already semi-standards for many medical reports.

I would love to. My problem is that a lot of the report is not generatable from my software or any other automated system, but rather is dictated by the physician and typed by the secretary. Final editing may be done by either, depending upon the physician's choice. I don't know if I can move them away from this dependance on a word processor - although I would love to. Generating an xml file which is then edited using a word processor (in this case OpenOffice) is a half way solution.

I would be most interested to hear how you might handle such a situation. Also how best to follow up on any proposed xml coding "standards" for such documents.

I do greatly appreciate the comments you are making, and the time and effort you are putting into them. I do have my own perspective on things and have come to this point via different experiences and may come across as a "difficult bastard" (to use a bit of Australian vernacular) at times. But I've always believed in robust discussion of software architecture. Sometimes people in on a design discussion I am having with a good friend of mine (we have both worked for each other at times) think we must be bitter enemies, but in fact we are good friends and at the end of the day have explored the possibilities and really understand why we have chosen the architecture we have and what to expect from it.

Regards
Doug

[xProgrammer]

Hi James

Would your recommendation be to follow the HL7 XML initiatives?

Regards
Doug

[James Bott]

Doug,

>>> My only point would be that automatic scatter gather means that the UI layer has to be aware of the fieldnames used by the data layer.

>> They are.

>But it would be preferable if they didn't need to be.

Why? I take the opposite position. If they are aware of the fields, then there is MUCH less coding required-in fact for the gather/scatter there is no coding required. Even if you don't wish to use this feature, why would it be a negative?

>> I suggest thinking about making reports in XML in the sense that it stores the data for retrieval and uses a separate format file to generate the onscreen or printed report. This is what I am doing with the Operative Report I am currently working on. There are already semi-standards for many medical reports.

>I would love to. My problem is that a lot of the report is not generatable from my software or any other automated system, but rather is dictated by the physician and typed by the secretary. Final editing may be done by either, depending upon the physician's choice. I don't know if I can move them away from this dependance on a word processor - although I would love to. Generating an xml file which is then edited using a word processor (in this case OpenOffice) is a half way solution.

They/you can input the data however you wish, but you output the report as an XML file (which can contain freeform text).

As a side note, I do remember reading an article about an semi-automated note system that was tested. Instead of freeform text being entered by the provider, they were presented with a list of items (sentences) that they could select from. They could select as many as desired and then all were included in the report. The study found that the resulting reports were more detailed than the dictated ones for two reasons. One it was faster to select items, so more items were often selected, and second, the providers were less likely to forget things since they had a list to remind them. Unfortunately, I don't have this reference in my notes.

>I would be most interested to hear how you might handle such a situation. Also how best to follow up on any proposed xml coding "standards" for such documents.

Unfortunately, there is no easy answer. I have spent hundreds of hours studying this and I still feel like I know very little.

>I do greatly appreciate the comments you are making, and the time and effort you are putting into them. I do have my own perspective on things and have come to this point via different experiences and may come across as a "difficult bastard" (to use a bit of Australian vernacular) at times. But I've always believed in robust discussion of software architecture. Sometimes people in on a design discussion I am having with a good friend of mine (we have both worked for each other at times) think we must be bitter enemies, but in fact we are good friends and at the end of the day have explored the possibilities and really understand why we have chosen the architecture we have and what to expect from it.

So far I am getting the impression that you believe in OOP, but not in inheritance, encapsulation, or polymorphism. So, I am still left with my original impression that you don't really understand OOP.

Regards,
James

[James Bott]

Doug,

>Would your recommendation be to follow the HL7 XML initiatives?

Probably. When I started my project more than a year ago, the only information about Operative Reports in XML that I could find was here: www.openhealth.org. They are an open source health record organization. HL7 would probably be a better standard to follow, because I am sure all the larger health organizations are going to use that one.

I don't know which report, or reports, you are working on, but here is a link to the samples that Open Health has:

www.openhealth.org/ASTM

For the HL7 specification for a clinical document go here:

http://healthinfo.med.dal.ca/hl7intro/C ... A_Overview

This will probably put you to sleep, so start reading it just before bedtime.

Regards,
James

[James Bott]

Doug,

I found the link to the list-based operative report.

http://www.annalssurgicaloncology.org/c ... /11/10/941

I'm not suggesting that you try this, but it is an interesting read and good information for future consideration.

James

[xProgrammer]

Hi James

Thanks for the links - very useful

>Why? I take the opposite position. If they are aware of the fields, then there is MUCH less coding required-in fact for the gather/scatter there is no coding required. Even if you don't wish to use this feature, why would it be a negative?

Because when you want your software to link with someone else's data object you have a real issue. For a standalone application that shall forever remain standalone and where fieldnames are essentially immutable and pretty much all data is in the one persistence model it doesn't really matter but beyond that it is a major time waster and source of errors.

You may care to look at:

http://en.wikipedia.org/wiki/Three-tier_(computing)

http://www.sei.cmu.edu/str/descriptions ... _body.html

http://msdn2.microsoft.com/en-us/librar ... S.85).aspx

http://www.linuxjournal.com/article/3508

http://www.oracle.com/technology/produc ... dev010.htm

Note: Years ago I developed a web application design / development / deployment system using three tier architecture stateless (naturally across the www) with transaction control etc. I suspect if you came with the same set of experiences your attitude to some of the issues we have been discussing might be rather different.

That's not a claim of I'm right you're wrong, but rather its a matter of having the right architecture for the future you perceive for your software and the environment(s) in which it must run and the external system(s) it must connect to. And maybe a question of a little more work now to save a lot more work later on.

Regards
Doug

[James Bott]

Doug,

>>Why? I take the opposite position. If they are aware of the fields, then there is MUCH less coding required-in fact for the gather/scatter there is no coding required. Even if you don't wish to use this feature, why would it be a negative?

>Because when you want your software to link with someone else's data object you have a real issue.

What is the issue?

>For a standalone application that shall forever remain standalone and where fieldnames are essentially immutable and pretty much all data is in the one persistence model it doesn't really matter but beyond that it is a major time waster and source of errors.

I don't understand why you think not having to code anything is a major time waster and source of errors?

With this system, if you later needed to map an object to different fieldnames then you could still do it. You just add different load and save methods. So I don't see any downside.

The upside is _/gather coding.

No work up front, some work possible later.

I do understand three-tier systems. I did describe how you can switch to using different database sources such as ADS, XML, SQL, array, etc. as long as those tables have the same structure and fieldnames. There is still no extra programming required.

I'm not sure how any application can be completely independent of the data source. I mean you can't easily adapt to another database from another system. I you have a patient table with certain fieldnames, types and lengths, you can't easily switch to using a patient table from a different system with different fieldnames, types, and lengths. This would not be trivial task if it could even be done.

Maybe I still do not understand what you are saying.

Regards,
James

[xProgrammer]

> I'm not sure how any application can be completely independent of the data source. I mean you can't easily adapt to another database from another system. I you have a patient table with certain fieldnames, types and lengths, you can't easily switch to using a patient table from a different system with different fieldnames, types, and lengths. This would not be trivial task if it could even be done.

Yo can - that's the essential message. It can be isolated to the data layer. Translation there can be made easy but you have to be careful about using inbuilt and potentially non-portable data types. That's a nice part of the xml revolution - everything as (readable) text. xBase is almost but not quite the same. Data is actually stored in readable text although we do have a small number of data types (C, D, L, N, M). I store my dates as CCYYMMDD in a character field and my own date time (CCYYMMDDhhmmsshh) - I know xHarbour has introduced its own. I do use logical memory variables but store as single character codes. Amazing how often something that is first thought to be yes / no ends up with a third possibility. It makes sense to add your own data types (stored as text) but that pretty much blows scatter/gather out of the water. But if there is an existing data object that returns data as xml then its easy to use your existing UI and BL layers with it even though data names are different.

Regards
Doug
(xProgrammer)

[Otto]

Hello Doug,

I too use text fields in my dbf files to save the values of some checkboxes:

dbf-field is then something like: 0110001

James showed me how to use OOP and a database object to overcome this.

I will share it with you.


I hope this is as usefull for you as it is for me.
And thanks again to James.
Regards,
Otto

Code: Select all

Add seven new instance variables to your class. 
I am going to make up just two for this explaination. 
You will also need to override the load(), save(), and blank() methods of the parent TData class.
 
class TCustomer
   DATA active 
   DATA approved
   method load()
   method save()
   method blank()
   ...
endclass
 
You may want to initialize them in the new method:
 
method new() class TCustomer
   ::active:=.t.
   ::approved:=.f.
   ...
return self
 
And also in your blank() method.
 
method blank() class TCustomer
   super:blank()
   ::active:=.t.
   ::approved:=.f.
return self

Then in your load method
 
method load() class TCustomer
   super():load()
    if substr(::ehrungjahr,1,1)="1"
        ::active:=.t.
    else
        ::active:=.f.
    endif
    if substr(::ehrungjahr,2,1)="1"
        ::approved:=.t.
    else
        ::approved:=.f.
    endif
endif
return self
 
And in the edit () method you treat them just the same as fieldnames:
 
    REDEFINE CHECKBOX    oEhre1   VAR  ::active   ID 401 OF oFld:aDialogs [ 5 ]
    REDEFINE CHECKBOX    oEhre2   VAR  ::approved   ID 402 OF oFld:aDialogs [ 5 ]
 
 Then in your save() method you convert them back to the legacy database:
method save() class TCustomer()
 
       ::ehrungjahr = stuff( ::ehrungjahr,1,1, if( ::active, "1", "0" ) )
       ::ehrungjahr = stuff( ::ehrungjahr,2,1, if( ::approved, "1", "0" ) )
       ::super():save()
return self 

Now, converting from 1/0 to logical and back is all transparent. 
You can use the new logical instance variables just as you would regular fields.
 
oCustomer:= TCustomer():new()
 
msgInfo( oCustomer:active )
 
oCustomer:active:=.f.
oCustomer:save()

[James Bott]

Doug,

>>> I'm not sure how any application can be completely independent of the data source.

What I meant by this is not the file type source but a different application with its own data tables. Another application could have a totally different set of fields and even different tables. They may not be storing all the same data that your system is. In this situation it is next to impossible to adapt to another system without major changes to either their data structure or your application.

>It makes sense to add your own data types (stored as text) but that pretty much blows scatter/gather out of the water.

As Otto showed, it does not.

James

[xProgrammer]

Hi James

>>> I'm not sure how any application can be completely independent of the data source.

>What I meant by this is not the file type source but a different application with its own data tables. Another application could have a totally different set of fields and even different tables. They may not be storing all the same data that your system is. In this situation it is next to impossible to adapt to another system without major changes to either their data structure or your application.

But it can be! Sure the other application has to have sufficient information and a means of being invoked and passing its output but that's pretty much it. I've done it - multiple times, even implemented dynamic table driven translation. Built gateways between systems written in different languages using different database back ends and running on different operating systems. In the health area. In the accounts / payroll area. For my own development environment. In some instances using a predefined format (HL7 with some additions), in others developing an independant format because its easier to only have to write a single two way translation as more disparate programs need the gateway service. (A bit like how Windows programs and printers work).

> As Otto showed, it does not.

What Otto showed is how you program around the issue - that is you automatically scatter/gather what you can and manually do the rest. It splits the code for a data object into multiple places which I don't really like. I am not sure why the values are stored as a single string when multiple fields would not increase table size. But if doing so I would certainly consider writing a class to handle such strings. What would be really nice is to be able to store our own data type designations then automatic scatter gather could pretty much do everything I need. One possibility I have been tempted to try is a structure table that contains the structure of the tables but contains more information - like your own data types. Then the object responsible for reading the data would know that this field is a primary key, or a date stored as a string, or whatever and handle accordingly. Maybe one can play around with the database driver and stuff this information into the table header itself? I haven't looked into that. I've stayed well away from replaceable database drivers so far.

Maybe you have some thoughts in this area. Also ties into a possible design tool.

For example the "extended field type" might tell the database object that this field is a date stored as a string so the read and write methods can automatically do the necessary translations. Better still you have "extended field type sub types" such as "default to today's date" to enable blank() function to be more user friendly than just blanking the date, or having to override it in a derived class. And "must be today or before" for checking a birthdate" etc. I certainly put such capability in my development environment. I have let the need to get familiar with FiveLinux and get working code out get in the way of exploring how best to do that.

Just maybe we can end up with the best of both worlds.

Regards
Doug

[James Bott]

Doug,

>>What I meant by this is not the file type source but a different application with its own data tables. Another application could have a totally different set of fields and even different tables.

>But it can be! Sure the other application has to have sufficient information and a means of being invoked..

But, what if you need to store the date and time the record was updated and the foreign table doesn't have a field for that? What if your customer name field is 35 characters long and it the foreign table it is only 30? I don't see how you can overcome these issues.

>> As Otto showed, it does not.

>What Otto showed is how you program around the issue - that is you automatically scatter/gather what you can and manually do the rest. It splits the code for a data object into multiple places which I don't really like.

But that is the advatange of inheritance. If you need to slightly change the behavior of a class you can do so with very little code. Also, if a bug is found and fixed or a feature is added to the parent class then all the subclasses benefit.

If you don't use inheritance, then you need to have 10 to 100 times as much code--much of it redundant.

>I am not sure why the values are stored as a single string when multiple fields would not increase table size.

This was a legacy system that we are using so we had to deal with the legacy structure.

>What would be really nice is to be able to store our own data type designations then automatic scatter gather could pretty much do everything I need. One possibility I have been tempted to try is a structure table that contains the structure of the tables but contains more information - like your own data types.

It seems like you are going to spend a tremendous amount of work up front for the possibility that it will be useful later. Perhaps you are working in an environment where this is a high probability, but I am not.

James

[Otto]

Doug,

>I am not sure why the values are stored as a single string when multiple fields would not increase table size.

Here you see what I save into these textfields:
I can access every cell with substr(cText,x,1) for example.
For input I use checkboxes.