I 100% agree. Generation of source code and then class files seems to be
pure waste of resources and could be a real pain for dynamic GUI. There are more smart ways to solve the obfuscation problems. I would rather make the GUI generator itself open source to allow debugging (and further development also!). In other words in must be a plug-in. >
Would you please provide us with any example of your XML GUI descriptor?
So far I have no clue of what we're talking about. >
I am also curious if you were able to address any issues I mentioned in
Would you please provide us with any example of your XML GUI descriptor?
So far I have no clue of what we're talking about.
>
It's something like that (it may change rather dramatically though):
I've had a look at the XML you provided. And it remind me of some other concern regarning internationalisation. Will it be possible to easily translate the GUI forms ? What are your thoughts about that ? Will it be easy to add/modify translations ? It is very important for a GUI builder to deal with internationalization.
Yes, the internalization is very important issue and we surely will support it in the GUI builder. The details are not defined yet and your input is welcome.
Would you please provide us with any example of your XML GUI
descriptor?
So far I have no clue of what we're talking about.
>
It's something like that (it may change rather dramatically though):
>
I've had a look at the XML you provided. And it remind me of some other concern regarning internationalisation. Will it be possible to easily translate the GUI forms ? What are your thoughts about that ? Will it be easy to add/modify translations ? It is very important for a GUI builder to deal with internationalization.
I am also very excited at seeing what JetBrains can do with a GUI Builder.
But I have to say I am a little disapointed at the idea of XML to Class generation. Even if the option of keeping the generated source is introduced as many have suggested there is still a problem as i see it.
For me the holy grail of GUI building has always been round-tripping gui building. And I had somehow hoped that IDEA would someday introduce this. What do I mean by round-tripping? Well... that one could use the tool even after editing the code by hand... that the many legacy projects we have to maintain in our team could be reverse-engineered into the builder... etc. Sort of like how certain UML tools allow you to synchronize diagrams on evolving code, rather than oneway make-diagram --> generate code paradigm.
so here is my wish list moving forward: -make the xml human-readable. -provide access to the generated source. -provide a way to reverse engineer existing code into the builder. (I know this is a huge one... but IDEA has many miracles to it's record already... so one more should not be impossible) - make it possible to step through the generated code either while debugging or even while manually walking throught the code(ie: ctrl-B to a method). Eventhough i trust that IDEA will generate bug-free code i know that I often miss-understand what is happening in the code and stepping through it is often neccessary to finally locate a rogue NPE or empty string!
Yes, the internalization is very important issue and we surely will
support
it in the GUI builder. The details are not defined yet and your input is welcome.
There are different things that we have to localize : the labels, and also the mnemonics (is there something else ?) (the mnemonics, because depending on the language, you might choose a different mnemonic) Maybe some graphics (such as splash screens), might have to be localized.
- In your GUI builder, there should be some convenient tool window (or whatever) inside which we could define the different labels and their translations. For instance : a drop-down menu in which we could select the language, and a two columns array with the labels and the translations (mainForm.buttonCancel.label = "Annuler", mainForm.buttonCancel.mnemonic = "A").
- in your XML file format, there could be a property defining the language to use for displaying the form. Using the ISO codes, such as FR_fr... or maybe not, maybe it'd be better to be able to change the language at run-time, from the menu. A class binded to this XML file that would deal with the translations ? Something like :
...
]]> ...
Before intanciating the form, you would pick up the language defined as default in the myTranslator instance.
Well, that's just some random thoughts that I've had, but I need more time to think more thouroughly about internationalization.
in my project i work with internalization and it's so big that i have more than one .properties-files for one language. for this reason i've wrote a helper-class which controlls the .properties files. when i need a string from a .properties file, i call a method in the helper-class, like this: Util.getResourceString("PROPERTIES_FILE_IDENTIFIER", "VALUE_IN_THE_FILE");
i think it's much better when you have a text field where you can write the text for the component, you can call a method that get's the text for the component or something else!!! isn't it better?
For me the holy grail of GUI building has always been round-tripping gui building. And I had somehow hoped that IDEA would someday introduce this. What do I mean by round-tripping? Well... that one could use the tool even after editing the code by hand... that the many legacy projects we have to maintain in our team could be reverse-engineered into the builder...
I think that this Round-Trip idea is patentet by Borland/Inprise. If it is, it would be very unlikely to see it without increasing the license fees to JBuilder level...
i think it's much better when you have a text field where you can write
the text for the component, >you can call a method that get's the text for the component or something else!!! isn't it better?
Well, the myTranslator instance would have a method like yours (using the default Locale) myTranslator.getResourceString("myButton.label");
Another one specifying the Locale myTranslator.getResourceString("myButton.label", "fr");
And if there are multiple property files myTranslator.getResourceString("myButton.label", "fr", "theVerySpecialPropertyFile");
Three different methods ? And after all, as you would use Idea to define the translations, do you really need to care about multiple property files ???
well in actuality I don't need pure round-tripping.... but something that isn't a one way street.
I think the reality is that at some point someone needs to edit existing code and does not have access to the gui builder because of logisitics or other issues.
At that point it would be nice to be able to say go ahead fix the code by hand cause I can just have the builder merge the changes into the existing file at some later point. So it's not pure round tripping but i can import the modified code into the builder and not have to re-implement the changes.
This does not have to be seemless. It's ok if the generated code looks nothing like the imported code... as long as the gui looks the same. It's even ok if there are some loose ends to tie in connecting the gui to the app after such an operation I wouldn't really mind. Cause as far as I can tell what everyone hates is dealling with th e billion or so setters in any gui not binding the presentation to the model.
thats pretty good. >And after all, as you would use Idea to define the translations, do you really need to care about multiple property files ???
yes, i need multiple property files, especialy if i had a application uses a "modul" which can be used for a lot of other applications, too. the "modul" needs another property file like the main application that it's independent!?
For me the holy grail of GUI building has always been round-tripping gui building. And I had somehow hoped that IDEA would someday introduce this. What do I mean by round-tripping? Well... that one could use the tool even after editing the code by hand... that the many legacy projects we have to maintain in our team could be reverse-engineered into the builder... etc. Sort of like how certain UML tools allow you to synchronize diagrams on evolving code, rather than oneway make-diagram --> generate code paradigm.
well in actuality I don't need pure round-tripping.... but something that isn't a one way street.
I think the reality is that at some point someone needs to edit existing code and does not have access to the gui builder because of logisitics or other issues.
Well, as we are speaking of Holy Grails, here's is mine, opposite to yours ;)
I do NOT want to modify the generated code at all.
I want to be able to modify the behavior/appearance of a generated UI by using overrides and/or mutator methods on the constructed instance.
yes, i need multiple property files, especialy if i had a application uses
a "modul" which can be used for a lot of other >applications, too. the "modul" needs another property file like the main application that it's independent!?
Hmmm... okay, I think I understand what you mean... So we need to have a way of defining the right property file to use... So in each form defined in the XML Gui file, we could define a set of property files in wich the myTranslator instance should dive into in order to find the right translation ! Right ?
There are different things that we have to localize : the labels, and also the mnemonics (is there something else ?)
Also icons and pictures. No kidding. For example, traditional american mail box is a weird ;) red half-cylinder on a pole. When I first saw localized MS Mail 3.0 I could not get what this red thingy is. Traditional russian or swedish mailbox is a blue rectangular box with "POST" on it in yellow or white. And russian text is, of course, in cyrillics :)
- In your GUI builder, there should be some convenient tool window (or whatever) inside which we could define the different labels and their translations. For instance : a drop-down menu in which we could select the language, and a two columns array with the labels and the translations (mainForm.buttonCancel.label = "Annuler", mainForm.buttonCancel.mnemonic = "A").
>
- in your XML file format, there could be a property defining the language to use for displaying the form.
It is essential to be able to use several languages in one form. And I would not link language to locale: I might want russian locale (for dates and money) but prefer to see english messages.
Internatiolization problem does not exist if you do it right from the very beginning. Here is a solution I've been using for years.
You don't mess with internationalization while prototyping and developing. In most cases it does nothing good but slow down the development. Instead you embed a hook[s] for a resource mapper. Unfortunately the default property file based framework is too primitive for that but it can be easily extended with a very little efforts. (Of course, the plugability of your mapper gives to you an another advantage. If you decided to put all your localized resources into a DB it would be very easy to achieve.) In most cases all you need is just a simple inheritance so if a mapping isn't found in a local mapping context it would check parent context and so forth. In other words you're using the message itself as a message ID in your mapper. The beauty of this approach is that even without any mapper you still have human readable messages (instead of STRING12345) in you code (and UI!) which makes it much easier to develop and debug. You can also postpone the development of the mapper untill you're clear of what you want of it. On top of it you can introduce a very simple syntax for dynamic localization. For example:
Hi! -- would result in a localized string based on the global locale settings :Hi! -- would always result in russian "Privet!" despite of the global locale
<@X>]]>:Hi! -- would use locale defined in a context variable X
etc.
So the bottom line: You don't need to design/expose any localization functionality on the UI definition level but provide pluggable localization mapper instead.
This would require that JetBrains open up the compiler to use in deployed products. Are you going to only license the GUI builder with IDEA and leave everything else (compiler/generator, framework, generated classes) freely redistributable?
Well, that's what I was afraid of. Looks like a yet another frozen-at-birth UI definition language. Please, please, please do convince me otherwise!!!!
Here is my understanding of your idea: 1. You're going to design (or already have) a GUI framework implementation. 2. You're going to use a static proprietary XML input language. Please correct me if there is anything more in that.
Here is what I have in mind: 1. Define a basic GUI framework interface. (Swing itself is a good starting point for that so you don't actually need to do anything here) 2. Use an XML-like structured language to interact with GUI framework via Java reflection. So the
Cancel
Value1
Value2
]]> would be translated into something like
And my_button is not nesessarily a JButton (or even a GUI component!), it's just an instance of a Java class (with the setText and setMyMapProperty methods) defined/created somewhere else.
So like everybody else you're trying to deal with concrete implementations while I was always thinking of well defined extendable interfaces and pluggable implementations for GUI components and GUI framework itself (that is, my approach would work with any GUI framework not just swing).
Well, I hate to tell you this, but unless you have something more to that then I'm about to loose my interest here. This approach is proven to be very limited and will eventually fail in a long run at least in my field.
Why don't you focus on the open API for a visual GUI editor instead and let the community to develop a variety of plugins for GUI design instead? Your proposed framework can fit into this wery well while being optional.
On Fri, 21 Mar 2003 05:48:08 +0000, Robert Seaton wrote:
- Refactoring: The biggest missing piece from all GUI builders (caveat: that I am familiar with). Refactoring, for me, in this context involves being able to select a sub-component (like a JPanel, which may have its own sub-components, buttons, sliders, etc) and creating a bean from that. IDEA's Refactor:"Extract Method" provides the conceptual model for this. So it would be something like: 1. Select a component from the form you are designing 2. Right mouse click "Refactor: Extract Bean".
This reminds me of Borlands "Frame" component they introduced a few versions back in Delphi. Select a few components you've put on a form, and conver it to a frame ( or create New->Frame from the menu ).
You can then just insert that frame on any form, and overide properties of it on your local instance, you can add additional fields/components to it, but not remove any existing ones.
On Fri, 21 Mar 2003 09:36:33 -0500, Dirk Dittert wrote:
I think that this Round-Trip idea is patentet by Borland/Inprise. If it is, it would be very unlikely to see it without increasing the license fees to JBuilder level...
I believe borland do have a patent on Two-way tools. Which is rather stupid I thought :( I'm sure you could come up with your own two-way tools method, it'd just have to be different to borlands.
On Sat, 22 Mar 2003 03:40:06 +0000, simplicity wrote:
I would prefer that source codes is generated. In the event that fine-tuning is necessary, the codes is around. Moreoever, not everyone uses IDEA.
The "not everone uses idea" has been addressed with the available of standalone/commandline compilers for the GUI designer. Weather these will be free or not, who knows.
For me the XML does not look 'abstract' enough. We are currently thinking on a GUI description XML suitable for both Swing & HTML. Having references to Swing classes is suggesting that IDEA XML->HTML/webapp transformation wouldn't be easy.
We would definetely prefer the idea of a form represented by 'abstract enough' XML document + possible addendums/'customizations' for Swing/webapp. The form does not have to be represented by a single XML document, it could be a pack of XML documents, like typical HTML page + CSS stylesheet. Here we could have 'basic' XML + 'Swing' stylesheet.
There were quite a few attempts to do this kind of "abstraction". To the best of my knowledge none of them succeeded so far. Sure you can do some primitive GUI this way but not much. It's not my business of course, but I would not waste my time on this. Those two beasts are just too different. It looks like an attempt to describe a submarine and a stealth fighter with one set of drawings, sure they have something in common :( Transformation based approaches seems to be much more productive and transparent. My approach would handle it even better because you can refer to custom classes/methods which will generate HTML or whatever else for you. In fact I never meant to use swing classes directly. Swing is just too poorly and inconsistently designed to make this possible. You can refer to my comment in http://www.intellij.net/tracker/idea/viewSCR?publicId=6533 for more details, but the bottom line is that GUI specification can be at the same time considered as an XML and as a Bean (not java bean as you know it though). All known technologies (XSLT, XPATH, DB persistence etc) would apply automatically. GUI descriptor would become a just another run-time data structure which can be loaded/saved/modified/generated/binded/transmitted/etc. the very same way as any other object.
For me the XML does not look 'abstract' enough. We are currently thinking on a GUI description XML suitable for both Swing & HTML. Having references to Swing classes is suggesting that IDEA XML->HTML/webapp transformation wouldn't be easy.
>
We would definetely prefer the idea of a form represented by 'abstract enough' XML document + possible
addendums/'customizations' for Swing/webapp.
The form does not have to be represented by a single XML document, it could be a pack of XML documents, like typical
HTML page + CSS stylesheet. Here we could have 'basic' XML + 'Swing' stylesheet. >
I've never used anything like Glade in Java, but a quick search on google for "java gui builders" showed up to proeminent projects: JEasy[2] and JGB[3], the last one being an open source. Hint: JetBrains could "adopt" the JGB project and make it really happens.
JGB is distributed under a GPL licence so IntelliJ would not be able to "adopt" it.
Not that it really matters since IntelliJ already has decided upon the syntax of the XML and such... now our only hope is that they actually publish this as an open source standard, that would really be cool.
So far I have no clue of what we're talking about.
It's something like that (it may change rather dramatically though):
-- Valentin Kipiatkov JetBrains, Inc http://www.intellij.com "Develop with pleasure!" "Oleg Danilov" ]]> wrote in message
news:11145443.1048186111013.JavaMail.jrun@is.intellij.net...
pure waste of resources and could be a real pain for dynamic GUI. There are
more smart ways to solve the obfuscation problems. I would rather make the
GUI generator itself open source to allow debugging (and further development
also!). In other words in must be a plug-in.
>
So far I have no clue of what we're talking about.
>
>
>
>
"Valentin Kipiatkov" <valentin@intellij.com> a ?crit dans le message de
news: b5evt3$hv0$1@is.intellij.net...
>
I've had a look at the XML you provided.
And it remind me of some other concern regarning internationalisation.
Will it be possible to easily translate the GUI forms ?
What are your thoughts about that ?
Will it be easy to add/modify translations ?
It is very important for a GUI builder to deal with internationalization.
Guillaume Laforge
Yes, the internalization is very important issue and we surely will support
it in the GUI builder. The details are not defined yet and your input is
welcome.
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:b5f0m6$jph$1@is.intellij.net...
>
descriptor?
>
>
>
>
I am also very excited at seeing what JetBrains can do with a GUI Builder.
But I have to say I am a little disapointed at the idea of XML to Class generation. Even if the option of keeping the generated source is introduced as many have suggested there is still a problem as i see it.
For me the holy grail of GUI building has always been round-tripping gui building. And I had somehow hoped that IDEA would someday introduce this. What do I mean by round-tripping? Well... that one could use the tool even after editing the code by hand... that the many legacy projects we have to maintain in our team could be reverse-engineered into the builder... etc. Sort of like how certain UML tools allow you to synchronize diagrams on evolving code, rather than oneway make-diagram --> generate code paradigm.
so here is my wish list moving forward:
-make the xml human-readable.
-provide access to the generated source.
-provide a way to reverse engineer existing code into the builder. (I know this is a huge one... but IDEA has many miracles to it's record already... so one more should not be impossible)
- make it possible to step through the generated code either while debugging or even while manually walking throught the code(ie: ctrl-B to a method). Eventhough i trust that IDEA will generate bug-free code i know that I often miss-understand what is happening in the code and stepping through it is often neccessary to finally locate a rogue NPE or empty string!
Florian Hehlen
"Valentin Kipiatkov" <valentin@intellij.com> a ?crit dans le message de
news: b5f2to$pbl$1@is.intellij.net...
support
There are different things that we have to localize : the labels, and also
the mnemonics (is there something else ?)
(the mnemonics, because depending on the language, you might choose a
different mnemonic)
Maybe some graphics (such as splash screens), might have to be localized.
- In your GUI builder, there should be some convenient tool window (or
whatever) inside which we could define the different labels and their
translations. For instance : a drop-down menu in which we could select the
language, and a two columns array with the labels and the translations
(mainForm.buttonCancel.label = "Annuler", mainForm.buttonCancel.mnemonic =
"A").
- in your XML file format, there could be a property defining the language
to use for displaying the form. Using the ISO codes, such as FR_fr... or
maybe not, maybe it'd be better to be able to change the language at
run-time, from the menu.
A class binded to this XML file that would deal with the translations ?
Something like :
... ]]>
...
Before intanciating the form, you would pick up the language defined as
default in the myTranslator instance.
Well, that's just some random thoughts that I've had, but I need more time
to think more thouroughly about internationalization.
Guillaume Laforge
+1
that's my wish list, too!!! ;)
in my project i work with internalization and it's so big that i have more than one .properties-files for one language. for this reason i've wrote a helper-class which controlls the .properties files. when i need a string from a .properties file, i call a method in the helper-class, like this:
Util.getResourceString("PROPERTIES_FILE_IDENTIFIER", "VALUE_IN_THE_FILE");
i think it's much better when you have a text field where you can write the text for the component, you can call a method that get's the text for the component or something else!!! isn't it better?
Florian Hehlen wrote:
I think that this Round-Trip idea is patentet by Borland/Inprise. If it
is, it would be very unlikely to see it without increasing the license
fees to JBuilder level...
Best regards,
Dirk Dittert
the text for the component,
>you can call a method that get's the text for the component or something
else!!! isn't it better?
Well, the myTranslator instance would have a method like yours (using the
default Locale)
myTranslator.getResourceString("myButton.label");
Another one specifying the Locale
myTranslator.getResourceString("myButton.label", "fr");
And if there are multiple property files
myTranslator.getResourceString("myButton.label", "fr",
"theVerySpecialPropertyFile");
Three different methods ?
And after all, as you would use Idea to define the translations, do you
really need to care about multiple property files ???
Guillaume Laforge
well in actuality I don't need pure round-tripping.... but something that isn't a one way street.
I think the reality is that at some point someone needs to edit existing code and does not have access to the gui builder because of logisitics or other issues.
At that point it would be nice to be able to say go ahead fix the code by hand cause I can just have the builder merge the changes into the existing file at some later point. So it's not pure round tripping but i can import the modified code into the builder and not have to re-implement the changes.
This does not have to be seemless. It's ok if the generated code looks nothing like the imported code... as long as the gui looks the same. It's even ok if there are some loose ends to tie in connecting the gui to the app after such an operation I wouldn't really mind. Cause as far as I can tell what everyone hates is dealling with th e billion or so setters in any gui not binding the presentation to the model.
florian
thats pretty good.
>And after all, as you would use Idea to define the translations, do you really need to care about multiple property files ???
yes, i need multiple property files, especialy if i had a application uses a "modul" which can be used for a lot of other applications, too. the "modul" needs another property file like the main application that it's independent!?
Florian Hehlen wrote:
Well, as we are speaking of Holy Grails, here's is mine, opposite to
yours ;)
I do NOT want to modify the generated code at all.
I want to be able to modify the behavior/appearance of a generated UI by
using overrides and/or mutator methods on the constructed instance.
Edo
a "modul" which can be used for a lot of other
>applications, too. the "modul" needs another property file like the main
application that it's independent!?
Hmmm... okay, I think I understand what you mean...
So we need to have a way of defining the right property file to use...
So in each form defined in the XML Gui file, we could define a set of
property files in wich the myTranslator instance should dive into in order
to find the right translation ! Right ?
mainModule commonTranslationsAcrossMultipleApps ]]>
And Idea would append the right locale "fr_FR", etc...
Wouldnt it fit your need ?
Guillaume Laforge
>
+1
Ciao
...Jochen
yes, that works!!! i hope ;)
I'm confident that JetBrains guys will find the right solution for us ;)
But we need to help them get into the right way!
Cheers and have a nice WE !
Guillaume Laforge
thanks. you too!!!
"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:b5f6cn$1qn$1@is.intellij.net...
Also icons and pictures. No kidding. For example, traditional american mail
box is a weird ;) red half-cylinder on a pole. When I first saw localized
MS Mail 3.0 I could not get what this red thingy is. Traditional russian or
swedish mailbox is a blue rectangular box with "POST" on it in yellow or
white. And russian text is, of course, in cyrillics :)
"Guillaume Laforge" <glaforge@reflexe.fr> wrote in message
news:b5f6cn$1qn$1@is.intellij.net...
>
It is essential to be able to use several languages in one form. And I would
not link language to locale: I might want russian locale (for dates and
money) but prefer to see english messages.
Internatiolization problem does not exist if you do it right from the very beginning. Here is a solution I've been using for years.
You don't mess with internationalization while prototyping and developing. In most cases it does nothing good but slow down the development. Instead you embed a hook[s] for a resource mapper. Unfortunately the default property file based framework is too primitive for that but it can be easily extended with a very little efforts. (Of course, the plugability of your mapper gives to you an another advantage. If you decided to put all your localized resources into a DB it would be very easy to achieve.) In most cases all you need is just a simple inheritance so if a mapping isn't found in a local mapping context it would check parent context and so forth. In other words you're using the message itself as a message ID in your mapper.
The beauty of this approach is that even without any mapper you still have human readable messages (instead of STRING12345) in you code (and UI!) which makes it much easier to develop and debug. You can also postpone the development of the mapper untill you're clear of what you want of it.
On top of it you can introduce a very simple syntax for dynamic localization. For example:
Hi! -- would result in a localized string based on the global locale settings
:Hi! -- would always result in russian "Privet!" despite of the global locale <@X>]]>:Hi! -- would use locale defined in a context variable X
etc.
So the bottom line: You don't need to design/expose any localization functionality on the UI definition level but provide pluggable localization mapper instead.
This would require that JetBrains open up the compiler to use in deployed products.
Are you going to only license the GUI builder with IDEA and leave everything else (compiler/generator, framework, generated classes) freely redistributable?
Jacques
Well, that's what I was afraid of. Looks like a yet another frozen-at-birth UI definition language. Please, please, please do convince me otherwise!!!!
Here is my understanding of your idea:
1. You're going to design (or already have) a GUI framework implementation.
2. You're going to use a static proprietary XML input language.
Please correct me if there is anything more in that.
Here is what I have in mind:
1. Define a basic GUI framework interface. (Swing itself is a good starting point for that so you don't actually need to do anything here)
2. Use an XML-like structured language to interact with GUI framework via Java reflection. So the
Cancel Value1 Value2 ]]>
would be translated into something like
my_button.setText(myMapper.map("Cancel"));
HashMap map = new HashMap();
map.put("Key1", myMapper.map("Value1"));
map.put("Key2", myMapper.map("Value2"));
my_button.setMyMapProperty(map);
And my_button is not nesessarily a JButton (or even a GUI component!), it's just an instance of a Java class (with the setText and setMyMapProperty methods) defined/created somewhere else.
So like everybody else you're trying to deal with concrete implementations while I was always thinking of well defined extendable interfaces and pluggable implementations for GUI components and GUI framework itself (that is, my approach would work with any GUI framework not just swing).
Well, I hate to tell you this, but unless you have something more to that then I'm about to loose my interest here. This approach is proven to be very limited and will eventually fail in a long run at least in my field.
Why don't you focus on the open API for a visual GUI editor instead and let the community to develop a variety of plugins for GUI design instead? Your proposed framework can fit into this wery well while being optional.
On Fri, 21 Mar 2003 05:48:08 +0000, Robert Seaton wrote:
This reminds me of Borlands "Frame" component they introduced a few
versions back in Delphi. Select a few components you've put on a form,
and conver it to a frame ( or create New->Frame from the menu ).
You can then just insert that frame on any form, and overide properties of
it on your local instance, you can add additional fields/components to it,
but not remove any existing ones.
On Fri, 21 Mar 2003 09:36:33 -0500, Dirk Dittert wrote:
I believe borland do have a patent on Two-way tools. Which is rather
stupid I thought :( I'm sure you could come up with your own two-way
tools method, it'd just have to be different to borlands.
I would prefer that source codes is generated. In the event that fine-tuning is necessary, the codes is around. Moreoever, not everyone uses IDEA.
On Sat, 22 Mar 2003 03:40:06 +0000, simplicity wrote:
The "not everone uses idea" has been addressed with the available of
standalone/commandline compilers for the GUI designer. Weather these will
be free or not, who knows.
For me the XML does not look 'abstract' enough.
We are currently thinking on a GUI description XML suitable for both Swing & HTML.
Having references to Swing classes is suggesting that IDEA XML->HTML/webapp transformation wouldn't be easy.
We would definetely prefer the idea of a form represented by 'abstract enough' XML document + possible addendums/'customizations' for Swing/webapp.
The form does not have to be represented by a single XML document, it could be a pack of XML documents, like typical HTML page + CSS stylesheet. Here we could have 'basic' XML + 'Swing' stylesheet.
There were quite a few attempts to do this kind of "abstraction". To the best of my knowledge none of them succeeded so
far. Sure you can do some primitive GUI this way but not much. It's not my business of course, but I would not waste my
time on this. Those two beasts are just too different. It looks like an attempt to describe a submarine and a stealth
fighter with one set of drawings, sure they have something in common :( Transformation based approaches seems to
be much more productive and transparent. My approach would handle it even better because you can refer to
custom classes/methods which will generate HTML or whatever else for you.
In fact I never meant to use swing classes directly. Swing is just too poorly and inconsistently designed to make this
possible. You can refer to my comment in
http://www.intellij.net/tracker/idea/viewSCR?publicId=6533
for more details, but the bottom line is that GUI specification can be at the same time considered as an XML and as a
Bean (not java bean as you know it though). All known technologies (XSLT, XPATH, DB persistence etc) would apply
automatically. GUI descriptor would become a just another run-time data structure which can be
loaded/saved/modified/generated/binded/transmitted/etc. the very same way as any other object.
"Igor Karpov" <igor.karpov@mail.ru> wrote in message news:21622309.1048505083851.JavaMail.jrun@is.intellij.net...
>
addendums/'customizations' for Swing/webapp.
HTML page + CSS stylesheet. Here we could have 'basic' XML + 'Swing' stylesheet.
>
JGB is distributed under a GPL licence so IntelliJ would not be able to "adopt" it.
Not that it really matters since IntelliJ already has decided upon the syntax of the XML and such... now our only hope is that they actually publish this as an open source standard, that would really be cool.
Stefan.
>... now our only hope is that they actually publish this as an open source standard, that would really be cool.
... and it can only become a standard, if the license allows use and
modification in commercial applications (as opposite to GPL).
Tom