Create and manage categories in lzVistA. Removing a category will not remove content.
Loading...
You can't create documents here, but watch for documents with information you can use.
The lzVistA project aims to explore methods and opportunities to build web-based clients for VistA-based systems using the OpenLaszlo Rich Internet Application (RIA) framework.
Quick Links
The beauty of the thing is it's simplicity. I have released a REST server which will form the basis for future development of this project. The server infrastructure is derived from MDB (MGateway's SimpleDB clone) and incorporates many of the Fileman interface tools of M2Web as modified by this project. Support currently exists for Get, Help, Put, RPC, Query, and Validate actions. The RPC action is a new and simplified version of my earlier attempt to implement brokerless RPC execution. RPCs can now be invoked by an authenticated user by providing an option number, RPC number, and any required arguments. Given these pre-conditions, the server will perform the following:
1. Verify that the user has access rights to the option.
2. Verify that the RPC is valid for the given option
3. Resolve the RPC number into routine and file names.
4. Load and examine the RPC source to determine the call signature.
5. Given the proper arguments the RPC is then executed.
6. Analyze the return variable by applying a few simple heuristics and render it into XML.
This feature needs further evaluation and is perhaps somewhat naive, but I think it has potential. In addition to the security provided by AWS style digitally signed requests, token based sessions are now provided for authenticated VistA users. I have also included a simple RIA tool that has been useful in the development and debugging of the server, and also demonstrates how a client might be constructed to interact with it.
The primary goal of this effort has been to provide a simple, effective, and transparent server scaffolding that can be easily customized and extended.
Finally, I have decided not to include the original client framework in this branch. To borrow a term from golf "I'm going to take a Mulligan" on that one. It seemed like the right approach at the time but I was never really satisfied with the results and just couldn't get the implementation right. But I learn and, as with many aspects of this project, have some new ideas. The latest updates are available under the "devel" branch of this project at launchpad. More to come soon...
Thanks for the opportunity to contribute and Happy New Year! --Wally
Building on the wonderful work of Mike Clayton and the GTM Integration project I now have EWD running on a modified "10 minute install" of OpenVistA. The install was accomplished manually with modifications to the mgw-astronaut-0.1 deb files and adding 32kb data block support for the relevant EWD globals to the ovinstanceadd script. Moving forward this will allow for the porting of M2Web's high level tools to EWD - a goal for some time. I have, since the technical conference earlier this year in Pittsburgh, believed that the secure, robust, and battle-tested EWD infrastructure combined with M2Web's tools represents the future of "real-world" M web server deployments. With any luck and a bit of time lzVista will soon enjoy the best of both worlds...
Only yesterday did I realize that have not posted since the end of March. Time this spring has been both fleeting and scarce. It was my hope to have a significant demo completed for the WV Community meeting in Bethesda. Unfortunately "real" life intervened. I have, however, continued to work on lzVistA - albeit at a glacial pace. I have exterminated numerous bugs and refactored some ugly and ill-advised code. The framework now performs pretty much as one would expect. Based on what I've seen so far, I have no reason to believe that this approach would not scale to handle something such as patient registration once network error handling and security are introduced. Which leaves me with the "chicken or the egg" dilemna. I had hoped by now to have ported the server side infrastructure to EWD via the EWD custom tag facility (After spending a day observing Rob Tweed developing with EWD, I must confess that I am a big EWD fan). Yet, I could just as easily produce a more-or-less full featured app using M2Web. Which is the greater good? Which would be the better use of my time for the WV community (and I would be remiss without entering OVID into the fray)? The OpenLaszlo piece of the puzzle is, for the most part, transparent to the backend technology. But I suspect that those who deploy and maintain real-world instances are not. Speak now...
As an aside, a recent Jaunty update has left Bazaar broken on my development machine. I have not yet had time to sort out the backtrace. I will therefore post code updates here until the issue is resolved. Finally, here is the obligatory screenshot of a recent test.
Cheers --Wally
It wasn't any one thing. The whirlwind visit to the WorldVistA technical conference in Pittsburgh, the continuing drama surrounding the "day job", along with a number of other issues left me exhausted. Thus, I took a few weeks off from this project to rest and reflect.
Batteries recharged, I'm now pushing forward again. After considerable thrashing I think that the lzVistA form framework is starting to take shape. The current set of components include vform, which is a container for the data fields and provides data submit, entry validation, and field level error and help support. The data fields currently supported include (static) text boxes, edit text boxes, radio buttons, check boxes, and combo boxes. The edit text fields support tooltips. I have not included tooltip funtionality in the other fields as they are constrained values and I wonder whether they are really needed. Are they?
Creating data fields in a vform container is a simple process. For static and edit text fields one simply needs to specify the datapath and name attributes using the fileman internal name for the field. Adding combo boxes and radio buttons are only nominally more difficult, requiring a that dataset be specified and setting the txtpath and valpath attributes. Finally the canvas file number, iens, flags, and fields attributes need to be set and the data request initiated. For testing purposes I'm just using a "test" button to configure and trigger the request.
So, inserting these lines into the test canvas boilerplate code:
<dataset name="dsReligeon" request="true" src="http://vista/query.xml?index=.001&dbfile=13"/>
<dataset name="dsSpInStatus" request="true" src="http://vista/options.xml?file=2&fields=57.4"/>
<dataset name="dsVeteranYN" request="true" src="http://vista/options.xml?file=2&fields=1901"/>
canvas.setAttribute('file', 2);
canvas.setAttribute('iens', 1);
canvas.setAttribute('flags', de);
canvas.setAttribute('fields', .01;.02;.03;.09;.08;57.4;1901);
<vform id="f1" visible="false" layout="axis:y;spacing:5">
<vtext name="Name" datapath="dsGet:/result/Name" lfontstyle="bold"/>
<vedittext name="DtOfBrth" datapath="dsGet:/result/DtOfBrth"/>
<vedittext name="SclScrNm" datapath="dsGet:/result/SclScrNm"/>
<vcombo name="RlgsPrfr" dpath="dsReligeon:/result/item" txtpath="Name/text()" valpath="RlgnNo/text()"/>
<vcombo name="SpnCrdIn" dpath="dsSpInStatus:/result/option" txtpath="text()" valpath="@value"/>
<vradio name="VtYNQstn" dpath="dsVeteranYN:/result" txtpath="text()" valpath="@value"/>
<text name="txtError" visible="false" fgcolor="#FF0000" multiline="true" width="${parent.width}"
datapath="dsStrings:/app/error/submit/text()"/>
<button text="Submit" onclick="parent.startRequest()"/>
</vform>
will get you this:
An invalid data entry will produce this,
this:
and this:
In real life you would, of course, want to configure component layout, etc., but i think that you get the idea.
Onward...
Welcome to the lzVistA project. As the project description implies, lzVistA is an exploratory effort to build web interfaces to VistA utilizing the OpenLaszlo RIA platform and Jim Self's wonderful M2Web server. While M2Web is the middleware of choice for this experiment the OpenLaszlo client should also work more-or-less transparently with M Gateway System's EWD platform.
I've received a lot of feedback in the weeks following the release of the “CPRS-like” demo. Among the chief concerns expressed was the ability of the OpenLaszlo platform and it's LZX language to scale to the complexity inherent in VistA, and the subsequent maintainability of the code base. These are legitimate and important questions - questions which this project aims to answer. To address the former I plan to implement targeted functionality and expand outwards until I hit the proverbial wall, if such a wall exists. As for the latter, I think that the success of this approach will depend largely upon the ability to push functionality down into a framework of well documented components.
The initial code push to Launchpad reflects the very beginning of this effort to develop a set of VistA-aware components. A text entry widget which supports tooltips, validation, and a help dialog has been included, as have a listbox and form widget. These components are neither complete, documented, or robust. Yet, they should offer an insight into what I am trying to do. I have chosen not to include the source for the original “CPRS-like” demo. It is available as a tarball elsewhere for the curious. I intend instead to incorporate a refactored and componentized version of that code. I'll post additional details and screenshots in a subsequent entry.
Finally, I would like to express my gratitude to Ben Mehling, Jon Tai, and Medsphere for graciously providing the collaborative hosting infrastructure and technical assistance for this effort. With any luck, we will in time produce something worthy of their support.
Regards --Wally