#87 XML form generator

open-accepted
nobody
None
5
2011-02-25
2011-01-15
No

the attached is a version of the xml based form generator with one bug fixed, and wider xslt engine support. specifically, it supports both xsltproc and xalan.

Discussion

  • Brady Miller

    Brady Miller - 2011-01-16

    hi,

    I put your code here (for review/testing):
    http://github.com/bradymiller/openemr/commits/xmlformgen

    commit 1: your original code
    commit 2: removed broken forms and/or forms that touch core openemr stuff
    commit 3: created/installed a working form for test/review

    Over next several days, will put a review on the code in github.

    (quick aside, please start to learn git/github; makes collaboration far easier; ie. .the time I spent putting this together on git/github could of gone towards the actual review)

    thanks for the contribution,
    -brady

     
  • Brady Miller

    Brady Miller - 2011-01-16

    hey,

    Done with code review/testing. See my comments in github at end of commit 1 and within commit 3. Another question I have is what the scripts in xmlformthrough are used for?

    -brady

     
  • Julia Longtin

    Julia Longtin - 2011-01-16

    Brady,

    the scripts for xmlformthrough/ are kindof an experiment, going in the direction of complete integration.

    If you replace any of the .PHP files in one of the generated forms with the ones in xmlformthrough, touch up one path in the files (still working on generating that part), and place your .xml file in just the right spot...
    then openemr generates the PHP for each page on-the-fly, then executes them. so, no generated .php files on disk.

    No, i don't intend for anyone sane to run that in production. but when i'm editing a forrm's XML live to "get the look right", its real nice to not even have a 'compile' step.

    as for github, I'm actually becoming very familiar with the git development style. i'm just gitorious centric, and would prefer to continue to learn gitorious, since i can have the source code to it. ;)

    I do like the inline commenting, that's neat. i wonder if i can do that on gitorious...

     
  • Julia Longtin

    Julia Longtin - 2011-01-16

    Oh, and regarding history.xml.. it does not attempt to replace. it effectively acomplishes replacement in trees before the 'new tab ui'.

    I would like to take this in the direction not just of adding forms to our current system, but of removing code from having to be maintained in dozens of places. A year ago, the output of history.xml was a drop-in replacement for the history code in openemr.

    I had to go through backflips to make that one work, as history contains data objects that are not used anywhere else in the system. XMLFORMGEN supports those objects. With your continued cooperation, i would like to target complete replacement of the history subsystem.

     
  • Julia Longtin

    Julia Longtin - 2011-01-17

    Hey Brady, I'm going through your first comment, and making the change you recommend includes a ton of script content directly into my xhtml output.

    do you know why this sript must be included in our forms, or some easy way to make this go away? I spend a lot of time staring at the source of these, and it would be very nice to not include script content directly into forms if avoidable.

     
  • Brady Miller

    Brady Miller - 2011-01-17

    hi,
    Not sure I understand what you mean. What script?
    thanks,
    -brady

     
  • Julia Longtin

    Julia Longtin - 2011-01-17

    brady,

    here's a version with all of the updates from commit 038ed26bd38d61f3..

    If you look at the source in the web browser of view.php or new.php, you'll find a large section of script being spit out by dynarch_calendar_en.inc.php.

    as a general rule, i like to see script content in a separate URI, not in the xhtml document itsself.

    I'm using gitorious to publish my other work would you like me to go ahead and start pushing this up, instead of dropping tarballs? ;)

     
  • Brady Miller

    Brady Miller - 2011-01-17

    hi,

    Gitorious is better tarballs (much easier to grab your commits of your repo than have to deal with tarballs). Problem with gitorious is no way to embed review comments, but still better than tarballs.

    -brady

     
  • Brady Miller

    Brady Miller - 2011-01-17

    hi,

    I'll wait for you to get it up to gitorious.

    Regarding script stuff, that is only way (that I know of) to get the javascript calendar internationalized (by running it through the php engine, can then use the xl() function to internationalize javascript code).

    -brady

     
  • Brady Miller

    Brady Miller - 2011-01-18

    hey,

    Had a little time, so looked at your tarball and put here (last commit on that branch):
    https://github.com/bradymiller/openemr/commits/xmlformgen_rev2

    Please go through all the original embedded comments in original review here (search through page for bradymiller to find them):
    http://github.com/bradymiller/openemr/commit/244ea5819750cd1fba82cbeedb6b995ee9c0c423

    Still need to finish replacing all the dynarch_calendar_en.js lines, htmlentities functions. innodb database thing, and deal with the signatures tables issues brought up.

    I suggest providing a simple example xml form (without signature feature and can discuss how to get a global signature table into openemr codebase on the forums as another issue). then if you fix above issues and it tests ok, it will be ready for commit. Then you begin getting more ambitious; goal now should be to make a simple form correctly and get your code committed.

    -brady

     
  • Julia Longtin

    Julia Longtin - 2011-01-28

    Here is a new version, with a simpler communication_log example, that should match the 'normal' behavior of an openemr form.

    I think I touched on all the issues in your review, though i don't know what you're referring to regarding PHP6.

     
  • Brady Miller

    Brady Miller - 2011-01-29

    hey,
    Also created a github branch to focus on your signature method. If this works, then we should place the table directly in OpenEMR so it is stable (otherwise run risk of having incompatible tables if have it created by the form generator):
    http://github.com/bradymiller/openemr/commits/form_signature_mathod
    -brady

     
  • Brady Miller

    Brady Miller - 2011-01-29

    Julia,

    I posted a thread to discuss your signature table/method:
    http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4079752

    Please describe the method there. Ideally, we could then commit the form generator code and the signatures table in the same commit. I'll package it up; you just need to convince the community why the signatures table/mechanism is useful.

    thanks,
    -brady

     
  • Brady Miller

    Brady Miller - 2011-02-02

    hey,

    To avoid this project stalling out again, I committed the below proposed rebased code. I also removed the commented out signature line in the example since this signature table/method is still under discussion in the forums. If the signature method makes sense, then should include the table in database.sql and upgrade script to ensure it's stable and can be modified from a central location (otherwise if you only modify it in your xmlformgen stuff then you'll start having forms that are no longer compatible in the future).

    So getting the signature table/method into the codebase would be the next logical step here (also would be cool to get your on the fly stuff working and in also...)

    thanks,
    -brady

     
  • Brady Miller

    Brady Miller - 2011-02-25
    • status: open --> open-accepted
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks