Richard Schilling wrote:
>I did see this book this weekend actually and almost bought it.
>
>I run a Java shop, so POJO's are near and dear to my heart, and I do
>think they're somewhat underrated. We can do so much by not using EJB,
>and in fact I use Java Beans in a "POJO environment" rather than in a
>managed environment. Works great!
I haven't really been keeping up with Java lately. I would be interested to
hear more
about what works well for you and not so well with POJO.
We spent quite a bit of time working with Java after it was first bundled with
Netscape
with the idea to utilize Java applets in our web interface to VMACS. I stopped
paying much
attention some time after Swing was released when we concluded that it (Java in
a web
browser) was all too heavyweight for what we needed and that Mozilla by itself
appeared to
be sufficient - and an easier transition for our programmers.
>Jim, I'm curious to know more about your ideas for approaching VistA
>data through Mozilla.
I have been thinking about this for quite a while so this could be a long
discussion. I
have a lot of ideas. ;)
Here is a rough outline to start:
- Standard reports
- direct database access
- symbolic access to data elements - names not numbers for field elements
- data objects
- iteration
- format and layout specification
- HTML, XML, JSON
- Overall user interface
- user privileges
- Menus
- hypertext
- AJAX
- XUL
>Several things have been tried - PHP integration,
>etc... (and from what I hear from Terry Weichman the PHP interface is
>difficult).
The only PHP interface I am aware of so far is the one available from the GT.M
project on
sourceforge. That gives low level access to MUMPS globals in PHP with equivalent
operations to MUMPS intrinsic functions like $ORDER and $DATA. That is not
sufficient to
access Metadata for Fileman without development in PHP of a great deal of
additional
infrastructure.
We (VMTH UCD) have multiple Perl interfaces for GT.M in development. These
could provide a
starting point for interfaces to other languages such as Python, PHP, Java,
etc. First is
a Perl module that provides objects for access to MUMPS globals with methods
that reflect
the standard MUMPS functions and operations such as $ORDER, $DATA, SET, LOCK,
KILL etc.
Layered on that is a module that provides higher level data objects
corrresponding to
records in Fileman files with named attributes that represent the data fields.
This is
based on metadata in ^view derived from ^DD in common with the query tools
included with
M2Web.
>Thoughts?
First off, for a MUMPS programmer it is just plain easy to provide views of
VistA data, or
any MUMPS data for that matter, to a web browser from GT.M/Linux or from most
other
current MUMPS implementations. We (VMTH UCD) started with a direct
implementation of the
HTTP protocol in Datatree MUMPS over 12 years ago and almost immediately had
every
standard report in VMACS available on the web. The same could be done for VistA
with
GT.M/Linux and M2Web.
The essential components of this first phase of web enabling were
1) a scheme for mapping each report to a URL and
2) a device type definition that could be invoked to cause the reports to
produce HTML
tags instead of the ESCAPE sequences that would be sent to a printer.
After that you can go back and simplify and enhance individual reporting
applications and
general report writers to take advantage of the more relaxed formatting
requirements and
added features of HTML, such as the possibility of making hypertext links out of
identifiers for lab reports, patients, clinicians, appointments, etc.
I imagine that direct database access is closer to your interests. I have some
examples of
queries on a VistA database at http://vista.vmth.ucdavis.edu and you can
construct many
more by interacting with the web pages there.
This is all I can write in a single email. More later if there is interest.
>Richard Schilling
>Cognition Group, Inc.
>Seattle, WA
>
>
>Jim Self wrote:
>> Gregory wrote:
>>
>>>The idea is that using standard Java, it is possible to build
>>>solutions with considerably less expense and overhead than EJB
>>>solutions, and the approach may fit well with the needs of VistA
>>>adopters, whether for integration in a single facility, or as a
>>>technological approach to building multi-facility/campus solutiions.
>>
>>
>> If one's objective is to access VistA data on the web, there is very little
>> need for Java
>> at all. Mozilla Firefox provides a rich multi-platform client supporting
>> pretty much all
>> the standard protocols and data formats you need and GT.M/Linux/Apache gives
>> a scalable
>> server to match - and all Open Source (Free).
---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
