Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
 | 1 | initial version | |
Hey there,
I'll don't close this question as duplicated cause you give here a compleet zul and controller.
I hope this is a "middlestep" of switching MVC to MVVM cause, and I'm really sorry to say, it's crappy code.
I'll start here with some suggestions what you can do. (I'll already started refactorring the zul and code but for the moment it's almost impossible without testing cause it's just to much).
I'm not shooting you but I hope I can teach you correct way's to handle the stuff.
Multiple declarations of vm's is no problem.
I have a problem with declaring a the same viewmodel multiple times.
If you need it more then once, you need to declare it higher in the tree.
Don't forget, each declaration gives you a new controller.
Secondly, when you have multiple vm's, Don't call them all "vm".
How do we know what vm you are pointing to (without searching the declaration)?
A label is normally a read only object. => Do not use @bind to set the value but @load. @bind is the shortcut for @load @save.
You just create overhead code when compiling.
Global variablen has to be scoped or they are package private in stead of class private.
You create the getters and setter so just add private before the declaration.
While I was trying to remove the the unused @wire vars, I saw that the labels where already used with the MVVM approach.
Still they are declared in your controller and do nothing.
It came worse when I was trying to search some vars like subtype.
They aren't in the zul so do you use the controller for multiple zuls or is this a forgotten deletion of refactoring?
If you succeed in that, you could change all the @Listen by adding in the zul onClick="@command('someCommand')" in the buttons they are referring to.<br/>
You can also set thevisible=@load(vm.buttonVisible)` and in stead of handling the button self, handle the boolean what's in the viewmodel.
With this you will also lower the usage of the wired button till you don't use the button.
Then it's time to remove the wired button out of the class.
I think you will not get at this point easy, but if all ○6@wireand@listenare removed, it's time to remove theextends SelectorComposer<component>.
Change in the zul the declaration of controller to declaration of viewmodel (and remove all the other declarations of same viewmodel).
When you stumble across problems changing to MVVM you can ask for help(just that part of zul and controller, maybe stacktrace), I'll help with pleasure but this is a little to big to do without the possibility of testing.
Greetz chill.
| | 2 | No.2 Revision |
Hey there,
I'll don't close this question as duplicated cause you give here a compleet complete zul and controller.
I hope this is a "middlestep" of switching MVC to MVVM cause, and I'm really sorry to say, it's crappy code.
I'll start here with some suggestions what you can do. (I'll already started refactorring the zul and code but for the moment it's almost impossible without testing cause it's just to much).
I'm not shooting you but I hope I can teach you correct way's to handle the stuff.
Multiple declarations of vm's is no problem.
I have a problem with declaring a the same viewmodel multiple times.
If you need it more then once, you need to declare it higher in the tree.
Don't forget, each declaration gives you a new controller.
Secondly, when you have multiple vm's, Don't call them all "vm".
How do we know what vm you are pointing to (without searching the declaration)?
A label is normally a read only object. => Do not use @bind to set the value but @load. @bind is the shortcut for @load @save.
You just create overhead code when compiling.
Global variablen has to be scoped or they are package private in stead of class private.
You create the getters and setter so just add private before the declaration.
While I was trying to remove the the unused @wire vars, I saw that the labels where already used with the MVVM approach.
Still they are declared in your controller and do nothing.
It came worse when I was trying to search some vars like subtype.
They aren't in the zul so do you use the controller for multiple zuls or is this a forgotten deletion of refactoring?
If you succeed in that, you could change all the @Listen by adding in the zul onClick="@command('someCommand')" in the buttons they are referring to.<br/>
You can also set thevisible=@load(vm.buttonVisible)` and in stead of handling the button self, handle the boolean what's in the viewmodel.
With this you will also lower the usage of the wired button till you don't use the button.
Then it's time to remove the wired button out of the class.
I think you will not get at this point easy, but if all ○6@wireand@listenare removed, it's time to remove theextends SelectorComposer<component>.
Change in the zul the declaration of controller to declaration of viewmodel (and remove all the other declarations of same viewmodel).
When you stumble across problems changing to MVVM you can ask for help(just that part of zul and controller, maybe stacktrace), I'll help with pleasure but this is a little to big to do without the possibility of testing.
Greetz chill.
| | 3 | No.3 Revision |
Hey there,
I'll don't close this question as duplicated cause you give here a complete zul and controller.
I hope this is a "middlestep" of switching MVC to MVVM cause, and I'm really sorry to say, it's crappy code.
I'll start here with some suggestions what you can do. (I'll already started refactorring the zul and code but for the moment it's almost impossible without testing cause it's just to much).
I'm not shooting you but I hope I can teach you correct way's to handle the stuff.
Multiple declarations of vm's is no problem.
I have a problem with declaring a the same viewmodel multiple times.
If you need it more then once, you need to declare it higher in the tree.
Don't forget, each declaration gives you a new controller.
Secondly, when you have multiple vm's, Don't call them all "vm".
How do we know what vm you are pointing to (without searching the declaration)?
A label is normally a read only object. => Do not use @bind to set the value but @load. @bind @bind is the shortcut for @load @save.
You just create overhead code when compiling.
Global variablen has to be scoped or they are package private in stead of class private.
You create the getters and setter so just add private before the declaration.
While I was trying to remove the the unused @wire vars, I saw that the labels where already used with the MVVM approach.
Still they are declared in your controller and do nothing.
It came worse when I was trying to search some vars like subtype.
They aren't in the zul so do you use the controller for multiple zuls or is this a forgotten deletion of refactoring?
If you succeed in that, you could change all the @Listen by adding in the zul onClick="@command('someCommand')" onClick="@command('someCommand')"to.<br/>
to.
You can also set thevisible=@load(vm.buttonVisible)` the visible=@load(vm.buttonVisible) and in stead of handling the button self, handle the boolean what's in the viewmodel.
With this you will also lower the usage of the wired button till you don't use the button.
Then it's time to remove the wired button out of the class.
I think you will not get at this point easy, but if all ○6@wireand@listenare removed, it's time to remove theextends SelectorComposer<component>.
Change in the zul the declaration of controller to declaration of viewmodel (and remove all the other declarations of same viewmodel).
When you stumble across problems changing to MVVM you can ask for help(just that part of zul and controller, maybe stacktrace), I'll help with pleasure but this is a little to big to do without the possibility of testing.
Greetz chill.
