Shamil Salakhetdinov
shamil at smsconsulting.spb.ru
Wed Feb 9 05:24:20 CST 2011
Hi Jim -- MS does realize the issues "bound" to classical ASP.NET view engine - they seems to have a solution: Introducing "Razor" - a new view engine for ASP.NET http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx It "works with any Text Editor: Razor doesn't require a specific tool and enables you to be productive in any plain old text editor (notepad works great)." :) Well, but this "Razor" view engine seems to be bound to ASP.NET MVC? No, wait.... "Razor" view engine and DNN - they say it will be part of DNN 5.6.2 http://www.dotnetnuke.com/Resources/Blogs/tabid/825/BlogID/15/Default.aspx So - ASP.NET - "Razor" View Engine - jQuery (it's supported by MS) ===================== Totals as a very advanced yet lightweight, fluid (flexible) Web development platform resulting in clean HTML "by definition"? (I'm kidding about the latter of course - one have to be very skilled in HTML and CSS to produce clean HTML IMO). And "Razor(CSHTML)" seems to be so much classical ASP like? Thank you. -- Shamil -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: 9 ??????? 2011 ?. 10:18 To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] From a reader I think that ASP.Net is a great program but if you just let the system create the forms for you, there will be so much traffic going on behind the scene that a big commercial application would have to have a server farm just to run it. By default the program wants to create some kind of bound BE... total insanity as far I can see. (duck and cover) ;-) What has to be done after the FE is boiler-plated together, is you have to go in and remove hundreds of lines of extra code and hand code the data connection... I know just how you feel. I have written very few applications compared to the dozens I have had to come in and cleaned up. When the app is completed it just snaps in comparison...and this is not rocket science...if I can do it anyone can. I think if any mid-range commercial application (20K hits per hour) needs more that 2 servers to manage the operations BE; this is not counting data storage, backup, fail-over, security or mail boxes but the real BE manager, there is a problem with how the app was written. I have seen so many systems where the techs just keep throwing more hardware at a blotted web application when just cleaning up the code, would solve so many problems. One day there may be a web building program that can build super tight code but not today. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Tuesday, February 08, 2011 4:21 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] From a reader Hmmmm, actually, I'd be leery of a 'commercial site' using strictly notepad. What about data? Now if you gave them a blank .mdb, or access to a blank SQL Database, and they created the entire data structure using T-SQL, ok, I'd be impressed! LOL What is the most striking issue, in my book, is just understanding the concepts of what your 'tools' are really doing in the back ground. ASP.Net is pretty slick, but boy, if you don't really understand what it is doing in the background, you are going to create one heck of a mess if you aren't careful. I just went through the wringer with a side project. It's a rebuild of a web form I built about 6 or 7 years ago. The original form was built using classic ASP, and VB 6 (for .dll's that did the business logic with the database). Way back then, I wasn't very good with javascript, so I was kind of limited on what I was doing from the client scripting side. They wanted several changes to that form, so we rebuilt it in .Net. There's a very long story as to what put me through the most hell, but one of the things that just boggled my mind was a 'custom' application they used on their end. They called it Passport. Basically, it was a custom 'user login' platform. In an NT environment, with multiple forests/domains, an 'intranet' in such an environment can't truly utilize Active Directory accounts. Not without some serious workarounds. So they built a 'system' to allow users to 'log in' to their Intranet, that controlled what applications various users could use. Now, technically, all my system needed to know was the username of the person currently 'logged in'. That allowed me to filter certain information for just that user. That's it. The rest of my application was strictly its own system, with its own database, etc. I had my project setup so that there were only 3 places where I needed to 'inject' this custom systems 'logged in user', which I was using a querystring value for development/placeholder purposes. Instead of just saying, ok, use this 'code', what I ended up having to do, is setup a complete server (virtual) with SQL Server, and VS 2010, so they could 'install' their system, because they wanted me to send them a 'complete' project. The reality was, I had to take my project, and make it a 'sub' project to theirs. What a pain. And what OVERKILL when it comes to that system. Lord have mercy, the complexity they threw into this thing...... it was the equivalent of using Airforce 1 as a golf cart..... Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Tuesday, February 08, 2011 2:45 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] From a reader No one should be able to build a web site with any tool until they can prove they can build a commercial site with note-pad. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Tuesday, February 08, 2011 11:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] From a reader The funny thing is, the reason Access gets such a bad name is that it can be used by amateurs, and when that happens, you get clunky. A professional Access developer understands what an .mdb is. They understand the inner-workings enough to optimize performance. This is the same reason so many 'clunky' web applications have been made. How many Access pro's could tell you EXACTLY what Jet is doing when you are running 'SELECT * FROM tblSomething WHERE ID=1' against a table in a backend .mdb? Probably very few. How many could give you a conceptual statement as to what is happening, like 'Jet is reading the index values from the b/e .mdb, and then using that information to determine where to start reading the table data'? Probably most. Yet how many 'amateurs' have even a conceptual understanding? They don't need to, Access just does things for them. Same problem with the web. There are a WIDE variety of tools available, that let someone with little to no understanding of a website/webserver/browser system throw a 'fully functioning' (<--- term used very loosely) 'website' (<---also used very loosely) up into production. It has been this way for a while. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms Sent: Thursday, February 03, 2011 8:30 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] From a reader I just LOVE that word "Clunky" to describe a web app !! When everyone says how great the web is, I just point out all of the "clunky" webapps I have to tolerate....from my bank, to my insurance company, and on and on it goes. Then I get to a client site and have to tolerate all of THEIR clunky webapps. They are slow, they don't respond, they forget to validate, etc, etc., they don't integrate with windows, they don't cut-and-paste properly, and the list just goes on forever. I'm going for a long, long winternight's sleep. Someone wake me up when all clunky web apps have been upgraded to Web 2.0 standards. > make it 'look' like an access combobox, and act like it, but what's > happening in the background is clunky. First, .Net is creating > javascript on the client side that is reacting to the 'OnClick' of the > combobox (or index changed event), then it's sending all the current