Hi there, my name is Alex and i'm very interested in your framework. I'm still new to it tho.
I tried to seperate my application in 3 library (logic, model, view) and i found myself stuck with a cyclic reference problem with the logic and view part.
The view need the reference to the controller for the generics + view attribute. I fixed the view attribute by added a contructor that take a string instead of a type and afterwards
use the Type.GetType(string) method to assign the good type to the type field in the view attribute. (tho i loose typechecking on the view attribute at least there is no direct dependency toward the task in the logic library.
The other problem come from the generics where you inherit from the View<T> interface where T : IController interface. This directly connect the view with the controller making it impossible to put both in different library.
So if the controllers need to be in the same library as the views does this mean i still have some kind of problem implementing different presentation (winforms/webform etc..) with the same controllers. (would this mean i need to copy paste the code for the controllers for each presentation in their presentation package)
I still understand the need to the view to access the controller directly to redirect user call to the controllers but It seem Controller interfaces would be necessary and no dependency from the presentation to the controllers. (but still the generics inheritance would require a reference to the logic library in the view)
I just tought of it and it's possible having another library just with the controller interfaces will make the controller interfaces usable in both the view and logic.
Because the View<T> as a contraint on the iController interface, I just have to implement controller interface inheriting from the icontroller interface and use them in the
form: WinformFormView<T> declaration.
Dam there a constraint saying that it need to be a class in the View<T> dammit hehe
can i modify this???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dam there also the Taskmanager.StartTask that take a (Task type as input) still needed to add another startTask(string) method to remove dependency to logic.tasks.
still kinda a pain to have all those library hehe :)
Wonder what the best route to go, put everything in one package and be free of the MVC# dependency problem or ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The fact that the Types of task, controllers and views are use in the framework as key to generic dictionaries make removing view to controller dependency quite troublesome really.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before I start thinking of how to remove the dependency of views on controllers, I need to know: Why don't you like such dependency, and why do you want to eliminate it?
Controllers can be placed in a separate assembly, and you still can reference them from your views without any problem. Can't you?
Thank you for the question,
--
Oleg Zhukov
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there, my name is Alex and i'm very interested in your framework. I'm still new to it tho.
I tried to seperate my application in 3 library (logic, model, view) and i found myself stuck with a cyclic reference problem with the logic and view part.
The view need the reference to the controller for the generics + view attribute. I fixed the view attribute by added a contructor that take a string instead of a type and afterwards
use the Type.GetType(string) method to assign the good type to the type field in the view attribute. (tho i loose typechecking on the view attribute at least there is no direct dependency toward the task in the logic library.
The other problem come from the generics where you inherit from the View<T> interface where T : IController interface. This directly connect the view with the controller making it impossible to put both in different library.
So if the controllers need to be in the same library as the views does this mean i still have some kind of problem implementing different presentation (winforms/webform etc..) with the same controllers. (would this mean i need to copy paste the code for the controllers for each presentation in their presentation package)
I still understand the need to the view to access the controller directly to redirect user call to the controllers but It seem Controller interfaces would be necessary and no dependency from the presentation to the controllers. (but still the generics inheritance would require a reference to the logic library in the view)
I just tought of it and it's possible having another library just with the controller interfaces will make the controller interfaces usable in both the view and logic.
Because the View<T> as a contraint on the iController interface, I just have to implement controller interface inheriting from the icontroller interface and use them in the
form: WinformFormView<T> declaration.
Dam there a constraint saying that it need to be a class in the View<T> dammit hehe
can i modify this???
It's actually in the WinFormView<T> that T need to be a class, (can i remove this constraint)
Dam there also the Taskmanager.StartTask that take a (Task type as input) still needed to add another startTask(string) method to remove dependency to logic.tasks.
still kinda a pain to have all those library hehe :)
Wonder what the best route to go, put everything in one package and be free of the MVC# dependency problem or ...
It's actually in the WinFormView<T> that T need to be a class, (can i remove this constraint)
The fact that the Types of task, controllers and views are use in the framework as key to generic dictionaries make removing view to controller dependency quite troublesome really.
Hi Alex,
Before I start thinking of how to remove the dependency of views on controllers, I need to know: Why don't you like such dependency, and why do you want to eliminate it?
Controllers can be placed in a separate assembly, and you still can reference them from your views without any problem. Can't you?
Thank you for the question,
--
Oleg Zhukov