springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-183) Pluggable Null property path handling

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

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

Lieven Doclo updated RCP-183:
-----------------------------

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

> Pluggable Null property path handling
> -------------------------------------
>
>                 Key: RCP-183
>                 URL: http://jira.springframework.org/browse/RCP-183
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Binding System
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>
> We need to provide a strategy that allows end users to implement their own null property path handling.
> Once we have implemented a solution to RCP-182 I believe this should be fairly simple as this "no value" idea would also dovetails in with the null property path handing. You could have the property access strategy return NoValue for nested properties whose parent is null or NoValue rather than throwing an exception like they do now. You could even extend this so that when you try to write a new value to one of these NoValue properties the property access strategy then uses some MissingParentPropertyStrategy to try and instantiate the parent so that the write can be successful, this would also mean that the parent property would only get instantiated if one of its child properties was written to.

-- 
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-566) Hide splash screen before showing main application window.

[Brad M. (JIRA) <no...@sp...>]

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

Brad Maupin commented on RCP-566:
---------------------------------

I do have my own lifecycleadvisor, but I had to create a different application launcher to provide the ability to close the splash screen w/o using SwingUtilities.invokeLater. I call this splash screen closer from the applicationLifecycle's onCommandsCreated(). I was executing the login command from onCommandsCreated(), but since there would be no Windows TaskBar entry I now execute my login command from onWindowOpened() (I have only 1 ApplicationWindow - MDI).

> Hide splash screen before showing main application window.
> ----------------------------------------------------------
>
>                 Key: RCP-566
>                 URL: http://jira.springframework.org/browse/RCP-566
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 1.0.0
>         Environment: Windows XP
>            Reporter: Brad Maupin
>            Priority: Minor
>             Fix For: 1.x
>
>
> My application first displays a login form before displaying the main application window. The splash screen is still visible when the login form is displayed. It would be nice to be able to hide the splash screen before showing the login form.

-- 
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-189) TableUtils resizing columns should take into account all rows.

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

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

Lieven Doclo updated RCP-189:
-----------------------------

    Fix Version/s: 1.x

> TableUtils resizing columns should take into account all rows.
> --------------------------------------------------------------
>
>                 Key: RCP-189
>                 URL: http://jira.springframework.org/browse/RCP-189
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Helper Classes
>            Reporter: Benoit Xhenseval
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>
> Hi
> As discussed at the end of post http://forum.springframework.org/viewtopic.php?t=8933 , the current implementation TableUtils.sizeColumnsToFitRowData(JTable) just looks at the first row. It is understandable if the table contains thousands of rows...
> Here is an alternative solution; it takes 250ms on my old laptop (1GHz) to resize a table of 7 columsn and 2,000 rows.
> [code]
> /**
> * Resize the columns based on the data contained in all rows and Header.
> * The original width will be based on the value of the column header, and,
> * will be expanded if at least one row requires more space.  The column header
> * size is slightly padded to allow for sorting icons (GlazedTableModel).
> * @param table the table to resize
> * @author Benoit Xhenseval (modified)
> */
> public static void sizeColumnsToFitAllRowData(JTable table) {
>   // go through each column first to take the renderer.
>   for (int col = 0; col < table.getColumnCount(); col++) {
>     final TableColumnModel colModel = table.getColumnModel();
>     final TableModel model = table.getModel();
>     TableColumn column = colModel.getColumn(col);
>     TableCellRenderer r = colModel.getColumn(col).getCellRenderer();
>     // original width should be based on the size of the HEADER.
>     int cWidth = table.getTableHeader().getFontMetrics(table.getTableHeader().getFont()).stringWidth(
> 	    model.getColumnName(col) + "XXXX"); // we have added 'XXXX' to allow space for sorting icons. 
>     for (int row = 0; row < table.getRowCount(); row++) {
> 	if (r == null) {
> 	    Object val = table.getValueAt(row, col);
> 	    if (val != null) {
> 		r = table.getDefaultRenderer(val.getClass());
> 	    }
> 	}
> 	if (r != null) {
> 	    Component c = r.getTableCellRendererComponent(table, table.getValueAt(row, col), false, false, 0,
> 		    col);
> 	    cWidth = Math.max(c.getPreferredSize().width, cWidth);
> 	}
>     }
>     column.setPreferredWidth(cWidth + UIConstants.ONE_SPACE);
>     column.setWidth(cWidth);
>   }
>   int width = Math.min(table.getColumnModel().getTotalColumnWidth(), (int) (WindowUtils.getScreenWidth() * .75));
>   table.setPreferredScrollableViewportSize(new Dimension(width, 300));
> }
> [/code]
> since the name is slightly different, could you add this method to the TableUtils? Thanks!
> We have also experienced some optimizations by quickly going through the values of each row and simply doing a toString() to it, then picking up the row
> where the string is the biggest and only try to render that row.  It is not the most accurate method if you have some funny 
> rendering (say Date formatting that abbreviate a Date dramatically).  But for big tables, it would be faster!  For our example
> of 2,000 rows & 7 columns, it is about 30% faster.
> Here is the code, again, we have named the method slightly differently so they can co-exist:
> [code]
> public static void sizeColumnsToFitAllRowDataBasedOnStrings(JTable table) {
>   for (int col = 0; col < table.getColumnCount(); col++) {
>     final TableColumnModel colModel = table.getColumnModel();
>     final TableModel model = table.getModel();
>     TableColumn column = colModel.getColumn(col);
>     TableCellRenderer r = colModel.getColumn(col).getCellRenderer();
>     // original width should be based on the size of the HEADER.
>     int cWidth = table.getTableHeader().getFontMetrics(table.getTableHeader().getFont()).stringWidth(
> 	    model.getColumnName(col) + "XXXX"); // we have added 'XXXX' to allow space for sorting icons.
>     // now simply spot the row that has the biggest "string"
>     int maxStringLength = 0;
>     Object maxRowValue = null;
>     int maxRowIndex = 0;
>     for (int row = 0; row < table.getRowCount(); row++) {
> 	Object value = table.getValueAt(row, col);
> 	if (value != null) {
> 	    final int length = value.toString().length();
> 	    if (length > maxStringLength) {
> 		maxStringLength = length;
> 		maxRowValue = value;
> 		maxRowIndex = row;
> 	    }
> 	}
>     }
>     // and uses that row for the rendering.
>     if (r == null) {
> 	Object val = table.getValueAt(maxRowIndex, col);
> 	if (val != null) {
> 	    r = table.getDefaultRenderer(val.getClass());
> 	}
>     }
>     if (r != null) {
> 	Component c = r.getTableCellRendererComponent(table, maxRowValue, false, false, 0, col);
> 	cWidth = Math.max(c.getPreferredSize().width, cWidth);
>     }
>     column.setPreferredWidth(cWidth + UIConstants.ONE_SPACE);
>     column.setWidth(cWidth);
>   }
>   int width = Math.min(table.getColumnModel().getTotalColumnWidth(), (int) (WindowUtils.getScreenWidth() * .75));
>   table.setPreferredScrollableViewportSize(new Dimension(width, 300));
> }
> [/code]
> Please let me know if/when you could put this in CVS so I can remove my own class.
> Many 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-198) Determine webAppContextUrl through JNLP instead of hard coding it with patch: JnlpPropertyPlaceholderConfigurer

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

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

Lieven Doclo updated RCP-198:
-----------------------------

    Fix Version/s: 1.x

> Determine webAppContextUrl through JNLP instead of hard coding it with patch: JnlpPropertyPlaceholderConfigurer
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: RCP-198
>                 URL: http://jira.springframework.org/browse/RCP-198
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Helper Classes
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 1.x
>
>         Attachments: JnlpPropertyPlaceholderConfigurer.java, JnlpPropertyPlaceholderConfigurer.java, JnlpPropertyPlaceholderConfigurer.java
>
>
> In the petclinic example I saw the localhost:8080 hardcoded, which means this would have to be adjusted in the properties file in the jar (which is in in the war) for deployment on any domain.
> With JnlpPropertyPlaceholderConfigurer (attached) there is not need to do this:
> For example:
>   <bean id="jnlpPropertyPlaceholderConfigurer"
>       class="be.kahosl.mammoet.swingclient.util.JnlpPropertyPlaceholderConfigurer">
>       <property name="fallBackWebAppContextUrl" value="http://localhost:8080/mammoet-webclient/"/>
>       <property name="jnlpRelativeDirectoryPathFromWebAppContext" value="/jnlp/"/>
>   </bean>
>   <bean name="orderService"
>     class="org.springframework.remoting.caucho.BurlapProxyFactoryBean">
>     <property name="serviceUrl">
>       <value>${jnlp.webAppContextUrl}orderService.service</value> <!-- NO HARD CODING, not even in a properties file-->
>     </property>
>     <property name="serviceInterface">
>       <value>be.kahosl.mammoet.serviceapi.order.OrderService</value>
>     </property>
>   </bean>

-- 
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-210) Abstract out Swing dependancy from binding system

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

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

Lieven Doclo resolved RCP-210.
------------------------------

    Resolution: Won't Fix

SWT support will not be provided as both technologies are completely incompatible

> Abstract out Swing dependancy from binding system
> -------------------------------------------------
>
>                 Key: RCP-210
>                 URL: http://jira.springframework.org/browse/RCP-210
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 1.0.2
>
>
> The core form model and binding system should be totaly independent of any specific GUI framework. 

-- 
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-222) Promote Settings Support from sandbox to src

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

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

Lieven Doclo updated RCP-222:
-----------------------------

    Fix Version/s: 1.0.2

> Promote Settings Support from sandbox to src
> --------------------------------------------
>
>                 Key: RCP-222
>                 URL: http://jira.springframework.org/browse/RCP-222
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Settings/Preferences
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 1.0.2
>
>
> Promote settings and prefs support to src

-- 
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-224) Integrate settings and prefs support in the sample application

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

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

Lieven Doclo updated RCP-224:
-----------------------------

    Fix Version/s: 1.x

> Integrate settings and prefs support in the sample application
> --------------------------------------------------------------
>
>                 Key: RCP-224
>                 URL: http://jira.springframework.org/browse/RCP-224
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Settings/Preferences
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 1.x
>
>
> Integrate settings and prefs in sample application
> - Preferences command + Preferences dialog
> - multiple pref pages
> - using xml settings implementation
> - find uses for the settings support (setup wizard, confirm close of window, ...)
> Please add suggestions as comments

-- 
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-226) Add SwingBindingFactory.bindCombobox and bindList

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

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

Lieven Doclo updated RCP-226:
-----------------------------

    Fix Version/s: 1.x

> Add SwingBindingFactory.bindCombobox and bindList
> -------------------------------------------------
>
>                 Key: RCP-226
>                 URL: http://jira.springframework.org/browse/RCP-226
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Binding System
>            Reporter: Kambiz Darabi
>            Assignee: Oliver Hutchison
>            Priority: Minor
>             Fix For: 1.x
>
>         Attachments: patch-swing-binding-factory.txt
>
>
> I use a gui builder (abeille) to create a JPanel and need to bind a combobox on this panel to a collection of beans.
> Additionally, I want to specify the bean property, which should be rendered.
> Currently, SwingBindingFactory only provides createBinding methods, which instantiate a control.
> So, there is a need for a method like AbstractBindingFactory.bindControl.
> This patch adds the following methods:
> public Binding bindList(JList list, String selectionFormProperty, ValueModel selectableItemsHolder, String renderedProperty, Integer forceSelectMode)
> public Binding bindComboBox(JComboBox combo, String formProperty, ValueModel selectableItemsHolder, String renderedProperty)
> Thanks
> Kambiz

-- 
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-229) Formatting by conversion service should be configurable

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

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

Lieven Doclo updated RCP-229:
-----------------------------

    Fix Version/s: 1.x

> Formatting by conversion service should be configurable
> -------------------------------------------------------
>
>                 Key: RCP-229
>                 URL: http://jira.springframework.org/browse/RCP-229
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Binding System
>            Reporter: Frank Bowers
>            Assignee: Oliver Hutchison
>            Priority: Minor
>             Fix For: 1.x
>
>
> If I have an Integer domain object property I am stuck with the formatting for the current locale when it's rendered in in a text field.  I want to be able to specify the formatting used by the conversion service on a per-property basis.

-- 
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-219) multiple view implementations should have a common interface

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

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

Lieven Doclo updated RCP-219:
-----------------------------

    Fix Version/s: 1.x

> multiple view implementations should have a common interface
> ------------------------------------------------------------
>
>                 Key: RCP-219
>                 URL: http://jira.springframework.org/browse/RCP-219
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Dialog System
>    Affects Versions: 0.1.0
>            Reporter: Geoffrey De Smet
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>
> There are several ways to organize multiple views:
> - internal frames
> - only tabs
> - perspective based (like eclipse)
> - docking based (like IntelliJ)
> If the have a commen interface following the Strategy Design Pattern, switch from one to another should be as simple as switching for Hessian to HttpInvoker in Swing.
> RCP-161
> RCP-98
> RCP-56
> There is also an OS integration project on java.net with one of the commercial docking frameworks. They too should be able to use this interface
> RCP-193
> Proposal for naming the interface:
> ViewOrganizer
> MultiView
> ...
> Proposal for methods of the common interface:
>  addView (view, attributes)
>  removeView (view)
>  addViewOrganizerListener()
>  removeViewOrganizerListener()
>  ...
>  
> I 'd like to do a simple TabbedViewOrganizer implementation that shows views in tabs and has a close (X) button on each tab.

-- 
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-235) Write documentation for settings support

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

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

Lieven Doclo updated RCP-235:
-----------------------------

    Fix Version/s: 1.0.2

> Write documentation for settings support
> ----------------------------------------
>
>                 Key: RCP-235
>                 URL: http://jira.springframework.org/browse/RCP-235
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Settings/Preferences
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 1.0.2
>
>
> - white paper
> - configuration
> - use cases
> - examples

-- 
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-238) Abstract test cases need to be renamed

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

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

Lieven Doclo updated RCP-238:
-----------------------------

    Fix Version/s: 1.x

> Abstract test cases need to be renamed
> --------------------------------------
>
>                 Key: RCP-238
>                 URL: http://jira.springframework.org/browse/RCP-238
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Larry Streepy
>            Assignee: Larry Streepy
>            Priority: Minor
>             Fix For: 1.x
>
>
> 1. Rename test cases that are meant to be Abstract (i.e., other test cases will extend them) from AbstractXxxTests to XxxTestBase.
> 2. Tests cases that are meant to test Abstract classes should be named AbstractXxxTests.  
> 3. Remove the **/Abstract* exclusion from the junit invocation in build.xml

-- 
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-251) The SecurityAwareConfigurer automatically loads all beans. Use of the lazy initialization (lazy-init = "true") now is not meaningful.

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

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

Lieven Doclo updated RCP-251:
-----------------------------

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

> The SecurityAwareConfigurer automatically loads all beans. Use of the lazy initialization (lazy-init = "true") now is not meaningful.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: RCP-251
>                 URL: http://jira.springframework.org/browse/RCP-251
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Ivan G. Storozhenko
>            Assignee: Oliver Hutchison
>            Priority: Minor
>             Fix For: 1.x
>
>


-- 
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-262) CheckBoxBinder could easily used for other ToggleButtons.

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

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

Lieven Doclo updated RCP-262:
-----------------------------

    Fix Version/s: 1.x

> CheckBoxBinder could easily used for other ToggleButtons.
> ---------------------------------------------------------
>
>                 Key: RCP-262
>                 URL: http://jira.springframework.org/browse/RCP-262
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>            Reporter: Arne Limburg
>            Assignee: Oliver Hutchison
>            Priority: Trivial
>             Fix For: 1.x
>
>
> The CheckBoxBinder code is not such specific. It could easily be used for other JToggleButtons. It should be refactored to ToggleButtonBinder and use a JToggleButton rather than a CheckBox. It could even use an AbstractButton. This could users prevent from writing RadioButtonBinders that have exactly the same source code like the CheckBoxBinder with a replace of JCheckBox to JRadioButton done

-- 
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-255) AbstractForm throws NullPointerException in setFormObject if no FormModel is set.

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

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

Lieven Doclo updated RCP-255:
-----------------------------

    Fix Version/s: 1.x

> AbstractForm throws NullPointerException in setFormObject if no FormModel is set.
> ---------------------------------------------------------------------------------
>
>                 Key: RCP-255
>                 URL: http://jira.springframework.org/browse/RCP-255
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Arne Limburg
>            Assignee: Oliver Hutchison
>            Priority: Minor
>             Fix For: 1.x
>
>
> AbstractForm throws NullPointerException in setFormObject if no FormModel is set. It would be an improvement if a FormModel would be created in such case with the help of the FormModelHelper, like it is done in the constructor corresponding constructor.
> An implementation could look like:
>     public void setFormObject(Object formObject) {
>         if (formModel == null)
>             setFormModel(FormModelHelper.createFormModel(formObject));
>         else
>             formModel.setFormObject(formObject);
>     }

-- 
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-261) Needed changes in SpringRCP classes

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

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

Lieven Doclo updated RCP-261:
-----------------------------

    Fix Version/s: 1.x

> Needed changes in SpringRCP classes
> -----------------------------------
>
>                 Key: RCP-261
>                 URL: http://jira.springframework.org/browse/RCP-261
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>         Environment: WinXp
>            Reporter: Martin Zeltner
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>         Attachments: patched_classes.zip
>
>
> Hello everybody,
> I'm currently working with SpringRCP in project EL4J
> (http://el4j.sf.net) and I had problems with some
> classes, because they hide methods that should not be
> hidden and do not have a default constructor and so on.
> Here are the details for the appended files:
> ---+ AbstractApplicationPage.java
> * Had only a constructor with parameters that can
> not be set twice.
> ---+ PageLayoutBuilder.java
> * I've added method "public void addView(String
> viewDescriptorId, Object positionArgument)" to be able
> to place a view somehow.
> ---+ ApplicationLauncher.java
> * The splash screen was displayed too late, because
> startup- and root-application-context has been started
> at the time.
> Here are further changes that should be made:
> * Add a default constructor where it is possible and
> implement interface InitializingBean.
> * If these classes would implement interface
> BeanNameAware it would be very easy to locate
> misconfigurations (e.g. if you have multiple views
> configured).
> * Don't hide setter or getter methods if it is not
> really necessary, e.g. see method "setId" of class
> "AbstractForm".
> * In method "createPage" of class
> "DefaultApplicationWindow" don't lookup a
> "DefaultApplicationPage".
> I hope my explanations are clear, else just ask.
> Comments are welcome too.
> Best regards,
> Martin
> BTW: In EL4J 0.9.2 (http://el4j.sf.net) we have a very nice SpringRCP demo working with javabeans. At the moment it is very simple and we didn't release any docs but we will extend it in the near future.

-- 
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-263) Adding ability to have multiple instance of internal frames

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

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

Lieven Doclo updated RCP-263:
-----------------------------

    Fix Version/s: 1.x

> Adding ability to have multiple instance of internal frames
> -----------------------------------------------------------
>
>                 Key: RCP-263
>                 URL: http://jira.springframework.org/browse/RCP-263
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Benoit Xhenseval
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>         Attachments: RCP-263.patch
>
>
> Hello
> based on Peter's RCP56 for Internal Frame, I note that the code has now moved to an mdi package.
> Would it be possible to add the following code to DesktopApplicationPage so that it is possible to have more than 1 internal frame based on the same view.
>     // + New Stuff for managing Singleton views...
>     private Map<String,Boolean> singletonViews = new HashMap<String,Boolean>(); 
>     
>     /**
>      * This method is called each time a new internal frame is being launched.
>      * @return null means that this view is not launched yet and therefore a new one will be created.
>      */
>     @Override
>     protected PageComponent findPageComponent(String viewDescriptorId) {
>         Boolean isSingleton = singletonViews.get(viewDescriptorId);
>         if (isSingleton==null) {
>             // fetch the bean and check if it is a singleton.
>             BeanFactory factory = Application.instance().getServices().getBeanFactory();
>             isSingleton = factory.isSingleton(viewDescriptorId);
>             singletonViews.put(viewDescriptorId,isSingleton);
>         }
>         
>         if (isSingleton) {
>             return super.findPageComponent(viewDescriptorId);
>         } else {
>             return null;
>         }
>     }
> More details on
> http://forum.springframework.org/showthread.php?t=20141&highlight=multiple+view
> The code shown in JDk5.0 but it would be trivial to refactor for any older jdk.
> Many 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-264) Master/detail hooks on commands: delete, save, update, ...

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

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

Lieven Doclo updated RCP-264:
-----------------------------

    Fix Version/s: 1.x

> Master/detail hooks on commands: delete, save, update, ...
> ----------------------------------------------------------
>
>                 Key: RCP-264
>                 URL: http://jira.springframework.org/browse/RCP-264
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Helper Classes
>            Reporter: Geoffrey De Smet
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>
> Currently it's hard to hook in a myService.deleteMyObject(myObject) on a delete command without disturbing all the logic already in spring rich.
> The only way I see is by overriding deleteSelectedItems() with an almost exact implementation.
> It would be nice if it was like this in AbstractMasterForm:
>     /**
>      * Delete the detail item at the specified index.
>      * @param index Index of item to delete
>      */
>     protected void deleteSelectedItems() {
>         ListSelectionModel sm = getSelectionModel();
>         if( sm.isSelectionEmpty() ) {
>             return;
>         }
>         _detailForm.reset();
>         int min = sm.getMinSelectionIndex();
>         int max = sm.getMaxSelectionIndex();
>         // Loop backwards and delete each selected item in the interval
>         for( int index = max; index >= min; index-- ) {
>             if( sm.isSelectedIndex( index ) ) {
>                 deleteItem(getMasterEventList().getElementAt(index));
>                 getMasterEventList().remove( index );
>             }
>         }
>     }
>     /**
>      * Template method, hook for service calls.
>      * @param o the object to delete
>      */
>     protected void deleteItem(Object o) {
>     }

-- 
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-267) Forms in Wizards (with FormBackedWizardPages) are never commited by the WizardDialog (the only implementation of a WizardContainer).

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

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

Lieven Doclo updated RCP-267:
-----------------------------

    Fix Version/s: 1.x

> Forms in Wizards (with FormBackedWizardPages) are never commited by the WizardDialog (the only implementation of a WizardContainer).
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: RCP-267
>                 URL: http://jira.springframework.org/browse/RCP-267
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>         Environment: any
>            Reporter: Arne Limburg
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>
> Forms in Wizards (with FormBackedWizardPages) are never commited by the WizardDialog (the only implementation of a WizardContainer). I don't consider this as a bug, but this should be done, when a FormBackedWizardPage becomes invisible (due to a click on back or next or via showPage) if it is commitable. At least this should happen on a click on next. I suggest adding the methods isCommittable() and commit() to the FormBackedWizardPage, delegating to the backed Form's FormModel. Then the WizardDialog should call this methods in onNext(), onBack() and showPage() if the current page is an instance of FormBackedWizardPage.

-- 
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-277) Maximize JInternalView automatically with a flag!

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

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

Lieven Doclo updated RCP-277:
-----------------------------

    Fix Version/s: 1.x

> Maximize JInternalView automatically with a flag!
> -------------------------------------------------
>
>                 Key: RCP-277
>                 URL: http://jira.springframework.org/browse/RCP-277
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Dialog System
>            Reporter: dma
>            Assignee: Oliver Hutchison
>            Priority: Minor
>             Fix For: 1.x
>
>
> Possiblity to set via application-context.xml whether the views should be maximized or not. Here is my solution:
> DesktopApplicationPage.java 
> private boolean maximizeFrame = false; --> This attribute is set by the constructor
> method giveFocusTo:
> ...
> try {
>             internalFrame.setMaximum(maximizeFrame);
>             internalFrame.setSelected(true);
>         } catch (PropertyVetoException e) {
>             // ignore
>         }
> ...
> DesktopApplicationWindow.java
>     private boolean maximizeFrame = false;  //Also declare a flag
>     protected ApplicationPage createPage(PageDescriptor descriptor) {
>         return new DesktopApplicationPage(this, descriptor, maximizeFrame);
>     }
>     public void setMaximizeFrame(boolean maximize){  //For setter-injection
>         this.maximizeFrame = maximize;   
>     }
> business-application-context.xml:
> <bean id="applicationWindowPrototype"
>     class="org.springframework.richclient.application.mdi.DesktopApplicationWindow"
>     singleton="false">
>     <property name="maximizeFrame">  <!-- SET THE FLAG -->
>       <value>true</value>
>     </property>
> </bean>
> markus

-- 
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-285) Petclinic: (Re)Enable webstart + standalone webstart on site demo

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

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

Lieven Doclo updated RCP-285:
-----------------------------

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

> Petclinic: (Re)Enable webstart + standalone webstart on site demo
> -----------------------------------------------------------------
>
>                 Key: RCP-285
>                 URL: http://jira.springframework.org/browse/RCP-285
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 1.x
>
>
> Enable webstart for petlinic:
> - client webstart included in server
> - standalone webstart included in maven site as demo "WEB START ME NOW"

-- 
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-271) Support for a default command for TargetableActionCommand

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

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

Lieven Doclo updated RCP-271:
-----------------------------

    Fix Version/s: 1.x

> Support for a default command for TargetableActionCommand
> ---------------------------------------------------------
>
>                 Key: RCP-271
>                 URL: http://jira.springframework.org/browse/RCP-271
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Command System
>            Reporter: Arne Limburg
>            Assignee: Oliver Hutchison
>             Fix For: 1.x
>
>         Attachments: TargetableActionCommand.java
>
>
> I have implemented support for a default command for the TargetableActionCommand-class. Sometimes it is appropriate to have a default behavior for an action and replace this behavior with a more specific one if in example some component is showing up on the screen. With my changes the component can register its specific action command executor when it shows up on the screen and deregister it when it hides. After deregistration the TargetableActionCommand will automatically register the default command again. My implementation changes the behavior of TargetableActionCommand NOT, if no default command is set.

-- 
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-291) Set up Continuum (for nighlty testing and builds)

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

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

Lieven Doclo updated RCP-291:
-----------------------------

    Fix Version/s: 1.x

> Set up Continuum (for nighlty testing and builds)
> -------------------------------------------------
>
>                 Key: RCP-291
>                 URL: http://jira.springframework.org/browse/RCP-291
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Build System
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 1.x
>
>
> - Discuss on the mailing list who's Linux server will be used and set up a Continuum on it.
> - add the multiproject pom.xml file
> - test if it doesn't compile the dev list gets an e-mail from continuum
> Additionally:
> - configure secure access to the SF site
> - replace "install" goal by "deploy site-deploy"

-- 
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-298) closing a spring rich application should not call system.exit

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

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

Lieven Doclo updated RCP-298:
-----------------------------

    Fix Version/s: 1.x

> closing a spring rich application should not call system.exit
> -------------------------------------------------------------
>
>                 Key: RCP-298
>                 URL: http://jira.springframework.org/browse/RCP-298
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Brian Ross
>             Fix For: 1.x
>
>
> Application.close() ends with a call to System.exit(0).
> This will kill the JVM, which in many cases is inappropriate.  For example, the spring rich application may be launched from inside another application running in the JVM and this call will bring down the entire process.
> Simply removing the call will prevent this from happening, but will introduce another problem.  If you try to relaunch the spring rich application, you will get an error because the application context still exists.  The solution is to replace the call to System.exit(0) with the line:
> SOLE_INSTANCE = null;

-- 
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-299) and access to the control on a CommandGroup

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

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

Lieven Doclo resolved RCP-299.
------------------------------

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

Controls can be added through the factory bean for command groups

> and access to the control on a CommandGroup
> -------------------------------------------
>
>                 Key: RCP-299
>                 URL: http://jira.springframework.org/browse/RCP-299
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>            Reporter: Brian Ross
>            Assignee: Larry Streepy
>             Fix For: 1.0.2
>
>         Attachments: CommandGroup.java
>
>
> some CommandGroup controls, like the toolbar, only support a very small set of features at this point.  Those who wish to add things to the toolbar other than plain buttons need a way to access the control from their code.  this involves only a small change to CommandGroup.java, which I will attach.

-- 
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