I feel insulted from this answer for good reasons:
Obviously it is not guaranteed that "
getApplication() does not return null ", since it does return null in some circumstances. "
You should not " is contradictory with "
is guaranteed "!
If "
You should not call attach/detach manually. ", then, make them private. Access modifiers are there pretty much for self explanatory design
Calling detach(), attach() looks like a ligitimate way to update the object instead of making another one, since the object doesn’t respond client side to requestRepaint() and whatever else I tried.
I think attach() and detach() are to be used mostly internally and your code should not use them directly.
What you need to do is layout.removeComponent(c) and layout.addComponent(c) which will call automatically detach() and attach() respectively.
When attach() and detach() are called in the normal way, getApplication() does not return null. When they are used for other purposes, it may not but is not supported.
public void resetText() {
// TODO: this null check should've happened internally, in the
// LoginForm, it's bound to change in the future
// if (getApplication() != null) {
AbstractOrderedLayout layout = (AbstractOrderedLayout) this.getParent();
layout.removeComponent(this);
// detach();
setUsernameCaption(Lang.getMessage("USERNAME"));
setPasswordCaption(Lang.getMessage("PASSWORD"));
setLoginButtonCaption(Lang.getMessage("AUTHENTICATE"));
layout.addComponent(this);
// attach();
// }
}
In my opinion, if attach() and detach() are to be used
mostly internally, but not always, someone should write a small article covering the excepting cases for reason why it isn’t made private, and put it in the method doc
P.S.
Sorry for being so bloody, but I’m working for food over here, and I’m bitching every time I think someone makes slip from good practice, while bribing their way into a quadruple wage or more… it’s getting to be a habit :vader:
The methods attach() and detach() are public because internal implementations of components containing other components (primarily layouts) need to call them. They are also public because a Java interface (Component in this case) only allows you to specify public methods. If not for these reasons, they could technically be protected and still be possible to override.
This said, the javadoc for the methods could be clearer, although it does state “The caller of this method is setParent(Component) if the parent is itself already attached to the application. …”
In developing a framework, it is always a balancing act between making things extensible even where the need is not anticipated, but keeping internals closed up enough that it is actually possible to make some changes in the framework without breaking all applications. Furthermore, we framework developers are human beings and make bad choices from time to time, and much of the code is quite old.
In developing a framework, it is always a balancing act between making things extensible even where the need is not anticipated
When I’m developing my application, my philosophy is to make everything private but the access point to the behaviour I want (encapsulation), because I’m pretty sure I’ll be the one making the changes in my application, and nobody else will reuse my classes but myself.
However, in a framework the philosophy should be inverse; every functionality that has a potential use to the client of that framework should be public, so there’s no need to anticipate anything really. I can’t contradict right now on the public status of attach/detach being impossible to make private, but I haven’t had trouble 'till now with applying patterns and good practice in java, as in being obligated to make something public that shouldn’t.
Also, in this case, I don’t know the internals, but if I did I could tell which is better for me, using detach/attach or remove/add(component)… this looks like a task for later.
My point is if I discover I have a gain using detach/attach I will even use reflection to use this functionality. I found 2 functionalities before that should’ve been public, and had to break into with reflection or find a more complex workaround that it was needed.
In conclusion, it is easier to follow an easy philosophy than to complicate things.
I’m speaking from the experience of my application that is big enough so I can’t remember all of it at once (has reached a certain maturity) and so I need to apply principles that let code speak for itself, and so I learned from need some good practice and design
Out of curiosity, what software development methodologies do you use? Initially I felt that Vaadin development is following a lead architect, but then he seemed to have gone missing after setting the initial girders of the framework in place