Re: [jplugin & swingx] Refactoring project status

tn5250j wrote, On 27/03/2003 10.57:
> Hello all
> 
> Finally got some time to start refactoring the krysalis code for the 
> projects jplugin and swingx that Nicola introduced the other day.

:-D

> Here is a status snapshot so far:
> 
> org.krysalis.dragonfly - not included
> 
> org.krysalis.imago - not included
> 
> org.krysalis.java - not included.  There have been no references to 
> these objects in the code.  Should they stay or should the go ?

Lwave it out then.

> org.krysalis.avalon - refactored to org.krysalis.jplugin.engine
> 
> org.krysalis.monarch - refactored to org.krysalis.jplugin.framework
> 
> org.krysalis.silk - refactored to org.krysalis.jplugin.components
> 
> org.krysalis.swallowtail - still exists at this time for testing but 
> only with a couple of the examples:
> 
> - still existing examples for testing framework
>    sheets.html
>    sheets.javahelp
>    sheets.text - also includes the NetBeans sheets.

+1

> org.krysalis.javax - refactored to org.krysalis.swingx
> 
> So far there are a few inter-dependencies that are posing some nice 
> opportunities for refactoring.

Yup.

>  From the concerns directory from the jplugin package is still there.
 >
> - AntiAliasing.java
> - Logginging.java
> 
> The concerns package modules now also exists in the 
> org.krysalis.swingx.concerns package.  Should this really stay in the 
> jplugin framework?

IMHO no.

BTW, what about Antialiasing? Is this the only way to do it? Is is 
something worth doing at all?

As for logging, should we remove it alltogether? Components can use 
Avalon logging, and the libraries should not have it anyway, no?

> So far for the gui component dependencies:
> 
>  From the org.krysalis.swingx.swing.splitter package
> - SplitterBar.java
> - SplitterLayout.java
> - SplitterSpace.java
> 
> These now reside also in jplugin.components.holders.splitter.  This 
> takes the cross dependency from the swingx packages.

See if you can put these only in swingx.

> JVerticalComponentBar is a really cool holder but am not sure that it 
> really belongs in the jplugin infrastructure.  It is being left for now 
> until feedback from you all.  It also has dependencies on JOutlookBar 
> from the swingx package.

I'm starting to see your point... and think also if one wants to use 
jplugin with SWT for example. I'm not sure, but how would we make 
holders without depending from a GUI library?

> SingleSheetActivatingHolder contains quite a few dependencies on swingx 
> at this time so will remain.  Have not gone deep enough to see what it 
> is used for yet.  Any ideas?  Am thinking at this time it is the main 
> sheet for the environment so probably should be moved to the swingx 
> package somewhere.

Well, these holders are part of jplugin, and this one is a holder that 
also uses the activation service to fire up a viewer every time an event 
of selection goes on the event system.

It seems that there are some design issues with the "holder" concept. 
What do you think?

> Actually now that this is being written it looks like all of the modules 
> in jplugin.components package really belong in the swingx package as 
> they are used to build the monarch gui interface and really have nothing 
> to do with a plugin per-sé.  This will also take care of the 
> AntiAliasing concern stated above.

Well, jplugin has sheets, holders, tools. These are coarse grained 
components that can be plugged-in. Each of the above are basically plugins.

The tools give the actions, the sheets the components, the holders the 
containers.

So if we create implementations of the above, we are making real life 
components. Coarse grained ones.

> Any ideas here or am I off base?

We need to hash out more precisely what we mean by swingx and jplugin ;-)

> The resources file for the avalon engine Boot module has been changed to 
> reflect the new module name references for the refactored items as 
> stated above.
> 
> Will be testing the build process a little later to make sure they all 
> build and run.

Very well.

> Well so far so good.  Not ready for CVS yet IMO until it actually builds 
> unless any of you guys really have the time to take a look at the code.

Ok, let's wait till it builds, and till we hash out the singx-jplugin 
divide.

IMHO swingx should be anything that does not use Avalon. Since holders, 
tools, sheets use Avalon, IMHO they are part of JPlugin. Dunno though, 
comments appreciated.

-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en