CHEATATJOE'S

bendtheweb:

Mogu Aristotle RC1 has been tagged!

Lots of new features in this release:

Actions:

• + add_widget -> adds a new widget as a child of the listener
• + remove_child -> removes and deletes a widget
• + slot -> passes a piece of information into a named ‘slot’ within the Application. After the application retrieves this information, it is no longer available. 
• + clear -> Clears all children of a widget
• + reload -> Reloads the widget (only works on dynamic widgets!)
• + register_user -> Given some userid and some auth code, registers a user into your system (these two pieces of information are passed in via slots so that the plaintext username/password will only exist momentarily)
• + change_session -> Changes the application’s active session
• + match -> Tests to see whether two input fields contain the same value (password verification, mostly)
• + test_text -> Tests to see whether information in an input-field matches an arbitrary string
• + set_text -> Alters a {text} widget’s displayed text.

Triggers:

• + keyup -> Allows event chains to be triggered from a user’s key going up.
• + succeed -> If the widget passes some test (a Validator, {match}, or {test_text} event currently), a chain of events can be bound to that success
• + fail -> Similarly, if a widget fails some test, a different chain of events can be triggered.

This means your widgets can now have some basic boolean logic associated with them. 

Validators:

validators["foo"] = {
    "type" : "{regex}", # Currently, the only type of validator available
    "test" : "^[a-zA-Z0-8]{2,8}$ " # the regex to test for
}

When a validator is bound to an input widget, it is called automatically on a keyup, triggering the widget’s success/fail signal. 

This means that an input widget that gives user feedback is as simple as:widgets[“form:input”] = { “type” : “{input}”, “content” : “Any letter, or numbers 0-8!”, “validator” : “foo” # uses the validator above } events[“form:input”] = [{ “signal” : “^209^”, “listeners” : “{self}”, “trigger” : “{fail}”, “action” : “{set_style}” “message” : “red_text” }]

Just like that, as the user is typing, if they do not enter the correct characters, the text in the input field changes to red. This is a simple example of course. You can do very complex things in this format, though.

Sessions are now fully supported (see a few posts ago for a detailed explanation of their inner workings).

The basic syntax can be like so, however:

widgets["greeting"] = {    
    "type" : "{text|dynamic}", 
    " content" : "YOU ARE NOT LOGGED IN.",
}
policies["greeting"] = {
    "storage_type" : "string",
    "mode" : "replace",
    "data_type" : "string" ,
    "default" : "Hello, Sweetie!"
}

Now, the text will show YOU ARE NOT LOGGED IN” by default, but once they are logged in, the widget can be reloaded to show “Hello, Sweetie!” instead.Of course, you can also let your user set their own greeting. For instance, if we wanted to use the “form:input” widget above, we could simply add the following to its events:

{
    "signal" : "^209^",
    "trigger" : "{succeed}",
    "listeners" : "{self}",
    "action" : "{store}",
    "message" : "greeting"
}

Now, if the user types a valid entry into the input field, it will automatically be stored as the user’s greeting, and they will see it next time the widget is reloaded. If they delete their greeting, “Hello, Sweetie” will be shown again. If they log out, “YOU ARE NOT LOGGED IN” will be shown. 

Lastly, a brief description of user registration and logins:
registration requires a userid and a user auth token (email address/password, for instance). Of course, these can be any values you choose. You may of course collect as much data as you like on registration, but those two things ARE REQUIRED.

Events should be bound to some sort of submit trigger (like clicking on a button), but as long as two input fields exposed to the application can be stored in the “USERID” and “USERAUTH” slot,  Mogu will be happy.

I will put a full, working example of user registration mogu script up on the wiki later. This functionality can also be seen at  FinancialFirsts.org later today (Friday, 8/24).

Next week should offer  the full release of Mogu Artistotle, the first beta release. We’re doing mathematicians.