Silverlight: the art of subsetting

Dog Breeding » Silverlight: the art of subsetting

Dog Breeding » Silverlight: the art of subsetting — Thu, 01 May 2008 19:37:14 GMT

PingBack from http://dogs-pets.info/dog-breeding/?p=929

re: Silverlight: the art of subsetting

Joe — Thu, 01 May 2008 20:35:42 GMT

Appreciate the post. I agree it is a difficult problem.

I don't understand the issue with testing though. Surely if you used the existing WPF code for templating then that would result in less testing - it already works in WPF ! at the moment you support two code bases - which doubles the work.

Didn't the same apply to getting the framework working initially? A few scattered conditional compliation directives?

Could you take the same approach for Silverlight? Cross compile the code from WPF. To prevent it from getting too big mark large chunks should be modular and optional. You mention Media.Drawing - make this a separate assembly that can be brought into the application install. If the user doesn't want to rewrite part of their app then they can just include the assembly and keep it as it is. Triggers and other core functionality should be in the core DLL, and bring back the visual/logical tree split.

I would like to see this apply to other parts of SL2 that are already in the core build to reduce the size. Like DeepZoom and some of the controls that are rarely used. Make it all optional on demand download.

Is it too late for this now? Are we really talking about SL3 requirements?

re: Silverlight: the art of subsetting

Josh Smith — Thu, 01 May 2008 21:34:56 GMT

Hi John,

Great post. Thanks for the informative tease.

You stated: "And in the future, when we add Triggers into Silverlight they are completely compatible with the Parts and States model...providing the best of the two models."

I question whether having the best of both models results in something superior to "merely" having the best of one. By the way you described it, the Parts and States model seems like a stopgap until triggers are properly implemented in Silverlight. Despite any advantages it might have, once a stopgap solution goes live, it must be supported and continue to exist thereafter. It's a shame to force oneself into a position where one must maintain backward compatibility with a stopgap solution.

It's exciting to watch this process unfold. All eyes are on you...keep up the awesome work (please)! :)

Josh

re: Silverlight: the art of subsetting

JohnGossman — Fri, 02 May 2008 05:27:48 GMT

To Josh:

The Parts and States model is not a stop-gap...as I said, I believe it adds structure to the Template that is useful. When we add Triggers, I'm not suggesting just adding Triggers with Setters, I'm also suggesting a "GoToState" custom Action, so we can pull the code that triggers the State transitions out of the controls and into the Template, but keep the structure available.

To really see the power though, you'll have to see the next iteration.

re: Silverlight: the art of subsetting

JohnGossman — Fri, 02 May 2008 05:29:28 GMT

Joe,

Desktop WPF was written as a Windows component with no size or portability concerns. As a result, when we started building Silverlight we found it impractical to simply conditionally compile the code and get a smaller version. Most of the code in the WPF framework that is in Silverlight is new.

re: Silverlight: the art of subsetting

Oran — Fri, 02 May 2008 07:33:52 GMT

So is the new teaser Parts and States model ready to roll today in WPF since it uses existing APIs, it's just Silverlight that's the hold-up? Or will WPF need enhancements to take best advantage of it?

I'm really curious to see if Silverlight becomes the "strangler app" of WPF, with WPF getting some of the innovation hand-me-downs from Silverlight (months later, sort of like Office on Mac) until eventually everyone agrees that 99% of new apps are written Silverlight-first anyway, so we might as well send WPF to Branson to perform alongside WinForms to a bunch of technology-hospice developers. Silverlight-first innovation (as opposed to WPF-first) makes a ton of sense as far as minimizing the number of new subsetting issues, but it leaves WPF as a sitting duck that will first be marginalized, then eventually overtaken by Silverlight. As far as I can tell, WPF is "done", just like COM is "done". Not dead, just done. Sliverlight is getting all the love, and I bet it's about to get even more love as the preferred UI and deployment package of the "internet OS," (Live Mesh) while WPF will be the preferred UI of the "classic OS."

Sorry to sound so negative, it just seems like a shame that 5 years from now 90% of .NET developers will be writing Silverlight apps, while maybe 5% will have written WPF apps. Of course if that will be the case, I guess it's a good thing Silverlight is getting so much love.

re: Silverlight: the art of subsetting

JohnGossman — Fri, 02 May 2008 16:55:33 GMT

Oran,

There will be times when we add something to Silverlight first, but the desktop Client is a long ways ahead of the web client in functionality and we'll be continuing to add stuff there too. Deployment concerns are always going to limit how much we add to Silverlight...so I don't see it "overtaking" the desktop version for at least a decade.

re: Silverlight: the art of subsetting

Joe — Fri, 02 May 2008 20:36:00 GMT

John

I know I'm simplifying things, but you said that WPF was written as a desktop platform with no size limitations - but couldn't the same be said of .NET. You managed to pull it off for that. It just seems a shame that you couldn't go the last mile and do it the same for the UI portion too.

Sure there are OS specific parts in WPF - but this also applies to the core framework. Just conditionally compile them out.

The problem is that this becomes a long term concern. There will always be differences in these two platforms and those differences are going to cause a big headache for developers. What you're seeing now is the tip of the iceberg.

I've tried porting some of my WPF code already to SL2 B1 and frankly gave up. So much code needed to change it was basically becoming a rewrite.

re: Silverlight: the art of subsetting

JohnGossman — Fri, 02 May 2008 20:59:21 GMT

Joe, believe me, we very, very much wanted to use the same code for WPF on desktop and web...but it was impractical. Many other parts of .NET are much less platform dependent.

re: Silverlight: the art of subsetting

JohnGossman — Fri, 02 May 2008 21:00:59 GMT

I should add, we fixed a large number of incompatibilties between desktop WPF and Silverlight between Beta1 and Beta2 (stay tuned).

re: Silverlight: the art of subsetting

Joe — Fri, 02 May 2008 23:52:49 GMT

Thanks John

I'm looking forward to beta 2.

Maybe somebody from the team could provide some best practices of maintaining a WPF and SL tree in parallel. I mean sharing source code, including resources that are common etc...

Once you also freeze your feature list I would like to see a categorical list of differences - just to save time when porting and trying to track down something that just doesn't seem to work, on either side.

Forgive the ranting, you are producing some great technology - it's just a little frustrating on the edges.

re: Silverlight: the art of subsetting

Neil Mosafi — Sat, 03 May 2008 14:36:08 GMT

John

Thanks so much for this post. I have read lots of posts which describe the "what" about Silverlight but none of them describe the "why"!

I feel much more comfortable knowing that you are aware of some of the issues and actively working on them for beta 2 - your comment saying you already fixed a large number of incompatibilties between desktop WPF and Silverlight between Beta1 and Beta2 made my mouth water in anticipation!

Any idea of a rough date? ;-)

Regards

Neil

re: Silverlight: the art of subsetting

John Lam — Sat, 03 May 2008 20:09:38 GMT

Wouldn't some kind of a tool like a WPF 'lint' be very useful in the scenarios that you described?

re: Silverlight: the art of subsetting

Joe S — Sun, 04 May 2008 00:44:54 GMT

We have already dropped a couple Silverlight applications we had originally proposed into contracts for future applications. There are quite a few reasons for this. A lot of the developers we have already know WPF which cost our company money to get them up to speed. Seeing as how Silverlight is deciding to require different coding techniques specifically with the control templates and how that impacts both our developers and designers, it's too much a financial liability on the company now to keep retraining people on like technologies which require specifically different skill sets. I am also a developer and i must say that after using the new control templating/parts model, its awful. It takes far too long to accomplish what was easily done in WPF. It requires the designer to jump into the code which is not somewhere they should be. I keep hearing about how "tools" will be easier to write with the new control template/parts model and frankly, I don't care about the tools. I care about the way the technology works, and to me, the parts model is cumbersome and I hope that it is fixed/changed back to the way it works in WPF.

re: Silverlight: the art of subsetting

Mark — Thu, 08 May 2008 19:31:26 GMT

John,

Its really nice to hear from somebody making the decisions about the tradeoffs involved in bringin Silverlight out. Your explanation on the Template Model and some of the background involved is really helpful.

However, there is one pain point that I wonder if you could go into: Why does SL not have an ICommand interface.

I understand the complexity of RoutedEvents and the debate about event propagation through a visual tree verses the application logic as you mention in http://blogs.msdn.com/johngossman/archive/2008/02/06/more-on-mvc-and-m-v-vm.aspx however, as you also indicate in that post you actually do like the ICommand interface itself.

Why isn't the interface itself defined. That would let me implement my own ICommand approach or more easily integrate with things like Prism. With the core interface missing however, it leaves one of the fundement building blocks missing and from what you said its not the ICommand interface that you have issues with but the implementation.

I also understand the space and testing constraints but how much space and testing time would be consumed by including an ICommand interface with ZERO implementing code just to permit easy duplication of the programming pattern. If it's the programming pattern itself that you want to prevent, can you perhaps explain a little about why that is?

Thanks!

re: Silverlight: the art of subsetting

JohnGossman — Thu, 08 May 2008 22:44:31 GMT

Mark,

Good question about ICommand. We definitely want to promote, not prevent, the programming pattern. That said, commanding was on the bubble for Silverlight in favor of staffing must-have, user cannot duplicate features. You can of course implement your own ICommand interface and use it. I intend to prototype this and blog it, including use the Attached Behavior pattern to hook controls to Commands even though the built-in controls do not support them.

Stay tuned.

WPF/Silverlight/XAML Web News - 2008/05/09

Rob Relyea - Xamlified — Fri, 09 May 2008 14:59:52 GMT

WPF Controls Emphess.Net: A MenuKiller Control - this article is a work in progress detailing how to

VisualStateManager for desktop WPF

Tales from the Smart Client — Sat, 09 Aug 2008 01:31:42 GMT

As I’ve described before , we introduced the new VisualStateManager concept into Silverlight WPF before