User Tools

Site Tools


pracro:devas_corner

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
pracro:devas_corner [2009/12/14 15:13] devapracro:devas_corner [2010/08/10 11:15] deva
Line 1: Line 1:
 ======Deva's corner====== ======Deva's corner======
-=====New protocol concept=====+ 
 +=====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. The new protocol concept is based on a challenge response system, combined with server-push.
 <code> <code>
Line 11: Line 108:
       |<-------'               |       |<-------'               |
       |                        |       |                        |
-                   +                  
-                   +                  
-                   .+                  .
       |                        |       Server push       |                        |       Server push
       |<--------|data|---------|       |<--------|data|---------|
Line 33: Line 130:
 It is therefore the responsibility of the server to maintain a list of commit ids within a live session.\\ 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. 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===== =====Class Hierarchy=====
Line 97: Line 215:
 A macro in resume mode is marked with a distinct colour when committed.\\ 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. A macro already committed, and reopened, is to be opened in edit mode, ie. it is to assume the old values from the commit.
- 
- 
pracro/devas_corner.txt · Last modified: 2011/01/14 14:49 by deva