GUI Builder and stuff

Hello Eugene,

It would be great to have real MVc (do not care for C that much) framework
for Jetbrain. Couple of questions:

- Could you use JavaBean persistence framework rather than your own XML
representation?
- Have you seen Scope project http://scope.sf.net ? It's an MVC
implementation which have some nice ideas in model/view area. We used (and
extended) it succesfuly (be glad to discuss it if you find it interesting).
- Binding a form to an arbitrary bean (which is in many cases does not offer
property change or such notification). Are you planning to provide any
solution? One is to provide wrap-around-bean models to provide notification
(might be very tricky with complex graphs of objects and collections).
- One of very important areas is how collections are handled. Are you
planning to provide bindings between collections and controls like JTable?

Alex


"Eugene Belyaev" <beg@intellij.com> wrote in message
news:b5dftc$bpt$1@is.intellij.net...

I'll start the GUI builder discussion from a scratch by explaining some of
the issues we have behind it and with the hope to answer most of the
questions arisen here.

>

First, let me say about the purpose of the project itself. We are doing

it

not to help reverse-engineer bunches of hand-written Swing code nor follow
the current dubious (feel free to convince me it's not) approach to

working

with UI aspects of applications. The goal here is to dramatically

simplify

the UI construction as a task. So this will not be just "one more" Swing
wizard. It will not even be a Swing or AWT builder in that usual
understanding, e.g. it will not work with all the layouts out there.

>

If you still want to hand-write the code yourself, we have one of the best
code editors out there. If you want a prototype wizard that generates a

lot

of code that you need to refactor afterwards, we won't do it.
We want a solution that will dramatically improve the way we program UIs,

so

this discussion is about that.

>

Of course, you should realize that to build a great visual tool, you need

to

operate on frameworks. And what's very important, frameworks designed

"for

tools", not vice-versa. There is a set of rules we will follow to keep it
an acceptable solution for usage by other people on the team not using

IDEA,

by providing a documentation, freely available command-line tools, etc.

It

should be possible to use it outside the IDE for no charge and licensing
restrictions, however missing the visual tool.

>

Of course the GUI builder is based on consuming JavaBean-based controls as
in its first generation. However, we have far-going ideas on the subject
that are not going to be covered right away.
Most of them are hard to explain without showing samples, so we'll leave

it

for the future times.

>

One important notion here, the GUI builder we are talking about is well
suited for statically created layouts, which make the majority of cases.

We

may advance the framework and tools to the dynamic case, but not right

away.

The form designed in the GUI builder is described in an XML file. It has a
clean but proprietary syntax.
For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly it
contains code creating helper panels, adding controls to them, etc. This
code never has to be seen, so we'll skip the source code generation phase
here and will provide resulting class files. The instantiation logic for
JavaBean-based controls is obvios, but in case of factory made controls we
might add support as well but later.
- code that opens access to the controls on the form that you need to
program against. Simply a class with fields for every component you

specify

or plan on using.

>

There are different thoughts here on how to bind events to handlers. One

of

them fully relies upon the developer, so you add listeners to components
yourself. Another one is to implement a binding like in Delphi or VB. We
are not really fixed on whether we provide the latter, but the former will
be there anyway. Other ideas we have had is to not only be able to have
fields for controls themselves but also for some of their properties.
Also, we are working on data binding. Something like to have a JavaBean

to

get and set properties to various components to/from. This is also not

yet

quite decided how to deal with, so we'll need your input and our own
experience when the time comes.

>

One more idea about working with forms: you should be able to specify
containers on the form that you will want to insert other components

later.

At runtime you will be able to add any components you want to a ready to

use

layout. This is very important when you want let's say have a fixed

layout

for a lot of dialogs where only a certain part varies. Also, when you

have

a statically created form that still needs to derive other parts from a
prototype, the GUI builder will be able to handle that. Also, these
"prototype" forms might enforce styles on child components. Let's say I
want to assure that every label that is added to this type of a dialog
becomes bold and of certain color. But this is in a very early stage of
discussion right now.

>

And again, our goal here is to help easily create outstanding forms,

instead

of tediously programs ugly ones.

>

Eugene Belyaev, CTO
JetBrains Inc
http://www.intellij.com
"Develop with pleasure"

>
>

Hi Eugene,

i have a very simple question(s):

What are you thinking about webapps development?
More and better support of this is maybe more important!?
(GUI for Webapps - exemplary keyword "JavaServer Faces").
Or is that all for you uninteresting?

Thanks

Eugene Belyaev schrieb:

I'll start the GUI builder discussion from a scratch by explaining some of
the issues we have behind it and with the hope to answer most of the
questions arisen here.

>

First, let me say about the purpose of the project itself. We are doing it
not to help reverse-engineer bunches of hand-written Swing code nor follow
the current dubious (feel free to convince me it's not) approach to working
with UI aspects of applications. The goal here is to dramatically simplify
the UI construction as a task. So this will not be just "one more" Swing
wizard. It will not even be a Swing or AWT builder in that usual
understanding, e.g. it will not work with all the layouts out there.

>

If you still want to hand-write the code yourself, we have one of the best
code editors out there. If you want a prototype wizard that generates a lot
of code that you need to refactor afterwards, we won't do it.
We want a solution that will dramatically improve the way we program UIs, so
this discussion is about that.

>

Of course, you should realize that to build a great visual tool, you need to
operate on frameworks. And what's very important, frameworks designed "for
tools", not vice-versa. There is a set of rules we will follow to keep it
an acceptable solution for usage by other people on the team not using IDEA,
by providing a documentation, freely available command-line tools, etc. It
should be possible to use it outside the IDE for no charge and licensing
restrictions, however missing the visual tool.

>

Of course the GUI builder is based on consuming JavaBean-based controls as
in its first generation. However, we have far-going ideas on the subject
that are not going to be covered right away.
Most of them are hard to explain without showing samples, so we'll leave it
for the future times.

>

One important notion here, the GUI builder we are talking about is well
suited for statically created layouts, which make the majority of cases. We
may advance the framework and tools to the dynamic case, but not right away.
The form designed in the GUI builder is described in an XML file. It has a
clean but proprietary syntax.
For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly it
contains code creating helper panels, adding controls to them, etc. This
code never has to be seen, so we'll skip the source code generation phase
here and will provide resulting class files. The instantiation logic for
JavaBean-based controls is obvios, but in case of factory made controls we
might add support as well but later.
- code that opens access to the controls on the form that you need to
program against. Simply a class with fields for every component you specify
or plan on using.

>

There are different thoughts here on how to bind events to handlers. One of
them fully relies upon the developer, so you add listeners to components
yourself. Another one is to implement a binding like in Delphi or VB. We
are not really fixed on whether we provide the latter, but the former will
be there anyway. Other ideas we have had is to not only be able to have
fields for controls themselves but also for some of their properties.
Also, we are working on data binding. Something like to have a JavaBean to
get and set properties to various components to/from. This is also not yet
quite decided how to deal with, so we'll need your input and our own
experience when the time comes.

>

One more idea about working with forms: you should be able to specify
containers on the form that you will want to insert other components later.
At runtime you will be able to add any components you want to a ready to use
layout. This is very important when you want let's say have a fixed layout
for a lot of dialogs where only a certain part varies. Also, when you have
a statically created form that still needs to derive other parts from a
prototype, the GUI builder will be able to handle that. Also, these
"prototype" forms might enforce styles on child components. Let's say I
want to assure that every label that is added to this type of a dialog
becomes bold and of certain color. But this is in a very early stage of
discussion right now.

>

And again, our goal here is to help easily create outstanding forms, instead
of tediously programs ugly ones.

>

Eugene Belyaev, CTO
JetBrains Inc
http://www.intellij.com
"Develop with pleasure"

--
Svetoslav Koev
Systementwicklung

Inno Consult GmbH
Comeniusstra?e 109
01309 Dresden

Telefon: +49 351 25796-13
Fax: +49 351 25796-24
http://www.inno-consult.com

This tends to remind me of the way interfaces are developed with cocoa
(os x), using interface builder. This also provides a clear seperation
between the gui setup code and the controller of the gui which imho is a
great way of working. Is this the direction you are going in?

Pepijn Van Eeckhoudt

"Eugene Belyaev" <beg@intellij.com> wrote in message
news:b5dftc$bpt$1@is.intellij.net...

One more idea about working with forms: you should be able to specify
containers on the form that you will want to insert other components

later.

At runtime you will be able to add any components you want to a ready to

use

layout. This is very important when you want let's say have a fixed

layout

for a lot of dialogs where only a certain part varies. Also, when you

have

a statically created form that still needs to derive other parts from a
prototype, the GUI builder will be able to handle that. Also, these
"prototype" forms might enforce styles on child components. Let's say I
want to assure that every label that is added to this type of a dialog
becomes bold and of certain color. But this is in a very early stage of
discussion right now.

I really like the idea of having such support for composition in the GUI
builder. As far as I'm aware, there is no other GUI builder currently
available which does this (please someone point one out to me if I'm wrong).
I also like this idea of having styles specified on prototype forms:
anything that makes it easier to centralise control of the visual style of
an application is a good thing IMHO.

Will the forms be treated like classes by the IDE? Will it be possible, for
example, to write code which uses a form and still have the benefit of IDEAs
refactoring support? Will it be possible to write a class which extends a
form?

Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

Eugene Belyaev wrote:

Of course, you should realize that to build a great visual tool, you need to
operate on frameworks. And what's very important, frameworks designed "for
tools", not vice-versa. There is a set of rules we will follow to keep it
an acceptable solution for usage by other people on the team not using IDEA,
by providing a documentation, freely available command-line tools, etc. It
should be possible to use it outside the IDE for no charge and licensing
restrictions, however missing the visual tool.

Well, I am happy of investing my time in writing java code that depends
on widely knwon an open source library to compile (eg code that depends
on say log4j, struts ...) and build files that depend on ant, test code
that depend on junit.
And so far IDEA has helped me a lot.

The decision to depend on a proprietary/not-mainstream product is
instead much more complex.

So I'd not be very happy to create files that require a proprietary,
even if free at the moment (free today is not enough, open source is
better), tool or component to be built.

So I'd like IDEA not to produce any files that require IDEA (or one of
its components), to be built.
Well, it may produce proprietary deliverables - as this can be much much
more efficient - but one should also have the alternative of keeping
'standard', derived ones (eg lain java source files), even if these, as
derived products are of much less value. They still give me an escape
route from the product that generated the proprietary files.

For instance, if I throw away netbeans, the source code for its form is
still usable and modifiable in IDEA - I lost the visual editing, but
that's part op the trade-off I accept.

One important notion here, the GUI builder we are talking about is well
suited for statically created layouts, which make the majority of cases. We
may advance the framework and tools to the dynamic case, but not right away.
The form designed in the GUI builder is described in an XML file. It has a
clean but proprietary syntax.
For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly it
contains code creating helper panels, adding controls to them, etc. This
code never has to be seen, so we'll skip the source code generation phase
here and will provide resulting class files. The instantiation logic for
JavaBean-based controls is obvios, but in case of factory made controls we
might add support as well but later.

As I said, I strongly prefer the option of keeping that code.

And again, our goal here is to help easily create outstanding forms, instead
of tediously programs ugly ones.

I'm confident you'll get where no-one else has been before !!

Edo

I believe that sometimes it is useful to be able to view and look at the code that gets generated for the form (primarily for the debugging purpose). So, it would be nice if the GUI builder provided a way of generating the code up front, so that the debugger can step thru it.

Also, if the code is going to get generated on the fly, is it going to hurt the run time performance? I also agree with the comment about being able to use the code without having to have the "code generator" (I like the NetBeans concept of being able to use the code even if I do not have the NetBeans).

I do not care for the code which draws the form if it works as designed and
documented. But it would be nice to have all kinds of hooks to all possible
actions. Like in Delphi one can drop a button on a form and use predefined
actions as hooks for callbacks. If the button does not have some specific
action, one can always derive own button from standard one, get a window
handle and go nuts. This is very understated beauty of Delphi: one can work
on very high level -- with classes and actions, or on very low level -- with
Windows handles and Windows API.

So, to be "cool" IDEA GUI designer must support inheritance of visual
elements and all possible levels of controlling the behaviour of the
controls with reasonable defaults, so the need for proprietary hooks would
be rare.

I am sure that you guys used Delphi before, so you know what I am looking
for ;)

As for proprietary "form files" or "resource files" -- I am OK with that. I
hate when some static visual stuff is defined with zillion of code lines.
But, if one build a semi-dynamic form and store its definition in
resource -- that would be nice. For example, I define for a control it
possible views, and I define these views in the same form or in common
repository. So, I want to be able to change the view programmaticaly, or to
link the view with another control or state (like radio button). If I would
be able to feed proper data to my control for all possible views, then I
would not have even to change the code, MVC rules.

Michael Jouravlev.

Edoardo,

I do not agree. I believe there could be no GUI without framework. If you
make tool to generated 100% of code for you it will be a maintenance
nightmare and huge and ineficient and not expandable... I would be glad to
PURCHASE framework from IntelliJ as a comertial product if it is good. One
of the reasons client side java is not widely accepted is lack of good high
level MVC frameworks (like Delphi)

"Edoardo Comar" <e.comar.no.spam@no.spam.btinternet.com> wrote in message
news:b5enip$4oq$1@is.intellij.net...

Eugene Belyaev wrote:

>

Of course, you should realize that to build a great visual tool, you

need to

operate on frameworks. And what's very important, frameworks designed

"for

tools", not vice-versa. There is a set of rules we will follow to keep

it

an acceptable solution for usage by other people on the team not using

IDEA,

by providing a documentation, freely available command-line tools, etc.

It

should be possible to use it outside the IDE for no charge and licensing
restrictions, however missing the visual tool.

>

Well, I am happy of investing my time in writing java code that depends
on widely knwon an open source library to compile (eg code that depends
on say log4j, struts ...) and build files that depend on ant, test code
that depend on junit.
And so far IDEA has helped me a lot.

>

The decision to depend on a proprietary/not-mainstream product is
instead much more complex.

>

So I'd not be very happy to create files that require a proprietary,
even if free at the moment (free today is not enough, open source is
better), tool or component to be built.

>

So I'd like IDEA not to produce any files that require IDEA (or one of
its components), to be built.
Well, it may produce proprietary deliverables - as this can be much much
more efficient - but one should also have the alternative of keeping
'standard', derived ones (eg lain java source files), even if these, as
derived products are of much less value. They still give me an escape
route from the product that generated the proprietary files.

>

For instance, if I throw away netbeans, the source code for its form is
still usable and modifiable in IDEA - I lost the visual editing, but
that's part op the trade-off I accept.

>

One important notion here, the GUI builder we are talking about is well
suited for statically created layouts, which make the majority of cases.

We

may advance the framework and tools to the dynamic case, but not right

away.

The form designed in the GUI builder is described in an XML file. It has

a

clean but proprietary syntax.
For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly

it

contains code creating helper panels, adding controls to them, etc.

This

code never has to be seen, so we'll skip the source code generation

phase

here and will provide resulting class files. The instantiation logic for
JavaBean-based controls is obvios, but in case of factory made controls

we

might add support as well but later.

>

As I said, I strongly prefer the option of keeping that code.

>

And again, our goal here is to help easily create outstanding forms,

instead

of tediously programs ugly ones.

>

I'm confident you'll get where no-one else has been before !!

>

Edo

>

What kind of support can we expect on the framework aspects? This is no logger just a developer tool and need in some cases fast turn-around of bug fixes.

This is why I agree with others on the fact that the framework should be open-source or at least have the sources available and the generator/compiler should allow source code generation.

Jacques

On Fri, 21 Mar 2003 08:54:32 -0800, Michael Jouravlev wrote:

I do not care for the code which draws the form if it works as designed
and documented. But it would be nice to have all kinds of hooks to all
possible actions. Like in Delphi one can drop a button on a form and use

Whilst I don't care for the code which draws the form, for day-to-day
coding, it would still be nice to be able to see it, and see how its being
used. For when we want/need to generate dynamic forms - it'd be nice to
keep them the same as how all the other forms as built.

On Fri, 21 Mar 2003 08:54:32 -0800, Michael Jouravlev wrote:

I am sure that you guys used Delphi before, so you know what I am looking
for ;)

I think the problem JBuilder had was that it -wasn't- like Delphi. They
kinda made it rather yecky to work with :p

Sounds very exciting ... :)

But I wonder if I may raise a few points:

The proprietary XML. I don't have a problem with this. Keeping the layout description separate from the code is a good idea.

Packaging. I would like to see it as a separate add-on module for IDEA, rather than being included in the core.

Generating class files directly. That's a tricky one. I'm thinking about version control here. Which files would we save under CVS for example? Would there be a way to regenerate the required files outside of IDEA (as a separate ANT task for example)?

On Sat, 22 Mar 2003 08:01:55 +0000, Rayz wrote:

Generating class files directly. That's a tricky one. I'm thinking about
version control here. Which files would we save under CVS for example?
Would there be a way to regenerate the required files outside of IDEA (as
a separate ANT task for example)?

Store the XML file in CVS of course. And an Ant task has been mentioned...

"Eugene Belyaev" <beg@intellij.com> wrote in
news:b5dftc$bpt$1@is.intellij.net:

I'll start the GUI builder discussion from a scratch by explaining
some of the issues we have behind it and with the hope to answer most
of the questions arisen here.

Having recently completed a moderately complicated GUI this is a subject
that's of great interest to me.

First, let me say about the purpose of the project itself. We are
doing it not to help reverse-engineer bunches of hand-written Swing
code nor follow the current dubious (feel free to convince me it's
not) approach to working with UI aspects of applications. The goal
here is to dramatically simplify the UI construction as a task. So
this will not be just "one more" Swing wizard. It will not even be a
Swing or AWT builder in that usual understanding, e.g. it will not
work with all the layouts out there.

I don't see not working with all the layouts as a real issue. A lot of
them are not worth the trouble anyway.

If you still want to hand-write the code yourself, we have one of the
best code editors out there. If you want a prototype wizard that
generates a lot of code that you need to refactor afterwards, we won't
do it. We want a solution that will dramatically improve the way we
program UIs, so this discussion is about that.

+1 on no wizards. I like that idea only has a single wizard.

Of course, you should realize that to build a great visual tool, you
need to operate on frameworks. And what's very important, frameworks
designed "for tools", not vice-versa. There is a set of rules we will
follow to keep it an acceptable solution for usage by other people on
the team not using IDEA, by providing a documentation, freely
available command-line tools, etc. It should be possible to use it
outside the IDE for no charge and licensing restrictions, however
missing the visual tool.

It's extremely important that other people not using Idea be able to use
this stuff (minus the GUI tool) so thats good.

I would go further than making it free. I'd make it open source. That
would give me a level of comfort that the solution will always be available
and will survive any problems that IntelliJ may suffer in the future (not
that I'm expecting any:).

If it's open source at least I have control over fixing any problems that I
may run into down the track - although IntelliJ should still be the ones
looking after the official blessed version of course.

Of course the GUI builder is based on consuming JavaBean-based
controls as in its first generation. However, we have far-going ideas
on the subject that are not going to be covered right away.
Most of them are hard to explain without showing samples, so we'll
leave it for the future times.

One important notion here, the GUI builder we are talking about is
well suited for statically created layouts, which make the majority of
cases. We may advance the framework and tools to the dynamic case,
but not right away. The form designed in the GUI builder is described
in an XML file. It has a clean but proprietary syntax.

I strongly believe that XML is the right way to store this data. One of
the major problems with tools that generate Java source code is that it
becomes pretty much unreadable afterwards. This is because GUI's are very
hierarchical in nature and Java code isn't. XML is.

For each form, two pieces are generated:
- code that handles actual assembly of the form at runtime. So mainly
it contains code creating helper panels, adding controls to them, etc.
This code never has to be seen, so we'll skip the source code
generation phase here and will provide resulting class files. The
instantiation logic for JavaBean-based controls is obvios, but in case
of factory made controls we might add support as well but later.
- code that opens access to the controls on the form that you need to
program against. Simply a class with fields for every component you
specify or plan on using.

+1

There are different thoughts here on how to bind events to handlers.
One of them fully relies upon the developer, so you add listeners to
components yourself. Another one is to implement a binding like in
Delphi or VB. We are not really fixed on whether we provide the
latter, but the former will be there anyway.

It would be nice to simplify the binding. It's not too hard to do them
manually with Idea but newbies love this because the learning curve is
reduced.

Other ideas we have had
is to not only be able to have fields for controls themselves but also
for some of their properties.

It's not clear what you mean here.

Also, we are working on data binding.
Something like to have a JavaBean to get and set properties to various
components to/from. This is also not yet quite decided how to deal
with, so we'll need your input and our own experience when the time
comes.

It would be nice to have something that lets you:

• Easily bind to a db field.

• Make changes

• Undo changes (to the row not just one field).

• Validate changes

• Restrict import based on field type and size.

• Commit or rollback changes.

One more idea about working with forms: you should be able to specify
containers on the form that you will want to insert other components
later. At runtime you will be able to add any components you want to a
ready to use layout. This is very important when you want let's say
have a fixed layout for a lot of dialogs where only a certain part
varies. Also, when you have a statically created form that still
needs to derive other parts from a prototype, the GUI builder will be
able to handle that. Also, these "prototype" forms might enforce
styles on child components. Let's say I want to assure that every
label that is added to this type of a dialog becomes bold and of
certain color. But this is in a very early stage of discussion right
now.

Okay... this ones extremely important. It should be possible to set a
style against a particular control and then change the style and have all
controls updated. For example I might have a heading style that applies to
JLabels. The heading style would define a large font with bold and
underline. Later I might change the colour and it would change all
controls with that style across the application. It should still be
possible for individual controls to override the styles properties however.

The "style" should go as far as automatically attaching certain event
handlers and defaulting the models.

Adding new controls should be really easy too.

And again, our goal here is to help easily create outstanding forms,
instead of tediously programs ugly ones.

Currently there are NO good GUI builders for Java. Some of this is to do
with how poorly swing was designed to work with GUI's. A lot of it also
comes down to poor implementations. Hopefully you guys can fix this
situation.

Regards,

Glen Stampoultzis
http://members.iinet.net.au/~gstamp/glen/

>> Other ideas we have had
>> is to not only be able to have fields for controls themselves but also
>> for some of their properties.

>It's not clear what you mean here.

I hope Eugene means that you will be able to traverse the bean graph. I would be really interested to be able to define a bean at the panel level that might contains other subpanels that are bound to properties of the bean.
I will illustrate with an example:
Let's say that we have an StreetAddress like that (getters/setters omitted):

I could have 2 objects ResidentialAddress and CommercialAddress that contains a StreetAddress.

I could have defined a panel StreetAddressPanel that binds to a StreetAddress bean.
In building the ResidentialAddressPanel I can use a StreetAddressPanel that will bind automatically to the property address. Same thing for CommercialAddressPanel.

We have an environment where we want to enforce a common L&F. Having a set of default UI for standard business object/types would be great. I would also speed up the development of panels since we would build hierarchical panels from the get go. Maybe the refactoring function that some other posters mentioned would be also great at extracting beans and panels at the same time.

Jacques

Okay, thanks. I managed to miss the part about command line tools.

So the entire GUI description will be contained in the XML file, from which the GUI classes can be regenerated from scratch during an Ant build? Sounds good.

Still not convinced about generating .class files directly though. If source files are generated, then wouldn't this give folk more options? Native Java compilers for example. And it would also make the process immune to changes in the class file structure (unlikely, but possible).

On Sun, 23 Mar 2003 06:21:22 +0000, Rayz wrote:

Still not convinced about generating .class files directly though. If
source files are generated, then wouldn't this give folk more options?
Native Java compilers for example. And it would also make the process
immune to changes in the class file structure (unlikely, but possible).

I was thinking on this, and was wondering if there was a way that AspectJ
could be used in relation to making GUI development in Java new and
revolutionary.

Possibly something along the lines of making use of pointcuts
before/after/during ActionListeners.

One thing I really hate with the way alot of existing GUI design tools do
things is there insistence of using ActionListeners, and putting
'modifyable' code inside. With the complete XML abstraction, I could see
all that code sitting in another class, either a subclass of the generated
code, or a child class, along with the "model/data" class.

Yes I agree. Also I believe Bean per Panel should not be the only way (not
flexible enough having to make your visual object containment to mimick your
bean containment) Nested bean properties should be supported too

"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:12328637.1048386613298.JavaMail.jrun@is.intellij.net...

>> Other ideas we have had
>> is to not only be able to have fields for controls themselves but also
>> for some of their properties.

>

>It's not clear what you mean here.

>

I hope Eugene means that you will be able to traverse the bean graph. I

would be really interested to be able to define a bean at the panel level
that might contains other subpanels that are bound to properties of the
bean.

I will illustrate with an example:
Let's say that we have an StreetAddress like that (getters/setters

omitted):

 class StreetAddress {
>   int streetNumber;
>   String street;
>   ZipCode zipCode;
>   UsState state;
> }
> ]]>

I could have 2 objects ResidentialAddress and CommercialAddress that

contains a StreetAddress.

 class ResidentialAddress {
>    Person person;
>    StreetAddress address;
> }
> class CommercialAddress {
>    Company company;
>    StreetAddress address;
> }
>
> ]]>

>

I could have defined a panel StreetAddressPanel that binds to a

StreetAddress bean.

In building the ResidentialAddressPanel I can use a StreetAddressPanel

that will bind automatically to the property address. Same thing for
CommercialAddressPanel.
>

We have an environment where we want to enforce a common L&F. Having a set

of default UI for standard business object/types would be great. I would
also speed up the development of panels since we would build hierarchical
panels from the get go. Maybe the refactoring function that some other
posters mentioned would be also great at extracting beans and panels at the
same time.
>

Jacques

Hi Eugene,

Eugene Belyaev wrote:
> I'll start the GUI builder discussion from a scratch by explaining
> some of the issues we have behind it and with the hope to answer most
> of the questions arisen here.
I nearly misted the post, but i'm really hungry for a good
visual UI Editor ;)


> First, let me say about the purpose of the project itself.
> not to help reverse-engineer
+1
> nor follow the current dubious (feel free to convince
> me it's not) approach to working with UI aspects of
> applications.
I don't get that point: which approach are you referring to?

> e.g. it will not work with all the layouts out there.
+/-1
I think the reason that no visual UI editor for Swing exists is
directly related to the varios LayoutManagers, but writing I18N
applications without LayoutManagers is very tough.


> We want a solution that will dramatically improve the way we
> program UIs, so this discussion is about that.
I have problems with revolutions aka silver bullets aka
"dramatically improve" ;)
I would love to see a more evolutionary approach, that supports
different styles of development (see below).


> One important notion here, the GUI builder we are talking about is
> well suited for statically created layouts, which make the majority
> of cases.
+1


> We may advance the framework and tools to the dynamic case, but
> not right away.
+1: I would prefer support for the following development styles:

- On the lowest support level, i get a sweet UI Editor that generates
a XML file that can be easily converted to another XML file that
my current frameworks operates on.
Support for this level includes I18N issues, and is mainly focues
on the (static) "look" of the application, it doesn't require
changes to any of my code outside the initial UI setup phase.

- On the next support level, i get the UI Editor, the XML file and
a Framework that provides higher-level features.
Support on this level will change my code, because it will provide
processes, places and structure beyond the Swing Framework.

- On the next support level, i get data binding.
It might perhaps support data binding via Smalltalk like
ValueModel's or a two tier data binding the VB/Delphi way.


> The form designed in the GUI builder is described in an XML file.
> It has a clean but proprietary syntax.
+1
The most importent point for me is that this XML file is already I18N
enabled, and easy to parse/process e.g. via XSLT or a small Perl
script.


> For each form, two pieces are generated:
> - code that handles actual assembly of the form at runtime.
> So mainly it contains code creating helper panels, adding controls
> to them, etc.
-1
Why do you generate special code? You could provide a Builder that
generates the panels etc. from the XML input as a generic class,
Example:
InputStream input = ...
SwingXMLBuilder builder= SwingXMLBuilder.create(input);


> - code that opens access to the controls on the form that you
> need to program against. Simply a class with fields for every
> component you specify or plan on using.
-1
Again, i don't understand why this should be special code.
Of course, i see the need for data binding to generate special code,
but on the lowest level, it would be perfectly o.k. to have an
access via the builder, like
JTextField textField= (JTextField)
builder.getComponentByName("myFrame/TestPanel/textField");


> There are different thoughts here on how to bind events to handlers.
Yes ;)

> One of them fully relies upon the developer, so you add listeners
> to components yourself.
I like the NeXTSTEP/Qt style:
connect(widget, callbackobject, methodname)
or in XML
> Also, we are working on data binding. +1, data binding is very importent, but again, this should be an (purely optional) add on. > This is also not yet quite decided how to deal with, so we'll need > your input and our own experience when the time comes. I currently prefer a ValueModel like approach (for more details see http://c2.com/ppr/vmodels.html). All VB/Delphi developers should get of course their two tier direct data binding stuff, but this is not very useful in a three tier environment. I also made a lot of progress lately by spliting my data binding framework in two halfs: o binding the data of a use case to display/edit widgets via a ValueModel's (see below for an example) o binding the state of a use case to command widgets (buttons, menus, ..) via a State/StateAdapter approach (see below for an example) I prefer the State/StateAdapter style to a more formal finite state machine approach (e.g. like Struts does it), because it fits IMO better to the dynamic nature of a Swing GUI. In any case, the data binding should reduce the "callback handling" code written by a developer as much as possible. > One more idea about working with forms: you should be able to > specify containers on the form that you will want to insert other >]]> components later.
I'm not so sure if this approach is generic enough. I like the "non
visual builder approach" from Karsten Lentzsch (jgoodies.org), but i
currently can't imagine how this can be integrated with a visual
builder.

> And again, our goal here is to help easily create outstanding
> forms, instead of tediously programs ugly ones.
+10 ;)


To summarize, my major points regarding the IDEA UI Editor are:
o The UI Editor provides an I18N XML file, suitable for processing
outside of Intellij
o The UI Editor provides integration with a general UI Framework
classes (simular to the Skeleton stuff from Karsten Lentzsch)
o The UI Editor provides data binding, both for a ValueModel like
style as well as for a Delphi like style.

Bye,

J?rgen



Example for ValueModel like data binding
========================================
/* ValueModel setup and data binding */
ListHolder tableData = new ListHolder();
// tableData holds a java.util.List of UserData objects

IndexedAdapter currentRow= new IndexedAdapter(tableData);
ValueModel trigger = new ValueHolder();
ValueModel bufferedCurrentRow=
new BufferedValueHolder(currentRow, trigger, true);
AspectAdapter firstNameAspect =
new AspectAdapter(bufferedCurrentRow,
UserData.class, "firstName");
AspectAdapter middleNameAspect=
new AspectAdapter(bufferedCurrentRow,
UserData.class, "middleName");
// etc.


/* ValueModel UI binding */
// ValueModel binding
new DocumentAdapter(firstNameAspect,
builder.getComponentByName("Frame/Panel/Details/FirstName"));
new DocumentAdapter(middleNameAspect,
builder.getComponentByName("Frame/Panel/Details/MiddleName"));


Example for State/StateAdapter like data binding
================================================
// bind the enabling/disabling of the file name textfield and
// the search button to the file radiobutton via a State/StateAdapter
JRadioButton fileButton =
(JRadioButton) builder.getComponentByName(BASE+"Source/File");

State fileState = new SwingSelectedState(fileButton.getModel());
StateAdapter fileAdapter= new SwingEnabledAdapter(fileState);
fileAdapter.add(builder.getComponentByName(BASE+"Source/FileName"));
fileAdapter.add(builder.getComponentByName(BASE+"Source/FileSearch"));


Example for a XML file
======================
This is an XML file i use as input for my SwingXMLBuilder class.
The XML file of the UI builder should at least contain the
non-visual and visual part, of course in a different format.


Quit Close application. Q Beenden Anwendung verlassen. B Q

Hi All

Certainly, an adequate support for I18N in GUI applications is extremely important, but I'd really like it to be done with the help of old good property files, not by encoding localised strings into the XML file.

On Mon, 31 Mar 2003 09:12:59 +0000, Sergei S. Ivanov wrote:

Certainly, an adequate support for I18N in GUI applications is extremely
important, but I'd really like it to be done with the help of old good
property files, not by encoding localised strings into the XML file.

When looking into I18N stuff for work I came accross the ICU4J stuff from
IBM, and RB Manager:

http://oss.software.ibm.com/cvs/icu4j/_checkout/unicodetools/com/ibm/rbm/docs/index.html

Havn't really used it yet, but a plugin wrapper could be kinda neat.

nteresting stuff about the GUI builder.

I'd like to point your attention to a layout manager called DialogLayout that we developed for form-based GUIs. It creates layouts that are precisely correct to platform standards (our Java layouts under Windows look exactly like Windows applications) and it is very predictable and easy to use. Perhaps you would like to take a look at the layout manager and see if any of the ideas we used would be of use. It's open-sourced under a permissive license.

The code and documentation is available at http://www.sourceforge.net/projects/dialoglayout.