One way to do this is to use the Page.ParseControl and Controls.Add methods to load the controls that are dynamically created. The downside to the approach is that the web forms controls are prefixed with "asp:", but the page has no namespace declaration associated with the namespace prefix "asp". So, you have to fake one in your XSLT, then remove it so that Page.ParseControl doesn't throw an exception. So, you have to implement some sort of a post-processor on your XSLT result as a string to remove the xmlns declaration for the dummy namespace bound to the asp prefix, but leaving the asp prefix on all nodes. Or, you can output elements as HTML with an additional "runat='server'" attribute and pass them into the Page.ParseControl method, enabling them to become HTML server controls. Performance takes a hit, but I couldn't pinpoint any huge glaring performance issues with small test sets.
Personally, I prefer a mixed approach, using XML to load into DataSets that are bound to UI elements as well as to use XSLT for limited display areas instead of entire pages. Kirk Allen Evans http://www.xmlandasp.net Author, "XML And ASP.NET", New Riders Publishing http://www.amazon.com/exec/obidos/ASIN/073571200X > -----Original Message----- > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED]] On Behalf Of Steven Livingstone > Sent: Tuesday, September 17, 2002 12:02 PM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Controls, .Net and Xslt insanity > > Ok, even after taking time out again to think about this issue I feel I > need some view and opinions. > Creating web controls in .Net - when and how? > > For years now I have almost without exception used Xslt to generate the > output for forms and content alike. Now, with web controls there is the > mixed content and code, some of which I don't like all that much. To > generate a menu for example, I would be more tempted to write the code > to use Xslt to transform the data. The idea of writing out table > elements in C# code with javascript inserted as strings is not at all > appealing. > > When it comes to forms, it is more appealing as you can get state > management and validation - both of which are a pain to manage in Xslt. > Still you have the annoying need to write out table elements and form > elements (e.g. output.Write("<td class='clsMenuBarCell' nowrap>");) > > I have hit one of those mind block days where I am arguing with myself > over the better way to do things, so it's out to the jury to let me know > what you have been doing. > I'm pretty sure the best way is some combination - this would ideally be > a way of still getting state management and validation, with OO, but > being able to separate the display from the Asp.Net, but this doesn't > seem possible. > > I also dislike the idea of transforming to an aspx page and then loading > that. > > Has anyone looked at in memory dynamic compilation? In other words, > still having your xslt's that can be loaded. These transform to an aspx > output in memory that is dynamically returned so that you can still get > all the benefits of state management and validation methods? An example > may be: > > - user vists page > - aspx page generates form using Xml data and Xslt to create aspx code > - user submits data > - aspx code behind validates and maintains viewstate > - in memory aspx output section is modified by code-behind (e.g. > label.Text="Invalid Telephone Number") > - result is sent to the output > > Thanks, > Steven. > > > ========================================================== > Steven Livingstone BSc (hons), PgDip ITS [[EMAIL PROTECTED]] > .Net & Xml Consultant > > Change your business at http://www.deltabis.net > Grow your business at http://www.venturetogether.com > Change European Football at http://www.theatlanticleague.com > > *** Author of "Application Development with MSXML 4.0" > *** Coming Soon to a developer near you... > "Beg VB.NET XML:Essential XML Skills for VB.NET Programmers" > "Beg C# XML:Essential XML Skills for C# Programmers" > ========================================================== > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
