>>4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.

 

How can the GUI-Builder know what event-handling framework/code-style

(eg.: one anonymous listener per button or one big inner-class-listener

for all the buttons or ...) you will use (or what code-style your

company/project-team is dictating you)?

IIRC, in Java/Swing Actions are known to be THE framework.

I think everything an GUI-Builder should do is creating the code that is

painting the gui and nothing more.

IMHO a GUI-builder should be a "visual layouter". Only the layout

should be stored externally, not how a component should look like or how

it is created.

Friendly,

Tom

>>4. No generation of event handling code or data bindings. Generated is not usable to integrate with my own event handling code.

 

How can the GUI-Builder know what event-handling framework/code-style

(eg.: one anonymous listener per button or one big inner-class-listener

for all the buttons or ...) you will use (or what code-style your

company/project-team is dictating you)?

 

IIRC, in Java/Swing Actions are known to be THE framework.

ok --> one more option in:

How can the GUI-Builder know what event-handling framework/code-style

(eg.: one anonymous listener per button or one big inner-class-listener

for all the buttons or ONE ACTION PER BUTTON or ...) you will use (or

what code-style your company/project-team is dictating you)

Regards,

Tom

On Mon, 02 Feb 2004 14:24:17 +0100, Thomas Singer wrote:

IIRC, in Java/Swing Actions are known to be THE framework.

Yet all other GUI builders inject anonymous ActionListeners amongst the

GUI contstruction/layout code.  This is one of my biggest gripes with

Netbeans/JBuilder and the like.  mixing the event code in the same place

as the design code.

Yes, but they emphasize, that all the same things can also be done in code, which was very hard before .net.

But the gui-designing-paradigma for longhorns .net will definitely be

XAML for GUI-Layout definitions (in most cases created by an gui-

builder-tool) and C#-code for event-handling.

And Jetbrains are not Microsoft. If anyone is in the position to create such a language for Java, then it is Sun.

ACK.

But anyone has to do the "first step". And JetBrains is known for many

innovative "first steps" they have done in the past and hopefully will

do in the future.

And I'm 100% sure that there will be an concrete JSR specified (and

implemented) in the near future for an XAML-like deklarative code-

layouting-language for Java.

(like Sun copied "syntactic sugar"-statements (foreach, enums,

Autoboxing, etc.) from .net/C# they will certainly copy XAML )

This kind of vendor dependence is simply out of the question.

full ACK.

That is one of my biggest complaints with IDEAs GUI-Builder. I know,

there is an free ant-task for compiling the XML-files, but in order to

visually design a gui I need IDEA at the moment (maybe someone is

writing an free GUI-Designer for IDEAs GUI-XML-dialect).

If xml definition of guis were such a good idea, then why isn't anyone using XUL?

Because time wasn't ready for that and the popular commercial GUI-

Frameworks (MFC/current .NET) offered no such possibillites.

In the apple-world (Mac OS X) everyone was/is creating (COCOA-)GUIs with

the "gui is stored in an xml-resource-file which is loaded and

interpreted at runtime"-paradigma for ages without

complaining/discussing. The same is true for Delphi.

It's simply much more flexible than the imho deprecated way of

programmatically layouting guis.

And with longhorns .net Microsoft (and every .net-GUI-application

developer) will definitely go the same way ("Avalon").

Regards,

Tom

On Tue, 03 Feb 2004 08:04:02 +0000, hmf wrote:

I know of at least one European Fortune100 company that considered Idea

and stayed with JBuilder for that reason.

Knowing that JBuilder likes you to use their own custom layouts and

databound controls in GUI apps, I wonder if they succombed to using those

as well, could make moving to ANYTHING a pain.