| 3/15/2006 1:00:00 PM |
Hi Paul,
Is it necessary to create a module for each table/ORMapper object (in another ORMapper DB) that I would like to maintain?
When I used the UIMapper, I crated a generic UIMapper control, and just changed certain properties like objecttype and editpage. I created a listpage.aspx, and passed objecttype and editpage as parameters, which in turn set the ListView objecttype property, and presto!, my table was listed, and maintainable using only one page.
Can you suggest how I would go about doing this using the module paradigm?
Many thanks,
Sean. |
| 3/15/2006 6:11:55 PM |
Hey Sean:
Is it necessary? Absolutely not. But until I get the chance to create a more generic table list/edit module you'll have to do that yourself -- and you could probably use the UIMapper in the process if you so desire. A module is just a reuseable control, that typically inherits from my module base class in all but the simplest of cases, and so anything you can do in any other ASP.NET control you can do in a module. The main thing is that you'll need to get each instance of that module, or part, to know what its specific settings are that differentiates it from the other instances of it -- and this is where you'll want to key on the PartId that each instance gets, unless you can make some assumptions about page name or something like that which is a little more risky unless you control everything. I'm thinking that when I create my generic table list/edit module I'll have a config action that will expose a few basic things like table and/or object name, and a few other things that may be required, which I'll save in a database table so that whenever that specific part instance of the module is instantiated I will know those few details that I need to use my ListView and EditView controls. I hope this helps, and I will certainly be creating something like this if no one else beats me to it.
Thanks, Paul Wilson
|