One interesting detail about the oscar distribution , is that it seems to have several different frameworks , applied at different times e.g. the basic login framework is fairly struts and object based; the appointments module is almost pure JSF without struts ; the encounter module reverts back to using struts; the CAISI extension seems to import the spring framework, which appeared on the scene several years after struts. It would have been interesting to see a version 2 oscar using the latest , fashionable frameworks, mainly because they are fashionable, but also because they possibly might show the differences between using pure JSF, Struts, and later frameworks, mainly for programmer educational purposes. To the end user, it's not really that important, unless the end user has medium to long term objectives of having an easily extendible, modifiable, and reuseable open source application, and then, the hypothesis is that rewriting in the newer frameworks, these goals might be made closer or even achieved.

Example prototype using java / apache MyFaces?/ JSF

unfortunately , the example cannot be posted, but is available here http://lists.gnu.org/archive/html/gnumed-devel/2006-07/msg00051.html[link to jar without libs]

The java libraries used are what is in the basic myfaces distribution library jar (note , the myfaces specific extension tomahawk is also required). http://myfaces.apache.org/download.html

And the more general chore of ReconstructingNoLibJars.

At this stage, the data is not persistent, but it shows one way of doing the appointments use case using MyFaces? JSF. Because the appointments use cases uses dynamic html table columns for each provider's column of appointments, this is problematic for the basic JSF specification , but the MyFaces? taglib extension allows the use of dynamic columns. It is a little bit idiosyncratic , as the outer dataTable must access some sort of collection which is not used, and the inner tag must access the providerAppointments collection. ( These tags work by specifying a collection object in the value attribute, and the iteration item name in the var attribute ; then the item name is a reference to each object in the collection as they are iterated over ).

In practice, the code overall looks quite cleaner, but debugging can be a little bit onerous, as debugging on the java model side of things required exporting the war out of eclipse after a debugging change, and then stopping , undeploying, and redeploying the war file . Text output test cases can be written to facilitate the java model debugging, which is a good , easy habit, that this developer needs to get into.

The actual model that evolved on this first attempt at using JSF for an appointments use case, is roughly : there is a controller mediator object FacesAppointmentManager? that is the single session bean for the application. It appears at this stage, that only one central session object is allowed, in the MyFaces? JSF implementation. It mediates for a business domain object called AppointmentBook?, which has "pages" organized according to rounded off dates, and on each page exists maps keyed by provider which reference appointment column objects called ProviderAppointments?. The provider appoinment objects manage filled appointments as appointment objects, but emit a view collection of AppointmentSlot? objects, which mediate between the view and the appointment objects. AppointmentSlots? main view specific responsibilities is holding the appointment slot interval times, and the CSS view class string , which is "empty" if the slot is empty, and "filled" if the slot is filled. The AppointmentDay?.jsp page then uses this label to determine which css style to apply to the input text html item for a given appointment. Once a view collection of appointmentSlots is emitted for a particular day and provider, it is stored in a map, and this gives the application some temporary storage , so that appointment days can be changed and any appointments filled can still be recalled for a particular day. This caching of appointment view information may not be necessary or desired when the persistence and store retrieval code is done, but currently it is useful to illustrate that view - model separation can still work for the moderately complicated appointments use case.
Topic attachments
I Attachment Action Size Date Who Comment
facesAppointment1-nolibs.jarjar facesAppointment1-nolibs.jar manage 41 K 18 Jul 2006 - 14:25 SyanTan testing no libs jar
Topic revision: 22 Jul 2006, SyanTan
 
Download.png
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark