Re: [jplugin & swingx] Refactoring project status

tn5250j wrote, On 28/03/2003 18.17:
> Nicola Ken Barozzi wrote:

Geez, you are the first one that really dives into this.
I'm happy :-)

...
>> You see, the idea is that an app is constructed of Sheets, Tools and 
>> Holders.
>>
>> Sheets are of course heavily GUI-dependent, so they can be made with 
>> Swing, SWT, or whatever. ATM only Swing and AWT are supported, but SWT 
>> could be too in the future.
>>
>> Tools are basically and conceptually just actions. 
> 
> 
> When you say actions here what you mean are components that actually 
> generate the events to the Director?

All Components can publish events. But tools are elements that usually 
don't have a view, and usually depend on a sheet.

So menu items, tollbar items, etc.

> To recap what I am getting from this now is the following:
> 
> 1. A main working area that is a high level component - a JFrame for 
> instance lets call it WorkArea.

Ok.

> 2. The WorkArea has different regions that a plugin can extend.
>    - ToolBar - These would be Holders?

Yes. A Tool holder.

>    - MenuBar - These would be Holders?

Yes. A Tool holder.

>    - StatusBar - ?

A Sheet.

>    - Viewing area where all the views are - This would be referred to as 
> a Holder and in the monarch example would be SinglSheetActivatingHolder.

Yup.

>       - The holders then hold different views called Sheets

Yes.

>          - JOulookBar on the left is a Holder that holds holds Sheets 
> that are made up of Tools

Hmmm, nope. It holds Tools.

>          - The main viewing area is a Holder of JPanel which holds 
> Sheets that are made up of Tools.

Nope. It's a Holder of Sheets that can expose tools (and it's up to a 
tool holder to show them *if* there is at least one).

> 3. The sheets themselves are the plugins that provide the tools and 
> interactive events to the holders via the Director of the avalon engine 
> part.

The sheets are view plugins (plugins can also be only tools, like a 
printthepage tool plugin) that can provide tools. They are setup by any 
holder that requests them (the activating one does it based on the 
activation service) and can recieve and send events via the Director.

> Correct so far?

Almost ;-)

>> These two have to be composed in holders, and interact loosly using 
>> events in the directorService.
>>
>>  - Swingx should only keep simple swing widgets.
>>  - JPlugin only the basic framework and engine stuff.
>>  - (when JPlugin is kinda stable) we need a kind of swallowtail 
>> project that keeps JPlugin components that can be composed to make the 
>> programs.
>>
>> If we will need extra specification of roles we can do that. 
> 
> I guess by Role I meant it what region would the plugin try to extend.  
> Would it intereact with a Menu Bar or act like a Toolbar or be a View.

Aha, here is the point. The plugin does *not* know what reagion it will 
extend. It simply gives a service. It's up to the holders that are setup 
decide where (and if) to put them.

We can of course add hints.

>>>>
>>>> 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.
>>
>> Well, the holder contains one ot more views. That's it. Or not? 
> 
> Which are the sheets.

Yup.

>> The contract *between* plugins, tools, etc is in the DirectorService. 
> 
> There is the glue I need to be looking at.  Thanks.

Which BTW is *very* *loosly* coupled.

It simply passes an object, not an Event. It passes a reference to the 
file selected, for example, not the FileSelectedEvent. Dunno if it's the 
best thing or not.

>> Now that you say it, we should be sure that a plugin declares the 
>> events it needs or supplies in a descriptor, so we can plug them, and 
>> eventually create adaptors in the DirectorService between them. 
> 
> This was one of the topics I was referring to when mentioning about some 
> sort of contract with the gui.  A nice XML markup would be cool.

Yup.

>>
>> A cool way would be to make these events also be able to be done in 
>> XML and transformed in XSLT. Slow but simple ;-) 
> 
> Maybe not.  There should not be that many entries to parse.

It depends on how many events pass per second.

Anyway, it seems that we are getting very well synchronized, and you 
have already highlited cool points.

Cool! :-D

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