ASP.Net 2.0 - Amazing
Joined: 04-Aug-2004
Joined: 04-Aug-2004
Jeff wrote:
I've my doubts. Writing a proper gui in webforms will still be based on stone-age technology like HTML. Checking a checkbox and with that disabling parts of the gui is basic stuff in a winforms client but hard in a webform client.
You're right. Let me rephrase what I meant. HTML is stone age and doesn't come close to providing the UI capabilities of a WinForm. But, when it comes to WebForms: when you need them, you need them. What I meant to say is: with ASP.Net 2.0 you can write a good browser app with about the same coding effort as a good WinForm app.
Oh, ok 
I fully agree with that! If the choice is 'webforms' then you have a much better experience in asp.net 2.0, fully agreed!
Makes sense, and for those times when I'm stuck with ASP.NET, definitely I'm looking forward to 2.0. 
Joined: 18-Aug-2003
Joined: 09-Jul-2004
Joined: 18-Aug-2003
Otis wrote:
swallace wrote:
The key to understanding the difference is in getting to know the new Longhorn interface and how it delivers winform/webpages. VS.NET 2005 is built with that in mind. This is why the two have different databinding, because the WinForms method is going away in the long run.
I disagree. Ok, Xaml will probably merge the two, but I don't see that happen in 3, 4 years. I think they have different databinding scenario's simply because there are two teams and for the past 10, 15 years, they haven't been able to provide a databinding framework which actually works and is easy to extend.
Web has a different model because there isn't a currency manager on the form, as the form is gone when the page is rendered. Instead of 'adopting a subset' they cooked up something different. The annoying part is: they don't care, as THEIR dataset crap works with the two models and no-one knows how/why as they refuce to document it properly. (for example why isn't there an interface you can implement like ITypedList. Why is ITypedList failing now? ... and why is it so (#$^@&^$@ hard to get this all working... It's not rocketscience, just grab the properties supplied and that's it...
Perhaps you're right. I certainly agree that this thing will take years more to get out the door, and many more to achieve acceptance. A friend and I were looking at how many people we know today who where still using Windows 95-derived products, and realizing that will likely mean that Longhorn will take up to ten years to achieve true market penetration.
Secondly, you really need a break... 
swallace wrote:
Otis wrote:
swallace wrote:
The key to understanding the difference is in getting to know the new Longhorn interface and how it delivers winform/webpages. VS.NET 2005 is built with that in mind. This is why the two have different databinding, because the WinForms method is going away in the long run.
I disagree. Ok, Xaml will probably merge the two, but I don't see that happen in 3, 4 years. I think they have different databinding scenario's simply because there are two teams and for the past 10, 15 years, they haven't been able to provide a databinding framework which actually works and is easy to extend.
Web has a different model because there isn't a currency manager on the form, as the form is gone when the page is rendered. Instead of 'adopting a subset' they cooked up something different. The annoying part is: they don't care, as THEIR dataset crap works with the two models and no-one knows how/why as they refuce to document it properly. (for example why isn't there an interface you can implement like ITypedList. Why is ITypedList failing now? ... and why is it so (#$^@&^$@ hard to get this all working... It's not rocketscience, just grab the properties supplied and that's it...
Perhaps you're right. I certainly agree that this thing will take years more to get out the door, and many more to achieve acceptance. A friend and I were looking at how many people we know today who where still using Windows 95-derived products, and realizing that will likely mean that Longhorn will take up to ten years to achieve true market penetration.
Exactly!
For marketing reasons, it's good to be there when a new platform launches, though the majority of users won't be on .NET 2.0 by Nov 7th, I can assure you. (we still have customers using .NET 1.0!
Secondly, you really need a break...
heh Yeah, though I'm not seeing a quiet moment on the horizon... The Nov 7th date for VS.NET is earlier than I expected.
Joined: 18-Aug-2003
Otis wrote:
heh
I was surprised to see that, too. I've been working with Beta 2, and while it might be possible to fix everything by then, I doubt it. The product is a great leap forward (Microsoft-China-Communism joke there...) from VS 2003, and the features will certainly sell it, but I don't know if those features can overcome a buggy product.
Aside from the development environment, the new Team System portions are far from feature complete, much less ready for beta. They look like they were hacked together from Visio diagrams in time to meet the beta 2 deadline. While VS 2005 will be a mature product in terms of features (though buggy), Team System is very much a Microsoft 1.0 product, if that.
The Team System is an idea long in coming. Getting these tools together matches the Microsoft strategy used in Office, of bringing tools together and creating benefits from shared interface and interaction. However, none of the individual components is the best available. They will grow, and by the time of Team System 3.0 (shipping with Visual Studio 2009, code name 'Hawaii'), it could really be an important product.
However, we're not building a business around it just yet.
(Was all of that off topic? Oh well...)
Things I'm looking forward to using in VS2005:
- Not using IIS to develop web pages,
- Generics,
- Object designer (yes, I'm a visual guy...),
- New Visual SourceSafe in SQL (Saints be praised!),
- Templates in ASP.NET (been using them already with Paul Wilson's MasterPages in ASP.NET 1.1. Great stuff!)
- Visual SourceSafe via HTTP,
- I'm sure there's more....
swallace wrote:
Otis wrote:
heh
I was surprised to see that, too. I've been working with Beta 2, and while it might be possible to fix everything by then, I doubt it. The product is a great leap forward (Microsoft-China-Communism joke there...) from VS 2003, and the features will certainly sell it, but I don't know if those features can overcome a buggy product.
Hmm, that's pretty bad! Because it costs a lot of money, and the big guns are already preparing to standarize on it (why I have no idea, as the ideas are already available for ages, including the tools, it's just as if they don't realize there is a whole world out there beyond what MS produces...). I haven't tried it out yet in full (with teamserver), just the client. I also find the requirements pretty huge. For the functionality it provides, it requires a whole serverpark it seems. That might seem normal but it isn't, it's bad. 1 GB of memory is a truckload of memory, several servers to get sourcecontrol up and running is just plain silly.
Aside from the development environment, the new Team System portions are far from feature complete, much less ready for beta. They look like they were hacked together from Visio diagrams in time to meet the beta 2 deadline. While VS 2005 will be a mature product in terms of features (though buggy), Team System is very much a Microsoft 1.0 product, if that.
That will cause some long faces I'm sure!. MS Marketing will be able to sell it, I'm sure, but if it's simply shabby, it will do them no good.
The Team System is an idea long in coming. Getting these tools together matches the Microsoft strategy used in Office, of bringing tools together and creating benefits from shared interface and interaction. However, none of the individual components is the best available. They will grow, and by the time of Team System 3.0 (shipping with Visual Studio 2009, code name 'Hawaii'), it could really be an important product.
I doubt it. It's already too late I think. It's too expensive for the small shops (and too intensive for servers.) and those will use the tools aready available like vault or subversion.
Things I'm looking forward to using in VS2005:
- Not using IIS to develop web pages,
- Generics,
- Object designer (yes, I'm a visual guy...),
I fail to find it useful. Perhaps it's because it's so darn slow. I simply can't imagine how a tool which pushes just a few diagrams around on a screen can be so incredibly slow on a 3Ghz Xeon box. I appreciate the direction they're taking for making modeling more important, and everyone knows that Visio is nice, but for PRODUCTIVE modelling it isn't functional, though if a tool is SLOW on top hardware it's IMHO badly (or better: sloppy) written software.
- New Visual SourceSafe in SQL (Saints be praised!),
You're kidding right? 
Joined: 18-Aug-2003
I'll address some things, but I'm lousy with the quoting thing so you'll just have to read from above...
In shops that force Microsoft standards, the coming of a new, more secure and reliable SourceSafe is a wonderful thing. Not everyone gets to use the tools that work, we're stuck with those that cost top dollar. If SourceSafe doesn't barf on me anymore, that's a good thing.
I think the value of Object Designer (much like Team System) is in it's promise, not it's current features, which, no doubt, makes me sound like a Microsoft apologist. Object Designer is a pig with lipstick, and so is the Beta 2 version of VS 2005. I wouldn't expect this to be the case (quite so badly) in the release version, and within two years (geez) the resource pigishness won't be so noticable because hardware will advance.
The promise of Object Designer originally was in integration of objects and other items. However, in it's current release it only does one thing, and that's draw objects and create code from those drawings. But that's just the camel's nose; there's much more coming.
For example, visual integration of objects and ObjectSpaces, so that the developer could visually tie objects to storage. Believe me, this is still coming, and it's something you should take into consideration. The chance to have ObjectDesigner linked to the Diagram designer in MSSQL, then cut all the code needed, is tempting. There's a reason there's no Diagram designer in SQL 2005 (in the betas I saw) like there is in the current version. They're not done with Object Designer, and ObjectSpaces, and the linking thereof.
Other examples include objects and rights to them via ActiveDirectory, objects and staging (instatiation at runtime) on various servers, connections to BizTalk, connections to form fields, and more, all with the code being created as you draw. Managers love this crap, and frankly, so do I (if it works).
We're a long ways from understanding the impact and implications of ObjectDesigner.
You're right, the costs of implementation of Team System, called the Team Foundation Server, is high. I heard they jacked up the price for the product and MSDN subscriptions, not to mention the costs of servers.
I get the feeling, however, that the goal is to offer Team Foundation Server hosting for small developers. Seems nuts offhand, but, just as I do shared hosting of IIS and SQL at my ISP, it's not impossible to do a shared hosting of Team Foundation Server. Small developers could really benefit costwise, plus be able to share stuff with contract customers easier than it is today. Team Foundation Server includes outputing reports and stuff to SharePoint, so that contract customers can view bugs, progress, requirements and goals that way, without having to have Visual Studio.
Sounds good, but of course implementation is another matter. Team Foundation Server is a living pig today, eating resources as though Microsoft owned every memory fab plant in the world.
However, this product's got legs, and I expect that three years from now it will be de rigour for many contractors.
Joined: 26-Oct-2003
swallace wrote:
I'll address some things, but I'm lousy with the quoting thing so you'll just have to read from above...
In shops that force Microsoft standards, the coming of a new, more secure and reliable SourceSafe is a wonderful thing. Not everyone gets to use the tools that work, we're stuck with those that cost top dollar. If SourceSafe doesn't barf on me anymore, that's a good thing.
I think the value of Object Designer (much like Team System) is in it's promise, not it's current features, which, no doubt, makes me sound like a Microsoft apologist. Object Designer is a pig with lipstick, and so is the Beta 2 version of VS 2005. I wouldn't expect this to be the case (quite so badly) in the release version, and within two years (geez) the resource pigishness won't be so noticable because hardware will advance.
The promise of Object Designer originally was in integration of objects and other items. However, in it's current release it only does one thing, and that's draw objects and create code from those drawings. But that's just the camel's nose; there's much more coming.
For example, visual integration of objects and ObjectSpaces, so that the developer could visually tie objects to storage. Believe me, this is still coming, and it's something you should take into consideration. The chance to have ObjectDesigner linked to the Diagram designer in MSSQL, then cut all the code needed, is tempting. There's a reason there's no Diagram designer in SQL 2005 (in the betas I saw) like there is in the current version. They're not done with Object Designer, and ObjectSpaces, and the linking thereof.
Other examples include objects and rights to them via ActiveDirectory, objects and staging (instatiation at runtime) on various servers, connections to BizTalk, connections to form fields, and more, all with the code being created as you draw. Managers love this crap, and frankly, so do I (if it works).
We're a long ways from understanding the impact and implications of ObjectDesigner.
You're right, the costs of implementation of Team System, called the Team Foundation Server, is high. I heard they jacked up the price for the product and MSDN subscriptions, not to mention the costs of servers.
I get the feeling, however, that the goal is to offer Team Foundation Server hosting for small developers. Seems nuts offhand, but, just as I do shared hosting of IIS and SQL at my ISP, it's not impossible to do a shared hosting of Team Foundation Server. Small developers could really benefit costwise, plus be able to share stuff with contract customers easier than it is today. Team Foundation Server includes outputing reports and stuff to SharePoint, so that contract customers can view bugs, progress, requirements and goals that way, without having to have Visual Studio.
Sounds good, but of course implementation is another matter. Team Foundation Server is a living pig today, eating resources as though Microsoft owned every memory fab plant in the world.
However, this product's got legs, and I expect that three years from now it will be de rigour for many contractors.
Ya'll did hear about this, right? http://blogs.msdn.com/robcaron/archive/2005/05/12/416915.aspx
swallace wrote:
In shops that force Microsoft standards, the coming of a new, more secure and reliable SourceSafe is a wonderful thing. Not everyone gets to use the tools that work, we're stuck with those that cost top dollar. If SourceSafe doesn't barf on me anymore, that's a good thing.
heh What I always hated about VSS is that it makes the files readonly AND creates a lot of goo in the vs.net project files. (this is more related to the VSS integration in vs.net thoug), and it also can't handle multiple times a project in a different solution.
The promise of Object Designer originally was in integration of objects and other items. However, in it's current release it only does one thing, and that's draw objects and create code from those drawings. But that's just the camel's nose; there's much more coming.
For example, visual integration of objects and ObjectSpaces, so that the developer could visually tie objects to storage. Believe me, this is still coming, and it's something you should take into consideration. The chance to have ObjectDesigner linked to the Diagram designer in MSSQL, then cut all the code needed, is tempting. There's a reason there's no Diagram designer in SQL 2005 (in the betas I saw) like there is in the current version. They're not done with Object Designer, and ObjectSpaces, and the linking thereof.
It depends I think. What I ultimately want is that the application reverse engineers a db to a NIAM model and you use that to produce entity code and also your db model.
I find thinking in classes too detailed. The point is that you miss an abstracted version of the reality, i.e.: you're modelling on the level of realization, but you should model on the level of that it makes sense in a model, how it is realized is up to the tool. In NIAM and also E/R you see that clearly: m:n relations are physically realized using an intermediate table, though in the model the intermediate table isn't there. You might say: "that's a detail", but there are numerous examples for this.
The main advantage of it is that you think in theoretical elements, not in technical elements. Theoretical elements can be applied to a technological platform, though that's something to deal with later on, when the model is done. If you let your thinking lead by technological elements, you also limit your thinking with the technical limits of the elements you're using, running the risk of missing a solution.
I therefore don't fear a class modeller which can tie to a database, as I don't envision that as a futuristic idea.
What I think will be the feature of the (near) future is having entity representing classes in your model and you apply functionality on them via AOP. This functionality can be persistence functionality but also BL functionality.
Other examples include objects and rights to them via ActiveDirectory, objects and staging (instatiation at runtime) on various servers, connections to BizTalk, connections to form fields, and more, all with the code being created as you draw. Managers love this crap, and frankly, so do I (if it works).
Pretty pictures always do their job well Ultimately you want a design which is directly executable, so you don't have to write any code. A visual language professor once told me: "We already have such a language representation form. It's called ascii".
We're a long ways from understanding the impact and implications of ObjectDesigner.
I think it'll appeal to some people but not to all people. Yesterday I talked about it with a friend of mine and he said "I use UML for the whiteboard to explain things, but not in models to generate code... because often it's faster to simply type it in". I think he has a point.