I have an implementation question on setting up a parent-child structure. My use case goes like this:
The user needs to maintain information about a Job. One of the things a user needs to do for a Job is to assign a Customer, and along with that Customer, a specific Customer Address. Each Customer contains a list of one or more Addresses. In the Job entry/edit screen, the user will need to enter the Customer's Id - which will then be validated to make sure it's a valid customer #. The Customer's name will then appear in a label next to the customer id text box. The user should then be able to pick a valid location from a list in a dropdown box. So when the Customer Id value is validated, it will also need to load the appropriate values into the dropdown box. The the user will select one Customer Address to be associated with the job.
My question then is how do I best implement that scenario in my objects? I obviously have an editable root for the Job object. But what do I do with Customer and Customer Address? I seem to think I need a Customer child object on the Job parent object but I'm not sure exactly how to set it up. And what of the address as well? I need a collection of valid addresses for the specified Customer in order to load the comboBox, but I really just need to store the Id for the chosen address.
There doesn't seem to be any direct correlation in PTracker and I've searched the forum here (unsuccessfully) for answers as well. I feel like there's an easy way to do this that's right in front of my face and I'm missing it. I keep having "I got it...I got it.........I don't got it......" moments trying to figure this out. If anyone can help me here it would be GREATLY appreciated.
Thanks,
Dennis
When I had to deal with this situation, my Job object only has
CustomerID and LocationID fields, but no child objects for those. I typically
setup two drop downs on the screen – one for customer, one for
location. When customer ID changes (via new value from drop down), I
reset LocationID to zero/blank inside the property setter for customer inside
Job object to keep it valid. As far as both drop downs go, I’d have
single source of data (read only list of customers, where each customer
contains read only list of locations). I use this object to populate both
dropdowns.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: dtabako
[mailto:cslanet@lhotka.net]
Sent: Monday, May 19, 2008 2:28 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Child object structure question
I have an implementation question on setting up a parent-child structure. My
use case goes like this:
The user needs to maintain information about a Job. One of the things a user
needs to do for a Job is to assign a Customer, and along with that Customer, a
specific Customer Address. Each Customer contains a list of one or more
Addresses. In the Job entry/edit screen, the user will need to enter the
Customer's Id - which will then be validated to make sure it's a valid customer
#. The Customer's name will then appear in a label next to
the customer id text box. The user should then be able to pick a
valid location from a list in a dropdown box. So when the Customer Id value is
validated, it will also need to load the appropriate values into the dropdown
box. The the user will select one Customer Address to be associated with the
job.
My question then is how do I best implement that scenario in my objects? I
obviously have an editable root for the Job object. But what do I do with
Customer and Customer Address? I seem to think I need a Customer child object
on the Job parent object but I'm not sure exactly how to set it up. And what of
the address as well? I need a collection of valid addresses for the specified
Customer in order to load the comboBox, but I really just need to store the Id
for the chosen address.
There doesn't seem to be any direct correlation in PTracker and I've
searched the forum here (unsuccessfully) for answers as well. I feel like
there's an easy way to do this that's right in front of my face and I'm missing
it. I keep having "I got it...I got it.........I don't got it......"
moments trying to figure this out. If anyone can help me here it would be
GREATLY appreciated.
Thanks,
Dennis
Thanks Sergey,
That was something I certainly considered - and in fact that would be the way I'd love to handle it. The problem is that carrying my list of customers could be a performance drain. Some users have 10,000 or more customers. And each customer may have many locations (rather than just a simple billing and shipping location). For instance, let's say the user is a building materials supplier with, say 10,000 customers. And perhaps some of those customers are home builders that have many locations (e.g. one for each home they are currently building). And they may wish to set up a Job for each of those locations. The numbers get big quickly as far as loading and maintaining collections for dropdown boxes. That's why part of the use case is that the user enters the Customer Id manually (rather than picking from a list - although manual entry is aided by a separate search dialog which I've already developed).
I also thought about going the route of having the Customer Id and Address Id as simple fields in the Job object (and if that's the way to go, so be it). I guess the only problems I can think of with that approach are (a) how do I easily maintain the label with the customer name and (b) how do I easily maintain the address list?
Thanks,
Dennis
I totally agree with your search dialog approach. As a
matter of fact, I used the same approach on large lists as well. As far
as your questions go:
1.
Customer name I would retrieve as past of the same SP by joining
with customers ( or via a correlated sub-query, whichever is faster). As
far as setting of it goes, I would return it from your search dialog along with
ID and populate UI based on that object.
2.
Address list if a bit trickier, I think. I do not see any
super easy way of doing it. If a customer cannot have but a handful of
locations, I would still go drop down route. If you can have thousands of
locations we well, then I would use the same approach as a customer search
dialog, but filter it based on selected customer.
Would this work for your? I am sure that there are many
other ways to do the same as well…
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: dtabako
[mailto:cslanet@lhotka.net]
Sent: Monday, May 19, 2008 3:52 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] RE: Child object structure question
Thanks Sergey,
That was something I certainly considered - and in fact that would be the
way I'd love to handle it. The problem is that carrying my list of customers
could be a performance drain. Some users have 10,000 or more customers. And
each customer may have many locations (rather than just a simple billing
and shipping location). For instance, let's say the user is a building
materials supplier with, say 10,000 customers. And perhaps some of those
customers are home builders that have many locations (e.g. one for each home
they are currently building). And they may wish to set up a Job for each of
those locations. The numbers get big quickly as far as loading and maintaining
collections for dropdown boxes. That's why part of the use case is that the
user enters the Customer Id manually (rather than picking from a list -
although manual entry is aided by a separate search dialog which I've already
developed).
I also thought about going the route of having the Customer Id and Address
Id as simple fields in the Job object (and if that's the way to go, so be it).
I guess the only problems I can think of with that approach are (a) how do I
easily maintain the label with the customer name and (b) how do I easily
maintain the address list?
Thanks,
Dennis
True, I could have the search dialog expose the name as well as the Id. Although, that still leaves manual entry - the user doesn't HAVE to use the search dialog. If he happens to know the customer Id, he can simply enter it manually. Then, of course, I'm not really calling the DB at all other than maybe doing a Customer.Exists(id) within the validation rules for the Customer Id field. Unless I make some specific call to get the customer name.
And furthermore, what if I wanted to setup validation rules so that the the customer number is required; but it must also exist; but there is no real meaningful default customer? How would I be able to set this up so that it works for a new Job? Yeesh, I'm creating more questions now ;^)
As for the customer addresses, I do still plan on using the dropdown. And I assume what would happen is that when the customer changes, I'll have to grab a new list of addresses to use as the BindingSources's DataSource. The tricky part for me is how do I know when to do that? Is the "PropertyChanged" event for CustomerId (within the Job object) exposed to the UI code? I didn't think it was, but I could certainly could be mistaken. If it's not, do I fire my own event from within the property setter? Or is there a better way?
This kind of illustrates the way this has gone for me as far as getting part or most of the way to a solution and then tripping on snags and not quite getting all the way there.
Thanks,
Dennis
I think you can use PropertyChanged event in the UI to get list
of addresses. I think you can also use custom rule to populate name
when customer ID is set. You just have to get fancy with your Exists rule
and retrieve the name as part of the same exists call.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Magenic ®
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: dtabako
[mailto:cslanet@lhotka.net]
Sent: Monday, May 19, 2008 4:33 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] Child object structure question
True, I could have the search dialog expose the name as well as the Id.
Although, that still leaves manual entry - the user doesn't HAVE to use the
search dialog. If he happens to know the customer Id, he can simply enter it
manually. Then, of course, I'm not really calling the DB at all other than
maybe doing a Customer.Exists(id) within the validation rules for the Customer
Id field. Unless I make some specific call to get the customer name.
And furthermore, what if I wanted to setup validation rules so that the the
customer number is required; but it must also exist; but there is no real
meaningful default customer? How would I be able to set this up so that it
works for a new Job? Yeesh, I'm creating more questions now ;^)
As for the customer addresses, I do still plan on using the dropdown. And I
assume what would happen is that when the customer changes, I'll have to grab a
new list of addresses to use as the BindingSources's DataSource. The tricky
part for me is how do I know when to do that? Is the
"PropertyChanged" event for CustomerId (within the Job object)
exposed to the UI code? I didn't think it was, but I could certainly could be
mistaken. If it's not, do I fire my own event from within the property setter?
Or is there a better way?
This kind of illustrates the way this has gone for me as far as getting part
or most of the way to a solution and then tripping on snags and not quite
getting all the way there.
Thanks,
Dennis
You can add a readonly list of addresses in your object, a readonly flag to check if customer is validated and a property to hold customer name. In property setter of customer id you can call another method, which in turn can validate customer id, fetch customer name and all the addresses of that customer and set the flag for customer's validity. In that way you need not to worry about anything on UI. You will just check the validation flag on UI and bind the addresses to drop down.
Copyright (c) Marimer LLC