Why more Single-Page support in Whidbey?

  • Thread starter Thread starter Bruce W.1
  • Start date Start date
In the upcoming Whidbey version of Visual Studio, there will be more
support for Single-Page Architecture (as opposed to code-behind).

Does anyone here know the motivation for this? What's wrong with
code-behind architecture? What's the future of code-behind?
Click to expand...

Hi!

I don't think the point is to move back to the single-page-design. Visual
Studio calls itself the world best IDE (which isn't so far off the truth).
The old Visual InterDev 6.0 also had the ability to edit in-page-script
blocks with intelli-sense. So it made me wonder why MS didn't continue to
provide this feature with asp.net. So they maybe are just re-adding a
feature that was lost (at least in VS2002). How can it call itself the best
IDE if such simple features aren't supported?

Also the single-page design may be more comfortable to most programmers
(asp, php, ...). Why exclude such a big group of developers?

Nevertheless, code-behind is one of the biggest benefits of asp.net. It made
web-programming so much easier and faster. As XAML (Longhorn's way of
application-programming, xml + code-behind) uses the same design, microsoft
will definatly not go back to a single-file architecture.

mat
 
I sure hope Whidbey will live up to the claim of being the best IDE. In
order to do this it needs thorough support for refactoring and
code-generating very common tasks (like creating a property out of a private
field). I need to be able to painlessly move classes to another interface,
rename classes, get a list of every place a class or method is being used,
be able to extract interfaces, etc etc etc before they have me sold on the
"Best IDE" boast. Impossible for an IDE to do this? The opensource IDE for
Java named Eclipse does this today.
 
Bruce,

It would help with the problem of inheriting the same code-behind page on
multiple pages because currently when you do this, you can't use the code
behind of the inheriting page, you have to put any overriding code into the
aspx page (you've already used your code behind as the common one). So
there's a huge penalty currently for using a common code behind page that
will be reduced with having intellisense, et al in the aspx page.

Brent
BugMonitor.com
 
Back
Top