OK, I've been playing with this (implements and a user control) and have figured a couple of things out.

First, the line of code below was for an Events "module" (from the IBuySpy Portal) that tracked upcoming events, not an event class. <g>

Next, the implements approach was off track. I was confused about how implements works and I was thinking that the implementing was done by the mmBusinessWebPage. However, it seems that the implementing is done by the controls, not the page.

What I am trying to do is confer the attributes, methods, etc. of the mmBusinessWebPage to a user control so that when I drop an MM control into my new hrmsPortalModule (sub-classed from usercontrol) the binding stuff still works.

My first experiment has been to "cut and paste" the methods in the mmBusinessWebPage into my hrmsPortalModule. This kinda works but I had a problem with the following line:

mmWebDataHelper.ControlBindData(this,(Control) control,bindingSource,bindingMember,null);

which I changed to:

mmWebDataHelper.ControlBindData(Page,(Control) control,bindingSource,bindingMember,null);

All the references to "this" now refer to the user control and not the "Page" so I had to change "this" to "Page".

The two way binding is now working, but there's some kind of problem with the validation. I'm getting this error:

The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).

I'm sure there are other things I'll have to tweak, and maybe you have some hints at what I might look at?

I was also curious if there's some kind of "pattern" that describes how to move functionality from a container class to a contained container class. Perhaps there's some methodology to keep the page container with all it's methods and have the contained container (in this case the user control) pass specific calls up to it's parent

TIA,
Chris.




>>In the IBuySpy framework, "modules" (ie, discreet sections of a page) are implemented as ASCX controls. A typical class definition looks like this:
>>

>>    public abstract class Events : ASPNetPortal.PortalModuleControl {
>>

>>
>>I'm not that good on "implements" yet but are you suggesting I could create a subclass of PortalModuleControl and have it implement ImmWebBinding and ImmWebBindingSimple?
>
>Yes that would work although I suspect that you don't want an Events class implementing data binding interfaces. <g> But if there are custom controls that you want to support in this fashion what you need to do is implement the mm interfaces. At that point Databinding would work. Most of the interfaces are pretty simple as they forward their calls to a decorator class that does all the hard work. All you do is call it and hte framework does the rest in most cases.
>
>The easiest way to do this is to copy the implementation from one of the existing controls like TextBox, then check and make mods as necessary...
>
>
>
>
>>I suppose I'm looking for this PortalModuleControl to have the additional behaviors as the mmBusinessWebPage so the mmControls and associated binding mechanisms all work harmoniously together.
>>
>>I think it's fairly straight forward to hook into mm business objects only and bind std controls to the returned datasets, etc. But the 2 way databinding is so cool and that's where I'm not so good at the implements approach and integrating the mm stuff into the PortalModuleControl. The existing data access for the portals content, etc is pretty wacky, but it works. I would leave that as is, and just work on my domain specific tables and data access, binding, etc.
>>
>>Looking forward to asp.net 2.0
>>
>>Thanks,
>>Chris.
>>
>>
>>
>>>>I'm interested in the addition of a couple of web controls to the framework:
>>>>
>>>>datalist
>>>>user control
>>>
>>>What are you missing in mmDataList?
>>>
>>>UserControl would be a tough one since it is too generic. The main things the UI controls implement is databinding and security interfaces and they're specific to the control and map to specific properties of these controls. With a generic user control this would be difficult to do and there's little to be gained. Basically you can create a new control subclassed from that control and then implement the interfaces you're interested in for databinding or security.
>>>
>>>>Another goal I have it to integrate the MM framework into the IBuySpy portal. While the MM web framework goes a long way to assisting in the process of creating web forms, it has no real UI framework for navigation, menus, users, roles, etc. At least I haven't seen it. The I Buy Spy portal has all that and a fairly straight-forward mechanism for managing content.
>>>
>>>You shouldn't have any problem integrating this stuff into any other framework. IBuySpy is essentially a UI front end and so it should play just fine with what MM provides. You can use IBuySpy as is and then for the page content use standard Web Form stuff with mm Controls to provide your logic.
>>>
>>>>Ideally, I could create an ASCX component that could inherit the attributes of the portals "module" class (in order to play well with its framework) but implement the attributes of the MM Business class (to play well with the MM business classes). This way it would be possible to add MM modules into the IBuySpy portal framework.
>>>
>>>I'm not sure I understand why you would think there would be any issues with integration. The main things I can think of would be to have the portal BOs use MM classes behind the scenes which would mean you pull out whats there and replace it. I'm not sure if that's necessary or whether that really buys you anything.
>>>
>>>FWIW, in ASP.Net 2.0 a lot of the stuff that you build for a typical portal will all be built-in to to the framework. Registration, controlled content, master pages - all of these things will drastically change the amount of code needed to do this sort of thing - and it is all pluggable with custom providers so you could for example, just plug in BO's from an MM app. But unfortunately that's still almost a year off...