Menu
▾
▴
Re: [Databionic-esom-devel] Java class discovery - BackgroundRenderers and ForegroundRenderers
|
From:
<fa...@in...> - 2005-04-28 07:51:16
|
Hi Thanassis, just adding my 5 (euro) cents. of course your code is welcome. i suggest you send patches to christian, for a start. maybe this is already a good point to start a new cvs branch. especially since we need to make some changes to the tool architecture for the upcoming musicminer program, that relies on the esom tools. @niko: can you start a dev branch, please? you idea of option panels provided by the background renderers in particular is something we have also discussed before. the RunDialog class, that is responsible for running the 'external' tools like training and projection, contains a mechanism to create render gui elements from an xml description. iirc weka has a similar mechanism, that came to my attention too late. maybe one of them or a combination thereof could be used for the bg renderers. as for the dynamic class discovery: it should work if you run "maven jar install" once, before continuing development with eclipse. but a more sophisticated mechanisme would'n hurt, i guess. bye fabian Christian Stamm wrote: > 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 >>> >> >> > > > > > ------------------------------------------------------- > 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 |
