Himle
From Wikipedia, the free encyclopedia
Himle | |
---|---|
Developed by | Juha-Jarmo Heinonen |
Latest release | 'stable' / 2008-05-07 |
Preview release | 'trunk' / head revision |
Written in | Javascript and Ruby |
OS | Cross-platform |
License | GPL |
Website | http://himle.org/ |
Himle is an AJAX-powered RIA SDK consisting of a Ruby HTTP server framework combined with a Javascript GUI framework inspired by the BeOS Interface Kit as well as Mac OS X Cocoa.
Contents |
[edit] Himle Client Framework
The client has a very high-level Web Browser abstraction. DOM-element interfaces are abstracted by the ElementManager. DOM-event interfaces are abstracted by the EventManager. New browsers or other layout engines can be enabled by adding support in these abstraction layers.
The User Interface library is based on object inheritance and its base class is HClass, a derivate of Base by Dean Edwards. Multi-tasking is provided by HSystem and HApplication, similar to the BeOS equivalents (BTicker, BLooper, BApplication). They provide onIdle -events that propagate down the view-tree to all connected sub-views.
The coordinate system origo is at the top-left corner of the browser window. The X-axis is incremented to the right, the Y-axis to the bottom with integers representing pixels. HPoint is an object with helper methods representing points in the coordinate space. HRect represents rectangles consisting of two points; Left/Top X/Y -coordinate as well as Right/Bottom X/Y coordinates. These objects are very similar to the BeOS BPoint and BRect and contain some additional functionality prenent in the Cocoa NSPoint and NSRect.
The basic visual building block is called HView, similar to BView and NSView. It implements basic visual and structural inheritance and can represent inself as well as its contents. Visually it defaults to a blank, transparent container element. It takes exactly two initialization arguments, the first being a HRect instance describing the position and dimensions. The second argument is the parent component; either an HApplication instance or another HView instance. HView interacts mainly with the ElementManager and its HRect instance.
HControl is inherited from HView, and as such shares all its features. Additionally, it implements events, labels and values. HControl interacts directly with EventManager to get synthetic, desktop-gui-like events as needed. Its initialization arguments are the same as HView, except for the third, optional Options-block. Options is an JSON-formatted block that specifies all extra properties HControl has. All derived components behave the same way. UI components are inherited from HView and HControl, depending on the nature of the component.
HThemeManager and HMarkupView makes theming components easy by supporting automatic, cached client-side html template rendering and stylesheet loading per component on a as-needed basis. Both html and style sheet templates have a template syntax identical to Ruby's string evaluation blocks, for example:
Some id's are bound automatically to the view structure for easy access in the component code. They consist of a prefix like 'label', 'subview', 'value' and so forth suffixed with the ElementManager's id for the HView-derived element. Template files are loaded and cached automatically based on the uri prefix specified in the HTemplateManager's properties as well as the name of the theme and the component. For instance, the files requested for a component named 'button' and theme named 'flowers' and theme prefix '/H/themes/' are:
/H/themes/flowers/html/button.html /H/themes/flowers/css/button.css
Images associated with themes are loaded from the 'gfx' subdirectory of the theme. Using #{this.getThemeGfxFile('flower.png')} inside a template will return the url of the image. In this case it would be:
/H/themes/flowers/gfx/flower.png
[edit] Himle Server Framework
Software is developed as server plugins. UI construction is defined in .js 'resource' files from the server's standpoint. All plugins are inherited from a class called 'Plugin', it's evaluated automatically in an anonymous module namespace by PluginManager. A plugin may optionally register itself with a name consisting of any valid string. This allows other plugins to call it explicitly. All plugins receive an idle -event on each XMLHttpRequest made by the client. Additionally, they also receive an init_ses -event whenever a new session is created and a restore_ses whenever an old session is restored. All requests share the same plugin instances. Request-specific data, such as the user's session data is passed around as Message -object instances. This keeps the performance high and memory consumption low, as very few instances are needed per request and it also keeps the software thread-safe by design. The himle server can handle thousands of concurrent clients even on modest hardware.
Data shared between the server and client components are defined as HValue instances. They are syncronized from client to server immediately upon changes or with the next request, if the previous syncronization is still busy. The syncronized value is then passed on to any number of validators bound to the value in the server. If all validators accept the value change, it's marked as clean. Validators are regular plugin methods that accept the msg and the value. They are can also be used as triggers. When the server changes a value, it's sent to the client in the ongoing request stream. Values bound to client components signal the associated components with setValue -events. This causes the positive side-effect of the value being updated in all associated components as well as associated plugin methods automatically, whenever the value is changed in the server or a client. Values are stored as members of the session data object to the session table.
[edit] Goals
- High Server Performance
- High Security
- Sophisticated GUI Framework
- Rapid development cycle
[edit] See also
[edit] References
[edit] External links
|