The BOs are defined.  Relations exist.  The user wants a form that simply displays data from the BOs.  For example:

Work Order BO
workorderindex (pk)
workorderid
partindex (fk)

Parts BO
partindex (pk)
partnum
unitindex (fk)

Units BO
unitindex (pk)
unitdesc

The grid will display workorderid, partnum, unitdesc.  With only the BOs, their corresponding BBSs and a DevEx Grid, can this be done?  If so, how?

I can easily get the Work Order BO and the Parts BO to display everything I need (employing the appropriate repository controls in the grid).  The Units BO is the kicker.

Hoping someone in the SF community will have run into this issue and will be able to shine some light on this.  Please note that I do not want to resort to SQL script here.  I can certainly create a data query and pass the results to the grid and bypass the BOs altogether.  That is not what I want to do.  I have some custom properties that are showing up in the grid from the Work Order BO that I must have.  These will be lost if I bypass the BOs.

Thanks,
Bill

Hi Bill,

Yes, I see now. Personally I would just create a view (and replicate your custom fields in the view) that brings everything together however I'm pretty sure you will see examples of bringing BO's together in this fashion for reporting. Try a forum search on reporting, especially SharpShooter examples.

Cheers, Peter

If I create a view (which is what I have always done up to this point...again, I am exploring the business object capabilities), then I also have to create a corresponding BO.  This new BO would easily populate the grid that I want.  I'll grant that option.  It is what I will be doing if no other clever solution comes my way.

I'd really like to take existing BOs that can be related to one another and display the flattened view of the data, including any custom properties of any of the BOs.  Perhaps this is simply not possible.  I am probably attempting something that the framework is not intended to do.

Actually this isn't far off.  There are a couple of things that you may want to consider.  First, I more than likely would not be trying to put all 3 tables inside of one grid unless they are all one-to-one relationships.  Otherwise this would get really messy.  In this case though, you would just want to create an updatable view which pulls this back and would then allow a record set to be updated going back the other way. 

What you are trying to accomplish is not outside of the scope of the framework and can be done, but the reason that you have received some of the comments suggesting other mechanisms is because a grid gets really messy when trying to cram all of this into one locale.  If this were read-only then it wouldn't be as big of a deal.  But in any case, just create an updatable view, then all of your BOs, custom properties, etc. will all work.  You can then create a new Custom BBS through the templates which will just side step the need to drop on a separate BBS on the form (same approach that is used for reporting).

Note: When creating updatable views, you must still specify a primary key field.  To do this, open up the BO Mapper, right-click the BO in question, then open the advanced section.  Then override the PK field and specify a PK so that the updates will work properly.

Sorry.  My communication skills do lack.  Getting what is in my brain onto paper has always been difficult.  I apologize in advance if I sound like I am repeating myself.

The grid is going to be read-only.  The user just wants to view the data (and I may whip out a report or two from the grid).  I am trying to get fields from three tables into one table-like presentation to the user.  Since the three BOs already exist, I was hoping to utilize some functionality there.  Since relations exist, couldn't I somehow derive a table from the three BOs and throw that into the grid?

Just exploring.

Dustin,

Much appreciated response!  I do not want to "complicate" things by adding custom properties to the first BO which reflect the already existing properties of the second and third BO.  I think that I may be trying to do something with business objects that they were not intended to do.  In other words, I cannot "query" (derive a table from) the business objects...I need to go back to the source DB for that.

Bill

Bill,



OK, so the BBS needs to have a strong typed property to work...didn't know that.



However, you might want to consider a ListView instead, since the data is readonly. In this case, you don't need strong typed properties, just columns in the underlying data table (they must be aliased in SQL though). You might have set up the population setting via code, but it works...I'm using heavily in a custom search form I use. In my case, I'm allowing the user to search on not just the base table, but also on values in a parent table and/or other FK tables. E.g. in your case, this would allow the user to search on unit description to retrieve a work order. I build the list view based on columns in the data table. You just need to alias all the columns in SQL. I don't think you can set this up via the designer, as it will only show you the strongly typed properties.



Of course, if you need to pump out reports, then you may be back to a grid....which means either adding the custom properties to the appropriate BO or creating a special BO based on a view. You may find that the custom properties are the way to go, as they might have other uses. If you use them, you'd just need to add these columns to your fill methods, then access the extra columns in you properties. There are lots of good posts on this out there.



Hope that helps!