BUNDLE!

[Neil Manuell]

I thought I'd relate the solution to simple problem that my current project (RL1) threw at me today.

Now it really isn't anything new, in fact you've all solved it loads of ways, but I thought a formal approach 

might be a good idea.

Basically I took the idea of Bundles from RL2 and instead of using it to configure the extensions, I used 

the idea to map into to injector to configure the app depending on the data loaded.

My Bundles have a simple interface:

public function map(injector:IInjector):void

thus I had a BootstrapBundle

that called sub Bundles 

ModelBundle

ServiceBundle

DecoderBundle

StartupCmdBundle

DataAcquisitionCmdBundle

DataDecodeCmdBundle

and later have I have 

EnvironmentOneBundle

EnvironmentTwoBundle

EnvironmentThreeBundle

which are called and map different Views and Controllers depending on the environment indicated by the data.

I was wondering if there was any thought of an equivalent formalised approached for mapping application actors in RL2?

Have looked but couldn't find anything. What do you guys think.   

[pixels4nickels]

It seems like the new listeners on the context, along with guards and
hooks, could allow for this kind of "phased" context initialization.
I am too in need of doing some particular mappings after we get a few
pieces of data that are async driven. I was also thinking maybe this
is where the modularity stuff could be helpful except where you may
want to just "add" to the main context's mappings.

Okay..enough dribble from me. I will be watching this post.

-Ken

On Jan 26, 12:03 pm, Neil Manuell <flee...@gmail.com> wrote:
> I thought I'd relate the solution to simple problem that my current project
> (RL1) threw at me today.
> Now it really isn't anything new, in fact you've all solved it loads of
> ways, but I thought a formal approach
> might be a good idea.
>
> Basically I took the idea of Bundles from RL2 and instead of using it to
> configure the extensions, I used
> the idea to map into to injector to configure the app depending on the data
> loaded.
> My Bundles have a simple interface:
>
> public function map(injector:IInjector):void
>

> thus I had a *BootstrapBundle*
> that called sub Bundles
> *ModelBundle*
> *ServiceBundle*
> *DecoderBundle*
> *StartupCmdBundle*
> *DataAcquisitionCmdBundle*
> *DataDecodeCmdBundle*
> *
> *

> and later have I have

> *EnvironmentOneBundle*
> *EnvironmentTwoBundle*
> *EnvironmentThreeBundle*
> *
> *

[Alessandro Bianco]

Isn't this the case where the rules and the command flow should kicks in?
BUT I don't know if they are implemented yet...

--
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

[pixels4nickels]

Indeed. I think my big thing here is how to add to the main context
after a few commands kick off and return some goodies. And should the
state machine also be running the show by this point. Or do I attach a
child context using modularity and feed in my parent context? I have
to say I love all the possibilities due to the new way of thinking in
RL2.

-Ken

On Jan 26, 12:25 pm, Alessandro Bianco <cyberpun...@gmail.com> wrote:
> Isn't this the case where the rules and the command flow should kicks in?
> BUT I don't know if they are implemented yet...

> Il giorno 26/gen/2012 21:18, "pixels4nickels" <pixels4nick...@gmail.com> ha

[Shaun Smith]

Hi Neil,

I haven't got round to fleshing out all the documentation yet, but for the most part you can just use plain classes as config files in RL2:

class SomeConfig {

[Inject] public var something:Something;

[PostConstruct]

public function config():void

{

something.doStuff();

}

}

But, I might well be misunderstanding what you're wanting to do.

IContextConfig is only needed when you want more control. It allows you to hook in to the initialization process (actually, the whole context lifecycle) and possibly suspend and resume the flow:

class AsyncConfig implements IContextConfig {

public function configureContext(context:IContext):void

{

 if (context.initialized)

   throw new Error("This config must be installed prior to context initialization");

 context.addStateHandler(ManagedObject.PRE_INITIALIZE, handleContextPreInitialize);

 context.addStateHandler(ManagedObject.POST_INITIALIZE, handleContextPostInitialize);

}

private function handleContextPreInitialize(step:String, callback:Function):void

{

 trace("Doing some things before the context self initializes...");

 setTimeout(callback, 1000);

}

private function handleContextPostInitialize():void

{

 trace("Doing some things now that the context is initialized...");

}

}

Whenever a state handler accepts a callback the flow is suspended until the handler calls back (possibly with an error). It's worth noting that such a config will not be injected into, and that the context may still be uninitialized.

However, if you don't need this kind of fine-grained control, you can just pass a plain config class. Before context initialization all plain config classes are queued when installed. They are processed as a batch when the context initialises. Configs installed after initialization are processed immediately. This is all handled by the config manager. You can also write your own config handlers. For more info on how configs are processed see:

https://github.com/robotlegs/robotlegs-framework/blob/version2/src/robotlegs/bender/framework/configManager/readme.md

Hope that helps. Lemme know if I missed the point :)

[Neil Manuell]

Thanks Sean,

I guess that my main point is that when I shifted my injections out of the command classes and into my 

Bundles, it FELT better, as the intention and hierarchy was plain, Which I guess is part of the point of formalising processes.

I can map using Commands, or plain Helper classes, sure.

But if I use a (lets for arguments sake call it a ) IMappingBundle it signals purpose.

And I can do this anyway ( and will ), as it felt write for me.

For some reason I was sure that I had seen a IConfig somewhere in the RL2 code base, but of course its in flux

and stuff has been changing, and it might well have been a pre IContextConfig.

This isn't a biggy, but I thought I'd mention it.

[Shaun Smith]

No probs. I think using plain config classes is nicer than using commands, and having a concept of bundles is helpful in terms of grouping configurations together and having an organised package layout. So, I think we're on the same page :) I'm still not sure if your question has been answered though..

[Neil Manuell]

lol I wasn't really asking a specific question I guess.

perhaps it was this

"Have you thought about formalising the mapping of  actors into the context in RL2"

and I guess the answer is its not really a problem...?

[Shaun Smith]

I suppose I've thought much more about the mechanics than any sort of formalised.. um.. thingy. See, I'm not sure if you're asking about naming or package layout conventions.. or the timing of things. Package layout is a tricky thing to get right as there are two forces at play: package by layer vs package by feature. And then there are the layers inside the features.. It's just one of those things that is different for every project. Even when strong conventions are in place, like package by layer in Rails, projects usually get to a point where things are broken out into features (or separate apps) because the layers get too fat and messy - the features get lost. You can't package everything by feature because there are always cross-cutting concerns. Apologies if I'm still completely missing you! bear with me :)

[Neil Manuell]

No, no you are making sense.

I am answered, thanks :)

[Shaun Smith]

Heh, ok cool. I do think we need to offer something in the way of a package naming and bootstrapping conventions at some point. Prescription can be very helpful in the early stages of a project, or for developers new to the framework.

[Neil Manuell]

Well, that was sort of what I was thinking, just something light  andnot too prescriptive