Slashdot Mirror
Resource-Based GUIs Vs. Code Generators In Java
Java Fan writes, "There is a good debate about GUI generation tools for Java going on at theserverside.com: '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.' Personally, I am partial to BuoyBuilder as a great solution to this issue."
300 bucks for a crappy UI builder that adds multiple layers of abstraction on top of Swing! That sure is cheaper than Visual C# Express, Interface Builder, SharpDevelop, wxWindows, Visual Basic, or any of the GUI builders available for Eclipse!
Wait, no, sorry. It's not.
Nice slashvertisement.
using namespace slashdot;
troll::post();
In theory, I'm not against the use of a GUI builder as long as it provides a way to use all of the layout managers that are available. I've just never seen one that could scale in complexity to the needs of a real world application. Sooner or later, the functionality requirements drive GUI elements to be created based on configuration settings and/or business rules. That is where you hit the wall with the GUI builder.
Anyone who's interested in this issue should look into the java.bean.XMLEncoder and java.bean.XMLDecoder classes. These classes are able to serialize and deserialize complete GUIs. In the past, I've used the Netbeans GUI Builder to develop throw-away GUI frontends, then serialized them to a file rather than using them directly. I then built a framework that used the little-known "Name" property on AWT/Swing components to attach actions.
The results were quite good. Not only was the GUI decoupled from the code, but development was actually accelerated as minor GUI hiccups had no effect on the rest of the codebase. The downside was that the XML occasionally had to be tweaked to perfection as the XMLEncoder class was not 100% perfect in serializing some of the finer details.
A few years ago I spoke with one of the Netbeans developers about making the XMLEncoder format the standard for Netbeans. The idea was met with some resistence, seemingly because there was no actual Java-standard framework to target. The JVM base libraries have the Encoder/Decoder routines, but all the rest of the work must be done by the programmer. (Such as attaching the actions to the components.)
Train yourself to use Swing Actions. It seems like you're creating hundreds of little objects, but what you're really doing is encapsulating actual actions in the system away from their physcial controls on screen. So if you have a button, a menu item, and a toolbar item that all do the same thing, a single action can control all three widgets. This helps smooth out issues like keyboard shortcuts, which can get quite confusing when coding a Swing application.
Javascript + Nintendo DSi = DSiCade
Who can smell the coffee?
"Every developer who requires a GUI to develop another GUI would write code that has the potential to give other developers cancer."
We started a project along the lines of Interface Builder with a Java Swing implementation for our master's thesis in 2005. It's called GINAC, as in GUI Is Not Application Code.
As I really hate designing GUI's in code, I've started working on it again lately, currently implementing something along the lines of cocoa bindings. If anybody is interested in helping out, let me know!
I've never been a big fan of run-time loaded UIs, always preferred the code-generators instead. It just feels better if you can see the code that's going to run, and if you're using a lot of custom components it's more flexible.
Juce and its "Jucer" UI builder is my favourite for this stuff - it generates c++ code with comment-tags for squeezing custom code into the generated sections. A particularly cute feature is that a Jucer document is just a compilable cpp file, with all of its UI metadata stored discreetly at the end in a commented-out block of XML.
I'm not sure how they released without some sort of GUI building tool. I haven't used Java in awhile, but I remember coming up with Shakespearean-esque curses to describe what I thought of GridLayout and their buddies.
Is there an accepted good builder now? The article seems to imply this is far from a solved problem. (10 years later!)
..don't panic
Possibly Java's greatest strategic feature is the classloader that can dynamically retrieve classes across the network at runtime and safely instantiate them. If Java had a standard API and data format for de/serializing UIs that accommodated their remote contexts, applets could become much smaller and dynamically bound to the UI facilities of their arbitrary runtime platforms. If these mobile UIs were componentized with a consistent internal API, applets could share UI elements among themselves on the same host. That architecture would not only reduce distribution size and increase flexibility, but it would promote reuse of the same UI components across applets, increasing user productivity with fewer learning curves.
If those APIs don't already exist, reusing an existing one, especially Flash, would offer possibilities for reusing existing components or patterns already populating the Net.
Java could increase its stature among distributed architectures. And make our lives easier.
--
make install -not war
It's a nice try, and GEE, they got themselves a nice slashvertisement.
But MAN OH MAN, you're not supposed to be able to find numerous bugs (in code and documentation) in the first hour you use ANY project, open source or payware. They've got a long way to go.
No thank you, what happens when they sell a couple of copies then go under. I am then stuck with some libraries I cannot modify or upgrade and a application that will have to then be redone from scratch. I don't care how fancy your wiz bang cool ui generator is, if I do not have the code it is definitely not going into my app.
Got Code?
Java developers though are left with either hand coding of GUIs or potentially messy and brittle code generators.
Whenever it comes to Java it always amazes me how many people have very outspoken opinions about it while its almost immediatly obvious that they hardly know what they're talking about. Then again, when reading the article its becoming obvious that when he's talking about GUI's (since when do you code in a GUI? I use an IDE for that) he actually means to say Eclipse. Don't get me wrong: I'm not dissing Eclipse here, but do question his bias.
When it comes to building GUI's Java really allows itself to be used by code generators IMO simply because Java is very modulair build. The only problem you might face here are the somewhat limited layout managers. For the non-Java people amongst us: these basicly define the "interface" between the GUI you're building and the way it behaves. For example; when it comes to resizing or placing of the objects then you're dealing with a layout manager.
Now... When it comes to Java IDE's two names immediatly spring out: NetBeans (my personal favorite) and Eclipse. Now that he has commented on the latter let me comment on the first. From NetBeans 5.0 and up it comes with a fancy GUI builder codenamed "Project Matisse". Its official name is now NetBeans Swing GUI builder. After taking a closer look at that I wonder if he still thinks that there are no decent GUI builders available for Java.
The real problem here isn't so much the GUI builder but the underlying layout manager which needs to keep things in check. I think that also explains why there isn't much of this available as it looks to me as if there aren't many people about who manage to come up with decent Java coded tools which can be used and adopted by many other coders. NetBeans has solved all this by introducing a layout manager of their own, the so called Absolute Layout. Pro's are its extreme extensiveness, the con's are that if you wish to use it you'll have to ship it with your software because its not part of the standard Java Runtime Environment (JRE).
If you wish to see a demo of Matisse in action then check out the NetBeans flash demos, especially the first part of "Why NetBeans?". Personally I'd recommend another approach, namely simply downloading NetBeans and trying it out for yourself. Its available for Linux, Solaris, Windows and I think even OS X.
> Apple has had this for years with Interface Builder
Presumably NeXT has had it for even longer, a couple of decades or there abouts. IB was written by a brilliant French coder as I recall... he was a friend of a colleague. Short of firing up my NeXTBox does anyone remember more of the history?
I find that the code generators/visual dev environments never create truly maintainable code that adheres to good coding conventions/standards when working with a reasonably complex user interface design.
My approach is to use the GUI designers to quickly prototype the UI and for fast proof of concept. Once I am pretty close to the requirements, it is time to refactor to good coding standards.
With regard to Java, the only approach that I have seen that is flexible and maintainable is to provide the correct getters/setters for Introspection (e.g. a JavaBean) so that your GUI Widget can be manipulated by a Visual designer for future use in other UI's and for maintenance.
NetBeans (available as a Free download) has a very nice built-in GUI builder.
If you don't understand a comment, don't mod it overrated. Here's a clue: F3 & Jaxx
Swing is cool, but we should not code Swing UI manually. By the way, XUL is not an alternative either. Only XMLSchema + SVG has good potential as fundations. Anyway, UI should be more objec model driven than today "hammer party" ...
Try "some proprietary XML, some proprietary binaries". XML is not some magical pixie dust that makes anything encoded with it suddenly open and non-proprietary. A proprietary XML format that happens to be somewhat easier to read than a proprietary binary format is no less proprietary.
XML-based Swing GUI tools are really a dime a dozen, and always seem to add an extra layer of complexity to Swing-based apps. Swing is a really nice component system, and pretty much every object is easily extendable. Personally, I have tried a good deal of the XML-based systems, and really using Swing as it was intended is the way to go. Build your own components, extend them, combine them. I know that there is this idea that you hand over the frontend to a designer, but we all know that most of the time it is the developer hacking on the frontend.
I can understand why people think they need XML-based systems. So much Swing-based code sucks ass. Putting all of your buttons and frames in a big-ass method is nasty and hard to maintain. Well-thought-out componentized Swing code is easy to maintain and nice to look at. Plus, once you are finished with your project, you can re-use any components you built. Swing is a great library - more people need to just learn it.
I hate java applications.
Developers constantly make excuses and try and blame something else for the poor performance. But the end user experience is pretty much always lacking.
I grew up using X windows in the 80's.. I watched applications and UI's get faster and faster... It all seemed to go downhill with java. Systems can't get fast enough to overcome the serialization and the bloat (BTW, Hi Firefox!).
If you report some bugs maybe they would get fixed AC. We are quite willing to fix anything that has been reported, but as of yet, nothing has been reported.
just don't use Java. Problem solved. Java's a great technology, but for end user applications that require GUIs? Not so much.
Right over here! http://malfy.org/
I find IBM's AUIML to be an amazingly good solution. You can design the GUI with a visual tool and write code that runs in Swing as well as in a web server (as a web or portal application). Here's a link to AUIML page on AlphaWorks: http://www.alphaworks.ibm.com/tech/auiml Download seems to be outdated at this time. Look for version 6.x if you want to give it a try.
I've been developing a lot of applications lately with J2EE (thus Webbased). There are some cool things happening there, for example good integration with JSF and Dreamweaver. This lets designers use Dreamweaver while the programmers are programming the back-end.
Also one thing that might be worth looking into is Apache's Velocity, templating at a whole new level.
My blog: http://www.redcode.nl
The Java-Gnome Project uses Glade to build a serializable (to XML) GUI.
I see nothing wrong with this.
Hand coding may not promote a clean separation of concerns, but it does nothing to preclude it. Interface generation does not ensure a clean separation of concerns. In fact I doubt that it does anything significant to promote it.
The problem is that the controller tier is still a user interface component, which many engineers don't seem to understand. The achilles heel in most MVC programs are bloated, unmaintainable controllers. You still end up with important assumptions being spread hither in yon in user interface code. The fact that it is non-visual interface code makes no difference at all. What you end up is not, fundamentally, different from the typical VB program, but often minus the convenience of tying UI elements to event handlers in the IDE.
There's nothing wrong with the MVC pattern, but there is cargo cult that has grown up around it, spurred by the impedance mismatch between browser presentations and server side processing.
You can't force people to do good design by making what the produce resemble a good design.
With respect to XML and other data representations of views, I've dabbled in them, and have not been that impressed. Consider isomorphic view represenations, one in Java and one in XML. Once you've gone through the effort of separating out your contol logic, there isn't much to choose between them. Sure, the XMl is probably language independent. But the Java is trivial, which helps make your code independent of the framework.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Scalable Vector Graphics (http://svg.startpagina.nl) with a bit of XUL maybe
and eXtensible Binding Language are what i'm eyeing
If it were $3000 that would be an "ivory tower response." But $300? That's basically one days salary for a developer.
Java applications never became a hit in desktop environment because of two reason imh .......
JVM Speed issues which will go away over the time may be
GUI and stupid layouts.
Why cant we have one generic layout Manager where we can place our GUI items without layers etc and define its position from boundaries in terms of ratios/percentages. so even if some one maximizes/scales the window nothing goes out of the place and the programmers dont have to juggle with layers and transparent layers and containers and panes
IntelliJ's designer does exactly that. I saves the UI code in XML files and you only need to code the specific business logic in a seperate class. The designer itself is quite nice as well.
I have to say, I'm pretty impressed so far.
Every single application I build these days, either for business or for personal use are based on a web UI. Java has incredible MVC frameworks for building web based applications from Struts, Spring, Tapestry, etc... Honestly, if someone is building a Swing based GUI, I'd have to ask: WHY?
I've always wondered why simply serializing a GUI wasn't used more in Java. Perhaps because Swing is so easy to use. Most java programmers I've known in the past shunned any type of GUI development tool in favor of hand-coding swing because it's so much more straight forward.
Also, it's difficult to get reuse out of a GUI editing tool, but very easy to get it by hand-coding. I generally write factory-type code that handles generating menus, buttons and linked Actions together, in a GUI tool you will often end up having to deal with each of these separately.
Much of the GUI code I've had to deal with is in the form of Properties sheets (large number of controls in predictable patterns). You absolutely should never generate this kind of GUI--or hand code the gui itself for that matter. The entire GUI should be generated from data files.
So in the past, RAD tools for swing were used by more amateur less professional users, and the amateur users are going to feel much more comfortable with generated code. Now that the tools are coming up to the point where professionals are starting to use them, I think we'll see a lot more cases of "Serialize out a finished screen at design time" and "Serialize it back in at runtime". (This was in some of SUN's original Java tools if I remember correctly).
it was in 1984 that we already had ResEdit which abstracted the whole GUI from the code -- it did such a good job, that end users could open a shipping application executable, and go in and change bitmaps, menu keyboard shortcuts, dialogue texts, and sounds -- so long as they kept the same resource ID, the app would keep on working.
.app in OSX, and its a really nice system once you work with it -- it also lets people responsible for layout to do so without having to bug the programmers. abstracting the GUI from the code like this lets the programmers concentrate on coding, and helps the GUI guys get the tools to make things right from the user perspective.
this system was eminently useful in getting mac applications translated into languages other than english, as any user could open the shipping application with resedit, start translating strings, save a copy of the resource, and start shipping a translated version. if the translated text was longer, and wouldn't fit in the dialogue box -- no problem, you could alter the window dimensions right there, and since the ID of the dialogue box was still the same, everything still worked.
brilliant, that's how good it was in 1984... then came windows, and we lost all that. some of it survived in the NeXT OS, which carried over the 'Interface Builder' paradigm to unix. this is ultimately the source of application frameworks, and the nested folder structure of an
best regards,
j.
I use XStream which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial).
Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design pattern. Set the gui elements to return an event id and use a central controller class to send the event flow to the proper commands.
The XML-serialization has a few problems though:
Anyways, XSLT can be used to convert older XML formats to new format and XStream's aliasing functions helps, but you still have to be careful when making changes.
http://www.codeproject.com/cs/library/OpenTheme.as p
GUI builders have been around for as long PHB's have wanted to insert themselves into the development process to speed up development. Don't use them. GUI builders relieve the programmer of the easiest, least demanding part of the development process - widget creation and layout. They add overhead and obscure GUI API's. They offer little to better organize interface callbacks into a nicely designed program. In fact the combination of generated and custom code will leave the next guy who has to maintain your program to wonder what you were thinking.
an ill wind that blows no good
Why not to use Mozilla XUL instead? There are many proficient pure-Java implementations of XUL, including tiny Thinlet.
I'm not sure why Java GUI's being behind the curve and difficult to work with is news. Anyone who has actually used the word 'Gridbag' knows that Java GUI development is a process somewhat akin to Chinese water torture.
Neither of which promote good MVC separation. In fact they tend to encourage violations unless you are a very disciplined coder.
I don't mean to sound all high and mighty, but if you aren't a disciplined coder, then you're not very serious anyway. You can pre-plan the MVC design to your hearts content, but it takes discipline to stay within the boundaries of the original design. Especially since if you don't then you create one of the worst anti-patterns ever, making you wish you'd just written one monolithic chunk of procedural code because bugs/changes would be doable.
If you use Qt for your interface, their GUI builder is pretty good. And it's free. And it generates C++ that you can inspect, modify and understand.
Currently hooked on AMP
So what good resource based GUI builders are there for Java? This is the one thing I have been hunting for, after having developed for the Mac and Windows. I can't stand code generators, since the code is usually large and ugly, and usually require some hand tweaking because the code generation has limitations. I once saw a solution that was written to use XML for the resources, but it ended up almost being as large and monstrous as the Java code it was meant to be replacing.
Maybe using Microsoft's GUI XML format could be a solution? Quite honestly I really think a JSR to make a standard Java GUI resource format would go a long way.
Jumpstart the tartan drive.
Java already has external XML GUI description files. They are the .form files generated by Matisse. Matisse lets me drag and drop together a GUI just like any other drag and drop program. It's not brittle; it's rock-solid, fast, and it makes the best-looking forms I've ever seen. At this point I would prefer to build a Swing app over a Web app, because Matisse makes the Swing app so much easier to build and make it look good.
The one problem with Swing is it is capable of doing too much, which makes some of the simple stuff more complicated than it should be. But I can do any kind of visual effect I want to do. Spend a week or two using Matisse and then decide what you think about Swing.
HyperCard was originally released with System Software 6 in 1987.
HyperCard was more advanced than NeXTStep in 1987, and in many important ways it is still is more advanced than Cocoa in 2006. In all the 18 years since the release of NeXTStep, it STILL does not let users edit their user interfaces the way HyperCard did. It has none of the user-customizable run-time flexibility, which was one of the most important features of HyperCard: it enabled anyone (even kids) to construct their own user interfaces.
Even OpenDoc (from 1992) and Cyberdog (from 1996) let users edit their own interfacs at run-time.
The technology behind Apple's Cocoa is old an outdated, and unimpressive and unimaginative compared to older but more advanced technologies that Apple dumped and forgot about.
-Don
Take a look and feel free: http://www.PieMenu.com
If you haven't used Interface Builder (IB), then you are really missing out. Many people have a difficult time wrapping their brain around the concepts of Interface Builder, but I assure you it is across the board the best GUI builder paradigm yet invented. For a very brief introduction to its concepts, see Hold Me, Use Me, Free Me http://www.stepwise.com/Articles/Technical/HoldMe. html.
. htmlr Tools/Conceptual/IBTips/IBTips.html
In fact, IB should have been named "Object Connector" because it is not a "builder" at all. All IB does is let you instantiate objects, specify their initial state, and define connections or relationships between the objects. You should note that it is equally applicable to user interface objects and every other kind of object including your own custom classes. The configured objects are serialized to either a binary file or an XML file (your choice). The "Test" mode in IB just serializes and then de-serializes the object graph in memory to produce a fully functional system that you can test.
Although Interface Builder has been available since 1988, it is actively developed by Apple and is in fact free along with the rest of Apple's development tools with Mac OS X. Recent additions to Interface Builder have included Key-Value Observing which eliminates al lot of "controller" code from a system and Data Modeler which automates a lot of "model" code.
Steve Jobs used to state that it doesn't matter whether code is hand written or computer written, every line of code is a potential bug and a source for future maintenance. The only way to radically improve programmer and life-cycle productivity is to radically reduce the amount of new code needed to implement applications. IB is a stellar example of the wisdom oh his words. [This is also a huge win for cultural localization...)
Given the extremely rich frameworks of objects (both GUI and non-GUI) that are available from Cocoa, IB's ability to instantiate objects and form connections and relationships between them without any code is a huge win. If you haven't used this technique, trust me: you don't know what you are missing. You will never want to go back!
IB's down side has always been documenting (for posterity) all of the connections and relationships that are specified in IB. IB is improving on that front with XML file formats and data "entity-relationship" modeling built in. There have also been plug-in palettes that improve documentation generation.
Just as a reminder, unlike most GUI builders, IB works equally well with your custom classes and the framework classes. You can build new "palettes" for you objects to provide slick graphical interaction, but the basic connections and relationships capabilities work with all objects with no special effort.
Apple's IB description: http://developer.apple.com/tools/interfacebuilder
There is an excellent but shallow Introduction to Interface Builder at http://developer.apple.com/documentation/Develope
You should check out the Buoy project http://buoy.sf.net/, it aims to be the 10% of Swing that you need 90% of the time. Its got a great event model as well.
I use netbeans to create the GUI components with NO APP LOGIC IN THEM AT ALL. I never edit the files that the GUI builder creates. I set the flag so the components (JButtons, JTextArea's and such) are public, and give them human readable names. (i.e. viewTableButton, hostNameTextArea)
Then in my application, I create an instance of the GUI panel wire up actionlisteners wrap it in a JFrame and I'm done. I can rearragne the GUI later, and since the widgets don't change names, it all still works.
-- ac at work
OpenLaszlo is a great way to write "AJAXian" dynamically downloaded componentized data driven applications, that run in the Flash player and DHTML/JavaScript browsers (and eventually the J2ME Java VM).
For many years, I've been building distributed data driven scriptable user interfaces, and evangelizing what's now called the "AJAX" architecture. Here are some old articles I wrote about X, NeWS and TCL in the 80's and 90's. Note that in this context "server" means window server (your desktop: once called the window server, now called the browser client), not web server (the remote system running the application: once called the application client, now called the web server).
-Don
From comp.windows.x, 1989 and xpert@athena, 1987:
From: Don Hopkins (don@brillig.umd.edu)
Date: Tues, Sep 19 1989 8:08 am
Groups: comp.windows.x
I think it's a pretty good idea to have the window manager, or some other process running close to the server, handle all the menus. Window managment and menu managment are separate functions, but it would be a real performance win for the window and the menu manager to reside in the same process. There should be options to deactivate either type of managment, so you could run, say, a motif window manager, and an open look menu manager at the same time. But I think that in most cases you'd want the uniform user interface, and the better performance, that you'd get by having both in one process.
I think it would be possible to implement something like this with the NDE window manager in X11/NeWS. It's written in object oriented PostScript, based on the tNt toolkit, and runs as a light weight processes inside the NeWS server. This way, selecting from a menu that invokes a window managment function only involves one process (the xnews server), instead of three (the x server and the two "outboard" managers), with all the associated overhead of paging, ipc, and context switching.
Here's a message on a related subject that I sent to xpert a couple years back (before I'd heard of the ICCCM). I never did get much response, except that one person pointed out that that was precisely the problem that NeWS was designed to solve. ;-)
c(-; Once were done forging the menu manager standard, how about we do text editors, huh?)
-Don
Date: Mon, 23 Feb 87 18:31:00 EST
From: Don Hopkins don@brillig.umd.edu
To: ru...@ucbvax.berkeley.edu
Cc: xpert@athena.mit.edu
Subject: Uwm extensions, perhaps?
I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to con
Take a look and feel free: http://www.PieMenu.com
First a disclaimer that I work for IBM. Similarly, my comments don't necessarily reflect that of my employer, etc, etc, etc...
r /application/
http://www-306.ibm.com/software/awdtools/develope
I use it for all the coding work I do. It has a GUI building tool that only generates Java code. Its much better than the old visual age line of products that required separate files to manage the GUI construction. You can even edit most of the generated code manually without fear of no longer being able to use the GUI builder. It uses (Eclipse) as its base platform so other eclipse plugins can be added to the tool. It includes extensive tools for other web related development as well (DB definitions, EJB work, XML, etc...)
Granted, it's listed as ~$2k for 1 license, so its not for everyone, but you'd be hard pressed to find a java/web development function that it doesn't help you with.
Dan
G
"Plurality should not be posited without necessity." - William of OccamFoam used XMLEncoder waaay back when Java 1.4 first came out. http://www.computersinmotion.com/ they have some example videos. It sure is nice to have your panels created in one line of code :-)
I like the way Qt (v4) Designer does it. The output of Designer is an XML file, and during the build stage uic (ui compiler) generates a form class. This class is not a widget (as it was in v3), but a very minimal class that's only one step away from being a legitimate POD class or struct. All it essentially contains is the form's component widgets as public data members, aand setupUi() function to layout the form in the widget you pass it. It doesn't inherit from anything.
This gives you a lot of flexibility. You can use the UI object directly, as a data member, or through multiple inheritance. You can even load the XML ui file at runtime if you wish, using the QtUiTools library. It also give you a clean OO design, as the UI itself is a stand-alone object.
Don't blame me, I didn't vote for either of them!
Using XML micro-formats is a more dynamic and flexible approach than persistent objects. Your data is much too important to tie it directly to the internal implementation of one particular version of one particular class.
The approach that OpenLaszlo takes is XML data binding and declarative constraints. You design XML "micro formats" for your data, and then you can write many different views and editors of the same data, by binding different OpenLaszlo classes to the XML data with XPath constraints and JavaScript expressions. (As well as methods and event handlers written in JavaScript, declared in XML).
That way you can have many different viewers and editors that are compatible with the same XML data, and you can use constraints and JavaScript to bind and tailor off-the-shelf and custom widgets together with the XML data. JavaScript constraints are automatically updated when the values they depend on are changed. The two-way XPath data binding between the XML and the OpenLaszlo objects automatically updates the XML and all other views bond to the same data.
It's not just old-school cargo-cult MVC. OpenLaszlo uses a more powerful, general purpose, easier to use approach: data binding (XPath), declarative constraints (JavaScript), with a prototype based class system.
-Don
Take a look and feel free: http://www.PieMenu.com
Jigloo is a great and inexpensive way to write swing/swt guis. (its an exlipse plugin)
The code it produces is simple and clean.
It might not be good for really complex interfaces, but for everything else it rocks.
My point is, that NeXTStep / Cocoa is NOT among the wonderful user-editable software inspired by HyperCardCounter-examples of "wonderful user-editable software inspired by HyperCard"?
At this point, it's an old, obsolete architecture [...]Did you miss your parent's mention that iWork and practically all the other Apple-blessed apps are built with Xcode using Cocoa? How exactly is a framework currently in wide use producing great software "obsolete"?
It does not support run-time scripting and user interface building and customization like HyperCard and OpenDoc did.Just plain wrong... F-script. Allows run-time scripting of Cocoa apps.
Methinks ya need to get off the HyperCard horse. It was a toy. A very neat, powerful, interesting, creative toy, but still a toy. How many programming languages could be used w/ HyperCard? Can you give me examples of HyperCard applications of any significant complexity? I thought not...
Seriously, HyperCard isn't even in the same league as Cocoa w/ Xcode.... might as well come off it already... sheesh...