Skip to main content

JDNC1.0 Roadmap *draft*

30 replies [Last post]
Anonymous

We've put together an initial stab at a roadmap for JDNC1.0:

https://jdnc.dev.java.net/documentation/roadmap.html

This document attempts to layout a vision, feature-set, and very tentative schedule (e.g. guesstimates) for JDNC's first release.

Your thoughts, ideas, comments are most welcome. I know you won't be shy :-)

Cheers,
Aim

Reply viewing options

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

Amy Fowler wrote:
>
> Ultimately, it should be possible to use the binding/form infrastructure with
> your own garden-variety panels/layouts. Jeanette is going to work directly on
> evolving the binding APIs and I'm sure this is something she's aware of....
>

Yes - I'm aware of the issue :-) In fact, my incubator examples contain
a demo how to interface to my favourite garden-variety interface builder

Jeanette

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

Amy Fowler

jdnc-interest@javadesktop.org wrote:
>
> 2) I suppose if the JXForm allows overriding/composition of the UI construction and placement in
bind() then other layouts might not be required. Will that be the case?
>
> In particular, I'm thinking of the case where I want to have some control over the alignment,
spacing, etc... of the UI controls that are created as a result of a bind(). For instance, I like
how some layout managers horizontally alig the label and text field and would want that in a
JXForm. Or, I might want label fields aligned on the left instead of on the right, centered, or
whatever. For whatever the reason, I might not want to use default JXForm layout and specify my own
instead.

Allowing developers to augment or completely override the default JXForm layout
is an absolute requirement. Today there are 2 ways to do this (neither of
which I'm very happy with):

1) set the form's autoLayout property to false, in which case the app must
take responsibility to add/layout each component created in the call/s
to form.bind() to the form (this causes bind to skip calling the
FormFactory's addComponent() method). The ugliness here is that you have
to dig the components out of the Binding instances returned from bind().
yuk.

2) Override/replace the default FormFactory and write your own addComponent()
method. The FormFactory can be replaced directly on a JXForm instance
(setFormFactory()) or on a global basis (FormFactory.setDefaultFormFactory()).

Ultimately, it should be possible to use the binding/form infrastructure with
your own garden-variety panels/layouts. Jeanette is going to work directly on
evolving the binding APIs and I'm sure this is something she's aware of....

Aim

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

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

Amy:

Are you working on the idea that the layout manager reads the layout hints from some external source at construction (or at least independantly from the individual calls to addLayoutComponent)?

There're a couple dozen efforts underway to create a UI language that documents the layout of panels: I think it would be a great service to the community if Sun were to formalize an interface wherein these independant efforts could all interoperate with existing layout managers.

I think it'd be interesting/useful to be able to pass at construction:

- A set of serialized GridBagConstraints (mapped to component name?) to a slightly modeified GridBagLayout
- A set of Karsten's FormLayout descriptions to a modified FormLayout
- Something like a .css file to a modified TableLayout

Dave Hall
http://jga.sf.net/

ps: of course, I think the next natural step after that is to ask why we write code to do component/form assembly at runtime at all? What's standing in the way of serializing the entire layout at buildtime?

jtr
Offline
Joined: 2003-06-10
Points: 0

> to ask why we write code to do component/form assembly at > runtime at all? What's standing in the way of serializing > the entire layout at buildtime?

It depends how it is done, but leaving a form in XML might provide an easier, or at least more standardized, mechanism of changing the form (think XSLT) or updating it at runtime.

Patrick Wright

jdnc-interest@javadesktop.org wrote:
>>to ask why we write code to do component/form assembly at > runtime at all? What's standing in the way of serializing > the entire layout at buildtime?
>
>
> It depends how it is done, but leaving a form in XML might provide an easier, or at least more standardized, mechanism of changing the form (think XSLT) or updating it at runtime.

XML also compresses well and so is suited for quick downloads over a
network, loading from the filesystem, a database, etc.

Patrick

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

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

> Unless you warn that the API is subject to change,
> people are likely to complain loudly about minor
> changes (for example see JDBC 2.0 vs 3.0, etc...).
> And as we all know, sometimes you get an epiphany
> while implementing those little details that make
> you want to refactor the base API.

So, a heads-up: The OpenMarkup API is changing in limited ways. This should not affect developers who just use the API to realize JDNC documents. However, developers of custom tag libraries and object realizers will have to make some changes when they move to the new OpenMarkup interfaces.

Ramesh Gupta

netsql
Offline
Joined: 2004-03-07
Points: 0

I wanted to say that using RowSet is not a good idea.
Instead a DAO/SoA interface on collections would be better.
Also, hopefully the blueprints get socilized here first before the final is released to the public.
.V

Anonymous

Hi I have had this problem also, the solution I found was to call jxtable.revalidate(); which forces the table to redraw its rows.

But from this I have found another problem where the revalidate causes a ArrayIndexOutOfBoundException in the ShuttleSort when removing the filters but the Event Dispatch Thread is not given a chance to run for a bit. Or atleast this is what I assume is happening as the exception occurs after control left my code. i.e my code is not directly causing the exception.

I'm not sure if it would be possible to put my code into a thread as nearly all the changes would effect the gui in some way.

Any advice on that would be most welcome.

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

Hey All,

> > I think one-year wait for Version-1.0 will disappoint many java developers who had placed a lot's of hopes on jdnc project. In the interim, I do hope that jdnc-team will continue to aggressively fix bugs reported against their existing codebase.
>
> Isn't this always the truth. But there's a lot of work to do and we want ample time to get the APIs right before we cast a "1.0". Originally we wanted to be to 1.0 by JavaOne'05, but when we looked at the work remaining it just didn't seem realistic. But clearly the schedule isn't final, so we can discuss whether it would be worthwhile to cut functionality to bring in the 1.0 date. Do others have an opinion?

I've been doing some thinking on this subject. There are esentially 3 aspects to software scheduling: resources, time, and features. In order to meet a deadline (ie: time is fixed) when the project is slipping, the project must either have sufficient resources or the number of features must be chucked, or else let the deadline slip.

The linux kernel (I believe) takes the latter approach using the mantra "ship it when its ready". Gnome takes the second option. It has a rigid release schedule, and just starts chucking features if they run out of time. I personally like the Gnome approach because it gives people (and perhaps more importantly companies) a predictable release cycle that they can plan for.

Its a little more different if you were planning on having feature X by date Y, but then either approach would fail on that need.

I would like to see the JavaOne '05 release of JDNC 1.0 revived. If necessary I'd prefer the swingx layer to the JN* layer or the xml layer.

The reason releasing at JavaOne is good is purely marketing. If we can go to JavaOne with a 1.0 release that companies can build products on (even if it doesn't have the fancy JN* or xml layers) then its a major win for the project. A release post JavaOne would still be good, but wouldn't get quite the same publicity, I think.

Thoughts?

Richard

jtr
Offline
Joined: 2003-06-10
Points: 0

I assume 1.0 means a frozen API. Will the API be flushed out and stable enough to be a 1.0 in a few months?

Unless you warn that the API is subject to change, people are likely to complain loudly about minor changes (for example see JDBC 2.0 vs 3.0, etc...). And as we all know, sometimes you get an epiphany while implementing those little details that make you want to refactor the base API.

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

> I assume 1.0 means a frozen API. Will the API be
> flushed out and stable enough to be a 1.0 in a few
> months?

Yes, and Yes :). I'm pretty confident that we'll have a good foundation (DataModels, binding, etc) by then since some of these concepts and architectures have been in progress for well over a year now (if you count Karsten's binding framework, for example, we have technology that has been matured a bit already).

I'm not so sure about some of the JN* level components and the XML stuff, but I think we can have something very useable out in time, and I feel that the API's will be ready.

>
> Unless you warn that the API is subject to change,
> people are likely to complain loudly about minor
> changes (for example see JDBC 2.0 vs 3.0, etc...).
> And as we all know, sometimes you get an epiphany
> y while implementing those little details that make
> you want to refactor the base API.

That's always the fear. I kind of feel like a) a perfect code base isn't necessary in order to build terrific and useable apps and b) a perfect code base is never possible anyway :). It seems like new ways of doing things are always cropping up, we just need to draw the line somewhere.

Richard

netsql
Offline
Joined: 2004-03-07
Points: 0

I vote to work on it utill it's right, rather than to set a date.
A big open source saying is :it's ready when it's ready.
.V

netsql
Offline
Joined: 2004-03-07
Points: 0

I vote to work on it utill it's right, rather than to set a date.
A big open source saying is :it's ready when it's ready.
.V

kdonald
Offline
Joined: 2004-03-04
Points: 0

Amy,

This looks like a roadmap in the right direction! As the founder of the Spring Rich Client project, I can't help but see some overlap between our efforts. I believe our user communities would greatly benefit from us pursuing integrations opportunities and knowledge/concept/terminology sharing as we both progress towards a 1.0 release. Our development team is already working with some other good projects in the rich client space, including Karsten's JGoodies (forms, bindings, and looks), Jesse Swankston's Glazed Lists, and JIDE/InfoNode/FlexDock for docking integration. We'll likely be getting involved in JSR-227 (binding) with Oracle in some fashion in the future. I've now signed up here, and hope to get active on the forums going forward.

Indeed, if you look at the aims of our project, they match decently well with JDNC. From our roadmap:

--

"The Spring Rich Client project serves several important developer needs:

1. Simplification. Swing, while the most complete Java widget toolkit today, is complex and cumbersome to use. Desktop developers desperately need abstractions that make it easier to wield the power of the Swing toolkit. Spring Rich provides this, capturing design best practices directly in the framework. It provides a simpler programming model you leverage and extend.

2. Consistency. Low level Swing provides no guidelines for constructing well layered applications in a consistent fashion. By “well layered” I mean applications with a clean separation between presentation and business tiers. This is a major goal of Spring Rich. Our framework, built on Spring, provides the foundation for an effective desktop application architecture. We bring strong J2EE services integration. It’s an end-to-end solution with a consistent programming model.

3. Sanity. Today’s Java is “all about choice”. Just as there are a ton of choices in the J2EE space, there are plenty of choices in the rich client space. Projects like JGoodies, JDNC, JDIC, Glazed Lists, Spin, Foxtrot, JIDE, InfoNode, and FlexDock… just to name a few. Spring Rich integrates the best of what’s out there and plugs it into a consistent, simpler programming model. We bring sanity to the landscape of choice which is today’s Java.

---

The way we're leveraging JDNC today is basically as a component provider. We're not in the business of writing better-looking components, but providing higher-level abstractions that make it easy to wield snazzy component libraries. I see JIDE and L2FProd's common components as other good providers in this space."

As far as features, here's the best of what we provide:

1. A set of abstractions managing the lifecycle and configuration of a desktop application. The framework provides a facility for managing multiple application windows, views, editors, and command bars, with a well-defined API for customization. Basically, you get a multi-window capable MDI-style application shell out of the box that leverages Spring's "lightweight container" for declarative configuration. In this respect, Spring Rich could be labeled a lighter weight "Eclipse RCP." Indeed, even our terminology is purposefully similiar (I think Eclipse RCP in general got it right.)

2. A command framework that builds on Swing's base action support, adding considerably more power and flexibility. Design roots orginiate from Andrew Pietchy's GUI Commands (also a java.net project!), and folks, he got the concepts right. I am particularly fond of this. I think this is one area where the JDNC community could really benefit from Andrew's and our work. Swing Actions, by themeselves, just can't compete with this.

3. A powerful data binding and validation framework, for auto-binding user input to backing domain objects. The validation API offers as-you-type results reporting against declarative rules associated with domain objects. A rich presentation model manages the enabled state of guarded GUI commands in response to validation events. Validation rules stay INDEPENDENT of presentation, so they can be reused between server-side and client side environments (this is key IMO.) Our support for javabeans-based binding is quite strong, with full support for for nested binding via dot notation and collections. Karsten and I have been working closely here.

4. Common support libraries addressing common rich client requirements, including well formed dialogs, wizards, form layout builders, preferences, i18n, image icon loading, progress monitoring, thread management (classes cleanly promoting responsive UIs), sortable tables, high-volume table updates, GUI standard enforcers, help/about, etc. This 4th point is where we look to integrate with a number of good solutions for components (JDNC/L2FProd/JIDE), threading (Spin/Foxtrot), and layout (JGoodies) into a cohesive platform. So, for example, our dialog/wizard abstractions DO NOT extend "JDialog" or "JPanel." They're control factories that produce and manage the underlying widgets, using them in best-practice fashion to accomplish typical dialog/wizard workflow. The widgets themselves are generally sourced from a centralized, pluggable component factory (making it really easy to plug in component libraries with little code change.) Our form builder abstractions make it easy to create _bound self-validating forms_ attached to backing form objects (usually domain objects) with very few lines of code!

Spring Rich, like the Spring Framework, is a layered framework--you may choose to use all of it, or only the parts you need in standalone library fashion. The whole concept of using a IoC container for centralized configuration and dependency management is another area I think the JDNC team could benefit. These "lightweight containers" are proving effective as the underpinning for a solid internal application architecture. The results from my teams engagements have been very positive--we've found IoC helps produce consistently higher-quality, easier testable and adapatable code.

---

Wooh! Long email there. Just wanted to share with you some of the things we're doing, and open the channel for communication & working together. I think some cross pollination and review of our overlapping feature sets would be a very good start!

Ultimately the reason I founded Spring Rich is I needed a platform for productivity for building Swing desktop applications faster (and got tired of watching companies throw tons of money investing in their own proprietary in-house frameworks.) Apparently a lot of other people do, too! At least three books I know of will be covering Spring Rich in some fashion, and we're not even to a 1.0 release yet (heck, we haven't even released!) Our forums at http://forum.springframework.com are active. As I'm sure you guys know, it's prime time for a desktop rejuvenation. I look forward to the chance to improve and compliment both of our efforts through working together!

Best regards,

Keith

http://www.springframework.org
http://forum.springframework.org

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

Hey Keith,

Glad to hear from you! Let me address some of the overlap here.

> 1. A set of abstractions managing the lifecycle and
> configuration of a desktop application. The
> framework provides a facility for managing multiple
> application windows, views, editors, and command
> bars, with a well-defined API for customization.
> Basically, you get a multi-window capable MDI-style
> e application shell out of the box that leverages
> Spring's "lightweight container" for declarative
> configuration. In this respect, Spring Rich could be
> labeled a lighter weight "Eclipse RCP." Indeed, even
> our terminology is purposefully similiar (I think
> Eclipse RCP in general got it right.)

This sounds like cool stuff. I don't know if you looked at the Netbeans framework? I haven't either, but it is another project who's real intent is what you describe. I assume your rcp framework is all plugin based?

>
> 2. A command framework that builds on Swing's base
> action support, adding considerably more power and
> flexibility. Design roots orginiate from Andrew
> Pietchy's GUI Commands (also a java.net project!),
> and folks, he got the concepts right. I am
> particularly fond of this. I think this is one area
> where the JDNC community could really benefit from
> Andrew's and our work. Swing Actions, by
> themeselves, just can't compete with this.

Ok, JDNC does have one of these, but honestly I don't know how progressed it is (Mark, Aim?). This looks like one area I'd like to know more about in the future. Are you simply including a jar of Andrew's project, or is he cutting source into your project now, or are you using his work with modifications?

>
> 3. A powerful data binding and validation framework,
> for auto-binding user input to backing domain
> objects. The validation API offers as-you-type
> results reporting against declarative rules
> associated with domain objects. A rich presentation
> model manages the enabled state of guarded GUI
> commands in response to validation events.
> Validation rules stay INDEPENDENT of presentation,
> , so they can be reused between server-side and
> client side environments (this is key IMO.) Our
> support for javabeans-based binding is quite strong,
> with full support for for nested binding via dot
> notation and collections. Karsten and I have been
> working closely here.

Our Binding API has also been influence by Karstens work, though it is still in flux at the moment. Kleopatra is working on the Binding portion for JDNC and is well aquanted with Karsten's work as well. It might be cool if you and her had a conversation on some thread. I mean, if Spring and JDNC used the same binding API --- talk about interoperability.

Are you guys binding mostly to java beans then? What about RowSets/ResultSets?

JDNC has spent a lot of time on the back end data-modeling infrastructure (including a DataSource
API supporting JDBC, EJB, webservices, custom designs, etc). I'd be really interested to see what data structures Spring Rich has that corrospond. This is one part of JDNC that I think really differentiates the project, at least from any other's whos source I've read. The JDNC data modeling code allows developers to use whatever data structures they want with a DataModel acting as a wrapper around those data structures (be they RowSets or Collections or a single bean, etc).

>
> 4. Common support libraries addressing common rich
> client requirements, including well formed dialogs,
> wizards, form layout builders, preferences, i18n,
> image icon loading, progress monitoring, thread
> management (classes cleanly promoting responsive
> UIs), sortable tables, high-volume table updates, GUI
> standard enforcers, help/about, etc. This 4th point
> is where we look to integrate with a number of good
> solutions for components (JDNC/L2FProd/JIDE),
> threading (Spin/Foxtrot), and layout (JGoodies) into
> a cohesive platform. So, for example, our
> dialog/wizard abstractions DO NOT extend "JDialog" or
> "JPanel." They're control factories that produce and
> manage the underlying widgets, using them in
> best-practice fashion to accomplish typical
> dialog/wizard workflow. The widgets themselves are
> generally sourced from a centralized, pluggable
> component factory (making it really easy to plug in
> component libraries with little code change.) Our
> form builder abstractions make it easy to create
> _bound self-validating forms_ attached to backing
> form objects (usually domain objects) with very few
> lines of code!

Are your API's designed for building gui's by hand, or by visual gui builder? I know Karsten has some really cool stuff for building with non-visual gui builders.

Thanks,
Richard

Message was edited by: rbair. Didn't particular like my wording...

jtr
Offline
Joined: 2003-06-10
Points: 0

A couple questions about layout:

1)I don't see a mention of layouts except in relation to JXForm. Is it outside the scope of JDNC to include a powerful but easy to use layout manager? (I'm thinking of something like FormLayout or TableLayout.)

2) I suppose if the JXForm allows overriding/composition of the UI construction and placement in bind() then other layouts might not be required. Will that be the case?

In particular, I'm thinking of the case where I want to have some control over the alignment, spacing, etc... of the UI controls that are created as a result of a bind(). For instance, I like how some layout managers horizontally alig the label and text field and would want that in a JXForm. Or, I might want label fields aligned on the left instead of on the right, centered, or whatever. For whatever the reason, I might not want to use default JXForm layout and specify my own instead.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> A couple questions about layout:
>
> 1)I don't see a mention of layouts except in relation to JXForm. Is it outside the scope of JDNC to include a powerful but easy to use layout manager? (I'm thinking of something like FormLayout or TableLayout.)

Funny you mention this. We have a project independent of JDNC that is trying to
address the layout burden with an emphasis on using a tools-approach.
This and other swing projects are leading us to think about how we might
restructure the java.net JDNC project to make it easier to include
additional, smaller projects which arn't tied directly to JDNC. I will
send out a proposal on this shortly.

Aim

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

jtr
Offline
Joined: 2003-06-10
Points: 0

> address the layout burden with an emphasis on using a
> tools-approach.

I'm not against tools (some of my best friends are tools), but I thought SpringLayout was the answer for a tools based layout? After seeing the SpringLayout demo at JavaOne a few years ago, I had great hopes for it. But now it's been out for a few years and I don't know of any tool providers which have picked it up (not even NetBeans). And manually writing SpringLayout code makes me pine for XmForm in X/Motif :).

Toolablity with XML would be nice though, especially if it is as easy to work with as jdnc's XML.

Anyway, I'll be looking forward to anything that comes down the 'pike, especially if it is as easy to use and functional as FormLayout. Toolablity is a nice extra for me.

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

Amy,

The roadmap is an excellent piece of work. I think all these pieces are extremely important. I wish we could have them today.

You may want to mention the messaging bus feature - which could be an extention of the Message/ProgressListener mechanism. A message bus is a module which acts a "central nervous system" for an application. Disparate event listeners and loggers could post messages on the bus. Bus listeners could extract or filter the information past on the bus and present it in UI like modal dialogs (yuck), message popups, status bars or loggers.

Other than that, I see that most of the important features have been called out.

I'm glad to see that a realistic schedule has been outlined to a 1.0 release. Some may feel this is

One minor nit: All the links in the Milestones/Schedule section are hard coded to point to the document on your web server. You may want to use the relative link anchor tags (for example, #login) instead.

Once again, excellent work!

--Mark

mgrev
Offline
Joined: 2003-08-12
Points: 0

Aim,
Thanks for sharing the information.

It seems that there are more sharing and interacting with the community happening nowadays, is that intentional or just a fluctuation in the Space-Time Continuum? Or have you (Sun) just pink-slipped a couple of them lawyers? ;)

Cheers,
Mikael Grev
grev >at< javalobby.org

dnautiyal
Offline
Joined: 2003-10-27
Points: 0

I think one-year wait for Version-1.0 will disappoint many java developers who had placed a lot's of hopes on jdnc project. In the interim, I do hope that jdnc-team will continue to aggressively fix bugs reported against their existing codebase.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> I think one-year wait for Version-1.0 will disappoint many java developers who had placed a lot's of hopes on jdnc project. In the interim, I do hope that jdnc-team will continue to aggressively fix bugs reported against their existing codebase.

Isn't this always the truth. But there's a lot of work to do and we want
ample time to get the APIs right before we cast a "1.0". Originally we wanted
to be to 1.0 by JavaOne'05, but when we looked at the work remaining it just didn't
seem realistic. But clearly the schedule isn't final, so we can discuss whether
it would be worthwhile to cut functionality to bring in the 1.0 date. Do others
have an opinion?

Aim

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

Anonymous

The great question of all time! Functionality or earlier release... I guess that it depends on the project. As for JDNC I would say that functionality shouldn't be cut. It's going to useable before the 1.0 release, granted a lot of it can change between now and then. I don't see changes being that hard to cope with though. But that's just my opinion based on the project I'm working on.

Gianni

Duncan McGregor

First can I say thanks for JDNC, even in these early releases swingx is making
my development life a lot easier.

In this spirit can I offer a criticism. I'm currently using a lot of sorting and
filtering tables, and looking at the code it is crying out for Null Object
pattern. JXTable is crammed full of code like

if (filters != null) {
filters.flush();
}
else if (sorter != null) {
sorter.refresh();
}

Null implementations of Filter and Sorter would clean up large chunks of this
code, as well as simplifying the testing.

Just my 2 pence worth. Now if only there was a NullSecurityManager...

Duncan McGregor
www.oneeyedmen.com

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

Duncan McGregor

Hi again

How do I remove a filter pipeline from JXTable?

At present the simplest way I can find is

public void clearFilter() {
storeTable.setFilters(
new FilterPipeline(
new Filter[] {
new PatternFilter(
".*",
Pattern.CASE_INSENSITIVE,
ProductTableModel.DESCRIPTION_COLUMN)

}));

Thanks in anticipation

Duncan McGregor

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

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

> Hi again
>
> How do I remove a filter pipeline from JXTable?
>
> At present the simplest way I can find is
>
> public void clearFilter() {
> storeTable.setFilters(
> new FilterPipeline(
> new Filter[] {
> new PatternFilter(
> ".*",
> Pattern.CASE_INSENSITIVE,
>
>
>
>
>
>
>
>
> ProductTableModel.DESCRIPTION_COLUMN)
>
> }));
>
>
> Thanks in anticipation
>
> Duncan McGregor

Duncan,

Simply calling myTable.setFilters(null) should work. Let me know if it doesn't.

Ramesh

Duncan McGregor

>Simply calling myTable.setFilters(null) should work. Let me know if it doesn't.

Well...

public void setFilters(FilterPipeline pipeline) {
filters = pipeline;
use(filters);
}

calls

private void use(FilterPipeline pipeline) {
if (pipeline != null) {
pipeline.addPipelineListener(this);
pipeline.assign(getComponentAdapter());
pipeline.flush();
}
}

but pipeline is null, so nothing is flushed.

Thanks for taking the time

Duncan

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

bino_george
Offline
Joined: 2003-06-16
Points: 0

Hi Duncan,
You might have spotted the problem. I tried
calling setFilters(null) and it does not quite work. It
leaves empty rows. Can you please file a bug ?

Thanks,
Bino.

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

Excelent.

I think geting the "Swing"/non XML should be first. Once that works it be easier to get the XML and not go back and forth.

I think form defintion and data should be 2 diferent xml files.

I do not think that RowSet is a big deal for binding, realtive to collections.

I know this will be a big sucess!
.V

siva
Offline
Joined: 2003-07-15
Points: 0

Looks like the link to Milestones/Schedule is broken.