Appcelerator flow FAQs

[focusfriend]

Just some questions to get a clear picture of the Appcelerator
processing flow.

[1] Processing line after $MQ()

When there's a script line after an $MQ() line, is this processed
immediately after the $MQ() is fired or does this wait for processing
'till the $MQ() chain of commands is ready?

[2] Statemachine "initial" state vs dynamically generated object

When a HTML object is dynamically generated (e.g. via Iterator) and
this object has a statemachine condition, the "initial" state does not
get fired. Where / how to place the statemachine that its "initial"
state gets fired even with objects created during runtime?

[3] Iterator "ready" condition

Is it possible to set a condition when an iterator is completely
finished?

[4] Toggle

Does toggle work on any CSS attribute? E.g. define two style values
that are toggled.

[Nolan Wright]

1) it is processed immediately after the $MQ fires its message (it
asynchronous).

2) The condition itself does not fire a state change event - the state
machine does. A state machine change event is fired when a state
machine has a state change (which is defined by its "if" attribute).
At the point of a state change, all elements in the DOM with an "on"
expresssion that has that state as a condition will get triggered
(e.g., if the "test" state machine changes to "state1", the following
expression will get executed: on="test[state1] then show")

If a state change event occurs and your element is not yet in the DOM,
it will not receive the state change event.

The reason your menu was not getting the initial state event was
because the menu was not in the DOM at the time the initial state
event was fired, since your state machine was defined above the script
widget that fired the message to populate your menu iterator.
Appcelerator fired the initial state change, then it processed your
$MQ that populates your iterator (but by that time the state change
event had already happened so the elements in your menu iterator
missed the event).

3) Not currently. We've talked about this type of thing but it's not
implemented yet.

4) Toggle does work with any CSS attribute

Hope this helps.

[Mark Luffel]

Requiring our users to understand the order in which widgets are parsed/compiled/executed is a Bad Thing. This is exactly what a framework should be abstracting out / simplifying for the user. These are simple (framework) solutions to these issues though, for example:

 

Where / how to place the statemachine that its "initial"
state gets fired even with objects created during runtime?

When on expressions are parsed, any statemachine conditions found (that are currently true) should be triggered for that element.

[3] Iterator "ready" condition

Is it possible to set a condition when an iterator is completely
finished?

Tejus was talking about this on Tuesday. He was having a similar problem with the order in which app:validation looks-up elements. If you try to dynamically generate elements to be validated, the validator won't find the elements, because they haven't yet been created. We discussed some ways of resolving this, all of them pragmatic rather than "elegant".

I'd be interested in hearing of ways that this general problem could be solved: dealing with the different phases of widget creation and dependencies between widgets in different phases.

--Mark

[focusfriend]

Is it possible to make app:statemachine and app:validation "always on
sub-routines"? So even when objects are created during runtime, they
get "parsed" by these apps. This was by the way my initial thought of
the app:statemachine.

Another approach is passing an object(tree) to the statemachine or
validation and have it operate on only these specific objects (so not
global).

In an AJAX / SOA world, most things happen at runtime, so statemachine
and validation should be able to deal with it.

-Ivo

[focusfriend]

Thanks for the clear explenation. Item [2] needs a solution for
runtime elements (see also Mark's reply) and [3] would be nice as
well.

One more question about the iterator: "why does it create a DIV for
itself?". I want to put my the iterations in my own container with an
own ID, so I can do $(containerID).childElements. But the iterator's
own runtime DIV container sits inbetween...

-Ivo

[Mark Luffel]

One more question about the iterator: "why does it create a DIV for
itself?". I want to put my the iterations in my own container with an
own ID, so I can do $(containerID).childElements. But the iterator's
own runtime DIV container sits inbetween...

A better approach than using "$(id).childElements" is to use Prototype's CSS selector functions, ( http://www.prototypejs.org/api/element/select ) like so:

  $$("#menu_container .togglemenu")

or maybe better:

  $("menu_container").select(".togglemenu")

This will make your app more flexible, for example, when you need to add extra tags to avoid a rendering bug in IE.

--Mark

[focusfriend]

Yep, for selecting the right elements, this CSS query approach is
going to work. But for the rendering it's still not pretty that the
iterator creates its own DIV's.

And why not take this same approach for the statemachine and
validation? E.g. $MQ(statemachineID, $(elementID).select(class));

But we still need to have an "iterator ready" condition to fire this
at the correct moment.

-Ivo

On 21 feb, 21:21, "Mark Luffel" <markluf...@gmail.com> wrote:
> > One more question about the iterator: "why does it create a DIV for
> > itself?". I want to put my the iterations in my own container with an
> > own ID, so I can do $(containerID).childElements. But the iterator's
> > own runtime DIV container sits inbetween...
>
> A better approach than using "$(id).childElements" is to use Prototype's CSS

> selector functions, (http://www.prototypejs.org/api/element/select) like

[focusfriend]

Here's a poor-mans approach to the "iterator ready" condition. Just
count the number of elements that are created during the iteration
process and compare that with the items in the payload. Here's a demo
based on your nested iterator sample. At the end of the iterator, the
statemachine gets fired which sets all the item colors to red.

http://84.81.3.149/labs/ac/src/iterator.html

-Ivo


On 21 feb, 21:21, "Mark Luffel" <markluf...@gmail.com> wrote:

> > One more question about the iterator: "why does it create a DIV for
> > itself?". I want to put my the iterations in my own container with an
> > own ID, so I can do $(containerID).childElements. But the iterator's
> > own runtime DIV container sits inbetween...
>
> A better approach than using "$(id).childElements" is to use Prototype's CSS

> selector functions, (http://www.prototypejs.org/api/element/select) like

[Nolan Wright]

Another thing you can do on the state machine is manually force a
state change via:

Appcelerator.Compiler.StateMachine.fireStateMachineChange("sm","grey",true)
or

Appcelerator.Compiler.StateMachine.fireStateMachineChange("sm","grey",false)


As for the iterator div issue, you can put an "id" on your iterator
and that "id" will be placed on the <div> that we create around the
iterator - I think that should solve your problem,