This week was more productive than the others (mostly because I had my last exam on Wednesday).
Here’s what I’ve done this week:
- Added AJAX functionality to the Add Concept dialog, via jQuery.
- Added a flexible way for programmers to add new widgets to the HTML Form Entry Designer module. Basically, the developers just need to specify an HTML template for the form in the Add Concept dialog and create a Javascript class with handleSubmit (called when the user presses the submit button) and generateHTML (which should return the string to put in the textarea) methods. If you want to know the full process of creating a add concept dialog for a (new) widget, you can see some examples.
- Added the Numeric, Text and Boolean widgets dialogs
Mid-term evaluations should start next week, so here’s a balance of the period. The goal for the mid-term evaluation was to have the Add Concept dialogs generating proper HTML (milestones 1-3). Milestone #2 (retrieving concepts and its datatype from the database) isn’t ready yet (haven’t started it yet!), but I’ll try to finish that before next week. To compensate for that, I’ve worked into milestone #5 (a framework for developers to add widgets), so I could say that the goal was almost reached.
I’m a bit behind on schedule, mostly due to my wrong estimates of available time during my school exams period. Now that the first period of exams is gone (I’m just counting on going to one other exam in the second period), I’ll have more time to get it back on schedule.
For the next week I’ll try to complete milestone #2 (retrieve concepts from the database) and I’ll begin “playing” with tinymce and fckeditor to decide on what editor to use. I’ll post the advantages and disadvantages I find on each one in the next weekly blog entry.
Some screenshots of the new widgets’ dialogs:
July 6, 2009 at 7:24 PM
Hi,
I’m following closely your work and I got several suggestions:
1) I see that you have updated the API jar to the very latest version. Is this necessary?. I planned to use this module with OpenMRS version 1.4.2 and I cannot update the API jars.
2) Let me suggest another editor just in case you don’t like the others: http://www.wymeditor.org/ This one is based on jQuery.
3) In my opinion, the most important feature of the editor (besides of your work) will be to have some templates of HTML TABLEs that ease the design of the form. If you could begin a new form with that kind of template, that would be very helpful.
July 6, 2009 at 8:22 PM
Thanks for your input!
1) I’ll switch to the 1.4.3 API on the next commit. That should be fully compatible with the 1.4.2 version.
2) Thanks for your suggestion, I’ll give it a try.
3) This is a good idea, and it will be taken into consideration after the foundations of the module are ready.
If you have any other suggestion, please share it!
July 9, 2009 at 11:08 PM
Yes, this should definitely target OpenMRS 1.4.
July 14, 2009 at 6:17 PM
Excuse me Agnor,
I know this is basic but I am not able to work it out. I got working htmlformentry-1.4.x and I’m compiling and deploying without errors htmlformentrydesigner-trunk and I can’t see where I must click to enter the designer. I’ve tried definining a new form and editing and existing one and, in nowhere, I see a “Designer mode”.
Besides, where, in the code, do you specify the “link” between the two modules. I can see your extension point but I don’t see where you “hook” it up onto the htmlformentry module. I have read the docs (I promise)
Thanks,
Eduardo.
July 14, 2009 at 6:43 PM
Thanks again for your interest. Because what is in trunk is still a early development release (for test purposes only), the htmlformentry module hasn’t an extension point yet.
If you add the following lines to the htmlForm.jsp page, after the first h2 tag – line 7 (http://dev.openmrs.org/browser/openmrs-modules/htmlformentry/1.4.x/web/module/htmlForm.jsp) it should work:
If this doesn’t work try to add this instead:
The link to the designer should appear when you create a new form. This is just for test purposes, there is still incomplete functionality, no data validation and it could have some bugs. It could still be useful for real use, because it automatically determines the type of the concept (if it is one of the supported types, numeric, boolean, text for now) and generates the code for that types, but just as an aid, not yet a “form designer”.
I’ll be hanging in IRC if you need help: #openmrs @ freenode