Skip to main content

Feedback on JDNC and my framework

11 replies [Last post]
shai.almog
Offline
Joined: 2006-02-17
Points: 0

Hi,
I'm very excited that JDNC (finally) came out, over the years I had to write most of these things for practically every project I worked at (I'm a consultant so sometimes I can't take code from one project to the next).
I have a framework implementation with some features that are not available (yet) in JDNC and I'll be very happy to contribute and even assign copyright/license as needed to get code into the tree, but I might be a bit stressed in time to merge stuff myself.

If there is any interest then let me know how I can contribute.

Anyway I have some comments on the structure of JDNC:

1. Its great that JDNC is divided so that JNTable does not derive from table. However the approach of maintaining the whole "component hierarchy" and layout management immediately visible is a bit problematic.
My solution in the framework was to use what I dubbed as templates (yes I stole the idea ;) the template is an interface whose implementer makes sure to layout a panel appropriately, you just assign roles to components and send them to the template that will produce a well laid out container.
This is very powerful since an advanced Swing user can implement several templates and layout logic can be reused. Templates can be nested, but it is much simpler and the hierarchy is not tree like as in the component/container hierarchy. I generally found templates to be much simpler and implemented correctly they can allow JDNC to create its own hierarchy and encapsulate the huge Swing/AWT API.

2. The table implementation needs some work for at least some of our customers to use it:
a. Different data types in a single column is very common (a "sum" or "total" row is very common).
b. Validation in "real world" tables is so complicated I just disabled table editing in our current framework version. Powerbuilder allows you to place constraints on losing focus and exiting row/cell etc... Thus allowing you to force a user to enter the correct data even in cyclic dependencies. I can't say I'm crazy about this myself but some "ex" powerbuilder users were on my case quite often about table validation and it was quite hard.

3. Image/Icon managers will be quite useful.

4. I saw no mention of i18n or BiDi.

5. What about a harness application? This way the developer doesn't have to implement main() etc... and gets things such as progress indicator, menubar, toolbar etc...
There can be several simple harness applications and the developer can override a method such as createFileMenuEntries()... to customize the application.

6. How will JDNC be packaged? Right now I see a single JavaDoc so I assume a single Jar. However since JDNC is layered it should probably be split up both for the sake of JNLP applications and for developers that don't want to use all the layers of JDNC.

7. I noticed Swing worker was incorporated which is nice. However since this framework has a layer targeted at beginners maybe a few calls to isSwingThread() that could result in an exception would be a good idea? Also how about incorporating something like foxtrot?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
zander
Offline
Joined: 2003-06-13
Points: 0

> > The lawyers tell us that contributors should make
> > sure they agree to the JCA (Joint Copyright
> > Assignment) before they post any code on the forum.
> > The idea, I think, is to avoid the kind of flap that
> > SCO and Linux are embroiled in :-)
> Ramesh and I were discussing the issue of copyright
> assignment and I referenced an article about having a
> "paper trail" of copyright assignments as a way of
> protecting a project from spurious lawsuites a la SCO
> vs. Linux.

Your concern in this matter is good, but the tactics are irrelevant and too far-reaching.
The SCO example has never in the many months that it went on actually looked at code, let alone questioned their origin. Even with everyone knowing that there is no paper-trail as such.
In other words; SCO-like practices are still very much an issue with or without Sun being able to claim copyright to 100% of their codebase.

I trust Suns lawyers are smart enough; so they must know this to be true.
I can't help but wonder if Sun just wants to avoid requests from the people that actually did the hard work to be able to have a say in how Sun uses their work.

Mark Davidson
Offline
Joined: 2006-02-17
Points: 0

> The lawyers tell us that contributors should make
> sure they agree to the JCA (Joint Copyright
> Assignment) before they post any code on the forum.
> The idea, I think, is to avoid the kind of flap that
> SCO and Linux are embroiled in :-)

Ramesh and I were discussing the issue of copyright assignment and I referenced an article about having a "paper trail" of copyright assignments as a way of protecting a project from spurious lawsuites a la SCO vs. Linux. I was discussing this issue with Ramesh last week and I couldn't remember where I read that article. I found it in this months Wired Magazine in an article about Darl McBride (CEO of SCO).

I found that this sidebar perfectly illustrated why we have a JCA in place.

http://www.wired.com/wired/archive/12.07/linux.html?pg=6

Since this project is sponsored by Sun, we want to ensure that we are "covering our assets" so to speak.

--Mark

shai.almog
Offline
Joined: 2006-02-17
Points: 0

Hi Mark,
I agree 100%, but is the signature I faxed enough or do I need to do something more?

> Ramesh and I were discussing the issue of copyright
> assignment and I referenced an article about having a
> "paper trail" of copyright assignments as a way of
> protecting a project from spurious lawsuites a la SCO
> vs. Linux. I was discussing this issue with Ramesh
> last week and I couldn't remember where I read that
> article. I found it in this months Wired Magazine in
> an article about Darl McBride (CEO of SCO).
>
> I found that this sidebar perfectly illustrated why
> we have a JCA in place.
>
> http://www.wired.com/wired/archive/12.07/linux.html?pg
> =6
>
> Since this project is sponsored by Sun, we want to
> ensure that we are "covering our assets" so to
> speak.
>
> --Mark

Mark Davidson

On 07/20/2004 01:06 AM, jdnc-interest@javadesktop.org wrote:
> Hi Mark,
> I agree 100%, but is the signature I faxed enough or do I need to do something more?

Hi Shai,

The fax should be adequate. We are trying to figure out a process in
which we are informed about the faxed JCAs.

Thanks,

--Mark

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

shai.almog
Offline
Joined: 2006-02-17
Points: 0

> The lawyers tell us that contributors should make
> sure they agree to the JCA (Joint Copyright
> Assignment) before they post any code on the forum.
> The idea, I think, is to avoid the kind of flap that
> SCO and Linux are embroiled in :-) For more
> information, please see
> https://jdnc.dev.java.net/contribute.html

Just sent the fax over, its ok to look over the code ;)

shai.almog
Offline
Joined: 2006-02-17
Points: 0

> > If there is any interest then let me know how I
> can
> > contribute.
>
> Yes, we are genuinely interested in engaging the
> developer community. The best way to start
> contributing is first try things out, then look at
> our code/API, and post ideas/bug fixes/sample code
> for enhancements on the forum.

I'll try to get some of my code on the web over the weekend. I will probably place it with a GPL license just for people to look at but I will be happy to license everything to Sun if necessary and grant every permission necessary in writing.
If you would like a different license just write it here and I will try to accommodate.

> This sounds intriguing. Please show us some sample
> code on how users would *use* such a facility. We can
> then talk about code sharing and how to implement
> such a facility in JDNC

In our current framework (which is somewhat simplified) a user creates a form (currently by deriving from it). Each form has a view and the view is an implementation of the Template interface. The template interface (I'm doing this from memory so this might be a bit far off), looks something like this:
public void setComponents(String logicalPosition, JComponent[] cmps);
public JComponent getView();

The template implementor can contain a JPanel into which he builds this huge layout/layout hierarchy. The setComponents() method is a bit cluttered usually since it needs to test for possible positions. However these positions are logical and thus the author of the template is the only person that needs to understand layout managers.

To further simplify I have an AbstractTemplate implementation that contains helper methods for common cases such as String and component pairs that automatically create labels for the strings.

The general idea was to hide the entire "hierarchy", I ended up with something that allows me to nest templates (since the setComponents method calls the setComponents method within it) but it is still much simpler. The general result and inspiration is from the J2EE Tiles framework.

> > 4. I saw no mention of i18n or BiDi.
> >
>
> We have dedicated i18n/BiDi experts/watchdogs on our
> team! So, even if things are currently not fully
> localizable, rest assured, they will be!

If they need any help ;)

> > 5. What about a harness application? This way the
> > developer doesn't have to implement main() etc...
> and
> > gets things such as progress indicator, menubar,
> > toolbar etc...
> > There can be several simple harness applications
> and
> > the developer can override a method such as
> > createFileMenuEntries()... to customize the
> > application.
> >
>
> We have a harness application for those using our
> markup language. It is called
> org.jdesktop.jdnc.runner.Application. Adding or
> suppressing menubars, toolbars, statusbars, and such
> is trivial using the JDNC markup language -- No
> methods to override, no Java code to write!

As a nonbeliver in XML based interfaces, could we still have a couple of these interfaces accessible in code?

> The layers in JDNC are clean. The dependencies are
> carefully monitored, and the layering strictly
> enforced. So, it is a simple matter of tweaking the
> Ant build scripts to package the jars by layer.

I read Mark's posting and this seems to be exactly what I was asking for.

Thanks.

I'll try to post at least a partial source code snapshot this weekend but it might be a bit messy. I'll try to do a small writeup explaining the highlights (and downsides...).

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

The lawyers tell us that contributors should make sure they agree to the JCA (Joint Copyright Assignment) before they post any code on the forum. The idea, I think, is to avoid the kind of flap that SCO and Linux are embroiled in :-) For more information, please see https://jdnc.dev.java.net/contribute.html

shai.almog
Offline
Joined: 2006-02-17
Points: 0

> The lawyers tell us that contributors should make
> sure they agree to the JCA (Joint Copyright
> Assignment) before they post any code on the forum.
> The idea, I think, is to avoid the kind of flap that
> SCO and Linux are embroiled in :-) For more
> information, please see
> https://jdnc.dev.java.net/contribute.html

Thank's, I'll make sure to sign and fax it on Sunday. Anyway I won't post any code to the forum yet and to be safe I GPL'd the code right now. You can have a look at it and on the java doc that comes with it on our web page here:
http://www.vprise.com/articles/swingee_release.jsp
http://www.vprise.com/articles/swingee_introduction.jsp
http://www.vprise.com/api/swingee/index.html and finally the download link is: http://www.vprise.com/download/swingee.zip
Obviously this is partial work containing the requirements of a very small cross section of our clients (the version used in the banking world is completely propriatery of the banks we worked with). So there are many things I would do differently in JDNC, but still I think some ideas might be appropriate for JDNC as well.

shai.almog
Offline
Joined: 2006-02-17
Points: 0

One thing I keep forgetting to mention about our framework is this:
The framework depends on a server, thats relatively easy to develop. However one of the nice features in the framework is the colaboration between the client and the server. When the user sorts a table one of the following two options can happen:
1. The table is completely cached in the client side and will thus be sorted on the client side alone.
2. The table is partially in the client side and thus will ask the server for a sorted version and refresh itself.

The same is true for searching, if the table is cached a search will be completely done in the client side. Otherwise the table will be refreshed with a search on the server side.

The engine also supports refreshing the cache in case a change occured in the server side.

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

> Hi,
> I'm very excited that JDNC (finally) came out, over
> the years I had to write most of these things for
> practically every project I worked at (I'm a
> consultant so sometimes I can't take code from one
> project to the next).
> I have a framework implementation with some features
> that are not available (yet) in JDNC and I'll be very
> happy to contribute and even assign copyright/license
> as needed to get code into the tree, but I might be a
> bit stressed in time to merge stuff myself.
>
> If there is any interest then let me know how I can
> contribute.

Yes, we are genuinely interested in engaging the developer community. The best way to start contributing is first try things out, then look at our code/API, and post ideas/bug fixes/sample code for enhancements on the forum.

>
> Anyway I have some comments on the structure of
> JDNC:
>
> 1. Its great that JDNC is divided so that JNTable
> does not derive from table. However the approach of
> maintaining the whole "component hierarchy" and
> layout management immediately visible is a bit
> problematic.
> My solution in the framework was to use what I dubbed
> as templates (yes I stole the idea ;) the template is
> an interface whose implementer makes sure to layout a
> panel appropriately, you just assign roles to
> components and send them to the template that will
> produce a well laid out container.
> This is very powerful since an advanced Swing user
> can implement several templates and layout logic can
> be reused. Templates can be nested, but it is much
> simpler and the hierarchy is not tree like as in the
> component/container hierarchy. I generally found
> templates to be much simpler and implemented
> correctly they can allow JDNC to create its own
> hierarchy and encapsulate the huge Swing/AWT API.

This sounds intriguing. Please show us some sample code on how users would *use* such a facility. We can then talk about code sharing and how to implement such a facility in JDNC

>
> 2. The table implementation needs some work for at
> least some of our customers to use it:
> a. Different data types in a single column is very
> ry common (a "sum" or "total" row is very common).

We already have plans for supporting "virtual rows" that can be used for "sum" or "total".

> b. Validation in "real world" tables is so
> so complicated I just disabled table editing in our
> current framework version. Powerbuilder allows you to
> place constraints on losing focus and exiting
> row/cell etc... Thus allowing you to force a user to
> enter the correct data even in cyclic dependencies. I
> can't say I'm crazy about this myself but some "ex"
> powerbuilder users were on my case quite often about
> table validation and it was quite hard.

Yes, this is non-trivial for anything beyond field-level validation.

>
> 3. Image/Icon managers will be quite useful.
>

We do have plans for this. Please stay tuned.

> 4. I saw no mention of i18n or BiDi.
>

We have dedicated i18n/BiDi experts/watchdogs on our team! So, even if things are currently not fully localizable, rest assured, they will be!

> 5. What about a harness application? This way the
> developer doesn't have to implement main() etc... and
> gets things such as progress indicator, menubar,
> toolbar etc...
> There can be several simple harness applications and
> the developer can override a method such as
> createFileMenuEntries()... to customize the
> application.
>

We have a harness application for those using our markup language. It is called org.jdesktop.jdnc.runner.Application. Adding or suppressing menubars, toolbars, statusbars, and such is trivial using the JDNC markup language -- No methods to override, no Java code to write!

> 6. How will JDNC be packaged? Right now I see a
> single JavaDoc so I assume a single Jar. However
> since JDNC is layered it should probably be split up
> both for the sake of JNLP applications and for
> developers that don't want to use all the layers of
> JDNC.
>
We used to package JDNC as a collection of individual jar files, but decided to put everything in a single jar for simplicity.

The layers in JDNC are clean. The dependencies are carefully monitored, and the layering strictly enforced. So, it is a simple matter of tweaking the Ant build scripts to package the jars by layer.

Mark Davidson

On 07/12/2004 05:56 PM, wrote:
>> 6. How will JDNC be packaged? Right now I see a single JavaDoc so I
>> assume a single Jar. However since JDNC is layered it should
>> probably be split up both for the sake of JNLP applications and for
>> developers that don't want to use all the layers of JDNC.
>
> We used to package JDNC as a collection of individual jar files, but
> decided to put everything in a single jar for simplicity.

Actually, the deployment/make/build.xml bundle task will create a
"jdnc-all" jar file which will be an agregate of all the jar files minus
the application loader. This was to simplified web start deployment.

For mainstream development we now have 4 jar files that map to the
sub-projects:

swingx.jar - the swing extensions.
jdnc.jar - jdnc components. (depends on swingx.jar)
jdnc-xml.jar - taglibs and realizer (depends on jdnc.jar, om.jar and
sor.jar).
jdnc-runner.jar - the xml application launcher (depends on jdnc-xml.jar)

> The layers in JDNC are clean. The dependencies are carefully
> monitored, and the layering strictly enforced. So, it is a simple
> matter of tweaking the Ant build scripts to package the jars by
> layer.

You can build the inividual jar files by going into the make directory
of the sub-project and typing "ant". The jar files will be placed in the
jdnc/dist/bin directory.

swingx/make - will build swingx.jar

jdnc_api/make - will build jdnc.jar

jdnc_xml/make - will build jdnc-xml.jar, jdnc-runner.jar

Also, each subproject contains a "lib" directory which contains the
dependencies for that project. At build time, these dependencies are
copied to the jdnc/dist/lib directory. For example, the jdnc_xml depends
on om.jar and sor.jar so they are located in jdnc_xml/lib.

We are hoping to manage the library dependencies with Maven in the near
future.

--Mark

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