View with JTree on Left, TreeNode Properties on Right

Link is http://www.snpe.co.yu/snpepetclinic.tar.bz2
I'm sorry

Snpe,

Why do you need a setter for the window control? ApplicationWindow is a factory for its swing control (JFrame): I'd rather not make that mutable. The same concern apply's to a window's page: the page area should only manipulatable through the showPage method.

Can you subclass Window and Page to get what you need? There should be neccessary hooks. What do you need?

Keith,
I must change showPage in DefaultApplicationWindow - see my code in src
DefaultApplicationWindow is ugly - you have field control and local variable control in method
createWindowControl

I have to set my page and my control variable, because DefaultApplicationPage is not good for me - I don't show view in page - I show docking window layout

- I want that DefaultApplicationWindow call page with bean "applicationPage" in createPage method with default to DefaltApplicationPage like bean 'applicationWindow'

I can implement interface ApplicationWindow and don't extends DefaultApplicationWindow, too, but it isn't too smart

ApplicationWindow and ApplicationPage was better before change

If You want I can make this change

regards

Snpe,

Well, the vision is to make the Views themselves the dockable components. We may also introduce the concept of an "Editor" component, with a different lifecycle than a View (for example, one with explicit saving.)

Specifically the "ViewPanes" -- which are SimpleInternalFrames right now, by default, are what I envision to be dockable. We'd like to have multiple views per page, with the ApplicationPage class managing the individual views (tracking the active view, as well as the initial page layout.) This is similiar in concept to how Eclipse RCP works: and I think it's a solid design. Is there a chance you could fit into this model?

Here it is summed up:
- There is one Application per VM
- There are one or more ApplicationWindows per VM. Each window is realized by a JFrame component.
- There is exactly one ApplicationPage area for each window. Each page has a singleton ApplicationPageDescriptor, which encapsulates rules on how to initially layout that page using the ApplicationPageLayoutBuilder (this interface is really bare right now) In the future, we want to support remembering custom (changed at runtime) layout settings: e.g page-specific user preferences.
- Each ApplicationPage is defined by one or more dockable views declaratively placed in different areas of the page area (left, bottom, center, etc). A view is also defined by a singleton ViewDdescriptor. View instances may be stacked, tabbed, etc. The same view may be open on different pages in different windows--but only one view instance per view descripor is allowed per page.
- When views are added to a page, the page creates a ViewPane which manages the visual presentation of the View. Currently this is realized by a SimpleInternalFrame in the default implementation. The page also tracks and notifies of view lifecycle events: creation, focus gained, focus lost, destruction. The page caches view instances, and informs the views when they are activated/deactivated/disposed.

I hope this description helps! The design is MUCH better and more formalized than it was before.

Keith,
Can You add next, only:

- setter for control and page in DefaultApplicationWindow
- instantation ApplicationPage with 'applicationPage' bean in ApplicationWindow#createPage
- change reference like this.control and this.page with getControl() and getPage()

Docking window (infonode) have a lot features and it is possible make this with separate window and page
In fact, I don't need page, but I want integrate docking window in RCP

If you want I can make this changes or add new ApplicationWindow/Page implementations, for instance DockingApplicationWindow and DockingApplicationPage

regards

But again: ApplicationWindow and ApplicationPage are not to be made dockable. The Views and Editors are--what is contained on the pages. I think your best bet is to add the capability to ViewPane - replace SimpleInternalFrame with a docking-capable pane.

Keith,
It is possible, but it is ugly if I haven't getControl() and getPage() in ApplicatiionWindow interface.
What is reason that You avoid setter method ?

regards

Snpe,

ApplicationWindow is a factory for its containing control. That control is scoped by the window instance: created by it, managed by it, and never replaced outside of its control. I can think of no case to put a setter.

The same goes for an window's ApplicationPage. The page can be switched by using the showPage() method on the ApplicationWindow interface: however, the underlying page control and the details of building it/laying it out is kept hidden behind the ApplicationPage implementation.

We're clear the best place to add docking support is with the ViewPane implementation, and within the ApplicationPage implementations? Each ViewPane control should be dockable/stackable at various well-define points within the page area.

Keith,
I don't understand - in infonode, I have one Swing component (RoowWindow) and all dockable windows/views are in RootWindow (I can make more RootWindow, but it is separate part then and it isn't solution)
I want from DefaultApplicationPage/Window next :
- make JFrame with menu, toolbar etc, but nothing in contentPane
- I grab JFrame and add RootWindow (or RootWindows) in content pane and add views in
any area

regards

p.s
last changes is in cvs and I try again

Keith,
it is great now
maybe it is good inject ApplicationPage, but its is fine

regards