Doublestrike wrote:Hey Max, I'm going to knock out the final step of moving the deck editor into the UI. I'm aiming for a big commit after this release, so I'm starting soon.
Couple of questions - are you done with your work in that area? And, do you have any guidelines that I should take into consideration?
I haven't dug into it yet, but the basic idea is I'll be splitting into views and controllers, creating singletons as much as possible, and probably using the new tab framework for some fun surprises. I don't plan to modify code much, but there are probably some things I need to be aware of?
I am perfectly done with deckeditors by the moment. The only thing that remains is move pet selection into quest deck editor and store it inside a quest deck (a derived class from common deck)
I don't generally like an idea to create singleton views or controllers at all. A singleton of object factory is ok, but I never liked singletons for windows, views, panels and controllers. At least the actual editor works without singletons at all. Besides I don't like them, I don't have much power here to ban their impropper use, so it seems you'll proceed in your way. =(
If you are about to replace the view, then you should only keep the functionality of
public class DeckController<T extends DeckBase> that is your interface to deck storage, model in our case. This class incapsulates a reference to deck actually being edited and pushes it to storage only when 'save' is triggered (a previous implementation was editing the deck right in storage, not its copy, without a way to discard changes.)