Hi all,

i'm starting the development of an UI framework in C# and ASP.NET, this
framework must generate pages on the fly and supply validation routines
and CRUD operations. Could anyone address me on resource that can
explain me best practices about realization of this kind of frameworks ?

Any help will be appreciated.

Giuliano

The question does not make sense as it is stated.

First, what exactly do you mean by "UI Framework?" "Framework" is a generic
term for any structure that supports the creation of other structures.
ASP.Net is a framework. The .Net platform is a framework. Windows is a
framework. In other words, "Framework" does not describe a requirement
without clarification.

Second, the requirement that "this framework must generate pages on the fly"
is already satisfied with ASP.Net. That is what ASP.Net does. So, you must
mean something different. But you need to clarify what you do mean by this
statement.

Third, "validation routines" is another rather generic statement. In the
context of UI, it implies "User Input validation routines," but implies
nothing about the user input to be validated. Again, ASP.Net itself supplies
UI-level validation, but apparently you are talking about something other
than the built-in ASP.Net UI validation. What exactly is that?

Finally, you mention "CRUD operations." CRUD is beyond the scope of UI. It
is business-related. Therefore, it makes no sense to include it in the
description of a "UI Framework."

So, could you clarify your requirements? Remember that the more you detail
what you want, the more we can help. I have already written more in my
response than you wrote in your request, in the interest of being clear. In
order to help us help you, please be as clear as possible about what you are
asking.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"Giuliano Musso" <giuliano_musso (AT) yahoo (DOT) it> wrote

Hi Kevin,

first of all i want say thank you for your answer. You're right, i'm
not so clear in my previous message, i will try to be more detailed.

I will start explain "this framework must generate pages on the fly",
for example i've a blank page named CustomerDetail.aspx, at this page
will be associated an XML file containing the definition of UI controls
needed on page (listbox, textbox, grid ...) When the ASP application
starts, all configuration files will be loaded by a component called for
example UIService.dll that will provide configuration infos about how
page must appear and which control it must contain.

This controls will be added to the page and for each control i need to
attach some basic routines to validate input based on custom rules (date
between a specific range, textbox value required because some other
fields are filled) and also the control appeareance (enabled, colour ..)
could change dependant other fields values (this is what i mean as
"validation routines")


I used the term "Framework" because i need to realize some components
that provides services to generate UI and not a UI code generator.


"CRUD operations": you're right i've used this term not in a proper manner.

Thank you for all
Giuliano Musso

Kevin Spencer ha scritto:

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.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net


Now,

"Giuliano Musso" <giuliano_musso (AT) yahoo (DOT) it> wrote

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)



Giuliano Musso wrote: