I am building a Silverlight 3.0 app based on the Silverlight Navigation Application template. One road block I ran into is communicating between the Pages. For instance, I am in one Page, and I want to kick off another page and send it some data. I am at a loss as to how to do this.
Any ideas?
You have 2 options
Use Publish/Subscribe pattern, i havent used this before, but it is useful in certain cases, i dont think it would solve ur problem though.
Use Request parameters, basically when you navigate to the new view, call it like so
NavigationService.Navigate(new Uri("/HomePage.xaml?HomePageId=12", UriKind.Relative));
You could slap some string.format in there to make it neater, but you get the idea, then on the new View, use string queryParam = HtmlPage.Document.QueryString["HomePageId"]; on page load to get the Id of the information you wish to display.
That should do it.
I've found an effective solution that does not involve too much complexity. I am using the LocalMessageSender and LocalMessageReceiver objects. The original purpose of these objects are to have 2 silverlight apps on the same web page talk to each, but it's just as good at having 2 views talk to each other.
The usage is really straight-forward. See this example for usage.
Jesse Liberty has an excellent blog post about just this. I use the techniques described there myself in a multi page Silverlight application.
I'm not sure though whether you can apply this with the Silverlight Navigation Application template.
Related
How do I get Web API to render a Razor view using the model that it returns? And only XML/JSON when the accept headers (or .extension) is set? Is this even possible?
It seems crazy to require one set of controllers for rendering HTML and another for JSON/XML if they're working on the same models.
Update Darrel Miller has already written a ViewEngineFormatter for Razor which might do the trick, though haven't tried it yet.
I asked a similar question about this in the past on StackOverflow, because I wanted to do the same thing. However, I eventually ended up with an "Api" area and set of controllers, and a standard set of MVC controllers for the website.
In hindsight this actually wasn't a bad thing. I've found I tend to do different things in each set of controllers anyway. My views aren't just CRUD but tend to contain extra contextual data, so returning view models specific to that page is nice.
I think if I had stuck to my goal of combining the two I might have ended up with either over-complicated controllers or a user experience that wasn't as optimal as it could have been. So while this isn't a direct answer to your question, in my experience not being able to do this might not be such a bad thing.
Instead I've ended up with a rich set of builders and commands that most of my controllers delegate to. That way I can reuse most of the controller logic while being able to do specific things for API versus the web:
http://www.paulstovell.com/clean-aspnet-mvc-controllers
Yes, it is how it is designed for: Web API for data and MVC for rendered views. I know that some people will try adding view engine support to web API but it is not designed for it.
My personal view on this is that this parallel world between MVC and Web API (which is the source of most criticisms while community has generally praised the product) is mainly a consequence of the fact that Web API has been added to MVC without having a reference (or knowledge of it).
As Jon Galloway said on a recent podcast, had the team have HTTP knowledge they have now (as well as hindesight of the popularity of REST API now which they did not have then), they would have designed just a single pipeline serving data and rendered view alike.
I can only speculate that the future version of MVC/Web API will be presented as a single pipeline. In fact, this parallel world might have been a careful plan to unify them in the near future.
It seems crazy to require one set of controllers for rendering HTML
and another for JSON/XML if they're working on the same models.
AFAIK, that's how it is. Standard controllers should be used for rendering HTML and ApiControllers for JSON/XML.
It seems crazy to require one set of controllers for rendering HTML
and another for JSON/XML if they're working on the same models.
Web API is exactly what it is called - a technology for creating API's.
If you are creating an ASP.NET MVC application and want to return some JSON for your own purpose then you don't need content negotiation etc. therefore you don't need Web API (just use plain old good JsonResult).
If you want to create a reusable API than Web API is what you need but your client application should consume it in the same way as everybody else.
Web API isn't meant to be a "hammer" for "nailing" all non-HTML requests - use it when you need it.
I am looking for something similar to this, but not entirely. Through scouring the web, I found a couple posts by Fredrik Normen. He writes about this exact problem space and actually identifies a third-party solution in the second post listed. Basically, the solution involves creating a custom MediaTypeFormatter that knows how to handle views using the Razor engine provided by Microsoft (through the use of a third-party library).
Using Razor engine together with Asp.Net Web API to create a
Hypermedia API
Using Razor together with ASP.NET Web API
ASP.Net Web API and using Razor the next step
Hopefully Microsoft will implement something soon in Web API as Hypermedia seems to be gaining traction.
Hope this helps!
My group is working on a new web application and is considering using MVC. However, there are members who would rather include pages than use master pages. Is this possible to do in ASP.NET MVC? In the small amount of time that I've poked around with MVC I have not yet been able to figure out how one might accomplish that.
Why the preference?
Having used both in the past, Master Pages are much easier to use. You just have to get over the (very small) learning curve.
ASP.NET MVC doesn't force you to do either one though...
If you like the Include method, then you would probably feel most comfortable using Partial Views to provide the same functionality. You would just add the Partial Views to each page instead of including another page.
No. It does not force you in any way.
You should really avoid server-side includes with anything newer than classic ASP. They're more difficult to debug, IIS has a hard time finding correct line numbers when there's a problem, etc. Also, I haven't looked at the order in which SSIs are processed in the request pipeline - they may not work at all with ASP.NET.
If you're moving into MVC, use RenderPartial() or RenderAction() instead. These perform essentially the same function as a server-side include, but are more inline with the spirit of the framework and provide some additional benefits, like passing models without having to declare a global variable (which should also be avoided, and I'm not sure if it is even possible under .NET scope rules).
And, no, master pages are not required, but you really should use them. Using includes to build your page layout works, but only if you don't and won't need to radically change the layout of your site at any point in the future. I'm in that boat now with a 350k line classic ASP app which used very nicely structured code and #includes to create the page layout. That was the best solution available at the time, but it's causing me a lot of headaches now (10+ years later).
With a master page you can move your ContentPlaceHolder blocks anywhere you want, whereas with #includes the final page really determines the format by the order in which the includes are placed. This also makes it pretty straightforward to create a mobile version of your site - you can create a mobile-specific master page and use the same content views.
Its a matter of choice,but for consistent look and feel across the web application, master pages give you just that. You have to take the team through the learning curve of good master page design, not only would it be useful for the current project at hand but also future projects. Good luck!
I would rather opt to go for Master pages due to the ease of use and built in support in MVC for this.
If you want to know more about it check out this tutorial: Creating Page Layouts with View Master Pages.
Grz, Kris.
Its time to rebuild my portfolio site, and I am thinking of either using Silverlight (still have to learn the basics but would be fun) or use MVC.NET.
I would like to use Silverlight since its something I am really interested in learning, and building up a small portfolio site should not be an out of this world task. However I do not know if its advisable, since I want my portfolio to be viewed and accessed by everyone, platform independent.
What do you guys think?
Thanks
From an SEO and ease of page bookmarking point of view you might want to go with traditional HTML, i.e. ASP.NET MVC.
The downside of building an entire site in Flash or Silverlight is that users can't bookmark a specific page within it, and search engine bots can't by default follow links or parse the text.
The following page deals with SEO and Silverlight sites.
http://silverlight.net/learn/whitepapers/seo-for-silverlight/
If really want platform independence you should avoid Silverlight, users on Linux especially won't get a good experience at the moment.
However if you want reasonable access by people in general then Silverlight is do-able.
You might ask yourself whether coupling your important portfolio site with your own personal improvement plan is a good idea.
Utlimately then develop your site with ASP.NET-MVC then spend some time with Silverlight without impacting your site, or perhaps include some content via Silverlight.
You can build both of them. It will allow you to see the differences between them and compare them.
I think your portfolio site should show your works also with its structure. If you are doing design, It would be nicer to make your site with Silverlight!
Those are actually not two techonologies that are related in any way or say that you should use one over another. You can have a ASP.NET MVC site (which I prefer and suggest to you) and then use Silverlight parts in it.
I prefer using Silverlight (or Flash for the same matter) only for animations, maybe parts of a website but not for entire website. If only portfolio will be built in Silverlight you should definitely do it in classic HTML too for users that lack Silverlight support.
May be it's too late about answering.
Now, Silverlight seems to go to its end. Microsoft wants to stop supporting it after 2021.
But, since Microsoft says they will ever support OOB mode, I think you could continue to developp to Silverlight today.
So I think, it's up not for animations. It's up to users of the application :
Silverlight has some good avaibilities to simulate windows like application.
After loading data in cache, you can have better user reactivity.
And, you get an other good point : user can easily cancel data they write.
At the end, with RIA services technology, for developpers, this is pretty easy to simulate entities like in client development.
As it says before, you can have mvc web application with silverlight inside.
What is the best and cleanest way to implement A-B testing in asp.net mvc? That is, when we make new changes to an asp.net mvc web site, we want to test the new html/css/js with a certain subset of visitors (defined on cookie, login id, etc) and then analyze some metrics (page response time, number of pages visited, $$$ in sales, etc) afterwards to measure the level of success of the changes.
I am looking for a clean way to implement a way of choosing what view (html/css/js, etc...) to render using asp.net mvc.
Check out FairlyCertain (http://www.fairtutor.com/fairlycertain/) when you get a chance. It's a .NET A/B library that you can pretty much just drop into your project and start writing tests.
Unlike the Javascript libraries from Google and VisualWebsiteOptimizer, everything happens on the server so you don't suffer any performance, user experience or SEO issues. I've been using it in my stuff for a while now and it works quite well.
There is an A/B testing framework specifically for ASP.NET MVC. This is an open source software I wrote myself when, just like you, didn't find a free tool which works nicely with ASP.NET MVC and doesn't require much setup.
Google Content Experiments? It's a Javascript-based solution that doesn't require anything from your backend.
You include Google's Javascript on your page
The script randomly substitutes elements on your page as defined by your A/B test
Google's site shows you a nice breakdown of the results...
If you are using the spark view engine, you could probably do it with a variation of the theme filter (http://sparkviewengine.com/documentation/viewlocations#Extendingfilepatternswithdescriptorfilters). For each new visitor to the site, determine if you want them to see the existing or new version of the site and set a cookie. Wire up a descriptor filter that looks for the presence of the cookie and modify the view location to look in the folder containing the modified views. If an alternative view exists, the Spark engine will automatically render it in place of the "normal" view, otherwise it will render the normal view.
If you are using the normal WFVE, then the simplest way to manage this would be to define a folder under Views where your view alternatives live. When you want to provide an alternative view, you place it in a location that matches its position within the normal Views folder but rooted at the alternatives folder e.g. to provide an alternative to Views/Users/login.aspx place your new view at Views/Alternative/Users/login.aspx.
With a convention in place for locating your alternative views, you can extend the WebFormViewEngine and overload CreatePartialView / CreateView to inspect some aspect of the ControllerContext to determine whether to render the default or overloaded view and alter the path as appropriate e.g. changing .../Views/Users/login.aspx to .../Views/Alternative/Users/login.aspx.
I suggest you use Display Modes to achieve A/B testing.
But Display Modes just support simple problems by default.
If you already implement Display Modes in some other scenario. You can consider DisplayModeMatrix (just google it). It helps you use Display Modes more efficiency.
https://www.nuget.org/packages/DisplayModeMatrix/
Wth Display Modes you can simply delete/rename views after A/B testing to clean up your project.
I think there isn't a ready to use solution for this and you will have to improvise.
Try to override your current functionality in well defined points without breaking it. Explicitly draw a border where your regular code and A-B testing code lives.
Inversion of control principle might help a lot here too (i.e. - controller factory could provide derived controller instead of original one). For views&partialviews - you could change viewengine so it would try to look for 'MyPartialViewAB.ascx' instead of 'MyPartialView.ascx'.
And it might be a good idea to take a look what performance counters are (in case you haven't).
It seems to me that, for structured development with both depth and breadth of capability, ASP.NET MVC and Silverlight have the potential to make a nice powerful framework with superior UI granularity and reduced AJAX exposure. Have any of you tried building such a stack with future durability in mind?
ASP.NET MVC and silverlight?
In some ways, it is an either-or choice - your data is displayed either in html/css/js generated by ASP.NET, or in Silverlight. Why mix them? I'm sure that ASP.NET MVC is a good way to deliver Silverlight, but that doesn't necessarily make it part of the same UI.
It's generally about reach vs. richness. A web UI with no Silverlight or Flash can reach more users, but one with Silverlight can have a richer UI. Silverlight is good fun to code in, and I have seen some wonderful apps using Silverlight's streaming video features, but if e.g. you are doing data entry and display, and you don't need the richness of Silverlight, then why not keep the reach and stay in Asp.Net?
If you are going to do the UI in silverlight it makes sense to do all of it in Silverlight. I have had good experiences with all the ViewModel-view-controller page flow happening inside the Silverlight app, rather than transitioning to another html page and loading a different silverlight app. It's faster and you can do fancy transition or fade-in effects in Silverlight's XAML markup.
Why is "reduced AJAX exposure" a desirable goal? Sites like e.g. Stackoverflow here use AJAX techniques to very good effect.
Stephen Walther's talk at MIX09 shows four pillars of ASP.Net as it currently stands - Forms, MVC, AJAX and Dynamic data. A lot of people are Seeing it as "moving from forms to MVC" but there are other approaches also being developed in the mix.
I've built a little test app with SL and MVC. It didn't work that well but I don't think I was doing right. I've tried using SL in views but its slow to switch pages since its loading new SL instances all the time. I've tried a single SL app which meant it contained all the control code as well but that relegates the server to data access which only needs some WCF/Web service code no need for MVC there.
It may work better if we dispense with the idea of there being many view pages. In my next iteration I shall be using controllers to respond with XML or JSON directly to requests from a Silverlight app which contains the views. However this approach would still leave some questions unanswered, for example, how does the controller get to have a say in what view is actually displayed?
To be honest, I'm getting the feeling that SL to ASP.NET-MVC are yet shaping up as a good match. Some web apps may benefit from some SL elements (charting for example) yet the app remain firmly in HTML. On the other hand, an app whose UI is purely in SL (whilst internally using some similar View/Controller concept) doesn't really need MVC on the server-side.
Its early days, it will take while for us early adopters to see what really works and what doesn't. There being a beta for version 3 with more coming from MS in the way SL can access serverside data may change things further.
I asked a similar question here: Does Silverlight 3 Change the MVC vs. Silverlight question. This was in response to SL2 vs. MVC where folks all agreed that they were complimentary technologies. I'm still not convinced. My experience has been similar to AnthonyWJones. Per the previous posts, I tried to mingle them without a lot of success. Could be my own ignorance, though. Right now I'm building a Silverlight only application using SL3 beta. I seem to be a lot closer to my intended effect. That being, an application with a few database features. So it didn't make sense to build a completely stand alone app (since the data is central), but I really wanted some Silverlight goodness to render the end result and allow the user to interact.
So where in the hell am I going with all of this? Based on my experience, this still seems like a YMMV type question. It really depends on what you're trying to build. Since I'm light on database, heavy on interaction, I'm biting the bullet with Silverlight 3 and .NET RIA Services for the little database stuff. If I were writing Stackoverflow, I'd probably do ASP.NET MVC and AJAX.
We are currently using ASP.NET MVC as an alternative to WCF to expose data to Silverlight where our Silverlight app makes RESTFUL calls to urls in our Mvc application and the controller returns a JsonResult which works well for us. It's by no means necessarily the text book way but we found this way the two technologies compliment each other. Now if we ever need an HTML implementation we've already done the Model-Controller work which can be re-used.