springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-314) Merge exception handler implementations

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-314:
-----------------------------

    Fix Version/s:     (was: 1.0.2)
                   1.x

> Merge exception handler implementations
> ---------------------------------------
>
>                 Key: RCP-314
>                 URL: http://jira.springframework.org/browse/RCP-314
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Helper Classes
>    Affects Versions: 0.1.0
>            Reporter: Geoffrey De Smet
>            Assignee: Larry Streepy
>             Fix For: 1.x
>
>
> On the dev list we 've found out each of us has it own exception handler.
> In the discussion "Exception handling" we aggreed they all should be merged into the best solution.
> Very short summary of the thread (pls take a look at it):
> Geoffrey's is checked in into the tiger module: D:\projects\sf\spring-richclient\tiger\src\main\java\be\springframework\richclient\exception\I18nUncaughtExceptionHandler.java
> It supports i18n and polymorfistic message declarationg (for example if there is no specific message for NullPointerException, the one from RuntimeException is used).
> Larry has an e-mail report.
> Jan uses SwingLab's JXErrorDialog.
> Bushe uses http://eventbus.dev.java.net and it's AWTExceptionHandler.
> Benoit found the best way to take an image was with this code, which uses the JDK (and not an LGPL library):
>     private byte[] takeScreenSnapshot() throws AWTException {
>         final Robot robot = new Robot();
>         final Dimension screenDim = Toolkit.getDefaultToolkit().getScreenSize();
>         final Rectangle rect = new Rectangle(0, 0, screenDim.width, screenDim.height);
>         final BufferedImage bi = robot.createScreenCapture(rect);
>  
>         ByteArrayOutputStream bos = new ByteArrayOutputStream();
>         try {
>             ImageIO.write((RenderedImage) bi, "png", bos);
>             bos.close();
>         } catch (IOException e) {
>             e.printStackTrace();
>         }
>  
>         // convert java.awt.Image to a PNG graphic (highest compression)
>         final byte[] pngArray = bos.toByteArray();
>         return pngArray;
>     }
> Some brainstorming:
> The commands on a thrown exception could be configurable (maybe?):
> - inject in a eMailReporterCommand at your own will
> - send all system properties too boolean
> IMHO catching Exception yourself (with try-catch) is bad: I18nUncaughtExceptionHandler shows it can be done differently.
> PMD, checkstyle, etc say to avoid catching general exceptions such as Throwable, Error, Exception, RuntimeException, unless in the root of the stacktrace (= exceptino handler api in 1.5)
> I've assigned it to Larry for the moment because he said he might look at it after the petclinic sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-304) application exception handler for ApplicationDialog.onFinishException(Exception)

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-304:
-----------------------------

    Fix Version/s: 1.x

> application exception handler for ApplicationDialog.onFinishException(Exception)
> --------------------------------------------------------------------------------
>
>                 Key: RCP-304
>                 URL: http://jira.springframework.org/browse/RCP-304
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Dialog System
>            Reporter: Markus Rogg
>            Priority: Minor
>             Fix For: 1.x
>
>
> It should be possible to set an exception handler for the onFinishException(Exception)-method for all ApplicationDialogs (maybe in the xml context). Currently an application with an own exception handler must overwrite every Dialog class to change the exception handling. For dialogs opened by the rich client e.g. the log-in dialog it isn't currently possible to change the exception handling. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-327) Define more GlobalCommandIds

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-327:
-----------------------------

    Fix Version/s: 1.x

> Define more GlobalCommandIds
> ----------------------------
>
>                 Key: RCP-327
>                 URL: http://jira.springframework.org/browse/RCP-327
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>            Reporter: Peter De Bruycker
>            Priority: Minor
>             Fix For: 1.x
>
>
> Print (ctrl-P)
> Export (maybe not common enough?)
> Find (ctrl-F)
> Find Again (ctrl-G)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-316) Enable full and release modules

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-316:
-----------------------------

    Fix Version/s: 1.x

> Enable full and release modules
> -------------------------------
>
>                 Key: RCP-316
>                 URL: http://jira.springframework.org/browse/RCP-316
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 1.x
>
>
> The full and release modules are currently commented out:
> - full because it corrupts the "mvn install" of petclinic
> - release because it takes to long to include into mvn install
> one option would be to create a "release profile" that includes full and release and a default profile which doesn't.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-318) UI Flow

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-318:
-----------------------------

         Priority: Trivial  (was: Major)
    Fix Version/s: 1.x

> UI Flow
> -------
>
>                 Key: RCP-318
>                 URL: http://jira.springframework.org/browse/RCP-318
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Andy DePue
>            Priority: Trivial
>             Fix For: 1.x
>
>
> Spring Rich could really use a UI flow mechanism.  By "UI Flow", I mean the Spring Rich equivalent of Spring's Web Flow.  Something that can direct the user and/or UI through a sequence of actions/commands/events.  For example, there is currently on the Spring Rich dev list discussion for the need to define a "flow" for application startup.  Some people need a sequence like this:
>   Login Dialog -> [successful login] -> Intro screen (if this is first login) -> Main Window
> Others might need:
>   Intro screen -> Login Dialog -> Main Window
> While others need:
>   Login Dialog -> Main Window
> Or even nothing at all (just straight to the Main Window).  Of course, after application startup, UI flow has many other uses, and can become quite dynamic.  For example, an application might have a user go through specific steps to setup a new "entity," and depending on the type of entity or other choices the user makes while setting up the entity, the flow may need to branch out and navigate the user to additional setup screens.  I can also see such a flow mechanism being embedded into the Wizard API to allow the developer to easily define complex wizard sequences.
> My recommendation is to investigate using Spring Web Flow itself as the flow engine for Spring Rich.  I have very little experience with Spring Web Flow, so I do not know if this is even feasible, but I'm guessing it is - and if so, this would create great synergy between the two projects as we would then be able to leverage the development efforts of the Web Flow team.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-348) Support setter injection and wait with initialize in afterPropertiesSet

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo resolved RCP-348.
------------------------------

       Resolution: Won't Fix
    Fix Version/s: 1.0.2

> Support setter injection and wait with initialize in afterPropertiesSet
> -----------------------------------------------------------------------
>
>                 Key: RCP-348
>                 URL: http://jira.springframework.org/browse/RCP-348
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 0.1.0
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 1.0.2
>
>
> Some services (Application, ...) require contructor injection.
> Both contructor injection and setter injection should be supported.
> All initializing code should be done in afterPropertiesSet,
> so there no more need of dirty things like
> <property name="applicationObjectConfigurerBeanId"><idref bean="applicationObjectConfigurer"/></property>
> instead of
> <property name="applicationObjectConfigurer"><bean ref="applicationObjectConfigurer"/></property>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-372) Focus for form used in Wizards and Dialogs

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-372:
-----------------------------

    Fix Version/s: 1.0.2

check patch

> Focus for form used in Wizards and Dialogs
> ------------------------------------------
>
>                 Key: RCP-372
>                 URL: http://jira.springframework.org/browse/RCP-372
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Dialog System
>    Affects Versions: 0.2.0
>            Reporter: Tomasz Lempart
>             Fix For: 1.0.2
>
>         Attachments: RCP-372-petclinic.patch, RCP-372.patch
>
>
> There should be easy way to specify in form which field should get focus when form is shown.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-359) Preference Settings should be user specific.

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-359:
-----------------------------

    Fix Version/s: 1.x

> Preference Settings should be user specific.
> --------------------------------------------
>
>                 Key: RCP-359
>                 URL: http://jira.springframework.org/browse/RCP-359
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Settings/Preferences
>            Reporter: Benoit Xhenseval
>             Fix For: 1.x
>
>
> Is it an improvement or a bug?  At the moment, if I use the j2seprefs.PreferencesSettingsFactory, the user settings are stored in the registry independently of the user logged in the application.
> Basically, the "user" settings will be the same for ALL application username/password on that machine...
> I think that I'd preferable to take the userId entered in the login screen by default and add this to the path for the preferences.
> My £0.02 suggestion...
> Thanks!
> Benoit

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-373) Update GUI from Domain Level Objects

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-373:
-----------------------------

    Fix Version/s: 1.x

> Update GUI from Domain Level Objects
> ------------------------------------
>
>                 Key: RCP-373
>                 URL: http://jira.springframework.org/browse/RCP-373
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Binding System
>    Affects Versions: 0.1.0, 0.2.0, 1.x
>            Reporter: Tim Canavan
>             Fix For: 1.x
>
>
> In the documentation for Spring it says that there is binding between the GUI control and the Data Model .   
> "A forms data binding and validation framework, for connecting edits made in your UI controls with your domain model automatically--with as you type feedback."
> Would it be possible to have also the reverse. For example imagine I have a grid wit where a  records currentlly selected row is  displayed in a separate JFame.  Each business object say has a status attriburre. I have an Action where I can change this Business Object attribute on all the objects that are selected in the grid.  I would like to update to be immediately propogated to the GUI without the need to call a refresh button.  
> If I update an attribure common to all domain objects selected I expect that this change be reflected on the display inside the Frame.  Currently we implement this where I work through propertyChangeEvents in the BO. We would like to get rid of this dependency 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-376) null application window

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-376:
-----------------------------

    Fix Version/s: 1.0.2

> null application window
> -----------------------
>
>                 Key: RCP-376
>                 URL: http://jira.springframework.org/browse/RCP-376
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.1.0
>            Reporter: Ryan Sonnek
>             Fix For: 1.0.2
>
>
> My action command executor extends the ApplicationWindowAwareCommand, yet when I run the command, I get a null pointer exception.
> how does the application window get initialized on my object?
> public class ApplicationWindowProgressMonitorActionCommandExecutor extends ApplicationWindowAwareCommand implements ActionCommandExecutor {
> 	private final ParameterizableActionCommandExecutor delegate;
> 	public ApplicationWindowProgressMonitorActionCommandExecutor(ParameterizableActionCommandExecutor delegate) {
> 		this.delegate = delegate;
> 	}
> 	protected void doExecuteCommand() {
>         BusyIndicator.showAt(getApplicationWindow().getControl());
>         getProgressMonitor().taskStarted(getText(), StatusBar.UNKNOWN);
>         delegate.execute(getParameters());
>         BusyIndicator.clearAt(getApplicationWindow().getControl());
>         getProgressMonitor().done();
> 	}
>     private ProgressMonitor getProgressMonitor() {
>     	return getApplicationWindow().getStatusBar().getProgressMonitor();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-376) null application window

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo resolved RCP-376.
------------------------------

    Resolution: Won't Fix

> null application window
> -----------------------
>
>                 Key: RCP-376
>                 URL: http://jira.springframework.org/browse/RCP-376
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>    Affects Versions: 0.1.0
>            Reporter: Ryan Sonnek
>
> My action command executor extends the ApplicationWindowAwareCommand, yet when I run the command, I get a null pointer exception.
> how does the application window get initialized on my object?
> public class ApplicationWindowProgressMonitorActionCommandExecutor extends ApplicationWindowAwareCommand implements ActionCommandExecutor {
> 	private final ParameterizableActionCommandExecutor delegate;
> 	public ApplicationWindowProgressMonitorActionCommandExecutor(ParameterizableActionCommandExecutor delegate) {
> 		this.delegate = delegate;
> 	}
> 	protected void doExecuteCommand() {
>         BusyIndicator.showAt(getApplicationWindow().getControl());
>         getProgressMonitor().taskStarted(getText(), StatusBar.UNKNOWN);
>         delegate.execute(getParameters());
>         BusyIndicator.clearAt(getApplicationWindow().getControl());
>         getProgressMonitor().done();
> 	}
>     private ProgressMonitor getProgressMonitor() {
>     	return getApplicationWindow().getStatusBar().getProgressMonitor();
>     }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-381) Autoconfigure global commands defined in the main richclient-application-context.xml file

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-381:
-----------------------------

    Fix Version/s: 1.x

> Autoconfigure global commands defined in the main richclient-application-context.xml file
> -----------------------------------------------------------------------------------------
>
>                 Key: RCP-381
>                 URL: http://jira.springframework.org/browse/RCP-381
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.2.0
>         Environment: XP SP2, 1.5.0_06
>            Reporter: Rogan Dawes
>             Fix For: 1.x
>
>
> As discussed on the list, I have a requirement to define some global commands that are not application window specific, and need to be synchronized between window instances (i.e. if I define a ToggleCommand, and I select it in one window, it should be selected in ALL other open or future windows.)
> It makes most sense to define such commands in the global application context, rather than in a window-specific commands-context.xml file, since the commands-context file is reread for each window that is opened. Consequently, approaches such as defining commands as singletons is ineffective, since a new Context it created each time a window is opened, and each object IS a singleton in that context, but there are multiple contexts, and hence multiple Command instances!
> The problem with defining commands in the Application context is that they are not autoconfigured with labels, etc, as they are when defined in the commands-context.
> The solution proposed by Larry was to make it easier to autoconfigure commands defined in the application context.
> This issue serves to document the discussion, and remind relevant parties that there is still interest in a solution ;-) Alternatively, some guidance as so how to begin fixing the issue, so that I can create a patch.
> Regards,
> Rogan

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-389) expose setFieldFaceSource in FormModel?

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-389:
-----------------------------

    Fix Version/s: 1.x

> expose setFieldFaceSource in FormModel?
> ---------------------------------------
>
>                 Key: RCP-389
>                 URL: http://jira.springframework.org/browse/RCP-389
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>            Reporter: Adrian Moos
>            Priority: Minor
>             Fix For: 1.x
>
>
> Configuring a custom field face source for a form model can only be done on AbstractFormModel, but the only way to get the implementation class short of a downcast is by manual construction. It can be inconvenient to provide an means for specifying the FieldFaceSource to be used at creation time. Why not simply publish this setter in the implementation class, so another instance can be installed by code using (but not creating) the form model?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-390) make the tests run in headless environment

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-390:
-----------------------------

    Fix Version/s: 1.x

> make the tests run in headless environment
> ------------------------------------------
>
>                 Key: RCP-390
>                 URL: http://jira.springframework.org/browse/RCP-390
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>    Affects Versions: 0.1.0, 0.2.0
>            Reporter: Mathias Broekelmann
>            Priority: Minor
>             Fix For: 1.x
>
>
> some of the tests don't run in a headless environment. I identified these tests to fail:
> support:
> FormGuardTests
> InputApplicationDialogTests
> DirtyIndicatorInterceptorTests
> sandbox:
> WindowMementoTests
> If we going to use continuum on a linux box these tests will not run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-401) add new default command to open web browser BrowserLauncherCommand

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-401:
-----------------------------

    Fix Version/s: 1.x

> add new default command to open web browser BrowserLauncherCommand
> ------------------------------------------------------------------
>
>                 Key: RCP-401
>                 URL: http://jira.springframework.org/browse/RCP-401
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Command System
>            Reporter: Ryan Sonnek
>            Priority: Minor
>             Fix For: 1.x
>
>
> add a new implementation of command to allow for application to open web browser.
> see http://jroller.com/page/wireframe/?anchor=spring_rich_client_browser_launcher for complete description and code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-406) Wizard validation fires before reaching step

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-406:
-----------------------------

         Priority: Minor  (was: Critical)
    Fix Version/s:     (was: 1.0.2)
                   1.x
       Issue Type: Task  (was: Bug)

> Wizard validation fires before reaching step
> --------------------------------------------
>
>                 Key: RCP-406
>                 URL: http://jira.springframework.org/browse/RCP-406
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Application Framework
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Ryan Sonnek
>            Assignee: Jan Hoskens
>            Priority: Minor
>             Fix For: 1.x
>
>
> Consider this simple scenerio:
> 1.  MyObject has two properties, firstName and lastName.
> 2.  register "required" validator for both properties.
> 3.  for some reason, i built a wizard where the firstName and lastName are on two different steps of the wizard.
> 4.  When launching the wizard, I'm unable to get past the first step because it says one of the properties is required.
> This is wrong because I haven't yet got to that step in the wizard to fill in that property.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-437) Enable multiple instances of MDI frames for same view.

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-437:
-----------------------------

    Fix Version/s: 1.x

> Enable multiple instances of MDI frames for same view.
> ------------------------------------------------------
>
>                 Key: RCP-437
>                 URL: http://jira.springframework.org/browse/RCP-437
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>    Affects Versions: 1.0.0
>            Reporter: Benoit Xhenseval
>             Fix For: 1.x
>
>         Attachments: DesktipApplicationPage.java.patch
>
>
> Hi
> I'd like to propose a patch that is backward compatible with the existing code.
> The patch allows several MDI windows for the same view (say "TradeView", traders would like to see more than 1).
> At the moment, this is not possible.
> This is simply done by looking up for the singleton property in the Spring XML config for the requested view.
> If the view is a singleton and an instance already exists, it returns it.
> If it does not exist or is not a singleton, DesktopApplicationPage.findPageComponent returns null which then indicates to SpringRC to build a new one.
> I'd be grateful if you'd consider it for inclusion in the mdi package in the sandbox.
> Thanks
> Benoit

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-432) support for multiple/switchable ApplicationPage's

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-432:
-----------------------------

         Priority: Minor  (was: Major)
    Fix Version/s: 1.x
       Issue Type: Improvement  (was: New Feature)

> support for multiple/switchable ApplicationPage's
> -------------------------------------------------
>
>                 Key: RCP-432
>                 URL: http://jira.springframework.org/browse/RCP-432
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 1.0.0, 1.x
>            Reporter: Joerg Buchberger
>            Priority: Minor
>             Fix For: 1.x
>
>
> - complex rich clients have different types of users, with different aim and needs, i.e. their collection of use cases differ
> - complex rich clients also have power users that need to perform very different sets of tasks, that comprise different sets of use cases / scenarios
> How can this needs be fulfilled within one rich client?
> You need the ability to preconfigure/customize a whole set of ApplicationPage's, where each can be tailored to a different set of use cases ...
> i.e. depending on the feature/subsystem the user needs to use, a suitable ApplicationPage can then be presented/chosen!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-439) make AbstractCommand.getFaceDescriptor() public

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-439:
-----------------------------

    Fix Version/s: 1.0.2

> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
>                 Key: RCP-439
>                 URL: http://jira.springframework.org/browse/RCP-439
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Arne Limburg
>            Assignee: Peter De Bruycker
>             Fix For: 1.0.2
>
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-439) make AbstractCommand.getFaceDescriptor() public

[Lieven D. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=40226#action_40226 ] 

Lieven Doclo commented on RCP-439:
----------------------------------

Is this still an issue?

> make AbstractCommand.getFaceDescriptor() public
> -----------------------------------------------
>
>                 Key: RCP-439
>                 URL: http://jira.springframework.org/browse/RCP-439
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Arne Limburg
>            Assignee: Peter De Bruycker
>             Fix For: 1.0.2
>
>
> In some situations it is necessary to get displayable informations (like text, icon, ...) from a configured AbstractCommand, i.e. if you want to display a command with a component that does not inherit from AbstractButton.
> There is no possibilty for this by now. AbstractCommand should either implement DescribedElement and VisualizedElement or you should make getFaceDescriptor() public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-447) Reenable de test org.springframework.richclient.image.HandlerTestsIgnored

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-447:
-----------------------------

    Fix Version/s: 1.x

> Reenable de test org.springframework.richclient.image.HandlerTestsIgnored
> -------------------------------------------------------------------------
>
>                 Key: RCP-447
>                 URL: http://jira.springframework.org/browse/RCP-447
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 1.0.0
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 1.x
>
>
> That test fails during "mvn clean install" so I ignored it by renaming it to ...Ignored.
> The test works in the IDE, so it's definitely a forking problem of the surefire configuration.
> One test shouldn't hold back all other tests for requiring to succeed - although of course this one test should also be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-443) Get spring-richclient on the central maven repo

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-443:
-----------------------------

    Fix Version/s: 1.x

> Get spring-richclient on the central maven repo
> -----------------------------------------------
>
>                 Key: RCP-443
>                 URL: http://jira.springframework.org/browse/RCP-443
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 1.x
>
>
> We can create upload-bundles, but that's annoying to have to do that every release.
> A better alternative is to sync up the repo, but it seems it's better if we would reuse spring's repo.
> ---- mail on maven dev list ----
> Sorry, I hadn't read that part yet (it's new in the last couple of months I believe).
> I don't know if we're allowed to run such a script on the SF server and if it would be possible to deploy to the spring repository instead.
> I 'll make an issue for myself.
> Carlos Sanchez wrote, On 2006-11-07 5:19 PM:
> > Take a look at the end of
> > http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
> > We use rsync over ssh.
> > 
> > On 11/7/06, Geoffrey De Smet <ge0...@gm...> wrote:
> >> Carlos,
> >>
> >> When spring-richclient released 0.2.1 I tried to make an upload bundle,
> >> but there's an issue for that for multiprojects.
> >>
> >> So I was wondering if you can't just sync our repo? :)
> >> http://spring-rich-c.sourceforge.net/maven2repository/org/springframework/richclient/ 
> >>
> >>
> >> -- 
> >> With kind regards,
> >> Geoffrey De Smet
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev...@ma...
> >> For additional commands, e-mail: dev...@ma...
> >>
> >>
> > 
> > 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-448) Use Microba DatePicker control

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-448:
-----------------------------

    Fix Version/s: 1.x
      Component/s: Binding System

> Use Microba DatePicker control
> ------------------------------
>
>                 Key: RCP-448
>                 URL: http://jira.springframework.org/browse/RCP-448
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>         Environment: All
>            Reporter: Michael Baranov
>            Priority: Minor
>             Fix For: 1.x
>
>
> Please, consider integrating Microba DatePicker and CalendarPane components into RCP. I'm the author and maintainer of the library. I'm willing to solve any troubles on this way, if any. You may also wish to make a head-to-head comparrison with NachoCalendar.
> http://microba.sf.net

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-455) Add to the ApplicationException hierarchy for method parameter validation.

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-455:
-----------------------------

    Fix Version/s: 1.x

> Add to the ApplicationException hierarchy for method parameter validation.
> --------------------------------------------------------------------------
>
>                 Key: RCP-455
>                 URL: http://jira.springframework.org/browse/RCP-455
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 0.2.1
>         Environment: All
>            Reporter: Kevin Stembridge
>            Priority: Minor
>             Fix For: 1.x
>
>
> Hi all,
> The code base makes use of Spring's Assert class for performing method parameter validation. Underneath the hood it throws either IllegalArgumentException or IllegalStateException. I'd like to suggest an alternative approach that is becoming more widely used these days and has several benefits.
> In summary, the new approach consists of creating a subclass of RuntimeException that is specific to a given application or framework and then creating several subclasses that are specific to each type of parameter validation rule we wish to enforce.
> For example:
> ApplicationException extends RuntimeException;
> InvalidArgumentException extends ApplicationException;
> NullArgumentException extends InvalidArgumentException;
> There are several advantages to this approach:
> 1. We can distinguish between exceptions being thrown from our own code and that of third parties.
> 2. The exception class can be responsible for creating a suitable error message so that the developer throwing the exception doesn't have to. This also makes the code cleaner.
> 3. Static methods can be added to the exception to simplify their use in application code.
> e.g. NullArgumentException.throwIfNull(String argumentName, Object argument);
> 4. The code is more explicit about what it does and therefore more understandable. For example, compare the following snippets. The first makes it explicit that a NullArgumentException will be thrown if the object is null. For the second, you have to read the javadoc of the Assert class to know that it will throw an IllegalArgumentException.
>         NullArgumentException.throwIfNull(someObject);
>         Assert.assertNotNull(someObject);
> 5. Unit testing can be more robust by ensuring that the exceptions we expect to see being thrown were actually thrown for the reason that we expected them to be thrown.  Comparing the two examples below, the first can only confirm that an IllegalArgumentException was thrown but it can't confirm why, and it could possibly report a false positive.
> Example 1:
> try {
>    new BogusObject(null);
>    Assert.fail("Should have thrown an IllegalArgumentException");
> }
> catch (IllegalArgumentException e) {
>    //do nothing, test succeeded
> }
> Example 2:
> try {
>    new BogusObject(null);
>    Assert.fail("Should have thrown a NullArgumentException");
> }
> catch (NullArgumentException e) {
>    Assert.assertEquals("arg0", e.getArgumentName());
> }
> The RCP code base already contains an ApplicationException class but it is not widely used (only 5 refs) and it has no subclasses. I don't recommend the use of ApplicationException directly because I think that in general it is a good idea for code to be throwing as specific and informative an exception as is practicable. Spring's BeansException and DataAccessException are good examples of a rich exception hierarchy.
> Anyway, this is just a suggestion for an improvement that I think would be worth considering and I'd be interested to hear what you all think.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-470) An exception handling ChainPurger should replace evaluatedChainedIndex

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-470:
-----------------------------

    Fix Version/s:     (was: 1.0.2)
                   1.x

> An exception handling ChainPurger should replace evaluatedChainedIndex
> ----------------------------------------------------------------------
>
>                 Key: RCP-470
>                 URL: http://jira.springframework.org/browse/RCP-470
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 1.x
>
>
> evaluatedChainedIndex only applies to MessagesDialogExceptionHandler, but it should also be useable on the delegating exception handler.
> evaluatedChainedIndex is to clumsy in most circumstances as it's the type of the exceptions, instead of the level that decide if it should be evaluated.
> ExceptionChainPurger to the rescue, pluggable into any ExceptionHandler.
> It cuts the first part of an exception chain if needed.
> It contains 2 properties:
> - alwaysEvaluatePrioritizedList: List<Class<? extends Exception>>: for example it contains "SQL504Exception", then any chain which contains that type of exception will be evaluated as the SQL504Exception instance.
> - alwaysTryToUnwrapList: List<Class<? extends Exception>>: for example it contains "WrappingServiceException", so it always tries to unwrap that.
> TODO: find beter names, suggestions welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira