This semester was surely an exciting roller coaster ride full of many bent turns, unexpected loops, and some worthwhile air time. The goal of this project was to gain minimal insight into electronic health record systems (EHR), and to explore the possibilities of developing an open source component to enable greater extensibility and interoperability for development platforms. It turned out that a big competitor in the medical health record industry, Medsphere had developed just that tool for creating a Java-based linker solution, called OVID (OpenVistA Interface Domain). The OVID project is still very young, yet they've pushed through great lengths recently to have it on a fully open repository. Medsphere also released a front-end patient record dashboard along with OVID, which was built using OpenLaszlo, called lzVistA. After realizing the potential of building such a dynamic front-end GUI using such expressive component based and XML driven-development of RIA's, I started looking for alternative RIA's that could help shape my own patient dashboard. This began the exploration of finding the right RIA that I'm most comfortable with. After giving OpenLaszlo a try, I thought to myself, "Yes, I'm impressed." Then I realized the hassle of not having a dedicated IDE for editing and building OpenLaszlo applications. This led me back to the road, where I would eventually reunite with my all time favorite Flash platform. It's been a long time since the Macromedia days, and Adobe's done a great job in marketing the trend of Flash now being used on practically every browser. Adobe is also well caught up with the open source community, since they recently released a full open source version of their XML/MXML development language kit, called Flex. Flex serves as an innovative way of producing web-based applications in a much more rich and multi-platform environment. In my recent discoveries, I mentioned that Flex provides many different ways to capture and retrieve data via data services, such as web services, HTTP and remote objects (including server-based Java objects). Flex is also accompanied by an IDE built on Eclipse, called Flex Builder. This makes for an easy migration, since I'm able to switch between developing environments with ease.
It's interesting as to how large the scope of the project has become since the introduction of OVID. I'm now hoping to build a web-based EHR client using Flex and Java's back-end server connection to OpenVistA via OVID. I'm glad to say that this has been a progressive project, including the immense time spent on getting used to Flex's component-based development, and refreshing my skills in the new ActionScript v3.0. The experience was well worth it, but I've yet to close this road permanently. I'm simply putting this project on hold in promises that I'll be able to continue down this path with more added time and consistency. I'm still actively supportive in the project and I've taken the necessary steps in order to keep up-to-date. Since OVID isn't a perfected system yet, I hope to give my helping hands on their development team. This would mean that MUMPS is back to haunt me again, but at least I'll have Java to accompany me along the way. As far as this semester goes, I'm probably more satisfied with what I've learned rather than what I've produced. Along with understanding how to self-manage myself, I've also learned to become more engaging as a programmer. This has opened me up to the possibilities of how many things still need to be invented, or needs improvement in this world. I'm thrilled to know that I'm stuck somewhere in between having thought of something with the right resources to do it, and realizing the proximity of a real-life product.
Friday, May 15, 2009
Sunday, May 10, 2009
Devcathlon Evaluation
Premise:
Devcathlon has been a three month project intended to simulate a software engineering environment in hopes to improve development team practices, and to promote overall project health. In this entry, I'll evaluate the application through my personal perspective as a developer, along with the evaluations of outside testers. I'll also mention about my experiences in building this project, and the future of this application.
A programmer's perspective:
The journey through markup...
Most of my development time was spent on building the profile section of Devcathlon. It wasn't difficult, but there's still room for lots of improvement. I kept this first version of Devcathlon's profile page simple, in order to focus on the teams, matches and scoreboard pages. Devcathlon underwent through many physical and functional changes since its first conceptual designs. We started out with basic HTML mock-ups which looked and felt very web 2.0-ish; considering that it had some Javascript, some signs of pagination and an array of CSS layouts. By separating ourselves into three separate teams of three, we were able to generate some very inspirational designs and structures that would eventually be inherited into the "final" product. Although some design elements were put away as future enhancements, due to being labeled as aesthetic gains rather than functional gains, we did provide, in this version, an intuitive, yet simple user experience. The gains of taking this conservative approach would rather benefit ourselves in the long-run, since we built a strong foundation of our application and left plenty of room for advance UI's to take place later. Of course, we've only scratch the surface of Wicket's abilities to render some "pretty," and dynamic markup, but I'll see to it in our future implementation that we have an eye-candy application. At this point, I'm very pleased with what we have, as far as the look and feel goes. The application has a conformed look and layout; we made good use of our CSS to standardize our information in reusable "panels," and we also preserved colors and fonts similar to Hackystat's UI. I'm willing to put energy during this summer to make improvements in this area by incorporating more AJAX-y alternatives to necessary parts of the web application.
Functionality in design...
Below is a list of my likes and dislikes, and some possible way of improving each portion of the web application. I'll also mention the difficulties and challenges in making these sections possible.
Front page review:
The front page contains a basic login and password form, along with a preview version of our scoreboard. Although, this idea of putting the scoreboard on the front page came late in the game, we found it useful to help advertise the current status of our application with regards to providing evidence of user traffic and ratings. The front-page version of the scoreboard is not all that different from the actual scoreboard, except that some links are not featured unless you have logged in with an account. The gray panels and use of reusable components makes the composition of this page very useful in context, by providing information on match events, teams events and individual player's scoring. A future improvement would be to provide a live scoring data provider that would emulate statistics on the fly through 5 minute increments or whenever it spots a new change in the system. This would be beneficial by reducing the number of whole-page refreshes and enhancing the user experience by providing a persistent way of retrieving data.
Profile page review:
The profile page went through minimal amounts of change due to its limited usages other than finding out more about the player participating in the game. Although, the profile page makes for very little use, I've come to find that there are many ways of approaching this section. I looked around on mostly social networking sites, including TechHui, Facebook and Twitter to gain some inspiration and possible commonalities. I narrowed down some details of a user profile to only include, the user's first and last name, location, contact number, email address and biographical information. The only required field is the email address, since it serves the purpose of your login name and our source of sending out game match invitations and updates. The main profile page also replicates information regarding a listing of user's team affiliates and current team events. The profile page successfully makes use of the qualified standard gray panels, and a simple-to-read 3-column layout. The profile section also includes "manage" and "browse" sub-pages. The Profile Manage section gives the player the ability to make changes to their profile information. The only ability that it lacks at this point is a way to add additional social networking aliases, modifiy email address, and the choice of choosing a different profile avatar. The addition of other social networking aliases is as simple as creating a textfield. At this point, there is no "right" way of changing a user's email address since the user's account information is dependent on it as an identifier in the system. Hopefully in future enhancements, we'll incorporate an interface to attribute to this feature of changing a user's email, and getting a email notification of the account being modified. Of course to preserve the integrity of our system, we'll need to require a primary email address to send that account modification. Another neat enhancement would be to enable a user the ability to modify their avatar on the system by providing a local image upload. This would require a persistent storage location on our public servers and a limited file size.
Team page review:The team management section is in itself very functional and simple to use. The team creation process is straightforward, users will not have very much difficultly in getting the hang of things here. I could only point out certain enhancements rather than any noticeable flaws in this section. Although, the co-creator of this section did indicate in the issues listing about a potential "weakness" to the user-to-team invitations handling. This may be a confounding factor that needs to be addressed in the next implementation stages of Devcathlon, but as for now, it sits deep under the covers.
Match page review:The match management section gives a listing of all involving team matches. It gives you the ability to create, update and destroy matches. The only disadvantage is through the ease of finding an existing match. There is no mechanism to browse for matches, but it would help to supply a way to immediately find a match rather than scrolling through a large column listing. Maybe we can incorporate similar pages implemented by the user profile and team management sections. This would require two additional pages, called "Match Browse" and "Match Profile." The match browse page will include a table listing all matches, and on each row a link to its respected match profile page.
Scoreboard page review:The scoreboard page includes a listing of all matches, team line-ups and their respective members, match events, comments, and top developers for that match. This page did a good job of portaying that information in a clear way. My only problem is that it would be difficult to display multiple team match line-ups, where matches can consist of more than one participating team. The Hall of Fame page is included as a scoreboard sub-page that gives an overview listing of wins, losses, points accumulated per match, and most valuable players. I only wished that this page had more visual references rather than just plain-old text and links.
Top 5 lessons learned:
Now, for some people, this is the time to put up their hardhats and salute to a good year of eventful meetings, to staying up late coding, and to enduring all those emails with the subject line starting with "[Devcathlon] ..." I'm not sure about others, but I'll sure be missing that feeling of being needed for a project and looking forward to just doing something the next day. This project brought in a mixed set of individuals with different skills and backgrounds, but with one common goal of making this project the best it could be. I could not have asked more from these group of highly talented people. Their dedication and hard work has paid off, and I hope that everyone takes something from this into their own personal endeavors in life. I know that I'll take this experience and be able to apply what I've learned into any setting. The time we sacrificed; those bloody hours at the keyboard; those late nights sipping on energy drinks, and those times when all you could think about was "Devcathlon" will now become a memory. Even as unfortunate as that may sound to a few, it has made a profound impact on what I see in a large team setting. The beginnings were difficult, but over time we progressed from novices to experts in our own way. This experience has challenged myself and others mentally and somewhat physically. This project has given me ways to express myself more freely than I usually do in any other class related setting. It has taught me to be ethical, respectful, resourceful and passionate about goals. It has also taught me to become a better person by encouraging me to open up to all sorts of people. I'll honestly miss that energy, and all those who made this project what it is today. I hope to find that same spark during my attempt at enhancing this project for this year's Google Summer of Code. I'm sorry that not all original members of the team will be participating, but I am grateful for their respectful input and support. Good luck to everyone, and thanks for all the hard work!
Devcathlon has been a three month project intended to simulate a software engineering environment in hopes to improve development team practices, and to promote overall project health. In this entry, I'll evaluate the application through my personal perspective as a developer, along with the evaluations of outside testers. I'll also mention about my experiences in building this project, and the future of this application.
A programmer's perspective:
The journey through markup...
Most of my development time was spent on building the profile section of Devcathlon. It wasn't difficult, but there's still room for lots of improvement. I kept this first version of Devcathlon's profile page simple, in order to focus on the teams, matches and scoreboard pages. Devcathlon underwent through many physical and functional changes since its first conceptual designs. We started out with basic HTML mock-ups which looked and felt very web 2.0-ish; considering that it had some Javascript, some signs of pagination and an array of CSS layouts. By separating ourselves into three separate teams of three, we were able to generate some very inspirational designs and structures that would eventually be inherited into the "final" product. Although some design elements were put away as future enhancements, due to being labeled as aesthetic gains rather than functional gains, we did provide, in this version, an intuitive, yet simple user experience. The gains of taking this conservative approach would rather benefit ourselves in the long-run, since we built a strong foundation of our application and left plenty of room for advance UI's to take place later. Of course, we've only scratch the surface of Wicket's abilities to render some "pretty," and dynamic markup, but I'll see to it in our future implementation that we have an eye-candy application. At this point, I'm very pleased with what we have, as far as the look and feel goes. The application has a conformed look and layout; we made good use of our CSS to standardize our information in reusable "panels," and we also preserved colors and fonts similar to Hackystat's UI. I'm willing to put energy during this summer to make improvements in this area by incorporating more AJAX-y alternatives to necessary parts of the web application.
Functionality in design...
Below is a list of my likes and dislikes, and some possible way of improving each portion of the web application. I'll also mention the difficulties and challenges in making these sections possible.
Front page review:
The front page contains a basic login and password form, along with a preview version of our scoreboard. Although, this idea of putting the scoreboard on the front page came late in the game, we found it useful to help advertise the current status of our application with regards to providing evidence of user traffic and ratings. The front-page version of the scoreboard is not all that different from the actual scoreboard, except that some links are not featured unless you have logged in with an account. The gray panels and use of reusable components makes the composition of this page very useful in context, by providing information on match events, teams events and individual player's scoring. A future improvement would be to provide a live scoring data provider that would emulate statistics on the fly through 5 minute increments or whenever it spots a new change in the system. This would be beneficial by reducing the number of whole-page refreshes and enhancing the user experience by providing a persistent way of retrieving data.
Profile page review:
The profile page went through minimal amounts of change due to its limited usages other than finding out more about the player participating in the game. Although, the profile page makes for very little use, I've come to find that there are many ways of approaching this section. I looked around on mostly social networking sites, including TechHui, Facebook and Twitter to gain some inspiration and possible commonalities. I narrowed down some details of a user profile to only include, the user's first and last name, location, contact number, email address and biographical information. The only required field is the email address, since it serves the purpose of your login name and our source of sending out game match invitations and updates. The main profile page also replicates information regarding a listing of user's team affiliates and current team events. The profile page successfully makes use of the qualified standard gray panels, and a simple-to-read 3-column layout. The profile section also includes "manage" and "browse" sub-pages. The Profile Manage section gives the player the ability to make changes to their profile information. The only ability that it lacks at this point is a way to add additional social networking aliases, modifiy email address, and the choice of choosing a different profile avatar. The addition of other social networking aliases is as simple as creating a textfield. At this point, there is no "right" way of changing a user's email address since the user's account information is dependent on it as an identifier in the system. Hopefully in future enhancements, we'll incorporate an interface to attribute to this feature of changing a user's email, and getting a email notification of the account being modified. Of course to preserve the integrity of our system, we'll need to require a primary email address to send that account modification. Another neat enhancement would be to enable a user the ability to modify their avatar on the system by providing a local image upload. This would require a persistent storage location on our public servers and a limited file size.
Team page review:The team management section is in itself very functional and simple to use. The team creation process is straightforward, users will not have very much difficultly in getting the hang of things here. I could only point out certain enhancements rather than any noticeable flaws in this section. Although, the co-creator of this section did indicate in the issues listing about a potential "weakness" to the user-to-team invitations handling. This may be a confounding factor that needs to be addressed in the next implementation stages of Devcathlon, but as for now, it sits deep under the covers.
Match page review:The match management section gives a listing of all involving team matches. It gives you the ability to create, update and destroy matches. The only disadvantage is through the ease of finding an existing match. There is no mechanism to browse for matches, but it would help to supply a way to immediately find a match rather than scrolling through a large column listing. Maybe we can incorporate similar pages implemented by the user profile and team management sections. This would require two additional pages, called "Match Browse" and "Match Profile." The match browse page will include a table listing all matches, and on each row a link to its respected match profile page.
Scoreboard page review:The scoreboard page includes a listing of all matches, team line-ups and their respective members, match events, comments, and top developers for that match. This page did a good job of portaying that information in a clear way. My only problem is that it would be difficult to display multiple team match line-ups, where matches can consist of more than one participating team. The Hall of Fame page is included as a scoreboard sub-page that gives an overview listing of wins, losses, points accumulated per match, and most valuable players. I only wished that this page had more visual references rather than just plain-old text and links.
Top 5 lessons learned:
- Time management - Time is the quintessential factor in everyone's life. I found it difficult in many cases, but had to ground myself to accepting the fact that I do have issues in this area. I have learned through this experience to be patient and better plan out ahead of what needs to get done. This holds a large part in my leadership skills too, since managing other people calls for good planning and time management skills.
- Leadership skills - I think that I've become a better person from being given the title of a "leader." In many ways, it has improved my outlook of managing a small team in such a large setting. At first I was somewhat doubtful that I could accomplish it, but I eventual grew out of the fear and simply started to care. I started to care for the project and its respected team members. This helped bring me closer to the individuals in my team as well as other project members.
- Control - I think that controlling that programmer's ego is a must in a large project setting. It's very different from critiquing your own work as oppose to being able to endure criticism from others. I've learned to respect others opinions to find a common solution. Eventually once you've set aside your ego, you'll notice a difference in the mood that you bring to the atmosphere. I learned to control that atmosphere through just being lightly assertive, but straight to the point.
- Collaboration - Collaborating with my team members weren't very difficult, but it had some confounding factors such as its frequency and effectiveness. The effective route is to meet as often as possible. It's very simply stated, but it turned out to work in our situation with a group of eight people. We also incorporated pair programming as a way to keep each individual on their toes.
- Forgive and forget - Sometimes you just gotta forgive and forget. Its difficult already that this project posed a challenge for many of us, but adding to that tension could have led to some adverse effects. I'm glad that this group had that notion of forgiveness. It was quite evident during those milestones that just did not work out as we planned. We would rarely hold personal grudges towards another individual. It was sometimes nice to just talk about it rather than tuning out the whole problem.
Now, for some people, this is the time to put up their hardhats and salute to a good year of eventful meetings, to staying up late coding, and to enduring all those emails with the subject line starting with "[Devcathlon] ..." I'm not sure about others, but I'll sure be missing that feeling of being needed for a project and looking forward to just doing something the next day. This project brought in a mixed set of individuals with different skills and backgrounds, but with one common goal of making this project the best it could be. I could not have asked more from these group of highly talented people. Their dedication and hard work has paid off, and I hope that everyone takes something from this into their own personal endeavors in life. I know that I'll take this experience and be able to apply what I've learned into any setting. The time we sacrificed; those bloody hours at the keyboard; those late nights sipping on energy drinks, and those times when all you could think about was "Devcathlon" will now become a memory. Even as unfortunate as that may sound to a few, it has made a profound impact on what I see in a large team setting. The beginnings were difficult, but over time we progressed from novices to experts in our own way. This experience has challenged myself and others mentally and somewhat physically. This project has given me ways to express myself more freely than I usually do in any other class related setting. It has taught me to be ethical, respectful, resourceful and passionate about goals. It has also taught me to become a better person by encouraging me to open up to all sorts of people. I'll honestly miss that energy, and all those who made this project what it is today. I hope to find that same spark during my attempt at enhancing this project for this year's Google Summer of Code. I'm sorry that not all original members of the team will be participating, but I am grateful for their respectful input and support. Good luck to everyone, and thanks for all the hard work!
Friday, May 1, 2009
[ICS 499] Java + Flex Hybrid
Premise:
In this blog entry, I'll discuss my experiences of hybridizing Java, Actionscript, and Flex into forming what could possibly be a perfect ingredient for success. Well not absolute success, since I will not be building anything in this entry, but it will leave you with some ideas that could work in your setting. I'll also mention the ease of migrating between Java and Actionscript, and give you some insight into the possible technologies that surround Flex.
Contextual definitions:
Flex - front-end client-server application
Java - back-end object oriented language for building an enterprise server for channeling data
Actionscript - object oriented and script-base language used to construct logic in controlling our Flex client application.
Actionscript & Java:
Actionscript is an object oriented, free form, functional language used to build logic into creating Flash rendered content. The language follows the standards of ECMAScript and recently, in version 3.0 has been enhanced to support E4X for ease of processing XML.
Java is an object oriented language that has been widely accepted for its cross-platform, and strong emphasis in creating server-side technologies.
ActionScript 3 is different from Java when it comes to properties, dynamic behavior, and some very convenient aspects of functional programming. However, the move between Java to Actionscript was not all that difficult and it makes for a beneficial switch once you get the hang of things.
If you need a quick comparison chart between Java & Actionscript, then check out this posting.
Java & Flex:
Java and Flex provides the perfect marriage between two things that just mix well. One, you have a strong server-side back-end and two, a simple, near real-time data rendering front-end with very high refresh rates on large data sets and almost 100% deployable on any browser.
How it all fits together?
Figure 1.
Figure 1: http://learn.adobe.com/wiki/display/Flex/Flex+and+Java
A successful marriage calls for good communication:
Flex's ability to communicate with a Java EE back-end using HTTP or SOAP-based Web services is highly useful, but you're not limited to those communication approaches.
Adobe provides an open source alternative, called Blaze DS -- a server based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex and Adobe's Air application front-ends. BlazeDS lets you use Java Messaging Service JMS for communicating through XML-based transactions and allows you to use object remoting with Java. BlazeDS also adds potential performance benefits because it uses the binary AMF3 format for faster communication than is normally experienced with XML.
Conclusion:
Sorry to leave you with such limited content. I'm just excited now to test out the logic and theory, in order to get one step closer into hybridizing Java with Flex. In my next posting, I'll be concluding my research into a report that summarizes what I've accomplished and my experiences during the course of this study.
Resources:
Java & Actionscript 3 (Part 1)
Java & Actionscript 3 (Part 2)
Java & Flex Integration (Part 1)
Java & Flex Integration (Part 2)
In this blog entry, I'll discuss my experiences of hybridizing Java, Actionscript, and Flex into forming what could possibly be a perfect ingredient for success. Well not absolute success, since I will not be building anything in this entry, but it will leave you with some ideas that could work in your setting. I'll also mention the ease of migrating between Java and Actionscript, and give you some insight into the possible technologies that surround Flex.
Contextual definitions:
Flex - front-end client-server application
Java - back-end object oriented language for building an enterprise server for channeling data
Actionscript - object oriented and script-base language used to construct logic in controlling our Flex client application.
Actionscript & Java:
Actionscript is an object oriented, free form, functional language used to build logic into creating Flash rendered content. The language follows the standards of ECMAScript and recently, in version 3.0 has been enhanced to support E4X for ease of processing XML.
Java is an object oriented language that has been widely accepted for its cross-platform, and strong emphasis in creating server-side technologies.
ActionScript 3 is different from Java when it comes to properties, dynamic behavior, and some very convenient aspects of functional programming. However, the move between Java to Actionscript was not all that difficult and it makes for a beneficial switch once you get the hang of things.
If you need a quick comparison chart between Java & Actionscript, then check out this posting.
Java & Flex:
Java and Flex provides the perfect marriage between two things that just mix well. One, you have a strong server-side back-end and two, a simple, near real-time data rendering front-end with very high refresh rates on large data sets and almost 100% deployable on any browser.
How it all fits together?
Figure 1.
Figure 1: http://learn.adobe.com/wiki/display/Flex/Flex+and+JavaA successful marriage calls for good communication:
Flex's ability to communicate with a Java EE back-end using HTTP or SOAP-based Web services is highly useful, but you're not limited to those communication approaches.
Adobe provides an open source alternative, called Blaze DS -- a server based Java remoting and web messaging technology that enables developers to easily connect to back-end distributed data and push data in real-time to Flex and Adobe's Air application front-ends. BlazeDS lets you use Java Messaging Service JMS for communicating through XML-based transactions and allows you to use object remoting with Java. BlazeDS also adds potential performance benefits because it uses the binary AMF3 format for faster communication than is normally experienced with XML.
Conclusion:
Sorry to leave you with such limited content. I'm just excited now to test out the logic and theory, in order to get one step closer into hybridizing Java with Flex. In my next posting, I'll be concluding my research into a report that summarizes what I've accomplished and my experiences during the course of this study.
Resources:
Java & Actionscript 3 (Part 1)
Java & Actionscript 3 (Part 2)
Java & Flex Integration (Part 1)
Java & Flex Integration (Part 2)
Monday, April 27, 2009
[ICS 499] My tour de Flex!
Premise:
Considering the commotion about OpenLaszlo and all things RIA, I decided this week to also speak about my experiences with trying out Flex 3. Flex is an open source Flash development framework designed from the ground up to facilitate the creation of Rich Internet Applications (RIAs) on the Flash platform (Flash 9). The Flex 3 SDK framework utilizes a mixture of a custom XML format called "MXML" and the OOP language, called ActionScript (3). ActionScript 3 is required in the recent release of the Flex 3 platform, as well as the Flash 9 platform.
In this blog entry I'll walk through my experiences developing in Flex by building a fun looking authentication application form.
Tools and requirements:
So instead of starting out with the usual "Hello World!" application, I'll just start diving into the fun stuff and we'll go from there. I'll first build a simple version of the Login form, and then we'll apply Flex magic to create a more exciting user experience. All elements below were built using Flex Builder's. I would recommend snagging a copy for yourself, but you can always resort to using any text-editor of your choosing.
Applying the basic Flex Framework:
LogMeIn.mxml:
Building the basic Login in form:
Here, we have a basic form with a submit button contained within a labeled panel. It's starting to look good so far, but nothing exactly works yet. Lets add some functionality to this component.
Adding some authentication logic:
And a successful login message...
Now that sure is one sexy Alert message, much better than those generated by Javascript's alert prompts. I'm somewhat impressed with this so far, but the interface can be improved to test out the power of Flex's physics engine. We can make the UI much more intuitive and surprisingly different from anything else. From here on, I'll be mimicking code produced by Doug Mccune, a fellow Flex developer.
The rest of the code is beyond the scope of this blog entry and will be featured as a download. I replaced the original form components within the panel to what was indicated in Doug's demo. Also the modified text input labels are enclosed in a "PhysicsContainer" class in order to provide that feeling of falling and manipulable objects.
When a person attempts to login with the wrong credentials, then the components would fall from their initial position due to some applied physics. These components are also draggable objects that can be manipulated and oriented however way you want.
Overall, these RIA platforms, including Flex have proven to be the next step in building a more interactive and responsive application for simple or complicated web interfaces. Flex, for instance, is an open source framework. This means that Adobe builds a bunch of "stuff" into the structure, which you can utilize in your applications seemlessly. What makes Flex so special is that it makes things incredibly easy to assemble through its component based framework—far, far easier than authoring custom applications in the Flash authoring tools presented in Adobe's Flash Professional. Flex comes with these essential UI components (Text input, labels, buttons, etc.), as well as additional ones to assist in laying out content. Flex also makes it incredibly simple to create your own custom components out of these components and has robust CSS support, making it quite easy to style your applications and even consume the same CSS files that you might use elsewhere on your website. And of course, it's easily portable. Just see for your self below.
This week's plans...
Flex is on my good side this week, so I'll be spending some time testing a prototype interface with OVID's VistA connector. My next blog entry will further expose the technology that Flex has to offer, with regards to its support for many data source providers, including HTTPService, WebServices and Remote Objects.
Just for fun, here's the embedded app for you to play with. It sure looks like another Flash application, but it's built using Flex!
Resources:
Learn Flex in a week
Adobe AIR application: Tour de Flex
Featured download: LogMeIn.zip
Considering the commotion about OpenLaszlo and all things RIA, I decided this week to also speak about my experiences with trying out Flex 3. Flex is an open source Flash development framework designed from the ground up to facilitate the creation of Rich Internet Applications (RIAs) on the Flash platform (Flash 9). The Flex 3 SDK framework utilizes a mixture of a custom XML format called "MXML" and the OOP language, called ActionScript (3). ActionScript 3 is required in the recent release of the Flex 3 platform, as well as the Flash 9 platform.
In this blog entry I'll walk through my experiences developing in Flex by building a fun looking authentication application form.
Tools and requirements:
- Java Runtime Environment
- Flex 3 SDK
- Flex Builder (IDE) - The Eclipse-based IDE for the creation of Flash RIAs. Not only does the presence of an IDE significantly aid in the creation of Flex applications, but Flex Builder also has a design view and a code view, each with its own benefits, further improving ease-of-use and application development workflow. The only downfall is a hefty price after the 60-day trial of using the product. Of course you could either pay the fee, or switch to a light weight editor, such as vim, emacs, textpad, notepad, etc..
- Flash 9
- Flex Charting: Aset of charting and graphing components, capable of generating Excel-style data representations, to aid in the visualization of data through Flex RIAs.
- Live Cycle Data Services (LCDS): Aserver-side application that expedites the speed of data synchronization between your middleware and your Flex application SWF (formerly, Flex Data Services).
So instead of starting out with the usual "Hello World!" application, I'll just start diving into the fun stuff and we'll go from there. I'll first build a simple version of the Login form, and then we'll apply Flex magic to create a more exciting user experience. All elements below were built using Flex Builder's. I would recommend snagging a copy for yourself, but you can always resort to using any text-editor of your choosing.
Applying the basic Flex Framework:
LogMeIn.mxml:
<?xml version="1.0" encoding="utf-8"?>This code is the basic container for all your components and the basis of any Flex application. Flex Builder should also generate two important files in order to make this internet application work: first the embedded LogMeIn.swf and second, the LogMeIn.html itself. Run this in your favorite browser (Firefox for me) and you should see a blue-green colored background that fills the entire page.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
</mx:Application>
Building the basic Login in form:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" horizontalAlign="center" verticalAlign="middle">
<mx:Panel id="loginPanel" width="309" height="182" title="Login Form" horizontalAlign="center" verticalAlign="middle">
<mx:Form verticalCenter="true">
<mx:FormItem required="true" label="Username" width="215">
<mx:TextInput id="loginTI"/>
</mx:FormItem>
<mx:FormItem required="true" label="Password" width="215">
<mx:TextInput id="passwordTI" displayAsPassword="true"/>
</mx:FormItem>
<mx:FormItem horizontalAlign="right" width="215">
<mx:Button id="loginButton" label="Login" click=""/>
</mx:FormItem>
</mx:Form>
</mx:Panel>
</mx:Application>
Here, we have a basic form with a submit button contained within a labeled panel. It's starting to look good so far, but nothing exactly works yet. Lets add some functionality to this component.Adding some authentication logic:
For an incorrect login info...
<mx:Script>
<![CDATA[
import mx.controls.Alert;
private function login():void {
if (loginTI.text == "admin" && passwordTI.text == "admin") {
Alert.show("Hurray!", "Login Message");
}
else {
Alert.show("Incorrect login and password combination.", "Login Error");
}
}
]]>
</mx:Script>
And a successful login message...Now that sure is one sexy Alert message, much better than those generated by Javascript's alert prompts. I'm somewhat impressed with this so far, but the interface can be improved to test out the power of Flex's physics engine. We can make the UI much more intuitive and surprisingly different from anything else. From here on, I'll be mimicking code produced by Doug Mccune, a fellow Flex developer.The rest of the code is beyond the scope of this blog entry and will be featured as a download. I replaced the original form components within the panel to what was indicated in Doug's demo. Also the modified text input labels are enclosed in a "PhysicsContainer" class in order to provide that feeling of falling and manipulable objects.
<panel ... >
<containers:PhysicsContainer id="canvas" width="100%" height="100%">
<!-- Original login form -->
...
<flexlib:PromptingTextInput id="loginTI" prompt="username" x="50" y="35"/>
<flexlib:PromptingTextInput id="passwordTI" prompt="password" x="50" y="75" displayAsPassword="true"/>
<mx:Button label="Login" x="158" y="115" click="login()" />
</containers:PhysicsContainer>
</panel>
When a person attempts to login with the wrong credentials, then the components would fall from their initial position due to some applied physics. These components are also draggable objects that can be manipulated and oriented however way you want.
Overall, these RIA platforms, including Flex have proven to be the next step in building a more interactive and responsive application for simple or complicated web interfaces. Flex, for instance, is an open source framework. This means that Adobe builds a bunch of "stuff" into the structure, which you can utilize in your applications seemlessly. What makes Flex so special is that it makes things incredibly easy to assemble through its component based framework—far, far easier than authoring custom applications in the Flash authoring tools presented in Adobe's Flash Professional. Flex comes with these essential UI components (Text input, labels, buttons, etc.), as well as additional ones to assist in laying out content. Flex also makes it incredibly simple to create your own custom components out of these components and has robust CSS support, making it quite easy to style your applications and even consume the same CSS files that you might use elsewhere on your website. And of course, it's easily portable. Just see for your self below.
This week's plans...
Flex is on my good side this week, so I'll be spending some time testing a prototype interface with OVID's VistA connector. My next blog entry will further expose the technology that Flex has to offer, with regards to its support for many data source providers, including HTTPService, WebServices and Remote Objects.
Just for fun, here's the embedded app for you to play with. It sure looks like another Flash application, but it's built using Flex!
Resources:
Learn Flex in a week
Adobe AIR application: Tour de Flex
Featured download: LogMeIn.zip
Saturday, April 11, 2009
[ICS 499] OpenLaszlo...simply wow
It looks and feels like Flash, but its not necessarily that. OpenLaszlo is a Rich Internet Application (RIA) platform targeted for building desktop-like web applications. Its component based syntax for declarative programming provides an array of supported outputs, such as Flash, and recently, DHTML. In this entry, I'll give what seems to be a very clear cut example of a simple OLZ application.
Please note that this application is a derivative of Adam Wolff's screencast for OpenLaszlo 4 programming.
Defining and porting our data...
Laszlo follows the strong standard XPath data-binding API's, as well as components to facilitate communication with the back-end. XML is used as the standard representation format of every LZX application file. Any data source that negotiates with Laszlo applications are quite capable of generating XML dynamically. Such sources may include: JavaServer Pages, Servlets, Microsoft Active Server Pages, ColdFusion pages, CGI applications, PHP scripts, etc. To keep things simple for this example, I'll provide the raw XML file for my LZX application.
Here's my XML file, called places.xml:
Simply create a file and name it with the extension of ".lzx", then place the following inside it:
Data source retrieval in LZX app:
Created a handler for when a user clicks on a data text --the data set that was clicked on would sync with the details window.
Defining your own window class:
Demonstrated a named method handler for closing a window (animator).
Marketing this app by embedding a Google map via the GoogleMaps API:
So as you can see, OpenLaszlo gives new meaning to web "mashups" by inherently being able to consume all sorts of data sources. RIAs do a very good job at utilizing an intuitive standard, like XML to bring many of these hierarchical components to life. Tomorrow, I plan on testing out yet another RIA platform, which went open source back in 2007, known as Adobe's Flex.
Please note that this application is a derivative of Adam Wolff's screencast for OpenLaszlo 4 programming.
Defining and porting our data...
Laszlo follows the strong standard XPath data-binding API's, as well as components to facilitate communication with the back-end. XML is used as the standard representation format of every LZX application file. Any data source that negotiates with Laszlo applications are quite capable of generating XML dynamically. Such sources may include: JavaServer Pages, Servlets, Microsoft Active Server Pages, ColdFusion pages, CGI applications, PHP scripts, etc. To keep things simple for this example, I'll provide the raw XML file for my LZX application.
Here's my XML file, called places.xml:
<places>Creating an LZX application file:
<place street="750 Keeaumoku St" description="Walmart store"
name="Walmart" city="Honolulu, HI 96814"/>
<place street="1450 Ala Moana Blvd" description="Ala Moana Shopping Center"
name="Ala Moana Center" city="Honolulu, HI 96814"/>
<place street="1527 Keeaumoku St" description="Makiki District Park"
name="Makiki Park" city="Honolulu, HI 96822"/>
</places>
Simply create a file and name it with the extension of ".lzx", then place the following inside it:
<canvas></canvas>There you have it, your very first Laszlo application! I know it's not very impressive, but it only gets better.
Data source retrieval in LZX app:
<canvas>In this bit of code, I introduced a data set tag referencing to my local "places.xml" file, with a name tag of "dsPlaces." Next, "window" is a simple way of creating a draggable window panel with an optional fixed width and height. The window is the container object for our data set output. By following standard XPath for XML styled notation (/places/...), we can simply list all the names of places from the xml file. Also a special note on "lazy" replication: It simply is built into the OLZ runtime and acts as a catalyst for retrieving data faster and efficiently (similar to Google Maps rendering).
<dataset src="places.xml" name="dsPlaces">
<window title="Places" width="200" height="250">
<simplelayout/>
<view>
<text>
<datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
</text>
</view>
</window>
</canvas>
<canvas>Added a little OLZ syntactic sugar for Javascript to allow mouse over effects to the text data.
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
<simplelayout/>
<view>
<text onmouseover="this.setBGColor(0xDDDDFF)"
onmouseout="this.setBGColor(null)>
<datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
<handler name="onClick">
details.datapath.setFromPointer(this.datapath)
<handler>
</text>
</view>
<scrollbar/>
</window>
<window name="details" title="$path{'@name'}" x="${main.x + main.width}" width="400" height="250">
<datapath/>
<text datapath="@description" fontsize="14" width="100%" multiline="true"/>
</window>
</canvas>
Created a handler for when a user clicks on a data text --the data set that was clicked on would sync with the details window.
Defining your own window class:
<canvas>Added extensible window class, called "detailswindow."
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
<simplelayout/>
<view>
<text onmouseover="this.setBGColor(0xDDDDFF)"
onmouseout="this.setBGColor(null)>
<datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
<handler name="onClick">
var details = new detailswindow(canvas);
details.datapath.setFromPointer(this.datapath);
<handler>
</text>
</view>
<scrollbar/>
</window>
<class name="detailswindow" extends="window" title="$path{'@name'}"
x="${main.x + main.width}" width="400" height="250" closeable="true">
<datapath/>
<method name="close">
putAway.doStart();
</method>
<animatorgroup name="putAway" process="sequential" duration='300' start="false">
<animator attribute="height" to="50"/><animator attribute="y" to="-50"/>
</animatorgroup>
<text datapath="@description" fontsize="14" width="100%" multiline="true"/>
</class>
</canvas>
Demonstrated a named method handler for closing a window (animator).
Marketing this app by embedding a Google map via the GoogleMaps API:
<canvas>Here's a sample of an htmlview.lzx:
<href="htmlview.lzx"/>
<dataset src="places.xml" name="dsPlaces">
<window name="main" title="Places" width="200" height="250" resizable="true">
<simplelayout/>
<view>
<text onmouseover="this.setBGColor(0xDDDDFF)"
onmouseout="this.setBGColor(null)>
<datapath xpath="dsPlaces:/places/place/@name" replication="lazy"/>
<handler name="onClick">
var details = new detailswindow(canvas);
details.datapath.setFromPointer(this.datapath);
<handler>
</text>
</view>
<scrollbar/>
</window>
<class name="detailswindow" extends="window" title="$path{'@name'}"
x="${main.x + main.width}" width="400" height="250" closeable="true">
<datapath/>
<method name="close">
putAway.doStart();
</method>
<animatorgroup name="putAway" process="sequential" duration='300' start="false">
<animator attribute="height" to="50"/><animator attribute="y" to="-50"/>
</animatorgroup>
<text datapath="@description" fontsize="14" width="100%" multiline="true"/>
<handler name="ondata">
var fullAddress = datapath.xpathQuery('@street');
fullAddress += ", " + datapath.xpathQuery('@city');
map.setSrc("map.html?addr=" + fullAddress);
</hander>
<htmlview name="map" width="100%"/>
</class>
</canvas>
<canvas>This displays a map beneath the selected address of interest.
<window width="600" height="600" resizable="true" oninit="this.htmlview.setSrc('http://maps.google.com')">
<html name="htmlview" xoffset="8" yoffset="25" widthoffset="-20" heightoffset="-45"
oninit="this.bringToFront()"/>
</window>
</canvas>
So as you can see, OpenLaszlo gives new meaning to web "mashups" by inherently being able to consume all sorts of data sources. RIAs do a very good job at utilizing an intuitive standard, like XML to bring many of these hierarchical components to life. Tomorrow, I plan on testing out yet another RIA platform, which went open source back in 2007, known as Adobe's Flex.
[ICS 499] Setting up shop...
My fellow colleague and I began configuring our working server this past weekend for the OVID project. Just to reiterate from my previous post, OpenVistA Interface Domain (OVID) is a Medsphere project that interfaces a layer for communication between applications and OpenVistA data. We checked out a copy on both of our machines without a hitch. The code builds successfully on both Eclipse and Netbeans, though some of the jar classes are meant to run correctly on Java 1.5.x -- class build number should be '49'. We were planning this week to speak to two other people regarding the configuration and setup of our environment. One person being a long-time Medsphere associate, Andy Pardue, and the other a head developer of the lzVistA project, Wally Cash. Although communication was a bit limited due to the Easter weekend, we were still able to get Apache's Tomcat running, OpenLaszlo installed, and the OVID code to build.
Here are some notes for the upcoming releases of the OVID project from Medsphere. I'm excited to see that they're planning on putting out a central codebase repository. It'll be interesting to see which route they'll take as a choice of their SCM system. Hopefully if we get in contact with Andy Pardue, then we'll have some say in the matter of its open release to the public.
Here are some notes for the upcoming releases of the OVID project from Medsphere. I'm excited to see that they're planning on putting out a central codebase repository. It'll be interesting to see which route they'll take as a choice of their SCM system. Hopefully if we get in contact with Andy Pardue, then we'll have some say in the matter of its open release to the public.
- Create a comprehensive set of acceptance tests. Right now, our tests are spread out and not validated. Having these tests will allow us to quickly add new classes while validating current functionality.
- Refactor the connection logic to make it easy to choose between RPCBroker and VistaLink. RIght now, we are reliant on VistaLink. RPCBroker would be a better choice for some platforms.
- Refactor the FM logic to enable richer queries.
- We're readying the codebase to be placed in an online repository to make it easier to collaborate.
Wednesday, April 8, 2009
[ICS 499] OVID is checking in...
In recent news, Medsphere released an open source tool set, called OpenVistA Interface Domain (OVID) which equips developers with tools for messaging with OpenVistA (OV) data. To my surprise, it had basically achieved all that I had hoped for for my BMXNet conversion to Java. This release enables developers the ability to communicate with OpenVistA data through either Remote Procedure Calls (RPC) or directly through FileMan (FM) calls by way of constructed Java bindings. Since this piece of the puzzle has finally made its way into the open source community for medical health record software systems, developers are now relieved of many cross-cutting concerns regarding support for multi-data providers, OS platform support and web-based integrations. Members of this project team have taken it to the next level by demonstrating a web application comprised of intricate web services (built in Java). Their demo release is packaged with this Web Service Definition Lanaguage (WSDL) driven application (Patient Dashboard, a.k.a. lzDashboard) made entirely in OpenLaszlo (OLZ). OLZ is an event-driven, object-oriented programming language for creating dynamic, data-driven applications. OLZ serves as one good candidate for building formal interfaces that access real patient health record databases. Since information management is a vital essence in the distribution and viewing of patient records, seeking for these resourceful tools will hold greater value and support to the community of users.
New plan...
So rather than going with my original plan of rebuilding this exact tool layer, I've decided to consume this resource by including it in a live source code management environment. Obviously, Medsphere isn't absolutely there with providing a central repository due to strict litigation and licensing. However, their open source awareness is pretty much their lively hood. Medsphere has gone through many changes recently and some of which have had an enormous impact on myself and others. They recently updated their website which now looks very much like a Web2.0 site, and are now participants of the popular social networking service, called Twitter. As for the rest, they are still considered the high-end advocates of health and technology related informatics. So, I've decided, with granted permissions from Medsphere associates (Ben Mehling) to allow me to migrate OVID to some suggested SCM (Google Projects or Github). I'm not sure about when the planning will take place, but in the mean time I'll be trying out the OVID library classes and possibly implementing my own extensions or participate in the continuation of Medsphere's OLZ application, called lzVistA. I'll elaborate more on the Rich Internet Application (RIA), lzVistA in a later post.
New plan...
So rather than going with my original plan of rebuilding this exact tool layer, I've decided to consume this resource by including it in a live source code management environment. Obviously, Medsphere isn't absolutely there with providing a central repository due to strict litigation and licensing. However, their open source awareness is pretty much their lively hood. Medsphere has gone through many changes recently and some of which have had an enormous impact on myself and others. They recently updated their website which now looks very much like a Web2.0 site, and are now participants of the popular social networking service, called Twitter. As for the rest, they are still considered the high-end advocates of health and technology related informatics. So, I've decided, with granted permissions from Medsphere associates (Ben Mehling) to allow me to migrate OVID to some suggested SCM (Google Projects or Github). I'm not sure about when the planning will take place, but in the mean time I'll be trying out the OVID library classes and possibly implementing my own extensions or participate in the continuation of Medsphere's OLZ application, called lzVistA. I'll elaborate more on the Rich Internet Application (RIA), lzVistA in a later post.
Subscribe to:
Posts (Atom)