In our project we have to define 15 screens for CRUD operations on core tables.
I want to define 1 screen with a list, navigation and UI markup just once, and want to re-use these screen for every CRUD table.
What is the best approach to achieve this?
I tried inheritance, but caught up with XAML that doesn't allow inheritance (I checked several approaches on the internet/blogs, but couldn't get a good result).
The best way to cope with this is to use Styles, UserControls and possibly Templates to maximize re-use.
The only way to prevent having to define all those UI's is by generating them (design-time or run-time).
Lightswitch is a generator that can do (could have done) this for you.
You can also create your own UI Framework which creates the UI based on meta data but that might be too costly.
Related
Is it common practice in WPF to create custom controls and use them as page components and directives, similar to how it's done in Angular?
Angular example:
<custom:control></custom:control>
<custom:super-bindable-view prop1="{}" prop2={}></custom:super-bindable-view>
It is a common practice, but doing so depends on the situation.
Creating sub-controls, either customs controls or user controls, can help to simplify your XAML. It separates the logic for that component so that your view model doesn't have to get unnecessarily bloated. The downside is that you do create extra binding logic by way of dependency properties and it can obfuscate what your view is supposed to be doing.
The main deciding factor is around reusability. If you want to use the same control in multiple places, then it's probably a good idea. Otherwise you need to ask whether or not pulling out a separate control will make your code easier to understand and maintain.
Recently, in working with AngularJS, I really like many of the features, like creating custom abstract data factories, etc.
KendoUI also has similar features like MVVM, SPA routes, etc. that AngularJS offers, so I'm curious about what the benefits are of mixing the two (other than the rich UI features of KendoUI)?
-- Update --
I'm asking this question for clarification, and for those who may be slightly confused about the benefits of each, and why one would use both in a project, rather than one over the other.
For example - Javascript unit testing capabilities (simply done with Angular controllers, but have not seen anyone doing this with KendoUI).
It seems like Kendo is trying to do it all, but does UI best.
Thanks.
-- Update --
Since writing this question I have gone through and integrated the KendoUI grid with Angular using OData and have written a tutorial here at www.whatsinyourlunch.com on how to accomplish this, in hopes that this will be useful for others.
The stack is AngularJS, KendoUI, OData, WebAPI2, .Net MVC5, C#, Entity Framework accessed through a generic repository.
I know this is old but here is my two cents. The more you use Angular the more you will realize you don't need Kendo. The Kendo/Angular integration is a bit of a hack but it seems to get the job done. The only reason I find to use Kendo is the grid. I've tried the Angular grids out there and they are riddled with bugs and formatting issues.
I think it's important not to be a purist and to just use whatever combination of tools that accomplish what you need. I tend to try to move away from being dependent on paid commercial libraries but the grid is just solid. Any paid product will probably have more support and upkeep, as well as personal access to the development team (vs. well maintained free products from large companies or single developer projects that waste away). I have seen so many great free products get abandoned. However, if you want a great free grid and can't stomach paying Telerik $1000.00 for just a grid, DataTables.net is a great alternative and what I currently use.
You have to love Telerik's support which is the best reason to use their stuff in my opinion. They are lacking some things in Kendo like a good date range calendar, tag cloud, etc. The charts are also lacking compared to say Highcharts. I use the date range calendar from Keith Wood, although he doesn't seem to respond to emails. I found some great angular controls for other things like drop downs, etc. as well. I used to not understand why people use a hodge podge of stuff, but it is the best tool for the job that is important.
I personally would not go any further than using the rich UI features of KendoUI in Angular directives. The rest should be Angular. Or use KendoUI exclusively.
Mixing them works fine. You don't have to use all of the framework code (MVVM, etc.) included with Kendo and can just focus on the rich UI features. We use several of their controls, including a highly customized version of the grid. Angular is perfect for this because we built directives to wrap the Kendo controls and encapsulate the 80% configuration that happens every time so the developer could focus on the 20% that is different in their page/module/whatever. Our project successfully engages over 20 developers in a distributed team on a project with tens of thousands of lines of code and we've had great success using the UI features of Kendo with Angular.
On our current project we're using both Angular and Kendo (mainly for the grid). We didn't mix the two and this would also be my suggestion. Angular should be the one responsible for your application logic and Kendo should only be concerned with managing the widgets.
Kendo provides there own kendo-angular library, which contains directives for most of their widgets.
Here are a couple of points of my experience which doesn't favor the mixing of KendoUI with AngularJs:
Though there are kendo directives for AngularJs, a lot of UI related stuff will end up in the controller (configuration, events, complex templates) and it's difficult to keep jQuery out of it.
The initialization and display of kendo components does add a serious time penalty to each page (grid, tabstrip, ...)
Events and method arguments are not coherent across the kendo framework (i.e. select method of grid vs listview vs combobox)
The use of templates with the grid (or listview) or responding to grid events does not feel like AngularJs.
Components behave differently than the native controls they try to replace (i.e. event order and databinding of combobox vs native select)
As soon as the look and feel of the kendo components has to be customized, one has to become familiar with the CSS classes used by kendo.
The KendoUI grid is great, but if the project doesn't need it, there's nothing to be gained by mixing the two.
I think mixing of them is not a good approach. you should ask yourself a question "witch one is more required and useful in my project"
I had decided to use kendo beside angular because of its rich grid components. But I canceled it.
The main controls of kendoUI is grid. But you need to watch every element of it to have a complete binding and it make it slow. Also dataItem of a row in grid does not return the original data.
you need to watch paging, filtering , sorting ....
But for other controls of kendo we have fewer problems.
I am building a rather large WP7 application and having a lot of fun with it. It is Pivot based and has quite a lot of pivot pages. I dynamically add and remove pivot pages based on what "mode" of the application the user has selected to keep the application look and feel as simple as possible. All is going quite well so far my app is fast responsive, not a memory or resource hog and performs background loading on demand when needed.
The Model layer contains all my business logic that represents what the application is all about. It is clean and separate from the the view-model and view layers.
The View-Model layer is an abstraction of the model to the extent that it needs to interact with the view and also contains the session-ness and workflow aspects of the application in general. It contains objects which represent the Model in a way the View needs to interact with. The view model persists the state of the application in isolated storage and supports tomb-stoning.
The View layer contains a lot of elements pivots, user controls, styles, resources etc in both xaml and the corresponding code behind. I do like Blend and the Xaml designer within visual studio 2010 however I find myself still coding/configuring the view objects within the code behind due to the nature in which they interact with each other. The code behind of the view objects is becoming quite large but still only reflects the state of the view and not the state of the application. I have made use of user controls quite a lot as this lets me build reusable components across many pivot pages however the user controls are not Blend friendly. What I am worried about is that my view might becoming more complex than it needs to be and losing the ability to coordinate the user interface design with tools like expression blend.
By customising the view this way and making use of reusable controls I have reduced my Xaml considerably and don't suffer from bloated Xaml files that other developers have mentioned but lost ability to co-ordinate with Blend. Is there are happy medium to be found? Should I be looking at designing custom controls?
[Edit]
Thanks for your reply. I think it boils down to either a lot of Xaml with a designer or break it down into user controls with more code behind. Since I moved into user controls my mindset has moved back to doing things by hand rather than with a designer (better the devil you know right!). My thoughts are should I make my user controls into skin-able custom controls or just keep going how I am and avoid using the designer. Its a bit of potato-potardo but I don't want to get into bad habits.
Custom Controls (or Templated Controls) are not directly related to your question as far as I can see. Custom controls are just controls that add new properties, events and methods to an existing control and are still capable of being 'templated' by a designer.
Creating UI in code does make it harder to design the application using Blend (and even the VS designer) because the only way to see the interface is by running the application.
A lot of the logic that creates the UI could possibly be replaced by using the Visual State Manager. Use states of the controls to design them for specific modes of the view. Only when you need extra/new states you will have to create a Custom Control.
As your question is a bit wide, feel free to add comments or extend your question so I can add more details or remove this answer when it is utter nonsense :)
I have a UI with some controls, then in the middle I have 6 overlapping grids. I am using these grids as 'pages' and as the user navigates through the 'pages' I cycle through using Visible.Hidden and Visible.Visible to show the correct 'page'.
I noticed while developing as I was adding more grids the application started to slow down (a lot). It wasn't really a problem until I added 6 more images to the last page. Since, the application is very slow even on my (faster than average) PC.
Do you have any advice on how I can still achieve the same look and feel but use a more efficient method?
Thanks in advance.
All in all it's not a good idea to have a bunch of overlapping controls like you have, because as you noticed, there are performance problems. You want to minimize the number of controls which are present in your application at any one time.
If you have a limited number of pages, use TabControl.
If you have a large or dynamic number of pages, consider Frames and Pages.
A third option is to have a hosting "shell" control with a ContentPresenter. Then whenever you want to navigate to a different page, just set the control's Content to a new instance of your page view.
Your views are separate from your data models, right? If not, consider using the MVVM pattern. This will allow you to have persistent data regardless of which view is showing (e.g. dynamically creating and destroying views won't mess up your data).
I suggest that you use the WPF Frame and Page classes instead of your current architecture. As with any presentation framework, performance degrades as you add more controls to your scene graph.
TabControl with a custom template?
I'm writing a fairly big interface using Silverlight. As I progress, the xaml file is getting fairly big and is becoming proportionally uglier.
Questions
Are there any resources out there to make the xaml more readable? For example, how would I display the order of attributes (e.g. height and Width first) so that it looks the most tidy?
Another issue is that there are multiple ways to implement an interface with grids and stack panels. Is there a preferred approach when using one or the other?
I am looking for advice and links to other resources that can be used as examples.
If you have lots of complex XAML, you could try to break it down into several UserControls to make it more modular and have less XAML in each file.
Here is a tutorial
http://silverlight.net/learn/tutorials/usercontrols.aspx
And here is a video
http://silverlight.net/learn/learnvideo.aspx?video=52036
This may be the same as the XAML best practices question, where the recommendation was to take a look at http://dotnet.org.za/rudi/archive/2009/01/13/xaml-guidelines-released.aspx
SilverLight like any other UI language has the size complexity problem
Much has been written about this problem in the HTML world, and the same rules apply
Use a testable pattern like MVP, MVC etc - There are test frameowrks for SilverLight
Keeping resource in separate files - A page layout should just be layout. Style, themes etc are shared resources in general
Use custom controls - try to avoid using the generic built in controls as they come, wrap them up in a custom control with all your default properties and handlers etc. When you then use this control on a page layout there is less attribute baggage to go with it
I prefer stackpanels over grids for their simplicity - It's a bit like the HTML worlds table vs .css layouts war
Have a look at other peoples SilverLight efforts with SilverLight Spy, and you might feel better about your own :-)
Check out the series on best practices for Silverlight on:
Silverlight 2 Best Practices - 4 articles
The author has 4 articles on this.