This would speed things a lot, especially for enterprise development.
Possibly.
But only if you like extremely idiotic surfaces.
Oh, I think that's a little harsh... You can do a lot in browser applications these days that was previously only possible in rich clients. For instance, HTML only provides dropdown lists, not real combo boxes, but there are real combo boxes available that take advantage of dynamic HTML to provide the same user experience. (Shameless plug: http://www.opinionatedgeek.com/DotNet/Products/PowerPack/Examples/ComboBox.aspx - or a free alternative by someone else: http://www.coreyhulen.com/ )
I agree that trying to come up with a platform that will allow a rendering to both web forms and win forms will mean you have to accept the lowest common denominator from both camps, but I don't think that that lowest common denominator is as low as you think.
That said, the original poster asked for comments and suggestions, so here's how I'd approach it.
First of all, I'd decide what controls I wanted to be available to developers using my platform. If it can be restricted to just text fields, labels, radio buttons and dropdown lists, then it will be much more straightforward.
Then I'd decide what lifecycle phases the form would go through. If it will always be a simple Load - Accept input - Validate - Save then again it should be quite straightforward. These lifecycle phases will become the "events" of your form that your users will be able to hook into. (Alternatively, don't expose any events at all - just find a nice way to describe how the input data should be saved to a data source.)
For each control you need/want to expose, you'll then need to write your own version that delegates to the appropriate control in windows or web environments. So, for an environment-independent textbox, you'd have something like:
public class IndyTextBox
{
:
private System.Web.UI.WebControls.TextBox webTextBox;
private System.Windows.Forms.TextBox winTextBox;
private EnvironmentType environment;
: public string Text
{
get
{
string szText;
if (environment == EnvironmentType.Web)
{
szText = webTextBox.Text;
}
else
{
szText = winTextBox.Text;
} return szText;
}
set
{
if (environment == EnvironmentType.Web)
{
webTextBox.Text = value;
}
else
{
winTextBox.Text = value;
} return;
}
}
:
:
}Your job will become more complicated the more complete you need/want to be. If you keep your needs simple, this approach should work for you. But if you want to provide a user experience in a web form that's as good as that of a rich windows application, you'll have to spend an awful lot more time on providing rich controls and exposing a lot more events and properties.
On the other hand though, plugging validation into each of the controls shouldn't be a big job, and it should be straightforward to provide a mechanism that is common to both windows and web.
XML is a natural choice for the form description-language, by the way. It provides a nice way to describe a nested control tree, and you can take advantage of a bunch of neat XML processing tools and libraries. Good choice!
So, for what it's worth, those are my thoughts on a common approach. It would be an interesting project, and the more complete it was the more useful it would be to programmers. Is there a market for it? Is it worth the effort? I don't know. But good luck if you decide to take it further. (Me? I'd probably go with Curt's suggestion and develop a really neat web app, then host IE/ASP.NET in a windows app.)
Hope this helps,
Geoff
-- OpinionatedGeek.com :: Part of the solution Quality ASP.NET cross-browser RichTextBox, ComboBox, DatePicker controls Visit http://www.opinionatedgeek.com/ for details.
=================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
