Re: [jplugin & swingx] Refactoring project status

Nicola Ken Barozzi wrote:

>
> 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. 

Done

>
>
>> 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

Will we want to keep the names swallowtail.  I really like the themes of 
the apache projects or maybe I should say projects with themes.  jplugin 
and swingx are kind of plain :-)

>
>> 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? 

I think it should be up to the gui parts or gui theme to decide whether 
components should be antialiased or not.  Not the plugin in general.

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

Agreed.

>
>
>> 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. 

Was just trying this to see if we could get the dependencies to a lesser 
degree.

>
>
>> 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? 

This is where we should come up with some kind of contract between the 
plugin and the gui parts.  Example a checkbox the plugin know it wants 
to be a check box but should not know how to render a checkbox, nor say 
that it should be antialiased, nor what font it should use.  The gui 
knows how to render the interface and asks the plugin in what form 
should I display you.  The plugin says well I should be a checkbox and 
the gui says ok waves it's magic wand and poof you are now a checkbox.  
Also only the gui knows where it should display the checkbox. 

>
>> 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.

OK this is the fifth time am trying to answer this part.  What I am 
gathering here is that the jplugin will also provide a certain set of 
gui type components?  IMO it could provide a SingleSheetActiveHolder 
that would extend a JPanel that provides a certain set of functionality 
but up to the implementor of the plugin to provide a gui for it.  We 
could then go on and provide maybe define a "Role" for different types 
of Holders.  An example being ToolBarHolder or even better Doclets.

ToolBarHolder, extending JToolBar, would be a common interface used to 
define an extra type of toolbar to the interface.  Example being a macro 
plugin that plays the role of a Toolbar and provides buttons for Run, 
Pause, Stop, Record.  The macro would be self contained within this type 
of interface.  It will also export a set of configuration options called 
ConfigProps[] maybe or Tools[] that the gui interface calls to get a 
list of different options that are Configurable and maybe 
Savable/Storable.  The gui then provides a PropertySheet that displays a 
set of options that are fired when a ConfigProp[x].configureMe().  
ConfigureMe() then creates a PropertySheet specific to the ConfigProp to 
be displayed and/or validated.

DocletHolder, extending JPanel or JComponent, would be a common 
interface used to display an AS400 IFS File structure to the interface.  
Example being an AS400 IFSFileViewer.  This could be presented by a tab 
in a JTabbedPane new tab if the gui writer uses this or in a new JFrame 
or JDialog if the gui writer decided not to use a tabbed pane, also as a 
new tab on the JOutlookBar that swingx provides.  It depends on the gui 
to decide how to handle Doclets.  The configuration is the same as the 
ToolBarHolder.  The plugin would be selfcontained to display the IFS 
file structure and react with the user.  Here we could interact with the 
SingleSheetActivatingHolder if provided in the same way as the monarch 
gui does now.

Maybe I am mixing apples and oranges here.  Anyway just some ideas. 

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

Maybe not design issues per-sé but maybe a lack of abstraction between 
the view and how we define the interaction between the two.

>
>
>> 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. 

Yes they are plugins.  What I mean is they would be actual 
"Plugin"-nable Components" - ( I know pluginnable is not a word just 
using for emphasis) - using the jplugin framework.  Did this make 
sense?  My idea for the swingx would be a gui front end that provides 
these types of Pluggable interfaces if they are wanted.  Am I missing 
the point of what swingx would be in the end? 

>
>
> 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. 

Given but what if I as a plugin developer do not want to use the swingx 
real life components but only want to be able to interact with others 
based on a given contract that is provided, that being a plugin framework.

Maybe this is the reason nobody has come up with a generic framework 
because a plugin would be to specific a component to generalize.  Each 
vendor has there own types of plugins.  For instance the examples given 
above.  I know they are specific to the plugins that are being asked for 
in the emulator but also both could be used in other projects as well.

>
>
>> Any ideas here or am I off base?
>
>
> We need to hash out more precisely what we mean by swingx and jplugin ;-) 

:-) agreed.  Anybody else have any opinions here

>
>
>> 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.
>
Cheers


Kenneth



-------------------------------------------------------
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