Community
Participate
Working Groups
Users of WDSC would like the ability to group filters from different subsystems together (possibly under a folder). Here is some background email: David Dykstal/Rochester/IBM wrote on 11/15/2006 03:18:39 PM: > This is a complicated requirement. First, do you want just "file > like" subsystems, arbitrary subsystems picked by the user, > subsystems of the same type in general? Would this be a preference > that one sets once for the workbench or would this be something set > on a connection basis? Wouldn't it also make sense to group > connections together? After all, some of my resources may be > scattered over several systems. > > The mechanism chosen probably shouldn't be specific to "file" > subsystems since grouping could be useful for other types of resources. > > Anyway it sounds interesting, so its worth opening an "enhancement > request", but its a pretty big impact. The RSE system view tree > structure was supposed to be general but I think it makes some > assumptions about what's really at which level in the tree and how > to get from "parent" to "child" and vice versa. > > Requirements/suggestions of this nature should now be opened on > eclipse bugzilla not on project central. > _______________________ > David Dykstal > david_dykstal@us.ibm.com > > Violaine Batthish/Toronto/IBM@IBMCA > 11/15/2006 12:20 PM > > To > > Kushal Munir/Toronto/IBM@IBMCA, David Dykstal/Rochester/IBM@IBMUS > > cc > > Subject > > Fw: [WDSCI-L] Connection as 'project' > > Dave, Kushal, > > Would RSE consider allowng users to have filter for different > subsystems appear grouped together? > (Just trying to see if it worth opening a requirement) > > thanks, > > Violaine Batthish > WebSphere Development Studio Client, IBM Toronto Lab > > ----- Forwarded by Violaine Batthish/Toronto/IBM on 11/15/06 01:18 PM ----- > > Buck Sent by: wdsci-l-bounces@midrange.com > > 11/15/06 09:54 AM > > Please respond to > Websphere Development Studio Client for iSeries <wdsci-l@midrange.com> > > To > > wdsci-l@midrange.com > > cc > > Subject > > [WDSCI-L] Connection as 'project' > > I listened in to the same webinar that Jeff did, and I admit I never > thought of a connexion as a 'project' before. All my connexions are > named for the physical machine they attach to. > > So I figure I really ought to get modern, and use a connexion as a > project, with its own filter pool and all that. Of course, the project > I'm working on now involves C source in PASE (the IFS) as well as RPG > members in OS400. I didn't see a way to put the filter for my IFS files > adjacent to the filter for my RPG members (they are segregated by > 'object' type (i.e. iSeries Object vs IFS files.) > > Is there a way to organise a project like this so that all the related > 'objects' are together under a single filter/pool? > --buck
This is an interesting enhancement request. I think that in the end, we'll probably want to have very generic filters on EVERY level of RSE, even on the top-level (such that only particular hosts are selected; or, particular subsystems, from particular hosts are grouped together). I see two possible technical implementations: (A) Static top-level filters (like working sets) ------------------------------------------------ The UI representation of these higher-level filters could be similar to the Working Sets in the Eclipse Resource Navigator -- allowing to select them either - as a view option (View-Menu > Select Working Set) or - as top-level elements (View-Menu > Top Level Elements > Working Sets). Handling these top-level filters different than the lower-level filters would resolve issues of having nested filters, since the top-level filter would just be a shortcut to navigating to the lower-level filter but would not have any recursive impact on the lower-level filter. (B) Dynamic top-level filters through a more generic filtering mechanism ------------------------------------------------------------------------ Bug 160113 proposes a generic filtering language that could apply to any type of remote objects. This generic filtering language would allow to define top-level filters that evaluate to any selection of objects from any host or subsystem. The only problem I see with this is that it may be hard to find a proper UI represenation for the filter query creation dialog. Working Sets are much simpler in this respect. --- Maybe a combined solution of (A) and (B) is best - representing the top-level filters graphically as working sets, but implementing them through a query language under the hood.
FYI, bug #182343 has a somewhat related request to create filters without having to select a context first (e.g. File > New > Filter...) The problem with this is, that filters look extremely different depending on the subsystem they should act on. Therefore, such a request makes only sense with a generic filtering language. Deferring to the Future for now, and re-assigning to the inbox.
