I’ve been tweaking the calendar views to suit the needs of our Agency. Before I go in too deep I wanted to make sure that OpenEMR is going to stick with PostCalendar v4.0 for the long haul. The changes I’m about to make will really spiff up the calendar interface for us. But if all my hard work will be wiped out be an upgrade to say, OpenEMR 2.9 which would switch away from PostCalendar, then I’ll likely avoid too many customizations.
FYI - I’m trying to limit all my customizations to the template files and not the core functionality.
But one glaring omission to PostCalendar, as far as I know, is that you cannot edit or delete a single Event in repeating Event.
Just this morning I committed a bunch of changes from another developer that (optionally) revamp the look of the calendar. This option is controlled via a selection in the user form (Admin/Users and Groups)… I asked him to make it optional, because some people are bound to not like it. You might want to look at that and perhaps plan to fit your ideas in similarly. See also the related notes in openemr/Changelog.
To answer your question, we do want to get away from Smarty. However nobody seems to be working on that yet. I think it would be a big step forward if someone (like you!) would rewrite the calendar to be faster and better, preferably replacing all the Smarty/PostCalendar stuff, and combining the best of everyone’s ideas. Regardless of that, why don’t you post your ideas here for more discussion?
Since I’ll have a deeply vested interest in this application I expect to be digging in pretty deep. As such, I’ll look at what other calendar options are available. But really, they all do the same thing. Perhaps there are a few packages with a lighter overhead but any one selected will need to be adapted to OpenEMR purposes. And of course there will need to be some scripts for converting data from PostCalendar to whatever.
I’ll keep my changes as modular as possible so they are optional to the basic OpenEMR installation.
If you are going to be making extensive changes to the Calendar, It really would be swell if you came up with a Calendar approach that does not involve Smarty.
I believe some of the existing calendar code (implicitly) references the $HTTP_FOO_VARS globals. Whether you change away from PostCalendar or not, it would be helpful if, as you (re)write code, you change references to the $HTTP_FOO_VARS globals to the equivalent $_FOO superglobals, as the old style (and the PHP 5.x register_long_arrays directive in php.ini) will no longer be supported with PHP 6.0, which is due out any day now.
Perhaps they “all do the same thing”, but I’m not sure that’s the thing we want. A few random (and not very deeply considered) thoughts:
My own past calendar changes have mostly focused on performance and visual compactness. It used to be MUCH slower when you have a large number of events than it is now. Snappy performance is vital.
Handling a larger number of doctors in a seamless way is probably the most important current obstacle to be overcome. How do other PM systems do that?
A calendar that updates itself in real time (for example with AJAX) would be nice. And if calendar events can be cached browser-side, most of the drawing and paging could be done with JavaScript to make it very responsive.
Due to time constraints I have only 4 days to revamp the calendar.
Instead of ripping out PostCalendar and it’s use of Smarty and old PHP Globals I’m just giving it a facelift. Something a little easier to manage when I have 150 ‘providers’ each with their own calendar view.
I’ll happily submit my changes to Rod. They will be in a nice little pntemplate thing that can just be dropped in place. Then with a tweak to a config file the ‘new’ interface can be used. Or the older existing one can be used. All depending on a config setting.
CFAPress:
Please, take a look at how the new interface switching was implemented in the latest CVS commit.
There is an per-user selection of Calendar UI. You can add yours as another option and change default.html and navigation.html to point to your template in case it is selected in the user profile.
Thank you.
I’m browsing the CVS repository right now and I don’t see any PostCalendar templates other than the ‘default’ one. Where else should I be looking to review the code you committed to CVS? Do you have any screenshots available so I can check out your work?
I’m at the point where I need to start my development from a stable release of OpenEMR because it’s going to be used in a production environment in less than one month. Picking up CVS code is difficult to justify.
Here are the files that were added (A) and modified (M) for Nethanel’s recent contribution:
M ChangeLog
M interface/main/main_info.php
M interface/main/calendar/add_edit_event.php
M interface/main/calendar/find_patient_popup.php
M interface/main/calendar/index.php
M interface/main/calendar/modules/PostCalendar/pnuserapi.php
M interface/main/calendar/modules/PostCalendar/plugins/function.pc_url.php
M interface/main/calendar/modules/PostCalendar/pntemplates/default/style/day.css
M interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/default.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/fancy_template.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/day/orig_default.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/global/fancy_navigation.html
M interface/main/calendar/modules/PostCalendar/pntemplates/default/views/global/navigation.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/global/orig_navigation.html
M interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week/default.html
A interface/main/calendar/modules/PostCalendar/pntemplates/default/views/week/orig_default.html
M interface/usergroup/user_admin.php
M interface/usergroup/usergroup_admin.php
M library/auth.inc
M library/dynarch_calendar_setup.js
M library/patient.inc
M sql/2_8_3-to-2_8_4_upgrade.sql
M sql/database.sql
I think that not working with current (CVS) code would be short-sighted. If you want your changes to be preserved in the next release, they have to get into CVS. Otherwise you’ll find yourself retrofitting your customizations every time you upgrade.
Using the latest code is not so bad. There may be new bugs, but also old bugs get fixed and new features are added. It’s normally a net plus.
I’ll check out the latest CVS code into my openemrDEV folder. That way I can see what the next release may look like.
======
This starts heading down the road of how to manage software releases. I’m a fan of the two branch model: stable and development. Stable gets infrequent updates but it’s stable; No surprises. Development gets updated daily and has the bleeding edge stuff. But it often has little bugs appearing.
In my case I think I’m heading down the road toward a fork. Our Agency is going to need lots of code changes to suit our needs specifically. It’s difficult to do my development with such specifics while at the same time making general contributions to the code base.
For example, the security model is not going to be sufficient for our business model: Health Centers combined with Psychiatry combined with Mental Health Counseling. 120 providers and about 7000 clients in one database. Nurses won’t need access to mental health forms, etc etc etc.
This has been the trouble I’ve always faced when trying to make contributions to Open Source while at the same time tailoring software to specific needs.
My first tip would be to negotiate for more time. Time spent working with others is a very real and necessary part of any serious software development project. Honestly, I think forking would lead to a very poor outcome.
And coincidentally, here’s something I wrote to Nethanel just yesterday:
“I think a worthy goal for the project is that nobody ever has to
customize the code. Obviously we are far from that, but when you find
that your site needs a change that others would not be interested in,
ask yourself why! Perhaps it reflects a larger issue that needs to be
addressed. Let’s try to do The Right Thing, whatever that may be.”
