ASPX now with methods and classes

[John Rivers]

hi, here is how to do it and restore sanity to aspx html rendering:

(please only reply with sensible architectural discussion - juan)

put this at the end of an aspx file (or use an include at the end
if you want to reuse it on many aspx pages)
(notice closing brace)

(start)
<%}
//Don"t change this bit
private System.Web.UI.HtmlTextWriter __output;
private System.Web.UI.Control parameterContainer;
void InitLib(System.Web.UI.HtmlTextWriter o, System.Web.UI.Control pc)
{
__output = o;
parameterContainer = pc;
}
//Convenience methods go here
string HTML(string data) {
return HttpUtility.HtmlEncode(data);
}
string URL(string data) {
return HttpUtility.UrlEncode(data);
}
string QPX(string name, string val) {
return URL(name) + "=" + URL(val) + "&";
}
//Add your rendering methods here!
void RenderLink(string Title, string URL) {
%><a href="<%=HTML(URL)%>"><%=HTML(Title)%></a><%
}
public class RenderClass {
private System.Web.UI.HtmlTextWriter __output;
private System.Web.UI.Control parameterContainer;
public RenderClass(System.Web.UI.HtmlTextWriter o,
System.Web.UI.Control p) {
__output = o;
parameterContainer = p;
}
public void Render() {
%>THIS IS RENDER CLASS FUNCTIONING!<%
}
}
//Don"t change anything after this
void ButtPlug() {
//this is the end
%>
(end)

now you can call these methods and use these classes from your aspx
page as follows:

<%
InitLib(__output, parameterContainer);
RenderClass c = new RenderClass(__output, parameterContainer);
c.Render();
%>


that means thanks to me we can now use the full power of
object oriented programming to develop user interfaces
whilst still benefiting from:

- code coloring
- code completion
- rewrite and retest without slow re-initialise of iis
- complex dhtml/javascript work is now realistic again
- class inheritance, delegates, callbacks, etc:

this also proves that microsoft deliberately made
the decision to disallow <%%> in methods and classes

BUT WHY??????????????????????????????????????????????

IT MAKES NO SENSE!!!

if you want to give people things like user controls
and custom controls

just let them do what i just did and implement an interface
or two, or derive their rendering class from another

this is simple stuff, microsoft, why did you bugger it?

HA HA HA microsoft muppets, they write some brilliant code at times
but sometimes they run with a bad idea for way to long ...


there is a concept in systems architecture i call "spirals"

an api which is well conceived has a "positive spiral"
that is that everything related to it succeeds
and it generates more and more "good stuff"
just like a foundation of a house

big chunks of asp.net are ill-conceived and result
in a "negative spiral" which means that code/apps built
on these parts of asp.net will always be faced with
problems, because they are built on a problematic concept

just by reading through 100 articles in this website
you can see the proof of this

i am not talking about beginners problems, i am talking
about people with experience (but not enough experience
to not use this features) struggling to complete very
simple tasks with broken tools

most of asp.net is very good

but aspx, html controls, user controls, custom controls,
viewstate, databinding, the page event model
really suck badly - and whoever brought them
into this world should find a new job

at least it gives an opportunity for me to solve these
issues with a product and make money

when something pisses you have to stop and think
"there is money to made, simply find a solution and sell it!"

--

on another note, i have read much nonsense about seperating
html from code

there is no seperation required

ASP IS THE PRESENTATION LAYER

most the power of asp comes from USING CODE TO EMIT HTML

so to talk about splitting rendering logic from rendering literals
is an absolute nonsense

also how can this be a sensible claim:

void Render() {
Response.Write("<html/>");
}

is acceptable, even better than:

void Render() {
%><html/><%
}

given the above list of benefits to be gained
by using code blocks given above?

please don't reply unless you understand what
i am saying and have something constructive to add

have a good day

 

[Damien]

John Rivers wrote:
[an article about allowing you to fully intermingle code and html in
ASP.NET]

Personally, I've learnt to stop worrying and love the Code-Behind
model. It's allowed me to do some things which are nigh-on impossible
with the old ASP style intermingled pages.

For instance, sometimes I have three completely differently laid out
pages, which all use the same code-behind page for all of the complex
code - they have the same controls but in completely different
locations. But all of the application logic only exists once. Your
alternatives with code-on-the-page are either:

1) A single monster page which has the control logic which determines
which controls are produced and when spread over the whole page, or,
2) Three independent pages which then always have to be maintained in
phase with each other when the application logic changes, or,
3) Three independent pages and a class which the pages call when they
need the application logic to run - but then, you're inventing
Code-behind.

And John, you've obviously never worked in a team where you have a
seperate web page designer - who is very good at producing pretty
webpages, but knows sod all about programming. The first time you
realised the problem with intermingling is after they do an edit of the
page, you get the latest version from source control and half of your
code has been vanished.

Damien

 

[Guest]

Agree in 100% with you Damien. John also see my reply in your "I have fixed
ASP.NET check it out" topic. Just start to understand the idea of the
OOP/Code Behind programming.

Cheers,

Milosz Skalecki
MCP, MCAD

 

[John Rivers]

Dear Damien,

thankyou for your reply

please see my comments below ...

John

John Rivers wrote:
[an article about allowing you to fully intermingle code and html in
ASP.NET]

Personally, I've learnt to stop worrying and love the Code-Behind
model. It's allowed me to do some things which are nigh-on impossible
with the old ASP style intermingled pages.

For instance, sometimes I have three completely differently laid out
pages, which all use the same code-behind page for all of the complex
code - they have the same controls but in completely different
locations. But all of the application logic only exists once. Your
alternatives with code-on-the-page are either:

1) A single monster page which has the control logic which determines
which controls are produced and when spread over the whole page, or,
2) Three independent pages which then always have to be maintained in
phase with each other when the application logic changes, or,
3) Three independent pages and a class which the pages call when they
need the application logic to run - but then, you're inventing
Code-behind.

my approach would enable you to do this:

create a re-usable class library for rendering
by letting you write full blown C# with codeblocks
so letting you use html literals, code completion etc.

let you write your three pages
and let them re-use the rendering code in the class library

whilst also letting you write complex dhtml/javascript apps
without this sort of kludge:

Response.Write(@"
<input type='button' onclick='
alert( ***read below );
'
");

***
do you see the problem here?
i can't use single quotes in the alert('hello'); method
because it will break the html single quotes

i have to use html single quotes
otherwise it breaks the C# double quotes

thus here are my choices:

the only way around this is to use "" instead of ' in the html
which means it isn't html literal anymore

the whole point in code blocks is to allow us to use html
unchanged

as codeblocks are just another syntax for response.write
it is ridiculous that we are prohibited from using them
in methods and classes

please somebody say you understand me!

i know i am right!

 

[John Horst]

Good grief...

You can always escape the double quotes.

Response.Write("<input type=\"button\" onclick=\"alert('this is a
message')\">");

will do what you are talking about.

And when you talk about libraries for rendering HTML, that is exactly
what ASP.NET server controls are. As an example, the Label control is a
library that renders a <span> tag with the label text as the innerText
of the element. If you wanted something to happen client side when the
user clicks on the span, you would do something like this in your
codebehind.

this.lblTest.Attributes.Add("onclick", "alert('You clicked me!');");
this.lblTest.Text = "Click me!";

The server would then replace the <asp:Label runat="server"
id="lblTest"...></asp:Label> in the aspx page with this:

<span id="lblTest" onclick="alert('You clicked me!');">Click me!</span>

before sending the response to the browser.

ASP.NET, from the Page class to all of the server controls, is nothing
but a bunch of rendering libraries. But what it does is allow you to
apply OOP to web programming. The TextBox class, for example, renders
an <input> tag. I recently created a class that inherits from TextBox
and adds color properties so a programmer can specify at design time one
back color when the text box gets the focus (say yellow) and another
when it loses the focus (normal white). All I have to do is drop that
control on a page and I get all the standard textbox functionality plus
my client side onfocus and onblur events.

Additionally, the rendering happens both in the VS designer surface as
well as the browser at runtime, so you can use standard HTML to organize
a page and server controls to handle the dynamic stuff. If you use
typed datasets you can actually have complex pages with grids that all
look at design time pretty much like what the user will see.

Get a book on server controls and actually start to write a couple and
you'll have a much better understanding of ASP.NET and why the kind of
rendering you're talking about is not supported at the page level
(server controls make it unnecessary).

In an earlier post you said you did not like user controls. On that I
agree. Once you get your head wrapped around server controls, user
controls kind of lose their appeal, not to mention that server controls
are more reusable.

John

 

[John Rivers]

Thankyou for your well-meaning response,

I understand everything you are saying

but, as i have said before, the approach
you mention would be greatly improved
by the use of codeblocks, they are
after all simply a different syntax to

response.write

but you will accrue these benefits:

- color coding of html and javascript and dhtml dom
- code completion of html and javascript
- syntax checking of html and javascript
- ability to use actual html rather than a messy escaped version
which gets very unmanageable when javascript is involved

plus what i am suggesting will not inhibit ANY of the things
you mentioned

just make them quicker and easier to implement, manage and debug

i have used every approach available in .net to build a simple page

and the one that works the best

is using the methods and classes with codeblocks

in other words what i am suggesting is an EXTENSION, and IMPROVEMENT
to the current offering, adding CHOICE and FLEXIBILITY

yet people on this newsgroup seem to resist that

which i find rather odd

here are some other ideas for microsoft to consider:

- allow build time compilation of aspx as an option to help
speedup the development process

- allow codeblocks in both pre-compiled and jit-compiled code modules
(ie: aspx and aspx.cs) its all presentation anyway

- allow optional precompilation of aspx to dll, this would allow
us to use the flexibility of jit compilation IF it suited us or not



and some comments on the mass confusion i have seen here on
multi-tiering and seperation of presentation code etc.

- writing a method or using a class doesn't imply you are writing
business logic
- total separation of presentation from business logic is impossible
for obvious reasons so multi-tiering as it is commonly understood is an
over simplistic concept that misses the fact that there is
cross-dependency between presentation literals (html) presentation
logic (asp.net) and business logic (dll)

as an example, due to the disconnected nature of http apps, the
database
locking that can be used in a connected application simply doesn't
work,
users of a web app can overwrite each others work without breaking
database level locking, so we have to now introduce a new, custom,
locking
architecture to protect our data, in doing this we have now created an
integration (as opposed to separation) of tiers, each tier depending on
intimate knowledge of the next - business logic can simply not exist
without understanding the extra locking requirements required of a web
app

thus a more realistic conceptual model for tiering is this:

presentation layer (html / javascript literals)
presentation logic layer (asp)
business logic / presentation logic integration layer
business logic layer

also the very concept of layers / encapsulation is very dangerous
many developers seem to that encapsulation is "a good thing" whatever
especially java programmers, one reason win32 is so powerful
is that the whole api is broken down and tiny parts and their
is hardly any encapsulation at all - its hell to program but
you can do anything

an easy to understand example of over-encapsulation is the classic asp
session state model

it could have been broken down into these parts:

- sessionid generation
- http roundtrip management (cookies / url munging)
- serialisation mechanism
- volatile storage (session object)
- persistent storage (sql)

this would have allowed people to use the parts
that they liked

it would have also enabled a hybrid storage concept:

- during website operation sessions to be stored in ram
- during restarts, to be persisted to allow
for maintenance restarts without losing current sessions
on a single server

(ie: if you have a thousand shopping baskets full of goodies
you don't want to kill them and annoy your customers)

instead we got over-encapsulation, we either had to use all of it
or none

which meant in my case having to build a custom serializer
and session architecture

plus this multi-tiering often leads to alot of "plumbing" and
"remoting"
code that introduces problems that often outweigh the slight advantages
gained, often latent advantages that are never realised by the way
(solving problems that never happen)

similar the htmlcontrols in asp.net
whose declared purpose is:

- solve problems of multiple html versions
(unrealistic - we will end up hand coding to get professional results
like we always have)

- create an event-driven model
(inappropriate, over-complex, introduces unpredictability and
non-deterministic behaviour, ie: it is very fragile and hard to debug)

just read these newsgroups for hundreds of msgs proving it

have a good day

 

[Guest]

You're still missing the point. Code blocks are MESSY. The idea of .NET is to
provide a tool for LARGE projects with many people involved. From my
experience web scripting technologies like ASP/PHP are not good for big
projects at all (even for small ones – no debugging, global variables,
variants, week utilities (both environmental and programming), no managed DB
providers, bla bla bla. I agree you can design web application in ASP quite
nicely, but at the end you can do it much better and QUICKER using ASP.NET.
Believe me, I’ve seen so many ASP projects that are extremely messy. Apart
from mess, I couldn’t see anything like “Design path†in those projects.
Therefore almost everyone who took a part in development (especially bloody
vb-global-hyper programmers) introduced their “nice†programming ideas .
Again, every company tries to reduce development time (which means money) and
it can be done by using more efficient and standardized tools like for
example ASP.NET, J2EE, where you can find many useful features. Realize ASP
way of thinking is a bit old – you can still use it, but soon you’ll get no
job . Don’t’ be tenacious and try to understand OOP.