Re: ASPX now with methods and classes

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 :P. Don’t’ be tenacious and try to understand OOP.
--
Milosz Skalecki
MCP, MCAD


"John Rivers" wrote:

>
>
>
> 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 :)
>
>
>
>
>
>
> John Horst wrote:
> > 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
>
>
.

Loading