Re: [Databionic-esom-devel] Java class discovery - BackgroundRenderers and ForegroundRenderers

[Christian S. <st...@Ma...>]

sorry for the repost, wrong reply address chosen...

Christian Stamm said:
> Hi Thanassis,
>
> nice to hear from you. Taking synergy from the Weka project surely sounds
> like a good idea, your code will be welcome. Can you give me a hint where
> I can learn more about the mechanism used in Weka?
>
> The foregroundrenderers had an auto load mechanism, which i removed, to
> make the software stable enough for a release. One of quite a few
> workarounds.
>
> Regarding the foregroundrenderers I had a different architecture in mind:
> As most foregroundrenderers require additional data like bestmatch
> classification, I moved most of them into the 'tool' and subpackages.
> The idea is to make the tools the automatically loaded plugins. The tool
> should know about how the data in question is created, modified, loaded,
> saved and displayed. (When talking about tools I mean classes derived from
> class AbstractTool.)
>
> The ToolLoader is at this time in the middle of a refactoring and uses two
> strategies to administer the tools. The old strategy is to know every tool
> explicitely the new is having them inside a toolhash. An automated loading
> mechanism is the goal. As the actual a state is of course no good, it is
> stable and therefore remained unchanged for the release.
>
> Regarding the backgroundrenderers, the actual solution is surely non
> optimal. I've been thinking about refactoring them in the way you
> suggested for quite a while, but there was always something more
> important. The main Renderer has lost and has to loose much more special
> knowledge than only this.
>
> Following picture gives you a hint on how the esomtools should ideally
> work:
> http://www.mathematik.uni-marburg.de/~stammi/esom/SomanaArchitecture.png
> where
> - 'external tasks' are training, projection etc.
> - 'core tools' are foregroundtool, renderertool and backgroundtool.
> - 'optional tools' are all other tools.
> - 'central data managment' is rather a TODO at this time, Project.java is
> used besides local solutions. Sadly the main renderer is still involved. A
> hash based datamanager is in the making.
>
> Hope this made things a little clearer. Please keep asking.
>
> mfg Christian
>
>
> Thanassis Stathopoulos said:
>> Hello everybody,
>>
>> I've been examining how the application discovers renderers (after
>> having
>> trouble running it in my Eclipse workbench) and noticed that it hits the
>> jar
>> file it was loaded from.
>> Examining the jar file for classes assumes that the jar is built already
>> there, which is not always the case.
>>
>> I would suggest adapting the run-time class discovery mechanism of the
>> latest Weka, which dynamically searches the classpath.
>> Then both renderer types could use automatic class discovery.
>>
>> Would the team be interested in integrating the proposed automatic class
>> discovery, if I code it?
>>
>> Another (architectural) point regarding renderers that require user
>> interaction, like Pmatrix and SmoothedHistogram - The renderers
>> themselves
>> could be providing custom panels to plug in to the appropriate frames,
>> instead of having the main renderer know about their names and the types
>> of
>> UI controls they use. Of course this is a bigger refactoring...
>>
>> Thanks,
>> Thanassis
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Databionic-esom-devel mailing list
>> Dat...@li...
>> https://lists.sourceforge.net/lists/listinfo/databionic-esom-devel
>>
>
>