Community
Participate
Working Groups
The following APIs are missing void setNavigationArgument(NavigationArgument argument); void removeContext(String key); Would be nice to add the methods in a future release.
I am hesitant about adding setNavigationArgument because the SubmoduleController does not get currently notified if an argument has changed. It only usually picks up the arguments when configureRidgets is called. I think it would be better if another navigate with a new NavigationArgument is used and only then is it possible to overwrite the navigationArgument in the submodulecontroller. Maybe we need then an event method in the submodulecontroller to notify it, that while the ridgets are all the same and hence configureRidgets is not called a new navigation has happened with a new argument. Manipulating the NavigationArgument in the context by using setContext is a potentially unsafe operation which might not work in future versions of Riena. (I know there is currently no other way, but this is something where you manipulate the "internals" of Riena.) We can add removeContext in the next version. Thats no real problem.
Then we need at least an API to specify an initial NaviagtionArgument when creating a new node. The point is that when an NaviagtionAssembler creates nodes, I need to specify an initial NaviagtionArgument the controller can work with. It differs from the behavior when I navigate to a node and supply an NavigationArgument. So I would recommend a new set of constructors with an additional NavigationArgument parameter. For example new SubModuleNode(NaviagtionNodeId id, NavigationArgument arg); new SubModuleNode(NaviagtionNodeId id, String label, NavigationArgument arg); new SubModuleNode(String label, NavigationArgument arg); We have to implement this over the whole hierarchy of nodeTypes. Easier and nicer is a setNavigationArgument() API at the abstract NavigationNode class with the maybe useful NavigationArgument changed event. The we can construct a new Navigationnode and can apply an navigationArgument. The event triggering in this case is not needed, because the node is about to be created. If you change the NavigationArgument later on, then maybe it makes sence.
Why dont you use the context when you want to pass a context relevant information to the submodule controller from the Assembler. The NavigationArgument was meant as a parameter from one controller to the other. The fact that the NavigationArgument is currently store in the context is a conincidence (an internal behaviour). I think it would make much more sense to use setContext and getContext in your usecase and only use the NavigationArgument for exchanging information between two controllers that involved in the navigation itself. That sounds like a much cleaner approach.
There are two spots in the Navigation circle to create/navigate nodes. One is the NavigationAssembler which can create and set a context value (and of course a NavigationArgument - but in the moment only via the direct context manipulation). The other one is a controller who initiates a navigation to a node. The controller can only pass the NavigationArgument. There is no way to apply a context value. So a possible controller has to react on two different ways to retrieve additional initialization data. That's not a practicable solution for me. Therefore I cant use the context. Maybe the name NavigationArgument is crab. But i need at least something (Initialization Data) that I can pass to a controller (initial on creation or via navigation).
so I think the way to go to allow in the navigate command to specify an initial context and have a removeContext method on the node. For that we drop the setNavigationArgument thing.
