Ed Leafe wrote:
On Jun 9, 2006, at 7:53 AM, Simen Haugen wrote:
I have just found this framework, and I must say that I am very excited
about it. It seems very flexible and powerful, but I have not yet
grasped the overall design or how to use it.
That's OK - sometimes I feel the same way, and I wrote much of it! ;-)
I'm trying to create a simple application that retrieves two tables,
link them together, and shows a custom view.
[snip]
I want to ling them on Type_id, and show Task_id, Type.Name.
I do not want to use datanav.Form, so I followed the grid screencast
(the screencasts are pretty neat).
I guess I could just run "select task.id, type.name from task, type
where task.type_id=type.type_id", but I don't know how that will work
when I try to update the tables (I want two tables).
Normally you'd want to create a business object for each table, but
in this case you simply want to denormalize the type table to get the
type name, right?
I haven't played with this much, but I know Paul has. In this case,
you can create a single bizobj for the main table, and define its SQL
like this:
biz.addField("main.f1")
biz.addField("main.f2")
biz.addField("main.f3")
biz.addField("child.fname")
biz.setFrom("main join child on main.childFK = child.pk")
In other words, define the fields you want returned, and then define
the join in the FROM clause. Try that out and let me know how it works.
This will work if you only want to update one of the two tables. In that
case, you need to be sure to set the NonUpdateFields property of the
bizobj so it doesn't try to save changed values back to non-existent fields.
I get the feeling we aren't talking about parent/child relationship
here, but really just two tables being joined 1:1. IOW, it could have
been designed on the backend to be in one table but for whatever reason
it was split in two. Is this correct?
If that is correct, I'd go the two-bizobj approach - one bizobj for each
table, even though that kind of violates the intent of 'one bizobj per
entity' rule. Then, set one as the child of the other and set the link
fields, etc. That way you'll be able to easily send updates to both
backend tables.
Otherwise (if you use the join in the sql with one bizobj), you'll have
to pick one or the other to send updates to, and then manually handle
the other table's updates (yuck). This is because when we craft the
update/insert statements we really assume it is just going to the one
main backend table.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
