As 0.3 signals a fairly mature, stable release I fill confident that
the functionality is there to start thinking about an official 1.0
release.
Here are the items on my list, grouped by priority:
HIGH
- Add validation for binding expressions (since Beans Binding does not
do it on its own). This will close the last hole in the JB
functionality that allows you to specify invalid bindings and only
finding out about it via manual testing
- Unit tests for all core functionality (progress has been made on
0.3, but our coverage is still fairly minimal)
- Add DimensionAsValueHandler from Alexandre (sorry that I forgot to
add it in 0.3) and deprecate some of the existing property handlers it
makes obsolete
- finish the PDF book and finally implement some of the comments and
sample apps from this forum
MEDIUM
- add support for action handlers that get wired automatically using a
naming convention, e.g. "okButtonAction()"
- create a PDF cheat sheet of all component properties that can be
used in the YAML file (preferably based off reflection and parsing of
the JavaBuilderConfig, to avoid manual coding)
Feel free to comment on these and suggest any new ones. I'd like to
make sure Swing JavaBuilder 1.0 becomes the best way to create user
interfaces in Swing by a wide margin compared to anything else.
Some feedbacks on the missing features in Swing Java Builder :
On the core Swing Java Builder :
- Validation : possibility to have a validation more sophisticated than just a popup by default like jgoodies https://validation.dev.java.net/images/validationdemo.png or https://bean-properties.dev.java.net/ - Binding : possibility to bind easy an arrayList with a JList (I don't succeed to have it, maybe it is already possible, if it is the case, how?),
- At least javabuilder-core and swingjavabuilder in Central Maven Repo (I can create a patch to do that, Jacek). I asked to upload all the dependencies needed and all are in the Central Maven Repo.
- The yaml lib used is anymore maintained, maybe switch to another lib like http://code.google.com/p/jvyamlb/ if it is not complicated to migrate (better after 1.0)
On extensions :
- A reflexion how to integrate Java Builder better than just making panel with a RCP; Netbeans RCP for Swing and Eclipse RCP for SWT.
I think a lot of firms which make Rich Client (Swing or SWT) use or will use in the future a RCP. For instance, in my firm (an famous Investment Banking) we use often Netbeans RCP (with JavaBuilder on the last one). In JP Morgan, they use Eclipse RCP (http://www.eclipsecon.org/2007/index.php?page=sub/&id=3842).
If some have ideas about it, I will implement it (notably on NetBeans RCP) in Swing Java Builder Ext.
Plugin :
- A eclipse plugin to have completion and validation on yaml. It is the last drawback of using JavaBuidler versus coding by the hand.
Jacek Furmankiewicz wrote:
> As 0.3 signals a fairly mature, stable release I fill confident that
> the functionality is there to start thinking about an official 1.0
> release.
> Here are the items on my list, grouped by priority:
> HIGH
> - Add validation for binding expressions (since Beans Binding does not
> do it on its own). This will close the last hole in the JB
> functionality that allows you to specify invalid bindings and only
> finding out about it via manual testing
> - Unit tests for all core functionality (progress has been made on
> 0.3, but our coverage is still fairly minimal)
> - Add DimensionAsValueHandler from Alexandre (sorry that I forgot to
> add it in 0.3) and deprecate some of the existing property handlers it
> makes obsolete
> - finish the PDF book and finally implement some of the comments and
> sample apps from this forum
> MEDIUM
> - add support for action handlers that get wired automatically using a
> naming convention, e.g. "okButtonAction()"
> - create a PDF cheat sheet of all component properties that can be
> used in the YAML file (preferably based off reflection and parsing of
> the JavaBuilderConfig, to avoid manual coding)
> Feel free to comment on these and suggest any new ones. I'd like to
> make sure Swing JavaBuilder 1.0 becomes the best way to create user
> interfaces in Swing by a wide margin compared to anything else.
Alexandre, can you log all of these as separate enhancement requests?
I will definitely look at the binding issue...it requires custom code
to use the Swing-specific hacks that are in Beans Binding, but I know
more or less what would need to be done to bind a list to a JList,
JComboBox or JTable.
All the external components (NB RCP, etc.) I'd rather delay till post
1.0 (and I think it belongs to SJB Extensions project anyway and
should not be part of the core).
JGoodies Validation integration is an interesting option that would
add a lot of visual pizazz to the apps. Depending on the complexity, I
may evaluate it. The main issue was understanding their API and then
figuring out what to do with it.
My 2 cents, I'd rather Jacek worry about writing the core API and enhancing
it than working on tool support. Having some sort of WYSIWYG in an IDE
defeats the purpose of JavaBuilders. The only thing I'd like to see is
support, as was said, for the YAML files to autocomplete and recognize their
Java file code. So for example if I go and create the JAVA code first, the
YAML would autocomplete event names for me and yuck yuck like that.
I wish I could find a good YAML plugin for IDEA that didn't come with all
the RAILS junk, but I can live with Ive got right now. Just make the API
solid. Tool support can be done much later and by someone else that will
actually use it. :)
Better binding always a +1
JGoodies validation integration, meh, I'd rather just have more control over
the way JavaBuilders displays messages. If I could intercept it somehow
(maybe I can already) and do my own things with the errors.
Gregg
On Tue, Mar 31, 2009 at 9:42 PM, Jacek Furmankiewicz <jace...@gmail.com>wrote:
> Alexandre, can you log all of these as separate enhancement requests?
> I will definitely look at the binding issue...it requires custom code
> to use the Swing-specific hacks that are in Beans Binding, but I know
> more or less what would need to be done to bind a list to a JList,
> JComboBox or JTable.
> All the external components (NB RCP, etc.) I'd rather delay till post
> 1.0 (and I think it belongs to SJB Extensions project anyway and
> should not be part of the core).
> JGoodies Validation integration is an interesting option that would
> add a lot of visual pizazz to the apps. Depending on the complexity, I
> may evaluate it. The main issue was understanding their API and then
> figuring out what to do with it.
Jacek Furmankiewicz wrote:
> Alexandre, can you log all of these as separate enhancement requests?
> I will definitely look at the binding issue...it requires custom code
> to use the Swing-specific hacks that are in Beans Binding, but I know
> more or less what would need to be done to bind a list to a JList,
> JComboBox or JTable.
> All the external components (NB RCP, etc.) I'd rather delay till post
> 1.0 (and I think it belongs to SJB Extensions project anyway and
> should not be part of the core).
I Totally agree.
> JGoodies Validation integration is an interesting option that would
> add a lot of visual pizazz to the apps. Depending on the complexity, I
> may evaluate it. The main issue was understanding their API and then
> figuring out what to do with it.
I take JGoodies just for instance to show what it is possible. I'm not sure it is the best implementation of validation on GUI.
Gregg Bolinger wrote:
> My 2 cents, I'd rather Jacek worry about writing the core API and > enhancing it than working on tool support. Having some sort of WYSIWYG > in an IDE defeats the purpose of JavaBuilders. The only thing I'd like > to see is support, as was said, for the YAML files to autocomplete and > recognize their Java file code. So for example if I go and create the > JAVA code first, the YAML would autocomplete event names for me and yuck > yuck like that.
I think I was misunderstood. I don't want to have a some sort of WYSIWYG, I prefer have something like a Spring IDE for spring xml file.
The kind of features are
- autocomplete (with some reflexion) on components, components attributes (what you said I think), event listeners, and variable on VSDL
- validation of the syntax yaml and components, component attributes, event listener, variables existence
> I wish I could find a good YAML plugin for IDEA that didn't come with > all the RAILS junk, but I can live with Ive got right now. Just make the > API solid. Tool support can be done much later and by someone else that > will actually use it. :)
I'm agree, not doing for 1.0.
> Better binding always a +1
> JGoodies validation integration, meh, I'd rather just have more control > over the way JavaBuilders displays messages. If I could intercept it > somehow (maybe I can already) and do my own things with the errors.
I take JGoodies only for instance what we can have but I also agree with you, I want more control on validation.
> On Tue, Mar 31, 2009 at 9:42 PM, Jacek Furmankiewicz <jace...@gmail.com > <mailto:jace...@gmail.com>> wrote:
> Alexandre, can you log all of these as separate enhancement requests?
> I will definitely look at the binding issue...it requires custom code
> to use the Swing-specific hacks that are in Beans Binding, but I know
> more or less what would need to be done to bind a list to a JList,
> JComboBox or JTable.
> All the external components (NB RCP, etc.) I'd rather delay till post
> 1.0 (and I think it belongs to SJB Extensions project anyway and
> should not be part of the core).
> JGoodies Validation integration is an interesting option that would
> add a lot of visual pizazz to the apps. Depending on the complexity, I
> may evaluate it. The main issue was understanding their API and then
> figuring out what to do with it.
I am definitely not looking at tooling support...not because I don't
want, but because of lack of time and above all knowledge (I know
nothing about writing Eclipse editor plugins, etc.)
This is where I am looking for someone else to contribute *hint*
*hint*
I am more than open to making the validation process more customizable
and give you guys hooks to override/change/modify the existing
implementation.
Let me think of something for 1.0
Once again, pls enter all of these as issues...otherwise they do get
sometimes lost in the weeks and months ahead.
On Wed, Apr 1, 2009 at 7:47 AM, Jacek Furmankiewicz <jace...@gmail.com> wrote:
> I am definitely not looking at tooling support...not because I don't
> want, but because of lack of time and above all knowledge (I know
> nothing about writing Eclipse editor plugins, etc.)
> This is where I am looking for someone else to contribute *hint*
> *hint*
> I am more than open to making the validation process more customizable
> and give you guys hooks to override/change/modify the existing
> implementation.
> Let me think of something for 1.0
> Once again, pls enter all of these as issues...otherwise they do get
> sometimes lost in the weeks and months ahead.
Hi
I have integrated a new TypeHandler and found out that the
exchangeabillity (plugabillity what ever) was not that easy than I
know it from other frameworks.
I think one issue is the use of singletons for TypeHandlers. They
force us to be aware of all eventually used libraries at compiletime.
For me it would be great to think about getting rid of the singletons
because they stand aginst the ideas of dependency injection.
AG WW
On 26 Mrz., 13:27, Jacek Furmankiewicz <jace...@gmail.com> wrote:
> As 0.3 signals a fairly mature, stable release I fill confident that
> the functionality is there to start thinking about an official 1.0
> release.
> Here are the items on my list, grouped by priority:
> HIGH
> - Add validation for binding expressions (since Beans Binding does not
> do it on its own). This will close the last hole in the JB
> functionality that allows you to specify invalid bindings and only
> finding out about it via manual testing
> - Unit tests for all core functionality (progress has been made on
> 0.3, but our coverage is still fairly minimal)
> - Add DimensionAsValueHandler from Alexandre (sorry that I forgot to
> add it in 0.3) and deprecate some of the existing property handlers it
> makes obsolete
> - finish the PDF book and finally implement some of the comments and
> sample apps from this forum
> MEDIUM
> - add support for action handlers that get wired automatically using a
> naming convention, e.g. "okButtonAction()"
> - create a PDF cheat sheet of all component properties that can be
> used in the YAML file (preferably based off reflection and parsing of
> the JavaBuilderConfig, to avoid manual coding)
> Feel free to comment on these and suggest any new ones. I'd like to
> make sure Swing JavaBuilder 1.0 becomes the best way to create user
> interfaces in Swing by a wide margin compared to anything else.
