springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-169) Add/remove a ValueChangeListener to all valueModels of a formModel

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-169:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Add/remove a ValueChangeListener to all valueModels of a formModel
> ------------------------------------------------------------------
>
>                 Key: RCP-169
>                 URL: http://jira.springframework.org/browse/RCP-169
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>            Reporter: Jan Hoskens
>            Assignee: Oliver Hutchison
>             Fix For: 1.0.1
>
>         Attachments: patch-RCP-169-fix.txt
>
>
> Add/remove a valuechangelistener to all valueModels of a formModel instead of a specific property. 
> Sometimes any change in a FormObject should trigger an event, so instead of coupling the listener to each property explicitly you can choose to attach it to each property of the 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-211) Write step by step guide to using binding system

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-211:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Write step by step guide to using binding system
> ------------------------------------------------
>
>                 Key: RCP-211
>                 URL: http://jira.springframework.org/browse/RCP-211
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Documentation
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 1.0.1
>
>


-- 
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-214) Handle collections at the PropertyAccessStrategy level

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-214:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Handle collections at the PropertyAccessStrategy level
> ------------------------------------------------------
>
>                 Key: RCP-214
>                 URL: http://jira.springframework.org/browse/RCP-214
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 1.0.1
>
>
> We need a CollectionPropertyAccessStrategy and also the ability to proxy collections returned by all PropertyAccessStrategies so that changes to collections are properly detected.

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

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-285:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> 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.0.1
>
>
> 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-236) Promote Master/Detail forms from sandbox to src

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-236:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Promote Master/Detail forms from sandbox to src
> -----------------------------------------------
>
>                 Key: RCP-236
>                 URL: http://jira.springframework.org/browse/RCP-236
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Larry Streepy
>            Assignee: Larry Streepy
>             Fix For: 1.0.1
>
>


-- 
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-212) Full JavaDocs for all binding module classes

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-212:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Full JavaDocs for all binding module classes
> --------------------------------------------
>
>                 Key: RCP-212
>                 URL: http://jira.springframework.org/browse/RCP-212
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System, Documentation
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 1.0.1
>
>


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

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-406:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> 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: Bug
>          Components: Application Framework
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Ryan Sonnek
>            Assignee: Jan Hoskens
>            Priority: Critical
>             Fix For: 1.0.1
>
>
> 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-433) DialogPage.visible not reflected in TreeCompositeDialogPage

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-433:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> DialogPage.visible not reflected in TreeCompositeDialogPage
> -----------------------------------------------------------
>
>                 Key: RCP-433
>                 URL: http://jira.springframework.org/browse/RCP-433
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Dialog System
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 1.0.1
>
>


-- 
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-314) Merge exception handler implementations

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-314:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> 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.0.1
>
>
> 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-512) Setup docbook manual in build system

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-512:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

> Setup docbook manual in build system
> ------------------------------------
>
>                 Key: RCP-512
>                 URL: http://jira.springframework.org/browse/RCP-512
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>             Fix For: 1.0.1
>
>


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

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens updated RCP-470:
----------------------------

    Fix Version/s:     (was: 1.0.0)
                   1.0.1

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

        

Re: [Springframework-rcp-dev] Release 1.0

[Jan H. <jh...@sc...>]

For some unknown reason the mvn release cycle broke during tests
(although running them separately went ok). I've then deployed the jars
by using the deploy command, so they are now available on the spring
rich maven repository. Because the release broke, no site/manual has
been built yet. I'll see to this tomorrow morning together with posting
a note on the forum.

Kind Regards,
Jan

On Mon, 2008-03-17 at 15:18 +0100, Peter De Bruycker wrote:
> And to answer you're second question:
> 
> I think it's a good idea to have the documentation driven by the
> forum.
> 
> Peter
> 
> On 3/17/08, Jan Hoskens <jh...@sc...> wrote:
>         Hi,
>         
>         Are we ready to release?
>         
>         I think we got most of the bugs handled. The docs are still
>         lacking, but
>         as we've said before we will do this on a as-needed basis. So
>         I could
>         release the 1.0 version and post this on the forum with a
>         request of
>         which part they really want to see documented. This little
>         poll can then
>         be a guide to posting a number of howto's on the developer
>         blog and/or
>         appended to the docbook (which we regularly update on site).
>         
>         WDYT?
>         
>         Kind Regards,
>         Jan
>         
>         
>           **** DISCLAIMER ****
>           http://www.schaubroeck.be/maildisclaimer.htm
>         
>         -------------------------------------------------------------------------
>         This SF.net email is sponsored by: Microsoft
>         Defy all challenges. Microsoft(R) Visual Studio 2008.
>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>         _______________________________________________
>         Springframework-rcp-dev mailing list
>         Spr...@li...
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

Re: [Springframework-rcp-dev] Release 1.0

[Peter De B. <pet...@gm...>]

And to answer you're second question:

I think it's a good idea to have the documentation driven by the forum.

Peter

On 3/17/08, Jan Hoskens <jh...@sc...> wrote:
>
> Hi,
>
> Are we ready to release?
>
> I think we got most of the bugs handled. The docs are still lacking, but
> as we've said before we will do this on a as-needed basis. So I could
> release the 1.0 version and post this on the forum with a request of
> which part they really want to see documented. This little poll can then
> be a guide to posting a number of howto's on the developer blog and/or
> appended to the docbook (which we regularly update on site).
>
> WDYT?
>
> Kind Regards,
> Jan
>
>
>   **** DISCLAIMER ****
>   http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] Release 1.0

[Peter De B. <pet...@gm...>]

ok with me.

I didn't have any time to help, sorry for that, but I saw you were very
active, so big kudos to you!

regards,

Peter

On 3/17/08, Jan Hoskens <jh...@sc...> wrote:
>
> Hi,
>
> Are we ready to release?
>
> I think we got most of the bugs handled. The docs are still lacking, but
> as we've said before we will do this on a as-needed basis. So I could
> release the 1.0 version and post this on the forum with a request of
> which part they really want to see documented. This little poll can then
> be a guide to posting a number of howto's on the developer blog and/or
> appended to the docbook (which we regularly update on site).
>
> WDYT?
>
> Kind Regards,
> Jan
>
>
>   **** DISCLAIMER ****
>   http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

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

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens commented on RCP-376:
---------------------------------

The current codebase needs a refactoring before any solid solution can be implemented:

http://www.nabble.com/ApplicationWindowAware---commands-context-to16055490.html

We'll probably fix this in Spring Desktop where we have the opportunity to do the refactoring. As mentioned, in some cases you can use a workaround by getting  the current window through the Application instance for now.

> 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] Release 1.0

[Jan H. <jh...@sc...>]

Hi,

Are we ready to release? 

I think we got most of the bugs handled. The docs are still lacking, but
as we've said before we will do this on a as-needed basis. So I could
release the 1.0 version and post this on the forum with a request of
which part they really want to see documented. This little poll can then
be a guide to posting a number of howto's on the developer blog and/or
appended to the docbook (which we regularly update on site).

WDYT?

Kind Regards,
Jan


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

Re: [Springframework-rcp-dev] ApplicationWindowAware & commands-context

[Peter De B. <pet...@gm...>]

Jan,

as I said at JavaPolis, I had started implementing something similar, but
I've ran into similar problems that are not easy to solve.

I agree that we should push it to the Spring Desktop project.

regards,

Peter

On 3/16/08, Jan Hoskens <jh...@sc...> wrote:
>
> I stumbled on some problems concerning the CommandManager that is set as
> a bean post processor in the commands-context. It creates a registry of
> commands and configures them when they are created. Normally it would
> create one manager for each window. If I try to have the
> commands-context imported in the application-context, the registry is
> created once and hence some things can go wrong when requesting a
> command from the registry.
>
> Fixing this is quite harsh as it would need a refactoring of the
> CommandManager: extracting the bean post processor, creating the
> commandManager separately for each window, probably having a global
> commandManager as a parent containing the commands not bound to the
> applicationWindow, commands that do have the ApplicationWindowAware
> interface should be inserted in the correct CommandManager ...
>
> This all is too big a change to implement for the release and is one of
> the things that should be taken into account when starting with the
> Spring Desktop project. I do think a workaround is possible by not using
> the ApplicationWindowAware interface outside of the commands-context but
> directly accessing the current window through the Application instance
> and possibly storing it for a short period (to ensure that changing the
> active window in between wouldn't interfere).
>
> I'm going to extract the stuff I had implemented just in case and revert
> my local copy.
>
> Kind Regards,
>
> Jan
>
>
>
> On Fri, 2008-03-14 at 17:37 +0100, Jan Hoskens wrote:
> > Hi all,
> >
> > I'm currently looking at the problems concerning the extra application
> > context for the commands and the associated ApplicationWindowAware
> > interface (relates to issue RCP-376). This is what I've done on my local
> > machine to fix this:
> >
> > 1) Implemented an ApplicationWindowScope. It contains a small registry
> > in map form to store the objects that are scoped 'window' for each
> > ApplicationWindow. It tracks the window by listening to application
> > events so that at the moment the that a bean is requested, it searches
> > its 'registry' for that bean, creates if necessary and stores it. When
> > the ApplicationWindow closes, another event will cause a removal of all
> > stored objects for that window.
> >
> > 2) Refactored the ApplicationWindowSetter to listen to the same events
> > as the scope, thus tracking the window that is active or being created
> > at the moment. This allows the AWS to be used as a normal
> > beanPostProcessor and by declaring it in the context your beans will get
> > the window injected. Mind though that if you use this interface,  the
> > bean needs to be in the 'window' scope as well to manage it's lifecycle
> > correctly.
> >
> > 3) Adapted the launcher to register the scope and its listener.
> >
> > 4) Adapted the lifecycleAdvisor to be able to not use the
> > commands-context set as windowCommandBarDefinitions and handled in a
> > separate context. So just use <import/> instead.
> >
> > 5) WindowManager and AbstractApplicationWindow are sending some extra
> > application events to make this work.
> >
> > Some things to know: I've successfully adapted a small app to use the
> > scope. I did this by using the context import, setting the menu beans in
> > 'window scope' as well as all other beans that implement the
> > ApplicationWindowAware interface. Mind that the whole chain should be in
> > the correct scope: menuBean->subMenuBean->myAppWindowCommand all three
> > need the 'window scope'.
> >
> > I can commit this as an additional way of configuring or I can remove
> > the old way of having a separate application context. Not sure yet what
> > to choose as these changes are quite new and not yet fully tested. I'm
> > going to check the other richclient samples and see if they expose any
> > problem with this approach.
> >
> > If anyone has some remarks or another view on how to implement this,
> > please share your thoughts.
> >
> > Kind Regards,
> > Jan
> >
> >
> >  **** DISCLAIMER ****
> >  http://www.schaubroeck.be/maildisclaimer.htm
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>   **** DISCLAIMER ****
>   http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-47) translations for the RCP built in properties

[Jan H. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_33368 ] 

Jan Hoskens commented on RCP-47:
--------------------------------

All messages supplied until now are added.

> translations for the RCP built in properties
> --------------------------------------------
>
>                 Key: RCP-47
>                 URL: http://jira.springframework.org/browse/RCP-47
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Marc Portier
>            Assignee: Peter De Bruycker
>            Priority: Trivial
>             Fix For: 2.0.0
>
>         Attachments: messages_de.properties, messages_es.properties, messages_es.properties, messages_fr.properties, messages_nl.properties, messages_pt_BR.properties, messages_zh_CN.properties, RCP-47_pt_BR_V_0.2.0.patch
>
>
> As proposed on the dev-list (http://sourceforge.net/mailarchive/forum.php?thread_id=6031612&forum_id=39905)
> This issue enables rcp-contributors to add their locale specific versions of built-in resource-bundles of the RCP project as attachments.
> -----------------------------------------------------------------------
> Important General Advise To Translation Contributors: 
> Files for resource-bundle properties are (per Java standard) required to be encoded in ISO-8859-1.  Characters not supported by that encoding can be entered in the file using the unicode-escape sequence (e.g. \u20AC for the euro-sign)
> ------------------------------------------------------------------------
> Currently the 'list' of resources to translate is limited to the 
> * 'messages' bundle 
>    at resource-location: org.springframework.richclient.application

-- 
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] Closed: (RCP-209) Add get/setReadOnly to FormModel & DefaultFormModel, to allow a whole form to be set read only

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens closed RCP-209.
---------------------------

      Assignee: Jan Hoskens  (was: Oliver Hutchison)
    Resolution: Fixed

Has been added a while ago: FormModel.isReadOnly() and ConfigurableFormModel.setReadOnly()

> Add get/setReadOnly to FormModel & DefaultFormModel, to allow a whole form to be set read only
> ----------------------------------------------------------------------------------------------
>
>                 Key: RCP-209
>                 URL: http://jira.springframework.org/browse/RCP-209
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Binding System
>            Reporter: Scott Russell
>            Assignee: Jan Hoskens
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Many components (eg. JTextField) display differently when set read only (ie. background grey and text black) as opposed to being disabled (ie. background white and text grey).
> Individual PropertyMetadata can be set read only, to display any bound components as enabled but non-editable. Additionaly, the individual PropertyMetadata can be set enabled or not. However, individual PropertyMetadata also respect the enclosing formModel's enabled property, which allows a form as a whole to be enabled/disabled at once, and have all bound controls display accordingly.
> It would be desirable to have a setReadOnly method on the FormModel, that all PropertyMetadata would respect, thus allowing a form to be set editable or non-editable (but readable) as a whole, and see the change reflected in all bound controls.
> -Scott

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

        

Re: [Springframework-rcp-dev] ApplicationWindowAware & commands-context

[Jan H. <jh...@sc...>]

I stumbled on some problems concerning the CommandManager that is set as
a bean post processor in the commands-context. It creates a registry of
commands and configures them when they are created. Normally it would
create one manager for each window. If I try to have the
commands-context imported in the application-context, the registry is
created once and hence some things can go wrong when requesting a
command from the registry.

Fixing this is quite harsh as it would need a refactoring of the
CommandManager: extracting the bean post processor, creating the
commandManager separately for each window, probably having a global
commandManager as a parent containing the commands not bound to the
applicationWindow, commands that do have the ApplicationWindowAware
interface should be inserted in the correct CommandManager ...

This all is too big a change to implement for the release and is one of
the things that should be taken into account when starting with the
Spring Desktop project. I do think a workaround is possible by not using
the ApplicationWindowAware interface outside of the commands-context but
directly accessing the current window through the Application instance
and possibly storing it for a short period (to ensure that changing the
active window in between wouldn't interfere).

I'm going to extract the stuff I had implemented just in case and revert
my local copy.

Kind Regards,
Jan


On Fri, 2008-03-14 at 17:37 +0100, Jan Hoskens wrote:
> Hi all,
> 
> I'm currently looking at the problems concerning the extra application
> context for the commands and the associated ApplicationWindowAware
> interface (relates to issue RCP-376). This is what I've done on my local
> machine to fix this:
> 
> 1) Implemented an ApplicationWindowScope. It contains a small registry
> in map form to store the objects that are scoped 'window' for each
> ApplicationWindow. It tracks the window by listening to application
> events so that at the moment the that a bean is requested, it searches
> its 'registry' for that bean, creates if necessary and stores it. When
> the ApplicationWindow closes, another event will cause a removal of all
> stored objects for that window.
> 
> 2) Refactored the ApplicationWindowSetter to listen to the same events
> as the scope, thus tracking the window that is active or being created
> at the moment. This allows the AWS to be used as a normal
> beanPostProcessor and by declaring it in the context your beans will get
> the window injected. Mind though that if you use this interface,  the
> bean needs to be in the 'window' scope as well to manage it's lifecycle
> correctly.
> 
> 3) Adapted the launcher to register the scope and its listener.
> 
> 4) Adapted the lifecycleAdvisor to be able to not use the
> commands-context set as windowCommandBarDefinitions and handled in a
> separate context. So just use <import/> instead.
> 
> 5) WindowManager and AbstractApplicationWindow are sending some extra
> application events to make this work.
> 
> Some things to know: I've successfully adapted a small app to use the
> scope. I did this by using the context import, setting the menu beans in
> 'window scope' as well as all other beans that implement the
> ApplicationWindowAware interface. Mind that the whole chain should be in
> the correct scope: menuBean->subMenuBean->myAppWindowCommand all three
> need the 'window scope'.
> 
> I can commit this as an additional way of configuring or I can remove
> the old way of having a separate application context. Not sure yet what
> to choose as these changes are quite new and not yet fully tested. I'm
> going to check the other richclient samples and see if they expose any
> problem with this approach.
> 
> If anyone has some remarks or another view on how to implement this,
> please share your thoughts.
> 
> Kind Regards,
> Jan
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-410) Generate bin scripts with appassembler-maven-plugin

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens closed RCP-410.
---------------------------

      Assignee: Jan Hoskens  (was: Geoffrey De Smet)
    Resolution: Won't Fix

I removed the scripts and opted to have a manifest with a classpath in the sample jars. 

In short the release zip contains (among others):
lib/ -> all jars
samples/ -> main jars for samples (also in lib/)

The jars in the samples/ dir are all executable and include a classpath refering to '../lib/XXX.jar'



> Generate bin scripts with appassembler-maven-plugin
> ---------------------------------------------------
>
>                 Key: RCP-410
>                 URL: http://jira.springframework.org/browse/RCP-410
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Build System
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Jan Hoskens
>             Fix For: 1.0.0
>
>
> The bat/sh scripts currently are done manually by Jan on each release.
> This plugin might automate that:
> http://mojo.codehaus.org/appassembler/appassembler-maven-plugin

-- 
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] Closed: (RCP-307) Replace scripts of petclinic standalone with UberJar

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens closed RCP-307.
---------------------------

      Assignee: Jan Hoskens
    Resolution: Won't Fix

I guess it's better to not use UberJar as our distro zip is already quite big. An UberJar would increase it's size too much. 

In an attempt to also fix the scripts, I thought it would be better to include the classpath in the samples manifest using a ../lib prefix. All jars are located in lib/, the main sample jars are also in samples/ and at that location they are executable due to their manifest.

> Replace scripts of petclinic standalone with UberJar
> ----------------------------------------------------
>
>                 Key: RCP-307
>                 URL: http://jira.springframework.org/browse/RCP-307
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>            Reporter: Jan Hoskens
>            Assignee: Jan Hoskens
>             Fix For: 1.0.0
>
>
> Currently the standalone petclinic sample will be accompanied with startupscripts. But as these contain relative paths, the sample cannot be extracted easily from the project structure. 
> We will replace this with an UberJar when the maven assembly plugin (or another) provides this option. It will place every dependency in one jar (jar-in-jar) which would be easily executable.

-- 
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] ApplicationWindowAware & commands-context

[Jan H. <jh...@sc...>]

Hi all,

I'm currently looking at the problems concerning the extra application
context for the commands and the associated ApplicationWindowAware
interface (relates to issue RCP-376). This is what I've done on my local
machine to fix this:

1) Implemented an ApplicationWindowScope. It contains a small registry
in map form to store the objects that are scoped 'window' for each
ApplicationWindow. It tracks the window by listening to application
events so that at the moment the that a bean is requested, it searches
its 'registry' for that bean, creates if necessary and stores it. When
the ApplicationWindow closes, another event will cause a removal of all
stored objects for that window.

2) Refactored the ApplicationWindowSetter to listen to the same events
as the scope, thus tracking the window that is active or being created
at the moment. This allows the AWS to be used as a normal
beanPostProcessor and by declaring it in the context your beans will get
the window injected. Mind though that if you use this interface,  the
bean needs to be in the 'window' scope as well to manage it's lifecycle
correctly.

3) Adapted the launcher to register the scope and its listener.

4) Adapted the lifecycleAdvisor to be able to not use the
commands-context set as windowCommandBarDefinitions and handled in a
separate context. So just use <import/> instead.

5) WindowManager and AbstractApplicationWindow are sending some extra
application events to make this work.

Some things to know: I've successfully adapted a small app to use the
scope. I did this by using the context import, setting the menu beans in
'window scope' as well as all other beans that implement the
ApplicationWindowAware interface. Mind that the whole chain should be in
the correct scope: menuBean->subMenuBean->myAppWindowCommand all three
need the 'window scope'.

I can commit this as an additional way of configuring or I can remove
the old way of having a separate application context. Not sure yet what
to choose as these changes are quite new and not yet fully tested. I'm
going to check the other richclient samples and see if they expose any
problem with this approach.

If anyone has some remarks or another view on how to implement this,
please share your thoughts.

Kind Regards,
Jan


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-303) Use URLStreamHandlerFactory instead of property to register image protocol

[Jan H. (JIRA) <no...@sp...>]

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

Jan Hoskens closed RCP-303.
---------------------------

         Assignee: Jan Hoskens
       Resolution: Won't Fix
    Fix Version/s: 1.0.0

As Larry mentions this whole thing isn't a bug but is due to the implementation of the URL protocol framework. In short there are three methods to register your own protocol:

1) Supply the URLStreamHandler when constructing your URL object. 

2) Create an URLStreamHandlerFactory and register it on the URL class by using the setURLStreamFactory method.

3) Create the URLStreamHandler by naming it Handler and placing it in a package which ends in the name if the protocol. Then register the package prefix before the protocol name by supplying it to the vm with the property -Djava.protocol.handler.pkgs. (thus setting it to eg 'my.company.protocols', your protocol is named image and your class name must be Handler which lives in package 'my.company.protocols.image')

Now all of these have drawbacks:

1) obviously you don't want to construct each URL object with its specific handler.

2) the factory can be set only once, if set twice an exception will be thrown. This was the initial error of this issue.

3) you need to supply this system parameter at startup. The static method in the image Handler can only be used if no URL was created before and the system parameter wasn't read yet.

Testing if the image protocol is registered correctly cannot is actually not possible and reasonable as we don't know in what environment the test runs and whether one of the drawbacks 2) or 3)  might popup. The only thing we can test is the actual handler itself by providing it in the URL constructor.

The factory might be provided, but is only a feature. To allow all things to work properly, we would need to use the same strategy as Sun's (or any other vm default factory) and thus actually copying a lot of stuf. For the time being I consider the providing of the system property as a good default. Registering it with the static method can be done if you're sure it runs before any URL is created. If your environment has its own factory, register it according to its rules.

> Use URLStreamHandlerFactory  instead of property to register image protocol
> ---------------------------------------------------------------------------
>
>                 Key: RCP-303
>                 URL: http://jira.springframework.org/browse/RCP-303
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>            Reporter: Larry Streepy
>            Assignee: Jan Hoskens
>            Priority: Minor
>             Fix For: 1.0.0
>
>
> From within eclipse, run the HandlerTest directly and note that it passes.
> In the support module, run "mvn test" and note that the test fails with the following output (in the org.springframework.richclient.image.HandlerTest.txt file):
> [ stacktrace ] -----------------------------------------------------------
> junit.framework.AssertionFailedError: protocol was not installed
>         at junit.framework.Assert.fail(Assert.java:47)
>         at org.springframework.richclient.image.HandlerTest.testHandler(HandlerTest.java:62)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at junit.framework.TestCase.runTest(TestCase.java:154)
>         at junit.framework.TestCase.runBare(TestCase.java:127)
>         at junit.framework.TestResult$1.protect(TestResult.java:106)
>         at junit.framework.TestResult.runProtected(TestResult.java:124)
>         at junit.framework.TestResult.run(TestResult.java:109)
>         at junit.framework.TestCase.run(TestCase.java:118)
>         at junit.framework.TestSuite.runTest(TestSuite.java:208)
>         .......

-- 
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-303) Use URLStreamHandlerFactory instead of property to register image protocol

[Geoffrey De S. (JIRA) <no...@sp...>]

    [ http://jira.springframework.org/browse/RCP-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_33232 ] 

Geoffrey De Smet commented on RCP-303:
--------------------------------------

HandlerTestsIgnored.java must be HandlerTests.java

See TODO in Handler.java

> Use URLStreamHandlerFactory  instead of property to register image protocol
> ---------------------------------------------------------------------------
>
>                 Key: RCP-303
>                 URL: http://jira.springframework.org/browse/RCP-303
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>            Reporter: Larry Streepy
>            Priority: Minor
>
> From within eclipse, run the HandlerTest directly and note that it passes.
> In the support module, run "mvn test" and note that the test fails with the following output (in the org.springframework.richclient.image.HandlerTest.txt file):
> [ stacktrace ] -----------------------------------------------------------
> junit.framework.AssertionFailedError: protocol was not installed
>         at junit.framework.Assert.fail(Assert.java:47)
>         at org.springframework.richclient.image.HandlerTest.testHandler(HandlerTest.java:62)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at junit.framework.TestCase.runTest(TestCase.java:154)
>         at junit.framework.TestCase.runBare(TestCase.java:127)
>         at junit.framework.TestResult$1.protect(TestResult.java:106)
>         at junit.framework.TestResult.runProtected(TestResult.java:124)
>         at junit.framework.TestResult.run(TestResult.java:109)
>         at junit.framework.TestCase.run(TestCase.java:118)
>         at junit.framework.TestSuite.runTest(TestSuite.java:208)
>         .......

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