Skip to main content

JDNC: Introducing Java Desktop Network Components, by Amy Fowler

80 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jtr
Offline
Joined: 2003-06-10

There are XML Swing gui builders projects around which incorporate layout managers. I just stumbled across:

http://jgb.sourceforge.net/documentation/tutorials/simplewindow/index.php

which still looks pretty raw, but does include layout managers. I don't know what the relation is to XUI though.

luano
Offline
Joined: 2003-06-12

Layout manager support will be introduced in the next release of XUI, an outline of this can be found at http://xui.sourceforge.net/docs/layouts.html and the corresponding code will be available shortly.

zander
Offline
Joined: 2003-06-13

Hi, sorry for falling into this discussion but I would like to share some thoughts..

> I did note that the XUI API encourages the use of
> absolute positioning,

I must honestly say that this is news to me, which is remarkable since I have been looking at working with XUI for a long time; it seems XUI could have 'learned' from me as I have been trying to learn from them :)

Let me explain my history in this;
I have been creating a XUI equivalent application that does not use a made-up xml file, but one from Qt Designer.
The application creates the GUI and fills it with values (if provided). Reading this you might get away with the idea that this is just a GUi bulder and thats it, but that would be missing the bigger picture.
UICompiler has been refactored last month to not only write java code from that XML, but also to instanciate the code directly on screen. With filled JLists and textfields and all.

As the instanciator and other extras are still in alpha (the rest is at 1.1 though) I'm not one to plan features ahead too much, but it has the potential to nicely fit the needed functionality into the project without problems.

So to make the circle round: It is my believe that the product Amy wrote about has merrit. The main problem is that it does not fit with Swing very well currently, mostly due to missing or imature components. (table sorter is a good example)
This basic layer is what the team is working on currently, while at the same time creating a design that allows the ideas from the paper to happen on top of that.

More readables at http://uic.sf.net

luano
Offline
Joined: 2003-06-12

Zander, I think you may have picked up XUI incorrectly. The XUI referred to was the project at http://xui.sourceforge.net, but correct me if I'm wrong.

pascal
Offline
Joined: 2004-03-12

Hi,
I need a little bit help. I want to you use the JDNC....but I have problems. I configured a tomcat apache server 4.1.30 and had test the Amy Fowler-Demos, but now I want to run the demos on my own pc in the network. I mean that I changed the URL's in the jnlp-files to my own host and I download the jar-Files, the jnlp_runtime.jnlp, demo01.jnlp and the demo01.jdnc-file and the BugSourceTable! All these files are in one directory. And actually if I make a change in the source code the browser load the original table without my changes! Is it the jdnc-file with the source?....have anyone an idea ??

I have to evaluate JDNC to the now working IntranetApplications and I'm a beginner of a programmer.
Thanks - Pascal

Anonymous

Members of the SwingTeam,

I am the developer of JForm, a Swing component for handling form-based user data.
JForm is hosted here at java.net (jform.dev.java.net).

I wonder if JForm could make it as a JNDC component?

Hope to hear from you,

Will

If you like to discuss this with me off the forum you can contact me directly at will@coderight.nl

bobsledbob
Offline
Joined: 2005-03-25

I just stumbled across the JDNC Intro article, and I must say I'm extremely excited. I'm trying to get an understanding of the timeline for this project. I'm in the very beginning stages of a project that could greatly benefit from JDNC and would like to hold off on the project if the JDNC preview release is going to be available soon. I think the article mentioned Fall 2003.

And, just to chime in, having the JDNC components data be in XML format is essential for me. I'm planning on using XML-RPC.

Thanks in advance.

Adam

kishore
Offline
Joined: 2003-06-23

Hi there,

I am thinking of a solution of removing the headache in changing an Applet which is made with JDNC to Application(ex:webStart based).

Imagine this scenario, where a webDeveloper(a user who dont know any JAVA stuff), made an Applet using JDNC, embedded it into my HTML tags. did all XML stuff.
now if he wants to make it as an Application also(to run with JAvaWebStart),
he need to write some java code, to put it in a JFrame, change Size,Location to make it of exact size of Applet etc. All these things need some knowledge of JAva.

I think even this level of coding and modifications can be avoided with a small new Component.
If there is a component(may be subclass of HTMLEDitorPane),
which will reads all the needed parameters (like size,locations) from the same HTML file which consists of the Applet and embed's it in a JFrame, it will be more easy.
{ All this without writing any JAva code }
This will be very handy,especially for the web Developers who dont know java.

And

If JNDC can really provide the easiness it is promising, I think JNDC will be a major success.
I am not looking at JNDC as another new API, its a great concept which allows
the non-JAvaprogrmmers to easily develop rich UI's for web and desktop.

Kishore.

fudster
Offline
Joined: 2004-05-06

Message removed by admin due to user being banned and posting cursing messages

davetron5000
Offline
Joined: 2003-06-10

Did anyone else notice that the article and the technology proposed doesn't really address the thesis touched on by Neilsen's quote and the article conclusion? That web apps are the Wrong Solution and that sometimes a first-class app is needed?

We don't need yet another way to do something in XML that is more easily done in Java. We don't need yet another way to dumb down something that is really not that complicated. We don't need yet another thing for developers to learn instead of just learning Java. What we [b]do[/b] need is some cross-pollentation of the Swing/JavaClient folks and J2EE. Swing + EJB + WebStart can crush any stupid VB app into oblivion.

The statement that most apps are web apps is just not the case. Most line-of-business apps are written in VB, Powerbuilder or some other equivalent language, and you end up with no re-usability across the enterprise.

That is what J2EE promises. With J2EE you can write your business logic in EJBs, provide a [b]real[/b] data entry interface to the users in Swing (find me a hardcore data entry clerk who will tolerate a web interface), and provide a web-based view of the same functionality to public internet users.

Right now, business users are subjected to legacy VT100 or Powerbuilder apps that are not maintained well, due to deployment costs, or horrible, horrible web interfaces that are too slow and waste network bandwidth.

The answer to Neilsen's charge is not ANOTHER xml-fest, but some smart application of existing technologies. You know, if code doesn't have angle brackets in it, it's OK. IT managers [i]might[/i] buy off on something if it doesn't involve XML.

jtr
Offline
Joined: 2003-06-10

> if code doesn't have angle brackets in it, it's OK

Heh. I feel that way sometimes as well.

But in defense of the JNDC, XUI, etc... XML-based solutions are declarative, which typically means two things:

- the XML is easier to read, making creating, editing, and understand the UI easier
- seperation of UI and backend models is enforced

Many people reading this board won't see the problems here because they can read and understand Java as well as XML. But others (read VB developers and lazy people like myself) appreciate the XML straightjacket. Because the description is generally more rigid than Java code, anyone can eyeball the XML file and see what the UI should look like, regardless of who wrote it. Tools can proccess it more easily, etc... The idea isn't new. Motif had something like this (UIL) back in the early 90's. Unfortunately, UIL was pretty slow.

If you're an architectual purist, you'll like that creating the UI in XML forces people not to write model code directly in the UI. :)

OTOH, I'm for /anything/ that will make it easier and quicker to write good looking apps. (See the discussion on UICompiler in http://javadesktop.org/forums/thread.jspa?threadID=82&tstart=0). zander makes the point that it should be easier to create nice looking apps and lists some of the things he's done to Swing widgets to make them GUI-builder friendly. Perhaps some of those changes will be folded into Swing as a result of JDNC.

charles.armstrong
Offline
Joined: 2006-02-17

But the whole fun of code is that you can re-use bits of it by calling it from other pieces. How do you call a piece of XML? So my instinct is that in any complex application you are going to end up repeating yourself unnecessarily - whether that repetition involves data, validation, localization, persistence, look and feel or whatever if you use XML ...

I accept that some people find XML easier and that is good if the whole world is to start using Swing. So it is an easy path into the Java world, rather than the best solution.

valcas
Offline
Joined: 2003-06-20

the last few postings are debating the value of using XML to describe components but really it's only worth what you think you can get out of it. If you don't like using XML then don't use it. But it's probably worth pointing out that the XUI project has many labour saving features which do not require you to describe any screens, components or logic in XML. The factories, data binding and event handling are good examples and the stylesheets help you to achieve your L&F with the minimum of fuss (although the stylesheets do use an XML format). The point is that it's not using XML for XMLs sake.

In addition, if you do decide to use XML to describe components, you can still use the Java classes to handle logic or navigation. A good example can be seen at http://xui.sourceforge.net/XMLEvents.html

Personally I like being able to remove all of the trivial stuff from the code and leave the 'real' code which is doing the useful work. But, that the choice is yours.

I should probably point out that I'm a developer on the XUI project.

davetron5000
Offline
Joined: 2003-06-10

I think the gist of my argument is that I see no need to describe these things in XML. Abstraction can be achieved in Java. Java is a skill needed by anyone building such a system as we are discussing, so what is the benefit of learning an additional syntax? Wouldn't it make more sense to discuss good ways of abstracting things and implementing them in Java? It only helps the targetting "inexperienced Java programmers" become better, rather than learning some much-less-prolific-and-useful XML mumbo jumbo.

I think that a lot of proposals in the Java world tend to be motivated by the following things:

- Use XML
- Be more Object Oriented
- Abstract things
- MOre strict adherence to Model-View-Controller (MVC)

And I think that a lot of engnineers and architects lose sight of WHY XML, OO, Abstract and MVC exist: To make the job of programming and maintaining code simpler. There is this assumption that any application of OO (e.g.) instantly makes something simpler. That is not the case. The current trend is to take simple concepts and add XML to them to make them "more abstracted" and therefore (allegedly) simpler, but that is not the case.

Look at properties files. Very simple. easy to read and easy to understand. But, now they are passe and are going away in favor of xml descriptors. Tell me what is easier to maintain and read:

[code]
com.foobar.okLabel=OK
com.foobar.cancelLabel=Cancel
[/code]

or

[code]






[/code]

Anyone who thinks XML is more readable than [b]code[/b] should have their head examined. XML is for data-interchange, not programming! It's debatable as a configuration file format.

This is not even to mention the training needed to get a regular Java programmer to understand some mickey-mouse XML language and syntax.

Please, OO, MVC, AOP, XML are not ends in and of themselves. They are means to certain ends. They are not always approriate, and their use doesn't always guaranteed that code quality increases.

zander
Offline
Joined: 2003-06-13

> I think the gist of my argument is that I see no need
> to describe these things in XML. Abstraction can be
> achieved in Java. Java is a skill needed by anyone
> building such a system as we are discussing, so what
> is the benefit of learning an additional syntax?

Usability experts, or graphics designers in general don't normally code java, they can fix things without a coder at hand using a GUI builder. A GUI builder can not run on top of your modified code; and it can work using XML. (but I am repeating myself)

> Please, OO, MVC, AOP, XML are not ends in and of
> themselves. They are means to certain ends. They
> are not always approriate, and their use doesn't
> always guaranteed that code quality increases.

Nobody said that; but many people feel different about the case at hand. I have posed many points, as have others, that say many problems we found are solved using the solutions you dont see are needed.
I get the feeling you have not read the entire thread; since you fail to do more then give your opionion in a "I think thats obvious" kind of matter.

As your properties verses xml example; maybe you should see a euro, or a � or even a chinese character in there and find out what that does to your example.

jtr
Offline
Joined: 2003-06-10

Great Idea

Like a good many web developers, I use XML (with something like XSLT) daily to create front ends. I've also had occasion to write the same code with JSPs or directly using APIs (this is somewhat akin to writing to the Swing APIs). XML is a huge timesaver in getting the GUI running. A GUI builder like the couple demoed at JavaOne is even better.

But the devil is in the details. The JDNC article looks good, but I'd like to know about how the backend access occurs (is it only JDBC or can you build your own?). Can I create my own local datasource and access it directly with Java code (maybe something like the EL used in JSP 2.0 or JSF)?

Speaking of JSF, the backend validation, converters, and framework could be very useful for JDNC apps as well. Hopefully that can be leveraged... Swing apps could be much simpler for the "corporate developer" to build if a framework were in place for them.

Anonymous

The devil is definitely in the details, and this is particularly true when it comes to the data-access part of these components. We're currently experiementing with a variety of common datasource/format scenarios (jdbc via web-tier servlet, JDBC web rowsets (jsr114), more generic web service requests & xml data, etc). Obviously this must be one of the most pluggable aspects of these components because we'll never be able to accommodate the idiosyncratic data needs of many applications.
I'm curious what particular data sources/formats you'd be interested in seeing support for?
We are definitely looking at the JSF/JSP EL as a possibility for expressing the UI binding for the data. We are also looking at building some JSF renderers that deploy these components rather than plain HTML, so in theory JDNC could be used directly with JSF (my history on the JSF project definitely comes in handy here :-).

jtr
Offline
Joined: 2003-06-10

Well, I believe the most popular, and perhaps easiest target will be JDBC-style datasources, so it makes sense to focus on that.

But a decent amount of the stuff /I/ need to display is pulled from a non-database, or if it does come directly from a database, it has to be modified/augmented/formatted before it can be displayed. Formatting is the usual stuff: making sure data is formatted for the client's locale, converting dollars to euros, etc... Augmenting is pulling several related pieces of data together to make one table row, perhaps showing prices and current exchange rates, which come from different sources. Modifying can be as simple as applying an exchange rate. The point is that I'd like some backend control instead of directly fetching from a database.

I suppose a web service with XML transport could supply this pretty well for a J2EE app. But, would a local-only client do for a binding (for instance, a Solaris /var/adm/messages viewer)? Or, maybe the local-only client isn't a target for JDNC?

mswanson
Offline
Joined: 2006-02-17

Hello,

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 1.5.
Would anyone be able to comment?

P.S. I've found 2 bugs in Sun's external JTreeTable component (Scott Violet) found here:
http://java.sun.com/products/jfc/tsc/articles/bookmarks/
and have a small fix for one. Since the article has no feedback address I'm not sure where to send it.

jeff
Offline
Joined: 2003-06-10

Hi Mark,

TreeTable didn't make it into the final cut for 1.5, but it is being actively worked on, and might go out on java.net first.

You can send the bugs and suggested fixes to: swing-feedback@java.sun.com

thanks!

jeff

charles.armstrong
Offline
Joined: 2006-02-17

Has it been decided how the deployment will work, and how these components can be integrated with a standard swing application. i.e. will you have a serialized bean to integrate or a Java class or some other deliverable for JDNC Components?

gerald_bauer
Offline
Joined: 2006-02-17

Hi,

I have written up a story about Amy's article titled "Sun XUL White Paper Online".

Read the full story @ http://sourceforge.net/mailarchive/forum.php?thread_id=2558219&forum_id=...

- Gerald

PS: To find out more about XUL (XML UI Language), check out the XUL Alliance site @ http://xul.sourceforge.net sporting more than a dozen free, open-source XUL motors/browser/runtimes for Java such as XWT, Luxor, Swix, Thinlet, JellySWT, and many more.

jeff
Offline
Joined: 2003-06-10

Gerard, if you are unable to refrain from the rude/sexist comments, I'm going to ask you to not post here.

gerald_bauer
Offline
Joined: 2006-02-17

Hi Jeff,

> Gerard, if you are unable to refrain from the
> rude/sexist comments, I'm going to ask you to not post
> here.

Sorry if anyone feels offended by my XUL News Wire story. I apologize. I got carried away with Sun's new Christina marketing theme that you can check out @ http://java.com/en/explore/mobile/christina.jsp

- Gerald

augusto
Offline
Joined: 2003-06-11

What does Christina Aguilera have to do with Amy Fowler?

Amy is not a "promotional theme/face", she's an engineer that's being doing cool Java Swing stuff for a while.

Be a bit more respectful, and instead of adding a footnote to your "article", edit it properly, it sounds very disrespecful.

luano
Offline
Joined: 2003-06-12

I read your article with interest. The XUI project (http://xui.sourceforge.net) is an open source project with some similiarities to JDNC. It has many of the same goals and some additional features. It may be of some interest.

Anonymous

Hi Luan - I confess I was not familiar with XUI, so I just spent some time browsing your site and documentation. JDNC does seem to share some of the same highlevel goals as XUI, although each is taking a slightly different approach - yours uses API factories and such to insulate the developer from some of the GUI plumbing while JDNC is focussing on generally higher level components with high degrees of built-in UI functionality (sorting, printing, filtering, etc).

I am intrigued by XUI's data model architecture, which uses the slash notation to declare flexible UI binding. JDNC is taking a similar approach, although we have yet to settle on the syntax. Currently we're thinking of leveraging the expression language syntax defined by JSP (and also leveraged by JSF), but certainly a more XPath-like notation would also work well.

One thing I couldn't get from the XUI documentation was a picture of the overall anatomy of a complete XUI client - in particular how the various bits and pieces of the application are supplied (single xml config file? multiple files? client-code? etc).

I did note that the XUI API encourages the use of absolute positioning, which is something JDNC could not get away with (given all our espousing on the importance of layout managers :-). I realize layout managers are beyond what many developers want to deal with, but we're looking at providing a higher-level approach which requires no knowledge of layout managers, but takes advantage of them under the covers to ensure solid cross-platform layout semantics.

dglasser
Offline
Joined: 2003-06-13

> I realize layout
> managers are beyond what many developers want to deal
> with,

Yeah, and that's a shame, too. When I came to Java from the VB world, layout managers were an epiphany of sorts for me. It was around that time that I first read _Design Patterns_, too, so the light bulb flicked on for me in a big way.

I remember how cumbersome it was in VB to write code to trap every little screen-resize event and do all kinds of calculations to re-layout the screen. Most programmers I worked with (in an enterprise client-server environment) just let the controls stay in one place and get clipped when the screen got smaller, or stay all bunched together when it got bigger. The next time you talk to the guy who wrote BorderLayout (I think it was Philip Miline -- I looked in the code), tell him my hat's off to him.

WRT your article, though, you've basically summarized many of the thoughts I've had for quite a while, specifically, that the browser is way overhyped as an actual platform for enterprise applications. I think many of the browser-based apps that have been written for various enterprises--when there was no compelling need for a browser-based interface--are not going to stand the test of time, and will be replaced with old-fashioned GUIs within a few years. (In fact, I've already seen that happen in a few instances.)

jeff
Offline
Joined: 2003-06-10

> The next time you talk to the guy who wrote
> BorderLayout (I think it was Philip Miline -- I
> looked in the code), tell him my hat's off to him.

Without looking, I'm pretty sure that Arthur Van Hoff wrote it - a quick port from the original NeWS [url=http://www.javadesktop.org/misc/borderbag.txt]BorderBag[/url] layout manager.

jeff

dglasser
Offline
Joined: 2003-06-13

> Without looking, I'm pretty sure that Arthur Van Hoff
> wrote it

Oops, you're right. (Sorry Arthur, props to you!)