Hello Brian,
If you want to use HiveMind to build a GUI application, you might consider
taking a look at the HiveGUI module of the HiveMind Utilities project on
SourceForge (http://sourceforge.net/projects/hivetranse/).
Cheers
Jean-Francois
-----Original Message-----
From: Brian K. Wallace [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 7:10 AM
To: [EMAIL PROTECTED]
Subject: Re: Bean Services with a twist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As an aside (or more likely, in direct support of this), I realized that
the problem, while noted with a Swing component, isn't applicable only
to those - trying to override a final method shouldn't be done in any
instance. I haven't investigated further, but that seemed like a place
where the bean creation should be more aware of 'final'.
Brian K. Wallace wrote:
| As I'm finding it easier and easier to utilize Hivemind at the core of
| my applications, I decided I'd try it in an alternate setting -
| Utilizing a pre-existing core configured with Hivemind, develop a Swing
| client as its UI interface. Right off the bat I found an issue that sent
| me back into the archives of this list (and onto the wiki,
| documentation, etc).
|
| While I'll admit I didn't see Hivemind used in such a circumstance
| previously, I had been looking at Spring's "RCP" to fill the role of
| allowing me to configure my clients. Here we are so many months later
| and no update on that project except to say "no update". And with my
| current usage of Hivemind in so many other circumstances, I figured I'd
| see what issues arose from its use in configuring my UI.
|
| Aside from a) creating a new object factory and b) manually configuring
| - is there implement the following configuration in Hivemind?
|
| ~ <service-point id="MenuBar" interface="javax.swing.JMenuBar">
| ~ <create-instance class="menu.CustomMenuBar"/>
| ~ </service-point>
|
| ~ <service-point id="ClientWindow" interface="ClientWindow">
| ~ <invoke-factory>
| ~ <construct class="ClientFrame">
| ~ <int>800</int>
| ~ <int>600</int>
| ~ <set property="titlePrefix" value="%client.title.prefix"/>
| ~ <set property="frameTitle" value="%client.title.default"/>
| ~ </construct>
| ~ </invoke-factory>
| ~ <interceptor service-id="hivemind.LoggingInterceptor"/>
| ~ </service-point>
|
| Keep in mind "ClientFrame" is a subclass of JFrame with a constructor
| taking two ints and JFrames have a method "setJMenuBar(JMenuBar
| menubar)". Autowiring of the menubar does attempt, but fails as the
| SingletonProxy attempts to override final methods.
|
| Note: In looking back to January/February messages on "why would you
| ever need a 'non-interface'?", my views were "you wouldn't". I think now
| that has changed as the amount of work outside the core classes to
| either a) access the menu bar prior to it being set or b) creating
| object factories simply to return a single object thereby negating ease
| of autowire would be negated if a concrete implementation were allowed.
|
| And forgive me if I'm overlooking something simplistic (even if it's
| "can't do it").
- ---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCfqpbaCoPKRow/gARAjghAKCYzqUVuxZZ8mkgZW0QslhstxzxkACeII6X
OBUFL0dfbkbktgDp0xG//GY=
=9v9x
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
