I'm still playing around with things trying to get a feel for what's possible with MVC and what's doable and how. One thing that I really can't get my head around at this point is how to build controls or resusable components. MVC is great of separation
of concerns and views that seem to work just fine for page/region scenarios. But I don't really see how this can be leveraged for building reusable components in a meaningful way.
There's limited support for the page engine and while that works for very basic things there are a lot of shortcomings - for example, no Page.ClientScript rendering (or any of the special insertion methods on Page for that matter) which makes it very diffcult
to package things up well. It's easy enough to get around PostBack issues with routing and even manual management but without some fo the core logistics the control model for MVC seems to be missing in action.
I'm pretty green when it comes to MVC as a concept so I might be overlooking something here. But what are other people considering for building reusable components that allow the ability to reuse code without copying markup around. Right now the only alternative
I see is to either embed everything into a raw rendering view and call that view from page code (ugly), using ASCX controls to wrap some of the functionality but with the same limitations of lacking some of the control events/features to build generic reusable
code or just creating raw views without any sort of framework help.
Is there any thought being given to build some sort of control model at Microsoft that doesn't feel like a strapped on hack as using the Web Forms engine feels at this point?
Is there any thought being given to build some sort of control model at Microsoft that doesn't feel like a strapped on hack as using the Web Forms engine feels at this point?
In many ways this will fall to me to help with, since the Toolkit helpers deal with UI. I'm musing with how to best handle this, and have built some things with embedded HTML resources and string replacement (that you can override) - but I'm not sure that's
optimal. I think I should come over to Maui on the Supah Ferry and we can geek out one of these days...
Let's keep this thread moving - it's important to scheme this up and I'd love to do it publicly with you! Tchus!
Is there any thought to a ScriptManager control you could drop in at the bottom of a MasterPage? Then you could register script like normal and the very last thing done on output of the page is render the javascript.
Is this discussion more than just script resources?
I think this is something where Microsoft really needs to take a lead and provide at least the outline of how this can work.
One of the issues likely is the fact that there's probably some resistance in the MVC audience who'll say that having some sort of control model will just dilute the 'get your hands dirty' and full control aspect of the model.
But I think most developers - myself included - are to a large degree spoiled by Web Forms and frankly going back to handcoding every little control from checkboxes to complex grids is not somehting that I look forward to. Been there done that and the 'control'
concept of Web Forms is something that really rather not give up.
The problem right now is that what's happening is that there's focus on helper utilities which helps some but it's not a model that's flexible. You can only pass so many parameters to a function effectively and there's no implied contract in the process
of creating these controls.
There are many problems with Web Forms as we all know most importantly the ViewState and Postback mess. But the control model and a framework that allows to build reusable functionality is pretty damn important to build a lively after market and extensibility
in a consistent and official way.
Some folks will say that's what got us to some of the 'too comfortable' spot with Web Forms, but the truth is that the well defined control model is the reason that Web Forms has done so well.
I guess what I'd like to hear from Microsoft is:
<div mce_keep="true">Are you at least thinking about a new engine?</div>
<div mce_keep="true">Or are you planning on providing only the stripped Page Engine (ie. ASPX and ASCX with stripped page cycle and object support).</div>
I think 1 would be optimal even if it in the end resembles the Page control cycle largely (a good thing) but with proper support for only the things that are actually supported in a complete way. We can currently use existing controls, but it's pretty painful.
Codebehind doesn't work right for control referencing (which is likely intentional, but it sucks if you do need to say databind a control or otherwise set a property (like an object reference) in code).
If 2 there needs to be some strong guidelines on what's supported and what's not.And I think there needs to be more support for things that are missing currently. Like the ability to embed script into the page or the headers. I realize that's difficult without
an official control model - where do you inject stuff, but this is somehting that has to be thought out.
I guess what I'm asking for is some guidance because frankly I'm not sure that I see right now how I even would approach creating a reusable component. For example, hooking up my own AJAX library. My server side library is very flexibile and I've already
made it work with MVC through manual hookups. But I can't see a good way to make this usage generic without a decent 'control' model where things can be declaratively defined. So what do we do? Create special 'component views' and pass a bunch of properties
to a constructor or object initialization code? If that's the case we're going back to the whole thing of having code in views which I thought was the main reason MVC exists in the first place.
I think it's really unfair to suggest that because we like to "'get our hands dirty", that automatically makes us enjoying writing verbose markup or sneer at reusable code. Open up any webform page, and I would say it's probably just as complex as an equivalent
page with standard html + css. A complex DataGrid or GridView is not any less verbose than a regular html table.
Take a peek at Monorail, and you will see that it
embraces reusable controls as much as webforms. The way RoR incorporates AJAX is much cleaner than the mess that is ASP.NET AJAX. (no offense to the ASP.NET AJAX team, I understand it's painful to work around webforms). Webforms took something as simple
as spitting out HTML and made it a nightmare to manage. I admit that it's an design beauty with OO principles pouring out of its core, but the complexity it brings is not needed. I'm all for KISS and DRY, but please do not bring back the 18 page lifecycle
events into our controls. Generating HTML should be easy to follow.
I think this is something where Microsoft really needs to take a lead and provide at least the outline of how this can work.
[Yes]
rstrahl
I guess what I'd like to hear from Microsoft is:
<div>Are you at least thinking about a new engine?</div>
<div>Or are you planning on providing only the stripped Page Engine (ie. ASPX and ASCX with stripped page cycle and object support).</div>
I get the feeling you are looking at MVC to be the next version of Webforms? MVC is just a second option for developing web apps and its an entirely different type of framework.
shinakuma
I'm all for KISS and DRY, but please do not bring back the 18 page lifecycle events into our controls. Generating HTML should be easy to follow.
[Yes]
rstrahl
and frankly going back to handcoding every little control from checkboxes to complex grids is not somehting that I look forward to
Personally I think there is tremendous value in writing out html, css, and js and I have no problem with it.
* Its Simple
* Its Clear
* The Intent is Explicit
* Every dev knows it
* The reuses between Web Designers & Developers increases by huge factor because its straight html
I don't want drag n' drop, I don't want designer generated code, I want control over my presentation. You have no idea how frustrated I would get in the web forms world when a control rendered the most jackass convoluted html and inline styles.
rstrahl
I guess what I'm asking for is some guidance because frankly I'm not sure that I see right now how I even would approach creating a reusable component
Its a reusable UserControl that just displays view data.
rstrahl
So what do we do? Create special 'component views' and pass a bunch of properties to a constructor or object initialization code? If that's the case we're going back to the whole thing of having code in views which I thought was the main reason MVC exists in
the first place.
Yes, you create components that just take view data for parameters and render it. I don't think passing parameters is really putting code into the view?
I also think that many of your issues about distributing reusable components can be addressed, I just don't think the expectation of reusing existing ServerControls should be there.
As I mentioned before creating a script manager to build up and emit JS on a page is a trivial case. Rendering views, scripts, and other assets from resources also shouldn't be that big of an issue. MS could address this one or some simple helper methods
could also handle it just fine.
Does this cover your pain points Rick or am I still missing it?
Yes, you create components that just take view data for parameters and render it. I don't think passing parameters is really putting code into the view?
I think that what's missing then is a way to have the component get its data by itself. If I put a box with the weather on several pages, they can't all go and supply the weather data to this component, its not their responsibility (in this scenario). I
guess what's needed is a way to call a controller that will render view that is just a small snippet of HTML. I don't know if such a thing could be packed up into a .dll, registered on a page (or web.config) and used by others.
It sounds like, from this thread, and the other thread going on about "Compleex pages and UserControls" that we will really need a RenderComponent versus a RenderPartial.
The Component actually runs through regular http process to render its partial view. calling a specific controller and action.
The RenderPartail would have no "Real Logic" and just output a view based on input.
So the difference as I understand it is a Component would require access to resources and thus would have its own controller and actions. A Partial just spits out ViewData in a nice way so you can make your views more moduler.
I am not sold on RenderComponent as you will find in the other thread. But to make it easier to bundle up 3rd party components this would probably make the most sense.
As long as my component could take a different controller and output the same view or let me override the controller and view in some way to get customization.
A big thing missing from all this is the ability to have "Sections" like Monorail View Components and RoR Partials. Not sure what that construct would look like in C#, but it makes ViewComponent building and reuse so much better.
I agree with your point about simplicity and not wanting to repeat the Web Form page life cycle. But somehow the subject of reusability needs to be addressed. If you're slapping together an application and you're building everything from scratch that works
well enough. But how many times are you going to create the same grid like layout by hand? How many times you're going to inject the AJAX code required to update page content into the page? Or even simple things like an error display control that includes
maybe a few AJAX effects? All these things require more than just spitting out a single block of HTML that you <%= RenderMyControlView() %> into the page.
I guess what I'm talking about is not to duplicate what's in Web Forms but a core set of features that are necessary to provide a more sophisticated model than <%= RenderSomeFunctionThatRendersSomeHeinousHtmlPart1() %> and then later <%= RenderSomeFunctionThatRendersSomeHeinousHtmlPart2()
%>, because there are multiple parts of the page that require updating. The way I see it right now there's no way that you can build self contained components of any kind if these components need to do more than render a single block of HTML (or whatever).
Once you start splitting things up (as is frequently the case to get script or formatting into the page) you end up manually hooking up that code.
I realize that currently that doesn't really seem possible given that there are no controls to hook the page. No <form runat="server"> so it'll be tough for example to inject script code.
But is everybody really so willing to give up a Component model to MVC and the productivity and community that it brings?
rstrahl
Contributor
2233 Points
375 Posts
ASPInsiders
MVP
Resuable Components/Controls
Dec 20, 2007 06:56 AM|LINK
I'm still playing around with things trying to get a feel for what's possible with MVC and what's doable and how. One thing that I really can't get my head around at this point is how to build controls or resusable components. MVC is great of separation of concerns and views that seem to work just fine for page/region scenarios. But I don't really see how this can be leveraged for building reusable components in a meaningful way.
There's limited support for the page engine and while that works for very basic things there are a lot of shortcomings - for example, no Page.ClientScript rendering (or any of the special insertion methods on Page for that matter) which makes it very diffcult to package things up well. It's easy enough to get around PostBack issues with routing and even manual management but without some fo the core logistics the control model for MVC seems to be missing in action.
I'm pretty green when it comes to MVC as a concept so I might be overlooking something here. But what are other people considering for building reusable components that allow the ability to reuse code without copying markup around. Right now the only alternative I see is to either embed everything into a raw rendering view and call that view from page code (ugly), using ASCX controls to wrap some of the functionality but with the same limitations of lacking some of the control events/features to build generic reusable code or just creating raw views without any sort of framework help.
Is there any thought being given to build some sort of control model at Microsoft that doesn't feel like a strapped on hack as using the Web Forms engine feels at this point?
West Wind Technologies
Making waves on the Web
www.west-wind.com/weblog
robconery
Participant
852 Points
195 Posts
Re: Resuable Components/Controls
Dec 20, 2007 07:32 PM|LINK
In many ways this will fall to me to help with, since the Toolkit helpers deal with UI. I'm musing with how to best handle this, and have built some things with embedded HTML resources and string replacement (that you can override) - but I'm not sure that's optimal. I think I should come over to Maui on the Supah Ferry and we can geek out one of these days...
Let's keep this thread moving - it's important to scheme this up and I'd love to do it publicly with you! Tchus!
abombss
Member
575 Points
164 Posts
Re: Resuable Components/Controls
Dec 20, 2007 07:58 PM|LINK
Is there any thought to a ScriptManager control you could drop in at the bottom of a MasterPage? Then you could register script like normal and the very last thing done on output of the page is render the javascript.
Is this discussion more than just script resources?
rstrahl
Contributor
2233 Points
375 Posts
ASPInsiders
MVP
Re: Resuable Components/Controls
Dec 20, 2007 09:20 PM|LINK
Rob,
I think this is something where Microsoft really needs to take a lead and provide at least the outline of how this can work.
One of the issues likely is the fact that there's probably some resistance in the MVC audience who'll say that having some sort of control model will just dilute the 'get your hands dirty' and full control aspect of the model.
But I think most developers - myself included - are to a large degree spoiled by Web Forms and frankly going back to handcoding every little control from checkboxes to complex grids is not somehting that I look forward to. Been there done that and the 'control' concept of Web Forms is something that really rather not give up.
The problem right now is that what's happening is that there's focus on helper utilities which helps some but it's not a model that's flexible. You can only pass so many parameters to a function effectively and there's no implied contract in the process of creating these controls.
There are many problems with Web Forms as we all know most importantly the ViewState and Postback mess. But the control model and a framework that allows to build reusable functionality is pretty damn important to build a lively after market and extensibility in a consistent and official way.
Some folks will say that's what got us to some of the 'too comfortable' spot with Web Forms, but the truth is that the well defined control model is the reason that Web Forms has done so well.
I guess what I'd like to hear from Microsoft is:
I think 1 would be optimal even if it in the end resembles the Page control cycle largely (a good thing) but with proper support for only the things that are actually supported in a complete way. We can currently use existing controls, but it's pretty painful. Codebehind doesn't work right for control referencing (which is likely intentional, but it sucks if you do need to say databind a control or otherwise set a property (like an object reference) in code).
If 2 there needs to be some strong guidelines on what's supported and what's not.And I think there needs to be more support for things that are missing currently. Like the ability to embed script into the page or the headers. I realize that's difficult without an official control model - where do you inject stuff, but this is somehting that has to be thought out.
I guess what I'm asking for is some guidance because frankly I'm not sure that I see right now how I even would approach creating a reusable component. For example, hooking up my own AJAX library. My server side library is very flexibile and I've already made it work with MVC through manual hookups. But I can't see a good way to make this usage generic without a decent 'control' model where things can be declaratively defined. So what do we do? Create special 'component views' and pass a bunch of properties to a constructor or object initialization code? If that's the case we're going back to the whole thing of having code in views which I thought was the main reason MVC exists in the first place.
+++ Rick ---
West Wind Technologies
Making waves on the Web
www.west-wind.com/weblog
shinakuma
Member
378 Points
92 Posts
Re: Resuable Components/Controls
Dec 21, 2007 04:48 AM|LINK
I think it's really unfair to suggest that because we like to "'get our hands dirty", that automatically makes us enjoying writing verbose markup or sneer at reusable code. Open up any webform page, and I would say it's probably just as complex as an equivalent page with standard html + css. A complex DataGrid or GridView is not any less verbose than a regular html table.
Take a peek at Monorail, and you will see that it embraces reusable controls as much as webforms. The way RoR incorporates AJAX is much cleaner than the mess that is ASP.NET AJAX. (no offense to the ASP.NET AJAX team, I understand it's painful to work around webforms). Webforms took something as simple as spitting out HTML and made it a nightmare to manage. I admit that it's an design beauty with OO principles pouring out of its core, but the complexity it brings is not needed. I'm all for KISS and DRY, but please do not bring back the 18 page lifecycle events into our controls. Generating HTML should be easy to follow.
monorail Server Control Ruby on Rails
random0xff
Member
102 Points
211 Posts
Re: Resuable Components/Controls
Dec 21, 2007 07:51 AM|LINK
I agree with that.
abombss
Member
575 Points
164 Posts
Re: Resuable Components/Controls
Dec 21, 2007 08:51 AM|LINK
[Yes]
I get the feeling you are looking at MVC to be the next version of Webforms? MVC is just a second option for developing web apps and its an entirely different type of framework.
[Yes]
Personally I think there is tremendous value in writing out html, css, and js and I have no problem with it.
* Its Simple
* Its Clear
* The Intent is Explicit
* Every dev knows it
* The reuses between Web Designers & Developers increases by huge factor because its straight html
I don't want drag n' drop, I don't want designer generated code, I want control over my presentation. You have no idea how frustrated I would get in the web forms world when a control rendered the most jackass convoluted html and inline styles.
Its a reusable UserControl that just displays view data.
Yes, you create components that just take view data for parameters and render it. I don't think passing parameters is really putting code into the view?
I also think that many of your issues about distributing reusable components can be addressed, I just don't think the expectation of reusing existing ServerControls should be there.
As I mentioned before creating a script manager to build up and emit JS on a page is a trivial case. Rendering views, scripts, and other assets from resources also shouldn't be that big of an issue. MS could address this one or some simple helper methods could also handle it just fine.
Does this cover your pain points Rick or am I still missing it?
random0xff
Member
102 Points
211 Posts
Re: Resuable Components/Controls
Dec 21, 2007 05:25 PM|LINK
I think that what's missing then is a way to have the component get its data by itself. If I put a box with the weather on several pages, they can't all go and supply the weather data to this component, its not their responsibility (in this scenario). I guess what's needed is a way to call a controller that will render view that is just a small snippet of HTML. I don't know if such a thing could be packed up into a .dll, registered on a page (or web.config) and used by others.
abombss
Member
575 Points
164 Posts
Re: Resuable Components/Controls
Dec 21, 2007 06:39 PM|LINK
It sounds like, from this thread, and the other thread going on about "Compleex pages and UserControls" that we will really need a RenderComponent versus a RenderPartial.
The Component actually runs through regular http process to render its partial view. calling a specific controller and action.
The RenderPartail would have no "Real Logic" and just output a view based on input.
So the difference as I understand it is a Component would require access to resources and thus would have its own controller and actions. A Partial just spits out ViewData in a nice way so you can make your views more moduler.
I am not sold on RenderComponent as you will find in the other thread. But to make it easier to bundle up 3rd party components this would probably make the most sense.
As long as my component could take a different controller and output the same view or let me override the controller and view in some way to get customization.
A big thing missing from all this is the ability to have "Sections" like Monorail View Components and RoR Partials. Not sure what that construct would look like in C#, but it makes ViewComponent building and reuse so much better.
rstrahl
Contributor
2233 Points
375 Posts
ASPInsiders
MVP
Re: Resuable Components/Controls
Dec 21, 2007 08:03 PM|LINK
I agree with your point about simplicity and not wanting to repeat the Web Form page life cycle. But somehow the subject of reusability needs to be addressed. If you're slapping together an application and you're building everything from scratch that works well enough. But how many times are you going to create the same grid like layout by hand? How many times you're going to inject the AJAX code required to update page content into the page? Or even simple things like an error display control that includes maybe a few AJAX effects? All these things require more than just spitting out a single block of HTML that you <%= RenderMyControlView() %> into the page.
I guess what I'm talking about is not to duplicate what's in Web Forms but a core set of features that are necessary to provide a more sophisticated model than <%= RenderSomeFunctionThatRendersSomeHeinousHtmlPart1() %> and then later <%= RenderSomeFunctionThatRendersSomeHeinousHtmlPart2() %>, because there are multiple parts of the page that require updating. The way I see it right now there's no way that you can build self contained components of any kind if these components need to do more than render a single block of HTML (or whatever). Once you start splitting things up (as is frequently the case to get script or formatting into the page) you end up manually hooking up that code.
I realize that currently that doesn't really seem possible given that there are no controls to hook the page. No <form runat="server"> so it'll be tough for example to inject script code.
But is everybody really so willing to give up a Component model to MVC and the productivity and community that it brings?
+++ Rick ---
West Wind Technologies
Making waves on the Web
www.west-wind.com/weblog