I figure out where “size” is coming from but It didn’t help as I still can’t use it.
Some more info:
1. In Page Configuration, Shared Settings: Framework/Breakpoint is called at the top docking.
a. Framework/Breakpoint is a Breakpoint Cointainer that has parameters. Also, it has small/large sizes due to its container type.
2. Framework/Breakpoint Embedded is called by Framework/Breakpoint
a. Its also a Breakpoint Container. The call is done in "small" breakpoint.
i. Gets the "Header/Header" path from its own parameter.
ii. It passes parameter "size" as a constant.
i. It directly calls Framework/Breakpoint Embedded
ii. Path is bind to its own parameter. It gets "Header/Header" the same way as the "large" size.
4. Framework/Breakpoint Embedded
a. The prop path is bind the same way as Framework/Breakpoint. Its the same for small and large sizes.
b. Both sizes pass (down?) "size" as a constant.
Plus I can see a behavior I cannot replicate from Shared settings.
That Docked View is able to call Framework/Breakpoint and pass Header/Header as a value. If a try that from a container I have to use one path for Framework/Breakpoint and myNewPath as a second parameter.
My only conclusion so far is that I cannot reuse the Framework folder for my own views because a Page is calling for a View and that View has nested views.
One path is to set the path for the Embedded View, which itself has a path parameter for its own embedded view. This is the expected behavior. It looks different from the docked view configuration dialog because you’re setting the path for the docked view in the drop down.
This has nothing to do with the folder structure at all, but is simply the way that “Framework/Breakpoint” view is setup. There is nothing preventing you from using the framework folder for your own views, or the views that are present in it for your own designs.
Obviously they originally designed the Breakpoint view to be used as a docked view.
Thank you for taking the time to read through this topic. I was wondering if I was expressing myself correctly.
You are right, nothing is preventing Framework/breakpoint to used as a container pointing to another view. I tested it many times using it with other views trying to replicate the responsive design that Header/Header has. I think at some point it worked but I accidentally erased that view. Now I’m trying to get there again in a logical manner rather than relying on luck.
As I understand now, if parameters have the same name, they can be passed down through many nested calls.
Let’s say myNewPath has custom parameters that should be exposed in Framework/Breakpoint. How can the parent be aware of the last child custom parameters?
My idea was to create many views with custom parameters for each one of them and show these parameters all the way up to the first call (Framework/Breakpoint).
Reading back through your second post, I think that you’ve missed interpreted some things.
The only parameters passed to the view are Path, breakpointLarge, and breakpointMedium.
The “Header” view’s size parameter would have to be set from where it is embedded. It seems like this is bound to the breakpoint container’s position.size property which would dictate if the embedded container was in the Large or Small breakpoint.
It appears that they are Embedding a breakpoint container in order to get 3 breakpoints, a breakpoint container by itself can only have a small and a large size, but by embedding a breakpoint container you can set it’s large size to the same as the small size of the parent and effectively have large, medium, and small containers.
As far as I am aware there is no notion of identically named parameters being passed down through many calls. In the example you have shown, the path parameter is sent to the view, inside that view (Framework/Breakpoint) there is undoubtedly an embedded view component which has its path property bound to self.view.params.path.
You have to specify the parameters at the Parent level in order for it to be aware of any child level parameters.
Here is a decent post that I think may help explain things a little better.