Hi Giovanni,
I absolutely understand what you mean. I recently refactored some Swing
GUI code and also tried to remove the circular references.
The menu bar of the app's main frame needed a reference to this frame in
order to show a modal dialog on it.
The frame embeds the menu bar and therefore references it.
And the menu bar references the frame to show a dialog on it when an
action is performed.
Fortunately, in Swing there is a method to find the frame which contains
the menu bar (or any component).
So I could remove the menu bar's reference to the frame. Instead I call
JOptionPane.getFrameForComponent(menuBar) to find the frame.
I also experienced some other circular dependencies which could not be
resolved directly. I decoupled some components using an EventBus, but
that is not always the right option.
Reagarding your case, if you had a menu panel and a content panel on the
same page and the menu's actions are responsible for switching the
content panel, the dependency cycle could be removed. But I don't think
this is a good solution for a web application. I'd rather stay with what
you have right now.
After doing some GUI refactorings, I went away with the opinion that
some code tends to need circular dependencies, especially in GUI code
this seems to be the case.
One should remove as much cycles as possible, but some are ok to keep.
That's my opinion, but I'm happy if someone can teach me better.
Regards,
Christian
Giovanni Cuccu schrieb:
Thanks for the response,
I try to clarify my point of view.
Before using wicket I don't remember that my classes were cross
references, I always paid attention that if class A references Class B
Class B can't reference Class A (even in imports).
After starting wicket development I've seen several cases of circular
references in my code. Since these circular references sometimes seem
natural (Page references MenuPanel and MenuPanel references Page) but
at the same time I consider the a "bad practice" I'm asking to myself
and to this list if someone had the same thoughts and what was the
conclusion.
What is your advice?
Should I relax my "best practice" about class circular referencing?
Should I code my Wicket app in a different manner?
Thanks,
Giovanni
It looks like you are looking for cohesion.
In the class menupanel.java I must reference PageXXXX
In the class PageXXXX.java I must reference MenuPanel
menupanel can to be an parameter to PageXXX; PageXXX can to be
abstract and
have an abstract method :
abstract protected Page
getPageToSetOnReturnOnCase1Case2And3(PossibleParameter p);
noted that in the examples there is a circular reference between
Checkout
page and Index page
on the example the objects has an reference to the other type class.
And the
class object do not has an reference those objects. I don't see it as
circular reference.
Are circular references unavoidable with Wicket?
do they are unavoidable in java, in object oriented paradigm? Is this
the
correct question?
Is there a best practive to avoid this situation?
When I avoid an circular reference, I make a choice between a several
possible solutions, the on I get depends on the class objectives
On Wed, Sep 23, 2009 at 7:21 AM, Giovanni Cuccu
<giovanni.cu...@cup2000.it>wrote:
Hi all,
I'm developing a wicket application and I'm facing a problem.
I built a menupanel that shows the menu to access the various
aplication
pages; since the panel needs to show the pages it contains a list of
links
that when clicked simply do the the following
setResponsePage(new PageXXXX());
In the class menupanel.java I must reference PageXXXX
In the class PageXXXX.java I must reference MenuPanel
At the end I have a circular reference between manupanel and the
various
PageXXXX and I don't like it.
While reading wicketInAction I noted that in the examples there is a
circular reference between Checkout page and Index page. Are circular
references unavoidable with Wicket? Is there a best practive to
avoid this
situation?
Thanks,
Giovanni
--
Giovanni Cuccu
Via del Borgo di S. Pietro, 90/c - 40126 Bologna
e-mail: giovanni.cuccu _at_ cup2000.it
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org