Skip to main content

JNDC and RIA

4 replies [Last post]
adriancuthbert
Offline
Joined: 2004-04-30
Points: 0

It seems impossible to find out whether JDNC (JDesktop Network Components) are really designed to contribute to the development of RIA or not. When used in a web-page, JNDC are essentially applets but they can be configured with the same XML configuration files as their desktop equivalents. Futhermore the components, because they are 'network' aware, can fetch their data from the originating web-site. Thus they have precisely the characteristics to make them a valuable component on a web-page.

But the documentation seems only too keen to point out the problems with using them on web-pages (variable Java support, longer load times, the need to reload after a page refresh). JDNC demos are all WebStart based and nobody is saying anything about scripting JDNC or allowing them to interact with other page content, be it HTML content accessible through the DOM or a Flash component. While it might be possible to drive JDNC components with Javascript (just because it can already speak to applets) the real question is whether they are designed to be scripted. For example can Javascript be used to scroll a JDNC 'table' component to a selected row or, more revealingly, can a row selection in a JDNC 'table' component trigger some Javascript?

With JDNC and JDIC Sun is obviously making a renewed effort on the desktop. But from the 'vision thing' point of view the most significant thing would seem to be Java WebStart. This brings many, if not virtually all, of the deployment advantages of pure web applications to the desktop. Whereas initiatives like JDNC and JDIC are [just] new tools for building conventional desktop applications in Java, albeit far more productively. But web deployable, desktop applications are not RIA. Where is the 'vision thing' for Java and RIA? It would have to be something that acknowledges the existence and importance of the web-browser as a primary tool of user interaction. With the web-browser comes a set of expectations related to choices and technology and the ability to combine them. If JDNC is part of a Java/RIA vision then it has to acknowledge that Java-based components, no matter how functional and how rich they are, are just that; components to be mixed and matched with any other Internet capable component.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mark Davidson

Hi Adrian,

Thanks for your insightful comments.

On 06/27/2004 12:06 PM, jdnc-interest@javadesktop.org wrote:
> It seems impossible to find out whether JDNC (JDesktop Network
> Components) are really designed to contribute to the development of
> RIA or not.

RIA == "Rich Internet Applications". I'm was not aware of the term.

> While it might be
> possible to drive JDNC components with Javascript (just because it
> can already speak to applets) the real question is whether they are
> [i]designed[/i] to be scripted.

We didn't design them to be scripted.

> For example can Javascript be used to
> scroll a JDNC 'table' component to a selected row or, more
> revealingly, can a row selection in a JDNC 'table' component trigger
> some Javascript?

No. I remember investigating javascript manipulation of Java applets
last year but it's not my area of expertise and interest. Last year we
had a small discussion on scripting support for JDNC. We kicked around
some ideas and this was where we left it:

// begin

From Ramesh Gupta:

From JSR 223 (http://jcp.org/en/jsr/detail?id=223):
"The specification is concerned with how to write and package Java
classes that will be accessible from different scripting engines."

From the BSF home page
(http://oss.software.ibm.com/developerworks/projects/bsf):
"The Java world currently does not have a well-defined scripting
architecture that allows Java applications to incorporate scripting
easily - BSF is such an architecture. The BSF architecture allows an
application to be scripted from any BSF supported language, without any
scripting language dependencies."

So, in a nutshell, both JSR 223 and BSF have the same goal -- to allow
applications to be scripted from different scripting languages/engines.
Neither actually provides an integrated script interpreter for a
specific scripting language. So, from UI developers' perspective, they
still have to choose a specific scripting language (e.g., ECMAScript,
Jacl, JPython...), and a scripting engine for that language must be
present on the client -- For browser-based clients, the script
interpreter is typically bundled with the browser.

If we were to support scripting within the JDNC project, we would either
have to choose a scripting language, and bundle an interpreter for that
language with our object realizer, or we will have to allow arbitrary
scripting languages, and expect users to download separate jars
depending on the scripting language(s) used by a particular JCCL
document. Bloat, complexity, or neither -- these are the choices facing us.

//end

Our focus specifically was primarily on simplifying the construction of
rich client applications and secondarily on creating some infrastructure
for more interactive network connected applications (RIA, I suppose).

Scripting components sounds like it could be part of those goals.

> But web deployable, desktop
> applications are not RIA. Where is the 'vision thing' for Java and
> RIA? It would have to be something that acknowledges the existence
> and importance of the web-browser as a primary tool of user
> interaction.

I'm not sure if I understand the terminology and implications of RIA?
I'm guessing that this is a Macromedia/Flex terminology. From my
perspective WebStart deployed applications *are* rich internet
applications. In my mind, the web browser plays a minor role: a way to
find applications. In the Macromedia/Flex world they *need* a browser
since (as I understand) their applications cannot exist in a stand alone
environment.

Personally, I hate using a browser as a primary tool of user
interaction. I'm sorry but web clients for highly interactive
applications just plain suck. Not only that, but complex browser based
applications are not platform independent - they *all* seem to work
perfectly with Win/IE but other platforms and newer Mozilla builds are
hit and miss. Rich Java Clients can provide better ease of use and
responsiveness. Perhaps we can debate these points in a separate thread.

> With the web-browser comes a set of expectations related
> to choices and technology and the ability to combine them. If JDNC is
> part of a Java/RIA vision then it has to acknowledge that Java-based
> components, no matter how functional and how rich they are, are just
> that; [b]components[/b] to be mixed and matched with any other
> Internet capable component.

It was never our focus to ensure interoperability with other components
and technologies other than pure Java/XML solutions. If we seem narrow
minded it's because we are in the desktop Java group and we don't see
the limitations of Java technology for delivering just as capable
solutions. We also don't have the expertise in interoperability so it
would be arrogant for us to come up with solutions in these spaces when
we don't fully understand the problems.

If you have a vision on how JDNC can become part the larger world of
internet capable components then I welcome you to make a proposal.
Perhaps you can drive this effort. This area was not the focus/expertise
of the core JDNC team.

--Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

adriancuthbert
Offline
Joined: 2004-04-30
Points: 0

Hi Mark,

thanks for your full and frank reply, it really made me think. I had always assumed people saw an enhanced browser as the future, but its obviously much more complex than that.

Hopefully you would agree there are circumstances where just being able to offer a richer experience in a browser would be a significant step forward. I can already see how JDNC could be used to that end.

Where I suspect we do not see eye-to-eye is on the relative importance of browser-based applications going forward.

-- Adrian

I've put down even more ramblings at http://adriancuthbert.blogspot.com/2004/06/webstart-and-web-browsers.html

Joshua Marinacci

I just read your blog and I think it's very insightful. I see HTML/ the
web, as being a huge kludge that succeeded where *decades* of other
technologies failed because of a few key advantages (zero conf
deployment, ease of development, vendor transparency) that *vastly
outweigh* all of it's disadvantages. However, it still has those
disadvantages, which are becoming more apparent as we try to take the
great things about the web and move them back to the desktop. Any given
application will be at some point between purely desktop and purely web
based. The nice thing about Java is that it spans the entire spectrum,
giving developers a choice about where on that spectrum they wish to be.

JDNC fits in to this, in my opinion, as a way of smoothing out some of
the discontinuities between the web and the desktop. Combined with
webstart it gives us a lot of the advantages of html (easy deployment,
good separation of UI and code, division of labor between programmers,
designers, and marketing) while keeping the richer programmatic
interface that a desktop app provides. But, again, it's a spectrum
that's available for us. Where we choose to be on that spectrum is up to us.

That said, I think using JDNC's xml markup in an applet is a great idea.
I think a lot of purely webbased applications could be greatly enhanced
by judicious use of an applet. Editing in a wiki comes to mind.
Wouldn't it be nice to use a WYSIWYG editor in a wiki, complete with
quick sketches from a java drawing tool?

Let's keep this dicussion going. I like what we're getting, and since I
had to miss JavaOne I'm jealous of all of you who are there to hear this
stuff in person.

- Joshua

jdnc-interest@javadesktop.org wrote:

> Hi Mark,
>
> thanks for your full and frank reply, it really made me think. I had
> always assumed people saw an enhanced browser as the future, but its
> obviously much more complex than that.
>
> Hopefully you would agree there are circumstances where just being
> able to offer a richer experience in a browser would be a significant
> step forward. I can already see how JDNC could be used to that end.
>
> Where I suspect we do not see eye-to-eye is on the relative
> importance of browser-based applications going forward.
>
> -- Adrian
>
> I've put down even more ramblings at
> http://adriancuthbert.blogspot.com/2004/06/webstart-and-web-browsers.html
> --- [Message sent by forum member 'adriancuthbert' (adrian
> cuthbert)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=13214&#13214
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net For
> additional commands, e-mail: jdnc-help@jdnc.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Anonymous

The irony is the JDNC started out precisely as a technology to enhance the browser-based application experience (we initially called it "enterprise applets") and we had plans to work on facilitating the connection between applets (which are embedded as components in the html page) and the enclosing DOM and other web-app infrastructure (session context, etc).

We are not discounting the value of this paradigm in certain circumstances, but we quickly concluded that the effort to make this work well was substantial and would likely dominate the limited resources we had for the project. So, like any real world project we had to prioritize and decided that we could get more bang for the buck by initially focusing on simplifying the construction of rich Java clients in a more general way.

But! we DO continue to support applet deployment and would welcome contributions towards making JDNC a nice fit for RIA.

Aim