Tim Lovern

Thanks, I knew it had to be something as simple as that.

I have an app that displays database metadata using a JTable on a scroll panel. The form was designed using netbeans ide.
In the forms designer, I can set a column property to be boolean. So far, so good.
However, when I go to load the table, using the following code snippet, it won't compile:
table.setValueAt(metaData.isIncluded(), iLoop, 2);
iLoop is the row within the table and corresponds to the entry of the data in an ArrayList.
Can't pass a boolean in the setter. Hmm, but I can declare the column to be a boolean during design.
Any help would be very much appreciated.
thanks in advance!

Ok, let me try this:
Since the order detail data can stand alone. i.e. certain analysis, etc, does not require that we even look at header data. So there is a VO that represents a detail line.
Likewise, there is certain processing that only involves header data. There is a VO that represents a header record.
Since a header is a unique entity and does correlate to a object in the database, it is in a VO.
A detail line is a unique entity and also correlates to an object in the database.
However, the concept of invoice, or sales order is expressed as a relationship between objects.
In fact, a sales order is conceptually nothing more than a container with an explicit hierarchy.
This hierarcy is based upon business rules. (which of course are subject to change)
I think I've answered my own question. There will be an invoice object that will enforce the relationship between all the VO's that comprise a sales order. It won't necessarily be a VO, and it will definately live at the business layer. It can be used to comunicate with the presentation (client) layer.
I'll probably implement as an interface, with a factory to instantiate to isolate the invoice from changes in requirements. (also allows for credits, transfers, local buys, etc.)
This is called collaboration with remote participants.
Thanks!

Sun provides a free IDE, as does NETBEANS.ORG.
I use the SUN IDE on my windows boxes and the NETBEANS IDE on my MAC. (Asthetically, they are identical, which is why I use them.)
They both work great, have syntax highlighting, will generate some code for you. Like if you specifiy that a module implements an interface, the IDE will put in a template for the methods the interface requires.
As you type in method names, the argument lists will be displayed, illegal syntax is highlighted, etc.
Hoep this was helpful.

I am trying to understand, or at least gain some insight, on when to use properties and when to use preferences.
I'm drawn to the fact that preferences is set up to use XML. Plus the backing store can be LDAP, or whatever.
However, it seems that it is more complex to set up and there are more things to code for than using properties.
Does anyone have any insight, or experiences with both that they are willing to share?
We need to determine what the standard will be within our organization. (I'm involved in the first JAVA project for our company.) The decisions I make now will impact future development, so I'd like to get it reasonbly right so that we won't refactor it into a completely different design when all is said and done.
Thanks in advance!
Tim.

There may be Value objects that the business layer uses to communicate with the presentation layer. These may or may not be passed on from the data layer. We are considering a category of VO's that are only used between the business layer and the presentation layer to be called Transfer Objects to distinguish them from traditional VO's.
(The business layer does not know what the presentation layer, or client is. It could be a web page, a web service, an XML document, or even another application.)
In the example of an invoice, since each detail line of the invoice is itself a VO, and can be manipulated independantly of the header data (and in many instances are, for example totaling an order does not require the header at all.)
Since header data can stand alone, and detail data can also stand alone, they are each represented by VO's. I guess it would make sense to have an invoice VO that would model the relationship between them, with an embedded header VO and a container with all the detail VO's
The difficulty (at least conceptually) is that modeling the order structure within a VO seems to violate the purity of the object. We only allow getters, setters, and a to string method in a VO.
As far as the relationship between a head and detail being business logic, while it is somewhat subjective, it really is a business model that drives this relationship.
I have worked with transactional systems that were designed such that an 'order' was a single record in which the header and detail information were together.
This system only allowed a single item on a transaction. In this case the business logic dictated a single object per order, whereas our business logic dictates multiple objects per order in an hierarchy.
In fact, if you really want to get a feel for the relationship, here's a quick overview (still omitting some information for clarity):
* Order header (1 per order)
* Order detail (1..N per order)
* inventory allocation (1..N per detail)
* Allocation packaging (1..N per alloc)
* Order total (1 per order)
* Order Packaging (crosses multiple orders & details)
It gets complex fairly quickly.
Hopefully this helps to understand where I am coming from.

I originally posted this in the Intemeadiate JAVA forum, but it was suggested I post this here.
One of the goals in our designs has been separation of data layer, business layer, and presentation layer.
We have Data Access Objects (DAO's) to access data stores (we don't care if the data comes from a relational database, an XML document, flat file, whatever).
Value Objects (VO's) are used to hold the data. Conceptually, they represent a single row from a query and are created and set by DAO's.
Other than the Setters and Getters, the VO's do not contain any business logic, nor do they have any Data access logic in them.
All of this has been presented as back ground into my real question (finally).
Where would (should?) one model relationships between VO's? I think this is really business logic, but could be persuaded (reluctantly) to do this at the VO level.
For example, if you have a sales order. Conceptually, an order consists of header information (Customer ID, shipping info, etc.) and a number of detail rows, one for each item purchased. This is a very basic one to many relationship.
Where is this relationship expressed in code? The sales order could have come from a relational database, an XML document, a flat file, a spreadsheet, etc. Plus we do not want an implementation that relies on a specific data access technology or data source.
One approach would be to embedd a container object in the header VO and then load it with references to the detail VO's, and have a reference on the detail VO's that point to the header.
Another would be to have some sort of relationship object (RO?) that would perform and manage the mapping functions to express the relationship.
There are other approaches that likewise could be used.
I guess I am trying to see how others handle this and what some of the options are. I have not found anything in any of the patterns books that covers this.
Thanks in advance!

The concept we use is pretty straight forward. The row from the database would be represented in a Value Object (VO)
The data access would be handled by a Data Access Object (DAO).
The DAO would be aware of the VO, but not vice versa. The DO is basically all the columns from the query with a getter and setter method for each.
If you are using SUN's free IDE, it will generate the getters and setters for you automatically.
Right click on a variable, select tools, then select generate R/W property for field.
It will generate a getter and a setter method for the field.
If you need to return more than one row from a database, have the DAO return a collection of VO's.
Again, this keeps the separation of the data from the data source. You could simply write a new DAO for XML documents, and your application would not break.
Also, abstract your DAO's one layer by coding to an interface. Use the interface in your programs, not the actual DAO object. Then it is a no brainer to change implementations. Just use a factory to return an instance of the DAO (interface).
just a thought.
hope this was helpful...

One of the goals in our designs has been separation of data layer, business layer, and presentation layer.
We have Data Access Objects (DAO's) to access data stores (we don't care if the data comes from a relational database, an XML document, flat file, whatever).
Value Objects (VO's) are used to hold the data. Conceptually, they represent a single row from a query and are created and set by DAO's.
Other than the Setters and Getters, the VO's do not contain any business logic, nor do they have any Data access logic in them.
All of this has been presented as back ground into my real question (finally).
Where would (should?) one model relationships between VO's? I think this is really business logic, but could be persuaded (reluctantly) to do this at the VO level.
For example, if you have a sales order. Conceptually, an order consists of header information (Customer ID, shipping info, etc.) and a number of detail rows, one for each item purchased. This is a very basic one to many relationship.
Where is this relationship expressed in code? The sales order could have come from a relational database, an XML document, a flat file, a spreadsheet, etc. Plus we do not want an implementation that relies on a specific data access technology or data source.
One approach would be to embedd a container object in the header VO and then load it with references to the detail VO's, and have a reference on the detail VO's that point to the header.
Another would be to have some sort of relationship object (RO?) that would perform and manage the mapping functions to express the relationship.
There are other approaches that likewise could be used.
I guess I am trying to see how others handle this and what some of the options are. I have not found anything in any of the patterns books that covers this.
Thanks in advance!

Very helpful, thanks! I'll need to chew on this a while and apply it to my situation. At a glance, looks like the concept is what I need.

Are there any published patterns for data filtering?
What I need is a way to provide a generic filtering mechanism that can be applied to Value Objects.
A user could fill in a table on a form with selection criteria for selecting sales orders, for example.
In the simplest case, this information could be used to generate a query. However, because of the complexity of our environment, the simplest case is rare.
What would happen, is that some of the criteria entered can be used to generate the query. Other aspects would need to be applied to the returned data Value Objects to filter the data. (Value Objects VO's are used to isolate the business layer from the database layer)
one thought is a filter interface with some sort of factory object supplying to needed filters to the application.
The underlying goal, is to have a generic way of doing this so that we don't have to re-invent the wheel for each application that requires the ability to do filtering of data. We also want to make sure that whatever we doesn't require the users to know the underlying structure of the data either.
Hope this made sense, and if so any ideas???