Using which of these is the best approach while planning Silverlight application? UserControls or Page.
My understanding is that when you have to encapsulate some of the logic of some component, which is truly generic and reusable then use usercontrol else use Page because Page is tightly integrated with browser's history etc, so you can move back and forth and can make use of NavigationService to navigate across pages because if you keep using usercontrols, it is very tiresome to navigate all the way to the required page. Thus we cannot bookmark it because it serves no purpose. We will have to again find our way through the menus in application to reach our desired location.
Is my understanding correct?
Your understanding is correct. Use Pages to integrate with the Navigation framework and the main pages and controls for custom components etc.
Related
I want to create a kiosk mode application using WPF. I want to use a single window because the user should not be able to exit this fullscreen application.
The application should guide the user trough a process. When the user proceeds trough the process, the screen should constantly change and show him the next step.
Usually I just create a single window and use a "state machine" to switch UserControls containing the information for the current step. Is there a better way to achieve this functionality? Maybe I would get a better result using multiple windows or Pages (never used them).
The reason why I am asking is that in future I want to have a simple, clean way of switching the content inside a single window. i.e. I am planning to implement some sort of animation when switching content (like sliding to the next / previous step). I don't want to put more effort into my current approach if it isn't the most flexible and clean one.
Any ideas?
PS: This is about desktop applications. Today I come from the Winforms environment and am experimenting with WPF.
There's a few ways you can achieve this.
First would be to use a Page based application, this will allow you to use a single window. Here is a pretty interesting tutorial
A bonus of using this approach is that navigation between pages is built in.
Your requirements are that you need to use animation for transitioning between pages, as far as I'm aware, using a Page based application cannot achieve this (I may be wrong). So your other option would be to use a UserControl MVVM approach.
This probably won't make a lot of sense now, but here goes:
You can use a single master view model which will hold multiple child view models, each of these could have a visibility property which dictates the visibility of the associated view. The master view model would simply be responsible for displaying the appropriate view model depending on where the user currently is in the application.
Using some clever XAML, you can create storyboards (animations) when the view becomes visible, which will allow you to achieve the crazy awesome animations that you require.
Anyway, that probably didn't make any sense, so here's a tutorial to get you started with MVVM.
I am trying to determine the best way to do this.
Basically, I have a child app that runs inside of a parent app in IIS. I want to be able to run this app inside of the parent app (using the same layout and functionality)
What is my my best bet for doing this? Running the app in an iFrame? Loading the app through jQuery into a div? Or should I create a web service that sends the parent app's layout to the child app?
Any guidance is appreciated.
What you are talking about here is composition. There are a whole bunch of different composition patterns you can apply which will each have pros and cons. Stack overflow isnt really a great place to get an answer on what the 'best' pattern to use is but here are a few I can think of:
Server side composition patterns
Shared Layout file with MVC
This method uses a layout file from a DLL shared by both sites to render all pages
Its pretty easy to implement but means you need to release both sites when the file changes
This encourages strong coupling between the sites (which is bad)
Sub request based rendering
Only have a parent site on the internet, at run time request blocks of content from an internal url for the child site
Loose coupling in terms of content but strong coupling in terms of urls
many child sites can be pulled in and are not coupled to each other
parent/child sites can be released independently
Client side composition
IFrames
really lo-fi, so easy to implement
has a bunch of really aweful stuff to deal with in terms of css and javascript between the frame and parent
Generally considered by devs as a bad idea (opinion)
Coupling only by URLs, sites can be released independantly
Ajax in content
Do an ajax request for components from other sites as the page loads
Increases page load times and gives ui flicker as bits load in
Pretty easy to implement and manage
Coupling only by URLs, sites can be released independantly
You could either use Area on your app, iFrame, or simply open a new browser tab for your child app.
If you want to include your project in a dll, you could compile all the views into a dll and reference it with your parent app, this web site explains how this can be done.
I would recommend you to use the way to make empty layout of your child application and render it to the div of your parent application with JQuery. IFrame should stay in the past.
I would like to know the difference between page, frame, navigation windows in c# wpf
what is the best choice of them for wpf windows application?
in my application how to make fixed part (contain main buttons) and changeable part (show pages) after clicking buttons in fixed part
are there any good websites provides video tutorials for c# wpf from beginning to professional?
thank you
A Page is much like a user control, only that is is displayed within a Frame, which again is part of a NavigationWindow. A NavigationWindow is a special kind of window that allows for page navigation and can display the respective controls for navigating pages.
A paged application is a good choice if you want Wizard-like functionality, or if the user experience should be comparable to what you get when browsing the web. In many cases, using standard WPF windows is a better choice.
The NavigationWindow already contains a "fixed part" that can contain controls. You can also use a normal window, place a Frame in it and then - through proper layout - create your own "fixed parts". Navigation would then come down to calling the navigation methods the Frame provides.
From the answer to this question:
Pages are intended for use in navigation applications (usually with back and forward buttons, e.g. Internet Explorer). Pages must be hosted in a NavigationWindow or a Frame
The best choice depends on what kind of application you want to create. Is it a wizard or navigation type application or just a regular application with one window (maybe with tabs)?
I would definitely consider using a MVVM framework like Caliburn.Micro for making a WPF application. It has some really powerful mechanisms for dealing with Screens, Conductors and Composition, in addition to encouraging you to decouple your application by using the MVVM pattern. The author of Caliburn.Micro, Rob Eisenberg, has written some tutorials with extensive explanation about and how to use the framework under the project's documentation. There is also lots of resources around the interwebz, google it! :)
I can also recommend Pluralsight's WPF and XAML Fundamentals and WPF Advanced Topics, they should cover what whatever is worth knowing about WPF :)
I have created certain functionalities for an application. These functionalities include -
ADD USER
EDIT USER
DELETE USER and so on
Now I have written all these in seperate pages. So when I have to delete a user I go to USER_DELETE.aspx page to do that.
My new requirement is that there should be a single page from which all these can be done. Being more specific, I want that there should be separate panels in a page called "USER_MANAGER". Each panel will have the required functionality.
Is there a way I can do this by just creating the new UI of the USER_MANAGER page and calling the other pages (as User Controls or any other easier way) into the UI of USER_MANAGER?
I don't want to do any changes to the existing pages for various functions. I hope the question is clear, I am a bit novice in this technology so I am not really sure.
Thanks and regards
It sounds like you want to turn your pages in to ASP.NET User Controls. User Controls are just as easy to create as pages and can be used in similar fashion as Server Controls. If you want to create controls that can be shared between projects, then you want to write Server Controls but thos cases are probably not so common.
There are many ways to tackle this problem. If you are listing the users in a gridview you could use inline editing and do it within there.
You could retain the pages you wrote and use a modal popup or iframe. Another way would be with a multiview or tabs or panels.
I would design the UI and the then decide what the best solution for your application is then write these elements.
If this is too hypothetical and needs to be somewhere else, please let me know.
I have a project that needs specific gridviews to appear on multiple pages. Instead of copying and pasting the gridviews on each of the pages I thought creating a user control for each specific gridview or create a page for each gridview and then use iframes would be my best options.
I have not used either extensively so I am looking to the SO community's experience, are there known problems with using user controls and/or iframes when it comes to:
validation
communication between user control/iframe and parent page
ajax/updatepanels containing user control/iframe
thanks in advance
Since a gridview is essentially a user control (that's very flexible), I would first explore doing this with neither of your options. If possible, use the standard gridview and let your data layer do most the work. However, assuming you already know that... but your requirements require one or the other of your options, here are things to consider.
An iframe is easy to implement but unless your need is really simplistic in terms of user interaction, the user control will be the most flexible. Another downside to an iframe is it's size (you're essentially loading two pages). The downside of user controls are the upfront time in building them.
Based on your criterion:
1. validation - can do with either option but you'll have more flexibility with a user control
2. communication between user control/iframe and parent page - much easier with user control unless query string parms will do the trick
3. ajax/updatepanels containing user control/iframe - again user control