springframework-rcp-dev — Spring Rich Client developer list

Re: [Springframework-rcp-dev] Change request for InputApplicationDialog

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

I have two classes, one extends AbstractDialogPage - this is actually where 
most of the code resides.  The other extends ApplicationDialog and provides a 
few lines of glue code to make it easier to associate it with a particular 
SDO "type" (equivalent to a Class) from the XML config.  So my XML might look 
something like this:

----------
  <bean
    id="personEditorDialog"
    class="com.mypackage.client.gui.TypeEditDialog">

    <property name="editPage">
      <ref bean="personEditor"/>
    </property>

    <property name="resizable"><value>true</value></property>
  </bean>

  <bean
    id="personEditor"
    class="com.mypackage.client.gui.EntityEditor">

    <property name="entityType"><ref bean="personType"/></property>
    <property name="propertiesToEdit">
      <list>
        <ref bean="pdPrefix"/>
        <ref bean="pdFirstName"/>
        <ref bean="pdMiddleName"/>
        <ref bean="pdLastName"/>
        <ref bean="pdSuffix"/>
      </list>
    </property>
  </bean>

-------
The "pdPrefix", etc.. beans are simple objects that describe the property to 
the editor (type, validation, GUI display name, etc).

Someday I'm going to take the time to see how difficult it would be to switch 
over to what you've provided in spring-rcp. :-)



On Wednesday 09 June 2004 10:10 am, Keith Donald wrote:
> Andy,
>
> Just curious - are you subclassing ApplicationDialog with your new
> InputApplicationDialog?  Just making sure the root dialog class hierarchy
> is meeting your needs.
>
> Keith

Re: [Springframework-rcp-dev] Change request for InputApplicationDialog

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

These are good ideas.  I should note that in my dialog I copy the values from 
the PropertyEditors to the actual data object when OK is pressed, but I do 
as-you-type validation via property change events on the PropertyEditors.  In 
my case, anyway, I get the best of both worlds. :-)

On Wednesday 09 June 2004 10:05 am, Keith Donald wrote:
> I agree the framework should support different modes of validating /
> binding....
>
> I've favored the "as you type" mode because it is the most impressive
> looking IMO, but it should be quite possible to fire validation on an "OK"
> click for example, as a typical command pattern type submit.  In that case,
> an error dialog would need to popup showing the validation errors that
> occurred, and binding would occur as part of the submit, onCancel() would
> do nothing as you said.
>
> So with that said, the modes I think we need are:
> 1 - as you type validation with a real-time results reporting pane on the
> dialog, and binding occurring on submit only.  The validation framework has
> to be able to handle proposed property changes and validate them against
> some context (at a minimum existing property of the bean, but we probably
> need to support other variables as well.)
>
> 2 - validation / binding occur together on submit only
>
> 3 - is as you type binding + validation (what we have now) an option we
> want?  Or does the copy issue just rule it out completely?
>
> - anything else I missed?
>
> I'll have to take a step back and see what I can put together to address
> some of these issues.
>
> Ronald - can you or someone else give me an example of different rules on
> the same object based on some context (or use case?)? For example, insert
> vs. update rules? I'm pretty sure that is a necessary requirement for the
> validation framework, I'll just like a concrete example to work a test case
> off of.  Thanks - Keith

RE: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Keith D. <kd...@cs...>]

Ronald,

Forgot to mention: the existing InputApplicationDialog has another
constructor too, that if you use, just creates a standard text field.  The
text field's input value then gets passed into the onFinish(Object
inputValue) template method when OK is clicked, which you can then grab and
do what you need with.  The setInputConstraint() method will allow you to
place a input constraint on the value, preventing submit from occurring.
All of this happens without any binding to a bean whatsoever.  

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ronald Haring
Sent: Wednesday, June 09, 2004 11:27 AM
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] Change request for
InputApplicationDialog


thanks, but you are right, the big issue is to bind or not to bind. I 
realized later that I could just as easily write my
own dialog, especially with the nice new integration you made for 
jgoodies forms (nice one btw)

Ronald


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

RE: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Keith D. <kd...@cs...>]

Andy,

Just curious - are you subclassing ApplicationDialog with your new
InputApplicationDialog?  Just making sure the root dialog class hierarchy is
meeting your needs.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Andy Depue
Sent: Wednesday, June 09, 2004 12:29 PM
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] Change request for
InputApplicationDialog

I've run into a similar situation as well.  I am using something modelled 
after "Service Data Objects" in my code and because of time constraints
wrote 
my own input dialog since SDOs use a different style of property access.  
However, I have found that I can still use PropertyEditors with my SDOs 
(PropertyEditors are pretty independent of any actual property access 
scheme).  Since PropertyEditors can store a property's value independent of 
the property, I use PropertyEditors to store the property value while
editing 
and tie everything to the PropertyEditor instead of the actual property.  If

the user hits Cancel, I simply do nothing.  If they hit OK, I copy the value

from the PropertyEditor to the actual property.  I haven't looked at the 
binder and validation code enough to know if this approach even makes sense 
for them, but I thought I'd throw it out.


On Wednesday 09 June 2004 06:48 am, Keith Donald wrote:
> I've been wresting with this issue myself.
>
> I think the larger question is what is the correct behavior for the bean
> binder + validation framework here?
>
> To support the as-you-type-validation, the binder is updating the property
> on each keystroke.  This then triggers revalidation of the declarative
> validation rules associated with this property.  The rules validate the
> bean object as a whole, which allows validation of the new property value
> in the context of other bean properties (for example, that firstName is
not
> equal to lastName, or whatever.)  So basically, the reason the binder
binds
> to the bean, is because the validation system evaluates the bean as a
> whole, not just the property value along with a passed in, unmodified
> reference to the bean.
>
> But I completely see the point it, especially in a client side
environment,
> not to modify the bean (even transiently) until a "finish" commit has been
> invoked.  So the issue to figure out is how to best support this.
>
> Should we:
>
> Enhance the validation system to take a new "proposed" property value and
> an unmodified instance of the bean as a context variable to use to support
> validation against other properties (or possibly other objects?)  Maybe it
> doesn't seem wise to assume validating the bean as a whole is good
> enough... (though it is simpler.)  In this case, the binder won't actually
> do any binding, but will just do validation & reporting.  The binding will
> need to happen on a commit, which will be on the finish button.
>
> Or
>
> Continue the behavior is, but have the dialog class make a copy, and
> restore it on cancel?  This seems, like you said, easy to forget.
>
> Hmm...
>
> In the meantime I can add a setter to the field.  No problem.
>
> Keith


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

RE: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Keith D. <kd...@cs...>]

I agree the framework should support different modes of validating /
binding....

I've favored the "as you type" mode because it is the most impressive
looking IMO, but it should be quite possible to fire validation on an "OK"
click for example, as a typical command pattern type submit.  In that case,
an error dialog would need to popup showing the validation errors that
occurred, and binding would occur as part of the submit, onCancel() would do
nothing as you said.

So with that said, the modes I think we need are:
1 - as you type validation with a real-time results reporting pane on the
dialog, and binding occurring on submit only.  The validation framework has
to be able to handle proposed property changes and validate them against
some context (at a minimum existing property of the bean, but we probably
need to support other variables as well.)

2 - validation / binding occur together on submit only

3 - is as you type binding + validation (what we have now) an option we
want?  Or does the copy issue just rule it out completely?

- anything else I missed?

I'll have to take a step back and see what I can put together to address
some of these issues.  

Ronald - can you or someone else give me an example of different rules on
the same object based on some context (or use case?)? For example, insert
vs. update rules? I'm pretty sure that is a necessary requirement for the
validation framework, I'll just like a concrete example to work a test case
off of.  Thanks - Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Andy Depue
Sent: Wednesday, June 09, 2004 12:29 PM
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] Change request for
InputApplicationDialog

I've run into a similar situation as well.  I am using something modelled 
after "Service Data Objects" in my code and because of time constraints
wrote 
my own input dialog since SDOs use a different style of property access.  
However, I have found that I can still use PropertyEditors with my SDOs 
(PropertyEditors are pretty independent of any actual property access 
scheme).  Since PropertyEditors can store a property's value independent of 
the property, I use PropertyEditors to store the property value while
editing 
and tie everything to the PropertyEditor instead of the actual property.  If

the user hits Cancel, I simply do nothing.  If they hit OK, I copy the value

from the PropertyEditor to the actual property.  I haven't looked at the 
binder and validation code enough to know if this approach even makes sense 
for them, but I thought I'd throw it out.


On Wednesday 09 June 2004 06:48 am, Keith Donald wrote:
> I've been wresting with this issue myself.
>
> I think the larger question is what is the correct behavior for the bean
> binder + validation framework here?
>
> To support the as-you-type-validation, the binder is updating the property
> on each keystroke.  This then triggers revalidation of the declarative
> validation rules associated with this property.  The rules validate the
> bean object as a whole, which allows validation of the new property value
> in the context of other bean properties (for example, that firstName is
not
> equal to lastName, or whatever.)  So basically, the reason the binder
binds
> to the bean, is because the validation system evaluates the bean as a
> whole, not just the property value along with a passed in, unmodified
> reference to the bean.
>
> But I completely see the point it, especially in a client side
environment,
> not to modify the bean (even transiently) until a "finish" commit has been
> invoked.  So the issue to figure out is how to best support this.
>
> Should we:
>
> Enhance the validation system to take a new "proposed" property value and
> an unmodified instance of the bean as a context variable to use to support
> validation against other properties (or possibly other objects?)  Maybe it
> doesn't seem wise to assume validating the bean as a whole is good
> enough... (though it is simpler.)  In this case, the binder won't actually
> do any binding, but will just do validation & reporting.  The binding will
> need to happen on a commit, which will be on the finish button.
>
> Or
>
> Continue the behavior is, but have the dialog class make a copy, and
> restore it on cancel?  This seems, like you said, easy to forget.
>
> Hmm...
>
> In the meantime I can add a setter to the field.  No problem.
>
> Keith


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] Change request for InputApplicationDialog

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

I've run into a similar situation as well.  I am using something modelled 
after "Service Data Objects" in my code and because of time constraints wrote 
my own input dialog since SDOs use a different style of property access.  
However, I have found that I can still use PropertyEditors with my SDOs 
(PropertyEditors are pretty independent of any actual property access 
scheme).  Since PropertyEditors can store a property's value independent of 
the property, I use PropertyEditors to store the property value while editing 
and tie everything to the PropertyEditor instead of the actual property.  If 
the user hits Cancel, I simply do nothing.  If they hit OK, I copy the value 
from the PropertyEditor to the actual property.  I haven't looked at the 
binder and validation code enough to know if this approach even makes sense 
for them, but I thought I'd throw it out.


On Wednesday 09 June 2004 06:48 am, Keith Donald wrote:
> I've been wresting with this issue myself.
>
> I think the larger question is what is the correct behavior for the bean
> binder + validation framework here?
>
> To support the as-you-type-validation, the binder is updating the property
> on each keystroke.  This then triggers revalidation of the declarative
> validation rules associated with this property.  The rules validate the
> bean object as a whole, which allows validation of the new property value
> in the context of other bean properties (for example, that firstName is not
> equal to lastName, or whatever.)  So basically, the reason the binder binds
> to the bean, is because the validation system evaluates the bean as a
> whole, not just the property value along with a passed in, unmodified
> reference to the bean.
>
> But I completely see the point it, especially in a client side environment,
> not to modify the bean (even transiently) until a "finish" commit has been
> invoked.  So the issue to figure out is how to best support this.
>
> Should we:
>
> Enhance the validation system to take a new "proposed" property value and
> an unmodified instance of the bean as a context variable to use to support
> validation against other properties (or possibly other objects?)  Maybe it
> doesn't seem wise to assume validating the bean as a whole is good
> enough... (though it is simpler.)  In this case, the binder won't actually
> do any binding, but will just do validation & reporting.  The binding will
> need to happen on a commit, which will be on the finish button.
>
> Or
>
> Continue the behavior is, but have the dialog class make a copy, and
> restore it on cancel?  This seems, like you said, easy to forget.
>
> Hmm...
>
> In the meantime I can add a setter to the field.  No problem.
>
> Keith

Re: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Ronald H. <ro...@co...>]

Yes, this is a difficult issue, not just on the client side. I've had 
the same issue with the web framework
(get a value object by hibernate, bind the servletrequestdatabinder to 
the object, validate it and upon
validation find out that it isnt valid, for instance an unique non-key 
field isnt unique and then finding out
that hibernate has already marked the bean as dirty and saved it),but 
its even more tricky with the
as you type validators.

>Should we:
>
>Enhance the validation system to take a new "proposed" property value and an
>unmodified instance of the bean as a context variable to use to support
>validation against other properties (or possibly other objects?)  Maybe it
>doesn't seem wise to assume validating the bean as a whole is good enough...
>(though it is simpler.)  In this case, the binder won't actually do any
>binding, but will just do validation & reporting.  The binding will need to
>happen on a commit, which will be on the finish button.
>  
>

This seems like a Good Thing to me. As I understand it now, you change 
the value immediately so you
can validate the value. To validate the value you must know which rule 
to invoke and this is defined by
changes to a specific field from a specific bean. This then also means 
that the beans can not be validated
depending on application context (e.g. update or insert mode can have 
different rules) so there should be
some programming rules as well.


>Or
>
>Continue the behavior is, but have the dialog class make a copy, and restore
>it on cancel?  This seems, like you said, easy to forget.
>  
>
Yes, and this will lead to annoying bugs and loss of confidence in the 
framework by the users of the framework

>In the meantime I can add a setter to the field.  No problem.
>  
>

thanks, but you are right, the big issue is to bind or not to bind. I 
realized later that I could just as easily write my
own dialog, especially with the nice new integration you made for 
jgoodies forms (nice one btw)

Ronald

RE: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Francois B. <fb...@us...>]

Hi !

On Wed, 9 Jun 2004 09:48:08 -0400, "Keith Donald" <kd...@cs...>
said:
[snip]
> Enhance the validation system to take a new "proposed" property value and
> an
> unmodified instance of the bean as a context variable to use to support
> validation against other properties (or possibly other objects?)  Maybe

It might be better to pass in a Map of changed values...  Since a
property might depend on the new value of another property ?  Say, a unit
and a numeric value (1 in, 2 cm).

> it
> doesn't seem wise to assume validating the bean as a whole is good
> enough...
> (though it is simpler.)  In this case, the binder won't actually do any
> binding, but will just do validation & reporting.  The binding will need
> to
> happen on a commit, which will be on the finish button.
>=20
> Or
>=20
> Continue the behavior is, but have the dialog class make a copy, and
> restore
> it on cancel?  This seems, like you said, easy to forget.

If the Dialog does that by itself, checking if the object can be cloned,
could be "correct", I believe.  If the object is non-cloneable, what do
you do ?  Make a new instance, and copy the values over ?  What about
references to other objects ?

Just some thoughts...

Bye !
Fran=E7ois
--
CareerNudge.com - http://www.careernudge.com/
Contact management for your professional and personal life

RE: [Springframework-rcp-dev] Strange TextField behaviour

[Keith D. <kd...@cs...>]

Thomas,

Isn't this weird?  setOverwriteMode(true) is the default.  I've changed =
it
to false, but then it's ALWAYS in overwrite mode, INSERT doesn't toggle =
it.
Do you know if this is a bug in JFormattedTextField?  I already have a
PatchedJFormattedTextField to correct one bug, if this is another I'll
likely need to add in a INS key binding to toggle the overwrite on the
formatter.  Any other ideas?

Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Achleitner Thomas
Sent: Wednesday, June 09, 2004 2:24 AM
To: spr...@li...
Subject: [Springframework-rcp-dev] Strange TextField behaviour

Hi!

Running the rcp petclinic sample app (and in my applications, too) i am
observing strange behaviour of the text fields. They are always in
overwrite mode. It seems that this occurs with the DefaultFormatter
passed to the TextField.=20

thomas

Thomas Achleitner
Abteilung IT - Entwicklung
ECOLOG Logistiksysteme GmbH
Bauernstra=DFe 11, A-4600 Wels
Tel ++43/7242/66200
Fax ++43/7242/66200-200
mailto:ac...@ec...
http://www.ecolog.at =20
=20


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

RE: [Springframework-rcp-dev] Change request for InputApplicationDialog

[Keith D. <kd...@cs...>]

I've been wresting with this issue myself.

I think the larger question is what is the correct behavior for the bean
binder + validation framework here?

To support the as-you-type-validation, the binder is updating the property
on each keystroke.  This then triggers revalidation of the declarative
validation rules associated with this property.  The rules validate the bean
object as a whole, which allows validation of the new property value in the
context of other bean properties (for example, that firstName is not equal
to lastName, or whatever.)  So basically, the reason the binder binds to the
bean, is because the validation system evaluates the bean as a whole, not
just the property value along with a passed in, unmodified reference to the
bean.

But I completely see the point it, especially in a client side environment,
not to modify the bean (even transiently) until a "finish" commit has been
invoked.  So the issue to figure out is how to best support this.

Should we:

Enhance the validation system to take a new "proposed" property value and an
unmodified instance of the bean as a context variable to use to support
validation against other properties (or possibly other objects?)  Maybe it
doesn't seem wise to assume validating the bean as a whole is good enough...
(though it is simpler.)  In this case, the binder won't actually do any
binding, but will just do validation & reporting.  The binding will need to
happen on a commit, which will be on the finish button.

Or

Continue the behavior is, but have the dialog class make a copy, and restore
it on cancel?  This seems, like you said, easy to forget.

Hmm...

In the meantime I can add a setter to the field.  No problem.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ronald Haring
Sent: Wednesday, June 09, 2004 9:03 AM
To: Spr...@li...
Subject: [Springframework-rcp-dev] Change request for InputApplicationDialog

Hi Keith,

I'm having some problems with the InputApplicationDialog in combination 
with the beanBinder.
Problem exists when I insert a bean, show the dialog, change the value 
and then press cancel. I would expect that the value will not be 
changed, but by using the bean binder, the value will automatically be 
saved. Thats not what is wanted in the cancel action. I could solve this 
problem, by making a copy before I call the input dialog and set the 
copy as the bean that the dialog should work with and then with the 
onfinisch, copy these values to the orginial bean. However that means 
that I will always have to remember to make copies. I will forget that 
at some time (and there might be additional problems with creating a new 
bean and hibernate trying to save it).

So what I would rather like to do, is to create it without the bean 
binder and in the onfinish copy the value to the bean. However, that 
means that I must be able to set the input field, and that is private 
now. So could you add a setter for this field or do you see another 
solution?

Ronald


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] Change request for InputApplicationDialog

[Ronald H. <em...@ro...>]

Hi Keith,

I'm having some problems with the InputApplicationDialog in combination 
with the beanBinder.
Problem exists when I insert a bean, show the dialog, change the value 
and then press cancel. I would expect that the value will not be 
changed, but by using the bean binder, the value will automatically be 
saved. Thats not what is wanted in the cancel action. I could solve this 
problem, by making a copy before I call the input dialog and set the 
copy as the bean that the dialog should work with and then with the 
onfinisch, copy these values to the orginial bean. However that means 
that I will always have to remember to make copies. I will forget that 
at some time (and there might be additional problems with creating a new 
bean and hibernate trying to save it).

So what I would rather like to do, is to create it without the bean 
binder and in the onfinish copy the value to the bean. However, that 
means that I must be able to set the input field, and that is private 
now. So could you add a setter for this field or do you see another 
solution?

Ronald

[Springframework-rcp-dev] Strange TextField behaviour

[Achleitner T. <ac...@ec...>]

Hi!

Running the rcp petclinic sample app (and in my applications, too) i am
observing strange behaviour of the text fields. They are always in
overwrite mode. It seems that this occurs with the DefaultFormatter
passed to the TextField.=20

thomas

Thomas Achleitner
Abteilung IT - Entwicklung
ECOLOG Logistiksysteme GmbH
Bauernstra=DFe 11, A-4600 Wels
Tel ++43/7242/66200
Fax ++43/7242/66200-200
mailto:ac...@ec...
http://www.ecolog.at =20
=20

[Springframework-rcp-dev] RE: [Acegisecurity-developer] how can GUI ask if an operation will be permited or not?

[Ben A. <ben...@ac...>]

> > > Thank you very much for the explanation. Just another
> > > possible solution occurred to me:
> > >
> > > 1) to define "ask" functions like this in secured beans:
> > >
> > > public boolean canModify(MyBean obj) {
> > >   return true;
> > > }
> > > public boolen canInsert() {
> > >   return true;
> > > }
> > >
> > > 2) apply to those functions the required roles in the
> > > MethodSecurityInterceptor definition
> > >
> > > sample.contact.ContactManager.save=CONTACT_OWNED_BY_CURRENT_USER
> > > 
> sample.contact.ContactManager.canModify=CONTACT_OWNED_BY_CURRENT_USER
> > >
> > > 3) then those functions can be safely called because in case
> > > of Granted access they will return true and will not perform
> > > any action and in case of denied access they will throw 
> an exception:
> > >
> > > try {
> > >   myService.canModify(myBean);
> > >   // access granted code
> > > } catch (AccessDeniedException ex) {
> > >   // access denied code
> > > }
> >
> > Hi Karel
> >
> > Yes, that would indeed work. There are so many ways of approaching
> Swing...
> >
> > For instance, I'm using JGoodies Swing Suite and its nice binding
> framework
> > (although you can implement bound bean properties pretty 
> easily yourself).
> > GrantedAuthority[]s get placed in a bound bean property on 
> the client side
> > after login. This fires a property change event, which all menu bar
> > builders, tool bar builders and views have registered to 
> receive. Each
> view
> > then re-evaluates whether it will provide services to the user and
> > enables/disables itself as appropriate. Bound properties 
> are also used for
> > the username and password. What does that buy us? Well, we can have
> > login/logout as a menu option without manually invoking a process to
> > enable/disable menus, toolbars and views. We can also have 
> a "refresh
> > security" menu option or automated background process, to 
> keep the user's
> > current GrantedAuthority[]s accurate as well respond 
> appropriately if the
> > account becomes disabled. If our manager bean is coded to 
> support it, we
> > could also make this background process detect if the 
> application as a
> whole
> > has been disabled, or will be shutdown at a given future 
> time, to automate
> > the shutdown or change the state of the Swing client.
> >
> > Best regards
> > Ben

> Ben,
> 
> Could you provide some code samples ?

Unfortunately providing code samples of what we use is difficult because it
all subclasses JGoodies code. However, Keith Donald is doing a great job on
Spring RCP. Once RCP is a little further developed I'll be able to write a
few RCP-specific classes to integrate Acegi Security login, action
validation etc for those interested. This can be part of the RCP or Acegi
Security projects, so people can get a jump-start on developing secure rich
clients.

If anyone needs anything urgently, please let me know and I can find out
from Keith the status of the different components we'd need in RCP.

Best regards
Ben

Re: [Springframework-rcp-dev] Relation between application, mainwindow and perspective

[Ronald H. <mo...@co...>]

> Do you mean an open new window action?

Well, not completely, I think. It does replace the menubar and toolbar,
but it doesnt open a new window. Right now (with the fixes I made) I've
got it working, but then if I leave the menu for views up, I will see all
the views that are defined, and not just the views that should be
available in this 'window'.

I'm not familiar with eclipse and the swt. I will look into it a bit, but
what I think should be possible is the following:
- a set of definitions that are MainWindow objects.
- each mainWindow object should have one menubar and toolbar (both
optional) and have a set of views. Each view can enable or disable the
visible menubars or toolbars, but shouldnt replace/add or remove them.
Thats the duty of the mainwindow object. This way you can have related
tasks live in the same mainwindow, but you can also switch to different
tasks. For instance, an administration screen, should not be available in
the main view, since these views will probably have little to do with the
regular application. Your vision seems bigger, better, faster then what I
think is necessary so I will just greet that vision with a big "Yee"

Ronald

> My vision is to provide the capability to open multiple windows within
> the application, where each window displays exactly one unique page
> (whose template is defined by a perspective), and where each perspective
> supports a distinct user task, consisting of one or more
> dockable/stackable views.  In this vision, a page's views may contribute
> their own items to the action bars when they are activated, thus
> allowing dynamic action bar
> reconfiguration to support different tasks.  This is very similar to the
> capability offered by Eclipse's RCP platform; in fact, I'm using the
> same terminology for the most part as I really like it.

>
> Besides defining a general model for the different objects and their
> interaction, and an API for managing action contribution policies at
> runtime, I have not yet had the time to make much progress yet in this
> area, unfortunately.
>
> This is one area where the Eclipse RCP platform really excels.  A
> logical question would be why reinvent the wheel if Eclipse already
> provides this, and that's a valid point.  The main driver thus far has
> been to prove you can build an as-capable, integrating system directly
> on-top of the swing toolkit, without requiring a dependency on the
> platform-dependent and less mature SWT, as well as the more complex
> eclipse plug-in model, using spring as the runtime container for
> configuration.  The vision is to integrate products from the swing
> community into a platform built on spring, which makes it easy for
> existing spring users to hit the ground running with a rich client app.
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Ronald Haring
> Sent: Monday, June 07, 2004 9:35 AM
> To: spr...@li...
> Subject: [Springframework-rcp-dev] Relation between application,
> mainwindow and perspective
>
> Hi Keith,
>
> next question from me.
>
> Right now I have a small application with a menu, toolbar and some
> panels. Now I've added a button on the toolbar. The behaviour I would
> like is that after pressing this button, the previous menu and toolbar
> and window should be replaced by another definitions. I've got this
> working now, by changing some stuff in the application and in
> applicationwindow, so this probably isnt the right way to do it, or isnt
> this in the framework yet?
>
> Here's how I've done it:
> org.springframework.rcp.application.ApplicationWindow:
> added a setter for windowControl.
>
> changed the public void openPage(String perspectiveName) as follows:
>         if (windowControl == null) {
>             this.windowControl = createWindowControl(page,
> this.windowControl);
>         }
> 	else {
> 		this.windowControl.getContentPane().removeAll();
> 		this.windowControl = createWindowControl(page,
> this.windowControl);
> 	}
>
> changed the private JFrame createWindowControl(ApplicationPage page) to
> private JFrame createWindowControl(ApplicationPage page, JFrame window)
> {
> 	if (window == null) {
>         	window = new JFrame();
> 	}
>
> and in Application, added the following to existing openWindow.
> public void openWindow(String perspectiveName) {
> 	ApplicationWindow mainWindow =
> (ApplicationWindow)getApplicationContext().getBean(perspectiveName);
> 	if (mainWindow == null) {
> 		logger.error("Unable to locate a main application window in
> context.");
> 	}
> 	mainWindow.setControl(getActiveWindow().getControl());
> 	activeWindow = mainWindow;
> 	mainWindow.openPage("defaultPerspective");
>     }
>
> but then I ran into the problem, that the ApplicationWindow doesnt know
> anything about perspectives. This got me wondering about the relations
> between the upper objects. How are they related?
>
> So I changed the openWindow to:
>
> public void openWindow(String perspectiveName) {
> 	ApplicationWindow mainWindow =
> (ApplicationWindow)getApplicationContext().getBean(perspectiveName);
> 	if (mainWindow == null) {
> 		logger.error("Unable to locate a main application window in
> context.");
> 	}
> 	mainWindow.setControl(getActiveWindow().getControl());
> 	activeWindow = mainWindow;
>     }
>
> and let the calling actionHandler set the page I would like to see (e.g.
> public class OpenRolesWindow implements ActionHandler {
>   public void performAction(String actionId) {
> 	Application.locator().openWindow("roleWindow");
> 	Application.locator().getActiveWindow().openPage("rolePerspective");
>   }
> }
>
> Is this the way it should be done, or should I start investigating VB?
> :)
>
> Ronald
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] Relation between application, mainwindow and perspective

[Keith D. <kd...@cs...>]

Do you mean an open new window action?  

I am all for that behavior, but you're right, we don't yet currently have
support for it.

My vision is to provide the capability to open multiple windows within the
application, where each window displays exactly one unique page (whose
template is defined by a perspective), and where each perspective supports a
distinct user task, consisting of one or more dockable/stackable views.  In
this vision, a page's views may contribute their own items to the action
bars when they are activated, thus allowing dynamic action bar
reconfiguration to support different tasks.  This is very similar to the
capability offered by Eclipse's RCP platform; in fact, I'm using the same
terminology for the most part as I really like it.  

Besides defining a general model for the different objects and their
interaction, and an API for managing action contribution policies at
runtime, I have not yet had the time to make much progress yet in this area,
unfortunately.

This is one area where the Eclipse RCP platform really excels.  A logical
question would be why reinvent the wheel if Eclipse already provides this,
and that's a valid point.  The main driver thus far has been to prove you
can build an as-capable, integrating system directly on-top of the swing
toolkit, without requiring a dependency on the platform-dependent and less
mature SWT, as well as the more complex eclipse plug-in model, using spring
as the runtime container for configuration.  The vision is to integrate
products from the swing community into a platform built on spring, which
makes it easy for existing spring users to hit the ground running with a
rich client app.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ronald Haring
Sent: Monday, June 07, 2004 9:35 AM
To: spr...@li...
Subject: [Springframework-rcp-dev] Relation between application, mainwindow
and perspective

Hi Keith,

next question from me.

Right now I have a small application with a menu, toolbar and some panels.
Now I've added a button on the toolbar. The behaviour I would like is that
after pressing this button, the previous menu and toolbar and window
should be replaced by another definitions. I've got this working now, by
changing some stuff in the application and in applicationwindow, so this
probably isnt the right way to do it, or isnt this in the framework yet?

Here's how I've done it:
org.springframework.rcp.application.ApplicationWindow:
added a setter for windowControl.

changed the public void openPage(String perspectiveName) as follows:
        if (windowControl == null) {
            this.windowControl = createWindowControl(page,
this.windowControl);
        }
	else {
		this.windowControl.getContentPane().removeAll();
		this.windowControl = createWindowControl(page,
this.windowControl);
	}

changed the private JFrame createWindowControl(ApplicationPage page) to
private JFrame createWindowControl(ApplicationPage page, JFrame window) {
	if (window == null) {
        	window = new JFrame();
	}

and in Application, added the following to existing openWindow.
public void openWindow(String perspectiveName) {
	ApplicationWindow mainWindow =
(ApplicationWindow)getApplicationContext().getBean(perspectiveName);
	if (mainWindow == null) {
		logger.error("Unable to locate a main application window in
context.");
	}
	mainWindow.setControl(getActiveWindow().getControl());
	activeWindow = mainWindow;
	mainWindow.openPage("defaultPerspective");
    }

but then I ran into the problem, that the ApplicationWindow doesnt know
anything about perspectives. This got me wondering about the relations
between the upper objects. How are they related?

So I changed the openWindow to:

public void openWindow(String perspectiveName) {
	ApplicationWindow mainWindow =
(ApplicationWindow)getApplicationContext().getBean(perspectiveName);
	if (mainWindow == null) {
		logger.error("Unable to locate a main application window in
context.");
	}
	mainWindow.setControl(getActiveWindow().getControl());
	activeWindow = mainWindow;
    }

and let the calling actionHandler set the page I would like to see (e.g.
public class OpenRolesWindow implements ActionHandler {
  public void performAction(String actionId) {
	Application.locator().openWindow("roleWindow");
	Application.locator().getActiveWindow().openPage("rolePerspective");
  }
}

Is this the way it should be done, or should I start investigating VB?  :)

Ronald





-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] Remarks rcp project and images

[Keith D. <kd...@cs...>]

Ronald,

I've relaxed the behavior; the icon source will now return null if no icon
could be resolved using the specified key, or if the key simply didn't exist
in the bundle to begin with.  getIcon() will log resolve failures at INFO
log level.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
admin
Sent: Monday, June 07, 2004 9:03 AM
To: spr...@li...
Subject: RE: [Springframework-rcp-dev] Remarks rcp project and images

Keith,

concerning the messages, I am happy right now. For instance, I created a
wizard dialog, and on the buttons it said dialog.ok and dialog.cancel.
>From that point its obvious to me, that I should (eventually) replace
those messages in the resources, but it isnt that important right now (or
at least not that important that the application should end). So if the
message isnt found, the key is displayed, and that is perfect behaviour to
me. Of course you could argue that in the end I will have to replace those
messages so it is perfect behaviour to let the application crash, but its
not very kind to us programmers, who try hard to reach time limits.

Ronald

> Ronald,
>
> What I could do is have the out-of-the-box components instantiate their
> own default images, instead of relying soley on the image source.
>
> I could add a similar getImage(String key, Image defaultImage) message
> as well, similar to MessageSource.
>
> I agree I'm probably being a bit strict.
>
> One other thing-I've added a "shared" images.properties file in
> org/springframework/rcp/image which has sensible defaults for all of the
> pre-packaged component icons.  The petclinic image source is now using
> the images from there, as well as its own image.properties.
>
> A similar question is raised in regards to messages.  Would you prefer
> the prepackaged components attempt to resolve their own messages?  Or do
> we put that burden on the client, and have the components just display
> what they're told?  On one hand encapsulating message resolution saves
> the client some trouble, on the other, is it what the client always
> wants?
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Ronald Haring
> Sent: Monday, June 07, 2004 8:35 AM
> To: spr...@li...
> Subject: RE: [Springframework-rcp-dev] Remarks rcp project and images
>
>> Ronald,
>>
>> Let me share what the behavior is right now; let me know what you guys
>> think:
>>
>> 1. getIcon() in the iconSource, delegates to get the underlying Awt
>> Image out of the getImage() in the imageSource.
>> 2. If the imageSource finds a matching image key, it attempts to
>> resolve a image from the Resource location (and subsequently cache
>> it.)  If it is unable to access the location, a broken image indicator
>> is returned. 3. HOWEVER, if te imageSource finds no matching key, a
>> NoSuchImageResource exception is found.  This behavior is consistent
>> with Spring's MessageSource implementations.
>>
>> I guess I could relax it to return <null>, or also return the
>> brokenImageIndicator if no key is found, but I guess I preferred the
>> more stringent exception case where -- if you pass in a invalid
>> resource key -- really indicates a configuration error, while
>> accessing a valid key who's location may be "temporarily" unavailable
>> is more likely something that needs to be handled (e.g. hence, the
>> broken image indicator.)
>>
>> What do you guys think?
>>
>> Keith
>
> Ok, I understand why you choose that behaviour. Yet the "annoyance"
> starts when you use one of your predefined components (for instance
> TitleDialog) and the application crashes because there is no
> titleDialog.icon defined. Maybe its possible to define a default blank
> image or default java image when it isnt set, or show a message on the
> error console and just carry on, since if an icon cant be found, that
> doesnt look like such a serious exception that the complete application
> should end.
>
> Ronald
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev





-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] Relation between application, mainwindow and perspective

[Ronald H. <mo...@co...>]

Hi Keith,

next question from me.

Right now I have a small application with a menu, toolbar and some panels.
Now I've added a button on the toolbar. The behaviour I would like is that
after pressing this button, the previous menu and toolbar and window
should be replaced by another definitions. I've got this working now, by
changing some stuff in the application and in applicationwindow, so this
probably isnt the right way to do it, or isnt this in the framework yet?

Here's how I've done it:
org.springframework.rcp.application.ApplicationWindow:
added a setter for windowControl.

changed the public void openPage(String perspectiveName) as follows:
        if (windowControl == null) {
            this.windowControl = createWindowControl(page,
this.windowControl);
        }
	else {
		this.windowControl.getContentPane().removeAll();
		this.windowControl = createWindowControl(page, this.windowControl);
	}

changed the private JFrame createWindowControl(ApplicationPage page) to
private JFrame createWindowControl(ApplicationPage page, JFrame window) {
	if (window == null) {
        	window = new JFrame();
	}

and in Application, added the following to existing openWindow.
public void openWindow(String perspectiveName) {
	ApplicationWindow mainWindow =
(ApplicationWindow)getApplicationContext().getBean(perspectiveName);
	if (mainWindow == null) {
		logger.error("Unable to locate a main application window in context.");
	}
	mainWindow.setControl(getActiveWindow().getControl());
	activeWindow = mainWindow;
	mainWindow.openPage("defaultPerspective");
    }

but then I ran into the problem, that the ApplicationWindow doesnt know
anything about perspectives. This got me wondering about the relations
between the upper objects. How are they related?

So I changed the openWindow to:

public void openWindow(String perspectiveName) {
	ApplicationWindow mainWindow =
(ApplicationWindow)getApplicationContext().getBean(perspectiveName);
	if (mainWindow == null) {
		logger.error("Unable to locate a main application window in context.");
	}
	mainWindow.setControl(getActiveWindow().getControl());
	activeWindow = mainWindow;
    }

and let the calling actionHandler set the page I would like to see (e.g.
public class OpenRolesWindow implements ActionHandler {
  public void performAction(String actionId) {
	Application.locator().openWindow("roleWindow");
	Application.locator().getActiveWindow().openPage("rolePerspective");
  }
}

Is this the way it should be done, or should I start investigating VB?  :)

Ronald

RE: [Springframework-rcp-dev] Remarks rcp project and images

[admin <ad...@co...>]

Keith,

concerning the messages, I am happy right now. For instance, I created a
wizard dialog, and on the buttons it said dialog.ok and dialog.cancel.
From that point its obvious to me, that I should (eventually) replace
those messages in the resources, but it isnt that important right now (or
at least not that important that the application should end). So if the
message isnt found, the key is displayed, and that is perfect behaviour to
me. Of course you could argue that in the end I will have to replace those
messages so it is perfect behaviour to let the application crash, but its
not very kind to us programmers, who try hard to reach time limits.

Ronald

> Ronald,
>
> What I could do is have the out-of-the-box components instantiate their
> own default images, instead of relying soley on the image source.
>
> I could add a similar getImage(String key, Image defaultImage) message
> as well, similar to MessageSource.
>
> I agree I'm probably being a bit strict.
>
> One other thing-I've added a "shared" images.properties file in
> org/springframework/rcp/image which has sensible defaults for all of the
> pre-packaged component icons.  The petclinic image source is now using
> the images from there, as well as its own image.properties.
>
> A similar question is raised in regards to messages.  Would you prefer
> the prepackaged components attempt to resolve their own messages?  Or do
> we put that burden on the client, and have the components just display
> what they're told?  On one hand encapsulating message resolution saves
> the client some trouble, on the other, is it what the client always
> wants?
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Ronald Haring
> Sent: Monday, June 07, 2004 8:35 AM
> To: spr...@li...
> Subject: RE: [Springframework-rcp-dev] Remarks rcp project and images
>
>> Ronald,
>>
>> Let me share what the behavior is right now; let me know what you guys
>> think:
>>
>> 1. getIcon() in the iconSource, delegates to get the underlying Awt
>> Image out of the getImage() in the imageSource.
>> 2. If the imageSource finds a matching image key, it attempts to
>> resolve a image from the Resource location (and subsequently cache
>> it.)  If it is unable to access the location, a broken image indicator
>> is returned. 3. HOWEVER, if te imageSource finds no matching key, a
>> NoSuchImageResource exception is found.  This behavior is consistent
>> with Spring's MessageSource implementations.
>>
>> I guess I could relax it to return <null>, or also return the
>> brokenImageIndicator if no key is found, but I guess I preferred the
>> more stringent exception case where -- if you pass in a invalid
>> resource key -- really indicates a configuration error, while
>> accessing a valid key who's location may be "temporarily" unavailable
>> is more likely something that needs to be handled (e.g. hence, the
>> broken image indicator.)
>>
>> What do you guys think?
>>
>> Keith
>
> Ok, I understand why you choose that behaviour. Yet the "annoyance"
> starts when you use one of your predefined components (for instance
> TitleDialog) and the application crashes because there is no
> titleDialog.icon defined. Maybe its possible to define a default blank
> image or default java image when it isnt set, or show a message on the
> error console and just carry on, since if an icon cant be found, that
> doesnt look like such a serious exception that the complete application
> should end.
>
> Ronald
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

RE: [Springframework-rcp-dev] Remarks rcp project and images

[Keith D. <kd...@cs...>]

Ronald,

What I could do is have the out-of-the-box components instantiate their own
default images, instead of relying soley on the image source.

I could add a similar getImage(String key, Image defaultImage) message as
well, similar to MessageSource.

I agree I'm probably being a bit strict.

One other thing-I've added a "shared" images.properties file in
org/springframework/rcp/image which has sensible defaults for all of the
pre-packaged component icons.  The petclinic image source is now using the
images from there, as well as its own image.properties.

A similar question is raised in regards to messages.  Would you prefer the
prepackaged components attempt to resolve their own messages?  Or do we put
that burden on the client, and have the components just display what they're
told?  On one hand encapsulating message resolution saves the client some
trouble, on the other, is it what the client always wants?

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Ronald Haring
Sent: Monday, June 07, 2004 8:35 AM
To: spr...@li...
Subject: RE: [Springframework-rcp-dev] Remarks rcp project and images

> Ronald,
>
> Let me share what the behavior is right now; let me know what you guys
> think:
>
> 1. getIcon() in the iconSource, delegates to get the underlying Awt
> Image out of the getImage() in the imageSource.
> 2. If the imageSource finds a matching image key, it attempts to resolve
> a image from the Resource location (and subsequently cache it.)  If it
> is unable to access the location, a broken image indicator is returned.
> 3. HOWEVER, if te imageSource finds no matching key, a
> NoSuchImageResource exception is found.  This behavior is consistent
> with Spring's MessageSource implementations.
>
> I guess I could relax it to return <null>, or also return the
> brokenImageIndicator if no key is found, but I guess I preferred the
> more stringent exception case where -- if you pass in a invalid resource
> key -- really indicates a configuration error, while accessing a valid
> key who's location may be "temporarily" unavailable is more likely
> something that needs to be handled (e.g. hence, the broken image
> indicator.)
>
> What do you guys think?
>
> Keith

Ok, I understand why you choose that behaviour. Yet the "annoyance" starts
when you use one of your predefined components (for instance TitleDialog)
and the application crashes because there is no titleDialog.icon defined.
Maybe its possible to define a default blank image or default java image
when it isnt set, or show a message on the error console and just carry
on, since if an icon cant be found, that doesnt look like such a serious
exception that the complete application should end.

Ronald





-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

RE: [Springframework-rcp-dev] Remarks rcp project and images

[Ronald H. <rh...@co...>]

> Ronald,
>
> Let me share what the behavior is right now; let me know what you guys
> think:
>
> 1. getIcon() in the iconSource, delegates to get the underlying Awt
> Image out of the getImage() in the imageSource.
> 2. If the imageSource finds a matching image key, it attempts to resolve
> a image from the Resource location (and subsequently cache it.)  If it
> is unable to access the location, a broken image indicator is returned.
> 3. HOWEVER, if te imageSource finds no matching key, a
> NoSuchImageResource exception is found.  This behavior is consistent
> with Spring's MessageSource implementations.
>
> I guess I could relax it to return <null>, or also return the
> brokenImageIndicator if no key is found, but I guess I preferred the
> more stringent exception case where -- if you pass in a invalid resource
> key -- really indicates a configuration error, while accessing a valid
> key who's location may be "temporarily" unavailable is more likely
> something that needs to be handled (e.g. hence, the broken image
> indicator.)
>
> What do you guys think?
>
> Keith

Ok, I understand why you choose that behaviour. Yet the "annoyance" starts
when you use one of your predefined components (for instance TitleDialog)
and the application crashes because there is no titleDialog.icon defined.
Maybe its possible to define a default blank image or default java image
when it isnt set, or show a message on the error console and just carry
on, since if an icon cant be found, that doesnt look like such a serious
exception that the complete application should end.

Ronald

RE: [Springframework-rcp-dev] Remarks rcp project and images

[Keith D. <kd...@cs...>]

Ronald,

Let me share what the behavior is right now; let me know what you guys
think:

1. getIcon() in the iconSource, delegates to get the underlying Awt Image
out of the getImage() in the imageSource.
2. If the imageSource finds a matching image key, it attempts to resolve a
image from the Resource location (and subsequently cache it.)  If it is
unable to access the location, a broken image indicator is returned.
3. HOWEVER, if te imageSource finds no matching key, a NoSuchImageResource
exception is found.  This behavior is consistent with Spring's MessageSource
implementations.

I guess I could relax it to return <null>, or also return the
brokenImageIndicator if no key is found, but I guess I preferred the more
stringent exception case where -- if you pass in a invalid resource key --
really indicates a configuration error, while accessing a valid key who's
location may be "temporarily" unavailable is more likely something that
needs to be handled (e.g. hence, the broken image indicator.)

What do you guys think?

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
admin
Sent: Monday, June 07, 2004 7:50 AM
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] Remarks rcp project and images

Pressed Send too soon again, the annoyance is caused by the following:

    public AwtImageResource getImageResource(String key) {
        Assert.notNull(key);
        Resource resource = (Resource)imageResources.get(key);
        if (resource == null) { throw new
NoSuchImageResourceException(key); }
        return new AwtImageResource(resource);
    }

The NoSuchImageResourceException isnt caught.

After changing org.springframework.rcp.image.DefaultImageIconSource method
getIcon(String key) to catch the exception, everything is rolling along
again.

    public Icon getIcon(String key) {
	try {
        	return (ImageIcon)cache.get(key);
	}
	catch (NoSuchImageResourceException e) {
		return null;
	}
    }

Ronald

> Hi Keith,
>
> after trying some things with the framework so far, I want to share one
> annoyance I have found so far: the icons and their requirements. It
> looks like almost every component needs to have an icon or the system
> will crash with assert errors. Is it possible to make this a little less
> stringent?
>
> Ronald
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev





-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] Remarks rcp project and images

[admin <ad...@co...>]

Pressed Send too soon again, the annoyance is caused by the following:

    public AwtImageResource getImageResource(String key) {
        Assert.notNull(key);
        Resource resource = (Resource)imageResources.get(key);
        if (resource == null) { throw new
NoSuchImageResourceException(key); }
        return new AwtImageResource(resource);
    }

The NoSuchImageResourceException isnt caught.

After changing org.springframework.rcp.image.DefaultImageIconSource method
getIcon(String key) to catch the exception, everything is rolling along
again.

    public Icon getIcon(String key) {
	try {
        	return (ImageIcon)cache.get(key);
	}
	catch (NoSuchImageResourceException e) {
		return null;
	}
    }

Ronald

> Hi Keith,
>
> after trying some things with the framework so far, I want to share one
> annoyance I have found so far: the icons and their requirements. It
> looks like almost every component needs to have an icon or the system
> will crash with assert errors. Is it possible to make this a little less
> stringent?
>
> Ronald
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>>From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] Remarks rcp project and images

[Ronald H. <rh...@co...>]

Hi Keith,

after trying some things with the framework so far, I want to share one
annoyance I have found so far: the icons and their requirements. It looks
like almost every component needs to have an icon or the system will crash
with assert errors. Is it possible to make this a little less stringent?

Ronald

RE: [Springframework-rcp-dev] Dumb Question

[Keith D. <kd...@cs...>]

The globalActionRegistry is defined in view-context.xml in the petclinic
sample, within the ui package.  It is a registry for actions that are shared
/ re-targeted between views; for example, cut, copy, paste, delete,
properties.

 

I've changed its definition is not required to startup the application;
however, if you need global actions you will need to define one for now.  I
will be enhancing the startup application configuration capability to
support programmatic configuration in-line with the enhanced lifecycle
support I brought up in a previous email to Ronald soon.

 

Keith

 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Andrew - Development
Sent: Sunday, June 06, 2004 6:31 PM
To: Spring Framework Rich Client Platform
Subject: RE: [Springframework-rcp-dev] Dumb Question

 

Keith,
Thanks for that, sorted out the problem with those messages. However, the
app now fails with this:
Looking in the petclinic app, I don't see anything related to
globalActionRegistry.?

org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'application' defined in class path resource
[org/ats/hrm/application-context.xml]: Initialization of bean failed; nested
exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'globalActionRegistry' is defined:
org.springframework.beans.factory.support.DefaultListableBeanFactory
defining beans
[application,applicationInfo,messageSource,applicationObjectConfigurer,mainW
indow]; Root of BeanFactory hierarchy
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'globalActionRegistry' is defined:
org.springframework.beans.factory.support.DefaultListableBeanFactory
defining beans
[application,applicationInfo,messageSource,applicationObjectConfigurer,mainW
indow]; Root of BeanFactory hierarchy
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean
Definition(DefaultListableBeanFactory.java:242)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getMergedBeanD
efinition(AbstractBeanFactory.java:498)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:143)
at
org.springframework.context.support.AbstractApplicationContext.getBean(Abstr
actApplicationContext.java:399)
at
org.springframework.rcp.application.Application.setupActionHandling(Applicat
ion.java:256)
at
org.springframework.rcp.application.Application.initApplicationContext(Appli
cation.java:203)
at
org.springframework.context.support.ApplicationObjectSupport.setApplicationC
ontext(ApplicationObjectSupport.java:79)
at
org.springframework.context.support.ApplicationContextAwareProcessor.postPro
cessBeforeInitialization(ApplicationContextAwareProcessor.java:65)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFact
ory.java:138)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:248)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:177)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:159)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInst
antiateSingletons(DefaultListableBeanFactory.java:183)
at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:268)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(Cl
assPathXmlApplicationContext.java:68)
at
org.springframework.rcp.application.startup.ApplicationLauncher.launch(Appli
cationLauncher.java:115)
at
org.springframework.rcp.application.startup.ApplicationLauncher.<init>(Appli
cationLauncher.java:81)
at org.ats.hrm.HRM.main(HRM.java:14)


On Sun, 2004-06-06 at 23:05, Keith Donald wrote: 

Andrew,

 

Your message source bean definition looks fine to me, pulling messages from
the root of your classpath, which I assume to be the /src directory.  Plus,
if there was a problem initializing the message source locations, it would
certainly tell you.

 

Do you have an application object configurer bean defined in your context?
See the petclinic application-context.xml example.  What this does is
configure all application objects by bean name after they are instantiated
by spring.  It is a bean post processor.  This is used to wire up
internationalized display properties for making those objects fit for
display in the GUI.  So for example, when the "applicationInfo" bean is
instantiated, the configurer will lookup the title, caption, and description
from the message source (applicationInfo.title, applicationInfo.caption,
applicationInfo.description, respectively) and inject them into your
ApplicationInfo bean.  Without the configurer defined, none of this will
happen.

 

The configurer is there to remove a good deal of the configuration you must
specify in the context file.  You don't have to use it, but I recommend it.
If you don't, you must fully define all required properties in the context
file.

 

Keith

 

  _____  



From:spr...@li...
[mailto:spr...@li...] On Behalf Of
Andrew Todd
Sent: Sunday, June 06, 2004 5:10 PM
To: Spring Framework Rich Client Platform
Subject: [Springframework-rcp-dev] Dumb Question


 

Obviously this will be a dumb question, but I can't get the
message.properties file to be read, which causes the application NOT to load
- error about label required.
Now, I have my messages.properties file in the src directory 
My application-context.xml has:
<?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.rcp.application.Application">
    <constructor-arg index="0">
        <ref bean="applicationInfo"/>
    </constructor-arg>
  </bean>

  <bean id="applicationInfo"
class="org.springframework.rcp.application.ApplicationInfo">
  <property name="version"><value>1.0</value></property>
  <property name="buildId"><value>20040530001</value></property>
  </bean>

<bean  id="messageSource" 
 
class="org.springframework.context.support.ResourceBundleMessageSource">
    <property name="basenames">
    <list>
    <value>messages</value>
    </list>
    </property>
  </bean>
</beans>

My messages.properties file has:
applicationInfo.title=Test Application
applicationInfo.caption=Test Application Caption, Spring RCP
applicationInfo.description=Test Spring RCP

And what happens is that the two properties in the application exist fine,
but the properties from messages.properties does not - obviously a problem
with the messageSource section of the application-context, but what?

My directory structure is:
/src
/src/messages.properties
/src/org/at/Start.java
/resources/application-context.xml





Andrew



  


Andrew - DEV 

 

RE: [Springframework-rcp-dev] Dumb Question

[Andrew - D. <at....@ds...>]

Keith,
Thanks for that, sorted out the problem with those messages. However,
the app now fails with this:
Looking in the petclinic app, I don't see anything related to
globalActionRegistry.?

org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'application' defined in class path resource
[org/ats/hrm/application-context.xml]: Initialization of bean failed;
nested exception is
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'globalActionRegistry' is defined:
org.springframework.beans.factory.support.DefaultListableBeanFactory
defining beans
[application,applicationInfo,messageSource,applicationObjectConfigurer,mainWindow]; Root of BeanFactory hierarchy
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'globalActionRegistry' is defined:
org.springframework.beans.factory.support.DefaultListableBeanFactory
defining beans
[application,applicationInfo,messageSource,applicationObjectConfigurer,mainWindow]; Root of BeanFactory hierarchy
	at
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:242)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getMergedBeanDefinition(AbstractBeanFactory.java:498)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:143)
	at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:399)
	at
org.springframework.rcp.application.Application.setupActionHandling(Application.java:256)
	at
org.springframework.rcp.application.Application.initApplicationContext(Application.java:203)
	at
org.springframework.context.support.ApplicationObjectSupport.setApplicationContext(ApplicationObjectSupport.java:79)
	at
org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:65)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:138)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:248)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159)
	at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:183)
	at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268)
	at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:68)
	at
org.springframework.rcp.application.startup.ApplicationLauncher.launch(ApplicationLauncher.java:115)
	at
org.springframework.rcp.application.startup.ApplicationLauncher.<init>(ApplicationLauncher.java:81)
	at org.ats.hrm.HRM.main(HRM.java:14)


On Sun, 2004-06-06 at 23:05, Keith Donald wrote:

> Andrew,
> 
>  
> 
> Your message source bean definition looks fine to me, pulling messages
> from the root of your classpath, which I assume to be the /src
> directory.  Plus, if there was a problem initializing the message
> source locations, it would certainly tell you.
> 
>  
> 
> Do you have an application object configurer bean defined in your
> context?  See the petclinic application-context.xml example.  What
> this does is configure all application objects by bean name after they
> are instantiated by spring.  It is a bean post processor.  This is
> used to wire up internationalized display properties for making those
> objects fit for display in the GUI.  So for example, when the
> “applicationInfo” bean is instantiated, the configurer will lookup the
> title, caption, and description from the message source
> (applicationInfo.title, applicationInfo.caption,
> applicationInfo.description, respectively) and inject them into your
> ApplicationInfo bean.  Without the configurer defined, none of this
> will happen.
> 
>  
> 
> The configurer is there to remove a good deal of the configuration you
> must specify in the context file.  You don’t have to use it, but I
> recommend it.  If you don’t, you must fully define all required
> properties in the context file.
> 
>  
> 
> Keith
> 
>  
> 
>                                    
> ______________________________________________________________________
> 
> From:spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Andrew Todd
> Sent: Sunday, June 06, 2004 5:10 PM
> To: Spring Framework Rich Client Platform
> Subject: [Springframework-rcp-dev] Dumb Question
> 
> 
>  
> 
> Obviously this will be a dumb question, but I can't get the
> message.properties file to be read, which causes the application NOT
> to load - error about label required.
> Now, I have my messages.properties file in the src directory 
> My application-context.xml has:
> <?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.rcp.application.Application">
>     <constructor-arg index="0">
>         <ref bean="applicationInfo"/>
>     </constructor-arg>
>   </bean>
> 
>   <bean id="applicationInfo"
> class="org.springframework.rcp.application.ApplicationInfo">
>   <property name="version"><value>1.0</value></property>
>   <property name="buildId"><value>20040530001</value></property>
>   </bean>
> 
> <bean  id="messageSource" 
>      
> class="org.springframework.context.support.ResourceBundleMessageSource">
>     <property name="basenames">
>     <list>
>     <value>messages</value>
>     </list>
>     </property>
>   </bean>
> </beans>
> 
> My messages.properties file has:
> applicationInfo.title=Test Application
> applicationInfo.caption=Test Application Caption, Spring RCP
> applicationInfo.description=Test Spring RCP
> 
> And what happens is that the two properties in the application exist
> fine, but the properties from messages.properties does not - obviously
> a problem with the messageSource section of the application-context,
> but what?
> 
> My directory structure is:
> /src
> /src/messages.properties
> /src/org/at/Start.java
> /resources/application-context.xml
> 
> 
> 
> Andrew
> 
> 
>  

Andrew - DEV