Menu
▾
▴
springframework-rcp-dev
|
From: Andy D. <an...@ma...> - 2004-05-19 17:52:26
|
With Spring RCP being so new, it appears the only documentation is the source. :-) So, after reading the source, let me see if I'm getting the idea (btw, I don't have any experience with Eclipse, so any concepts spring-rcp borrows from Eclipse I've learned only through spring-rcp source). If I'm getting this wrong, please let me know. An Application consists of one or more windows (ApplicationWindow), managed by WindowManager. An application has at least one window (a main window). A Window displays a single page (ApplicationPage) at a time. A page contains a View registry. This means a Page can contain multiple Views. So, if my application's main window consists of a single Page (which is really the only option, right?), then I can swap out the contents of the main window by swapping pages? I'm guessing an example of this would be "workbenches" in the IDE world? For example, if I am in Edit mode, then I have several views open on my page: maybe a folder view, an edit view, and an output view. In Debug mode, I have a "watches" view, breakpoint view, source code view, stack view, etc. With this understanding, I'm having trouble figuring out where the Perspective class fits in, as it seems to be a one-to-one relationshipship with a View (though it is by the view's ID and not a reference to a View itself). OK. On to Actions. In rcp, you have VisualActions and ActionHandlers. A VisualAction defines only the visual representation and keyboard access (menu item, toolbar item, icon, text, mnemonic, accelerator, etc). The actual functionality of the action is provided separately in an ActionHandler. Actions are registered in a global ActionRegistry, and ActionHandlers are registered with views (via the ViewContext). Well, I guess it is also possible to associate an ActionHandler directly with an Action (for those actions that are not view dependent). So, when a View becomes active, spring-rcp will query the view against every registered global Action to see if that View provides an ActionHandler for the Action. This means that the functionality of a particular Action can be dynamically implemented per-view (kinda cool, actually). It looks like for this to work, your Actions must also implement TargetableVisualAction (which is implemented by DefaultVisualAction). The org.springframework.rcp.action.contribution package seems to be all about building menus and toolbars. I'm not sure I have this right, since I haven't played around with it. Since an Application can present the user with multiple ways to do actions (menus, toolbars, pop up menus. etc), spring-rcp provides an abstraction that allows you to group such actions logically and automatically represent that group as any of these more concrete implementations. So, a ContributionItem is an abstraction on top of a menu item, toolbar button, etc and a ContributionItemManager is an abstraction on top of a menu bar, toolbar set, etc. ContributionItemManager allows you to group ContributionItems (via group id) - each group becoming a different menu along a menubar, or a different toolbar in a toolbar set(?) I'm not too sure about this actually. ContributionItem seems similar in many ways to an Action... but I guess it needs to be different because some menu items (such as seperators) are not actions? In fact, ActionContributionItem seems to be no more than a wrapper (adapter) that makes an Action look like a ContributionItem. A ContributionItem can create menu items and toolbar controls just like an Action can. Some questions on my exploration of the source so far: What is the preferred way for creating/configuring controls from spring-rcp? I don't see a common Page interface... it looks like dialogs get their own idea of what a page is and windows get another. Is this intentional? Well, that's about all the further I've gotten so far. BTW, if anyone has any example configuration files used with spring-rcp, I'd love to see them. Thanks, Andy |
|
From: Keith D. <kd...@cs...> - 2004-05-19 18:25:04
|
Yes, documentation is lacking. That will be improving as the design of = the undocumented features stabalize, and certainly before we release = anything. Nice description btw, here are my observations: - Yes there is a single "Application" per rcp-app. The application has associated with it a default perspective, where a perspective provides a configuration 'template' for a application page. (Note: the application, however, can have multiple perspectives defined. Each perspective, when opened, is displayed on a single page within an application window. = There can be multiple application windows per application, each with it's own menubar/toolbar/statusbar and page area.) =20 - When the application launcher initializes the application, the main = window definition is retrieved from the context. The window is then configured = - this is where the *.contribution stuff comes in -- consisting of its menubars, toolbars, page, and status line. The *.contribution stuff provides factories (higher-level abstraction) for producing menu items, = tool bar buttons, and status line items, for example. Group markers, as you mentioned, allow you to create logical groups of contribution items, so custom views can contribute their own actions to those groups when they = are activated. - You are entirely correct about the View behaivior. When a view is activated, it is handed a context which provides information about the window it's displayed on and allows for the view to register local = action handlers with global actions. This keeps, for example, the "Delete" = action invoking the right code based on the active view - assuming two = different views both support "Delete" and they do different things... Check out ComponentFactory for creating controls. I will forward some samples to the list this weekend (unfortunately I can't right now as I = need to remove some stuff first.) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Andy Depue Sent: Wednesday, May 19, 2004 1:52 PM To: spr...@li... Subject: [Springframework-rcp-dev] Am I getting the idea? With Spring RCP being so new, it appears the only documentation is the=20 source. :-) So, after reading the source, let me see if I'm getting the idea=20 (btw, I don't have any experience with Eclipse, so any concepts = spring-rcp=20 borrows from Eclipse I've learned only through spring-rcp source). If = I'm=20 getting this wrong, please let me know. An Application consists of one or more windows (ApplicationWindow), = managed by=20 WindowManager. An application has at least one window (a main window). = A=20 Window displays a single page (ApplicationPage) at a time. A page = contains a=20 View registry. This means a Page can contain multiple Views. So, if my = application's main window consists of a single Page (which is really the only=20 option, right?), then I can swap out the contents of the main window by=20 swapping pages? I'm guessing an example of this would be "workbenches" = in=20 the IDE world? For example, if I am in Edit mode, then I have several = views open on my page: maybe a folder view, an edit view, and an output view. = In=20 Debug mode, I have a "watches" view, breakpoint view, source code view, stack=20 view, etc. With this understanding, I'm having trouble figuring out = where=20 the Perspective class fits in, as it seems to be a one-to-one=20 relationshipship with a View (though it is by the view's ID and not a=20 reference to a View itself). OK. On to Actions. In rcp, you have VisualActions and ActionHandlers. = A=20 VisualAction defines only the visual representation and keyboard access (menu=20 item, toolbar item, icon, text, mnemonic, accelerator, etc). The actual = functionality of the action is provided separately in an ActionHandler. = Actions are registered in a global ActionRegistry, and ActionHandlers = are=20 register7ed with views (via the ViewContext). Well, I guess it is also=20 possible to associate an ActionHandler directly with an Action (for = those=20 actions that are not view dependent). So, when a View becomes active,=20 spring-rcp will query the view against every registered global Action to = see if that View provides an ActionHandler for the Action. This means that = the=20 functionality of a particular Action can be dynamically implemented = per-view (kinda cool, actually). It looks like for this to work, your Actions = must=20 also implement TargetableVisualAction (which is implemented by=20 DefaultVisualAction). The org.springframework.rcp.action.contribution package seems to be all about=20 building menus and toolbars. I'm not sure I have this right, since I haven't=20 played around with it. Since an Application can present the user with=20 multiple ways to do actions (menus, toolbars, pop up menus. etc), = spring-rcp provides an abstraction that allows you to group such actions logically = and=20 automatically represent that group as any of these more concrete=20 implementations. So, a ContributionItem is an abstraction on top of a = menu=20 item, toolbar button, etc and a ContributionItemManager is an = abstraction on top of a menu bar, toolbar set, etc. ContributionItemManager allows you = to=20 group ContributionItems (via group id) - each group becoming a different menu=20 along a menubar, or a different toolbar in a toolbar set(?) I'm not too sure=20 about this actually. ContributionItem seems similar in many ways to an=20 Action... but I guess it needs to be different because some menu items = (such as seperators) are not actions? In fact, ActionContributionItem seems = to be no more than a wrapper (adapter) that makes an Action look like a=20 ContributionItem. A ContributionItem can create menu items and toolbar=20 controls just like an Action can. Some questions on my exploration of the source so far: What is the preferred way for creating/configuring controls from = spring-rcp? I don't see a common Page interface... it looks like dialogs get their = own=20 idea of what a page is and windows get another. Is this intentional? Well, that's about all the further I've gotten so far. BTW, if anyone has any example configuration files used with spring-rcp, = I'd love to see them. Thanks, Andy ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now = for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev |
|
From: Keith D. <kd...@cs...> - 2004-05-19 18:41:14
|
Got 'em together; attached are some sample context configuration files. Keith =20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Keith Donald Sent: Wednesday, May 19, 2004 2:25 PM To: 'Andy Depue' Cc: spr...@li... Subject: RE: [Springframework-rcp-dev] Am I getting the idea? Yes, documentation is lacking. That will be improving as the design of = the undocumented features stabalize, and certainly before we release = anything. Nice description btw, here are my observations: - Yes there is a single "Application" per rcp-app. The application has associated with it a default perspective, where a perspective provides a configuration 'template' for a application page. (Note: the application, however, can have multiple perspectives defined. Each perspective, when opened, is displayed on a single page within an application window. = There can be multiple application windows per application, each with it's own menubar/toolbar/statusbar and page area.) =20 - When the application launcher initializes the application, the main = window definition is retrieved from the context. The window is then configured = - this is where the *.contribution stuff comes in -- consisting of its menubars, toolbars, page, and status line. The *.contribution stuff provides factories (higher-level abstraction) for producing menu items, = tool bar buttons, and status line items, for example. Group markers, as you mentioned, allow you to create logical groups of contribution items, so custom views can contribute their own actions to those groups when they = are activated. - You are entirely correct about the View behaivior. When a view is activated, it is handed a context which provides information about the window it's displayed on and allows for the view to register local = action handlers with global actions. This keeps, for example, the "Delete" = action invoking the right code based on the active view - assuming two = different views both support "Delete" and they do different things... Check out ComponentFactory for creating controls. I will forward some samples to the list this weekend (unfortunately I can't right now as I = need to remove some stuff first.) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Andy Depue Sent: Wednesday, May 19, 2004 1:52 PM To: spr...@li... Subject: [Springframework-rcp-dev] Am I getting the idea? With Spring RCP being so new, it appears the only documentation is the=20 source. :-) So, after reading the source, let me see if I'm getting the idea=20 (btw, I don't have any experience with Eclipse, so any concepts = spring-rcp=20 borrows from Eclipse I've learned only through spring-rcp source). If = I'm=20 getting this wrong, please let me know. An Application consists of one or more windows (ApplicationWindow), = managed by=20 WindowManager. An application has at least one window (a main window). = A=20 Window displays a single page (ApplicationPage) at a time. A page = contains a=20 View registry. This means a Page can contain multiple Views. So, if my = application's main window consists of a single Page (which is really the only=20 option, right?), then I can swap out the contents of the main window by=20 swapping pages? I'm guessing an example of this would be "workbenches" = in=20 the IDE world? For example, if I am in Edit mode, then I have several = views open on my page: maybe a folder view, an edit view, and an output view. = In=20 Debug mode, I have a "watches" view, breakpoint view, source code view, stack=20 view, etc. With this understanding, I'm having trouble figuring out = where=20 the Perspective class fits in, as it seems to be a one-to-one=20 relationshipship with a View (though it is by the view's ID and not a=20 reference to a View itself). OK. On to Actions. In rcp, you have VisualActions and ActionHandlers. = A=20 VisualAction defines only the visual representation and keyboard access (menu=20 item, toolbar item, icon, text, mnemonic, accelerator, etc). The actual = functionality of the action is provided separately in an ActionHandler. = Actions are registered in a global ActionRegistry, and ActionHandlers = are=20 register7ed with views (via the ViewContext). Well, I guess it is also=20 possible to associate an ActionHandler directly with an Action (for = those=20 actions that are not view dependent). So, when a View becomes active,=20 spring-rcp will query the view against every registered global Action to = see if that View provides an ActionHandler for the Action. This means that = the=20 functionality of a particular Action can be dynamically implemented = per-view (kinda cool, actually). It looks like for this to work, your Actions = must=20 also implement TargetableVisualAction (which is implemented by=20 DefaultVisualAction). The org.springframework.rcp.action.contribution package seems to be all about=20 building menus and toolbars. I'm not sure I have this right, since I haven't=20 played around with it. Since an Application can present the user with=20 multiple ways to do actions (menus, toolbars, pop up menus. etc), = spring-rcp provides an abstraction that allows you to group such actions logically = and=20 automatically represent that group as any of these more concrete=20 implementations. So, a ContributionItem is an abstraction on top of a = menu=20 item, toolbar button, etc and a ContributionItemManager is an = abstraction on top of a menu bar, toolbar set, etc. ContributionItemManager allows you = to=20 group ContributionItems (via group id) - each group becoming a different menu=20 along a menubar, or a different toolbar in a toolbar set(?) I'm not too sure=20 about this actually. ContributionItem seems similar in many ways to an=20 Action... but I guess it needs to be different because some menu items = (such as seperators) are not actions? In fact, ActionContributionItem seems = to be no more than a wrapper (adapter) that makes an Action look like a=20 ContributionItem. A ContributionItem can create menu items and toolbar=20 controls just like an Action can. Some questions on my exploration of the source so far: What is the preferred way for creating/configuring controls from = spring-rcp? I don't see a common Page interface... it looks like dialogs get their = own=20 idea of what a page is and windows get another. Is this intentional? Well, that's about all the further I've gotten so far. BTW, if anyone has any example configuration files used with spring-rcp, = I'd love to see them. Thanks, Andy ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now = for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now = for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=CCk _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev |
|
From: Andy D. <an...@ma...> - 2004-05-24 17:17:46
|
As mentioned previously, I'm currently developing a rich client. One of the things this rich client must do is present to the user a unified UI that is composed of information from various services. For example, an employee's salary might come from the payroll service, while the employee's security roles will come from the security service. To the end user, it is all one unified front, while in reality there are many back end services that need to be called into and managed. On top of that, the UI must be dynamic... not all users will be allowed to see an employee's salary or their security information, in which case I don't need to waste the bandwidth gathering this information (anyway, I would get a security exception if I tried). I'm guessing this could be a fairly common issue in rich clients: building a UI that is a composite of many POJO DTOs from many different services. What I would like is the ability to dynamically compose "logical objects" at runtime that are a composite of actual POJOs from various services. For example, a logical "employee" object might contain a salary field from the payroll service, a securityRoles field from the security service, a name field from the HR service, and so on. After digging around a bit, I discovered the Service Data Objects specification from IBM+BEA (which has now been made into a JSR). This specification seems to address this very issue. I'm wondering if it would be worth the effort to offer any kind of integration with this spec in the spring-rcp project? Of course the spec is very new and still evolving, but when has that ever stopped open source? :-) More details can be found here: Original Spec: http://dev2dev.bea.com/technologies/commonj/sdo/index.jsp JSR 235: http://www.jcp.org/en/jsr/detail?id=235 theserverside.com discussion: http://theserverside.com/news/thread.tss?thread_id=22646 |
|
From: Andy D. <an...@ma...> - 2004-05-19 19:07:13
|
Thank you for your quick response! I saw ComponentFactory, which caused me to realize I'm probably approaching this from the wrong angle. I can't get the idea out of my head that what I want to do is code only functionality in Java code (in other words, code only ActionHandlers and any custom GUI components), but avoid writing a drop of glue code (Pages, Views, Wizards, etc). Instead, I want to glue things together using IoC: create components, configure them, assemble them into views, pages, dialogs, wizards, etc, into a final Application. Maybe this is where my encounter with SwiXML could come in: define views (or pages?) using some form of XUL, and configure the components used into those views/pages using IoC (Spring). It seems like an intruguing idea that rich client pages could be loaded from a server in much the same way that HTML pages are loaded from a server (though this could be optional, of course... just include the XUL and Spring XML in a .jar instead). Say you have an object in your GUI that brings up a menu when right-clicked, and one of those menu actions pulls up a dialog for editing the object... if there was the option to have that dialog page served up XUL style, then I could customize that page dynamically on the server-side - thus keeping more of the code on the server side and making the client a little bit thinner. Someone in the manager role might get a different page than someone in the ceo role, for example. Another way to say it: what I want to do is code only application building blocks in Java (actions, components, etc), and then dynamically construct those building blocks into a final application at run time. This way, I could dynamically generate XML from my server that defines the application at run time. This would create a slightly thinner rich client. - Andy On Wednesday 19 May 2004 11:24 am, Keith Donald wrote: > Yes, documentation is lacking. That will be improving as the design of the > undocumented features stabalize, and certainly before we release anything. > > Nice description btw, here are my observations: > > - Yes there is a single "Application" per rcp-app. The application has > associated with it a default perspective, where a perspective provides a > configuration 'template' for a application page. (Note: the application, > however, can have multiple perspectives defined. Each perspective, when > opened, is displayed on a single page within an application window. There > can be multiple application windows per application, each with it's own > menubar/toolbar/statusbar and page area.) > > - When the application launcher initializes the application, the main > window definition is retrieved from the context. The window is then > configured - this is where the *.contribution stuff comes in -- consisting > of its menubars, toolbars, page, and status line. The *.contribution stuff > provides factories (higher-level abstraction) for producing menu items, > tool bar buttons, and status line items, for example. Group markers, as > you mentioned, allow you to create logical groups of contribution items, so > custom views can contribute their own actions to those groups when they are > activated. > > - You are entirely correct about the View behaivior. When a view is > activated, it is handed a context which provides information about the > window it's displayed on and allows for the view to register local action > handlers with global actions. This keeps, for example, the "Delete" action > invoking the right code based on the active view - assuming two different > views both support "Delete" and they do different things... > > Check out ComponentFactory for creating controls. I will forward some > samples to the list this weekend (unfortunately I can't right now as I need > to remove some stuff first.) > > Keith > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf Of > Andy Depue > Sent: Wednesday, May 19, 2004 1:52 PM > To: spr...@li... > Subject: [Springframework-rcp-dev] Am I getting the idea? > > > With Spring RCP being so new, it appears the only documentation is the > source. :-) So, after reading the source, let me see if I'm getting the > idea > (btw, I don't have any experience with Eclipse, so any concepts spring-rcp > borrows from Eclipse I've learned only through spring-rcp source). If I'm > getting this wrong, please let me know. > > An Application consists of one or more windows (ApplicationWindow), managed > by > WindowManager. An application has at least one window (a main window). A > Window displays a single page (ApplicationPage) at a time. A page contains > a > View registry. This means a Page can contain multiple Views. So, if my > application's main window consists of a single Page (which is really the > only > option, right?), then I can swap out the contents of the main window by > swapping pages? I'm guessing an example of this would be "workbenches" in > the IDE world? For example, if I am in Edit mode, then I have several > views > > open on my page: maybe a folder view, an edit view, and an output view. In > Debug mode, I have a "watches" view, breakpoint view, source code view, > stack > view, etc. With this understanding, I'm having trouble figuring out where > the Perspective class fits in, as it seems to be a one-to-one > relationshipship with a View (though it is by the view's ID and not a > reference to a View itself). > OK. On to Actions. In rcp, you have VisualActions and ActionHandlers. A > VisualAction defines only the visual representation and keyboard access > (menu > item, toolbar item, icon, text, mnemonic, accelerator, etc). The actual > functionality of the action is provided separately in an ActionHandler. > Actions are registered in a global ActionRegistry, and ActionHandlers are > register7ed with views (via the ViewContext). Well, I guess it is also > possible to associate an ActionHandler directly with an Action (for those > actions that are not view dependent). So, when a View becomes active, > spring-rcp will query the view against every registered global Action to > see > > if that View provides an ActionHandler for the Action. This means that the > functionality of a particular Action can be dynamically implemented > per-view > > (kinda cool, actually). It looks like for this to work, your Actions must > also implement TargetableVisualAction (which is implemented by > DefaultVisualAction). > The org.springframework.rcp.action.contribution package seems to be all > about > building menus and toolbars. I'm not sure I have this right, since I > haven't > played around with it. Since an Application can present the user with > multiple ways to do actions (menus, toolbars, pop up menus. etc), > spring-rcp > > provides an abstraction that allows you to group such actions logically and > automatically represent that group as any of these more concrete > implementations. So, a ContributionItem is an abstraction on top of a menu > item, toolbar button, etc and a ContributionItemManager is an abstraction > on > > top of a menu bar, toolbar set, etc. ContributionItemManager allows you to > group ContributionItems (via group id) - each group becoming a different > menu > along a menubar, or a different toolbar in a toolbar set(?) I'm not too > sure > about this actually. ContributionItem seems similar in many ways to an > Action... but I guess it needs to be different because some menu items > (such > > as seperators) are not actions? In fact, ActionContributionItem seems to > be > > no more than a wrapper (adapter) that makes an Action look like a > ContributionItem. A ContributionItem can create menu items and toolbar > controls just like an Action can. > Some questions on my exploration of the source so far: > What is the preferred way for creating/configuring controls from > spring-rcp? I don't see a common Page interface... it looks like dialogs > get their own idea of what a page is and windows get another. Is this > intentional? > > Well, that's about all the further I've gotten so far. > BTW, if anyone has any example configuration files used with spring-rcp, > I'd > > love to see them. > > Thanks, > Andy > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now > for SourceForge Broadband and get the fastest 6.0/768 connection for only > $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id%62&alloc_ida84&op=Click > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X