|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 41
Messages: 41
Messages: 41
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ask TSS: Resource based GUIs vs. Code Generation
Java is frequently maligned for not having 'native feeling' GUIs. But yet the tools for creating Java GUIs aren't in the same league as those used for 'native' GUIs on the various OS's.
Almost every platform has a visual designer that serializes the GUI to resources (some XML, some proprietary binaries) and then attaches it to the controller at runtime. Apple has had this for years with Interface Builder, Vista has a similar philosophy now as well.
Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.
The GUI should be able to be created without the code and the converse should be true as well. The controller code should be completely independent of the GUI code, and not be hampered in any way by the tool that generates the GUI.
Code maintenance becomes much easier as well. Editing the GUI to make small adjustments has no effect on the code at all, so no bugs can be introduced. Also with a resource based GUI, there is no need to worry about hacks to the code that make it illegible to the parser.
With all that being said, why is it that code generators are still so prevalent in Java?
|
|
|
Message #223034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
Well, I think the reason it is the way it is, is that all the Java money went server-side, J2EE, etc. Plenty of investment in JSP, JSF and other templating technologies for web-based stuff. Swing GUIs became a bit passe.
I see a slight change though as people get bored with plain HTML and want RIAs. If it isn't AJAX in the browser then I suspect that there is a fairly large minority of Java client apps whose GUI is built using some kind of declarative language. There are quite a few options now such as SwiXML and Thinlets.
Personally I'd like to see such a feature for Eclipse, or Spring RCP.
Kit
|
|
|
Message #223036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Been doing that, sort of
For about 8 years now I've used a custom-built interface builder that stores the interfaces outside the code, in XML format that can be tweaked even while the program is running.
A custom JPanel reads the XML and builds the interface on demand, instantaneously.
The interfaces can be updated in place with data embedded in XML that follows the same "outline" as the interface descriptors, and default data can be included in the descriptors.
I've designed and used hundreds of interfaces this way, keeping all that tedious interface code out of my programs.
Examples: http://www.unc.edu/~uncled/DVMPortfolio/ProjecTier.html
|
|
|
Message #223044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
swixml is nice...
but i found that in the end you just move your bugs to the much harder to debug xml file.
What is really needed is a wysiwyg editor, a bindings language and a hierarchical component model of those gui-xmls (think of parameters for xml components)
Don't know about vista but Interface Builder has been around for so many years and it still provides a so much better experience than anything on the pure java side.
apple has stopped to support their cocoa-java gui framework that was using Interface Builder on top of Swing-subclasses.
Technologies like Webobject's direct-to-java (the cousin of direct-to-web) and Enterprise-Objects (with client side code and properties) never got enought attention.
|
|
|
Message #223048
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BuoyBuilder for resource-based GUIs
What is really needed is a wysiwyg editor, a bindings language and a hierarchical component model of those gui-xmls (think of parameters for xml components)
You should check out BuoyBuilder (www.buoybuilder.com). It also serializes its components to XML, but provides both a layout tool to design your GUI using drag and drop and a document loader that actually loads the GUI from XML and, at runtime, dynamically attaches it to your controller. The layout tool also has the ability to dynamically register callback methods for events so your controller doesn't have to implement ActionListener interfaces and inspect events.
It also includes goodies like automatic localization, extended layout managers, and the ability to incorporate custom widgets. From reading some of the posts the creators modeled it after Apple's Cocoa and Interface Builder.
|
|
|
Message #223055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Separation of gui and logic
This is very good to handle by using products like swixml, thinlet, SwingML, XMLgui, Gui4j and so on.
By having it really separated, one is able to manipulate the gui without changing or compiling the source code.
I would advise every Java developer to look at those products if they do client side programming.
|
|
|
Message #223058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web Application
Romaframework uses the MDA approach: create your domain object model and plug the other aspects.
Current release of Roma generates the GUI as Web Application (100% Ajax, using Echo2 rendering engine). The GUI is generate automagically reading your domain POJOs.
CRUD are generated by the Wizards (code generator).
Customization of generated HTML is done by annotations in classes and by editing the stylesheet.
Ciao,
Luca Garulli
AssetData.it
|
|
|
Message #223064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
prevalent? it depends
Java is the unverise of choices. Plenty of markup languages based GUI technology.
JSF/JSF is a typical example, while ZK takes a step further. Even for mobile GUI, there is Thinlet.
|
|
|
Message #223065
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Call to NetBeans and Eclipse
Please, please NetBeans and Eclipse guys (and other GUI builders) SHOULD (MUST) work together on a XML standard (or something like that) to describe static GUI layouts (Swing mostly), the current "code generation" approach is a bit crappy.
Microsoft world has this type of resource description years and years ago...
Jose M. Arranz
JNIEasy: bring your legacy C/C++ code to "natural" Java
AsPeopleSay: The first democratic syntactic analyzer.
|
|
|
Message #223071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't agree
The controller code should be completely independent of the GUI code, and not be hampered in any way by the tool that generates the GUI.
Controller code is never independent of the GUI! Its only purpose is to control the GUI. The manipulations, one can make to the GUI, which do not affect the controller code, are really minor. There is no single reason, why controller code should not depend on the GUI!
Things that will make GUI coding more efficient are:
o Usage of meta information from the business model
o An intelligent data binding mechanism
o Inheritance
Ideally, you have a mechanism, that accumulates meta information from different sources:
o Reflection (properties and their types, enums, primitives are not nullable)
o OR- Mapping if applicable (nullability, precision, scale, length, relations)
o Annotations (format, validation)
o Authorization
o Localization
.. and automatically utilizes them, when building the UI. We've made good experience with this approach in our OSBL.
|
|
|
Message #223081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Independent controller definition
Controller code is never independent of the GUI! Its only purpose is to control the GUI. The manipulations, one can make to the GUI, which do not affect the controller code, are really minor. There is no single reason, why controller code should not depend on the GUI!
I think the definition an "independent controller" is getting misunderstood. Correct, the controller should receive events from the GUI, process them and update accordingly. However, the Controller should not be concerned with laying out the GUI, localizing it, or even the structure of it. Once your controller starts doing that, it really because an extension of the view.
|
|
|
Message #223084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
In typical TSS style two camps are put against each other. What a non-sense.
Yes, resource based is very nice.
And yes, some code generation tools are so good, that you never look at that code.
I have used JFormDesigner on a large GUI project. We actually handled the generated code exactly as if it was a resource. Perhaps the integration was even better as we simple programmed our own code (listeners and such) in a class that extended the generated code.
|
|
|
Message #223087
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
This is a very good question given that Swing is completely designed for dynamic gui generation. Using it to hard code guis makes very little sense.
Honestly, I think it comes down to a lack of imagination. It's not confined to this topic. Take the 'pojo' revolution. It's really the JavaBean revolution and JavaBeans are IMHO, the worst idea ever introduced into Java. I don't know exactly who came up with it but they must have confused Java with SmallTalk. Hibernate and Swing work with objects that act as hard-coded maps with all the problems of map based design and almost none of the flexibility. It's beyond stupid that adding a new query to a system starts with 'write a class with getters and setters'. It's the same thing as with Swing, let's take something flexible elegant and dynamic and cut-off it's legs with 10,000 lines of code. It's become the Java MO.
Sorry to get off-topic here but I needed to get that off my chest.
|
|
|
Message #223089
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Call to NetBeans and Eclipse
Microsoft world has this type of resource description years and years ago...
Unless it is an option, .Net uses class files for WinForms. More correctly, .Net 2.0 uses partial class files.
|
|
|
Message #223090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The client side is not just GUI
The client side is not just GUI.
This is the one thing that is easy to loose out of sight.
If you think of the typical business system as a channnel of communication between the database and the user, the server side acts as a proxy between the database and the network, while the client side acts as a proxy between the user and the network.
This should remind us that objects handled by the program logic are as complex either side. It is at this point that the biggest basic failure of user side designs materialize.
This is also why code generators become a problem, resource based GUI engines stay relatively unknown, and practically every major project choses to hand code their user side once again, inventing their own resource schemes, sometimes also GUI frameworks.
The problem becomes clearest when you consider complicated objects that for example are finite state machines. For each significant state, the significant attributes, and the possible state transitions one needs mechanisms to communicate, check, remmber, bookkeep, apply business logic, show, and react to user inputs.
In this picture, the GUI specific code takes care of the verbs 'show' and 'react'. The client specific code is, in addition to the GUI specific, possibly the business logic. The rest is essentially similar to the server side.
Out of the whole the 'show' and 'react' bit is essentially a thin layer between the GUI library (SWING, SWT, Motif, etc..) and the business objects handled.
The client is actually a server (remember X-server?) serving reactions from the user as the database side (serveside) requests them. It also has a model of the users point of view (Window/Display manager). It desperately wants to be asynchronous just like the user.
Most tools, platforms, techniques that are supposed to help building GUI's, clients, user side applications only help at parts of this big picture.
In my opinion this is the problem. The code generating GUI tools falls short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them.
|
|
|
Message #223091
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The client side is not just GUI
In my opinion this is the problem. The code generating GUI tools falls short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them.
I'm not sure I follow but it seems to me that the entire swing architecture could easily be described with an XML schema which could then be used to script GUI construction. Can you give an example of something that could not? The Action class (often overlooked) could be used to link the GUI to the code. The big problem I've seen in GUIs is that they have hard references to business processes at best and at worst they actually have business logic embedded in the code.
|
|
|
Message #223096
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who needs code generators anyway?
Java is a very modulair build language which makes it ideal for basicly grouping these building blocks together and thus forming a GUI, no need to re-generate the same code over and over again IMVHO. Just put the right "blocks" together. The Bean Builder is IMO a very good example of that.
Another example, to a certain degree, is given by the NetBeans Swing GUI Builder which is formerly known as Project Matisse. It basicly generates the entire method which creates the GUI and defines all of its listener methods and allows you to insert your own code in every method invoked by an event triggered by the GUI.
So while I do agree that these kind of code generators are scarce I seriously wonder if we actually need them. IMO all you need are good building blocks.
|
|
|
Message #223098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Who needs code generators anyway?
So while I do agree that these kind of code generators are scarce I seriously wonder if we actually need them. IMO all you need are good building blocks.
I think you missed the point here. No one said the generators are scarce. The point of the post was that they are too prevalent.
What I don't understand is why people will go to all the effort to write a generator to write code that will build a gui at runtime. Why not just go one step further and write code that builds a gui at runtime based on structured input? It's not much harder and it's much more useful.
|
|
|
Message #223108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Craft by Hand
I have had a lot of experience with GUI work (including GASP!! Visual Basic). On my latest project though we have been building a GUI using Swing and the JGoodies libraries. The binding library supports Martin Fowler's Presentation Model. The Forms library has a nice layout manager called FormLayout that has a very simple descriptor language. I have to say after doing VB development I much prefer developing with these Java tools over the drag and drop method even VB provides. You have more control over your code and it produces very nice looking GUIs. I think it's even possible to develop more functional feature rich apps like this over anything a drag and drop or a xml describe method can provide.
Before the project started we reviewed a couple of Java layout tools and none of them cut the mustard. The most common problems were: 1. They only handled the simpler problems GUIs tackle. 2. They couldn't handle odd user requirements. Like dissimilar object graphs that needed to be joined together into the same view or grabbing values that are only related to the object graph during the user's session. 3. Inefficient code was generated. 4. Aesthetically the screens didn't look nice and trying to tweak the descriptor (i.e. XML) language either wasn't possible to make it look nice or produced other undesirable effects.
I think most people who speak up about rich GUIs are already biased against them because the Web has become the bread and butter for most. There is however still a need for rich clients for things like high volume data entry. I have seen data entry people make even native clients look like them perform badly.
|
|
|
Message #223109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a red herring if there ever was one
"Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators. Neither of which promote good MVC separation."
Neither of which HAVE ANYTHING AT ALL TO DO WITH MVC
|
|
|
Message #223111
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GWT solution
I've been working on a project in the Google Web Toolkit for the past couple months and I've enjoyed how these problems are dealt with. While it is a web tech, programming GWT feels just like programming Swing/SWT code. It's very impressive. Better yet, after it's compiled to javascript it's styled with CSS. It's not perfect, but you can make a lot of design/layout decsions without touching a line of code.
Obviously this is a web tech so some things are different, but having a css-esque layer for swing to take care of positioning/alignment/etc would be appealing to me.
|
|
|
Message #223112
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Craft by Hand
You have more control over your code and it produces very nice looking GUIs. I think it's even possible to develop more functional feature rich apps like this over anything a drag and drop or a xml describe method can provide.
Are you proposing that there are Swing object graphs that cannot be represented in XML or something else?
|
|
|
Message #223118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
Why do people like to program in xml/properties better than Java?
|
|
|
Message #223121
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
Why do people like to factor out configuration into .properties and/or xml files?
Why does Spring exist?
Why would I want to represent components of an application in a simpler, static manner when I could code them all up in Java?
etc. etc.
|
|
|
Message #223124
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The client side is not just GUI
In my opinion this is the problem. The code generating GUI tools fall short because widgets/subpanels are shadows of the objects, not the other way. The resource based GUI tools are useful but not fully so because objects of the business often can not be fully described with them.
I'm not sure I follow but it seems to me that the entire swing architecture could easily be described with an XML schema which could then be used to script GUI construction. Can you give an example of something that could not? The Action class (often overlooked) could be used to link the GUI to the code. The big problem I've seen in GUIs is that they have hard references to business processes at best and at worst they actually have business logic embedded in the code.
I agree that you can do quite a lot of useful things. The problem that I am pointing at remains. "Action class .. to link the GUI to the code" illustrates it neatly. What you call "code" is the sunken part of the iceberg. It is a bit too big and support is only partial.
Examples are custom widgets to represent your complicated objects by specifying their looks and behaviours in XML in such a way that you can connect these to details of messages to and from the database side with a minimum of custom code. Most tools leave slightly complicated things to yourself.
The business of the database side is to keep, and watch the books/intelligence of the company. The business of the user side is to present these to, and maintain the dialogue with the user in perfect cognitive ergonomy. Mixing the business rules of one, into the logic of the other is likely to have a delayed cost. May be I should have written "-user side- business logic".
|
|
|
Message #223138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
Why do people like to factor out configuration into .properties and/or xml files?
Why does Spring exist?
Why would I want to represent components of an application in a simpler, static manner when I could code them all up in Java?
etc. etc.
You are confused. Code written in Java is 'static' under any technical usage of the term. Using a input file in XML or other format to script actions in Java is 'dynamic'.
|
|
|
Message #223139
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The client side is not just GUI
I agree that you can do quite a lot of useful things. The problem that I am pointing at remains. "Action class .. to link the GUI to the code" illustrates it neatly. What you call "code" is the sunken part of the iceberg. It is a bit too big and support is only partial.
I don't follow you here. A GUI framework need not and should not support the core logic of the application.
Examples are custom widgets to represent your complicated objects by specifying their looks and behaviours in XML in such a way that you can connect these to details of messages to and from the database side with a minimum of custom code. Most tools leave slightly complicated things to yourself.
How is that worse than leaving everything to yourself? It seems to me that a good XML gui builder framework should support custom components instead of trying to do everything for you. This 'you don't have to think' approach to tool design drives me nuts and is the norm. Perhaps that is the issue you have run into.
The business of the database side is to keep, and watch the books/intelligence of the company. The business of the user side is to present these to, and maintain the dialogue with the user in perfect cognitive ergonomy. Mixing the business rules of one, into the logic of the other is likely to have a delayed cost. May be I should have written "-user side- business logic".
You've lost me. I don't know what this has to do with drawing a gui on the screen. Maybe I'm not being clear.
|
|
|
Message #223142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Resources are crap!
I can't believe you are honestly trying to push GUI code into cryptic XML files or VC++ style resource files. Do you know how happy I am we *don't* have that kind of crap in Java? Ever try diffing two GUI resource files? It's a nightmare.
Code generators are smart because at least you get type safety (compile-time checking) and they're easier to DIFF. The only thing that might require some improvement is more flexibility to insert user code around generated code and/or making generated code look a bit nicer. Aside from that I honestly don't see what your complaints are :) Just my 2 cents.
Gili
|
|
|
Message #223149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Resources are crap!
I can't believe you are honestly trying to push GUI code into cryptic XML files or VC++ style resource files. Do you know how happy I am we *don't* have that kind of crap in Java? Ever try diffing two GUI resource files? It's a nightmare.
Code generators are smart because at least you get type safety (compile-time checking) and they're easier to DIFF. The only thing that might require some improvement is more flexibility to insert user code around generated code and/or making generated code look a bit nicer. Aside from that I honestly don't see what your complaints are :) Just my 2 cents.
Gili
If the generator wrote a simple 'script' and not a ton of classes, I might be OK with it. The problem is that it's not nearly as flexible as creating a document that describes the gui. That structure can then be rendered as needed in (theoretcially) any language and gui framework, even AJAX, perhaps. That would be a more complicated task than what I'm really imagining but you still get a good amount of flexibility even if it's Swing specific.
As far as diffs are concerned, XML can sometimes be hard to diff because it's often munged onto a single line and the order of same type siblings is not significant. I've resolved these issues in the past with a pretty printer that sorted such siblings prior to running a diff.
|
|
|
Message #223152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Both are needed
Code generation has been pretty useful and met considerable success in the Java world. It introduces that additional level of indirection that shields your code from the platform/s it'll eventually run.
Having said that it'd be good to see some resource based GUI for Java at least for Windows and Linux.
Peace,
Paul C.
Sr. Developer
jBilling - The open source enterprise billing system
|
|
|
Message #223154
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Both are needed
Code generation has been pretty useful and met considerable success in the Java world.
I've seen very few cases where it was really needed and it almost always hamstrung me where it was used.
It introduces that additional level of indirection that shields your code from the platform/s it'll eventually run.
How does code generation shield your code?
|
|
|
Message #223183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XML won't help
The core problem here is that still even more GUI builders for Java suck. And the idea of making it run time configurable using XML is even more sick, IMHO. Apple (or rather next step) has shown how to build guis easily using graphical tools years ago. The one thing that is needed desperately to be really productive is not the storage anyway (Netbeans can serialize the objects anyway), the problem is that there is no standard, high quality application model in the Java Space. Also, of course, "standard" java still misses some standard (non graphical) components one would need to be really effective using this approach.
|
|
|
Message #223188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: XML won't help
The core problem here is that still even more GUI builders for Java suck. And the idea of making it run time configurable using XML is even more sick, IMHO. Apple (or rather next step) has shown how to build guis easily using graphical tools years ago. The one thing that is needed desperately to be really productive is not the storage anyway (Netbeans can serialize the objects anyway), the problem is that there is no standard, high quality application model in the Java Space. Also, of course, "standard" java still misses some standard (non graphical) components one would need to be really effective using this approach.
Hi Karl,
If I uderstand you right, then I totaly agree. What is lacking in java is a real component model. By this I mean a way to link together objects after compile time.
It all started with C++ and the idea that you could have a viable component model by using a static language with complex runtimes like COM and CORBA. It didn't work.
NextStep showed that for a viable component model what you really need is a late-bound, dynamic programming language. Objective-C as used in OSX and NextStep is a late-bound, dynamic, OO language. The web guys have caught on to the benfits of late-binding and are using http, and URLs to create mashups from re-usable web components, yet we still do not have a viable way of doing the same thing with Java objects.
I agree that Spring and XML is no subsititue. When will the mainstream wakeup to this basic fact?
Paul.
|
|
|
Message #223190
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: XML won't help
How about JMS as the binding?
You will still need to configure JMS though.
|
|
|
Message #223192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: XML won't help
How about JMS as the binding?
You will still need to configure JMS though.
Hi Satilmis,
Strange as it sounds, JMS would be a move in the right direction. Pure OO languages are based on message sends. So binding to another object is a matter of sending a message at runtime. To do this you do not need to know anything about the recieving object such as its class.
Using message sends leads to true polymorphism, where the recieving object can take any form as long as it suppports the message protocol used by the sender.
The anology with the web is clear. You can post to any URL what ever message you like as long as the receiving page supports the message protocol at runtime.
Unfortunately like I said before this was a basic misunderstanding in C++, and the idea of object Class (implementation) became confused with Type (interface) and we ended up with the virtual function call instead of a message send as a way of meeting the needs of an optimising static compiler.
Objective-C avoided the C++ route and stuck to pure message sends, Java didn't, and the rest is history.
Paul.
|
|
|
Message #223229
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: XML won't help
The core problem here is that still even more GUI builders for Java suck. And the idea of making it run time configurable using XML is even more sick, IMHO. Apple (or rather next step) has shown how to build guis easily using graphical tools years ago.
I think you misunderstand. The point is not to hand-craft XML. You would have a WYSIWYG editor just like you describe. The difference is what this tool would produce. Does Apple's tool generate code?
Using the xml to make it configurable at runtime isn't sick. Do you think cascading-style-sheets are sick? It's the exact same concept.
|
|
|
Message #223231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: XML won't help
The web guys have caught on to the benfits of late-binding and are using http, and URLs to create mashups from re-usable web components, yet we still do not have a viable way of doing the same thing with Java objects.
Nonsense. I'm doing finish up Java code that does it right now.
|
|
|
Message #223268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ask TSS: Resource based GUIs vs. Code Generation
In other words, the web is a good platform for applications, and HTML (or HTML-like format) is a good presentation layer.
I completely agree. The internet is good *because* of HTML. Can HTML be improved (or scrapped and replaced with something better)? Sure, but the general concept is good. Can we use something besides stateless HTTP requests? Sure, but Ajax can handle a lot. GUIs will be built as documents (or components) built from tags and driven by stateless request/response cycles for a long time to come. Rich client GUIs are getting more like web apps, not the other way around.
|
|
|
Message #223436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The client side is not just GUI
What are we talking about?
Looking at all this discussion, I would like to ask this simple question - how much of guis do you need for your application and how complex should they be?
From my personal experience, user interface in most cases is very simple and requires a very short list of fields with respective input from the user. In that case what you call a resource based gui is much more preferrable and easy to implement.
The burden of bundling code with a gui form has a long history (starting from 1977 when the first work on dialogue generators was published). Smalltalk-80 also added to it.
Projects like Thinlet are targetted in the right direction.
I am not sure you need XML (with the burden of its parsing and conversion to XML) for describing the gui forms or resources. It can be done with much more primitive mark-up.
The advantage of separating resources or dialogue forms from code that deals with presenting them to the user is not new in its essence. It was used starting from 1978 for building user interfaces on various hardware/software systems. Simply this work is not known to the Western software community just because it was done in Russia.
There were a lot of comments about Struts as the nice way of building web applications. Don't you think that it is too heavy for them? There is a lot of statements that those frameworks utilize MVC, but nobody realizes that MVC is much more than just a pattern for guis.
|
|
|
Message #223503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'll take bothe Resource based GUIs AND Code Generation, thanks!
From my POV both are neccessary:
- I use code based GUI to take full advantage of inheritence and such (code reuse is the most important thing after all)
- I use resources for stuff which need resources: for example in java, I would prefer to have an HTML resource for formatted text: "this is a [b]fancy[/b] resource". Then this HTML can be used in most (?) of the SWING elements (or as I prefer JEditorPane) with text/html content...
Kind regards,
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
