the only error is that when i go to the center the mesh rotate around itself is the gimbal lock?
It is not exactly an error. When the center is crossed during mouse movement, the value of phi jumps by 180 degree. That is intentional, because it gives you the same result as when moving from the start position to the end position in a half-circle. Remember that this implements an absolute control scheme, hence driving the mouse to a specific position should, for that position, yield in a result that is independent on the way you have used to reach the position.
As I said earlier, the inherent problem is that a 2D input device is used to control a 3D camera device. The 2 ways I've suggested above describe basic control schemes. To overcome shortcomings where possible, more a sophisticated control scheme need to be developed.
a question , is possible to do it with an a sphere and add the roll?
if you say yes i try.
for view the target object in all position.
Roll is not needed to see the object from all orbit positions. I would even say that adding roll to a manually controlled camera makes things "wonky". I would not do so. So now that we are finally speaking about the control scheme itself, what I could envision is a control scheme that
a) uses the current camera position as start,
b) constantly enforces a look-at to the object,
c) creates a heading with a little more than [-180°,+180°], using the horizontal mouse position for this,
d) creates a pitch with a little less than [-90°,+90°], using the vertical mouse position for this,
e) forces roll to be 0,
f) allows to change the orbit radius, e.g. when moving the up/down and pressing a key while doing so,
g) perhaps draws a little circle on the screen that serves as draggable gadget and indicator where the current orbiting is located in the phi/theta parameter space (and in the end also that orbiting mode is activated).
Question is still: What control scheme do you want?