RL2 App entry point
91 views
Skip to first unread message
Joni Bekenstein
Mar 1, 2012, 3:13:02 PM3/1/12
to robo...@googlegroups.com
In RL1 we had the startup() method. What would be the equivalent in RL2? After creating a context with bundles and config objects, where could I create the first view? I think I could do it in a config object which waits for the context to be initialized. Is this a good approach?
Shaun Smith
Mar 1, 2012, 3:26:38 PM3/1/12
to robo...@googlegroups.com
Yup, this is missing at the moment. The context will probably need to dispatch events that match its lifecycle methods (but this raises a slew of questions). Also, I want to add a config processor that handles Function references and calls them after context initialisation, so you would be able to do this:
context = new Context(
Bundles…,
onStartup);
* where onStartup is some method/function reference.
What I like about that approach is that the place where we define the context is usually the place where we want to add the first view, and for a Flex application this means that we don't have to cast the "contextView" back to an IVisualElementContainer in some external command/config.
In the meantime your approach should work fine. Just be sure to add that config last.
On 1 Mar 2012, at 20:13, Joni Bekenstein wrote:
In RL1 we had the startup() method. What would be the equivalent in RL2? After creating a context with bundles and config objects, where could I create the first view? I think I could do it in a config object which waits for the context to be initialized. Is this a good approach?
--
You received this message because you are subscribed to the Google
Groups "Robotlegs" group.
To post to this group, send email to robo...@googlegroups.com
To unsubscribe from this group, send email to
robotlegs+...@googlegroups.com
for support visit http://knowledge.robotlegs.org
Joni Bekenstein
Mar 1, 2012, 3:35:53 PM3/1/12
to robo...@googlegroups.com
I'm doing something like this:
public class AppEntryPoint implements IContextConfig
{
private var _context:IContext;
public function configureContext(context:IContext):void
{
_context = context;
context.addStateHandler(ManagedObject.POST_INITIALIZE, handleContextPostInitialize);
}
private function handleContextPostInitialize():void
{
var contextView:DisplayObjectContainer = _context.injector.getInstance(DisplayObjectContainer);
contextView.addChild(new HomeView());
}
}
Where HomeView would be the first view to create. And this works even if I don't but this config last. I suspect it's because I'm waiting for POST_INITIALIZE?
About passing function references, wouldn't that mean that I would have to know about HomeView (in my example above) outside of the context?
Another thing I stumbled upon is async configs, for example to load critical assets at startup. I think I could add a handler with context.addConfigHandler, since handler support async operations... right? I've been reading all the readme's in the repo for a while now, still digesting everything though.
Shaun Smith
Mar 1, 2012, 4:06:48 PM3/1/12
to robo...@googlegroups.com
Ah, I assumed we were talking about a plain config class (not an IContextConfig). The plain config version might look something like this:
class AppEntryPoint
{
[Inject] public var contextView:DisplayObjectContainer;
[PostConstruct]
public function init():void
{
contextView.addChild(new HomeView());
}
}
And it would need to be installed last. As a general rule, I'd avoid IContextConfigs unless you're writing extensions. In fact, perhaps IContextConfig is poorly named.. maybe it should be IContextExtension or something like that.
Also, POST_INITIALIZE might not be the correct time to add this view (from a theoretical point of view): post initialize runs after initialization and, in my opinion, adding the main view is part of the initialization process. At post initialize I would expect the app to be fully initialized, and this would include having the main view on stage.
About passing function references, wouldn't that mean that I would have to know about HomeView (in my example above) outside of the context?
Yup, but personally I don't mind that too much in this particular case.
Joni Bekenstein
Mar 2, 2012, 6:13:31 AM3/2/12
to robo...@googlegroups.com
I agree the name IContextConfig may be confusing. Though, isn't it possible for an extension to install itself without implementing IContextConfig? Context maps itself in the injector, so an extension can follow the same pattern you just described, a plain config object, and achieve the same result. What advantage do you get by using the IContextConfig interface?
On the other hand, do you have any pointer on how one could setup an async context config? Is there a way to halt the initialization? Maybe context.addConfigHandler? Thanks!
Shaun Smith
Mar 2, 2012, 6:54:20 AM3/2/12
to robo...@googlegroups.com
On 2 Mar 2012, at 11:13, Joni Bekenstein wrote:
I agree the name IContextConfig may be confusing. Though, isn't it possible for an extension to install itself without implementing IContextConfig?
Nope, not really. Plain classes are instantiated (by the injector) at context self initialization phase, so they have no control over the initialization process at all. You can see how the ConfigManager processes them here:
If the context is already initialized when a plain class is installed, the injector simply instantiates an instance of that class. If the context is not yet initialized, that class is queued up until initialization completes.
You can read about this config handler and the others here:
The ConfigManager follows the same principles as the ObjectProcessor which you can read about here:
Context maps itself in the injector, so an extension can follow the same pattern you just described, a plain config object, and achieve the same result. What advantage do you get by using the IContextConfig interface?
Classes or objects that implement IContextConfig are handled completely differently to plain classes/objects. No injection occurs, and the context is immediately passed to the configureContext method. This allows the extension/bundle to hook into the context as soon as possible (at the moment it is installed) and register it's own handlers. These handlers can be asynchronous and can pause initialization.
On the other hand, do you have any pointer on how one could setup an async context config? Is there a way to halt the initialization? Maybe context.addConfigHandler? Thanks!
Sure thing! Have a quick read through the MessageDispatcher:
When you implement IContextConfig you are able to grab the context and add message handlers for the various context lifecycle phases (as declared in ManagedObject). You can make a handler asynchronous by giving it an asynchronous signature:
function asyncHandler(phase:String, callback:Function):void
{
// store the callback
// do some async stuff
// if everything worked out, call callback() with no arguments
// if there was an error, pass that error to the callback: callback(error)
// note: you MUST call the callback at some point or the process will never complete
}
There is more info on the async conventions here:
So, one approach is to implement IContextConfig, but that's usually just for extensions and bundles. If you want to create your own kind of configuration mechanism you can register a config handler with the ConfigManager. A config handler allows you to define what happens when a particular type of object or class is installed into a context (via the context constructor or via context.require()).
You might decide to handle any object that implements a particular interface and do something with it:
context.addConfigHandler(
instanceOf(ISomeType),
function(instance:ISomeType):void {
// do something whenever an object of this type is "required"
});
As with any message handler, the config handler can be asynchronous by having an asynchronous signature.
However, you need to make sure that your config handler is installed before any configs it needs to process are installed. Therefore you'd create an extension to install the config handler and pass that extension to your context at construction time:
_context = new Context(
MyConfigHandlerExtension, // installs a config handler that processes ISomeType instances
new MySpecialConfig("param")); // an instance that implements ISomeType
Anyhoo, most of that stuff is for advanced usage (extension design). If you outline your use case I can see if there is a simpler way to do it.
Reply all
Reply to author
Forward
0 new messages