Skip to main content
Home Forums Silverlight Programming Programming with .NET - General Silverlight 2.0 missing features
108 replies. Latest Post by bropa09 on June 12, 2008.
(3)
justncase80
Member
349 points
144 Posts
03-07-2008 2:44 PM |
Hello,
I am trying to create a silverlight 2.0 application and I'm noticing a few missing features compared to WPF. I'm using Blend 2.5 preview also so I'm not sure if I'm encountering real problems or blend bugs. I seem to get different error messages for different things depending on if I'm in blend or VS so I'm not sure what is correct.
1.) Styles
In blend if I have the code <Style x:Key="s1" TargetType="{x:Type Rectangle}">...</Style> I get an error because it doesn't like {x:Type ...}. If I remove the target type then I end up with errors on the PropertyName attributes in the Setter tags. What is going on?
2.) Templates
Where the heck are the Template properties? Was this left out or is this a Blend bug? I'm having a hard time coming to terms with the idea that you cannot templatize anything... this is a major downside to silverlight if it's true. Will I really need to create a control that inherits from ButtonBase to get a templatized button? UGH.
3.) MergedDictionaries
I was hoping to have a shared resource dictionary file between a WPF application and a silverlight application but it seems that I cannot link to a resource dictionary file in silverlight because there is no MergedDictionary property. How is themeing supposed to happen if I cannot do this?
4.) RoutedEvent
I had created a control but the RoutedEvent class is nowhere to be found... There are RoutedEventArgs and RoutedEventHandler objects but no way to declare a routed event... what am I supposed to do about this?
5.) FrameworkPropertyMetadata
I have created some DependencyProperties that (in WPF) required the declaration of property metadata to specify a handler and to declare that it affects rendering. In silverlight you just pass in a handler but cannot specify AffectsRender, is this ok? Can I expect the same behavior?
6.) Linked Files
There seems to be a bug with linked user controls. I can see in the code generated files for silverlight that it's trying to load the xaml files but since they are linked files the paths are completely wrong and it blows up.
7.) Margin Resources
If I convert a margin property to a local resource everything works fine in blend but visual studio has a parsing error on the xaml blend produced. Something like <Thickness x:Key="t1">2,2,2,2</Thickness>, visual studio does not like this.
What is going on ?!?!
deltakosh
6 points
6 Posts
03-08-2008 5:00 AM |
Another feature request : capability to generate image using kind of putpixel methods.
Roland T...
4 points
2 Posts
03-08-2008 5:47 AM |
Hi,
I'm playing with Silverlight since yesterday, trying to "port" some WPF application into Silverlight. And the main issues I encountered were about Styliing and Templating.
About Styles, I had the same issues, until I saw that TargetType synthax was different from the WPF one : You should directly write : <Style x:Key="s1" TargetType="Rectangle">...</Style>
About templates, I had problems until I extract my templates to put them directly within the resources of the XAML files using targeted items. Another point : It seems that Silverlight Template don't support Triggers and Resources ( ControlTemplate.Triggers and ControlTemplate.Resource ). It's quite annoying, for it is part of the power of XAML. But I saw samples using ControlTemplate.Triggers .. So, did I do something Wrong ?
Another issue : It seems that Xaml files don't support anymore the "DynamicResource" directive. Eg, when entering "<MyControl Template="{DynamicResource MyResource}>" , Blend 2.5 beta and Visual Studio 2008's editor both send my an error about "DynamicResource". Is it normal ?
03-08-2008 1:31 PM |
Thanks for that TargetType tip! I've noticed the same things with the DynamicResource but I haven't tried the triggers yet. I bet you these things will be there for the final version of Silverilght. It's hard to believe that they'll leave it out, it's so essential. It would be nice to hear from someone at Microsoft that there are plans to, at least, make it more similar to WPF. Obviously they won't be able to tell us right now exactly what it will look like but it would be nice to have confirmation that at least some things will be better.
Thanks.
m.wawrusch
20 points
15 Posts
03-08-2008 2:53 PM |
Another feature desperately needed is the x:Static data binding extension, to be able to do something like this:
Text="{Binding UserName,Source={x:Static a:IdentityManager.Current},Mode=OneWay}"
Where IdentityManager is a singleton referenced by Current, and the property is UserName.
Dave Relyea
Participant
1084 points
249 Posts
03-08-2008 8:31 PM |
Silverlight 2 is meant to be a lean, mean and cross-platform subset of WPF. Some features are not there now, but will be eventually; other features might not ever make it into Silverlight. One of the things that we'll be relying on for deciding where to invest is feedback from the community. So please, let us know where it hurts--we're listening.
This might be a fun exercise: If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on? For example, you might decide that you really need merged ResourceDictionaries, so you'd spend 50 AMU on that, but maybe Margin Resources are only worth 5 AMU to you, etc.
What am I bid? :)
Answers to original post:
1) Omit the x:Type, as has already been noted.
2) Templated controls are in SL2B1.
3-5) Not available.
6) What is a linked file?
7) Yeah, that doesn't work. You can set the Margin in a Style.
Cass
Contributor
3157 points
654 Posts
03-21-2008 6:54 PM |
Hi Dave,
I don’t know how I missed this but I have been trying to get attention of anyone from MSFT at wrong places.
Well my requirements are very simple actually, and very straight and similar to WPF.
5 AMU Brushes (Visual Brush, Drawing Brush etc.)
I don’t know how realistic this is but Visual Brush would be a great thing to have in Silverlight.
5 AMU Sockets
Really need improvements here.
10 AMU RoutedEvents
I have been struggling to figure out how Silverlight is handling RoutedEvents, it really baffles me how Silverlight handles routed events, can you please simplify this? Also creating custom RoutedEvents is very handy at times, so please EventManager.
20 AMU Dynamic Binding
I don’t know about this or your plans for including Dynamic Binding in Silverlight, but given the fact that you have included DataGrid in Silverlight gives me a suspicion that you don’t have intention of including Dynamic Binding in Silverlight in near future. But please this is very important to us.
20 AMU Styles / Resource Dictionaries
No offence but Styles in Silverlight is a joke, what is the point of having style if you can’t add them to one place; we still have to make copies of Styles if we have to define them again and again.
20 AMU Control Templates
Yes, there are control templates in Silverlight but compared to WPF they are absolutely nothing, I just love them for what they are, I think fixing Styles would really help getting better Control Templates.
20 AMU Triggers
I am just surprised why Triggers are not supported in Silverlight; this really saves lots of time in writing simple events.
I don’t know how realistic these are, and how much they are going to affect Plug-in size but please these are the issues that really bothers me, there are many features that we might expect but I don’t see a point in adding new points when we have these issues.
Regards
03-21-2008 7:11 PM |
Thanks. I'll pass this along to the product managers. What more specifically do you need with sockets?
AFAIK you can put styles in the application resources.
Templates are pretty much the same except for the limitations imposed by styling, and the lack of triggers. Just out of curiousity, how do you do your templates, or how would you do them if everything was available? Blend? VS? Notepad?
03-21-2008 7:29 PM |
I would definitely like to reiterate ResourceDictionaries and DynamicBinding and everything related to being able to theme (style / template) your application in a seperate xaml file.
03-21-2008 8:27 PM |
Dave Relyea: Thanks. I'll pass this along to the product managers. What more specifically do you need with sockets? AFAIK you can put styles in the application resources. Templates are pretty much the same except for the limitations imposed by styling, and the lack of triggers. Just out of curiousity, how do you do your templates, or how would you do them if everything was available? Blend? VS? Notepad?
With Sockets, the most important issue is cross domain issues and ports, with these in place its actually not possible to get the most out of Sockets, as I see the possibilities of Sockets can really be achieved only if cross domain calls are supported.
Well I could go on and on with feature requests, but those I mentioned in my previous post are the most important as far as I am concerned they are already in place and they needs to be seriously fixed, and I understand that if you fix styles you fix all other issues like Control Templates, and I adore the control templates that are available in WPF, and I use my templates in Blend, it makes templating very easy.
I don’t think trying to include new features will make Silverlight any better platform than actually fixing it.
Having said that, there are also issues I would love to see fixed in Beta 2, like
· Keyboard entry on Full Screen Mode
· Sync support for communication
Because of the nature of my work and my projects (I deal mostly with Videos), I am a little disappointed with MediaElement. Don’t take me wrong but I love the new capabilities of MediaElement in Silverlight 2 and I can actually see the difference in buffering compared to Silverlight 1/1.1, but playing a media in MediaElement at a different slower/higher rate similar to WPF would be very nice. But there are also issues with playing asx (Media Playlists) over http, in Silverlight 2 Beta 1 asx is only supported over mms and not http. There are also issues over reading markers on wmv, if reading through a playlist asx.
At a different level I would like to know what Silverlight team think about supporting wsx and Server-Side Playlists (SSPL)/Wallclock in Silverlight, I am currently working on a project where this is really essential and I don’t understand the reason it is not supported after all its just a playlist of wmv files, can we see this in near future perhaps in Beta 2?
BenHayat
1026 points
597 Posts
03-21-2008 8:54 PM |
This might be a fun exercise: If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on?
Hi Dave;
Thanks for giving some attention to this post. I'm going to switch to a different direction and spend my AMU there.
For the past year that I've been waiting for SL 2 to be available, I have been anticipating to start developing Business database driven application. I had made a conscious decision to use SL instead of ASP.Net to offer clients a more modern and state of the art business application that can be used via web and bowser. To me, as business application developer, database capabilities are considered as the core of this framework. And trust me, for the past 2 and half weeks I have discussions with many other colleagues who want to use SL for the same purpose and feel database features are very important.
So, I'd put my 100 AMU on features that are similar (at least) to what ASP.Net offers out of the box. Secondly, more than betting money on it, could you please give us some info about what the plans are to get data to-and-from SL as easy and straight forward as possible?
I look forward getting some constructive answers here!
Thank you Sir!
TomGiam
706 points
204 Posts
03-21-2008 9:13 PM |
I'm building an online "drawing" program (actually a free form photo album). I have written it in WPF and the only thing missing there in full trust mode is more image manipulation (e.g. contrast, brightness, sepia etc...). In partial trust XBAP what is missing is the ability to send an application generated image (from visualbrush) to the server, fileSave and XamlWriter.Save (even to a string).
For Silverlight what I need is:
1. Visualbrush
2. Viewbox attribute of imagebrush (for cropping arbitrary sections)
3. Menus including ContextMenu
4. XamlWriter.Save at least to a string
5. Ability to send application generated image to server.
6. LayoutTransform
7. Viewbox to automatically resize objects
8. WrapPanel
9. Adorners, but I can work around that
10. In general, more controls and capabilities to make it closer to WPF.
Tom
ork
32 points
23 Posts
03-21-2008 9:15 PM |
I think MS should really really carefully evaluate some of the styling, templating, and binding support in SL2 as their claim to have SL as a direct subset rings hallow without some of the fundemental features like those mentioned here! For example, there is a huge difference between using triggers and the parts model being pushed for SL2.. This obviously creates two code sets as far as I am concerned, and any future development of both SL and WPF would have to diverge on this key design strategy - also, this is not something MS can easily add later without having to change the design tactics en-mass! Overall, I would appreciate 100% design parity with WPF whilst giving up some feature sets in the short term! Oh, I would definately pay equal importance on performance too, xaml happy code makes for a loaded visual tree! Is someone working to get the lag out of scrolling, anyone??
03-21-2008 9:35 PM |
I think I must add the lack of ISerializable is disheartning and so is the lack of the whole dataset model. I think MS should try harder to rank up the compatibility with the bigger .NET framework - particularly in the area of data consuption as that is the essence of SL (ie. Data Consumption for Presentation). Yes, web services, wcf and rest type models are all avaliable for use, but the old rank and file methodoliges should also be there - for example, I think the distinct lack of dataset hurts when you want to consume or use non-typed but structured data, in this case LINQ inspired anyomous types don't quite cut it.
03-22-2008 4:25 AM |
I don't think that ISerializable or DataSets are really that valuable frankly. Because of the nature of silverlight you will never be able to directly access data from a database which really defeats the whole purpose of the dataset. You make a service reference and it generates for you your proxy classes which are (frankly) better than datasets. This is good enough.
03-22-2008 9:21 AM |
For me, the most important thing is that the graphical subset defined by Silverlight becomes compatible with the most important features of WPF. Aka, 40 AM on Styles and Templates Triggers ( really good for designers, too ), and 30 AM for resource dictionnaries. I offer you the 30 remaining AM, just to motivate you to continue this way :D.
I've port one of our biggest WPF application in Silverlight, as a proof of concept. And I was delighted to see that there were finally not so much differences, apart from triggers.
03-22-2008 9:31 AM |
I am really surprised to see that most of us are unhappy about the Style/Templates/Triggers features (No offence Ben ). But I am also surprised that no one is really bragging about new features like Printing (XPS)/New Controls.
Yeah, there is no Wrap Panel/Dock Panel but I think that goes unsaid I reckon.
03-22-2008 10:21 AM |
Cass:I am really surprised to see that most of us are unhappy about the Style/Templates/Triggers features (No offence Ben ).
I am really surprised to see that most of us are unhappy about the Style/Templates/Triggers features (No offence Ben ).
Ok, Ok! I'll remember this... trying to lobby against my feature list? Wait till I see you in London next time.
03-22-2008 12:14 PM |
BenHayat:Ok, Ok! I'll remember this... trying to lobby against my feature list? Wait till I see you in London next time.
Err... Any chance you going to forget about it by then?
03-22-2008 12:24 PM |
Cass:Err... Any chance you going to forget about it by then?
No chance! Remember, my middle name is "Elephant"!
Brauliod
1163 points
469 Posts
03-24-2008 7:57 AM |
Another missing feautre: It would be a good idea to have the ability of exporting the content of a canvas to a jpg/png file.
A lot of people will use Silverlight to create "diagramming" applications, one of the common features is to export the diagram to several format (one of them... a pic to hang it on the wall ;-)).
Thanks
Braulio
03-24-2008 8:44 AM |
Brauliod, I second this. I just spent 2 days writing a server side workaround (ever run WPF in a WindowsService, this ain't no fun..) to get image export working.
Another feature I would love to see is ClipToBounds. Although this can be emulated using Clip it is so much more convenienent and probably one of the things everybody uses in WPF applications.
TextTrimming seems to be missing too.
And while you are at it please release the source code for the TextBox control too. I and probably lot's of others need some kind of RichTextEditor and worst case scenario is to write one based on the TextBox (If anyone is working on that and needs beta testing let me know, I have done so before for a component vendor and have an urgent need for this control).
ot42
40 points
21 Posts
03-25-2008 12:50 PM |
-- This might be a fun exercise: If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on?
20 AMU: Style/Triggers/Templates as in WPF
80 AMU: Synchronous HTTP server calls (also in background threads). Really critical for large C/S projects.
03-25-2008 2:34 PM |
I disagree with the Synchronous request. It's not actually necessary for any situation, you just have to think about the problem a little differently is all. I don't mind at all that your proxy objects are generating async only calls.
Synchronous web service calls result in slow blocking operations that degrade user experience. For large projects you will eventually HAVE to go async and try converting a large project half-way through when you realize you need to do everything async... what a nightmare. It's better to just start out thinking asynchronously.
03-25-2008 2:45 PM |
..and try converting a large project half-way through when you realize you need to do everything async... what a nightmare.
Exactly! We already have a very large AJAX application that we would like to port (not rewrite) to Silverlight. To do that with async will be a nightmare.
If we had to rewrite the app from scratch, we could probably do it using async (or at least large parts of it). But this illustrates very well why we should have the choice.
03-25-2008 2:51 PM |
That's a good point... however not redoing it will be a nightmare for the user
03-25-2008 3:02 PM |
Actually, this is a C/S app that always run on a local network with good response times. Currently, it runs just fine in a browser and a SL version should perform no worse.
After porting we would start optimizing the user experience, but we simply do not have the resources to re-architect the whole thing.
GearWorld
820 points
1,084 Posts
03-25-2008 6:04 PM |
BenHayat: Hi Dave and others as well, Oh God, I bid my 100 AMU on it too. I mean, yeah its nice it works to handle data but what a heck of a job to make it work. That would be so cool just by using the traditional way of using Web services with direct use of DataSet and custom object we did since a few years. Imagine I did make a Wrapper around the DataSet so it is so easy to handle data that its like playing lego. Now its unusable with SL Ah well, I'm not here to complain, I'm just full of hope :) Keep the good work tho. I will support SL as long as I can see with my own eyes. Since Monitors are killing them :) Ahhhhhh ages.
Hi Dave and others as well,
Oh God, I bid my 100 AMU on it too. I mean, yeah its nice it works to handle data but what a heck of a job to make it work. That would be so cool just by using the traditional way of using Web services with direct use of DataSet and custom object we did since a few years.
Imagine I did make a Wrapper around the DataSet so it is so easy to handle data that its like playing lego. Now its unusable with SL Ah well, I'm not here to complain, I'm just full of hope :)
Keep the good work tho. I will support SL as long as I can see with my own eyes. Since Monitors are killing them :) Ahhhhhh ages.
03-25-2008 10:37 PM |
Silverlight has a quite robust system of data access right now... WCF web service references. One thing you have to keep in mind is that silverlight is NOT a web technology, it actually runs on the client machine and is merely distributed via the web. With that in mind you must realize silverlight applications will never have the ability to make direct connections to a database. Instead you make a webservice, or WCF service then make a reference from your silverlight application.
All of your server side code is exactly the same as it has always been you just access your proxy objects somewhat differently in your silverlight code behind (primarily because you can only make async calls to your service).
03-26-2008 4:49 PM |
03-26-2008 5:35 PM |
That is pretty interesting, I guess they're storing the DB files in isolated storage. I wonder how they are accessing the DB without ADO.NET? I thought the VistaDB provider only came with an ADO.NET api. It would be even better if the silverlight runtime itself came with a DB that you could access per application for storing things like settings and whatnot, rather than pull down the vistadb api's for every application and it would sure beat the hell out of simply storing settings files directly into isolated storage...
03-26-2008 6:36 PM |
Ork, I don't mean to sound argumentative about your info on VistaDB and SL, but I think that's a total different direction that MS has set for SL. It's just my speculation that SL is going to be a purely thin client that gets it data from a middle tier server. If MS changes course, that would be one great feature!
03-26-2008 7:18 PM |
jackbond
2806 points
722 Posts
03-26-2008 9:25 PM |
justncase80:It's not actually necessary for any situation
Bad generalization. Here's one, try calling a web service in your applicationexit handler. BOOM.
justncase80:Synchronous web service calls result in slow blocking operations that degrade user experience
In the hands of inexperienced developers. A good developer will simply put long operations in background threads. And for calls that return 1 bit, async operations degrade the user experience. And async operations get particularily horrid when inexperienced developers attempt to simulate sync behavoir, i.e.
DoSomeThingAsync()
Sleep(5000); //oops, async returned after .03 seconds, but I'm waiting 5 just in case
justncase80:For large projects you will eventually HAVE to go async
Nonsense. Only a billion large projects out there to disprove that argument.
justncase80:It's better to just start out thinking asynchronously.
How about thinking about the best approach for a particular situation? If async is some sort of magic, why not make EVERY call async, such as:
int i;
i =Completed += new IntegerAssignedDelegate(TheIntegerWasAssigned);
i =Asnyc(5);
03-26-2008 10:19 PM |
jackbond: Bad generalization. Here's one, try calling a web service in your applicationexit handler. BOOM.
Seems like calling any sort of long blocking operation during the application exit is a horrible user experience...
jackbond: async operations get particularily horrid when inexperienced developers attempt to simulate sync behavoir, i.e. DoSomeThingAsync() Sleep(5000); //oops, async returned after .03 seconds, but I'm waiting 5 just in case
So I think you're proving my point here, unnecessary blocking is a poor user experience.
jackbond: Nonsense. Only a billion large projects out there to disprove that argument.
This doesn't convince me, either all of those billion applications have async mechanisms or they would be better if they did.
jackbond: How about thinking about the best approach for a particular situation? If async is some sort of magic, why not make EVERY call async
indeed, I just happen to think that async is better in any given situation. Of course if making a web service call across the web was even remotely comparable to assigning a value to an integer in memory then perhaps an argument for synchronous webservice calls could be made. Alas, they are not. They are woefully slow even in optimal circumstances resulting in poorly responsive UI's that implement blocking, synchronous web service calls.
I'm just saying, I don't miss the fact that I don't get synchronous web service methods generated for me. Forcing me to do things correctly the first time is beneficial in the long run so oh well.
03-27-2008 12:53 AM |
justncase80: Seems like calling any sort of long blocking operation during the application exit is a horrible user experience...
Who said it was a long running operation. It sent one 1 bit, returned instantly. But now, the only work around is to call async and then sleep for x amount of time to guarantee that the async op completes. User experience diminished BECAUSE of async.
justncase80:So I think you're proving my point here, unnecessary blocking is a poor user experience.
Blocking BECAUSE of async, if it were it's previous sync version(which returned instantly) there would be no need for sleep.
justncase80:This doesn't convince me, either all of those billion applications have async mechanisms or they would be better if they did.
But you don't need async to not block the UI, just put it in a background thread. Application logic cleaner, no degradation to the user experience. Everyone wins.
justncase80:indeed, I just happen to think that async is better in any given situation.
You say that despite the fact that you have some VERY experienced developers saying, wow, this just blew up my very clean code base? Our user interfaces don't block, because we know about the System.Threading namespace.
justncase80:even remotely comparable to assigning a value to an integer in memory
:) I was grossly exaggerating there. Bottom line, crippling good developers who know when to put long running operations into a background thread, is not the way to grow a platform. The lack of sync functionality is going to block the adoption of Silverlight for certain types of applications.
justncase80:They are woefully slow even in optimal circumstances resulting in poorly responsive UI's that implement blocking, synchronous web service calls.
Odd, my service calls aren't slow, maybe they're not responsible for your performance problems.
justncase80:Forcing me to do things correctly the first time is beneficial in the long run so oh well.
Forcing you to turn your code base into a spaghetti mess, when you could "correctly" put your long operations into a background thread, is beneficial to no one.
fkruesch
38 points
22 Posts
03-27-2008 6:55 AM |
Here's what I'm missing apart from what has already been mentioned:
jordanha...
190 points
104 Posts
03-31-2008 6:37 AM |
Has anyone from Microsoft responded to any of these issues?
We really need some answers ASAP else we will have to go for Flex.
03-31-2008 10:01 AM |
I'm monitoring the thread and will make sure that the feedback is taken into consideration for planning purposes. Of course, this doesn't guarantee anything, because until we solve the time travel and cloning problems we can't do everything we want to do, but your voices are being heard.
03-31-2008 10:38 AM |
Dave Relyea:until we solve the time travel and cloning problems we can't do everything we want to do
I may have missed something, but I'll bite; what are the time travel and cloning problems?
03-31-2008 10:43 AM |
If a team can be cloned a few times over, and/or can be sent back in time, there is no limit to what they can accomplish :)
03-31-2008 11:23 AM |
Dave Relyea:If a team can be cloned a few times over, and/or can be sent back in time, there is no limit to what they can accomplish :)
OK, you got me. :) There I thought they were some fancy names for technical challenges you were addressing.
03-31-2008 12:00 PM |
They're more like long-term research projects. :)
So far, in carefully controlled trials, they've managed to give a developer a headache an hour before the experiment starts.
andyboyne
105 points
56 Posts
03-31-2008 12:39 PM |
Dave Relyea:This might be a fun exercise: If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on? For example, you might decide that you really need merged ResourceDictionaries, so you'd spend 50 AMU on that, but maybe Margin Resources are only worth 5 AMU to you, etc.
It is great to see some MSFT activity on this topic. Please see the list below.
(30 AMU) ControlTemplate Triggers, DataTemplate triggers, Style Triggers, DataTriggers - in general, be able to reuse the XAML from WPF controls in Silverlight.
(20 AMU) Adorners. As mentioned below, ErrorProviders in WPF can be implemented with adorners and attached properties. (Of course there are a multitude of other reasons as for why Adorners are useful)
(10 AMU) No way to get Binding from a control. In WPF we were able to use techniques involving Bindings to know what control was bound to an object and vice versa. In WinForms and ASP.Net there is an out-of-the-box error provider. In WPF it is fairly easy to create an ErrorProvider by tracking the bindings and using AttachedProperties and style triggers with adorners. In Silverlight it seems an awkwardly difficult task - we cannot even navigate the logical tree and spoof adorners by manipulating the tree :o(
(10 AMU) Ability to author custom MarkupExtensions as per WPF. (Are Silverlight bindings from markup “{Binding Forename, ...}” just ‘magic’?)
(10 AMU) How to handle databinding currency, especially with lists as there are no ICollectionView types? E.g. List<People> bound to a textbox, how do we know which person the textbox is displaying?
(10 AMU) Binding is inconsistent between WPF and Silverlight:
No ElementName source No RelativeSource Self BindingExpressions not compatible between Silverlight/WPF. Therefore form layout reuse is not possible.
(5 AMU) No commands/input bindings/gestures
(5 AMU) Attached/DependenctProperty inheritance.
Cheers,
Andy
brauliod
04-01-2008 2:13 AM |
I agree with you that a product can't have all that the user expects.
But... maybe it's time to make a list of things that WON'T be on the next release. I'm tired of all the marketing machinery, I mean Silverlight it's a superb product, but I want to know what can I expect from the product in the next releases and what not,I think it's worse to use silverlight for a real project and then realize that doesn't have this or that feature so you are pissed off with your client (e.g. in the previous versions it was announced with bells and whistles that Silverlight was search engine friendly, now not... that's a big limitation and right now we don't know what is going to happen).
JoeS
18 points
9 Posts
04-03-2008 11:17 PM |
1.) Control Templates need to work like WPF, I was afraid something like this would happen. There has to be parity between WPF and Silverlight. I've been playing with Silverlight for a few weeks now and coming from WPF, a control that took me about 10 minutes to build in WPF took me about 45 minutes in Silverlight. Unacceptable. Get rid of the Template Part model, it breaks the whole designer/developer workflow.
2.) Property Triggers, Data Triggers and Event Triggers support.
3.) Element binding, such a key featire of WPF needs to be added to Silverlight.
4.) ICommand interface needs to be added with support for Routed Commands.
5.) Routed Events need to be up to WPF standards.
6.) Style Inheritance, this is actually pretty important, creating the same xaml over and over again just to change one property is pretty ridiculous.
Having other controls like Wrap Panel and such are nice and all but I think you need to concentrate on the core functionality of the framework before you start introducing more controls. Working with WPF has been wonderful, working with Silverlight has been a hair pulling experience. It almost feels like you have to fight the framework to get work done, especially coming from what I have become accustomed to with WPF.
Roet
211 points
65 Posts
04-04-2008 5:39 AM |
I'm currently working on a LOB application where users work with many datagrids and fill in forms, so the basic formcontrols are very welcome. Scrolling is also essential for a good user experience.
Though MSFT might not see SL the way I do, but I see a good future if it gets closer to the ASP.NET functionality. This way you have power like ASP, but no AJAX crap, call/postbacks and most importantly; browsercompatiblity hell.
WPCoder
116 points
24 Posts
04-04-2008 11:47 AM |
I'd like to see more of the controls that exist in WPF added (and Windows, and basic HTML) -- especially components that are challenging to build really well/efficiently (or impossible):
Plus, it really needs to support things many users have come to expect:
It's hard to see right now how to do a complete LOB type application without some of these missing elements. They definitely belong native, and not provided as a 3rd party solution (or some coding hack).
I do find it strange that code that was before OnMouse... in WPF (or Winforms or ...) now must be coded as an event. It doesn't follow the .NET design guidelines.
samcov
930 points
360 Posts
04-04-2008 10:18 PM |
Of course, all of this comes after the primary concern, which is bug fixing, but here is my list.First Tier Requests: The "Really want to have" features1. Rich Text Editor2. TreeView3. Pixel Control (GetPixel/SetPixel)4. Right Click
Second Tier Requests1. Menus2. Access to the video stream3. Access to the audio stream
Third Tier Requests1. ComboBox2. WrapPanel3. Better Scrolling
Finally, it would be greately appreciated if MS could "telegraph" their leaning on these important issues. It's critical for us to know what MS is thinking so that we can make intelligent development decisions about where we put scarce resources.
04-07-2008 5:57 AM |
Amen to that Samvoc. Though I would add scrolling and combobox to the First Tier Requests.
Tim Favour
93 points
69 Posts
04-08-2008 4:00 AM |
Quite a few of us are in desperate need of decent printing support:
http://silverlight.net/forums/t/516.aspx
Working with non-media applications like vector graphics almost certainly includes vector printing.
One problem is that one cannot serialize plugin contents back to XAML, if there would be an easy way to do that, we could create our own converters for pdf etc.
Tim
MishaSt
88 points
04-09-2008 5:18 AM |
1. <B>Image-by-image Animation</B>
I want easy way to make animation from images, but in WPF & Silverlight this i can solve by writing Animation class, that can be done to me.
I want just choose in Blend in file open dialog images and then blend make animation from images by switching this. Now it dificult to do this animation type.
2. NetwotkStream, BinaryReader
I was very surprised, then don't find this. I plan to use this classes with CryptoStream, but i failed. I implement NetworkStream self. But it's not critical.
3. Tag property
This is very strange, that "Tag" property can hold only string values, but have type object. In MSDN don't around that "Tag" can hold only strings.
04-09-2008 5:36 AM |
samcov:2. WrapPanel
Yes, it missing. But i found WrapPanel realisation for silverlight :)
chadbr
53 points
27 Posts
04-15-2008 4:41 PM |
Dave Relyea: If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on?
If you had 100 Arbitrary Monetary Units to spend on Silverlight features, what would you spend it on?
If I'm not too late...
40 AMU's -- Some kind of generic data story. Datatable/Dataset or some kind of lightweight version of those so we don't have to define 1000's of business data classes.
10 AMU's Dynamic Binding - as describled above
20 AMU's -- Some kind of XPath navigation on XDocuments.
10 AMU's RoutedEvents
10 AMU's Triggers
10 AMU's Adorners.
Controls are nice - but I can get those from vendors.
Is it worthwhile to put these on Connect?
gourmet
110 points
04-18-2008 6:41 PM |
60 AMU´s: Templating and styling 100% congruent with WPF (TRIGGERS!!!!!)
25 AMU´s: Binding (DynamicBinding, x:static, RelativeSource,RelativeSource,RelativeSource)
15 AMU´s: LayoutTransform
That´s what I would have written if I was a native english speaker!
(JoeS:) " Having other controls like Wrap Panel and such are nice and all but I think you need to concentrate on the core functionality of the framework before you start introducing more controls. Working with WPF has been wonderful, working with Silverlight has been a hair pulling experience. It almost feels like you have to fight the framework to get work done, especially coming from what I have become accustomed to with WPF."
(JoeS:)
" Having other controls like Wrap Panel and such are nice and all but I think you need to concentrate on the core functionality of the framework before you start introducing more controls. Working with WPF has been wonderful, working with Silverlight has been a hair pulling experience. It almost feels like you have to fight the framework to get work done, especially coming from what I have become accustomed to with WPF."
I know that we can´t expect Silverlight to offer all features WPF has. But if you consider Silverlight as the small brother of WPF you have to care about it´s abality to become as powerful as it´s big brother. Designing the templating the way it is now is like cutting one leg of sweet little Silverlight. Even if it´s grown up it can never be as strong and elegant as it´s big brother...
04-18-2008 7:29 PM |
I just wanted to say that I'm not responding to every post on this thread, but I'm still reading everything.
egoZd
326 points
125 Posts
04-20-2008 6:22 AM |
I'm coming to fingure out my dream also.
-------------Great Dreams(every day will make)--------------------
1. I want directx or opengl been exposed.
2. I want we can get a richtext editor (Have ability to analysis HTML symbol) .
-------------Little dreams (Sometime will make)
1. Give me some more control (Treeview,Combobox,Password Textbox etc)
2.Can i have ablility a save file to local computer.If it because of security .then what about IE's Popup save dialoge.Does it the same thing.
3.Give me some abilibty a desgin a report and print it out.
Hope i can have a good dream.
best regards
04-20-2008 12:22 PM |
Dave Relyea:I just wanted to say that I'm not responding to every post on this thread, but I'm still reading everything.
Just curious to see if you have compiled the requests and which ones do you foresee that would be implemented in version 2.
Thanks!
04-20-2008 5:05 PM |
I haven't officially compiled anything yet, although the team is aware of this thread. I'd have to do the compilation and see what's there. The important thing to remember is that if something you want doesn't make it into SL2, well, we're not gonna stop at SL2. I will use this thread to help determine what my team (controls and layout) does in the next version (it we're not doing it in this one), and I will encourage other teams to do so as well.
04-20-2008 5:35 PM |
Dave, thank you for prompt response. I fully understand your comment if it doesn't make it to version 2 and there will be other versions. I'm also very glad that you initiated with your question "what we want to see". As you can see, you got lots of valuable feedback. I think this form of communication between the team and developers (us), will be very valuable and helpful. So, I also agree with you that other teams on SL, to open up the channel of communications with developers. Perhaps in your internal meetings, you can bring this point up to other teams.
Thanks again for monitoring this forum!
Eloff
139 points
114 Posts
04-22-2008 2:16 AM |
Edit: some things TextBox needs:
I've seen many people say that one of the major advantages of Silverlight is that you guys can port your Flash/Flex killer, RichTextBox, to Silverlight. They may have a point. That is the single most useful control you could add to Silverlight.
Remember, the UI is the application as far as the user's are concerned.
GaryBerg
2 points
3 Posts
04-25-2008 2:56 PM |
35 PreserveObjectReferences in the DataContract Serializer is essential for sending complex object graphs from/to server. WCF is pretty important with no database functionality so why not support it to the max.
35 Printing support
30 Triggers in Styles, and otherwise try to make XAML syntax/functionality very similar to WPF.
04-29-2008 9:24 PM |
Here's another thing that is missing: Private reflection.
I understand why you might not be able to perform private reflection on Types from other assemblies but you should be able to perform private reflection for types inheriting from a base class at least. For example the following is very common and useful:
public class Base { public void Serialize() { foreach(FieldInfo field in GetType().GetFields(BindingFlags.Instance | BindingFlags.NonPublic)) { object value = field.GetValue(this); //DoSomething(value); } } } public class Sub : Base { private string f1 = "I may need to be serialized"; }
It sort of messes with your object model to only be able to access public properties from a base class using reflection. Also, I have tried creating dynamic methods that access the private fields, that are associated with the type but this also throws a FieldAccessException. Very frustrating.
jhauppa
12 points
04-30-2008 11:48 AM |
Some things I find missing as I try to get a bunch of forms/user controls written
1. There is not good support for user control inheritance. I can get the inheritance working if I play namespace games, but then the designer does not work any longer. This is frustrating since we will have several devs trying to get up to speed on this, and loosing the designer is a big sacrifice for a new XAML dev.
2. No style inheritance makes our styling difficult to maintain
3. No built in combo-box, dropdown control. I know we can write our own, but isn't a control like this so fundamental that it is should be included?
4. Solid support for both wsHttpBinding and https
Not trying to complain too much here. In general most of the Silverlight 2 stuff is working great.
Eugene A...
26 points
10 Posts
05-01-2008 1:43 AM |
Most important missed features for me
Property Triggers in Styles
Binding as in WPF (support for RelativeSource, ElementName),
Binding to TemplatedParent in Templates,
Binding in nested objects (Not only in FrameworkElement)
Merged dictionaries (or some other way to create reusable resources packages)
Commands
Less important
Routed events
Property inheritance
Print support
cardinal
05-03-2008 8:21 AM |
The WPF application solution is great in blend, its got everything a UI designer, in my case web-designer, would need. Except that in my case it is silverlight which delivers WPF to the web, and at the moment I'm wondering why in a silverlight site all that same functionality isn't there? Is there a fundamental problem here? If so, would I want to stake the future of my e-business on it?
I need to be able to edit control parts, triggers, events in blend and publish it for silverlight, without coding, otherwise the product is useless to me as a designer. I have hopes for the final release but I'm getting increasingly confused as to how much silverlight can actually deliver.
I really need more information such as:
1) Why are most controls missing in silverlight?
2) When will blend 2.5 be on the shelves? i.e. how long do we have to wait until we actually have a useable product?
3) Will I be able to create the same things I can in WPF without coding, in a silverlight 2 application using the same methods?
I'm not a programmer so any clarification of the above would also be helpful. :-)
05-03-2008 12:17 PM |
Cardinal; your point is well taken (trying to bring designers into SL), and not having all the features of WPF, makes it hard. I'm with you and I do miss many features of WPF in Blend that are not in SL, heck there are features in SL 2 that is not even in Blend 2.5 preview. I had already inquired about that in Expression Blend forum, but did not get any answer.
However, the good news is that, the team had already done it once in Blend for WPF, so they already have experience how to do it, but it will take some time for SL to catch up with WPF. And to be honest with you, it's not like we have that many alternatives to develop apps that are based on Managed code, compiled and uses .Net foundation. So, let's just use what we have for now and hope for more in near future!
JamesMcP...
05-05-2008 4:42 AM |
I'll give my 100 AMU :)
50 AMU: WPF DataTemplate.DataType
25 AMU: Event Triggers. Property and Data would be nice too :)
25 AMU: DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="Visibility" DiscreteObjectKeyFrame x:Static Visibility.Visible/Collapsed
05-05-2008 9:12 AM |
Thanks for the reply. Yes I agree Blend is pretty good so far, its just a bit nail-biting having to wait for it!
A release date would ease the anticipation, do you think its likely to be 2008, say Q4?
Working alongside a coder, if a designer creates a WPF based website, how easy is it going to be to modify the original WPF code so that it runs in silverlight?
Cheers
Bydia3
05-12-2008 1:21 AM |
The whole purpose of the dataset is not direct access to the database, but rather to have a disconnected remote type view of part of the database. Your use of the proxy is one way. A dataset enables me to list rows in different ways, insert, update and delete rows with out extra trips to the server... then when I'm ready I can submit these changes. On the server my dataset can then be saved for change tracking, logging, and even sent to another system as a quick and dirty data transfer. The possiblilities are endless. Without the dataset I have to manage all the state properties on the xml myself, yuk.
jasonbst...
7 Posts
05-12-2008 8:37 AM |
My 100 AMUs worth...
40 AMU Styles / Templates / Triggers20 AMU Combobox20 Menus and Right-Click Menus10 AMU Scrolling and scrollwheel that works10 Tree view
To all you guys talking about issues with SL data driven apps, have you had a good look at ASP.NET DataServices (aka Astoria)? I hold out high hopes that this will be the solution for being able to get data manuipulate it with chnage tracking and then post it back to uopdate the database through a Business Logic Middle Tier. There does not appear to be a Data Services client that will work with SKL 2 beta 1 as yet but there should be one released with SL 2 Beta 2.
I too want to use SL for data driven LOB applications and I would give up the whole 100 AMU for a decent solution for data round tripping - lets hope Astoria is it!
Jason
05-12-2008 9:41 AM |
Also want to add one more...
5. How about improving the TextBox to be Multi-line and scrollable
05-12-2008 10:03 AM |
wrap the textbox with a scroll tag.
05-12-2008 10:16 AM |
I already tried that. the TextBox really only works well with a single line of text. The text just scrolls off to the right. there does not appear to be any text wrapping options, and the user has to hit enter for the text to drop to the next line. The TextBox also does not resize itself vertically as the content grows, which is what it would need to do to make the scrollbar useful.
If I am missing something here please post code of one that is working. I can wrap it in a scrollbar, but the problem appears to be with the textbox inside the scrollbar.
At this point If I want a textbox that works well for multiline it looks like I will have to write the control myself. Being able to input multiline text is a basic UI requirement, so I think a solid implementation of a multiline textbox should be included in the runtime for everyone to use.
Thanks,
John
05-12-2008 10:25 AM |
This is from the generic.xaml styling for one of my controls.
<Grid VerticalAlignment="Center" HorizontalAlignment="Center"> <Grid.RowDefinitions> <RowDefinition Height="*"/> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <ScrollViewer Margin="4" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Auto"> <TextBlock x:Name="Message" Text="{TemplateBinding Message}" HorizontalAlignment="Center" VerticalAlignment="Center" Margin="4" FontFamily="Tahoma" FontSize="14" TextWrapping="Wrap" Foreground="WhiteSmoke" /> </ScrollViewer> <Button x:Name="OkButton" Content="OK" Width="100" HorizontalAlignment="Right" Margin="8" Grid.Row="1" /></Grid>
05-12-2008 10:27 AM |
Hi John;
I'm in the same situation right now and I hope MSFT has resolved this issue with beta 2. I hear beta 2 is around the corner and before you make crazy changes to your code, wait till you get the beta 2, and you may not have to change anything.
Hope this helps!
05-12-2008 10:35 AM |
Jordan,
Thanks for posting this code. It works well for the TextBlock, but there is no similar approach that I could find for the TextBox. I need the user to be able to enter (not just display) multi-line text. I don't think there is a way to do that with the TextBlock, otherwise I would have gone with what you posted above.
05-12-2008 10:39 AM |
ah, sorry, my confusion.
bdenham
1 Posts
05-13-2008 5:20 PM |
I'd spend my 100 AMUs as follows:
40 - Complete the Styles / Templates / Triggers framework so it works like WPF30 - Work on TextBox/TextArea so that it works for lots of text input (autoWrap/autoScroll) and that can render both in plain text and HTML text using simple HTML markup (like Flex's TextArea where you can simply set a property to determine support for text or htmlText). 20 - RichTextEditor that works (even if you take the Flex approach of wrapping your TextBox/TextArea inside a panel with controls that apply HTML markup); just be sure it's not as buggy as Flex's version (terrible).5 - Add Right-Click Context Menus5 - Add Mouse-wheel support built into the scrollable controls
ComboBox is one of those staple controls that should be there without me spending any units on it. However, I'd rather build that myself and have you guys work on additions to the core SL framework (styles, templates, triggers, context menus) and the other hard stuff like better text handling/support (textarea/richtext) that's essential for enterprise business applications.Thanks for reading!
Best,Bruce
jdokulil
05-13-2008 6:23 PM |
I'm still too new to Silverlight development to be able to allocate my AMUs. However, I would like to throw a vote out for exposing RenderTargetBitmap. I would like to create a thumbnail composite of a MediaElement overlayed with an InkPresenter and the thought of round-tripping to the server is a major downer for this application. Thanks, it's great to see that Microsoft is at least listening here!
thosebug
273 points
70 Posts
05-14-2008 7:05 AM |
50 AMU to Hire more programmers to Silverlight (looks like SL is too big for Microsoft)30 AMU to Hire 5 people like Jesse Liberty (Is the only one person to give us nice tutorials ???? )20 Visual Controls (combobox, textbox with accentuation problems solved, menu, tabcontrol, powerfull datagrid, groupbox, etc.)
05-14-2008 7:12 AM |
thosebug:My 100 AMUs worth... 50 AMU to Hire more programmers to Silverlight (looks like SL is too big for Microsoft)30 AMU to Hire 5 people like Jesse Liberty (Is the only one person to give us nice tutorials ???? )20 Visual Controls (combobox, textbox with accentuation problems solved, menu, tabcontrol, powerfull datagrid, groupbox, etc.)
Best use of money thus far... :)
Kevmeister
249 points
119 Posts
05-14-2008 7:37 PM |
My observations so far having started playing with Silverlight over the last two weeks.
- WsHttpBinding for those of use who need SessionMode=Required in our web service, and don't want to use AspNetCompatibility with BasicHttpBinding - otherwise shouldn't we just keep using .asmx on the server?
- No TreeView, ComboBox/DropList (selectable), or PasswordTextBox controls.
- Pageable operation for the Datagrid, particularly for datasets of unknown (and potentially very large) size.
- No DockPanel container. I'm sure I'll probably need a WrapPanel/FlowPanel kind of thing down the track, too.
- Whatever support is necessary to enable Theming, so a user can choose from one of several display themes for their application. And I guess that includes support for multiple merged resource files to improve maintainability.
- Style "BasedOn" would simplify style maintenance a'la CSS.
- ISerializable, because sometimes you want to serialize data not for transmission over the wire, but for internal consumption later.
- Synchronous web services would be useful (along with Async). Some web services are *naturally* synchronous to the user interface experience and making them asynchronous just makes life harder. Especially for line-of-business applications. Consider saving a record - what else is your user going to do in the meantime whilst saving a record, when the record might in fact have errors that prevent them from "completing" that task? It's a logical stop-and-wait point.
- An appropriate mechanism for sending large files from the client to the server (ie. File Upload mechanism), with progress tracking capability.
- A SaveFileAs dialog so users can download content through a silverlight application and save it to their local machine without having to jump out to HTML/AJAX etc to do this.
- BETTER DOCUMENTATION. Especially stuff that gives "big picture" overviews of the class hierarchy and controls.
- Reduce Documentation Confusion versus full-strength WPF. Silverlight is intended to be a subset of WPF yet there is an entirely separate set of documentation for it. So when you start looking things up you can easily get a "bum steer" by looking at the wrong sub-set of documentation. You should merge the documentation together and point out which bits do and do not apply to "full-strength" WPF or to Silverlight. Much like how the Win32 API is documented only once and tells you which O/Ses a particular function applies to.
Oops, a couple more I wish to second (from other poster's feedback).
- Simple DataSets - in a LOB app, the UI might allow a user to define what columns are shown in a table, and it makes sense to only transfer the appropriate columns from the server - which in turn means the behaviour is behaviour is basically like a DataSet.
- Menus and right-click context menus.
- Scroll-wheel support.
- Keyboard support in Full-Screen mode. I realise the security implication here for "spoofing", so perhaps a "modified" full-screen concept that provides a visual cue that Silverlight is running, *IF* keyboard support is enabled in Full-Screen Mode?
05-15-2008 1:19 AM |
One more thing, I'm not even sure if this is possible, but I'd REALLY like to see drag & drop supported from outside of a silverlight app into it. I mean I'd like to be able to drag a file directly onto it, or drag an object off of it that could be consumed in an external app.
dmrn
4 Posts
05-15-2008 4:13 AM |
Routed events like in WPF - 70 AMU
Property bindings like in WPF - 30 AMU
dcstraw
258 points
85 Posts
05-16-2008 4:50 PM |
30 AMU: Triggers
20 AMU: Element Binding
15 AMU: Adorners
10 AMU: Commands
10 AMU: Routed Events
10 AMU: Merged Dictionaries
5 AMU: Style inheritance
05-20-2008 2:34 AM |
I've noticed today that Silverlight has no ITypedList support. This means (as best I can tell) that you can't implement your own "generic" data collection (like a DataTable - also not in Silverlight) and get proper DataBinding semantics.
05-20-2008 9:47 AM |
Kevmeister: I've noticed today that Silverlight has no ITypedList support. This means (as best I can tell) that you can't implement your own "generic" data collection (like a DataTable - also not in Silverlight) and get proper DataBinding semantics.
Does this really matter though? I mean there is no direct database support in general you can only work with WCF proxy classes. Though I suppose you could come up with a 3rd party direct to database scheme since raw sockets are available it definitely seems like an external project. Anyway, if you have an object that implements INotifyPropertyChanged you can get propery DataBinding semantics. It's not quite the same as WinForms or WPF thats for sure but the question is... what scenario are you encountering where you wish to use a DataTable in silverlight?
05-20-2008 8:49 PM |
Why is it that many assume that using a DataSet means we want to directly connect to the db? While in Asp.net 2.0 a DataSet can also attach a dataAdaptor to help with this, however, originally the dataset was just a collection of tables, rows and relationships.. an in memory db. What some of us would want is a way to wrap( in a generic way) the xml we get from a service, do all our CRUD operations on the client in silverlight, then post back this object for updating... maybe with optimistic concurrency enabled. Sounds like a DataSet would be good. If not then how should this be done? By adding a ton of parameters to a ton of webservices?
05-21-2008 2:28 PM |
Can I get some of my AMU back? I'd like to put at least 15 AMU toward the DataTemplate.DataType property support.
I should have been more prudent with my AMU.
05-23-2008 5:34 AM |
I am also need viewbox to automatically resize objects.
05-23-2008 5:46 AM |
dmrn: I am also need viewbox to automatically resize objects.
Try this: http://blogs.msdn.com/jaimer/archive/2008/04/29/viewbox-for-silverlight2.aspx
05-23-2008 10:57 AM |
Bydia3: Why is it that many assume that using a DataSet means we want to directly connect to the db? While in Asp.net 2.0 a DataSet can also attach a dataAdaptor to help with this, however, originally the dataset was just a collection of tables, rows and relationships.. an in memory db. What some of us would want is a way to wrap( in a generic way) the xml we get from a service, do all our CRUD operations on the client in silverlight, then post back this object for updating... maybe with optimistic concurrency enabled. Sounds like a DataSet would be good. If not then how should this be done? By adding a ton of parameters to a ton of webservices?
I can't improve on that. My thoughts exactly...
05-23-2008 11:26 AM |
You can use compeltely strongly typed objects right in the webservice. How is a dataset even close to as good as this?
[WebMethod]
public MyComplexObject Get(int id)
{
return new MyComplexObject(); // do data access here}
public void Update(MyComplexObject obj)
// do update here.}
Then in code:
MyComplexObject obj = client.Get(100);
obj.SomeField = "new value";
obj.NestedComplexObject.SomeNestedProperty = 10;
client.Update(obj);
You can even use partial classes to add members to these generated proxy objects. Or what would be even better is to create actual business objects and use these proxy classes as a DTO to load that more complex business object. How on earth is this not better in every way to a dataset?
sladapter
All-Star
17179 points
3,132 Posts
05-23-2008 3:09 PM |
justncase80:You can use compeltely strongly typed objects right in the webservice. How is a dataset even close to as good as this?[WebMethod]public MyComplexObject Get(int id){ return new MyComplexObject(); // do data access here}[WebMethod]public void Update(MyComplexObject obj){ // do update here.} Then in code:MyComplexObject obj = client.Get(100);obj.SomeField = "new value";obj.NestedComplexObject.SomeNestedProperty = 10; client.Update(obj); You can even use partial classes to add members to these generated proxy objects. Or what would be even better is to create actual business objects and use these proxy classes as a DTO to load that more complex business object. How on earth is this not better in every way to a dataset?
OK, Here is my case: We simply can not pre-define a object with hard coded properties.
Say we have a customer object which has a main DB table map to it. The customer could have some pre-defiend fields such as name, address, gender etc. But each Company who bought our product has different set of attributes to define their customer object and they can add attributes to the customer object and add fields to the Customer table as they like. So how can we use the Entity/Object model plus LinQ to achieve this.
Currently we use dynamcially generated SQL + DataSet + MetaData (the data to describe each object field such as mapped db field, field type, field control in UI etc) we can do everything. In our List pages we use DataGrid to display data. Each end user can chose which column to display from a list of all the possible columns for that object. User can define a filter based on each possible column as criteria. So we cannot pre-define a SQL or LinQ statement. They have to be generated dynamically.
The generic feature of DataSet is it's advantage I do not see other technology provide. I like the elegant programming style of new Entity/Object Model/LinQ and I can see their usage. But currently they still can not do what we need to do.
We have more than 1000 tables in our data base, but we only need 3 Web Service functions to cover 90% of usage in our application.
public string GetData(Filter filter)
//Calling our business object based on the BusinessObjectID and Filter Criteria in Filter object to get the Data back
return DataSet.GetXml(); // return DataSet XML}
public void Update(DataSet dt, BusinessObjectID ID )
// calling business object to do the data set update
// business object knows how to build Update SQL based on the Meta Data for that object and Data in the DataSet }
public void Delete(BusinessObjectID, ID)
// calling business object to do the delete}
05-23-2008 5:48 PM |
We use ORM, and what SilverLight offers works for most situations, but is inferior for some applications where being closer to the metal(database) is prefered. These applications generally revolve around transforming data when SPEED is an issue.
If you have a highly used reporting site, getting data to tables as fast as possible is what is needed. Converting to Objects is an unnecessary step.
It all depends on the application, however, if you close off access to other options, that generally results in problems.
05-23-2008 8:17 PM |
--You can use compeltely strongly typed objects right in the webservice. How is a dataset even close to as good as this?--
--OK, Here is my case: We simply can not pre-define a object with hard coded properties. --
I agree with both these statements, it is not strong typed datasets that some of us are after. When we get a UnTyped dataset we can also within the same Untyped dataset retrieve some meta data that we can setup a dynamic forms. In this way, we can lower the amount of code we need to write and still make a generic data management system look likes it written specifically for the data in mind. So how is a dataset even close to as good as strongly typed objects? When the dataset is a UnTyped one and a 1000 webservices become 3 generic ones. Our company created an (internal use)AJAX web site, back when MSXml 3 first came out. We wrote a one method webservice that all client data passed through. It sure save alot of coding. Hoping we an do something similar with Silverlight 2
05-23-2008 9:29 PM |
Bydia3,
I'm totally with you. Finally I find someone think the same way as we do.
05-24-2008 3:17 AM |
sladapter: Bydia3, I'm totally with you. Finally I find someone think the same way as we do.
Not so fast. That's not a good reason, because we have EXACTLY ONE Webservice that serves up ANY ORM object from the database, we don't have to change one line of code, and we can do CRUD on it all day long. It's all in how you generate the classes, setup up the acchitecture, and the transport method(we use JSON on both client and server in SilverLight, EXACTLY the way we do in AJAX).
The reason you want datasets(or weak typing), etc, is generally for flexibility and SPEED. Reporting is the perfect example, and a solution exists for SilverLight(weakly typed JSON), but it uses as much reflection as we use for the object based solution to display it in a DataGrid.
So while I'm in agreement with what you guys want, I just have a mild disagreement about the reason.
05-24-2008 9:18 AM |
Samcov,
So we are in the same camp too. . I agree with what you said and we are also doing what you are doing. Actually we only have one Web Service call just like you what you have described. I was showing 3 just want to compare to the WCF calls justncase80 showed us. Let's hope Microsoft gets what we want.
05-24-2008 9:13 PM |
Samcov: 1.It's all in how you generate the classes 2. The reason you want datasets(or weak typing), etc, is generally for flexibility and SPEED 3 it uses as much reflection as we use for the object based solution to display it in a DataGrid 4. I just have a mild disagreement about the reason.
1.It's all in how you generate the classes
2. The reason you want datasets(or weak typing), etc, is generally for flexibility and SPEED
3 it uses as much reflection as we use for the object based solution to display it in a DataGrid
4. I just have a mild disagreement about the reason.
1. Right, and we generate the classes quite well.
2 Right, and not just flexibility and speed but to minimize the code that gets sent down to the client. If we want to display 1000 tables in a datagrid, we would like to just dataGrid.DataSource=dataset;dataGrid.DataMember="table"; As it is now we must code each table on the client, right? Note: I am not suggesting 1000 table in one dataset, we may have a database navigator type app. where selecting a table gets just that table from the server and displays it in a grid. The data fields may not be know until runtime.
3. Let the reflection do the work, not us. If one compares the reflection of 1 dataset to 1 object based solution then yes, code may be the same, but how about 1000 tables. Creating objects for each one increases the code. This is not a DRY (Do-not Repeat Yourself) solution, because we need to repeat code for each table and field.
4. There are many other reasons, just giving some examples.
We are thankful for the JSON addition. Previously, we created an Xml packet, much like SOAP(but more flexible), that wrapped our datasets and parameters that we sent to and from our webservice. We have dropped it and now use JSON as it removes the need for many parameters on the webserve and the data sent/received is smaller in size too.
05-25-2008 3:57 AM |
Bydia3: 2 Right, and not just flexibility and speed but to minimize the code that gets sent down to the client.
2 Right, and not just flexibility and speed but to minimize the code that gets sent down to the client.
Yes, code minimization is another benefit, you make a lot of good points.
The bottom line is that while the current way the DataGrid works is elegant, but in the pursuit of elegance, we lost the simplicity of efficient design(IMO).
I'm hopeful that we should get something that allows us to set the datagrid at the cell level, and then we can do any kind of binding we want.
I doubt MS will want to bring datasets back, but cell level access will neatly solve the problem.
Sam...
P.S. We're quickly running out of days left in May, so Beta 2 will have to be delivered next week(hopefully).
05-25-2008 9:41 PM |
I'm a believer in code simplicity. I come from a C++ background, so Reflection is not a technique that I regularly look to to solve problems. I tend to shy away from it because of its performance implications.
There's no disputing that someone can't construct types on the fly to send them down the wire so that the client (Silverlight app) can consume them easily (in particular, the DataGrid control).
But I think we are putting the cart before the horse here. The DataGrid represents a VIEW of the data. The data you send down the wire is the MODEL of the data. In my mind the MODEL usually is not heavily dictated by the view technology, and yet here is a perfect example of that.
On the other hand, if you are modelling your data on the application/web-service tier as objects, good on you. Great to see that that approach works well for you. Unfortunately, some people either cannot do that or don't want to do that for reasons such as performance.
I consider the lack of a DataSet/DataTable and the inability to programmatically populate the DataGrid as substantial omissions. DataBinding should be considered a feature of DataGrid, not it's only method of operation, and even worse when the DataBinding capability forces you to use a very particular method of data representation in order to make it work.
Now apparently LINQ-to-SQL can generate anonymous types (whatever they are called) on-the-fly in response to queries. But not everyone is using LINQ so if this is the only "convenient" way of making this happen then it's clearly working against those (like myself) who need to implement things in other ways, perhaps to support an existing code-base.
I'll throw up one word here: Flexibility. The Silverlight way of doing things at present is not currently Flexible to the extent I would like it to be.
Back to my original comment about ITypedList support, this is simply another area of inflexibility within Silverlight which forces you to either have first-class types or instantiate anonymous types in order to get a DataGrid to work, because it is incapable of working with a more generic structure. I don't care if Microsoft don't give me a DataSet or a DataTable - I can write those myself. But to then prevent me from being able to databind against that type of data structure, well then I'm pretty much just writing adapter code for no good reason.
05-26-2008 11:16 PM |
Kevmeister: I'm a believer in code simplicity.... construct types on the fly to send them down the wire ...I consider the lack of a DataSet/DataTable and the inability to programmatically populate the DataGrid as substantial omissions. DataBinding should be considered a feature of DataGrid, not it's only method of operation, and even worse when the DataBinding capability forces you to use a very particular method of data representation in order to make it work.... ..because it is incapable of working with a more generic structure. I don't care if Microsoft don't give me a DataSet or a DataTable - I can write those myself. But to then prevent me from being able to databind against that type of data structure, well then I'm pretty much just writing adapter code for no good reason.
I'm a believer in code simplicity.... construct types on the fly to send them down the wire ...I consider the lack of a DataSet/DataTable and the inability to programmatically populate the DataGrid as substantial omissions. DataBinding should be considered a feature of DataGrid, not it's only method of operation, and even worse when the DataBinding capability forces you to use a very particular method of data representation in order to make it work....
..because it is incapable of working with a more generic structure. I don't care if Microsoft don't give me a DataSet or a DataTable - I can write those myself. But to then prevent me from being able to databind against that type of data structure, well then I'm pretty much just writing adapter code for no good reason.
My point in using a dataset is to NOT construct types on the fly. Just use it as an xml wrapper with methods that help to maintain insert, update and delete state... and a simple way to bind to a datagrid to view the current rows.. Just string data is good enough. Does not need to be complex, doing xml transform on the client to display a html table was good enough for our AJAX solution... cause it is simple. For the web and javascript client, we just pulled the xml(string) from a webservice and accessed it via a javascript object much like server side untyped dataset. The untyped dataset is the type, and values are strings since that's how it comes from the server. Add in schema meta data and we can loop through a columns collection if we want to know the type of the string data and then we can create dynamic forms.
I do recognize that this may not come about because seems like Silverlight wants to go the direction of "Rich" internet app. Up to this point our AJAX had been the richest I have seen due to our inhouse built xml objects for client side access.
05-27-2008 9:44 AM |
a lot of this seems like a limitation in SOAP in general more than Silverlight or a lack of datasets. It's intended to be a strongly defined public API. It really seems like the desire to use Silverlight for generalized reporting is really on the outside of it's sweetspot.
05-27-2008 10:29 PM |
justncase80:a lot of this seems like a limitation in SOAP in general more than Silverlight or a lack of datasets. It's intended to be a strongly defined public API. It really seems like the desire to use Silverlight for generalized reporting is really on the outside of it's sweetspot.
I don't think the focus on "reporting" helps issues any. A web service API based on a DataSet object is as strongly typed as a webservice taking polymorphic objects - which is what must be happening if you have a web service with only 3 functions covering numerous entities. So I don't think we can blame SOAP here.
It's simply a matter of connectability: as I've said before anyone can write a DataSet/DataTable and have that pass back-and-forth between their web-service. The more serious matter is that the serious UI controls such as DataGrid require me to repackage my data in a format fit for its consumption.
DataBinding is slow enough as it is by virtue of using reflection, and now we have numerous examples whereby people are transmitting their data in one format and then repackaging it into a dynamically-constructed type just so the DataGrid can "consume" it? That's nonsense.
And it's also different from what's achievable in say ASP.NET. Even if the approach is considered "not best practice" there's surely going to be a lot of developers getting into Silverlight (from ASP.NET) asking why they have to jump through so many hoops to deliver this kind of data to a Silverlight application.
Where is the KISS principle in what we currently have?
05-27-2008 10:33 PM |
It seems like the simple approach is to use the DataSet (or whatever) on the server side then use a DTO for your webservice and just bind against that directly. Pretty darn simple to me.
05-27-2008 10:41 PM |
justncase80:It seems like the simple approach is to use the DataSet (or whatever) on the server side then use a DTO for your webservice and just bind against that directly. Pretty darn simple to me.
Just because you express the idea in one sentence doesn't make the concept itself simple. Your average .NET programmer is not going to write that DTO that you talk about off the top of their head using IL Emit methods, are they?
And I don't think you can argue that binding directly to the DataSet/DataTable would be even simpler, because there is no DTO involved. Not to mention more efficient and hence more performant.
I think we're going to have to agree to disagree on this.
Edit: Oh, and therefore we'll just have to use your suggested technique at the moment, because aside from the web-service generating these dynamic types, there's not really much else one can do - irrespective of whether your DTO consumes XML, DataTable, DataSet, whatever. DataGrid needs a first-class type to DataBind correctly. But that doesn't mean Microsoft can't make life easier for developers ...
bropa09
0 points
06-12-2008 9:51 AM |
Just thought I'd add my thoughts to the post. Having parity at the core level with styling, templating, triggers, binding and resource dictionaries (merging) with WPF is essential to help with code artefact sharing between WPF and Silverlight and also porting existing WPF applications to Silverlight.
I'm trying to build a WPF application today knowing that I ideally want to also support a Silverlight version as well. I'm trying to build it so that it will be compatible between the two but I am already using core features/syntax that I know are only partially supported (or not at all) in Silverlight. The reason why I am looking to build both is that in order to support advanced simulation plug-ins in 3D you would need to install the full desktop app (and use WPF), but Silverlight could be used as a low deployment footprint with basic 2D simulation support. The simulator visualizers are plug-ins so the basic app remains the same, but the deployment cost is commensurate with the need for more advanced simulation support. It's a choice, but one that would work if a lot of the core WPF capabilities had parity with Silverlight.
Silverlight 2.0 missing features