Using Multiple BOs and BBSs in a DevEx Grid


Author
Message
Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
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

Greg McGuffey
Greg McGuffey
Strategic Support Team Member (3.3K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
Bill,



If I understand you correctly, you could write a fill method in your Work Order BO that would return the appropriate data (using the appropriate SQL joins to the other tables). The data table under BO can have any column in it (i.e. there doesn't have to a strongly typed property associated with each column), to the extra data would be available in the underlying datatable. You would then have your custom properties. I'm a bit slow to make use of grids, so I'm not sure how the BBS works with a datatable like this, but if the BBS is just binding to the data table, I'd guess that it would work just fine.



Hope that sparks some ideas.
Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
you could write a fill method in your Work Order BO

So, I could write something like FillDataTable("SELECT WO.*, Parts.partnum, Units.unitdesc FROM WorkOrders WO LEFT OUTER JOIN...") and these two fields will show up in the BBS?  Is that right?  If so...my problem might be solved.

Testing now.

Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
That does not work.  The fields come back with blank stares.  Kinda creepy.

As I understand it, the BO must have the field defined in order for the BBS to pick it up.  It has to be a part of the CurrentDataTable of the BO.  That is why I really want to see if this can be down only using currently defined BOs.  All of the data I need already exists in these separate BO definitions.  They can be instantiated and filled quite quickly.  Somehow, I should be able to relate the BOs and point to the field I want to display in the grid.  Somehow.

I really do not want to create a custom property in the Work Order BO called UnitDesc.  I shudder just thinking about that.

Thanks for the help!
Bill

Peter Jones
Peter Jones
Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)
Group: Forum Members
Posts: 386, Visits: 2.1K
Hi Bill,

I may be missing the point but isn't this just three DX grids: Parent, Child and GrandChild using the SF ParentRelationship and ParentBusinessObject properties to bind them together?

Cheers, Peter

Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
One grid.  Three BOs.  Three BBSs.  Just looking for a simple, flattened view of the data.  I do not need any of the master-detail type stuff going on in this particular DevEx grid.

Please keep in mind that this is an exercise for the use of SF BOs.  If a business object exists, then I should be able to point to its properties.  If one of the properties has a relation to another BO, then I should also be able to point to that second BOs properties, too.  The fundamental question is, can it be done in a grid format, using it as a table-like representation of the data?

Hope I am making myself clear--doesn't sound like it, though.  Holler if anyone needs more clarification.

Bill

Peter Jones
Peter Jones
Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)Advanced StrataFrame User (504 reputation)
Group: Forum Members
Posts: 386, Visits: 2.1K
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

Bill Cunnien
Bill Cunnien
StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)StrataFrame VIP (1.1K reputation)
Group: Forum Members
Posts: 785, Visits: 3.6K
just create a view (and replicate your custom fields in the view)

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.

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
So, I could write something like FillDataTable("SELECT WO.*, Parts.partnum, Units.unitdesc FROM WorkOrders WO LEFT OUTER JOIN...") and these two fields will show up in the BBS?  Is that right?  If so...my problem might be solved.

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.

Dustin Taylor
Dustin Taylor
StrataFrame Team Member (652 reputation)
Group: StrataFrame Users
Posts: 364, Visits: 771
One more approach on top of Trent's suggestion is to bring everything into the Work Orders BO. Greg's already hit on this, the only additional thing you would need to do is create public properties and custom bindable property descriptors so that the BBS will recognize those new fields. 

As Trent said, however, doing it this way (pulling everything into a single BO) would only work if the data is meant to be read only. If you want to be able to update the data through the grid, you will need to use Trent's suggestion of the  updateable view.

If the grid is read only, and you do want to handle it all via the work orders BO, then your original response to Greg is most of the way there.  Once the custom fields are pulled in via your custom query (just like you described in your original reply to Greg), you will need to expose them via public properties on the work order BO:

#Region " Public Properties "


        ''' <summary>
        ''' Part Index (Primary Key)
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Public ReadOnly Property parts_partindex() As String
            Get
                Return CType(Me.CurrentRow.Item("parts_partindex"), String)
            End Get
        End Property

        ''' <summary>
        ''' Part Number
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Public ReadOnly Property parts_partnum() As String
            Get
                Return CType(Me.CurrentRow.Item("parts_partnum"), String)
            End Get
        End Property

        ''' <summary>
        ''' Part Unit Index (Foreign Key)
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Public ReadOnly Property parts_unitindex() As String
            Get
                Return CType(Me.CurrentRow.Item("parts_unitindex"), String)
            End Get
        End Property

        ''' <summary>
        ''' Unit Index (Primary Key)
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Public ReadOnly Property units_unitindex() As String
            Get
                Return CType(Me.CurrentRow.Item("units_unitindex"), String)
            End Get
        End Property

        ''' <summary>
        ''' Unit Description
        ''' </summary>
        ''' <value></value>
        ''' <returns></returns>
        ''' <remarks></remarks>
        Public ReadOnly Property units_unitdesc() As String
            Get
                Return CType(Me.CurrentRow.Item("units_unitdesc"), String)
            End Get
        End Property

#End Region

And then provide custom property descriptors on the work order BO to access those custom fields:

Protected Overrides Function GetCustomBindablePropertyDescriptors() As FieldPropertyDescriptor()
    Return New FieldPropertyDescriptor() { _
        New ReflectionPropertyDescriptor("parts_partindex", GetType(WorkOrderBO)), _
        New ReflectionPropertyDescriptor("parts_partnum", GetType(WorkOrderBO)), _
        New ReflectionPropertyDescriptor("parts_unitindex", GetType(WorkOrderBO)), _
        New ReflectionPropertyDescriptor("units_unitindex", GetType(WorkOrderBO)), _
        New ReflectionPropertyDescriptor("units_unitdesc", GetType(WorkOrderBO))}
End Function

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search