Discussion and feedback on the JDNC Article
Forgot to say - there is no one size fits all or hard coding.
It is totally flexible and pluggable. Just plug in the PersistenceWorker to fit the storage mechanism. None of the Screen code has to be re-written. That is the entire point of introducing the extra layer (of abstraction).
If I can (please) ignore the XML verus code dogmatism can I ask how do will you configure such a system? Are you going to hard code the layers?
You say there is no binding required so how is one layer to know which PersistanceWorker to use in the next layer? The same interface perhaps, but which instance? Is it random or is there just one possible instance?
As Ocean suggests giving developers a better starting point for building applications will be of great benefit but I think there's much more involved than just validation and localization.
To configure you set the PersistenceWorker you call
where the PARAM is of the form XmlPeristenceWorker.createInstance()
or EjbPersistenceWorker.createInstance() etc...
This is done as part of the startup sequence for the application..
There is just one PersistenceWorker instance for all the Data Objects, i.e. A PersistenceWorker can take any Datanode (see the ref below) as a parameter and work out how to persist it from a getType() and deriveFieldMap() methods in the Datanode Object. That is the clever bit. We call it 'Generic Processing'... The implementation of the PersistenceWorker is as simple or as complex as the mapping between the types and field names of the Data Objects and the element names (for XML storage) or table and column names (for SQL) of the underlying storage. We have off the shelf ones that assume certain file/table formats...
We will have all the tutorials ready by Oct 15th...
However the 'theory' is at:
I am afraid the document is not finished or baselined yet and its pretty dry (our equiv of the Java lang Spec)... but people have managed to get the gist from it..
We haven't tried using random number generators for configuration... ;)
If you are genuinely interested (rather than just keen to extract revenge for my outspoken views on XML :-) ) let me know and I can point you to Javadoc or even send you running demonstrations... might be better to e-mail me (address in my profile) rather than fill this thread up with stuff not everyone will be interested in ...
How do you cope with the variety of requirements that many modern application have to handle. For example you may have a mobile client with several communications routes to a server, you may also have many types of client device, several desktop environments etc... The requirements of each client may differ and furthermore the requirements may change over the lifetime of the client/application. How would you for instance introduce a diagnostic layer?
I for one don't think hard coding is a good solution or that a 'one size fits all' approach is adequate. If you have some smart way of solving such configurations issues please enlighten me.
If the situation is complex then the Implementation of the PersistenceWorker will be complex. However the complexity will be shielded from the Screen Developers and can be dealt with by enterprise grade programmers.
What we are trying to avoid is having any dependencies on where or how the data is stored in the screen code. i.e. binding components directly to physical data sources.
However if the situation is simple then you can use an off the shelf PersistenceWorker implementation. For many people, especially where there is no legacy system or old data can be migrated an off the shelf Persistence Worker implementation will work out of the box.
If the situation changes over time just plug in a different PersistenceWorker implementation.
The idea of using a Persistence Interface to abstract away these sort of issues is not new. 'Applying UML and Patterns' by Craig Larman is an excellent reference on this and many other issues. I can't recommend it highly enough as a source of enlightenment..
Oracle have proposed a JSR for "A Standard Data Binding & Data Access Facility for J2EE". Looks like it shares some of the same goals as JDNC. Anyhow the JSR can be found at: http://jcp.org/en/jsr/detail?id=227
Message was edited by: luano
[content of banned user "oracle" (aka Gerald Bauer) removed]
[Edited by: admin]
Oracle == Gerald Bauer?????
> Oracle == Gerald Bauer?????
Yep. Same IP address.
I'm not a big forums guy, but even I have heard of Gerald Bauer's troublemaking. Seems to be an unfortunate mix of smarts and poor taste/lack of common sense. But as some have mentioned, he does make good points sometimes. Too bad he tried to pull a fast one.
> - XML is not a panecea, though many in the space
> treat it as such.
> - OO programming is not for everyone
Preach on. I've seen all types. Unfortunately Java is so wide-open to various styles that I've seen them all in the same office. Ugh. Use of a good framework helps a lot, though, as people start to grok the good stuff over time and quit trying to wade in the shallows or go off the deep end without a way to get back to shore.
> - Many projects simply can't afford the
> cost/time/expertise required to
> design an "architecture" up front - the answer is
> is not to disregard the importance of good
> design, but to leverage existing architecture
> and design (frameworks, templates, components,
> blueprints, etc)
I agree. Some of amount of simplification and standardization is needed to get the "average" programmer off the ground quicker with a robust and easily extensible and configurable application.
> Sadly, many organizations have adopted
> the "thou shalt deliver only browser clients"
> mantra, and these mandates often come at levels
> above the application developers. Our
> intention in JDNC is to provide some rational
> guidelines and "encouragement"
> in choosing the webstart-client route (if only
> "rationality" was enough :-)
The "Thou shalt" certainly happened where I work, and happened in my last job, too. The thorny issues always come up when you need rich controls, "instant" interactivity, or media playback. I think the latest versions of webstart/jnlp are giving developers ammunition to go back to their management and say yeah, applets didn't work out so well (myself and many others have been "burned" by them), but the problems have for the most part been solved and GUI apps can leverage the same code as the web apps. But I do think the webstart isn't the final solution. See my posts in reploy to your weblog (http://weblogs.java.net/pub/wlg/681) for my thoughts on this -- there is an extra mile yet to be traveled.
> The goal of these apis is to significantly
> reduce the amount of OO design and coding required to
> construct common types of clients
That I can use. But I wonder how well it will interface with other APIs and frameworks? Is it compatible with or complementary to JSF? Does it lend itself to or include code generation tools/technology? I've really been into code generation lately, and am finding it to be very useful. With a good framework and robust templating, you can go a long ways toward automatically creating huge chunks of application. I hope JNDC will make code generation simpler.
Sorry - didn't mean to rant or be rude...
Its just your post discussed some problems that I have seen on real projects too. However they were all caused by the projects being run by a consultancy that wanted to bill the client on a headcount basis...
So the memories still make me angry today - as it didn't have to be that way...
The debate about OO/Java vs XML is a really good one and there's
truth in all the points made by Charles, jtr, & ocean.
- XML is not a panecea, though many in the space treat it as such.
(we've spent as much time arguing about the JDNC schema as we
have coding it)
- OO programming is not for everyone - often there's no
worse disaster than someone who thinks he gets OO but really doesn't.
(many programmers in this camp CAN write procedural code, including
Java code, but are not skilled in designing for abstraction)
- Many projects simply can't afford the cost/time/expertise required to
design an "architecture" up front - the answer is not to disregard
the importance of good design, but to leverage existing architecture
and design (frameworks, templates, components, blueprints, etc)
Now, as a general response to many of the good questions raised about
JDNC on this thread...
First, JDNC isn't just about plugging rich components into web pages --
it will also be possible to use these components to build standalone
(webstarted) clients as well. We (Swing) have been preaching for more than 3
years about the evils of shoehorning all UIs into a browser (Dr.Nielsen's
studies also bolster this view). Sadly, many organizations have
adopted the "thou shalt deliver only browser clients" mantra, and these
mandates often come at levels above the application developers. Our
intention in JDNC is to provide some rational guidelines and "encouragement"
in choosing the webstart-client route (if only "rationality" was enough :-)
Second, the JDNC whitepaper highly emphasized the XML configuration,
however that doesn't mean its a black box inside. In fact, we've currently
backed off from the XML schema design to strengthen the programming model
and Java apis that lie underneath. The goal of these apis is to significantly
reduce the amount of OO design and coding required to construct common
types of clients - I like to refer to it as an "automatic" transmission
for Swing. Swing already provides one hell of a manual transmission for
those who need/want it.
So, those who find comfort in the confines of XML will have that. Those
who'd rather just author code can have that. And most will probably use
some of both - XML for declaring the UI structure and data binding,
and Java code for event handling and business logic.
A few questions:
Will JNDC be open source? I'm not saying it should necessarily be open source (in fact, if it's meant to be a usable, well-designed, highly consistent framework it probably shouldn't be open source) but I'm just curious.
What will be the application model for JNDC? One thing that's always struck me is that Swing is, in reality, a very low-level 'widget-centric' API. It's not XLib, but it's also not, say, PowerBuilder. The fact that there is no Application or Form class, for example, is quite striking to some. One thing I've been working on is a higher level 'application-centric' API, Skip, which I plan to open source some day soon. It sounds to me like JNDC will be doing the same thing. Such a high level API won't work for everybody so I'm very curious as to what you consider the common requirements of most Swing apps out there.
Indeed, one of the striking things I've noticed is that many developers, when using Swing for the first few times, just have no idea of where to begin. Just giving them something as simple as an Application class to subclass can be a huge boon.
Lastly, there's the question of patterns and idioms. It sounds like you're working out many in JNDC? One of things that's always bothered me is that few people ever seem to talk about such patterns with Swing. A good many can be gleaned just from Swing itself (things like keep Action classes close--preferrably as inner classes--to the component they work with like the Text components do) but there's still seems to be a distinct lack of consensus concerning such issues as how to handle localization and validation in a medium-to-large app. (Perhaps we can get a board here to discuss issues?)
What I'm suggesting is that the high-level application-centric framework that might come out of JNDC would, by itself, be very valuable. Just giving developers a clear path through the forest in the form of a solid object model, (kind of like a Struts for Swing), can do wonders for productivity--and you don't have to make them write a bunch of XML files.
Ocean - in response to your call for debate about localization and validation...
In our Framework (for release Oct 2003) we have decided on an architecture where there is a Client Side Data Object Layer between the 'widgets' and the back end (whether the back end is a local file system or a remote server etc)...
To connect the Data Object Model to ANY backend you implement one interface PersistenceWorker - so you can have XmlPersistenceWorker, EjbPersistenceWorker etc... so there is no binding required...
In answer to your question about localization and validation every Data Object has its localization and validation information for all its Fields built into the Data Objects. So we can then offer a set of semi-intelligent widgets that extract the localization and validation information from the Data Objects they are displaying and use them for labelling, tool tips and validation ....
If you are still with me you will be thinking - but yes - coding the Data Object layer will be a nightmare....
So we have borrowed a few ideas from A.I. in this and have built an easy to use GUI tool where you define your Concepts and Fields (the 'Ontology') as well as localization and validation information (it really IS easy to use)... from this Ontology the Data Object classes and for the Data Object layer are then generated.... They are TOTALLY orthogonal... so no editing generated code nightmares...
It sounds a lot - but it works beautifully - and the doco will be ready in Oct...
Hope some of that makes some sense...
Very interesting to read ! Just a few small things.
GUI - it is a place where User interacts with a computer system,
and complexity of some interaction sometimes very complicated.
And, certainly, I don't want to maintain the complex interaction by code in XML.
Heh. I chose minivan because they are almost universally berated as ugly, clumsy, slow, passe, etc.. by folks that don't own one. But almost everyone who owns one enjoys their simple utility. It's not a perfect analogy, but I thought it was pretty good. Anyway, enough of the Click-and-Clack automotive talk. :)
I'd second the suggestion that people looking for good tools check out UICompiler.
Donkeys are even slower.
BUT they can walk up mountain paths, eating the grass. No petrol (gas) required..
Donkeys have their uses. And are still used in many places in the world.
Just don't turn up at the next Ferrari analyst conference suggesting they should start selling donkeys...
> I couldn't find ox:swing via google, so I'm not sure
> what to think about it. If you have an Oracle OTN
> acount, I'd suggest you check into UIX as a decent
> XML UI framework. Otherwise, I guess we'll have to
> agree to disagree.
Never used UIX but I'll keep an eye out for it.
> - Complexity. XML makes for simpler, more uniform
> GUIs. Well, I think this is a good thing. The
> framework should wire things up so they work well.
> And by the way, if there is a real usablity need
> d for some complexity, just drop back to Java code
> where you need it.
What I was suggesting is that there's really no such thing
trivial GUI. For most any application there's always that corner case that creeps up which requires you to hack out some real code or create your component. This is just like the old VB/PowerBuilder/AppForge
argument. Sure, it's nice to whip out a "working" product in a day
or two but there will be a significant price to pay. This doesn't
mean it shouldn't be done (read: VB is very, very popular)
but it will be difficult to achieve long term return on the investment
(read: much time is wasted and pain endured rewriting old VB apps). But in my experience, drag and drop (or in this case, an XML descriptor file) is never enough.
Also, I really, really question your willingness to
"just drop back to Java code". You should carefully consider the
implications of spreading logic for a single form between XML files
and Java. For any even medium-sized application I suspect this will
quickly lead to a mess.
> - XML editing. Not sure of the problem. Try Oracle
> JDeveloper for the UIX framework. Sun's NetBeans
> has a decent XML editor. XMLSpy is pretty good.
> Even emacs, although primitive, is bareable.
I've used pretty much all of the XML editors out there and really
they're all painful when you find yourself editing really long files
for hours on end (read: programming). This is probably partly due to the
nature of XML itself but...
> - Validation logic. See JSF or UIX for plugin
> validators. Custom validators are written in Java,
> refered to from XML.
IMO, this is a really misguided statement. I really can't stress this
enough: validation is business logic. In my opinion, this means the only
place to put such logic is in the getters/setters of business domain classes.
Putting validation logic in XML files is, in my experience, and doing it on a per-form basis is just asking for it. Not only will it lead to massive redundancy (how many times do you find yourself saying a customer's name can't be blank?) but it also invites all sorts of inconsistencies and bugs into the application.
> - Reuse. Easier in XML as it is in Java using
> template entities and includes. See UIX or other
> templating engines for details.
This is another very common myth. Templates and includes are not a form of reuse. At best, they're macros. Real reuse can only occur within a well-defined component system using the time-tested principles of OO.
> - Expression Language. If it is a monster, it is a
> friendly one. I don't see the issue here.
Look at many of the JSPs currently out there. Mixing code and XML is again, just another time-bomb waiting to happen. Again, you get the same issues: logic is spread between multiple files and points in the system and it looks a mess and it simply will not scale.
> I think we agree on a central point, that XML
> described UIs don't compare to high quality Java
> code, in code style and UI flexiblity. But then, a
> minivan doesn't compare to a formula one racer, or a
> dump truck, but it gets the job done for lots of
> soccer-parents, it's a lot cheaper, runs on freeways,
> and are easier to get serviced. :)
Actually, the point I was trying to make was that there's really no such thing as 'throw-away' applications. Applications have a way of surviving within organizations for a very long time and during this time growing in unexpected ways. Considering this, it's almost always better to spend a little of time to work out a good design and use POJOs rather than resorting to XML. I'm not really discouraging people from attempting to use XML-based declarative frameworks, I'm just relating my experience.
We're talking past each other. I'd just like to offer a few concrete data points from my experiences. We probably come from very different backgounds. None of these are throwaway projects, all are still around albeit in maintaince mode.
- a very large Motif project, with about 20-30 members. We used UIL for "boring" stuff like dialogs and panels. We dropped back to C/C++ for complex panels. The UIL was generated by both a GUI builder and hand editing.
- C++ project we used the VB-like GUI builder for MSC++. Again, we dropped back to C++ for complex control interactions.
- smaller java project. We developed several custom java components and a small framework of extensible components. It was fun, but most missed the MSC++ GUI builder.
- several medium size java integrated projects without GUI builders, 100+ team members. This was lunacy. It was practically impossible to quickly figure out someone else's GUI code.
- several medium size java integrated projects via XML (no scripting, tiny EL). 100+ team members . XML really helped here, everyone could understand everyone else's UIs. We dropped back to java for complex situations. This fall-back java was less than 1% of the UI. We were able to include and template UI panels for others to reuse. Without the XML framework, we might be still working on this project now! :)
I've also seen, but not directly particpated in, several other UI projects that were sucessful without using a description file. Basically, managment decreeded that developers MUST follow a set of restrictive code conventions isolating the GUI building code to one file. This was enforced with code reviews. Last I heard, they were looking into using XML too.
What does this mean? Put a bunch of "corporate" developers on a project and you'll find half fall below the 50 percentile. The decorator pattern is a mystery to them. Some really aren't all that familar with OO concepts. These folks really benefit from the XML straightjacket. The HIE (aka pixel police) usually aren't all that skilled in Java or OO either. But they can tweak the XML with the best of 'em. Lastly the QA groups aren't all that thrilled about looking at code, but can usually understand XML after some training.
FWIW: Do I use XML for my own code at home? No. At least, not yet. There's still some kernel hacker in me I guess. :)
Where these projects with a hundred people being billed to the client on a per developer basis?
Otherwise fire the 95 that don't know what they are doing - keep the 5 that do. Get a manager who is up to the task of enforcing code conventions and re-use.
You'll build a much better system, much cheaper and much more quickly.
My frustration is at the I.T. industry, not you, but your post is a perfect illustration of an engineering profession which thinks its O.K. to use unskilled labour...
I think everyone should check out:
There is a Java framework that effectively isolates GUI from application, is more object oriented than anything I have seen before, frees from having to declare same things into UI part and business objects.
Those ideas of very high level beans in JDNC comes close to this, but this goes so much further.
Distributed applications comes almost free if you write a standalone application.
And lots of other good feature.
Check out and tell what you think of it!
Does anyone know what happened to JDNC? Is the project still alive? Any news?
If I may quote all the promises from Sun's JDNC whitepaper:
[i]When it comes to understanding the challenges inherent in building real world applications, no one is more knowledgeable than the application developer himself. In order for a technology like Java Desktop Network Components to succeed, it will need to be nurtured and shaped by a community that includes those who use it to produce world-class Java desktop clients. The timely arrival of the new community Web site, javadesktop.org, provides just the place to host the evolution of this project under an Open Source development model.
Currently a team at Sun that includes Swing engineers and some outside application developers is busy building an early access version of the JDNC technology. [b]Once we reach this early access milestone (targeted for Fall 03) we'll roll it out as an Open Source project hosted on javadesktop.org.[/b] From there we'll look to the Java desktop development community for contributions aimed at improving the design and implementation. The details are still being worked out, so please visit the javadesktop.org Web site in the future for updates on the status of this project.[/i]
I have been wondering the same, could someone in Sun give some direction of the future and state of JDNC?
I wondered the same thing, so I contacted the author a couple of months ago. She said that the project had been delayed, but that they were looking at around a spring 2004 release date.
Definetly take this with a grain of salt, as this info is only second hand. I think the point though is that they're working on JDNC and want to get it out as soon as it's possible. I'm guessing they're particularly interested in making it as stable as possible before releasing.
Hope this helps.
> Zander - you are busted...
Oh oh...but maybe not... :)
> Just found this:
> If you are going to plug a product (especially with
> claims that fly in the face of common sense) please
> have the courtesy to declare your involvement in it...
I beleive zander declared his involvment earlier in this thread. See these quotes from his post:
"Let me explain my history in this;
I have been creating a XUI equivalent application..."
"UICompiler has been refactored last month..."
"More readables at http://uic.sf.net"
OK Zander - I owe you an apology..
You had stated your involvement...
Maybe to save people having to read all 70 of your posts to find out where you are coming from you could declare your role in UICompiler in your profile..
Zander - you are busted...
Just found this:
If you are going to plug a product (especially with claims that fly in the face of common sense) please have the courtesy to declare your involvement in it...
> Zander - you are busted...
In my opinion; when you use an open source application (or framework etc) a lot then you are automatically a member of that community; I did not feel I hide anything from you.
>> It just seems your environment for this stuff is immature as all your points can be fixed in software.
> Object Orientation is semantically richer than XML.
So, yes I wrote an environment that brings UI editing to a different level and that allows a graphical editor to be de-coupled from the code. Why should that take away my right to comment on the issues? Since I have obvious experience with the subject, I would expect the opposite reaction!
You seem to be saying that I have to use sand and dirt to build houses; and I claim to have given the world an CAD application that can build a house using bricks. Or dirt or whatever you want.
While you might have a little more tuning for the end-result, I have been working in creating an industrial building machine that creates quite the same, but very professional houses.
Hope you understand my sometimes too general statements :)
I was guessing that this would come up. Using XML can actually make reuse easier!
You can do things like:
- define a common XML tree in one file and reference it in several places
- create a templating mechanism where one element "extends" another to provide new functionality
- define new XML elements (a la custom JSP tags)
couple with advantages I mentioned earlier (code seperation, rigid definition, tool friendlyness, its declarative nature) XML described UIs can be quite powerful. There are good examples of this, the one I'm best familar with is Oracle's UIX.
re: resource bundles -- your resource bundle just needs to be referenced from the XML (something like the JSP/JSF expression language)
re: OO is richer than XML -- basically true, but in practice it is rare that OO is /required/ to get the job done, and the XML is usually simpler.
FWIW: I'm annoyed as the next person at XML cropping up in places it isn't well suited.
Oh, and I have yet to find what I consider a great XML framework for Swing, but I'm still looking.
Speaking as someone who's stitched together his own Swing XML framework (ox:swing), let me just state my experiences having travelled down that road.
- Messy. Editing XML sucks. The tools aren't there and won't be there for quite some time. When you begin putting large chunks of your code (forms, dialogs, etc) in XML you end up with a mess of XML files and Java files which have all sorts of wierd interrelationships(eg. change the name of the textfield in this XML file means change the code in that Java file). It's a big tightly-coupled mess and you won't like it for any significantly complex application.
- Declarative vs Imperative. In the beginning, the notion of a declarative swing framework seems very, very tempting. You can capture all sorts of information declaratively that looks much messier in Java. Not just layout but things like validation (eg this textfield can't be empty), things like localalization (eg this label's text comes from this entry in that resource bundle), customization, the list goes on and on. At first you don't feel bad because you tell yourself that all of this is "orthogonal" logic--that is it doesn't really have anything to do with the _functionality_ of your application.
It's a lie.
Validation logic is business logic. Putting it an external XML files (what a lot of web frameworks eg Struts, Webwork2 do) is suicide. Localization and customization aren't really declarative. The thing about XML languages (in fact, the thing about all declarative languages from xpath to SQL to XUL) is that it's just never enough. It becomes a slippery slope. First you add the notion of variables so you can refer to different components. Then you add an include syntax. Next comes the expression language. Finally you get a scripting languages and before you know it, (at least before I knew it), you've created a monster.
- Reuse. Ultimately, it all comes down to reuse. You might think there's no place for reuse in GUIs but Swing's very existence should demonstrate how wrong a notion that is. Reuse in complex guis is paramount. With a bit of forethought (ok, with a lot of forethought) it's really possible to do things like form inheritance and create highly reusable components. It's hard, but it's very doable. No XML framework (which all tend be inherently page-based reformulations of html) will be able to capture the power and expressiveness of a well-thought out component framework. It's just that simple.
Personally, I have nothing against JDNC because I suspect it's actually targeted towards all the newly-arriving Visual Basic programmers who're used to whipping up presentable applications that don't do much besides churn data. (Though I suspect a lot of people who invest in JDNC will end up like people who invested in VB: they'll end up paying more in the long term when they need to rewrite the app using a 'real' framework but this time with Swing instead of MFC). But for people building non-trivial desktop apps I strongly recommend sticking with plain old java objects.
> re: reuse
> I was guessing that this would come up. Using XML
> can actually make reuse easier!
> You can do things like:
> - define a common XML tree in one file and reference
> it in several places
> - create a templating mechanism where one element
> "extends" another to provide new functionality
> - define new XML elements (a la custom JSP tags)
> couple with advantages I mentioned earlier (code
> seperation, rigid definition, tool friendlyness, its
> declarative nature) XML described UIs can be quite
> powerful. There are good examples of this, the one
> I'm best familar with is Oracle's UIX.
> re: resource bundles -- your resource bundle just
> needs to be referenced from the XML (something like
> the JSP/JSF expression language)
> re: OO is richer than XML -- basically true, but in
> practice it is rare that OO is /required/ to get the
> job done, and the XML is usually simpler.
> FWIW: I'm annoyed as the next person at XML cropping
> up in places it isn't well suited.
> Oh, and I have yet to find what I consider a great
> XML framework for Swing, but I'm still looking.
I couldn't find ox:swing via google, so I'm not sure what to think about it. If you have an Oracle OTN acount, I'd suggest you check into UIX as a decent XML UI framework. Otherwise, I guess we'll have to agree to disagree.
- Complexity. XML makes for simpler, more uniform GUIs. Well, I think this is a good thing. The framework should wire things up so they work well. And by the way, if there is a real usablity need for some complexity, just drop back to Java code where you need it.
- XML editing. Not sure of the problem. Try Oracle JDeveloper for the UIX framework. Sun's NetBeans has a decent XML editor. XMLSpy is pretty good. Even emacs, although primitive, is bareable.
- Validation logic. See JSF or UIX for plugin validators. Custom validators are written in Java, refered to from XML.
- Reuse. Easier in XML as it is in Java using template entities and includes. See UIX or other templating engines for details.
- Expression Language. If it is a monster, it is a friendly one. I don't see the issue here.
I think we agree on a central point, that XML described UIs don't compare to high quality Java code, in code style and UI flexiblity. But then, a minivan doesn't compare to a formula one racer, or a dump truck, but it gets the job done for lots of soccer-parents, it's a lot cheaper, runs on freeways, and are easier to get serviced. :)
they all sound so advanced
so XML just has this ring to it - and people can put an X in their project names that use it to make them sound advanced too..
Problem is though - XML is a donkey of a programming language... not a mini-van
Isn't Qt proving with QtDesigner that this can very well work. XML is a very to output (for Java JDom rules ;) )
I thought that a whole bunch of applications in KDE are developed using QtDesigner and I have no complaints using there applications so far.
The problem might be in finding a good editor.
An other advantage of using an intermediate structure is being able to use new featers (for example mnemonics in tabbed pane, table sorter Sun in planning to add) after regenerating your code... Instead of changing it.
In my opinion that is far more "developer friendly"
Reuse is great, but how many times do you need to code a reusable dialog or form layout for instance? What if you need to support different formats/layouts of such forms? How much of the reuse is in the layout?
What's to stop reuse of XML? In many cases XML is manipulated with Java so there are plenty of opportunities for bringing the power of Java to bear on the XML UI description.
If the XML description were monolithic then you would probably end up with alot of repetition but the XML can consist of multiple (single purpose) files so there should be little need to repeat declarations.
Actually Messages in Dialogs I re-use an awful lot. The reason is Localization. You don't want to translate in 30 languages more than once - so ResourceBundles are a Godsend...
If you are going to combine XML and Java and have lots of XML files then you might as well use Java. How is an XML stylesheet simpler than a LookAndFeelManager.java class that lets you get and set the relevant properties, and you get compile time checking.
My point is for simple applications for Inexperienced Developers XML is helpful, but for industrial strength applications it should be avoided.
> My point is for simple applications for Inexperienced
> Developers XML is helpful, but for industrial
> strength applications it should be avoided.
It just seems your environment for this stuff is immature as all your points can be fixed in software. Remember that an xml can easily be used to visually represent in an application in different formats; this is a lot harder then with java source code.
That said; I have build industrial strength applications using the uicompiler, including localisation etc.
The tools make the job easy; but the brain ultimately defines the success of the job.
Reply to Zander - read his post to understand the tone of this one...
Object Orientation is semantically richer than XML.
You can do anything in Java that you can do in XML but not
Surely that's obvious? Ultimately its the brain that can comprehend the concepts.
Databinding - I think you need to tackle some of the hard-problems when doing this stuff, like lazy fetching and sortability of lazy sets, object flattening adapters and drill through for object hierarchies. e.g. I have a Stock object and I want to see a synopsis of that Stock - Name, Ticker, Price, Currency. Currency is an object - so I want to be able to specify Name as the displayed field. This field would be either a 'hyperlink' allowing me to drill into Currency, or perhaps could use a treetable to expand on the Currency detail.
I guess some kind of JMS mechanism (drop in play) would be good to provide eventing to the front end.
The JDNC is a great idea - and perhaps what Swing should have been in the first place - emphasis on componentised UI building, support for out-of-the-box UI paradigms etc - get this right and it will turn Java into a tool with the ease of use Visual Basic.
Perhaps you should consider Karsten Lentzsch's high-level components for some of this JNDC stuff - always very impressive.
[b]> If the swing team does not reply here (Lets see if
> they read this forum : )[/b]
Not just the swing team but all of the J2SE client side development teams will be reading the forum on javadesktop.org. They are part of the community though the most important contributors are you the external developers.
> I noticed with interest at the mention of TreeTable.
> I have found this to be a _very_ useful component and
> I'm wondering if this is going to be included in
> Would anyone be able to comment?
> P.S. I've found 2 bugs in Sun's external JTreeTable
> component (Scott Violet) found here:
> and have a small fix for one. Since the article has
> no feedback address I'm not sure where to send it.
If the swing team does not reply here (Lets see if they read this forum : ) then I suggest firstname.lastname@example.org, I'm sure Scott reads that.
> If the swing team does not reply here (Lets see if
> they read this forum : )
Yep, we're reading it. :)
> then I suggest
> email@example.com, I'm sure Scott reads that.
Yes, we all read that too. :)
I'd also like to say that I think the Christina marketing e.g.
"the point of Java is you can find out what she is wearing"
is degrading both to women and Java.
However that was absolutely no excuse for causing offence to a talented engineer.
OK Gerard so you are a twerp for the inappropriate humour...
However I have just looked at your http://xul.sourceforge.net and it is a good site.
So I'd just like to recommend that people visit it rather than be put off by the author's misdemenours...
> Gerard, if you are unable to refrain from the
> rude/sexist comments, I'm going to ask you to not
> post here.
I second Jeff's comments.
While you can't edit an email you certainly didn't have to make reference to it. You're comments could have been reposted to this forum without the sexual overtones.
As for Amy, she's one of the best engineers I've ever worked for and with. Easily in my top 5. Her technical expertise has been recognized both inside and outside of Sun.
She's a great mentor and role model as well. Four years ago she spent over an hour with my daughter talking about engineering. They covered all kinds of topic from doing what "you" want to do to balancing family and work. She had more of an effect in one hour than I could have had in weeks.
As the the community manager I encourage a difference of opinion. But there will be little toleration of posts with inappropriate comments.
JavaDesktop Community Manager
> As for Amy, she's one of the best engineers I've ever
> worked for and with. Easily in my top 5. Her technical
> expertise has been recognized both inside and outside of
Ok. Let's get the "Amy affair" behind us and let's get down to business.
Why is Sun reinventing the wheel, the toothbrush and the alphabet with the new Java Desktop Network Components (JDNC) initiative? Using XML for creating UIs is hardly a novel idea. Why not work with the community?
There are more than a dozen free, open-source projects. I'm sure Sun hasn't approached anyone. I try to keep track of them all at the XUL alliance site @ http://xul.sourceforge.net
Any comments about JellySwing, Swix, Luxor, XWT, XUI, Thinlet and so on?
Yes, Gerald, let's get down to business. I might suggest in the future that if you start out with just an ounce of professionalism and hit us up with solid prose on technical and community issues, you'll find we'd be happy to engage in discussion. For the moment, I plan to engage with Luan O'Carroll, who sent us a very reasonable suggestion to take a look at XUI for synergistic possibilities with JDNC.
Just to let you know that I tried to crack some jokes in the XUL News Wire story write-up inspired by Sun's new Christina marketing theme. See http://www.bignoisenow.com/christina/christinamotorola for an example. Please, don't take it serious.
I do not want to belittle Amy's outstanding achievements and question her qualities as an excellent and capable engineer of the highest caliber.
Also if it's any comfort I dish out bad jokes regularly. I know I'm not Jay Leno, but anyway. What is life without humor? Someone has to try.
To help you see the post in a different light, you might wonna check out my two weglogs entitled "The Saturn Times" @ http://vamphq.com/times and "The Richmond Post" @ http://xul.sourceforge.net/post
Again, I apologize for sterotyping blonds.
PS: I'm sorry to tell you that I can't remove the offending parts from the story as the mail archives are out of my control. For balance I will use a "Size Matters - Micro Willy" theme for my next story. Just kidding ;-)
Yup A v H did the BorderLayout
Phil did a lot of the JTable design.
Hi Amy, You're quite right. The absolute positioning was used as a quick and easy way of getting started and we haven't really had a chance to consider integration of layout managers in detail but we suspect that the nesting of components in panels or containers combined with some hints could be used to enable use of layout managers. We originally set out to develop for handheld applications and to cleanup some of the code spewed out by IDEs so layout managers were not top priority. We are also considering how to compose applications with static elements such as toolbars, navigation controls, sidebars etc with more dynamic content, sort of like framesets in html and this will probably have some impact on our use of layout managers. I for one would be delighted if JDNC can achieve the hiding of layout complexity that you suggest.
We tried to avoid creating high level components or a widget library as we didn't think we would be able to either maintain such a library or provide a wide enough range of components so instead we tried to provide features that could be applied to any component. Therefore we chose to use adapters to integrate components with the data binding.
In XUI there is a single startup file that directs the application to xml files for things like styles, static data, validation rules and so on, each with a single purpose. We separated the style information so as to be able to change the look application wide and to help enforce common styles across an application. The validations are also held separately so that they can be applied across pages/screens/views and perhaps even across projects (for example a validation might specify limits for a physical value such as temperature). The validations can be tied into the data binding mechanism by the xpath style naming convention. The data is described in another XML file or files (for static data, databases, web services etc). All the xml files use a similar structure and can be mapped using the xpath style notation.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.