I have seen various descriptions of how to handle movement in a component-based entity framework. The most common I've stumbled across is the idea of using components called Controller, Physics, Transform, Velocity, and Collider.
The idea here is that the Controller influences the Velocity component when movement keystrokes are detected. The Velocity component in turn influences Physics. Once the simulation has been stepped, the Collider is either affected if a collision occured or is not if no collision happened. In the end, the Transform is updated with the new position from the physics simulation step and thusly the Renderable needs to be adjusted so it is drawn in the proper location.
I have often read that one needs to consider both physics-driven and non-physics-driven entities. As outlined in the above paragraph, manipulating physics-driven entities seems like a piece of cake. The difference with non-physics-driven entities is that the Velocity component values need to simply be applied to the the Transform based on delta-time. This would allow moving the entity without being concerned with physics nor collision detection.
For physics-driven entities, one simply iterates entities with both Velocity and Physics components. But for non-physics-driven entities, simply iterating over entities with a Velocity component isn't sufficient as it would include the above subset as well.
So there must be some factor that clearly separates these two cases. So with these two cases in mind, how would movement actions that influence the values of Velocity be carried out in such a system to manipulate both types of entities whether physics plays a roll in their movement or not??
And lastly, considering that there may be times where the transform for an entity needs to be manipulated directly, such as player clicking on a portal to be teleported to another x/y/z position, how would one properly propagate this change to adjust both the physics step simultation and the renderable's draw location?
EDIT: @bobenko Your explanations provide insight to the most common case where objects are simulated via physics but I'm somewhat lost on the Kinematic aspect regarding updating an entities position via a velocity value? Are you simply implying that some code of my own will apply movement to the entity via velocity, thus being Kinematic? I still am interested in your explanation on how to avoid cyclic notifications effectively when aspects of these components involved change.
For all who answered, I'm still not clear how would you handle teleporting an entity from one position to another? Would this involve turning off physics, teleporting the player, then turning physics on after teleport finished? Turning physics on/off can be as simply as setting the entity as Kinematic YES/NO, right?