Hi Guiliano,

Thanks for the clarification! I understand what you're after now. I must
admit I'm curious as to why you're going this route, but that isn't really
relevant to answering your question, so I will just try to answer your
question.

I'm not entirely sure about how the HTTP request to this application will be
formed. That may have some bearing on how it should be designed. In
addition, other UI requirements may have some bearing on the architecture.
You see, the ASP.Net Page model is designed to work within certain
parameters, and it sounds like you may be working outside of those
parameters. This doesn't mean that you can't successfully use ASP.Net to
fulfill your requirements. In fact, ASP.Net is fully extensible to fit any
type of web or HTTP application. However, I'm not sure that even employing
an ASP.Net Page is your best start.

The ASP.Net Page model uses a Control Hierarchy and a PostBack mechanism
with Viewstate for the purpose of maintaining Page state during a single
Page "transaction" (for lack of a better term). It employes the HTML form
mechanism to do this, and the entire Page and Control architecture is
centered around this model.

In your case, you are working with a design model that employs an XML data
source to create the structure of at least some portion of the HTML document
returned to the client. It apparently uses HTML forms, and takes input from
an end user. This is all well and good, BTW. Don't get me wrong here. There
are any number of scenarios where this might well be an excellent solution.
Here's where my lack of knowledge about your system makes it difficult for
me.

The first question that comes to mind is, how much of the resulting HTML
should your UI Framework be responsible for? That is, can it be separated
out into consituent components? For example, if the XML file is only going
to contain information about form fields, you might be able to employ the
ASP.Net Page model with a custom Control that renders form elements
dynamically, by adding Controls to the Form in an ASP.Net Page, in which
case these Controls could be wired up to work with the existing ASP.Net Page
model to fulfill your requirements. If the XML file also contains layout
information, it might still be possible to leverage the ASP.Net Page model
by employing MasterPages, Themes, etc. Again, it depends on how much
responsibility the data in the XML file will have for creating the HTML
document that the user interacts with. The HTML document is the User
Interface.

On the other hand, if you want or need to get really detailed with regards
to the layout, user interaction, handling state, you could dispense with the
Page model altogether, and even go with a pure HttpHandler that doesn't
require an ASP.Net Page to handle the HTTP requests at all. In this case,
your UI Framework would behave more like a CGI program that does all of the
work in a class library. Again, that gives you absolute control over the
application, but also requires more work, since you're essentially building
everything but the handler mechanism.

System.Web.UI.Page implements the IHttpHandler Interface, and is a
higher-level complete model for handling HTTP requests, with its own set of
specifications and parameters, and the advantage of a whole set of classes
and Controls that are designed to work with it. It has the advantage of
requiring a lot less work to put an application together, but the
disadvantage of working within a fairly strict programming model. But at a
lower level, you can create your own HttpHandler(s) and your own programming
model. Depending again upon your exact requirements, your solution lies
somewhere between those 2 extremes.

So, with what little knowledge I have at this point, that's the best advice
I can give.

you are referring to th model-view-controller (MVC) pattern. google this
term and you will find lots of info. you will also find several
framweorks you could start with, though its usage is more common in the
java world than the .net world.

-- bruce (sqlwork.com)