Plans for Swing JB 1.0 : need community feedback and ideas

[Jacek Furmankiewicz]

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.

Cheers, Jacek

[Alexandre Navarro]

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.

Alexandre

PS : help Jacek with posting a comment on his great article on javalobby
http://java.dzone.com/articles/making-gui-builders-obsolete

[Jacek Furmankiewicz]

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.

[Gregg Bolinger]

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

--
Gregg Bolinger

[Alexandre Navarro]

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.

Ok, I will add the BeanTableMobel (https://beantablemodel.dev.java.net/)
extension will resolve a part of the problem on a 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.

Alexandre

>
> >

[Alexandre Navarro]

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.

Alexandre

[Jacek Furmankiewicz]

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.

Cheers, Jacek

[Fred Swartz]

I'm with everyone else: framework / tooling integration would be great,
but the core API is much more important.

-- Fred

[wwagner4]

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