[newbie] DataSources and their relationships with DataBoundComponents

[bbruyn]

Currently evaluating SmartGWT client and server packages. I've been over the Quick Start and many of the samples (300 is a lot to look at) in the showcase, and thought I had a handle on DataSources and their relationships with DataBoundComponents. Turns out, I must have missed something(s) along the way. Apologies in advance for what I'm sure are all stupid questions.

Let's suppose the Animals datasource in the BuiltInDS example has 100 fields in it instead of 7. I want to display 5 of them in my listGrid, and maybe 30 in my edit form. I thought the easy way to do that might be with an operationBinding(s) on the datasource, where I'd set 'outputs' equal to the fields in question. What I thought that would do is influence the columns in my grid for me, but what I think I see is that this only affects the data returned from the fetch. Fair enough, if that's all it's supposed to do, but can someone verify that?

So I guess what I'd do now (for e.g., the grid) is declare 5 ListGridFields explicitly and drop them on the grid. Not difficult, but now I'm not sure I see the point of 'outputs', unless it was just to restrict the amount of data coming across the wire... Do I have that right?

So I'll define those ListGridFields like I see it in nearly every sample

/* my db column names are really ugly and mostly unsuitable for titles */
ListGridField commonName = new ListGridField("foo_co_nm");

But now SmartGWT thinks I'm trying to override "foo_co_nm", if I have that right, and that's not what I want. I don't want to have to redefine the title, for example - it's already on the ds definition. All I want is to refer to the field already defined on the datasource, so I can say for example 'show only these 5 fields out of the 100 defined', or 'put these 15 fields on tab 1, another 15 on tab 2, and ignore the other 70.' Surely I'm missing some fundamental concept here, and I'm quite happy to have another look at a sample or documentation if someone can point me in the right direction.

Many thanks in advance.


Bill

[davidj6]

You are doing it exactly right. When you define the ListGridField with the name matching a field in the DS, all the properties from the DS are merged with any in your LGF allowing overrides if desired. Your title from the DS will be retained if you don't change it in the LGF. Same concept applies for DynamicForms.

The outputs allows you to restrict the data say for a drop down selection that shares the DS but only needs to show a few columns but many rows.

[bbruyn]

Your title from the DS will be retained if you don't change it in the LGF.

Funny, that's not what I'm seeing at all. When I define

<field name="JOB_REQ_UK" [b]title="Job ID"[/b] type="number" primaryKey="true"/>
<field name="JOB_REQ_TYPE_UK" [b]title="Job Type"[/b] type="number">

And construct my grid like so

ListGrid results = new ListGrid();
results.setAutoFetchData(true);
results.setDataSource(DataSource.get("WorkOrder"));
ListGridField jobId = new ListGridField("JOB_REQ_UK");
ListGridField jobType = new ListGridField("JOB_REQ_TYPE_UK");
results.setFields(jobId, jobType);

What I see on my grid column titles are Job Req Uk and Job Req Type Uk.

i.e., it looks from here like I have to use the (String name, String title) constructor to avoid the derived title. In real life I'd probably use the i18n mechanism anyway, but I can't get past what I think is some misunderstanding of my own.

(SmartGwt EE eval v 2.4)

[bbruyn]

Well, there you go. Turns out I had duplicate field definitions in the datasource produced by the generator. It would have been nice if (a) the generator hadn't done that, and (b) there was some constraint on the datasource itself to prevent that (or warn me at load), but I'm happy to know that it all does seem to work they way I thought it did. :-)

Again, apologies for the stupid questions.

[Isomorphic]

What generator? Be sure you're using either schemaBean or autoDeriveSchema as covered in the intro of the QuickStart Guide chapter on the Server Framework. Then there's never going to be additional fields unless you get the names wrong.

[bbruyn]

Well, I generated an xml sqlDataSource using the tool at com.smartgwtee.tools.client.SCEE.openDataSourceGenerator();

Looking at the other datasources I had it build, they all turned out with duplicated field definitions. e.g.,

<fields>
<field name="APPROVAL_STATUS_UK" type="number"></field>
<field name="DESCRIPTION" length="50" type="text"></field>
<!-- and so on -->
<field name="APPROVAL_STATUS_UK" type="number"></field>
<field name="DESCRIPTION" length="50" type="text"></field>
<!-- and so on -->

If you're interested, I can go back and figure out what happened. I have an idea, but I'd need to go and prove it.

[Isomorphic]

We'd be interested in finding out how you got this result (if it's a bug). However, be sure to read the indicated portion of the QuickStart Guide. Right now you're headed down a path intended for people with a large number of highly consistent pre-existing entities (eg more than a dozen).

[bbruyn]

be sure to read the indicated portion of the QuickStart Guide. Right now you're headed down a path intended for people with a large number of highly consistent pre-existing entities (eg more than a dozen).

Did that 2 or 3 times, actually. I must have missed something though, because I don't know what you mean by 'highly consistent'. Static, Stable? If you don't mind, could you please explain in what way I might be headed down the wrong path?

I do have loads and loads (waaaay more than a dozen) of pre-existing entities, and most of the columns in each of them are going to need some sort of customization via xml...

Appreciate the help, and I'm so far digging both client and server frameworks.

[Isomorphic]

There are two styles:

1. schemaBean/autoDeriveSchema requires manual creation of one .ds.xml file per entity but auto-derives all fields on the fly, such that you only specify overrides. If new fields are introduced in source schemaBean or SQL table, they magically appear in bound grids and forms etc with no effort on your part.

2. DataSource generators can generate .ds.xml files for a large number of entities in one go, and with the Batch DataSource Generator, you can affect how generation is done, so you can, for example, introduce rules that rely on naming conventions or Java annotations to automatically put properties like foreignKey or displayField on generated DataSourceFields. Using this style, ideally you enhance the Generator until you have no need to make further customizations to the output .ds.xml files, so you are free to re-run the generator at any time if the underlying entities change - you can just wipe out the old files because you've never customized them.

[bbruyn]

Don't remember reading about the generation rules, so thanks for the tip. Is there somewhere I can go to read more about that in particular? I've been over the quick start and the javadoc linked to from there...

[Isomorphic]

These aren't rules, they are approaches for minimizing duplication and maximizing agility as the data definition changes.

The very beginning of the Server Framework chapter in the QuickStart Guide explains why you do this and how the generation works, and links to deeper documentation.

[bbruyn]

Got that, thanks. I was referring to the 'rules' you alluded to in style #2

"you can, for example, introduce rules that rely on naming conventions or Java annotations to automatically put properties like foreignKey or displayField on generated DataSourceFields."

The quick start guide reads, "Provides customization hooks so that you can easily use organization-specific naming patterns, Java annotations, or other available hints to generate richer DataSource definitions and avoid hand-coding"

But neither it nor the javadoc I've seen describes what I should do to plug in to those hooks... Apologies if it should be obvious - I am looking in the doc (I've read the QuickStart guide cover to cover once and piecemeal any number of times after) but just don't see where that's documented.

[Isomorphic]

Go to the Batch DataSource generous itself - there are no rules, the customization hook is your ability to edit the generator itself (the .jsp file it submits to has extensive comments and code samples).