pracro:devas_corner
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
pracro:devas_corner [2009/12/14 15:06] – deva | pracro:devas_corner [2010/08/10 11:13] – deva | ||
---|---|---|---|
Line 1: | Line 1: | ||
======Deva' | ======Deva' | ||
- | =====New protocol | + | |
+ | =====New Clientside Scripting System===== | ||
+ | <code lua> | ||
+ | <?xml version=' | ||
+ | <macro name=" | ||
+ | |||
+ | < | ||
+ | <script src=" | ||
+ | < | ||
+ | -- inline code | ||
+ | if(regexp(' | ||
+ | then | ||
+ | return 'a string' | ||
+ | else | ||
+ | return ' | ||
+ | end | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | < | ||
+ | function foo() | ||
+ | -- this: current widget (widget that triggered the event) | ||
+ | |||
+ | this: | ||
+ | |||
+ | foo = widget(' | ||
+ | |||
+ | if ( foo && foo:type() == ' | ||
+ | then | ||
+ | foo: | ||
+ | end | ||
+ | end | ||
+ | </ | ||
+ | </ | ||
+ | <widgets caption=" | ||
+ | layout=" | ||
+ | < | ||
+ | truevalue=" | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | ====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> | ||
+ | < | ||
+ | <script src=" | ||
+ | < | ||
+ | --example | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ====The Widget Events==== | ||
+ | Each widget has an event that is inspired by the current '' | ||
+ | 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 ' | ||
+ | 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 '' | ||
+ | |||
+ | ====Event Handlers==== | ||
+ | * '' | ||
+ | * '' | ||
+ | * and many more | ||
+ | |||
+ | |||
+ | ====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 ' | ||
+ | Other object can be retrieved using the '' | ||
+ | <code lua> | ||
+ | function foo() | ||
+ | if (this.value == ' | ||
+ | | ||
+ | this.setValue(' | ||
+ | end | ||
+ | |||
+ | bas = getWidget(' | ||
+ | if (bas && bas.value == ' | ||
+ | | ||
+ | bas.setValue(' | ||
+ | end | ||
+ | end | ||
+ | </ | ||
+ | A small number of methods are common to all widget types. These include are: | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | Others are specific to certain widget types, such as (and many more): | ||
+ | * '' | ||
+ | |||
+ | =====New protocol===== | ||
+ | Branched in CVS using tag '' | ||
+ | Check out using '' | ||
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. | ||
< | < | ||
Line 11: | Line 106: | ||
|< | |< | ||
| | | | | | ||
- | . | + | |
- | | + | . |
- | | + | . |
| | | | | | ||
|< | |< | ||
Line 25: | Line 120: | ||
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).\\ | 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)\\ | 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 ' | + | When the ' |
- | The id is returned with every macro when queried. It is therefore the responsibility of the server to maintain | + | The resulting macros from a template request will never have ids. They are to be treated as new never-before-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. | + | |
====Edit session==== | ====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. | 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===== | =====Class Hierarchy===== | ||
Line 95: | Line 213: | ||
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