Skip to main content

[DRY] (Table)Binding

10 replies [Last post]
Anonymous

Same question for TableBinding.

Why do we have this constructor?

public TableBinding(JTable component,
DataModel dataModel,
String[] fieldNames)

Wouldn't this suffice?

public TableBinding(JTable component,
DataModel dataModel)

This is true for other Binding classes as well, like the Text one.
Maybe the DataModel does not have enough information?

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

Reply viewing options

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

Vic

jdnc-interest@javadesktop.org wrote:
> I just want to underline that using RowSet to talk to DaO or SoA is a bad practice.
>
> I use JDNC w/ out RowSet.

No argument with that on my part. My point would be that the
client-server architecture, from rich-client direct to database, is
still in use for small applications. I havent done much of that in
paying work for awhile, but when I help small groups (like nonprofits)
out, that is often their preferred alternative. It is incredibly easy to
set up an easy-to-use networked database with FileMaker or Access; I
would just like to see JDNC help on that end as well.

Regards
Patrick

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

kleopatra
Offline
Joined: 2003-06-11

Hi Richard,

>
> Well, you know my views ;).

> Actually, in this case I
> have to disagree with using MetaData to describe
> which columns to show, and which to hide. I could
> very easily have two different tables linked to the
> same DataModel, and only wanting to show a different
> subset of columns in each table.

I think that's just a matter of perspective - we can easily have the same underlying model in two different fields with different metaData attached to it. These metaData can carry additional rendering hints (like the label to use for the bound table), constraints (display-only) or whatever.

> I'd prefer to leave
> this up to the developer -- show all of the columns
> by default, but if they want to override which
> columns are visible then they should be able to do
> that on the Binding level as opposed to the DataModel
> level.
>

I agree that the developer should have fine-grained access to building a form, but most of the time even then her partner is not the Binding: they should be auto-created either by the form or by the FormFactory.

>
> Again, this sounds like a good idea from the
> perspective of an auto-layout engine, but for
> useability it seems like a pain.

we are not (yet) talking about layout :-) That's just one aspect of the "dumping" triade - besides auto-binding and auto-wrapping of simple datastructure (like simple lists of beans or tabular data). And they are designed to be decoupled from each other.

> If I want complete
> control over how things are done, I'd prefer to do it
> on the component, or at least on the binding, rather
> than having to declare it in the MetaData.
>

Anyway, I'm a control freak myself :-) We probably end up needing both.

> making my job harder. I fear putting too much in the
> MetaData for this very cause. I'd prefer a simple
> MetaData that can be used to generate simple forms,
> and then get out of the programmers way and let them
> do as they please.
>

Agreed - I'm also weary about the MetaData being/growing fat. On the surface they are a simple collection of properties without any behaviour beyond change notification. Under the hood they have their tentacles everywhere - from steering component creation, carrying rendering hints to presentation logic, even expanding a bit into the "data" like. Sooner or later we'll have to do something about it - but for the time being I'd prefer to go with it and refactor later.

> Looks like the beginning of another long thread :)
>

I love it ;-)

Jeanette

Anonymous

Hey all,
From what I know of Datamodels the reason to have the constructor with the String[] parameter is (as far as tables go) is to allow only certain fields to be displayed and allow the others to be 'invisible' as far as the table is concerned, without having to create a new DataModel with a new MetaData set.

Though as you said perhaps the datamodel (or metadata) doens't have enough information, and I could see that as another possible way of allowing certain fields to be displayed and others not.

As for my project, this functionality is needed and very useful, though for other projects I could see how it is not as used.

Well, that's what I think
Gianni

kleopatra
Offline
Joined: 2003-06-11

>
> Though as you said perhaps the datamodel (or
> metadata) doens't have enough information, and I
> could see that as another possible way of allowing
> certain fields to be displayed and others not.
>

One aspect to consider carefully: MetaData are associated with _fields_ of a DataModel not with the DataModel itself. So currently there is no direct way to express something like "use only a subset of the fields" (which I would regard as a kind MetaData for a certain view of an underlying DataModel). The indirect way (as I tried to explain in my earlier answer, obviously not very clearly :-) is to push a DataModel as a value into another DataModel and then declare MetaData for that field.

One basic idea (at least from my ui-biased perspective :) was to somehow construct a graph of DataModels with carefully declared MetaData and then dump that into the ui-realm which takes care of creating ui-components and bind them to the appropriate field in the models. The MetaData-graph plays a major role in this because it defines the (component) structure to be built. "holes" in the graph short-circuit any automatics.

Jeanette

rbair
Offline
Joined: 2003-07-08

> >
> > Though as you said perhaps the datamodel (or
> > metadata) doens't have enough information, and I
> > could see that as another possible way of allowing
> > certain fields to be displayed and others not.
> >
>
> One aspect to consider carefully: MetaData are
> associated with _fields_ of a DataModel not with the
> DataModel itself. So currently there is no direct way
> to express something like "use only a subset of the
> fields" (which I would regard as a kind MetaData for
> a certain view of an underlying DataModel). The
> indirect way (as I tried to explain in my earlier
> answer, obviously not very clearly :-) is to push a
> DataModel as a value into another DataModel and then
> declare MetaData for that field.

Well, you know my views ;). Actually, in this case I have to disagree with using MetaData to describe which columns to show, and which to hide. I could very easily have two different tables linked to the same DataModel, and only wanting to show a different subset of columns in each table. I'd prefer to leave this up to the developer -- show all of the columns by default, but if they want to override which columns are visible then they should be able to do that on the Binding level as opposed to the DataModel level.

> One basic idea (at least from my ui-biased
> perspective :) was to somehow construct a graph of
> DataModels with carefully declared MetaData and then
> dump that into the ui-realm which takes care of
> creating ui-components and bind them to the
> appropriate field in the models. The MetaData-graph
> plays a major role in this because it defines the
> (component) structure to be built. "holes" in the
> graph short-circuit any automatics.

Again, this sounds like a good idea from the perspective of an auto-layout engine, but for useability it seems like a pain. If I want complete control over how things are done, I'd prefer to do it on the component, or at least on the binding, rather than having to declare it in the MetaData.

Yesterday and today I've been trying to get JBoss/PostgreSQL and the PetStore demo working together, and its been a royal pain in the neck. Why? Because J2EE requires you to declare everything in configuration files, and then it does all of this magic behind the scenes. For complex deployments that may be really cool, but for a lowly app developer all of this declarative stuff is just an extra layer making my job harder. I fear putting too much in the MetaData for this very cause. I'd prefer a simple MetaData that can be used to generate simple forms, and then get out of the programmers way and let them do as they please.

Looks like the beginning of another long thread :)

Richard

Patrick Wright

> Well, you know my views ;). Actually, in this case I have to disagree with using MetaData to describe which columns to show, and which to hide. I could very easily have two different tables linked to the same DataModel, and only wanting to show a different subset of columns in each table. I'd prefer to leave this up to the developer -- show all of the columns by default, but if they want to override which columns are visible then they should be able to do that on the Binding level as opposed to the DataModel level.

I agree. If you are working with a direct SQL result set, which is nice
for small local apps, the DataModel and MetaData can represent the
query, mapped to a table, which may be modified by one or more forms
showing different columns. Editing the forms can push to the same DM,
and thus have one mapping back to the database for storage. The MetaData
is nice in that you could pick and choose what to show on the tables or
forms dynamically. That way the same query and database key mapping,
code to insert/update/delete can be used against a single DM...

Patrick

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

netsql
Offline
Joined: 2004-03-07

I just want to underline that using RowSet to talk to DaO or SoA is a bad practice.

I use JDNC w/ out RowSet.
.V

rbair
Offline
Joined: 2003-07-08

Hey,

RowSet is especially useful for direct-database kinds of applications, so it needs to be supported. ResultSet supports basic functionality, RowSet extends ResultSet and adds the ability to create the sql statements necessary for insert, update, and deletes.

Whether you want to use it for soa or not is really up to you, but RowSets will play a crucial role is simpler direct-database kinds of apps.

Richard

Kleopatra

Hi Nicola,

that's a hot discussion between Richard and me :-)

>
> Why do we have this constructor?
>
> public TableBinding(JTable component,
> DataModel dataModel,
> String[] fieldNames)
>
> Wouldn't this suffice?
>
> public TableBinding(JTable component,
> DataModel dataModel)
>
> This is true for other Binding classes as well, like the Text one.

Not exactly - currently Binding is designed to work with a field of
DataModel, not the model itself.

"Class which binds a user-interface component to a specific element in a
data model."

And that's what the other binding implementations adhere to. To strictly
play by the rules, we'll have to expose the DataModel which should be
bound to a JTable as a field of a DataModel.

That may sound strange but has advantages:

- the current setup of collaborators: A Form is the "natural" client of
a DataModel, a Binding is the "natural" client of a field of a
DataModel. That maps smoothly to a container hierarchy and allows to
auto-build/layout/bind model graphs into potentially nested views.

- a field of a DataModel has associated MetaData. That's the place to
add presentation details like the fieldnames in the first constructor
(the intention there is to only show a subset of all columns), a
display-only property, a title ... whatever

So my side on this is to go with the current setup as long as it
carries, and change if we'll hit a wall.

On the other hand: we are right in the middle of the "rawest" jdnc
sections - so changes are in the air :-)

Jeanette

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

Nicola Ken Barozzi

Kleopatra wrote:
> Hi Nicola,

Hi! :-)

> that's a hot discussion between Richard and me :-)

:-D

...
> So my side on this is to go with the current setup as long as it
> carries, and change if we'll hit a wall.

Understood.

> On the other hand: we are right in the middle of the "rawest" jdnc
> sections - so changes are in the air :-)

No problem, it's all very 'cool'. ;-)

I had made my own swing extensions library, and am happy to be able to
see -finally- a common place where swing devs can collaborate on it.
I'm sending now the email for participating in the incubator, I can't
wait :-)

--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------

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