I see that the Infragistics grid automatically creates bands for you if your bo contains a list of other bo's. How do you go about filtering the child band so it only shows records associated with the expanded parent record?
I'm trying to show a list of "Tickets", where each Ticket has a collection of "Orders". Right now every order is showing up under every ticket. Or do I need to make a DataSet and do the relationship in there?
Thanks,
Mike
That should work automatically (we use CSLA + Infragistics extensively for exactly this case). I've never seen a case where it pulls in "extra" records. Are you sure your "Orders" collection under each "Ticket" is actually loading only those records it should?
No, I'm not :) I'm doing it wrong. I think I can fix that, but just a quick question - can you do this with one trip to the database? Or would each ticket fetched have to make another trip to the DB to retrieve its orders?
Thanks,
Mike
No idea what is going on but I just cannot post my reply!!! I'll try it in pieces. Here goes:
That is up to you depending on your implementation. We actually use three different methods depending on scenerio. They are:
Ahh! I originally had a URL link to a one such discusiion on loading children, etc in one call and it seems thats what was making my post fail. Let me try it again. Here is the link:
Wow, thanks for being persistent. I appreciate the info. Nice to have options. For this particular case, I think I'll go the lazy-loading approach, only because the user will somewhat infrequently drill down, and that should just be for a ticket or two.
Thanks again,
Mike
Hey Bayu,
I've played with CAB and Infragistics, but not with CSLA - this was before I discovered CSLA. I don't see why they couldn't be used together, though.
For what I was doing, CAB was pretty cool, but I think it was overkill for what I needed. Takes longer to develop stuff and I never needed to re-use the views - if I remember that terminology right.
What I did want to have was a plug-in type app where the plug-ins could talk to each other. So the event broker mechanism was cool.
BTW, I assume you know that Infragistics has it's own CAB components too.
Michael Hildner:
Hey Bayu,
I've played with CAB and Infragistics, but not with CSLA - this was before I discovered CSLA. I don't see why they couldn't be used together, though.
For what I was doing, CAB was pretty cool, but I think it was overkill for what I needed. Takes longer to develop stuff and I never needed to re-use the views - if I remember that terminology right.
What I did want to have was a plug-in type app where the plug-ins could talk to each other. So the event broker mechanism was cool.
BTW, I assume you know that Infragistics has it's own CAB components too.
Bayu,
Yeah, my app was deployed with ClickOnce. I've never installed anything in the GAC. I never wanted that extra maintenence. I guess you'd be safe with CAB - that hasn't changed in almost a year, I believe, but Infragistics changes pretty quickly.
I just didn't see the advantage of installing anything in the GAC - nothing that offset the maintenance. Disk space is cheap :)
Not sure if you know how ClickOnce works, hope I'm not saying something you already know, but once your app is installed, and then you update your assemblies, only the modifed assemblies get sent over the wire. For example, one app I have and update regularly is only about 2-3 megs for the GUI and business library. That's usually the only thing that changes, so that's all the user has to wait for. Recently I upgraded to Infragistics 6.3, so that deployment was about 31 megs total.
Regards,
Mike
Yeah, my app was deployed with ClickOnce. I've never installed anything in the GAC. I never wanted that extra maintenence. I guess you'd be safe with CAB - that hasn't changed in almost a year, I believe, but Infragistics changes pretty quickly.
I have never worked with ClickOnce yet. But is sounds like a good alternative. With ClickOnce, will updates be atomic? In other words, if you have a new version of Infragistics and correspondingly a new UI, then you wouldn't want the user to be able to run the app while only the new UI has been updated so far and the remainder is still in progress. Hmm, saying this, I cannot imagine they dit not make it atomic.
I just didn't see the advantage of installing anything in the GAC - nothing that offset the maintenance. Disk space is cheap :)
Good point. I may be a bit too concerned about just a few MBs.
Not sure if you know how ClickOnce works, hope I'm not saying something you already know, but once your app is installed, and then you update your assemblies, only the modifed assemblies get sent over the wire. For example, one app I have and update regularly is only about 2-3 megs for the GUI and business library. That's usually the only thing that changes, so that's all the user has to wait for. Recently I upgraded to Infragistics 6.3, so that deployment was about 31 megs total.
>>you wouldn't want the user to be able to run the app while only the new UI has been updated so far and the remainder is still in progress
That doesn't happen, nothing to worry about there. I think ClickOnce is great, I'd go for it.
Here's a helpful FAQ http://www.windowsforms.net/FAQs/default.aspx?PageID=1&CategoryID=24&tabindex=2
Just one word of warning; the user can Skip the update if its detected. Because of this, my application checks its version number against a value stored in the database, which defines the minium version of the application to run. That way, I can keep older clients out in case the database structure has changed.
Copyright (c) Marimer LLC