[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] (no subject)
|
Hi Martin, thanks for your answer!
I would still want to re-use as much as possible from RSE, what would you suggest would be the "correct" way forward for me?
A host can have many targets and they can appear and dissapear dynamically. Should I handle each target as a "top-level" element and connect subsystems to them? What class should the target then implement and can I dynamically register subsystems on each target?
Best regards,
Tobias Södergren
-----Original Message-----
From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: den 15 september 2008 17:33
To: Target Management developer discussions
Subject: RE: [dsdp-tm-dev] (no subject)
Hello Tobias,
I have not checked in detail, but I'm afraid that in order to implement a structure like outlined by you, you won't be able to re-use the existing
FileServiceSubSystem
ProcessServiceSubSystem
classes.
I think the main problem is that in the SystemView code, which renders the tree, there are some assumptions made about the relationship of elements (i.e. stuff that can be adapted to an
ISystemViewElementAdapter) and their hierarchy.
As far as I can remember, the code does walk up/down the tree in order to associate such elements with a given subsystem, associate filters with filter references and so on. In your proposal, these assumptions about parent/child relationships are at least partially broken.
Long story short: Of course you can create your own subsystem and implement your own methods of getChildren(), adapter etc in order to return any structure you like.
But re-using the existing subsystem code (unchanged!) in such an environment is not specified, and unlikely to work ... feel free to try it out, and let me know if it works, but I'm guessing that you'd be running into trouble.
Allowing such re-use in the future is interesting, and there are existing discussions in that direction e.g.
[filters] Grouping filters across subsystems
https://bugs.eclipse.org/bugs/show_bug.cgi?id=164807
http://wiki.eclipse.org/DSDP-TM_Proposal_for_RSE_Hierarchy_by_Dave_Dykstal_2005x11x09
But I assume that such work will likely need changes in the extension point structure and most likely changes in the SystemView code (not even talking about the other views like TableView, Monitor).
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Tobias Södergren
> XT
> Sent: Friday, September 12, 2008 2:27 PM
> To: Target Management developer discussions
> Subject: [dsdp-tm-dev] (no subject)
>
> Hi TM gurus!
>
> I'm trying to understand how to implement the following tree:
>
> [Connection]
> ^---[SubSystem]
> ^---[Target 1]
> ^---[Processes]
> ^---Process 1
> ^---Process 2
> ^---[Remote files]
> ^---File 1
> ^---File 2
> ^---[Target 2]
> ^---[Processes]
> ^---Process 1
> ^---Process 2
> ^---[Remote files]
> ^---File 1
> ^---File 2
>
> I've got the Connection, SubSystem and Target working, but I'd like to
> reuse the AbstractFileService and ProcessService with complementary UI
> for the remote IRemoteFile and IHostProcess.
> I guess that there exist some UI/AbstractResource that operates on an
> IFileService implementation.
> I've implemented the AbstractFileService but I haven't found the way
> to create the tree above.
> Can/should I use an extension point and register something on the
> Target, should I implement
> getChildren() in my TargetResourceAdapter that returns an [Remote
> files] instance, or what?
>
> Any help is appreciated.
>
> Best regards,
> Tobias Södergren
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
