I have the following structure (pretty much boilerplate). My question her is, are Mappings that I define in the ParentStack available in the ChildSTacks or would I need to duplicate them? I KNOW I can pass in Parameters to the ChildStack but was wondering if the Mappngs are implicitely passed to ChildStacks so I dont have to duplicaet them in each Child Stack?
ParentStack (Containing Mappings, Parameters)
ChildStack1
ChildStack2
No they aren't.
You can consider nested stacks as standalone stacks but their creation/update/deletion is orchestrated by the parent stack.
This limitation is usually easy to workaround by having the parent stack execute the FindInMap operation when passing down the parameters to the child stack.
Related
I'm building a class (sorry - Agent) that will work with a set of Tank objects (Fluid Library) - doing things like monitoring individual levels or total level of all tanks, reporting on levels and initiating actions based on levels - things of that nature. For argument's sake let's call it a "TankMonitor" agent.
Ideally I'd like to be able to define a Parameter in my "TankMonitor" agent that allows me to define the tanks of interest when I place a TankMonitor in main. I have tried to define the type of the parameter as Other - ArrayList<Tank> however I don't know how to set up the next step to allow me to populate the ArrayList of Tanks when I put an instance of this agent in main. My preference would be to have a list type control to populate the ArrayList - much like the way the AnyLogic Seize block allows you to specify multiple resource pools to choose from.
Has anyone attempted this before and been successful?
This is possible as follows:
Change the type to "Other" and then 'Tank[]' , i.e. an Array of Tanks
Change the control type to "one-dimensional array"
Example below. Now you have the same UI to pre-define tanks at design time for your agent instance.
In addition to Benjamin's perfect answer, I'd just add the manual workaround, which is not needed here but can be useful when the parameter in question has a more complicated structure than covered by the pre-made controls, say a list of lists, a map, or similar.
In such a case, the Control Type is still Text, and populating it in an instance happens by pointing it to a new object of the parameter's type. E.g. for an ArrayList<Tank> parameter, you might instantiate a new ArrayList object, which you fill with a list of objects like so:
new ArrayList<Tank>(Arrays.asList(tankA, tankB))
In the Java code, whatever is written into that text box will end up on the right side of a parameter assignment statement in the embedded Agent instance's auto-generated parameter setup function. Therefore, multi-statement code won't work in this spot. Instead, if the process of building the parameter value doesn't fit neatly into a single expression, you can hide the code in a function which returns the desired object, and call that from the parameter's text box.
Have a collection of cloudformation templates in a parent-child relationship and want to pass an AWS::IAM::Role into the parameters of a child stack and use GetAttr to get the Arn.
This fails validation because can only call GetAttr on resources, not on parameters.
Anyone know/guess why this is designed in this way?
It's not a problem as it can be worked around by just passing the Arn into the stack, I'm just curious really
What Fn::GetAttr and Parameters are trying to do in AWS CloudFormation is fundamentally different. As per AWS docs:
The intrinsic function Fn::GetAtt returns the value of an attribute
from a resource in the template.
[1] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-getatt.html
You can use the optional Parameters section to pass values into your
template when you create a stack. With parameters, you can create
templates that are customized each time you create a stack.
[2] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html
I believe your confusion is stemming from the fact that you're trying to think of this in terms of the object-oriented/some other programming paradigm, where Resources and Parameters are some kind of objects and Fn::GetAttr is a generic function which retrieves the value of a reference that's passed in as an argument.
In my case, I wanted to access the resource attributes like ARN and Name in the nested stack. If I pass resource string and use GetAtt to get these, I dont need to pass them as two parameters. With this limitation, I had to pass them as two parameters.
I would like to present the user with a variable number of scenes within the GUI (arranged say horizontally) composing different views of the data, depending on runtime conditions?
I really don't want to redefine the GUI, and a number of scene related traits for every use case. (i.e. bool_scene_1_viewable=Bool(), bool_scene_2_viewable=Bool()... )
It looks like I might be able to define a wildcard trait: scene_=Instance(Scene,()). But, if this is the best way to do it, how would I go about combining n traits into a View?
(A) I did not distinguish between "runtime" dependence, and merely depending on some number of traits that are declared after initialization (but before config_traits is called). As such, I can use default_traits_view to create a view that depends on the current state of the object and its members.
(B) I was also confused about how to turn this list_of_scenes into an object that could be viewed. After all, HGroup and VGroup don't take lists! I was missing that * could be used to unpack the list.
Steps:
1. init class instance
foo=Foo()
add scenes as you like
foo.add_trait(string_scene_name,scene)
foo.scene_name_list.append(string_scene_name)
foo.scene_list.append(scene)
Create group within default_traits_view()
items=[Item(name,style='custom') for name in self. scene_name_list]
scene_group=Group( *items)
In the 1.5.2.3 Defining a Binding Path section of OpenUI5 demokit:
A context exists either for each entry of the aggregation in case of aggregation binding or can be set explicitly for a control by using the setBindingContext method.
In the 1.5.3.3 Element Binding section of OpenUI5 demokit:
Element binding allows to bind elements to a specific object in the model data, which will create a binding context and allow relative binding within the control and all of its children.
It seems to me that the two techniques actually do the same thing. They both create a binding context for a control so that bindings of the containing controls will resolve relatively to it. But what's the difference between them? In what scenario will either of them come into play?
The setBindingContext doesn't work in the following code:https://jsbin.com/bigope/edit?html,output
However, if I change oPanel.setBindingContext("/nameinfo"); to oPanel.bindElement("/nameinfo");, it works, why?
setBindingContext requires you to pass a Context like this:
oPanel.setBindingContext(new sap.ui.model.Context(oModel, "/nameinfo"));
The difference between those two is conceptual.
The Binding Context is used as a parent context for all bindings (for that model) in that Control or its children. It only holds a reference to the used model, (a part of) the path and optional another parent context. It is used when creating relative bindings.
The bindElement method on the other hand behaves like every other bind* method.
It creates a binding (in this case, a ContextBinding) which allows change events, data binding, etc.
Additionally the created ContextBinding also serves as a BindingContext for other bindings, just like a Context added with setBindingContext would do.
Not confusing at all, right ;)?
Reading the code for ManagedObject might help you to understand the internals better. (bindObject = bindElement)
In my app, I have a presenter (Presenter1) which I use to kick off an Editor (EditorView1) which edits a Foo object. This MVP setup is akin to what is described in this answer, https://stackoverflow.com/a/10699346/565863
Now, let's say that I need to create another view (EditorView2 which is kicked off by Presenter2) which also edits a Foo object, but needs to make use of EditorView1.
EditorView1 would be supplied to EditorView2 by Presenter1.
This approach seems sloppy and error prone. Is there another way to do this?
As I was writing this question, I realized a much more clean approach.
The problem with what is described above is that I was intent on re-using the first Presenter, Presenter1.
It would be much cleaner to abstract out the Editor portion of the EditorView1 code into a re-usable Editor widget (Editor1) which could be used by both EditorView1 and EditorView2. Now, I have one presenter, one view, and one EditorDriver. There is no need to juggle nested presenters or multiple EditorDrivers.