RE: [OzSilverlight] A couple of questions
Hi all, Yes its right that with using [Serializable] you can use your classes on client side i.e. in Silver Light App. You can use it in DTO Tier. If you have any concerns please let me know. Have a nice Light J Regards, Muhammad Niaz Software Engineer Intagleo Systems (Pvt) Ltd. +92 321 569 4195 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordan Knight Sent: Monday, September 22, 2008 5:36 AM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions I believe DataContractSerializer is compatible with SerializationAttribute... so in theory you should be able to serialise the same classes without modification (even if they are in an older 1.1 or 2.0 assembly that you don't have to source for J) - im going from memory here though From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross McKinnon Sent: Monday, 22 September 2008 9:00 AM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Just quickly, 1) You are mainly suggesting a server based identity, which I did contemplate and implement, but the problem with that is you end up losing some of the silverlight power of local application with the constant need to go back and forth in a complex web application across multiple pages. I did implement a expiring token in local storage, but that has a number of architectural syncronisation problems with the server based asp.net security model which works so well. 2) Good to hear. 3) Interesting. I just didn't think it would be that simple. 4) Silverlight works reasonably well with the XML Formatter, expecially when you put it in with Linq to SQL, with most things being tied into nice classes, but not having the binary formatter you lose a degree of flexibility in being able to serialise anything. Thanks, Ross. PS, we should catch up anyway when you are back if you have a spare hour or two. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Thursday, 18 September 2008 5:20 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Hi Ross! (long time no speak) J 1) You have a number of options, essentially the easiest way is to tap into the Windows Communication Foundation services and utilize this option. It's essentially sending data over the wire in XML format, Silverlight has great hooks already built in to handle these type of requests. We're also looking to do more here to make things more seamless in upcoming versions. I can't say more than that, but it will get a lot easier in the long term. 2) That's the intent going forward. We see a great deal of positive power with using LINQ inside Silverlight and WPF. It's almost safe to say out loud to think of LINQ as you're Data Passport between client and server. There will be more expansion on this in the future as well. 3) Security will remain similar or if not the same as ASP.NET today. The difference is on the client, you essentially need to architect in such a way that the initial first ask is defining whom the person is and what their session may look like. From there, it's a case of CanIHaveAccessTo(args) style security access (given you're in a non-Refresh situation - assuming this is a 100% Silverlight App by the way). Now, the danger here is if not architected correctly is that you can fake the true/false responses, so the further piece to this is to maybe consider using XAML over the wire. In that can I have access to ViewAllUsrProfiles?, If the answer is true, you essentially trigger a .xap download or you load .XAML remotely, via an ASP.NET page (pushing the content). As this will also be a secondary check to make sure they did indeed have positive response to the question 4) Could you expand on the Binary Formatter? I.e. what do you have in mind? 5) We're working on smarter ways to go between Client and Server, but can't say much just yet on what that will look like. We're still actively planning features and so feel free to expand on what you're thinking here as I'm more than happy to walk this into the next planning meeting and discuss with the team. P.S I'll be back home in Brisbane (currently Belinda and I are living in Seattle now) around XMAS time. So if you're still stuck around then, I'm sure we can find a EY event to meet up at and discuss in depth over a beer or two. Failing that, feel free to contact me offline to discuss in depth should the above not be enough (same goes for anyone on this list btw). -- Scott Barnes (Rich Platforms Product Manager) Microsoft Corp. http://www.microsoft.com/ | Blog: http://blogs.msdn.com/msmossyblog http://blogs.msdn.com/msmossyblog | Mobile: + 1 (425) 802-9503 (New!) Twitter: twitter.com/mossyblog http://twitter.com/mossyblog | MSN: [EMAIL PROTECTED] P Please consider your environmental
RE: [OzSilverlight] A couple of questions
Well let me weigh in where I can :) · You essentially create a Façade that handles registering/unregistering command classes. The job of this façade is to marry both an EventClass and CommandClass together (as well as echo the state of the applications mode - ie Initializing, Loaded etc). · A CommandClass is essentially a packet of Business Logic. It's job is to execute on a given role, in that it may ask the ModelLocator for state based information or it may request a service (via delegate pattern) to fire a remote response. It can also act as a payload for SubCommands as well (a Command can instantiate other commands within - via a Macro Command like pattern). · When you fire an Event via Notification/Observer (ie in our case it just bubbles an event against a known index, so many Listeners can act on the same event) it will the FrontController will automatically interpret this event and fire the command it's married to via the executeCommand() method (or however you want to structure this). So essentially you can be anywhere in the view so to speak (typically you want to marry a view with a viewhelper to promote re-use for the view vs simply a code-behind (this is more of code style though so it's got no hard fast rule here). The ViewHelper simply needs to fire a Notification event (via a singleton class) and the rest will orchestrate itself. Now, the secret to the orchestration is that you want to have a Model which you bind your controls to, in that pretty much like old school DataSets, you simply bind the controls to properties within respective models. When you fire a command, what you want to do is via the executeCommand() update that given model as this will automatically update yoru view throughout (you can do some interesting binding routines here and get away with it). The trick for us however is you need to ensure the INotifyPropertyChanged is implemented in the Model, as you need to tell the controls that new data is in the model and they should refresh (we hope to clean this up in future releases may I add, as yes it's an absolute pain in the royal butt). I plan on releasing some code via new project I've started called Nexus (which I'm extremely excited about and thank this list for inspiration for such an idea). http://blogs.msdn.com/msmossyblog/archive/2008/09/19/introducing-ms-project-nexus.aspx From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Madero Sent: Friday, September 19, 2008 7:11 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Scott, Sounds interesting, specially for composite applications (a'la CAB), but I think that could be a bit complex for simpler views/apps, something like what Nikhil did with the Scripts was really simple and straightforward, the only disadvantage I saw was that it added heavy dependencies to the dlr. Miguel A. Madero Reyes www.miguelmadero.comhttp://www.miguelmadero.com/ (blog) [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] (871)730-8319 (871)763-0020 Peten #509 Fracc Florida Blanca, 27260 Torreón, Coahuila P Please reconsider your environmental responsibility before printing this e-mail The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Friday, 19 September 2008 3:52 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions The other benefit of Commands is that essentially you can throw the same command from different areas within your View, which helps reduce coupling of the View with how the overall traffic flows within your Client. You can build a FrontController class which marries both the Event and Command together today. Given that Silverlight has RoutedEvents, one could simply throw an Event (through a homemade EventDispatcher), the FrontController catches it and marries the event with a command and then the command fires a execute method. This in turn will carry out the workflow required in order to achieve a successful command delivery. Upon a result, the command can also throw another command (depending on the data returned) and so on. This is good, as it essentially allows again multiple events to feed off the same commands (but yet have different semantic value) whilst at the same time keeping parts of the overall view abstracted from one another. Martin Fowler's J2EE patterns have some good paths here to follow around this kind of thing. Actually I feel a blog post + code brewing now.. stand by.. (*cracks fingers* - time to put my code where my mouth is!) -- Scott Barnes (Rich Platforms Product Manager) Microsoft Corp.http
RE: [OzSilverlight] A couple of questions
Scott, This looks like something Ive been looking for, actually Ive been discussing this before with several people and thought we might not see it til v3. Could you let me know more about how to dynamically load the xaps? This could really help to load 3rd party libraries, frameworks, dlr, etc without double taxing. Miguel A. Madero Reyes http://www.miguelmadero.com/ www.miguelmadero.com (blog) mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] (871)730-8319 (871)763-0020 Peten #509 Fracc Florida Blanca, 27260 Torreón, Coahuila P Please reconsider your environmental responsibility before printing this e-mail The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Friday, 19 September 2008 3:34 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Jonas, Correct but it also depends at what level youre at and what you define is secret. In that if a user is authenticated and you have all the forms for example housed in the .XAP (which is fine), then before you accept and receive data between the client and server you need to sanitize it and ensure the user doesnt go rogue. Its something at times Ive seen folks in both Flash and Silverlight space overlook (as once they get through the security gate, its an assumed the user will not interfere with the client). It can be small things like switching parts of the UI on or off and the more clues you give a malicious user, the more they have to work with in terms of figuring out what it is you have written and how you expect data to be sent back and forth. Its more of a cautionary tip and Id highly recommend folks (when it comes to Admin vs. Public) look into dynamically loading .XAP files or more to the point bring XAML in over the wire as well. Ive gotten loading of modules to work dynamically and should post some demo code around this as its quite cool to bring in .XAP files over the wire as needed. As when you load a .XAP file, it stores it local cache (ie not in memory) and then feeds from it when it needs it as well, so the tax isnt high. You also can do sniff tests to determine if an assembly is loaded or not and if it isnt go get it. Ive taken a framework I wrote in the early days of Flex and ported it over to Silverlight, (SynergyFlex = SynergyLight) :D and as we draw closer to Silverlight 2 ship dates Ill see if I can spare up some time to release it as a basic starter guide to some of these ideas. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, September 18, 2008 5:12 AM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Scott, On point 3, why would that matter? Even if you fake the response and trick your Silverlight app (which would be easy, just download the XAP, unzip it, and have it talk to a different end-point), your XAML shouldn't really contain any secret information anyway. Your users is not part of your markup, that's just data. That information should be sent to the user in an authenticated WCF call So even if you manage to enable the show all user screen, your service should re-validate on the server side before giving you that data. But there might be cases where what you describe makes allot of sense. And partial loading of XAP's is quite interesting stuff - could be useful for things like composite Silverlight applications, where you download modules as needed. On Thu, Sep 18, 2008 at 5:19 PM, Scott Barnes [EMAIL PROTECTED] wrote: Hi Ross! (long time no speak) J 1) You have a number of options, essentially the easiest way is to tap into the Windows Communication Foundation services and utilize this option. It's essentially sending data over the wire in XML format, Silverlight has great hooks already built in to handle these type of requests. We're also looking to do more here to make things more seamless in upcoming versions. I can't say more than that, but it will get a lot easier in the long term. 2) That's the intent going forward. We see a great deal of positive power with using LINQ inside Silverlight and WPF. It's almost safe to say out loud to think of LINQ as you're Data Passport between client and server. There will be more expansion on this in the future as well. 3) Security will remain similar or if not the same as ASP.NET today. The difference is on the client, you essentially need to architect in such a way that the initial first ask is defining whom the person is and what their session may look like. From there, it's a case of CanIHaveAccessTo(args) style security access (given
RE: [OzSilverlight] A couple of questions
Scott, Sounds interesting, specially for composite applications (ala CAB), but I think that could be a bit complex for simpler views/apps, something like what Nikhil did with the Scripts was really simple and straightforward, the only disadvantage I saw was that it added heavy dependencies to the dlr. Miguel A. Madero Reyes http://www.miguelmadero.com/ www.miguelmadero.com (blog) mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] (871)730-8319 (871)763-0020 Peten #509 Fracc Florida Blanca, 27260 Torreón, Coahuila P Please reconsider your environmental responsibility before printing this e-mail The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Friday, 19 September 2008 3:52 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions The other benefit of Commands is that essentially you can throw the same command from different areas within your View, which helps reduce coupling of the View with how the overall traffic flows within your Client. You can build a FrontController class which marries both the Event and Command together today. Given that Silverlight has RoutedEvents, one could simply throw an Event (through a homemade EventDispatcher), the FrontController catches it and marries the event with a command and then the command fires a execute method. This in turn will carry out the workflow required in order to achieve a successful command delivery. Upon a result, the command can also throw another command (depending on the data returned) and so on. This is good, as it essentially allows again multiple events to feed off the same commands (but yet have different semantic value) whilst at the same time keeping parts of the overall view abstracted from one another. Martin Fowlers J2EE patterns have some good paths here to follow around this kind of thing. Actually I feel a blog post + code brewing now.. stand by.. (*cracks fingers* - time to put my code where my mouth is!) -- Scott Barnes (Rich Platforms Product Manager) http://www.microsoft.com/ Microsoft Corp. | Blog: http://blogs.msdn.com/msmossyblog http://blogs.msdn.com/msmossyblog | Mobile: + 1 (425) 802-9503 (New!) Twitter: http://twitter.com/mossyblog twitter.com/mossyblog | MSN: [EMAIL PROTECTED] P Please consider your environmental responsibility before printing this e-mail From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, September 18, 2008 8:23 PM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like IsSaveEnabled to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any btnSave_Click event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up owning part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie [EMAIL PROTECTED] wrote: It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn
RE: [OzSilverlight] A couple of questions
+1 on triggers/data triggers. It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, 18 September 2008 10:24 PM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions I tend to favor the Model-View-ViewModel pattern for Silverlight and WPF, and is _really_ concerned with providing a best possible design time experience. I always strive for no-code behind in my applications. These are some of the challenges: * No support for commands. Can be implemented using attached properties. But commands is important to prevent coupling between event invoker (button/UI element) and event handler. The fewer named elements you have to hook events against the better. More flexibility to designer, less chance to screw up. * No support for triggers/data triggers. Today there is no easy way to trigger an animation based on changes made in the ViewModel. For instance, say I set an IsBussy property to true, in that case I would like to start a ProgressBarAnimation. Today I have to write code behind to do that. Nikhil Kothari has some interesting examples on how to use behaviors to achieve trigger-like behavior in Silverlight. But his current implementation breaks Blend 2.5 support, so I haven't been able to use it. * Not allot of guidance on multi page navigation. This is something I've gotten allot of questions. I normally solve this by swapping parts in and out of a master page, and have a navigation helper on the Application object. But some clear guidance on this would be helpful. * How to provide design time dummy data. I solve this by providing mock implementations of external services, and it works quite well. I use the HtmlPage.IsEnabled to detect weather or not the code is running in Blend. I know this isn't a good check, and that this property is actually used to check if the host has blocked access to the HTML DOM. So a better hook to see where the code is executing would be valuable. * Validation and Data Binding. I'm not a big fan of the way you have to hook event handlers to handle the binding exception event when doing validation. This forces me to add code in the code-behind. I wish I could solve this more declarative. Nikhils behaviors might be one way, a custom control could be another solution. These are some of the initial comments on this topic. I agree that it's interesting to see what people are discovering about Silverlight. At the same time it's also good to reuse alot of experience from WPF. I know Rocky Lotkha is doing interesting things with CSLA.NEThttp://CSLA.NET, and there is all ready an early port of Prism for Silverlight (Composite WPF Guidance). Cheers, Jonas :) On Thu, Sep 18, 2008 at 5:28 PM, Scott Barnes [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: I'm seeing a bit of traffic these days around how to architect Silverlight. I think this is exciting news as folks have not only digested Silverlight well, but are now pushing beyond the boundaries (growth is a powerful thing to monitor and observe). I've got a few ideas on how to solve this, but am curious to hear some of your pain points specifically around what hurdles you face when architecting Rich Applications such as Silverlight? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of .net noobie Sent: Wednesday, September 17, 2008 9:43 PM To: listserver@ozsilverlight.commailto:listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions ok cool, thanks On Thu, Sep 18, 2008 at 2:31 PM, Jonas Follesø [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Well, you can actually do all this from a Silverlight application. And anything you could do from MS AJAX, you could do from Silverlight. And to be fair the Client Application Services (for Windows Forms/WPF) comes with classes that abstract away the service interaction, and actually gives you a client side Membership- and Role Provider. But under the hood it's all HTTP JSON calls (I assume for performance reasons, as their API only has synchronous methods for accessing the Membership- and Role Provider). Check this post: http://blogs.msdn.com/brada/archive/2007/05/23/net-client-application-services.aspx for more information on what you can do. The service-end point used by the Client Application Services client libraries are: http://localhost/myservice/Profile_JSON_AppService.axd http://localhost/myservice/Authentication_JSON_AppService.axd http://localhost/myservice/Role_JSON_AppService.axd You don't get WSDL for these services, but you can invoke them as REST services and do things like create user, create role etc. given that the currently authenticated user have the permissions needed. On Thu, Sep 18, 2008 at 2:19 PM, .net noobie [EMAIL PROTECTED]mailto
Re: [OzSilverlight] A couple of questions
It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn) --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like IsSaveEnabled to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any btnSave_Click event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up owning part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie [EMAIL PROTECTED]wrote: It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn) --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
but you can write storyboards in code, not that is is as easy as just drop and drag in blend On Fri, Sep 19, 2008 at 1:23 PM, Jonas Follesø [EMAIL PROTECTED] wrote: Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like IsSaveEnabled to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any btnSave_Click event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up owning part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie [EMAIL PROTECTED]wrote: It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn) --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net -- .net noobie™ --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
The whole point is to have as little code as possible. And doing storyboards in code is deff. not the solution to this problem. The whole point is to use patterns that lets your designer own the user experience and not depend on code and Visual Studio. But sure, procedural animations is a powerful technique, and useful in a bunch of cases (where to want some randomness/dynamicness to the animation. On Fri, Sep 19, 2008 at 1:41 PM, .net noobie [EMAIL PROTECTED] wrote: but you can write storyboards in code, not that is is as easy as just drop and drag in blend On Fri, Sep 19, 2008 at 1:23 PM, Jonas Follesø [EMAIL PROTECTED] wrote: Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like IsSaveEnabled to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any btnSave_Click event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up owning part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie [EMAIL PROTECTED]wrote: It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn) --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net -- .net noobie™ --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
RE: [OzSilverlight] A couple of questions
Jonas, Correct but it also depends at what level you're at and what you define is secret. In that if a user is authenticated and you have all the forms for example housed in the .XAP (which is fine), then before you accept and receive data between the client and server you need to sanitize it and ensure the user doesn't go rogue. It's something at times I've seen folks in both Flash and Silverlight space overlook (as once they get through the security gate, it's an assumed the user will not interfere with the client). It can be small things like switching parts of the UI on or off and the more clues you give a malicious user, the more they have to work with in terms of figuring out what it is you have written and how you expect data to be sent back and forth. It's more of a cautionary tip and I'd highly recommend folks (when it comes to Admin vs. Public) look into dynamically loading .XAP files or more to the point bring XAML in over the wire as well. I've gotten loading of modules to work dynamically and should post some demo code around this as it's quite cool to bring in .XAP files over the wire as needed. As when you load a .XAP file, it stores it local cache (ie not in memory) and then feeds from it when it needs it as well, so the tax isn't high. You also can do sniff tests to determine if an assembly is loaded or not and if it isn't go get it. I've taken a framework I wrote in the early days of Flex and ported it over to Silverlight, (SynergyFlex = SynergyLight) :D and as we draw closer to Silverlight 2 ship dates I'll see if I can spare up some time to release it as a basic starter guide to some of these ideas. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, September 18, 2008 5:12 AM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Scott, On point 3, why would that matter? Even if you fake the response and trick your Silverlight app (which would be easy, just download the XAP, unzip it, and have it talk to a different end-point), your XAML shouldn't really contain any secret information anyway. Your users is not part of your markup, that's just data. That information should be sent to the user in an authenticated WCF call So even if you manage to enable the show all user screen, your service should re-validate on the server side before giving you that data. But there might be cases where what you describe makes allot of sense. And partial loading of XAP's is quite interesting stuff - could be useful for things like composite Silverlight applications, where you download modules as needed. On Thu, Sep 18, 2008 at 5:19 PM, Scott Barnes [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Hi Ross! (long time no speak) :) 1) You have a number of options, essentially the easiest way is to tap into the Windows Communication Foundation services and utilize this option. It's essentially sending data over the wire in XML format, Silverlight has great hooks already built in to handle these type of requests. We're also looking to do more here to make things more seamless in upcoming versions. I can't say more than that, but it will get a lot easier in the long term. 2) That's the intent going forward. We see a great deal of positive power with using LINQ inside Silverlight and WPF. It's almost safe to say out loud to think of LINQ as you're Data Passport between client and server. There will be more expansion on this in the future as well. 3) Security will remain similar or if not the same as ASP.NEThttp://ASP.NET today. The difference is on the client, you essentially need to architect in such a way that the initial first ask is defining whom the person is and what their session may look like. From there, it's a case of CanIHaveAccessTo(args) style security access (given you're in a non-Refresh situation - assuming this is a 100% Silverlight App by the way). Now, the danger here is if not architected correctly is that you can fake the true/false responses, so the further piece to this is to maybe consider using XAML over the wire. In that can I have access to ViewAllUsrProfiles?, If the answer is true, you essentially trigger a .xap download or you load .XAML remotely, via an ASP.NEThttp://ASP.NET page (pushing the content). As this will also be a secondary check to make sure they did indeed have positive response to the question 4) Could you expand on the Binary Formatter? I.e. what do you have in mind? 5) We're working on smarter ways to go between Client and Server, but can't say much just yet on what that will look like. We're still actively planning features and so feel free to expand on what you're thinking here as I'm more than happy to walk this into the next planning meeting and discuss with the team. P.S I'll be back home in Brisbane (currently Belinda and I are living in Seattle now) around XMAS time. So if you're
RE: [OzSilverlight] A couple of questions
The other benefit of Commands is that essentially you can throw the same command from different areas within your View, which helps reduce coupling of the View with how the overall traffic flows within your Client. You can build a FrontController class which marries both the Event and Command together today. Given that Silverlight has RoutedEvents, one could simply throw an Event (through a homemade EventDispatcher), the FrontController catches it and marries the event with a command and then the command fires a execute method. This in turn will carry out the workflow required in order to achieve a successful command delivery. Upon a result, the command can also throw another command (depending on the data returned) and so on. This is good, as it essentially allows again multiple events to feed off the same commands (but yet have different semantic value) whilst at the same time keeping parts of the overall view abstracted from one another. Martin Fowler's J2EE patterns have some good paths here to follow around this kind of thing. Actually I feel a blog post + code brewing now.. stand by.. (*cracks fingers* - time to put my code where my mouth is!) -- Scott Barnes (Rich Platforms Product Manager) Microsoft Corp.http://www.microsoft.com/ | Blog: http://blogs.msdn.com/msmossyblog | Mobile: + 1 (425) 802-9503 (New!) Twitter: twitter.com/mossybloghttp://twitter.com/mossyblog | MSN: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] P Please consider your environmental responsibility before printing this e-mail From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, September 18, 2008 8:23 PM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Well, I can't answer for Jordan but I'll try to illustrate. While using the Model-View-ViewModel pattern you have all your UI state and behavior in a separate class. This class is normally set as the data context on your View (XAML page), and you bind everything against this class. Even things like IsSaveEnabled to enable the save button. The View communicates back to the ViewModel by commands. The benefit is that you don't have any btnSave_Click event handler in your codebehind. Instead your ViewModel waits for that Command to trigger, and then do the work. The benefit of designing your application using these patterns is that you can build quite big applications with (almost) no code-behind. This makes your app easier to test, more maintainable, and easier to work with for a designer using Blend. So what is the problem? The problem is that there is no declarative(XAML) way of triggering animations when thing happens. So if you want to start a storyboard then the ViewModel IsBussy property is true, you will have to write this code by hand. Typically that would involve listening to a PropertyChanged event in the codebehind of the form, and when the ViewModel IsBussy changes to true, then start the storyboard, when it changes to false, then stop it. This isn't the end of the world, but when we're so close to achieving no-code behind it would be nice to go all the way. Also, doing this forces your designer to have a stroyboard with that exact name (say ShowProgressanimation) present, so you as the developer ends up owning part of the user experience. If the designer accidentally deletes the storyboard the app will fail at runtime, or perhaps not even compile. The less named elements in your XAML file the better. - Jonas On Fri, Sep 19, 2008 at 1:12 PM, Barry Beattie [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: It's a PITA to make apps with all the bells and whistles in XAML then have to break M-V-VM to finish it off. got an example to show what you mean? (just curious/wanting to learn) --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.comhttp://mailenable.com - List managed by www.readify.nethttp://www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
Jordan - that's a clever way to do create dummy data - looking forward to your blog post. Like I mentioned at TechEd I've been playing with the idea of using a HTTP proxy to sniff up test data, but your approach is probably easier. A more drastic approach a colleague of mine is using (for WPF) is to have a SQL Compact Edititon database with dummy data. So we're toying with the idea of building something similar to the Dummy Data Generator in Visual Studio Data Dude (don't know the official name of that product), as well as a simple general purpose UI for the designer to interact with the SQL Compact Edititon database to add new test data to it... Scott - You're right. I've seen examples over and over of developers getting a little confused of the whole server vs client scenario with AJAX and particular Silverlight applications. And really making sure people understand that users can tamper with the data, and really caring about security is key. Looking forward to your post on dynamic loading. Personally I find that exciting from a composite application where you might want to load different modules for different users. I'll give you a private reply with my involvement with Silverlight - But it's a deep love relationship;) On Fri, Sep 19, 2008 at 3:41 PM, Jordan Knight [EMAIL PROTECTED]wrote: For dummy data I've been serialising out my models to iso storage, then picking up the files from the iso directory and placing them in the XAP for deserialisation … it's been a great way to get real dummy data. I have a blog post in the works on this *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Scott Barnes *Sent:* Friday, 19 September 2008 3:33 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions · Commands. I've seen a few requests around this, and I've made notes of them with the team already but yeah, I agree. · Triggers/Data. Well Nikhil's one of our architects in the Silverlight camp, so the fact he wrote about may indicate our thinking of where this will end up eventually ;) · Guidance is a blindspot, 100% agree and I'm working with the Patterns Practices team on this, so stay tuned. · Dummy Data. Interesting approach, hadn't thought of that, I'll defer my answer until after I speak with some of the teams about some ideas around this. · Validation + Data Binding. We're spending a lot of time and energy on this, and I'd love to share but it's still early days on what our plans are here. That being said, I'll make sure to follow-up with the list as things draw closer (adding this email to my follow-ups) to ensure we explain ourselves here. That all put aside, I'm also really curious to see what types of solutions folks are building. I'm also super keen to find out how most of you landed on Silverlight and what your love/hate with the product is? (Can I ask you send me this via little-r so I can continue the conversation with folks privately as it may get noisy with the list if we echo it all outloud?) *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, September 18, 2008 5:24 AM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions I tend to favor the Model-View-ViewModel pattern for Silverlight and WPF, and is _really_ concerned with providing a best possible design time experience. I always strive for no-code behind in my applications. These are some of the challenges: - No support for commands. Can be implemented using attached properties. But commands is important to prevent coupling between event invoker (button/UI element) and event handler. The fewer named elements you have to hook events against the better. More flexibility to designer, less chance to screw up. - No support for triggers/data triggers. Today there is no easy way to trigger an animation based on changes made in the ViewModel. For instance, say I set an IsBussy property to true, in that case I would like to start a ProgressBarAnimation. Today I have to write code behind to do that. Nikhil Kothari has some interesting examples on how to use behaviors to achieve trigger-like behavior in Silverlight. But his current implementation breaks Blend 2.5 support, so I haven't been able to use it. - Not allot of guidance on multi page navigation. This is something I've gotten allot of questions. I normally solve this by swapping parts in and out of a master page, and have a navigation helper on the Application object. But some clear guidance on this would be helpful. - How to provide design time dummy data. I solve this by providing mock implementations of external services, and it works quite well. I use the HtmlPage.IsEnabled to detect weather or not the code is running in Blend. I know this isn't a good check
RE: [OzSilverlight] A couple of questions
Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff :). Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NET Authentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross McKinnon Sent: Thursday, 18 September 2008 12:20 PM To: listserver@ozSilverlight.com Subject: [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds are not the suggested best practice. 1) What is the best way of persisting user identity through multiple silverlight pages? 2) It appears to me that linq to SQL entities seem to lose the ability to maintain state (ie know what is changed) after passing through a wcf call and silverlight treats it like a normal class. Is that the case and if so, is that going to be changed? 3) What is the best practice for integrating security and sessions between asp.net / silverlight / wcf? 4) Are there plans for a binary formatter in the silverlight framework? 5) I have been overlaying silverlight pages over aspx with master and content pages. The largest issue with that is being able to pass information between your master and content pages (easily achievable in aspx), but are there any plans to implement a method to easily pass information between SL pages on the client (usually user specific information), other than at creation of the page. Thanks for any help in advance, Ross. 18/9/2008 Ross McKinnon listserver@ozSilverlight.com This email and any attachments (Email) are intended only for the addressee and may contain privileged, confidential and/or disclosure-exempt information. You must not edit this Email without our express consent. Michael Hill Jeweller (Australia) Pty Ltd does not warrant that this Email is complete, error-free or virus free, and by opening any attachments, you accept full responsibility for the consequences. If you are not the addressee, you must not disseminate, rely upon or copy this Email, and you must immediately erase permanently and destroy all records of it and notify us by phone (at our cost). Thank you. --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
RE: [OzSilverlight] A couple of questions
Sorry Ross :) - not Michael. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordan Knight Sent: Thursday, 18 September 2008 12:35 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff :). Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NET Authentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross McKinnon Sent: Thursday, 18 September 2008 12:20 PM To: listserver@ozSilverlight.com Subject: [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds are not the suggested best practice. 1) What is the best way of persisting user identity through multiple silverlight pages? 2) It appears to me that linq to SQL entities seem to lose the ability to maintain state (ie know what is changed) after passing through a wcf call and silverlight treats it like a normal class. Is that the case and if so, is that going to be changed? 3) What is the best practice for integrating security and sessions between asp.net / silverlight / wcf? 4) Are there plans for a binary formatter in the silverlight framework? 5) I have been overlaying silverlight pages over aspx with master and content pages. The largest issue with that is being able to pass information between your master and content pages (easily achievable in aspx), but are there any plans to implement a method to easily pass information between SL pages on the client (usually user specific information), other than at creation of the page. Thanks for any help in advance, Ross. 18/9/2008 Ross McKinnon listserver@ozSilverlight.com This email and any attachments (Email) are intended only for the addressee and may contain privileged, confidential and/or disclosure-exempt information. You must not edit this Email without our express consent. Michael Hill Jeweller (Australia) Pty Ltd does not warrant that this Email is complete, error-free or virus free, and by opening any attachments, you accept full responsibility for the consequences. If you are not the addressee, you must not disseminate, rely upon or copy this Email, and you must immediately erase permanently and destroy all records of it and notify us by phone (at our cost). Thank you. --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
RE: [OzSilverlight] A couple of questions
You where slowed down by all the extra detail :) Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, 18 September 2008 12:42 PM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Sorry Ross :) - not Michael. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Jordan Knight Sent: Thursday, 18 September 2008 12:35 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NEThttp://ASP.NET membership - i.e. use the normal stuff :). Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NEThttp://ASP.NET Authentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] | W: www.readify.nethttp://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Ross McKinnon Sent: Thursday, 18 September 2008 12:20 PM To: listserver@ozSilverlight.com Subject: [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds are not the suggested best practice. 1) What is the best way of persisting user identity through multiple silverlight pages? 2) It appears to me that linq to SQL entities seem to lose the ability to maintain state (ie know what is changed) after passing through a wcf call and silverlight treats it like a normal class. Is that the case and if so, is that going to be changed? 3) What is the best practice for integrating security and sessions between asp.nethttp://asp.net / silverlight / wcf? 4) Are there plans for a binary formatter in the silverlight framework? 5) I have been overlaying silverlight pages over aspx with master and content pages. The largest issue with that is being able to pass information between your master and content pages (easily achievable in aspx), but are there any plans to implement a method to easily pass information between SL pages on the client (usually user specific information), other than at creation of the page. Thanks for any help in advance, Ross. 18/9/2008 Ross McKinnon listserver@ozSilverlight.com This email and any attachments (Email) are intended only for the addressee and may contain privileged, confidential and/or disclosure-exempt information. You must not edit this Email without our express consent. Michael Hill Jeweller (Australia) Pty Ltd does not warrant that this Email is complete, error-free or virus free, and by opening any attachments, you accept full responsibility for the consequences. If you are not the addressee, you must not disseminate, rely upon or copy this Email, and you must immediately erase permanently and destroy all records of it and notify us by phone (at our cost). Thank you. --- OzSilverlight.com - to unsubscribe from
RE: [OzSilverlight] A couple of questions
Thanks to both of you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordan Knight Sent: Thursday, 18 September 2008 12:44 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | W: www.readify.net http://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Follesø Sent: Thursday, 18 September 2008 12:42 PM To: listserver@ozsilverlight.com Subject: Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | W: www.readify.net http://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordan Knight Sent: Thursday, 18 September 2008 12:35 PM To: listserver@ozSilverlight.com Subject: RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NET Authentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, Jordan Knight Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | W: www.readify.net http://www.readify.net/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross McKinnon Sent: Thursday, 18 September 2008 12:20 PM To: listserver@ozSilverlight.com Subject: [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds are not the suggested best practice. 1) What is the best way of persisting user identity through multiple silverlight pages? 2) It appears to me that linq to SQL entities seem to lose the ability to maintain state (ie know what is changed) after passing through a wcf call and silverlight treats it like a normal class. Is that the case and if so, is that going to be changed? 3) What is the best practice for integrating security and sessions between asp.net / silverlight / wcf? 4) Are there plans for a binary formatter in the silverlight framework? 5) I have been overlaying silverlight pages over aspx with master and content pages. The largest issue with that is being able to pass information between your master and content pages (easily achievable in aspx), but are there any plans to implement a method to easily pass information between SL pages on the client (usually user specific information), other than at creation of the page. Thanks for any help in advance, Ross. 18/9/2008 Ross McKinnon listserver@ozSilverlight.com This email and any attachments (Email) are intended only for the addressee and may contain privileged, confidential and/or disclosure-exempt information. You must not edit this Email without our express consent. Michael Hill Jeweller (Australia) Pty Ltd does not warrant that this Email is complete, error-free or virus free, and by opening any attachments, you accept full responsibility for the consequences. If you are not the addressee, you must not disseminate, rely upon or copy this Email, and you must immediately erase permanently and destroy
Re: [OzSilverlight] A couple of questions
Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NET Authentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Ross McKinnon *Sent:* Thursday, 18 September 2008 12:20 PM *To:* listserver@ozSilverlight.com *Subject:* [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds are not the suggested best practice. 1) What is the best way of persisting user identity through multiple silverlight pages? 2) It appears to me that linq to SQL entities seem to lose the ability to maintain state (ie know what is changed) after passing through a wcf call and silverlight treats it like a normal class. Is that the case and if so, is that going to be changed? 3) What is the best practice for integrating security and sessions between asp.net / silverlight / wcf? 4) Are there plans for a binary formatter in the silverlight framework? 5) I have been overlaying silverlight pages over aspx with master and content pages. The largest issue with that is being able to pass information between your master and content pages (easily achievable in aspx), but are there any plans to implement a method to easily pass information between SL pages on the client
Re: [OzSilverlight] A couple of questions
From a Silverlight client point of view, what else do you really need? Everything that has to do with validation, accessing user store etc. has to happen on the server and not on the client. Some thing, like Authorization (does this user belong to this role) is useful from the UI, as you can enable/disable certain buttons and functionality. But in the end you have to redo all the validation on the server as you can't trust any input coming from the client. The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. You got functionality to create new users, create roles, change role assignment etc. To do those things from a Silverlight client you would have to expose (and secure) the individual pieces your self. On Thu, Sep 18, 2008 at 2:00 PM, .net noobie [EMAIL PROTECTED] wrote: Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NETAuthentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Ross McKinnon *Sent:* Thursday, 18 September 2008 12:20 PM *To:* listserver@ozSilverlight.com *Subject:* [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process of replacing our global website. The executive here are very excited by the opportunities presented by silverlight and we will be developing the new site using this technology and are trying to release it as soon as possible. I did have a couple of questions which I have posed to Microsoft, but they have been unable to answer and most of them are directed towards my personally perceived weaknesses of silverlight and I was hoping that someone would be able to point out how they can be achieved. Hopefully our work arounds
Re: [OzSilverlight] A couple of questions
The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. bingo. from what I've seen people do (and truth be told I sometimes fall into this myself) is being so caught up in this blurring between client and server (esp coding within VS) that this can be easy to forget. it's standard Client/Server with a twist - the client is only occasionally connected (at least until you can push from Server back to client without polling) meh, my 2c --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
new users, create roles, change role assignment etc. they are the things I wanted to do... so really I would be better off handling all this in the ASP.NET page that is hosting my Silverlight Applications and then talking too and from the ASP.NET page with my Silverlight Application to do these things? then to stop the page reloading I would need to do these tasks new users, create roles, change role assignment etc. via something like MS AJAX...? On Thu, Sep 18, 2008 at 2:07 PM, Jonas Follesø [EMAIL PROTECTED] wrote: From a Silverlight client point of view, what else do you really need? Everything that has to do with validation, accessing user store etc. has to happen on the server and not on the client. Some thing, like Authorization (does this user belong to this role) is useful from the UI, as you can enable/disable certain buttons and functionality. But in the end you have to redo all the validation on the server as you can't trust any input coming from the client. The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. You got functionality to create new users, create roles, change role assignment etc. To do those things from a Silverlight client you would have to expose (and secure) the individual pieces your self. On Thu, Sep 18, 2008 at 2:00 PM, .net noobie [EMAIL PROTECTED]wrote: Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NETAuthentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Ross McKinnon *Sent:* Thursday, 18 September 2008 12:20 PM *To:* listserver@ozSilverlight.com *Subject:* [OzSilverlight] A couple of questions Hi all, I am the CIO of Michael Hill Jeweller which is an international (US, Canada, New Zealand, Australia) jewellery retail chain whose global head office is based in Brisbane and we are in the process
Re: [OzSilverlight] A couple of questions
Yepp. You're right Barry. And with Silverlight this gets even more confusing since it's all happening in the browser. So the rule of thumb is that Silverlight has WAY more in common with WPF than ASP.NET. So use the WPF mindset, not the ASP.NET mindset when thinking about these application. That being said, you often end up replicating business logic on both server and client. You want to have the logic on the client so that the user don't have to do lots of edits, then only to get an exception back from the server saying that the input data was invalid. But at the same time your server cannot depend on the client passing in valid data. Building these (rich) clients that have a deep understanding of the server is tricky. Pat Helland discusses this in his The Emissary Design Pattern and RIAs talk ( http://blogs.msdn.com/pathelland/archive/2008/08/10/the-emissary-design-pattern-and-rias-rich-internet-applications.aspx). And I expect some of these ideas making it into this PDC08 talk: Microsoft Silverlight Futures: Building Business Focused Applications What if you could develop your solutions with the ease pioneered by Microsoft Office Access, deploy them like an Internet application, and take advantage of the power of Microsoft .NET? Learn about an exciting new technology that is all about making business applications for RIA (Rich Internet Applications) much easier to build. In this session, hear how we've made n-tier application development as simple as traditional 2-tier, provided application level solutions to developers, and how we're doing all of this with the same .NET platform and tools on both the client and server. On Thu, Sep 18, 2008 at 2:17 PM, Barry Beattie [EMAIL PROTECTED]wrote: The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. bingo. from what I've seen people do (and truth be told I sometimes fall into this myself) is being so caught up in this blurring between client and server (esp coding within VS) that this can be easy to forget. it's standard Client/Server with a twist - the client is only occasionally connected (at least until you can push from Server back to client without polling) meh, my 2c --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net --- OzSilverlight.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
Re: [OzSilverlight] A couple of questions
I understand what code runs on the server and what runs in the browser... but in ASP.NET page login control the code is also running on the server to log the user in, so why not also add the options to create new users etc., etc. to the Authentication Application Service On Thu, Sep 18, 2008 at 2:19 PM, .net noobie [EMAIL PROTECTED] wrote: new users, create roles, change role assignment etc. they are the things I wanted to do... so really I would be better off handling all this in the ASP.NET page that is hosting my Silverlight Applications and then talking too and from the ASP.NET page with my Silverlight Application to do these things? then to stop the page reloading I would need to do these tasks new users, create roles, change role assignment etc. via something like MS AJAX...? On Thu, Sep 18, 2008 at 2:07 PM, Jonas Follesø [EMAIL PROTECTED] wrote: From a Silverlight client point of view, what else do you really need? Everything that has to do with validation, accessing user store etc. has to happen on the server and not on the client. Some thing, like Authorization (does this user belong to this role) is useful from the UI, as you can enable/disable certain buttons and functionality. But in the end you have to redo all the validation on the server as you can't trust any input coming from the client. The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. You got functionality to create new users, create roles, change role assignment etc. To do those things from a Silverlight client you would have to expose (and secure) the individual pieces your self. On Thu, Sep 18, 2008 at 2:00 PM, .net noobie [EMAIL PROTECTED]wrote: Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard browser networking stack, so you will have access to session state, cookies and all the other goodies you expect. To find out which user is logged in you can use the ASP.NETAuthentication Application Service, which can be exposed via WCF quite easily (then you can log in and check login status etc from Silverlight). 4 is a little more tricky, but basically you could hook up events to AJAX changes in the page then fire through pieces of information to Silverlight using the HTML JavaScript bridge... It's quite easy to do, have a Google around. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Ross
Re: [OzSilverlight] A couple of questions
Well, you can actually do all this from a Silverlight application. And anything you could do from MS AJAX, you could do from Silverlight. And to be fair the Client Application Services (for Windows Forms/WPF) comes with classes that abstract away the service interaction, and actually gives you a client side Membership- and Role Provider. But under the hood it's all HTTP JSON calls (I assume for performance reasons, as their API only has synchronous methods for accessing the Membership- and Role Provider). Check this post: http://blogs.msdn.com/brada/archive/2007/05/23/net-client-application-services.aspx for more information on what you can do. The service-end point used by the Client Application Services client libraries are: http://localhost/myservice/Profile_JSON_AppService.axd http://localhost/myservice/Authentication_JSON_AppService.axd http://localhost/myservice/Role_JSON_AppService.axd You don't get WSDL for these services, but you can invoke them as REST services and do things like create user, create role etc. given that the currently authenticated user have the permissions needed. On Thu, Sep 18, 2008 at 2:19 PM, .net noobie [EMAIL PROTECTED] wrote: new users, create roles, change role assignment etc. they are the things I wanted to do... so really I would be better off handling all this in the ASP.NET page that is hosting my Silverlight Applications and then talking too and from the ASP.NET page with my Silverlight Application to do these things? then to stop the page reloading I would need to do these tasks new users, create roles, change role assignment etc. via something like MS AJAX...? On Thu, Sep 18, 2008 at 2:07 PM, Jonas Follesø [EMAIL PROTECTED] wrote: From a Silverlight client point of view, what else do you really need? Everything that has to do with validation, accessing user store etc. has to happen on the server and not on the client. Some thing, like Authorization (does this user belong to this role) is useful from the UI, as you can enable/disable certain buttons and functionality. But in the end you have to redo all the validation on the server as you can't trust any input coming from the client. The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. You got functionality to create new users, create roles, change role assignment etc. To do those things from a Silverlight client you would have to expose (and secure) the individual pieces your self. On Thu, Sep 18, 2008 at 2:00 PM, .net noobie [EMAIL PROTECTED]wrote: Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication and/or ASP.NET membership - i.e. use the normal stuff J. Whenever Silverlight accesses the server, it uses the standard
Re: [OzSilverlight] A couple of questions
ok cool, thanks On Thu, Sep 18, 2008 at 2:31 PM, Jonas Follesø [EMAIL PROTECTED] wrote: Well, you can actually do all this from a Silverlight application. And anything you could do from MS AJAX, you could do from Silverlight. And to be fair the Client Application Services (for Windows Forms/WPF) comes with classes that abstract away the service interaction, and actually gives you a client side Membership- and Role Provider. But under the hood it's all HTTP JSON calls (I assume for performance reasons, as their API only has synchronous methods for accessing the Membership- and Role Provider). Check this post: http://blogs.msdn.com/brada/archive/2007/05/23/net-client-application-services.aspx for more information on what you can do. The service-end point used by the Client Application Services client libraries are: http://localhost/myservice/Profile_JSON_AppService.axd http://localhost/myservice/Authentication_JSON_AppService.axd http://localhost/myservice/Role_JSON_AppService.axd You don't get WSDL for these services, but you can invoke them as REST services and do things like create user, create role etc. given that the currently authenticated user have the permissions needed. On Thu, Sep 18, 2008 at 2:19 PM, .net noobie [EMAIL PROTECTED]wrote: new users, create roles, change role assignment etc. they are the things I wanted to do... so really I would be better off handling all this in the ASP.NET page that is hosting my Silverlight Applications and then talking too and from the ASP.NET page with my Silverlight Application to do these things? then to stop the page reloading I would need to do these tasks new users, create roles, change role assignment etc. via something like MS AJAX...? On Thu, Sep 18, 2008 at 2:07 PM, Jonas Follesø [EMAIL PROTECTED] wrote: From a Silverlight client point of view, what else do you really need? Everything that has to do with validation, accessing user store etc. has to happen on the server and not on the client. Some thing, like Authorization (does this user belong to this role) is useful from the UI, as you can enable/disable certain buttons and functionality. But in the end you have to redo all the validation on the server as you can't trust any input coming from the client. The reason you got allot more functionality in ASP.NET is because you're running on the server, and that is a whole different ball game. You got functionality to create new users, create roles, change role assignment etc. To do those things from a Silverlight client you would have to expose (and secure) the individual pieces your self. On Thu, Sep 18, 2008 at 2:00 PM, .net noobie [EMAIL PROTECTED]wrote: Authentication Application Service, via WCF is a very limited set of functionality compared to what you have in a ASP.NET page, you can do a few things like Login, Logout and one to two there things right..? when I was checking it out I ended up making a normal WCF service for my Silverlight application, then adding the membership to it via just wrapping the methods of the Membership class I wanted, but it also had a few issues doing it that way to, but I got all the parts of Membership I wanted to use...? is this a bad way to go about it in the future? please note it was just a learning application for myself, so I was not really worried about any security issues passing the data back and forth at the time On Thu, Sep 18, 2008 at 12:51 PM, Ross McKinnon [EMAIL PROTECTED] wrote: Thanks to both of you. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:44 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions You where slowed down by all the extra detail J Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jonas Follesø *Sent:* Thursday, 18 September 2008 12:42 PM *To:* listserver@ozsilverlight.com *Subject:* Re: [OzSilverlight] A couple of questions Haha - looks like you beat me too by 5 min Jordan ;) On Thu, Sep 18, 2008 at 12:38 PM, Jordan Knight [EMAIL PROTECTED] wrote: Sorry Ross J - not Michael. Regards, *Jordan Knight* Readify - Senior Developer Suite 206 Nolan Tower | 29 Rakaia Way | Docklands | VIC 3008 | Australia M: +61 403 532 404 | E: [EMAIL PROTECTED] | W: www.readify.net *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Jordan Knight *Sent:* Thursday, 18 September 2008 12:35 PM *To:* listserver@ozSilverlight.com *Subject:* RE: [OzSilverlight] A couple of questions Hi Michael, I can answer 1 and 3 for you (and maybe a bit of 4): The short answer is Forms Authentication
