Skip to main content

JDNC Objectives & Scope

10 replies [Last post]
evans_castonguay
Offline
Joined: 2003-08-13
Points: 0

The goal of JDNC based on the official project home page is:
to significantly reduce the effort and expertise required to build rich, data-centric, Java desktop clients for J2EE-based network services.
This statement implies that without additional framework components that goal could no be achieved. By meating differents Java developers of differents companies I reallized that a lot of peoples come to that conclusion a while ago. And since they did not have ,at the time, a project like JDNC they build there own libraries to improve there productivity and the richness of there application. I am not differents them.

During the last year I try to analyse what were my Swing framework needs and translate them into particular requirements. Same if JDNC address part of my needs I believe that JDNC only look at the tip of the iceberg.

I am sending this email to start a discussions about the differents requirements that meet the goal of the JDNC project but are currently not address by the current implementation. By identifing differents requirements this group could prioritize the development activities and provides the most important feature first.

This is a list of framework with short description that we needed for our rich application and that I think that could be nice in JDNC:
Thin-client Creational Swing Framework
Framework that sub-divided your complete application into components: model, view, controller,action.
The framework is reponsible to create, link and integrate all the previous component based on a XML descriptor.
This is done using a factory create your application based on that xml.This factory could use reflection mechanism to initialise components. This imply that your application become like building block and the composition of your application is not done at run-time instead of being done at compile time. The framework support stand-alone or thin-client application where the descriptor is localed either in a local storage or in a central server. Different descriptor could be used contextual to the authenticated user and its security.
For example, certain views, modules and controllers could be accessible only with the propert authorization.
All controllers are managed centrally by the framework so that we could implemented easilly security support and keymap support.
Thin-client Swing authentication and authorization module (compatible with JAAS or other security mechanism.)
Stand-alone version with file descriptor
Server side version with JAAS integration
Implement data-binding components
I won't go in a lot of detail because it is really similar to JDNC data-binding component.
The only think that we implement that is missing in JDNC implementation is that we are able to rebuild the xml that describes the view based on the current view. Today JDNC read the XML and render the Jtable. But they are not able from a rendered Jtable to re-generate XML.

We also had a user preference storage service where we could store preference for a given user. This allows the application to keep the preference of user same after the user close is thin-client.

A lot of the framework that we created are based on the struct paradigm. And I believe that this is where JDNC should go.

I am currently really impress with the first version of the JDNC and I think that providing Swing data-aware components is a good way to improve productivity. One of the most productive tools (in term of development cost) to manage information is MS-Access which does some kind of data-binding. But like you know ms-access is no a viable solution for a enterprise solution (portability, scallability, packaging, etc...) Borland also attemp fee years ago to address the same problem with there dbswing data-binding components. At the time the project did not raized enough interest so they stop there development. I believe that by seperating the data from the XML meta-info the JDNC group have taken a much more flexible and extensible approach than borland. The fact that they have a JNDC XML also is a big edge.

In conclusion,I am really happy to see that Sun started that new initiative. I really think that this initiative may fullfill a gap that has been for a long time ignore.

I would like to know which are the framework components would you like to see in JNDC. Also I would like to know if you are interested in any of the one that I have mentioned earlier.

Best Regard,
Evans Castonguay

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> Having worked with a number of GUI frameworks in
> various programming languages, I've noticed that
> certain features useful for creating real enterprise
> applications always seem to get left out. These tend
> to be cross-cutting features, meaning that the
> development team must implement them before
> constructing the application or risk having to make
> sweeping changes later.
>
> JDNC is off to an encouraging start in that JNTable
> already supports interactive sorting, reordering
> columns, and alternate row highlighting. These
> features are usually left as an exercise for the
> reader.
>
> However, JDNC is still lacking other features our
> team has consistently had to add to the GUI
> frameworks we have used for our applications over the
> years:
>
> 1) A Persistence Mechanism for UI Preferences - When
> the user resizes or re-orders columns in a table or
> resizes or moves a window, he has a reasonable
> expectation that the application will remember these
> changes the next time it runs. Too often it does not
> because the developer had other things to do.

This is on our TBD list ;-)

>
> 2) Multi-Column Table Sorting - Users expect to be
> able to sort a UI table by more than one column at
> time. After all, Excel lets them do this.

JXTable currently supports multi-column sorting where you can specify both, the order in which columns within a group are sorted, and the sort direction (ascending or descending) for each individual column. To set this up, you have to create a FilterPipeline with an array of suitably configured Sorter objects, and set that filter pipeline on the table.

>
> 3) Standard Dialogs for UI Preferences - It's great
> to be able to set up the visible columns, column
> widths and sorting behavior in a table interactively,
> but what if the user wants to set up a number of
> tables with a consistent format? What if the company
> wants to configure a set of tables in a standard way?
> Most Enterprise UI's need a standard UI preferences
> (View Properties) dialog far more than they need a
> standard Color Chooser.

In addition to the preference dialogs, we need a persistence format for such preferences. The XML description of tables, columns, and such should be amenable to styling using this persistence format. That way, both XML and non-XML users can benefit from a single implementation.

>
> 4) Paged Data Retrieval - Users don't want to think
> about query parameters in advance. They'd rather make
> a broad query using default parameters, even if it
> returns 10,000 rows, and then refine the query once
> they see the data. The problem for client/something
> user interfaces is that users don't want to wait for
> all 10,000 rows to make it down to their desktops
> before they know the size of the result set and see
> the data. Neither does it make sense for the
> enterprise to pay for the network capacity to handle
> 10,000 row result sets when all but a tiny fraction
> of the data will never be used.
>
> While an RDMBS must return the entire result set for
> a given query, the middle tiers present in most
> enterprise applications provide the means to cache
> the result set and only return the first "page" of
> rows to the desktop. However, even when the GUI
> framework uses an asynchronous method to populate the
> data model and lazy loading to bring it into the
> view, the entire result set still has to travel
> across the wire and be unmarshalled into the
> client-side data model. To avoid this, the framework
> must be extended to support paged browsing of the
> result set (think Google).

One possibility is to load the first two (or three) blocks or screenfulls of rows, and then pause the data loading thread until the user clicks the scrollbar, and then repeat with the next or previous two blocks, depending on which part of the scrollbar was clicked, and pause again.

>
> 5) Formatted Reports - Users expect to be able to
> print the data as it is displayed in any view of the
> application in a format suitable for presentation to
> a customer. This means that a simple screen dump will
> not do. The report must contain header and trailer
> information on each page. Again, Excel does this so
> users expect it in other applications.

Starting with J2SE 5.0, JTable has built-in support for WYSIWYG printing for all rows in a table, complete with alternate row highlighting and such.

My strong recommendation in this area is to export table data in XML using the simple schema definition we have today, so as to allow XSLT/XSL-FO formatting for additional presentational flexibility.

>
> All of these things can be accomplished in Swing, but
> at the cost of effort and expertise. This is why
> these features would be good candidates for inclusion
> in the JDNC framework.

Agreed :-)

Anonymous

I would like to add my part to this:

1) I would like to see all events carry a reference to the visual component that generated them

2) In our application, there is a requirement to enable/disable Save, Cancel buttons based on whether the user dirtied any field on the screen. I would like be notified when the user changes something since the last Save (read 'since the last event that we will demarcate in code'). I created a component that did this and realized that there was also a need to "know" all components on which operations could be performed not-intrusively (locking/disabling/enabling fields, recognizing dynamically created fields, enhancing the behavior of components dynamically using reflection and the decorator pattern).

Anonymous

I found there is an isModified() method somewhere in the API..

cp1965
Offline
Joined: 2004-06-11
Points: 0

Hello! I share your enthousiasm for JDNC. Put it simply: It's about time! I would suggest to add the goal to provide a online repository of JDNC design patterns which will essentially be some predesigned screens in JDNC that any user coud download and use immediately. This will make development even faster. We could try to make the file self-documented with comments and suggestions.

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> Hello! I share your enthousiasm for JDNC. Put it
> simply: It's about time! I would suggest to add the
> goal to provide a online repository of JDNC design
> patterns which will essentially be some predesigned
> screens in JDNC that any user coud download and use
> immediately. This will make development even faster.
> We could try to make the file self-documented with
> h comments and suggestions.

I think this is a fantastic idea! I see a lot of questions along the lines of how do I do this or how do I do that. We could answer those questions on the forum, but they are not as easily accessbile as an online repository.

I think we should create an examples subdirectory under each of Swing Extensions, JDNC API, and JDNC Markup as a place to hold moderated, tested examples that people can draw on.

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

[snip]
> I am sending this email to start a discussions about
> the differents requirements that meet the goal of
> f the JDNC project but are currently not address by
> the current implementation.[snip]
>
> This is a list of framework with short description
> that we needed for our rich application and that I
> think that could be nice in JDNC:
> Thin-client Creational Swing Framework
> Framework that sub-divided your complete application
> into components: model, view, controller,action.
> The framework is reponsible to create, link and
> integrate all the previous component based on a XML
> descriptor.

We have parts of the framework that you are referring to. For example:

XML descriptor (here) == XML configuration file (in JDNC terminology)

> This is done using a factory create your application
> based on that xml.This factory could use reflection
> mechanism to initialise components.

factory == ObjectRealizer

> This imply that
> your application become like building block and the
> composition of your application is not done at
> run-time instead of being done at compile time.

I presume you meant that the composition *is* done at run-time, not at compile time.

JDNC currently does not have this level of flexibility. eNode has some examples of dynamic application compositions (http://www.enode.com/x/webservices) where they show how three separate web-service applications can be used independently, as well as composed into a seamless whole (complete with menu merging and all).

Is there interest within the JDNC community for something like this?

> The framework support stand-alone or thin-client
> application where the descriptor is localed either in
> a local storage or in a central server. Different
> descriptor could be used contextual to the
> authenticated user and its security.
> For example, certain views, modules and controllers
> could be accessible only with the propert
> authorization.
>
> All controllers are managed centrally by the
> framework so that we could implemented easilly
> security support and keymap support.
> Thin-client Swing authentication and authorization
> module (compatible with JAAS or other security
> mechanism.)
> Stand-alone version with file descriptor
> Server side version with JAAS integration

The JDNC team is currently debating this feature. How important is it to the JDNC community to be able to dynamically compose certain views, modules, and controllers based on user authorization.

> Implement data-binding components
> I won't go in a lot of detail because it is really
> similar to JDNC data-binding component.
> The only think that we implement that is missing in
> JDNC implementation is that we are able to rebuild
> the xml that describes the view based on the current
> view. Today JDNC read the XML and render the Jtable.
> But they are not able from a rendered Jtable to
> re-generate XML.

This request comes up a lot. At some point, I think we should definitely look into this.

>
> We also had a user preference storage service where
> we could store preference for a given user. This
> allows the application to keep the preference of user
> same after the user close is thin-client.

Yes, personalization support is another frequently requested feature.

[snip]
> I am currently really impress with the first version
> of the JDNC and I think that providing Swing
> data-aware components is a good way to improve
> productivity. One of the most productive tools (in
> term of development cost) to manage information is
> MS-Access which does some kind of data-binding. But
> like you know ms-access is no a viable solution for a
> enterprise solution (portability, scallability,
> packaging, etc...) Borland also attemp fee years ago
> to address the same problem with there dbswing
> data-binding components. At the time the project did
> not raized enough interest so they stop there
> development. I believe that by seperating the data
> from the XML meta-info the JDNC group have taken a
> much more flexible and extensible approach than
> borland. The fact that they have a JNDC XML also is a
> big edge.

Thanks!

Ramesh

dcurry
Offline
Joined: 2006-02-17
Points: 0

Having worked with a number of GUI frameworks in various programming languages, I've noticed that certain features useful for creating real enterprise applications always seem to get left out. These tend to be cross-cutting features, meaning that the development team must implement them before constructing the application or risk having to make sweeping changes later.

JDNC is off to an encouraging start in that JNTable already supports interactive sorting, reordering columns, and alternate row highlighting. These features are usually left as an exercise for the reader.

However, JDNC is still lacking other features our team has consistently had to add to the GUI frameworks we have used for our applications over the years:

1) A Persistence Mechanism for UI Preferences - When the user resizes or re-orders columns in a table or resizes or moves a window, he has a reasonable expectation that the application will remember these changes the next time it runs. Too often it does not because the developer had other things to do.

2) Multi-Column Table Sorting - Users expect to be able to sort a UI table by more than one column at time. After all, Excel lets them do this.

3) Standard Dialogs for UI Preferences - It's great to be able to set up the visible columns, column widths and sorting behavior in a table interactively, but what if the user wants to set up a number of tables with a consistent format? What if the company wants to configure a set of tables in a standard way? Most Enterprise UI's need a standard UI preferences (View Properties) dialog far more than they need a standard Color Chooser.

4) Paged Data Retrieval - Users don't want to think about query parameters in advance. They'd rather make a broad query using default parameters, even if it returns 10,000 rows, and then refine the query once they see the data. The problem for client/something user interfaces is that users don't want to wait for all 10,000 rows to make it down to their desktops before they know the size of the result set and see the data. Neither does it make sense for the enterprise to pay for the network capacity to handle 10,000 row result sets when all but a tiny fraction of the data will never be used.

While an RDMBS must return the entire result set for a given query, the middle tiers present in most enterprise applications provide the means to cache the result set and only return the first "page" of rows to the desktop. However, even when the GUI framework uses an asynchronous method to populate the data model and lazy loading to bring it into the view, the entire result set still has to travel across the wire and be unmarshalled into the client-side data model. To avoid this, the framework must be extended to support paged browsing of the result set (think Google).

5) Formatted Reports - Users expect to be able to print the data as it is displayed in any view of the application in a format suitable for presentation to a customer. This means that a simple screen dump will not do. The report must contain header and trailer information on each page. Again, Excel does this so users expect it in other applications.

All of these things can be accomplished in Swing, but at the cost of effort and expertise. This is why these features would be good candidates for inclusion in the JDNC framework.

Adrian Sutton

There's a couple of of things I can help with here.

> 2) Multi-Column Table Sorting - Users expect to be able to sort a UI
> table by more than one column at time. After all, Excel lets them do
> this.

JDNC tables already support this in the same way that it's supported in
most other table implementations. If you click on table header it
sorts by that then if you click a different header it sorts by that
column with the secondary ordering of the first column. This can be
done with any number of columns.

> 5) Formatted Reports - Users expect to be able to print the data as it
> is displayed in any view of the application in a format suitable for
> presentation to a customer. This means that a simple screen dump will
> not do. The report must contain header and trailer information on each
> page. Again, Excel does this so users expect it in other applications.

You should look at the new print methods on JTable provided as part of
Swing (I think it's new in Java 1.5). This behaves pretty much like
Excel by default but can be customized fairly easily.

Regards,

Adrian Sutton.

----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

Anonymous

Evans,

You are right - this is most certainly the time to start discussing scope and requirements so that we can more crisply prioritize the components and features we need for our initial 1.0 release and beyond.

We must be careful to remain focused, however, otherwise we risk a kitchen-sink destiny which would be unattainable. I've seen many great projects unravel into oblivion because of feature addiction.

Anyhow, our team would very much like to hear what developers want this project to provide (in keeping with the "rich, data-centric desktop client for ee services" goal, which is admittedly, ehem, broad).

In the spirit of a whiteboard brainstorm (sans whiteboard) perhaps members could send a message which:

a) describes succinctly the app they need to build

b) defines a *prioritized* list of requirements of things jdnc could provide to facilitate that end (even if you've already had to build those things yourself due to the current vacuum)

Remember that rule#1 of a brainstorm is that thoughts should flow without critique -- at least initially.

Aim

rbair
Offline
Joined: 2003-07-08
Points: 0

a) Client/server desktop application that scales from small (1+) person deployments to massive internet based deployments. Top priority is performance. 2nd priority is look and feel (its gotta be easy to use and pretty to look at :-)). The backend data store is a database, Tomcat is running in between servicing requests, and all communication between the client and server is over port 80. Currently the clients are all thick (Tomcat is used for the server instead of writing my own), but thin (read, browser) based clients will be written in the future. Currently, thick clients address a specific url that will return a series of RowSets to get data from the db.

b) The biggest draw for me towards JDNC is the asyncronous loading. Second is databinding. Databinding would be a bigger deal except I am already running a framework that works pretty well. RowSet support is critical.