Differences

This shows you the differences between two versions of the page.

--- pracro:devas_corner [2009/12/14 15:06] – deva
+++ pracro:devas_corner [2011/01/14 14:49] (current) – deva
@@ Line 1: / Line 1: @@
 ======Deva's corner======
-=====New protocol concept=====
+=====Session sharing======
+Client logon with (patientid, template) tupple.\\
+Server makes lookup in active sessions for tupples matching the one supplied by the client.\\
+If none matches, a new session is created and 'returned' to the client.\\
+If a match exists, the client is queried if it want to take over the session.\\
+The session state is to be stored with the session (open, closed_no_commit) so the client must actively notify the server when a session is closed without commit.\\
+If a client is about to take over an active (not closed_no_committed) a warning should be issued, about possible race conditions happening.
+=====New Clientside Scripting System=====
+<code lua>
+<?xml version='1.0' encoding='UTF-8'?>
+<macro name="test_resume" version="1.0">
+  <resume>
+    <script src="regexp.lua"/>
+    <script>
+      -- inline code
+      if(regexp('.+', ''))
+      then
+        return 'a string'
+      else
+        return 'another string'
+      end
+    </script>
+  </resume>
+  <scripts>
+    <script>
+      function foo()
+        -- this: current widget (widget that triggered the event)
+        this:setChecked(true)
+        foo = widget('test2')
+        if ( foo && foo:type() == 'lineedit' )
+        then
+          foo:setValue('bleh')
+        end
+      end
+    </script>
+  </scripts>
+  <widgets caption="Test Resume"
+          layout="vbox">
+    <checkbox name="bar" caption="?" onChange="foo()"
+              truevalue="ja" falsevalue="nej"/>
+  </widgets>
+</macro>
+</code>
+====The Script Tag====
+The script tag can either consist of inline code, or be a reference to a serverside file, that will be inserted in-place by the server before it is sent to the client.
+<code xml>
+<scripts>
+  <script src="foo.lua"/>
+  <script>
+    --example
+  </script>
+</scripts>
+</code>
+====The Widget Events====
+Each widget has an event that is inspired by the current ''script'' attribute.\\
+Currently the script is referred by its name, and called whenever the widget changes its value.\\
+In the new system, the script attribute is removed and replaced by event attributes. The event attributes will themselves contain lua code and not simply a name. In order to call 'external' code, simply wrap it in a function and call it here.\\
+The return values will no longer be used. Instead widget methods will be added to control the validation state of each widget, eg. ''setValid(true|false)''.\\
+Since it is no longer required (due to redundancy) the ''regexp'' attribute will be removed.
+====Event Handlers====
+  * ''onChange'': triggered whenever the value of the widget is changed, either programmatically or by the user.
+  * more to come
+====The Widget Object====
+When in a lua function, invoked by an event handler, the calling object (the object invoking the event) will be made available through the value 'this'.
+Other object can be retrieved using the ''widget('name')'' function.
+<code lua>
+function foo()
+   if (this:value() == 'bar')
+   then
+      this:setValue('dut')
+   end
+   bas = widget('mywdg')
+   if (bas && bas:value() == 'bar' )
+   then
+      bas:setValue('dims')
+   end
+end
+</code>
+A small number of methods are common to all widget types. These include are:
+  * ''setValue(string)'', ''value()''
+  * ''setValid(boolean)'', ''valid()''
+  * ''setVisible(boolean)'', ''visible()''
+  * ''setEnabled(boolean)'', ''enabled()''
+  * ''type()''
+  * ''name()''
+Others are specific to certain widget types, such as (and many more):
+  * ''setChekced(boolean)'', ''checked()'' (checkbox)
+=====New protocol=====
+Branched in CVS using tag ''new_protocol''.\\
+Check out using ''cvs checkout -r new_protocol pracro''.\\
 The new protocol concept is based on a challenge response system, combined with server-push.
 <code>
@@ Line 11: / Line 115: @@
       |<-------'               |
       |                        |
-                   .
+                  .
-                   .
+                  .
-                   .
+                  .
       |                        |       Server push
       |<--------|data|---------|
@@ Line 25: / Line 129: @@
 The macros will all be created by the client in the order in which they arrive. And they will remain in their positions throughout the entire session (unless the user reorders them that is).\\
 Some macros are static macros and will remain open at all times, and not be drawn with collapse buttons (FIXME defined in the macro files, not in the template). They will be pushed by the server upon content changes. (FIXME is this even possible? -  think of 'off site' changes, eg. in Artefact. These are not necessarily pushed to the server)\\
-When the 'open' is handled, a request for the given macros is sent to the server. This macros is returned in expanded/non-resume state. If the macro was already filled out, its ID is to be sent with the request, making the server fill out the macro with its previous values.
+When the 'open' is handled, a request for the given macros is sent to the server. This macros is returned in expanded/non-resume state. If the macro was already filled out, it is to be queried in edit mode (see below).
-The id is returned with every macro when queried. It is therefore the responsibility of the server to maintain a list of commit ids within a live session.\\
+The resulting macros from a template request will never have ids. They are to be treated as new never-before-committed macros.
-If a macro is not given an id, it means that the macro has not yet been committed. The id will be generated when first committed.
 ====Edit session====
 If a macro is to be opened in edit mode, the client simply needs to achieve its id, and send it in the query.
+The returned expanded macro will be prefilled with the values from the original commit. The id is to be stored and sent with data when the changes are to be committed. The server will then connect the old values with the new ones in a way similar to a CVS system. The old values are preserved and can be retrieved in some manner, but the latest ones are 'on top'. This includes the generated resume text.
+It is therefore the responsibility of the server to maintain a list of commit ids within a live session.\\
+If a macro is not given an id, it means that the macro has not yet been committed. The id will be generated when first committed.
+====Server event map====
+Input: Request, template.\\
+Events: Read template file, read macros, process macros.\\
+Output: Macros in resume mode. Macro ids\\
+\\
+Input: Request, macro.\\
+Events: Read macro, process macro.\\
+Output: Macro in widgets mode. Macro id\\
+\\
+Input: Request, macro resume.\\
+Events: Read macro, process macro.\\
+Output: Macro in resume mode. Macro id\\
+\\
+Input: Commit, macro, macro id.\\
+Events: Read macro, process macro, make commit\\
+Output: Transaction id.\\
+\\
+Input: Commit, session, id list (commit order)\\
+Events: Order stored resume texts. Commit resume texts to journal. Remove session.
+Output: Empty\\
 =====Class Hierarchy=====
@@ Line 95: / Line 222: @@
 A macro in resume mode is marked with a distinct colour when committed.\\
 A macro already committed, and reopened, is to be opened in edit mode, ie. it is to assume the old values from the commit.