springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-124) Comparing of null values hardcoded in ShuttleSortableTableModel

[Keith D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Donald updated RCP-124:
-----------------------------

    Assignee:     (was: Keith Donald)

> Comparing of null values hardcoded in ShuttleSortableTableModel
> ---------------------------------------------------------------
>
>                 Key: RCP-124
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-124
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Adrian Gygax
>            Priority: Minor
>         Attachments: ShuttleSortableTableModel_nullvalue.patch
>
>
> org.springframework.richclient.table.ShuttleSortableTableModel has hardcoded behaviour for comparing null values. This makes it impossible for Comparators to handle them. As the Java API docs only recommend Comparables (and not Comparators) to throw a NullPointerException if compared to nulls, the hardcoded behaviour should only be executed if no Comparators are specified.
> For example, in my application I need Dates to be sorted in a non-default way. A null value should be larger instead of smaller than anything. This can easily implemented with a Comparator, if ShuttleSortableTableModel lets it treat this case.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-127) support glue in ButtonBarGroupContainerPopulator

[Keith D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Donald updated RCP-127:
-----------------------------

    Assignee:     (was: Keith Donald)

> support glue in ButtonBarGroupContainerPopulator
> ------------------------------------------------
>
>                 Key: RCP-127
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-127
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Peter De Bruycker
>            Priority: Minor
>         Attachments: bad.png, good.png
>
>
> I tried to add a help button to the left of a buttonbar in an application dialog, but the help button was not placed to the left of the dialog, but was located just next to the ok button. (see screenshot1). See the 2nd screenshot for the expected result
> This is caused by:
> 1. the ButtonBarGroupContainerPopulator always inserts glue before inserting buttons (this is to align all buttons to the right).
> 2. the JGoodies ButtonBarBuilder ignores Box.Filler elements (as created by the GlueGroupMember)
> I propose the following solution:
> Create the method addGlue() in GroupContainerPopulator
> SimpleGroupContainerPopulator implementation:
>     public void addGlue() {
>         container.add(Box.createGlue());
>     }
> ButtonBarGroupContainerPopulator:
>     public void addGlue() {
>         buttons.add(CommandGroupFactoryBean.GLUE_MEMBER_CODE);
>     }
>     public void onPopulated() {
>         if (!buttons.contains(CommandGroupFactoryBean.GLUE_MEMBER_CODE)) {
>             builder.addGlue();
>         }
>         int length = buttons.size();
>         for (int i = 0; i < length; i++) {
>             Object o = buttons.get(i);
>             if (o instanceof String) {
>                 if (o == CommandGroupFactoryBean.SEPARATOR_MEMBER_CODE) {
>                     builder.addUnrelatedGap();
>                 }
>                 else if (o == CommandGroupFactoryBean.GLUE_MEMBER_CODE) {
>                     builder.addGlue();
>                 }
>             }
>             else if (o instanceof AbstractButton) {
>                 AbstractButton button = (AbstractButton) o;
>                 if (minimumSize != null) {
>                     addCustomGridded(button);
>                 }
>                 else {
>                     builder.addGridded(button);
>                 }
>                 if (i < buttons.size() - 1) {
>                     builder.addRelatedGap();
>                 }
>             }
>         }
>     }
> The GlueGroupMember also has to be changed:
>     protected void fill(GroupContainerPopulator parentContainer, Object factory, CommandButtonConfigurer configurer, List previousButtons) {
>         parentContainer.addGlue();
>     }

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-129) Modifier util methods in ActionCommand

[Keith D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Donald updated RCP-129:
-----------------------------

    Assignee:     (was: Keith Donald)

> Modifier util methods in ActionCommand
> --------------------------------------
>
>                 Key: RCP-129
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-129
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Peter De Bruycker
>            Priority: Trivial
>
> These methods should be added for easier modifier key detection
>     /**
>      * Returns <code>true</code> if the shift key was down when invoking this
>      * <code>ActionCommand</code>.
>      * @return <code>true</code> if the shift key was down, <code>false</code>
>      * otherwise
>      */
> 	protected boolean isShiftDown() {
> 		return (getModifiers() & ActionEvent.SHIFT_MASK) != 0;
> 	}
>     
> 	/**
> 	 * Returns <code>true</code> if the control key was down when invoking this
> 	 * <code>ActionCommand</code>.
> 	 * @return <code>true</code> if the control key was down, <code>false</code>
> 	 * otherwise
> 	 */
> 	protected boolean isControlDown() {
> 		return (getModifiers() & ActionEvent.CTRL_MASK) != 0;
> 	}
>     
> 	/**
> 	 * Returns <code>true</code> if the meta key was down when invoking this
> 	 * <code>ActionCommand</code>.
> 	 * @return <code>true</code> if the meta key was down, <code>false</code>
> 	 * otherwise
> 	 */
> 	protected boolean isMetaDown() {
> 		return (getModifiers() & ActionEvent.META_MASK) != 0;
> 	}
>     
> 	/**
> 	 * Returns <code>true</code> if the alt key was down when invoking this
> 	 * <code>ActionCommand</code>.
> 	 * @return <code>true</code> if the alt key was down, <code>false</code>
> 	 * otherwise
> 	 */
> 	protected boolean isAltDown() {
> 		return (getModifiers() & ActionEvent.ALT_MASK) != 0;
> 	}

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-97) Creating ActionCommands without a CommandFaceDescriptor causes memory leaks

[Keith D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Donald updated RCP-97:
----------------------------

    Assignee:     (was: Keith Donald)

> Creating ActionCommands without a CommandFaceDescriptor causes memory leaks
> ---------------------------------------------------------------------------
>
>                 Key: RCP-97
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-97
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Calvin Yu
>         Attachments: CommandFaceButtonManager.patch
>
>
> If no CommandFaceDescriptor is specified, then CommandFaceDescriptor.BLANK_FACE_DESCRIPTOR.  The ActionCommand's CommandFaceButtonManager then calls addPropertyChangeListener() on this descriptor, adding itself as the listener.  Unless another CommandFaceDescriptor is set for that ActionCommand, the CommandFaceButtonManager will never be removed from BLANK_FACE_DESCRIPTOR, and therefore the manager and command will never be garbage collected since the descriptor is a static.
> Possible solutions:
> 1) Remove AbstractPropertyChangePublisher's final modifiers on the addPropertyChangeListener() methods, so that they can be overriden by BLANK_FACE_DESCRIPTOR to be a no-op.
> 2) Create a new blank CommandFaceDescriptor instead of using a constant.
> 3) Modify CommandFaceButtonManager so that it isn't added as a PropertyChangeListener if the descriptor is BLANK_FACE_DESCRIPTOR.
> I've attached a patch to solution #3.  While I believe #3 isn't the most optimal solution, it does have less potential side effects to solutions #1 and #2.

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

        

Re: [Springframework-rcp-dev] Class based FormModel

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

> How hard would it be to adapt ClassPropertyAccessStrategy to non-class 
> based backing objects, such as Data Objects, Maps, or DOMs?  We actually 
> use some of these already with Spring Rich (by using our own custom 
> MutablePropertyAccessStrategy) - it would be nice to reuse some of 
> ClassPropertyAccessStrategy if possible.

I haven't thought of this yet, but this is a good moment to start. Is it
possible to send some examples of your implementation? Maybe you already
got some tests as well?

> > - the current implementation (BeanPropertyAccessStrategy - BPAS) is
> > using the BeanWrapperImpl behind the scenes. This implies that if
> > there's a property method with the incorrect visibility, it will be
> > 'fixed' to provide access. Do we need the same functionality here? I
> > personally don't think so.
> >   
> I agree (for now).

So at the moment we all do :-)

> > - the BPAS is based on beans and thus can inspect collections/maps etc.
> > The CPAS cannot look into these and currently doesn't support them. Any
> > comments on this? Should we provide this and how? Geoffrey already gave
> > a remark about this: we could use annotations to provide information
> > about the element type and then go on. WDYT?
> >   
> As Geoffrey has already mentioned, generic types are available at the 
> Class level, just not the Collection instance level.  This means one can 
> inspect the generic type signature of the Class to determine the 
> Collection element type.  Even so, this should still be configurable, 
> not just with annotations, but also at runtime (maybe some sort of 
> binding context key to override the collection type).  This is useful 
> when a broad collection is defined (List<MyBaseObject>), but at runtime 
> we know it will contain only MySpecificBaseObject.

Same remark as with Geoffrey: we're targeting 1.4 now. Should we move to
1.5 to use generics? 

> > - I provided both options BPAS and CPAS in order not to break anything.
> > This leads to changes in
> > FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
> > with both of them or evaluate both and remove one from the mentioned
> > classes? The 'removed' can always be used when with the specific
> > constructor on DefaultFormModel which takes a
> > MutablePropertyAccessStrategy.
> >   
> As it is, if CPAS directly uses Java reflection, then we will be forced 
> to use our own MutablePropertyAccessStrategy, since some of our forms 
> use non-JavaBean backing objects.  However, if CPAS is designed to use 
> an abstracted interface for introspection, one that could easily be 
> swapped out for some other type of backing object (such as a 
> DataObject), then CPAS could do the job all by itself (we could reuse 
> everything CPAS has to offer and only have to implement the 
> introspection interface for our custom backing objects).

At the moment it's pretty fixed to classes, but as said before it is the
moment to put in the extra bit of work to have some more flexibility.
I'll definitely polish things up before pushing it into RCP.

(other comment waaay below)

> We just did something very similar to this.  In our case, we bound to a 
> property, something like this:
> "agency.address.name"
> However, the "agency" happens to be null when the form is first 
> displayed and isn't filled in until the user selects an agency from a 
> combo box.  The requirement was that all components bound to the agency 
> will be disabled until the agency becomes non-null.  Since we are using 
> our own custom MutablePropertyAccessStrategy (MPAS), we decided the 
> easiest path would be if a ValueModel could indicate whether it is 
> "enabled" or not.  If a ValueModel is from a property path containing 
> "null", then it is considered disabled, otherwise it is considered 
> enabled.  So, we created a GuardedValueModel interface:
> 
> public interface GuardedValueModel extends ValueModel, Guarded, 
> PropertyChangePublisher
> {
>   String ENABLED_PROPERTY = "enabled";
> }
> 
> And implement this interface in the custom ValueModels returned from our 
> custom MPAS.  The ValueModel detects when the parent ValueModel becomes 
> non-null, then changes its enabled state (as defined in the Guarded 
> interface from Spring Rich), which fires a property change event.  We 
> then link this property change event to the Form's FieldMetadata by 
> overriding the postProcessNewValueModel method in DefaultFormModel:
> 
>   @Override
>   protected void postProcessNewValueModel(final String formProperty, 
> final ValueModel valueModel)
>   {
>     super.postProcessNewValueModel(formProperty, valueModel);
>     final GuardedValueModel guarded;
>     if(valueModel instanceof GuardedValueModel) {
>       guarded = (GuardedValueModel)valueModel;
>     } else if(valueModel instanceof ValueModelWrapper) {
>       final ValueModel inner = 
> ((ValueModelWrapper)valueModel).getInnerMostWrappedValueModel();
>       if(inner instanceof GuardedValueModel) {
>         guarded = (GuardedValueModel)inner;
>       } else {
>         guarded = null;
>       }
>     } else {
>       guarded = null;
>     }
> 
>     if(guarded != null) {
>       final FieldMetadata fieldMetadata = getFieldMetadata(formProperty);
>       
> guarded.addPropertyChangeListener(GuardedValueModel.ENABLED_PROPERTY, 
> new PropertyChangeListener() {
>         public void propertyChange(PropertyChangeEvent evt) {
>           fieldMetadata.setEnabled(guarded.isEnabled());
>         }
>       });
>     }
>   }
> 
> This isn't perfect, but works for our needs.
> We decided GuardedValueModel was easier than making, say, the "readable" 
> and "writeable" properties of PropertyMetaAspectAccessor mutable (and 
> observable) once we got into the guts of DefaultFormModel (and 
> AbstractFormModel).

Hmm, this looks like another use-case to me. You're referring to
transitive properties and their parent path which may return a null
value. I'm taking note of this, if I'm correctly the current BPAS
doesn't allow this and will give an exception when a parent path returns
null.

I guess your selected agency always has write/read access to the name
property and this doesn't change when having another implementation of
agency. So my use case would be having AgencyReadOnlyName and
AgencyWriteName (extending the former one). Then the field should switch
between read-only and writable.

Kind Regards,
Jan


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

Re: [Springframework-rcp-dev] Class based FormModel

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

> > 
> > - the current implementation (BeanPropertyAccessStrategy - BPAS) is
> > using the BeanWrapperImpl behind the scenes. This implies that if
> > there's a property method with the incorrect visibility, it will be
> > 'fixed' to provide access. Do we need the same functionality here? I
> > personally don't think so.
> 
> no, although if you look at hibernate (which is bean-2-database mapping, 
> instead of bean-2-form mapping) it does support it. But when in doubt - 
> leave it out, we can always put it back in.

Yep, I agree.

> > 
> > - the BPAS is based on beans and thus can inspect collections/maps etc.
> > The CPAS cannot look into these and currently doesn't support them. Any
> > comments on this? Should we provide this and how? Geoffrey already gave
> > a remark about this: we could use annotations to provide information
> > about the element type and then go on. WDYT?
> 
> I think we can do more then we think:
> For example if you give hibernate:
> 
>    class Boss {
>      public List<Person> getMyList
>    }
> 
> hibernate knows that it's a list of Person (not just Object), at runtime.
> 
> Erasure doesn't erase that knowledge on the Boss class methods.
> (It does erase that knowlegde on list instances).
> So it must be available with the Reflection API.

You do implicitly refer to switch to java 1.5 when talking about
generics?  Not sure we can do this, though it's nice to know that it is
possible. 

> 
> Nevertheless I believe in time we could use annotations on the beans to 
> fine tune bindings. But of course they should also be extactly alike 
> creatable with an xml, much like orm.xml is to define JPA/hibernate 
> annotations on non-annotated classes.

Indeed, some form of annotation could provide a nice way out.

> 
> > 
> > - I provided both options BPAS and CPAS in order not to break anything.
> > This leads to changes in
> > FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
> > with both of them or evaluate both and remove one from the mentioned
> > classes? The 'removed' can always be used when with the specific
> > constructor on DefaultFormModel which takes a
> > MutablePropertyAccessStrategy.
> 
> How about we remove BPAS directly after the release of 0.3.0?
> 
> This of course depends how big the big pain is to switch.
> It could be close to zero if we can make a CPAS intead of BPAS based on 
> instance.getClass() etc in depricated methods.

Not a bad idea. We'll make a release before I put in the CPAS.

> Personally, I believe the whole idea of determining read-only access 
> based on existence getters/setters is flaky at best.
> If something needs to be read-only, use 
> getFieldMetaData(...).setReadOnly(true).
> Same goes for setEnabled(false).

The read-only access you mention should be at hand, no doubt about that.
Actually it's the other way around. Making something read-only is
limiting, while I'm referring to expanding to writable. The reason is
that you typically have a super interface/class which you would like to
use to create the form. This can be used throughout the whole process,
except for creating new objects which needs write access to (almost) all
fields. So you got a complete CPAS based on PropertyDescriptors of a
certain class/interface X and then you want the added write-access of
interface/class Y implements/extends X. Your setter isn't defined on X
so no propertyDescriptor exists. And you cannot go the other way around:
creating the CPAS with Y and then using it for objects that conform to X
won't work and will throw an exception.

Or do I not see where your aiming at? Then enlighten me ;-)


Kind Regards,
Jan


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

Re: [Springframework-rcp-dev] Class based FormModel

[Andy D. <an...@ma...>]

Comments inlined below...

Jan Hoskens wrote:
> Hi all,
>
> I'm currently looking at a way to provide class based formModels. Well
> actually it boils down to a different implementation of
> MutablePropertyAccessStrategy called ClassPropertyAccessStrategy (CPAS).
> It all kinda starts to work, but there are a few things that bother me:
>
>   
How hard would it be to adapt ClassPropertyAccessStrategy to non-class 
based backing objects, such as Data Objects, Maps, or DOMs?  We actually 
use some of these already with Spring Rich (by using our own custom 
MutablePropertyAccessStrategy) - it would be nice to reuse some of 
ClassPropertyAccessStrategy if possible.
> - the current implementation (BeanPropertyAccessStrategy - BPAS) is
> using the BeanWrapperImpl behind the scenes. This implies that if
> there's a property method with the incorrect visibility, it will be
> 'fixed' to provide access. Do we need the same functionality here? I
> personally don't think so.
>   
I agree (for now).
> - the BPAS is based on beans and thus can inspect collections/maps etc.
> The CPAS cannot look into these and currently doesn't support them. Any
> comments on this? Should we provide this and how? Geoffrey already gave
> a remark about this: we could use annotations to provide information
> about the element type and then go on. WDYT?
>   
As Geoffrey has already mentioned, generic types are available at the 
Class level, just not the Collection instance level.  This means one can 
inspect the generic type signature of the Class to determine the 
Collection element type.  Even so, this should still be configurable, 
not just with annotations, but also at runtime (maybe some sort of 
binding context key to override the collection type).  This is useful 
when a broad collection is defined (List<MyBaseObject>), but at runtime 
we know it will contain only MySpecificBaseObject.
> - I provided both options BPAS and CPAS in order not to break anything.
> This leads to changes in
> FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
> with both of them or evaluate both and remove one from the mentioned
> classes? The 'removed' can always be used when with the specific
> constructor on DefaultFormModel which takes a
> MutablePropertyAccessStrategy.
>   
As it is, if CPAS directly uses Java reflection, then we will be forced 
to use our own MutablePropertyAccessStrategy, since some of our forms 
use non-JavaBean backing objects.  However, if CPAS is designed to use 
an abstracted interface for introspection, one that could easily be 
swapped out for some other type of backing object (such as a 
DataObject), then CPAS could do the job all by itself (we could reuse 
everything CPAS has to offer and only have to implement the 
introspection interface for our custom backing objects).
> - I want to provide some feature to allow write access when
> possible/needed. I'll explain with an example:
>
> interface Person{
> 	String getName();
> }
>
> class Admin implements Person {
> 	String getName()...
> }
>
> class BadPerson implements Person{
> 	String getName()...
> 	void setName(String)...
> }
>
> Now creating a formModel based on Person will only provide you with read
> access. Which can be ok for most cases. But when I want write access for
> BadPerson, I don't want to create a separate formModel. So I want some
> flexibility to state that, when possible, the property name may be
> writeable. It would be nice to be able to define a number of properties
> that may be writable if the current backing bean allows it. So the class
> provided to create the formModel will define the properties and their
> getters as a minimum together with the setters of those that are always
> writable. If specified, a bean that provides a setter for one of these
> properties might enable write access.
>
> I think I can do this by providing some backingBean specific logic in
> the CPAS. But I would like to hear your comments on this first.
>   
We just did something very similar to this.  In our case, we bound to a 
property, something like this:
"agency.address.name"
However, the "agency" happens to be null when the form is first 
displayed and isn't filled in until the user selects an agency from a 
combo box.  The requirement was that all components bound to the agency 
will be disabled until the agency becomes non-null.  Since we are using 
our own custom MutablePropertyAccessStrategy (MPAS), we decided the 
easiest path would be if a ValueModel could indicate whether it is 
"enabled" or not.  If a ValueModel is from a property path containing 
"null", then it is considered disabled, otherwise it is considered 
enabled.  So, we created a GuardedValueModel interface:

public interface GuardedValueModel extends ValueModel, Guarded, 
PropertyChangePublisher
{
  String ENABLED_PROPERTY = "enabled";
}

And implement this interface in the custom ValueModels returned from our 
custom MPAS.  The ValueModel detects when the parent ValueModel becomes 
non-null, then changes its enabled state (as defined in the Guarded 
interface from Spring Rich), which fires a property change event.  We 
then link this property change event to the Form's FieldMetadata by 
overriding the postProcessNewValueModel method in DefaultFormModel:

  @Override
  protected void postProcessNewValueModel(final String formProperty, 
final ValueModel valueModel)
  {
    super.postProcessNewValueModel(formProperty, valueModel);
    final GuardedValueModel guarded;
    if(valueModel instanceof GuardedValueModel) {
      guarded = (GuardedValueModel)valueModel;
    } else if(valueModel instanceof ValueModelWrapper) {
      final ValueModel inner = 
((ValueModelWrapper)valueModel).getInnerMostWrappedValueModel();
      if(inner instanceof GuardedValueModel) {
        guarded = (GuardedValueModel)inner;
      } else {
        guarded = null;
      }
    } else {
      guarded = null;
    }

    if(guarded != null) {
      final FieldMetadata fieldMetadata = getFieldMetadata(formProperty);
      
guarded.addPropertyChangeListener(GuardedValueModel.ENABLED_PROPERTY, 
new PropertyChangeListener() {
        public void propertyChange(PropertyChangeEvent evt) {
          fieldMetadata.setEnabled(guarded.isEnabled());
        }
      });
    }
  }

This isn't perfect, but works for our needs.
We decided GuardedValueModel was easier than making, say, the "readable" 
and "writeable" properties of PropertyMetaAspectAccessor mutable (and 
observable) once we got into the guts of DefaultFormModel (and 
AbstractFormModel).

  - Andy

Re: [Springframework-rcp-dev] Class based FormModel

[Geoffrey De S. <ge0...@gm...>]

With kind regards,
Geoffrey De Smet

Jan Hoskens schreef:
> Hi all,
> 
> I'm currently looking at a way to provide class based formModels. Well
> actually it boils down to a different implementation of
> MutablePropertyAccessStrategy called ClassPropertyAccessStrategy (CPAS).
> It all kinda starts to work, but there are a few things that bother me:
> 
> - the current implementation (BeanPropertyAccessStrategy - BPAS) is
> using the BeanWrapperImpl behind the scenes. This implies that if
> there's a property method with the incorrect visibility, it will be
> 'fixed' to provide access. Do we need the same functionality here? I
> personally don't think so.

no, although if you look at hibernate (which is bean-2-database mapping, 
instead of bean-2-form mapping) it does support it. But when in doubt - 
leave it out, we can always put it back in.

> 
> - the BPAS is based on beans and thus can inspect collections/maps etc.
> The CPAS cannot look into these and currently doesn't support them. Any
> comments on this? Should we provide this and how? Geoffrey already gave
> a remark about this: we could use annotations to provide information
> about the element type and then go on. WDYT?

I think we can do more then we think:
For example if you give hibernate:

   class Boss {
     public List<Person> getMyList
   }

hibernate knows that it's a list of Person (not just Object), at runtime.

Erasure doesn't erase that knowledge on the Boss class methods.
(It does erase that knowlegde on list instances).
So it must be available with the Reflection API.

Nevertheless I believe in time we could use annotations on the beans to 
fine tune bindings. But of course they should also be extactly alike 
creatable with an xml, much like orm.xml is to define JPA/hibernate 
annotations on non-annotated classes.

> 
> - I provided both options BPAS and CPAS in order not to break anything.
> This leads to changes in
> FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
> with both of them or evaluate both and remove one from the mentioned
> classes? The 'removed' can always be used when with the specific
> constructor on DefaultFormModel which takes a
> MutablePropertyAccessStrategy.

How about we remove BPAS directly after the release of 0.3.0?

This of course depends how big the big pain is to switch.
It could be close to zero if we can make a CPAS intead of BPAS based on 
instance.getClass() etc in depricated methods.

> 
> - I want to provide some feature to allow write access when
> possible/needed. I'll explain with an example:
> 
> interface Person{
> 	String getName();
> }
> 
> class Admin implements Person {
> 	String getName()...
> }
> 
> class BadPerson implements Person{
> 	String getName()...
> 	void setName(String)...
> }
> 
> Now creating a formModel based on Person will only provide you with read
> access. Which can be ok for most cases. But when I want write access for
> BadPerson, I don't want to create a separate formModel. So I want some
> flexibility to state that, when possible, the property name may be
> writeable. It would be nice to be able to define a number of properties
> that may be writable if the current backing bean allows it. So the class
> provided to create the formModel will define the properties and their
> getters as a minimum together with the setters of those that are always
> writable. If specified, a bean that provides a setter for one of these
> properties might enable write access.

Personally, I believe the whole idea of determining read-only access 
based on existence getters/setters is flaky at best.
If something needs to be read-only, use 
getFieldMetaData(...).setReadOnly(true).
Same goes for setEnabled(false).

> 
> I think I can do this by providing some backingBean specific logic in
> the CPAS. But I would like to hear your comments on this first.
> 
> 
> Kind Regards,
> Jan
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/

[Springframework-rcp-dev] Class based FormModel

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

Hi all,

I'm currently looking at a way to provide class based formModels. Well
actually it boils down to a different implementation of
MutablePropertyAccessStrategy called ClassPropertyAccessStrategy (CPAS).
It all kinda starts to work, but there are a few things that bother me:

- the current implementation (BeanPropertyAccessStrategy - BPAS) is
using the BeanWrapperImpl behind the scenes. This implies that if
there's a property method with the incorrect visibility, it will be
'fixed' to provide access. Do we need the same functionality here? I
personally don't think so.

- the BPAS is based on beans and thus can inspect collections/maps etc.
The CPAS cannot look into these and currently doesn't support them. Any
comments on this? Should we provide this and how? Geoffrey already gave
a remark about this: we could use annotations to provide information
about the element type and then go on. WDYT?

- I provided both options BPAS and CPAS in order not to break anything.
This leads to changes in
FormModelHelper/AbstractFormModel/DefaultFormModel.  Should we continue
with both of them or evaluate both and remove one from the mentioned
classes? The 'removed' can always be used when with the specific
constructor on DefaultFormModel which takes a
MutablePropertyAccessStrategy.

- I want to provide some feature to allow write access when
possible/needed. I'll explain with an example:

interface Person{
	String getName();
}

class Admin implements Person {
	String getName()...
}

class BadPerson implements Person{
	String getName()...
	void setName(String)...
}

Now creating a formModel based on Person will only provide you with read
access. Which can be ok for most cases. But when I want write access for
BadPerson, I don't want to create a separate formModel. So I want some
flexibility to state that, when possible, the property name may be
writeable. It would be nice to be able to define a number of properties
that may be writable if the current backing bean allows it. So the class
provided to create the formModel will define the properties and their
getters as a minimum together with the setters of those that are always
writable. If specified, a bean that provides a setter for one of these
properties might enable write access.

I think I can do this by providing some backingBean specific logic in
the CPAS. But I would like to hear your comments on this first.


Kind Regards,
Jan


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

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25315 ] 

Jan Hoskens commented on RCP-165:
---------------------------------

3) thanks

4) as I mentioned, it can be used for prototyping or new projects if we provide it in the archetype. You start off by creating a new project (mvn archetype stuff) and then you get a structure to start from which includes a basic project-rcp.xml and commands.xml (like the one you provided). All your cases would then apply to that setup. I still don't think we need this in the support jar.

As for the beanNames, I call them magic because you don't need to inject them. There's no other connection between the advisor and the menuBeanId than in code. I would prefer to remove the in-code defaultIds and let them be injected in the code. This is more transparant in my opinion.

Concerning the last remark: I think commands should be reusable anywhere, as is the case now. You shouldn't need to define if it may end up in the menu/toolbar etc... It's just another component to represent the same command. The only issue that is surfacing here is the separate commands context. It would be better to just have the commands added to the context (or preferably by importing the current commands.xml instead of providing the url to the advisor for special handling). The problem here is that there should be a way to fix the ApplicationWindowAware-ness of the commands, which is why there is a separate handling currently. Not yet sure how to do this, but I've posted this issue on the dev list as well to discuss it with the other developers.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

Re: [Springframework-rcp-dev] Serious FieldMetaData issue with generics? Test included.

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

I'm guessing this is related to the generic type erasure of java. It
would probably work when stating <T extends Integer> but this probably
isn't what you want. BeanWrapperImpl is only using the
PropertyDescriptor framework of java, so don't blame it on spring. If
you really want to verify this, just use java.beans to access the
IntSuper1 and look at the descriptor signatures.

Don't jump, just take a few more pints and you'll get over it ;-)


Kind Regards,
Jan

On Wed, 2007-08-08 at 01:05 +0100, Benoit Xhenseval wrote:
> The issue seems to be related to the Spring BeanWrapper! (I’m using
> Spring 2.0.6)
> 
>     public static void main(String[] a) {
> 
>         IntSuper1 intSuper1 = new IntSuper1(123);
> 
>         BeanWrapper bw = newBeanWrapperImpl(intSuper1);
> 
> 
> System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++");
> 
>         System.out.println("name is of type:" +
> bw.getPropertyType("name"));
> 
>         System.out.println("id is of type:" +
> bw.getPropertyType("id"));
> 
> 
> System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++");
> 
>         
> 
>     }
> 
>  
> 
> This returns the same value (incorrect imho)
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> name is of type:class java.lang.String
> 
> id is of type:class java.lang.Object
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
>  
> 
> Same if I use a generic directly like Super1<Integer> it still returns
> Object as the type of “id”.
> 
>  
> 
> Any suggestion apart from jumping off Tower Bridge?
> 
>  
> 
> Thanks
> 
>  
> 
> Benoit
> 
>  
> 
> From:spr...@li...
> [mailto:spr...@li...] On
> Behalf Of Benoit Xhenseval
> Sent: 08 August 2007 00:56
> To: spr...@li...
> Subject: [Springframework-rcp-dev] Serious FieldMetaData issue with
> generics? Test included.
> Importance: High
> 
> 
>  
> 
> Dear All,
> 
>  
> 
> I'm faced with what I believe is a serious issue in Spring RC.
> 
>  
> 
> I enclose an example of a typical code that I now face following some
> refactoring.
> 
> Basically my method getId() used to return int and now is returning
> Integer.
> 
> No sweat one would say but ALL forms fails on trying to convert Object
> to String and String to Object!
> 
>  
> 
> java.lang.IllegalArgumentException: No converter registered to convert
> from sourceClass 'class java.lang.String' to target class 'class
> java.lang.Object'
> 
>         at
> org.springframework.binding.convert.support.GenericConversionService.getConversionExecutor(GenericConversionService.java:145)
> 
>         at
> org.springframework.binding.form.support.AbstractFormModel.createConvertingValueModel(AbstractFormModel.java:350)
> 
>         at
> org.springframework.binding.form.support.AbstractFormModel.getValueModel(AbstractFormModel.java:294)
> 
>         at
> org.springframework.richclient.form.binding.support.AbstractBinding.getValueModel(AbstractBinding.java:114)
> 
>         at
> org.springframework.richclient.form.binding.swing.TextComponentBinding.doBindControl(TextComponentBinding.java:39)
> 
>         at
> org.springframework.richclient.form.binding.support.AbstractBinding.createControl(AbstractBinding.java:75)
> 
>         at
> org.springframework.richclient.factory.AbstractControlFactory.getControl(AbstractControlFactory.java:85)
> 
>         at
> org.springframework.richclient.form.binding.support.AbstractBindingFactory.interceptBinding(AbstractBindingFactory.java:92)
> 
>         at
> org.springframework.richclient.form.binding.support.AbstractBindingFactory.createBinding(AbstractBindingFactory.java:70)
> 
>         at
> org.springframework.richclient.form.binding.support.AbstractBindingFactory.createBinding(AbstractBindingFactory.java:55)
> 
>         at
> org.springframework.richclient.form.builder.AbstractFormBuilder.createDefaultBinding(AbstractFormBuilder.java:78)
> 
>         at
> org.springframework.richclient.form.builder.TableFormBuilder.add(TableFormBuilder.java:109)
> 
>         at
> org.springframework.richclient.form.builder.TableFormBuilder.add(TableFormBuilder.java:85)
> 
>         at
> net.objectlab.springtest.TestForm.createFormControl(TestForm.java:22)
> 
>  
> 
> The issue relates to the use of generics.
> 
>  
> 
> The output for the example below is:
> 
>  
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> name is of type:class java.lang.String
> 
> id is of type:class java.lang.Object
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
>  
> 
> I would have expected "id" to be of type java.lang.Integer.
> 
>  
> 
> Has anyone faced this issue? Did you manage to find a workaround??? 
> 
> Please please!  I will also investigate the code in FielMetaData to
> try to figure out what is happening.
> 
>  
> 
> Many thanks!!
> 
>  
> 
> Benoit
> 
>  
> 
> ----------------
> 
>  
> 
> import org.springframework.binding.form.FormModel;
> 
> import org.springframework.richclient.form.FormModelHelper;
> 
>  
> 
> public class GenericTest {
> 
>     public static void test() {
> 
>         IntSuper1 intSuper1 = new IntSuper1(123);
> 
>         FormModel model = FormModelHelper.createFormModel(intSuper1);
> 
> 
> System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++");
> 
>         System.out.println("name is of type:" +
> model.getFieldMetadata("name").getPropertyType());
> 
>         System.out.println("id is of type:" +
> model.getFieldMetadata("id").getPropertyType());
> 
> 
> System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++");
> 
>     }
> 
>     
> 
>     private static class Super1<T> {
> 
>         T id;
> 
>  
> 
>         public Super1(T id) {
> 
>             this.id = id;
> 
>         }
> 
>  
> 
>         public T getId() {
> 
>             return id;
> 
>         }
> 
>  
> 
>         public void setId(T id) {
> 
>             this.id = id;
> 
>         }
> 
>     }
> 
>     
> 
>     private static class IntSuper1 extends Super1<Integer> {
> 
>         private String name;
> 
>  
> 
>         public IntSuper1(Integer id) {
> 
>             super(id);
> 
>         }
> 
>  
> 
>         public String getName() {
> 
>             return name;
> 
>         }
> 
>  
> 
>         public void setName(String name) {
> 
>             this.name = name;
> 
>         }
> 
>     }
> 
> }
> 
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
> 06/08/2007 16:53
> 
>  
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
> 06/08/2007 16:53
> 
> 
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date:
> 06/08/2007 16:53
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________ 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] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

If I've examined the advisor correctly, the only reason that the
commands are defined elsewhere is that they are processed by a specific
CommandBarApplicationContext that registers a special beanPostProcessor
ApplicationWindowSetter. The latter one will install the newly created
window on the command if it's implementing ApplicationWindowAware. (eg
ShowViewCommand is such a command)

If we can fix this, a separate context isn't needed anymore. All
commands could then just be in the regular context by importing the xml
instead of injecting the url in the advisor. Haven't gone deep enough to
provide a solution for this though. 

One question just kinda dropped into mind: is it possible to define an
ApplicationWindow scope in spring? So every bean(command) that needs to
be applicationWindowAware will be instantiated based on that scope?

I'm not (yet) into the OSGi details, so I'm not aware of all the
possibilities on that end.

Kind Regards,
Jan


On Tue, 2007-08-07 at 23:25 +0200, Rogan Dawes wrote:
> Arne Limburg (JIRA) wrote:
> > 
> > 3) You are right. I have upgraded my patch.
> > 
> > 4) It is great for prototypes.
> > 
> > I don't think you have to refactor the advisor. These bean names are
> > not magic anyway. You can change them via the menubarBeanName and
> > toolbarBeanName properties in DefaultApplicationLifecycleAdvisor.
> > With this you can also change the toolbar without the need of
> > specifying any menubar. You only need to include my
> > commands-context.xml into yours, provide your own toolbar-bean and
> > set its name in the advisor. You can also add new menubar entries by
> > specifying a new menubar bean, but reuse the fileMenu, editMenu,
> > windowMenu and helpMenu.
> > 
> > But anyway this cannot be the final solution. We need a more
> > pluggable architecture for the commands context. What about a special
> > menubar bean that acts as a beanpostprocessor to search for menubar
> > entries? We then would need only a marker interface like MenubarEntry
> > for the commands that should be plugged into the menubar. Same could
> > go for the toolbar and the new-menu. You then would just have to
> > specify your additional menus, new-commands and toolbar commands and
> > could use the default-commands-context for the rest. We then should
> > provide the ability to specify multiple commands-contexts in the
> > advisor.
> 
> Hi folks,
> 
> I have been considering what would be required in order to enable OSGi 
> and Spring RCP to interoperate. The basic approach would be to provide 
> the application "shell", with a number of plug points, and allow OSGi 
> providers to register things like views/view descriptors, 
> commands/command descriptors, etc.
> 
> The thing that would need to change a fair amount is the 
> commands-context.xml that we have currently. At the moment, each 
> application window creates a whole new context by reading 
> commands-context.xml. This means that setting beans to be singletons, 
> etc is ineffective, since the bean is only a singleton *within that 
> context*, and the context is sourced anew for each application window.
> 
> One approach might be to introduce CommandDescriptors, from which 
> instances of the described Command are created, similarly to the 
> ViewDescriptors. This would allow OSGi plugins to register a 
> CommandDescriptor in the appropriate place, and this would still work 
> for multiple app windows.
> 
> Any comments? Am I overcomplicating things?
> 
> Rogan
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> 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] Serious FieldMetaData issue with generics? Test included.

[Benoit X. <bx...@ob...>]

The issue seems to be related to the Spring BeanWrapper! (I=92m using =
Spring
2.0.6)

    public static void main(String[] a) {

        IntSuper1 intSuper1 =3D new IntSuper1(123);

        BeanWrapper bw =3D new BeanWrapperImpl(intSuper1);

=20
System.out.println("+++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++
++++");

        System.out.println("name is of type:" + =
bw.getPropertyType("name"));

        System.out.println("id is of type:" + bw.getPropertyType("id"));

=20
System.out.println("+++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++
++++");

       =20

    }

=20

This returns the same value (incorrect imho)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

name is of type:class java.lang.String

id is of type:class java.lang.Object

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=20

Same if I use a generic directly like Super1<Integer> it still returns
Object as the type of =93id=94.

=20

Any suggestion apart from jumping off Tower Bridge?

=20

Thanks

=20

Benoit

=20

From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Benoit Xhenseval
Sent: 08 August 2007 00:56
To: spr...@li...
Subject: [Springframework-rcp-dev] Serious FieldMetaData issue with
generics? Test included.
Importance: High

=20

Dear All,

=20

I'm faced with what I believe is a serious issue in Spring RC.

=20

I enclose an example of a typical code that I now face following some
refactoring.

Basically my method getId() used to return int and now is returning =
Integer.

No sweat one would say but ALL forms fails on trying to convert Object =
to
String and String to Object!

=20

java.lang.IllegalArgumentException: No converter registered to convert =
from
sourceClass 'class java.lang.String' to target class 'class
java.lang.Object'

        at
org.springframework.binding.convert.support.GenericConversionService.getC=
onv
ersionExecutor(GenericConversionService.java:145)

        at
org.springframework.binding.form.support.AbstractFormModel.createConverti=
ngV
alueModel(AbstractFormModel.java:350)

        at
org.springframework.binding.form.support.AbstractFormModel.getValueModel(=
Abs
tractFormModel.java:294)

        at
org.springframework.richclient.form.binding.support.AbstractBinding.getVa=
lue
Model(AbstractBinding.java:114)

        at
org.springframework.richclient.form.binding.swing.TextComponentBinding.do=
Bin
dControl(TextComponentBinding.java:39)

        at
org.springframework.richclient.form.binding.support.AbstractBinding.creat=
eCo
ntrol(AbstractBinding.java:75)

        at
org.springframework.richclient.factory.AbstractControlFactory.getControl(=
Abs
tractControlFactory.java:85)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactor=
y.i
nterceptBinding(AbstractBindingFactory.java:92)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactor=
y.c
reateBinding(AbstractBindingFactory.java:70)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactor=
y.c
reateBinding(AbstractBindingFactory.java:55)

        at
org.springframework.richclient.form.builder.AbstractFormBuilder.createDef=
aul
tBinding(AbstractFormBuilder.java:78)

        at
org.springframework.richclient.form.builder.TableFormBuilder.add(TableFor=
mBu
ilder.java:109)

        at
org.springframework.richclient.form.builder.TableFormBuilder.add(TableFor=
mBu
ilder.java:85)

        at
net.objectlab.springtest.TestForm.createFormControl(TestForm.java:22)

=20

The issue relates to the use of generics.

=20

The output for the example below is:

=20

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

name is of type:class java.lang.String

id is of type:class java.lang.Object

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=20

I would have expected "id" to be of type java.lang.Integer.

=20

Has anyone faced this issue? Did you manage to find a workaround???=20

Please please!  I will also investigate the code in FielMetaData to try =
to
figure out what is happening.

=20

Many thanks!!

=20

Benoit

=20

----------------

=20

import org.springframework.binding.form.FormModel;

import org.springframework.richclient.form.FormModelHelper;

=20

public class GenericTest {

    public static void test() {

        IntSuper1 intSuper1 =3D new IntSuper1(123);

        FormModel model =3D FormModelHelper.createFormModel(intSuper1);

=20
System.out.println("+++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++
++++");

        System.out.println("name is of type:" +
model.getFieldMetadata("name").getPropertyType());

        System.out.println("id is of type:" +
model.getFieldMetadata("id").getPropertyType());

=20
System.out.println("+++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++
++++");

    }

   =20

    private static class Super1<T> {

        T id;

=20

        public Super1(T id) {

            this.id =3D id;

        }

=20

        public T getId() {

            return id;

        }

=20

        public void setId(T id) {

            this.id =3D id;

        }

    }

   =20

    private static class IntSuper1 extends Super1<Integer> {

        private String name;

=20

        public IntSuper1(Integer id) {

            super(id);

        }

=20

        public String getName() {

            return name;

        }

=20

        public void setName(String name) {

            this.name =3D name;

        }

    }

}

=20

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: =
06/08/2007
16:53

=20

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: =
06/08/2007
16:53


No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: =
06/08/2007
16:53
=20

[Springframework-rcp-dev] Serious FieldMetaData issue with generics? Test included.

[Benoit X. <bx...@ob...>]

Dear All,

 

I'm faced with what I believe is a serious issue in Spring RC.

 

I enclose an example of a typical code that I now face following some
refactoring.

Basically my method getId() used to return int and now is returning Integer.

No sweat one would say but ALL forms fails on trying to convert Object to
String and String to Object!

 

java.lang.IllegalArgumentException: No converter registered to convert from
sourceClass 'class java.lang.String' to target class 'class
java.lang.Object'

        at
org.springframework.binding.convert.support.GenericConversionService.getConv
ersionExecutor(GenericConversionService.java:145)

        at
org.springframework.binding.form.support.AbstractFormModel.createConvertingV
alueModel(AbstractFormModel.java:350)

        at
org.springframework.binding.form.support.AbstractFormModel.getValueModel(Abs
tractFormModel.java:294)

        at
org.springframework.richclient.form.binding.support.AbstractBinding.getValue
Model(AbstractBinding.java:114)

        at
org.springframework.richclient.form.binding.swing.TextComponentBinding.doBin
dControl(TextComponentBinding.java:39)

        at
org.springframework.richclient.form.binding.support.AbstractBinding.createCo
ntrol(AbstractBinding.java:75)

        at
org.springframework.richclient.factory.AbstractControlFactory.getControl(Abs
tractControlFactory.java:85)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactory.i
nterceptBinding(AbstractBindingFactory.java:92)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactory.c
reateBinding(AbstractBindingFactory.java:70)

        at
org.springframework.richclient.form.binding.support.AbstractBindingFactory.c
reateBinding(AbstractBindingFactory.java:55)

        at
org.springframework.richclient.form.builder.AbstractFormBuilder.createDefaul
tBinding(AbstractFormBuilder.java:78)

        at
org.springframework.richclient.form.builder.TableFormBuilder.add(TableFormBu
ilder.java:109)

        at
org.springframework.richclient.form.builder.TableFormBuilder.add(TableFormBu
ilder.java:85)

        at
net.objectlab.springtest.TestForm.createFormControl(TestForm.java:22)

 

The issue relates to the use of generics.

 

The output for the example below is:

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

name is of type:class java.lang.String

id is of type:class java.lang.Object

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

I would have expected "id" to be of type java.lang.Integer.

 

Has anyone faced this issue? Did you manage to find a workaround??? 

Please please!  I will also investigate the code in FielMetaData to try to
figure out what is happening.

 

Many thanks!!

 

Benoit

 

----------------

 

import org.springframework.binding.form.FormModel;

import org.springframework.richclient.form.FormModelHelper;

 

public class GenericTest {

    public static void test() {

        IntSuper1 intSuper1 = new IntSuper1(123);

        FormModel model = FormModelHelper.createFormModel(intSuper1);

 
System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++");

        System.out.println("name is of type:" +
model.getFieldMetadata("name").getPropertyType());

        System.out.println("id is of type:" +
model.getFieldMetadata("id").getPropertyType());

 
System.out.println("++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++");

    }

    

    private static class Super1<T> {

        T id;

 

        public Super1(T id) {

            this.id = id;

        }

 

        public T getId() {

            return id;

        }

 

        public void setId(T id) {

            this.id = id;

        }

    }

    

    private static class IntSuper1 extends Super1<Integer> {

        private String name;

 

        public IntSuper1(Integer id) {

            super(id);

        }

 

        public String getName() {

            return name;

        }

 

        public void setName(String name) {

            this.name = name;

        }

    }

}


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: 06/08/2007
16:53
 

Re: [Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Rogan D. <ro...@da...>]

Arne Limburg (JIRA) wrote:
> 
> 3) You are right. I have upgraded my patch.
> 
> 4) It is great for prototypes.
> 
> I don't think you have to refactor the advisor. These bean names are
> not magic anyway. You can change them via the menubarBeanName and
> toolbarBeanName properties in DefaultApplicationLifecycleAdvisor.
> With this you can also change the toolbar without the need of
> specifying any menubar. You only need to include my
> commands-context.xml into yours, provide your own toolbar-bean and
> set its name in the advisor. You can also add new menubar entries by
> specifying a new menubar bean, but reuse the fileMenu, editMenu,
> windowMenu and helpMenu.
> 
> But anyway this cannot be the final solution. We need a more
> pluggable architecture for the commands context. What about a special
> menubar bean that acts as a beanpostprocessor to search for menubar
> entries? We then would need only a marker interface like MenubarEntry
> for the commands that should be plugged into the menubar. Same could
> go for the toolbar and the new-menu. You then would just have to
> specify your additional menus, new-commands and toolbar commands and
> could use the default-commands-context for the rest. We then should
> provide the ability to specify multiple commands-contexts in the
> advisor.

Hi folks,

I have been considering what would be required in order to enable OSGi 
and Spring RCP to interoperate. The basic approach would be to provide 
the application "shell", with a number of plug points, and allow OSGi 
providers to register things like views/view descriptors, 
commands/command descriptors, etc.

The thing that would need to change a fair amount is the 
commands-context.xml that we have currently. At the moment, each 
application window creates a whole new context by reading 
commands-context.xml. This means that setting beans to be singletons, 
etc is ineffective, since the bean is only a singleton *within that 
context*, and the context is sourced anew for each application window.

One approach might be to introduce CommandDescriptors, from which 
instances of the described Command are created, similarly to the 
ViewDescriptors. This would allow OSGi plugins to register a 
CommandDescriptor in the appropriate place, and this would still work 
for multiple app windows.

Any comments? Am I overcomplicating things?

Rogan

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25262 ] 

Arne Limburg commented on RCP-165:
----------------------------------

3) You are right. I have upgraded my patch.

4) It is great for prototypes.

I don't think you have to refactor the advisor. These bean names are not magic anyway. You can change them via the menubarBeanName and toolbarBeanName properties in DefaultApplicationLifecycleAdvisor. With this you can also change the toolbar without the need of specifying any menubar. You only need to include my commands-context.xml into yours, provide your own toolbar-bean and set its name in the advisor. You can also add new menubar entries by specifying a new menubar bean, but reuse the fileMenu, editMenu, windowMenu and helpMenu.

But anyway this cannot be the final solution. We need a more pluggable architecture for the commands context. What about a special menubar bean that acts as a beanpostprocessor to search for menubar entries? We then would need only a marker interface like MenubarEntry for the commands that should be plugged into the menubar. Same could go for the toolbar and the new-menu. You then would just have to specify your additional menus, new-commands and toolbar commands and could use the default-commands-context for the rest. We then should provide the ability to specify multiple commands-contexts in the advisor.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arne Limburg updated RCP-165:
-----------------------------

    Attachment: RCP-165.patch

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25231 ] 

Jan Hoskens commented on RCP-165:
---------------------------------

Some remarks:

3) You've bypassed the ApplicationPageFactory by directly creating a DefaultApplicationPage in the openWindow. I think we should let the factory handle the null case.

4) why are you providing a commands-context that will always be overruled and hence unneeded? I can imagine starting a new app from an archetype which does provide something like this, but I don't see why we would include a sample-xml with the rcp-support-jar. Can't we opt to have an empty menu or no menu at all instead? 

Besides this, I would like to refactor the advisor in order to remove these magic bean names so anyone who would like to have menu or/and toolbar can define this with the advisor in a more clear way. This would also allow to reuse menu's in other apps (think of suites or so).

WDYT?

Thanks for the patch!

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

Re: [Springframework-rcp-dev] To bean or not to bean. => Class based formmodels

[Vamsi P. <vpu...@gm...>]

Hi Geoffrey,

I have a question:

how do I integrate persistence into the AbstractDetailForm, I have extended
this form to add it into the commit method. This propogates the commited bu=
t
unsaved instance to the master side. Is there a better place for me to
commit the form model, persist it and propogagte it back to the form model?

Thanks


Vamsi

On 7/23/07, Geoffrey De Smet <ge0...@gm...> wrote:
>
> +1  to creating a FormModel based on a Class (or interface)
>
> We 've discussed this before, but no one felt strong enough to implement
> it:
>
>
> Replay of an old mail of mine "Class based formmodels - WDYT"
>
> =3D=3D=3D
> Currently form models are instance based.
> - they can't handle null values. A possible use case for a null value
> could be the details form of a master-detail view when nothing is
> selected. I think Larry had to sort of hack that.
> - it limits us from dependency injecting forms (as they need a form
> model based on an instance)
>
> Should they be class based,
> just like ORM mappings are also class based?
> What do you think?
>
>
> Backward compatibility can be ensured like this:
>
> public FormModel(Object o) {
>     this(o.getClass());
>     setFormObject(o);
> }
> =3D=3D=3D
>
> spring-core always uses bean instances, but spring-core is an
> initialization framework NOT a binding framework.
> jpa, hibernate, toplink are class based, they are binding frameworks (to
> the database instead of the gui however).
>
> With kind regards,
> Geoffrey De Smet
>
> Benoit Xhenseval schreef:
> > Hi all,
> >
> > I agree with Jan's case and go further in that replacing the form objec=
t
> > seems to trigger some strange behaviour due to the call to reset. I'm
> not
> > sure it is actually required... surely not in all cases anyway.
> >
> > This is especially true if one has a lot of "business" logic hanging of
> the
> > model (things handled by PropertyListeners on some properties). Changin=
g
> the
> > formObject then has a massive ripple effect due to the reset call, it
> then
> > requires some specific code to simply "be ignored!".  I did raise this
> about
> > a year ago as I was facing exactly the case of having to provide a
> 'dummy'
> > bean before asking the user for the Id of the bean and then fetch it an=
d
> > display it by calling setFormObject... I'd like FormModel to be able to
> take
> > a class/interface.
> >
> > It would also be useful to have the ability to enable / disable ALL
> > PropertyListeners in the subsequent ValueModels. So one could have a
> 'dead'
> > form, set the object, then enable logic for handling potential changes.
> >
> > I'd like to add that a parametizable/generics FormModel would also be
> useful
> > I think. But that would either require a move to 1.5 or to be in the
> tiger
> > module. Furthermore, it would be useful to provide helper methods on
> > ValueModel to get an Integer, a String, a Date, a BigDecimal... that
> would
> > remove much casting... Again, use of generics could help.
> >
> > In any case, please do not break dramatically the existing interfaces..=
.
> >
> > My =A30.02 worth comments,
> >
> > Thanks
> >
> > Benoit
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behal=
f
> Of
> > Rogan Dawes
> > Sent: 20 July 2007 10:05
> > To: spr...@li...
> > Subject: Re: [Springframework-rcp-dev] To bean or not to bean.
> >
> > Jan Hoskens wrote:
> >> Hi all,
> >>
> >
> >> The second issue is the main thing I've been pondering of: to bean or
> >> not to bean. Should we create the formModel based on beans (current
> >> situation) or based on class/interface? We could create a FormModel
> >> based on a class/interface, then set a FormObject when needed and
> >> provide a null handling. The method getFormObject might actually retur=
n
> >> null while no default constructor is needed. No bean at creation time
> is
> >> needed. Now for al this magic to happen, I need to inform you that the
> >> current implementation does rely on the beans plumbing of spring. This
> >> isn't bad, but does mean a that some serious refactoring/implementing
> is
> >> needed before this will work. Before I jump into this pit, I'm
> wondering
> >> if this all makes sense. Is this worth the trip? Would you benefit fro=
m
> >> this change? I'm guessing it would, but I'd like to have some feedback
> >> on this first.
> >>
> >> ps: it might be that these things have been surfaced a while ago and
> >> that I'm just reopening the discussion. Haven't yet searched the mail
> >> archive. (I remember whining about this a year or so ago, but did I
> mail
> >> it??)
> >>
> >> Kind Regards,
> >> Jan
> >
> > Hi Jan,
> >
> > Not having worked very heavily with FormModels, but struggling when I
> > did, I agree with your analysis.
> >
> > It DOES make more sense to have the FormModel based on a Class or
> > Interface, rather than an instance.
> >
> > Rogan
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 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
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date:
> 19/07/2007
> > 18:10
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.10/908 - Release Date:
> 19/07/2007
> > 18:10
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25201 ] 

Arne Limburg commented on RCP-165:
----------------------------------

My first patch is included in the second so you may savely delete the Application.java.patch

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arne Limburg updated RCP-165:
-----------------------------

    Attachment: RCP-165.patch

I have taken a closer look at the task of providing a nice default configuration for spring-richclient.

With my changes (applied in the second patch above) a spring-richclient-application is able to start up without configuring anything. The application context can look like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="application" class="org.springframework.richclient.application.Application"/>
</beans>

A spring-richclient application is even able to start without an application context this way:

Application application = new Application();
application.afterPropertiesSet();
application.start();

This is what I did:

1. Added a default constructor to Application, that creates a DefaultApplicationLifecycleAdvisor
2. Removed the assertion in afterPropertiesSet of ApplicationLifecycleAdvisor, that checks if the startingPageId is set  (I don't need the startingPageId to be set any more, if the developer wants to start with an empty page, why not?)
3. Added code to openWindow of Application to handle null pageDescriptorId (i.e. startingPageId)
4. Setting a default-location for the windowCommandBarDefinitions in DefaultApplicationLifecycleAdvisor. I created a default-commands-context for this.
5. Added a check in Application.services() wether the ApplicationServicesLocator-singleton is initialized (for this I added the method isLoaded in ApplicationServicesLocator). If it is not, it will be initialized there with DefaultApplicationServices.
6. Fixed a bug in getImage of Application leading to an Exception when no application-image is configured.
7. Changed imageSourceImplBuilder, messageSourceImplBuilder and applicationObjectConfigurerImplBuilder in DefaultApplicationServices to use org/springframework/richclient/image/images.properties and org/springframework/richclient/application/messages.properties as default. For this I had to change getApplicationContext in DefaultApplicationServices to always return a non-null (but empty) application-context to avoid a NullPointerException when accessing the application-context.
8. At the last I added newCommand.label and newCommand.caption to messages.properties and newCommand.icon, saveCommand.icon, printCommand.icon and propertiesCommand.icon to images.properties to support my commands-context

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arne Limburg updated RCP-165:
-----------------------------

    Attachment: Application.java.patch

This patch enables a spring-richclient application to start without an image-source configured.
It catches the NoSuchImageResourceException in getImage() if no such source is configured.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Oliver Hutchison
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-221) Shadowed logger

[Kevin S. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Stembridge resolved RCP-221.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.3.0

Patch applied. Thanks Yudhi.

> Shadowed logger
> ---------------
>
>                 Key: RCP-221
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-221
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>            Reporter: Geoffrey De Smet
>            Assignee: Kevin Stembridge
>            Priority: Trivial
>             Fix For: 0.3.0
>
>         Attachments: RCP-221.patch
>
>
> The logger in AbstractControlFactory  shadows the one in ApplicationServicesAccessor:
> public abstract class AbstractControlFactory extends ApplicationServicesAccessor implements ControlFactory {
>     protected Log logger = LogFactory.getLog(getClass());
>     //...
> }
> public class ApplicationServicesAccessor {
>     protected final Log logger = LogFactory.getLog(getClass());
>     //...
> }

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

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-408) MessageDialog's ok button should be the default button (enter key should press it)

[Kevin S. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Stembridge resolved RCP-408.
----------------------------------

    Resolution: Fixed

Patch applied. Thanks very much Yudhi.

The reason that the OK button was not being set as the default was because the message dialog uses an underlying JTextPane, which will 'hijack' the ENTER key. 

See this JRootPane javadoc:
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JRootPane.html#setDefaultButton(javax.swing.JButton)



> MessageDialog's ok button should be the default button (enter key should press it)
> ----------------------------------------------------------------------------------
>
>                 Key: RCP-408
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-408
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Dialog System
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Kevin Stembridge
>            Priority: Minor
>             Fix For: 0.3.0
>
>         Attachments: RCP-408.patch
>
>
> Now it's not the default button, so when a login succeeds, you have to press escape (instead of enter) to press it.

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

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-453) LabelInfoFactory will be deprecated in favour of a factory method on LabelInfo itself

[Kevin S. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Stembridge resolved RCP-453.
----------------------------------

    Resolution: Fixed

> LabelInfoFactory will be deprecated in favour of a factory method on LabelInfo itself
> -------------------------------------------------------------------------------------
>
>                 Key: RCP-453
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-453
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 0.2.1
>         Environment: All
>            Reporter: Kevin Stembridge
>            Assignee: Kevin Stembridge
>            Priority: Minor
>             Fix For: 0.3.0
>
>
> This issue relates to an improvement to the way that LabelInfo instances can be created. In particular, the removal of the LabelInfoFactory class and the addition of a factory method on the LabelInfo class. The reasoning behind this change is explained below.
> Using LabelInfoFactory, a LabelInfo can be created in 3 ways:
> 1. Create a new LabelInfoFactory using the no-args constructor, then set the encodedLabel, then call createLabelInfo().
> 2. Create a new LabelInfoFactory using the constructor that takes the encodedLabel as an argument, then call createLabelInfo().
> 3. Call the static method that takes an encodedLabel. 
> Note that the implementation of option 3 just performs option 2.
> There is no reason to store the encodedLabel in a public instance variable. The class could be stateless and provide only a static factory method. 
> So if LabelInfoFactory is whittled down to a single static factory method, the next question to ask is 'Do we need to allow for pluggable syntaxes?', whereby users may choose to use a different syntax to the one currently used. 
> If so, then the factory should become an interface, with the existing LabelInfoFactory being the default implementation. 
> If not, then there doesn't seem to be any need to separate the creation of a LabelInfo from the LabelInfo class itself. It would be better to add a static createLabelInfo(String  encodedLabel) method to the LabelInfo class and do away with the factory altogether. 
> After discussions on the dev mailing list, the second approach was considered to be the best choice because:
> * It doesn't seem unreasonable to ask users to work with the syntax we have already defined because the only special characters we are using are &, @ and the KeyStrokes  that are part of the core Java API, e.g. ctrl.
> * The other approach would add complexity by requiring the factory implementation to be injected into all the classes that need to create LabelInfo objects, some of which may not be created by the Spring IoC container.

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