I'm designing data-oriented application in Silverlight 3 and I'm wondering if is it worth using new DataForm control. It looks really awesome on PowerPoint slides but I have no idea how it is in real life.
I need to achieve following behaviours:
group model's fields to areas, for instance separating groups using horizontal lines or naming group of fields,
place 2 or 3 input controls in exactly one row, for example: country-dropdown, zip textbox and city textbox,
multilingual validation errors,
a few readonly fields in edit mode,
posibility to hide fields in dataforms,
displying a helper button for showing modal popup window with dictionary/grid view.
I'd like to build it using Prism and RIA services.
Has anybody any experience to share?
I have tried using the DataForm in a couple of places in my current project. Spent several days tweaking the various properties and attributes on my classes and found that it never did quite work the way I wanted it to. The demos that are on the web look great but they don't have 'real world' scenarios and are incomplete. So, I wouldn't recomend the DataForm for complex scenarios.
My favourite feature of the DataForm control is that it works "out of the box". That is, you can plug one on your user interface, bind it to your data classes, and have it working with a minimal amount of code. Of course you need to further tune both the behavior and the appearance of the form (by using attributes on the data classes and/or properties on the form control itself), but for feasibility studies or for early usage testing it is usually enough (and very useful) to have it working quickly with the default behavior.
By the way this is a good resource to get started with the DataForm: http://www.silverlightshow.net/items/Creating-Rich-Data-Forms-in-Silverlight-3-Introduction.aspx
Related
We need to get rid of DevExpress Bootstrap Controls for ASP.NET Core from project.
What would be the easiest/cheapest/feastet solution?
To simply rewrite everything with a different framework like Angular/Vue/React?
Maybe there is a known framework/method of migrating to DevExpress ASP.NET Core Controls? Or to something else?
How many controls were used from DevExpress?
If you only used a few controls, then you only need a few replacements.
I would not call purchase of some controls from DevExpress a whole "framework", but that of only purchasing some controls to use with your project.
So, does the project use 3-5 or 50 of those DevExpress controls? (by using, I mean DIFFERENT kinds of controls).
If you only used a few, say like their GridView, then you would only need to find a replacement for their gridview control, or simply use the built-in one, and fancy it up with some css, and addtional options. (I would make a user control).
So, you want to determine what the controls used did, how many different controls were used, and then find some controls that have a great look and feel that you like.
Their grid controls are VERY nice, since they have some "really" nice filter options for the header of that grid control.
So, you need to find some control replacements, but how many did the project use will quite much determine scope here.
So, in place of say their tab control, then consider using the jQuery one. As noted, I would wrap say the jQuery.UI tab control into a user control, so then you can just drag + drop in that jQuery.UI "tab" control in place of the devExpress one.
Same goes for the multi-select combo box (dropdown list).
So, either you cobbile together some replacements of your own, or you find some replacemetns, or you buy some more controls from another vendor.
The challenge and issue will of course be that each of their controls has a specific object and event model.
However, that's not really any different then say if you started used sweet-alert, and now want to replace sweet-alert say with some jQuery.UI dialogs.
I would say that the real challenge of replacing their controls is often not so much finding a replacement, but finding something that has a great look and feel. The main huge wonderful bonus of the devExpress controls tends to be their look and feel. In other words, they had someone with REALLY good taste in terms of look and feel.
I mean, for years I used the ajaxtoolkit. (free, open source). it was and still remains a fantastic set of controls. The pop dialog, the tab control, the multi-select combo box, the HTML editor?
They are all great, but their HUGE downside is not the features, but the controls from that free toolkit look like something from the 1980's!!!
The popular jQuery.UI? Same thing, the controls look ugly and something designed by a un-employed rodeo clown living in a trailer park.
There is a HUGE but BEYOND huge reason that bootstap is so popular.
Know the answer?
Why of course bootstrap is popular for ONE big HUGE massive SIMPLE reason:
Bootstrap has a fantastic look + feel. (zero other reasons for bootstrap being popular!!).
If you ever hired a graphic artist to re-work the look and feel of your web site? Guess what? Their resulting work and suggestions will look like the default of bootstrap!!!
So, someone in the print and graphic design industry or someone with VERY good talent and great taste created the bootstrap system. So, when you use bootstrap, then you get fantastic looking results, results that normally would take a full time graphic artist on your staff.
Regardless, we are wondering off topic here.
The main issue you have to determine is how many controls were used from devExpress. Most of their controls do follow a similar object model as the base controls found in asp.net webform controls.
So, for example, jQuery.UI controls has a great set of features (a great set of UI components), but they look way too dated and old fashioned.
The issue you have is not that you want to replace some of the devExpress controls you used, but how much work it would be to replace say a dev-express "gridview" with another different grid control. Every single one of those controls used will not only require you to spend HUGE amounts of time finding a replacement, but I think the LARGER issue is finding something that don't look like it was created by someone living in mom's basement, or by that drunken un-employed rodeo clown that does not belong in our industry.
your issue is not finding some replacement controls, your issue is how much code and money (time and resources) you have available to replace those controls.
You can no more change a bunch of code in c# to then using say client side JavaScript can then you take some Pascal code, and covert that code to vb.net code.
There no more a replacement for those controls from dev-express then there is deciding tomorrow to re-write some server side code in vb.net to now being client side JavaScript code.
In fact, what I am quite much telling you?
How the computer and IT industry has worked for 50+ years has NOT change one bit, and it not change one bit if you decide to rip out some existing controls and replace them with different controls.
Its possible you are asking for something you never seen, never heard of, and thus are imagining some magic wand here, but those don't exist in our industry either, do they?
As I noted, for quite some time, I used the AjaxToolKit. Turns out that jQuery.UI has near EVERY the same kind of controls available. But, the massive difference is jQuery.UI controls are client side ones, but worse yet, they don't work the same as the AjaxToolKit ones. In other words, there is a nice "tab" control in AjaxToolkit, and there is a nice tab control in jQuery.UI. So, they both are tab control, but THEY are VAST different in their operations, how you use them, how they work.
However, both the jQuery.UI and the AjaxToolkit tab control?
My gosh, do they look like crap.
At least the jQuery.UI one can be easy bootstrapped styled.
Again, note how we not really now back to a JUST having a control replacement, but one that looks VERY nice and VERY tasteful out of the box, and a control that should take zero efforts on your part to obtain that great look and feel.
Want to know what product has those great looking controls and great look and feel out of the box?
the DevExpress ones!!!
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 service that returns an observable collection of persons that will be used to display the person name in a list box in my Silverlight application.
While designing the list box, the designer used sample data. However, when the xaml reaches the developer working on the view model and the service that returns an observable collection of persons to be displayed, there are some changes that need to be done.. like remove all bindings to the sample data, plug in the observable collection persons properties.
So my questions are:-
Is there a way to do this in a way where in design mode it shows the sample data and when it runs it shows the service data?
Is there a way for it to return service data while in design mode itself?
Does the designer using Expression Blend need to know what properties of the observable collection {persons} will be bound to the list box?
I would want to do this in an MVVM friendly manner {without using MVVM Light toolkit}.
Thanks for your time...
Loads of good examples out there:
http://blogs.msdn.com/b/avip/archive/2010/12/06/the-simplest-way-to-do-design-time-viewmodels-with-mvvm-and-blend.aspx
http://karlshifflett.wordpress.com/2009/10/28/ddesigninstance-ddesigndata-in-visual-studio-2010-beta2/
It's very simple. Lots of other resources on google if you need them
Edit based on comment
2. Is there a way for it to return service data while in design mode itself?
Possibly but I've not seen it. In my mind you probably wouldn't want to do this for many reasons.
You may get a delay before your data
shows up which could get quite
frustrating if you need to make a lot
of small changes.
You have a reliance on services being
available which is going to make you
even more unproductive if they ever
go down.
You or a designer doesn't have any
control over changing what is
displayed on an ad-hoc basis. At
least using the sample data system
you can change values to test
different scenarios without having to
get services data changed.
3. Does the designer using Expression Blend need to know what properties of the observable collection {persons} will be bound to the list box?
The designer/developer workflow is a tricky one. Obviously each project will be different, but having just finished a design heavy wpf project I can tell you that our designers want as little to do with Blend as possible.
The workflow that has worked for us, is for the developers (we have a front end team that work at the view/viewmodel level and backend team that build up the model and service layer) to build up the views as best they can. That means building the layout, composing the controls, adding most of the design and hooking up the bindings. We then had a designer who had experience in using Blend (there aren't many) delve in and tweak the designs to get them exactly as they wanted.
This way they had very little to do with the main brunt of the work and we could keep clean and organised views (something few designers would have the experience to do). The designers didn't really have to know anything about domain objects. It all worked very well once we'd worked out how it was going to work. Having the designers build up the views themselves would have been a nightmare in my opinion... and not something they'd have enjoyed either.
I'm writing an application that is supposed to show and hide the content of the main window stack panel based on the user choice. For example, the user clicks on the button that displays the list of the customers, then click on the button that displays the ordering form. The customers content should be hidden and the ordering form should be visible. Moreover, if there are contents with related information (like customers and their data) I want to be able to change the data in one window and it should automatically refresh the data in the other window when the user decides to open it. Is there a good way to do it in MVVM?
Thanks for any suggestions.
Because this question is so generic, the answer must be as well, and the answer is that this is exactly what MVVM is for - modeling data and binding it as needed. In fact, I would argue that a majority of MVVM examples you find online will be some flavor of an answer to your question, most likely using good ol' Northwind.
It sounds like you need to really take a good look at how you want to do your design before you jump in and start coding.
You might want to check out Prism (or as it is really named Composite Application Guidance). You can build really complex and modular designs with it.
You might be interested in the MVVM sample applications of the WPF Application Framework (WAF).
Writer: Shows how the Views (UserControls) can be switched (Edit mode; Print Preview mode).
BookLibrary: Shows how data modified in one View is automatically updated in other Views.
I have seen a lot of discussions going on and people asking about DataGrid for WPF and complaining about Microsoft for not having one with their WPF framework till date. We know that WPF is a great UI technology and have the Concept of ItemsControl,DataTemplate, etc,etc to make great UX. Even WPF has got a more closely matching control- ListView, which can be easily templated to give better UX than a traditional Datagrid like display. And I would say a readymade DataGrid control will kill or hide a lot of creativity and it surely will decrease the innovations in User Experience field.
So what is your opinion about the need of DataGrid in WPF as a Framework component? If you feel it is necessary then is it just because the world is so used to the DatGrid way of data display for many years?
Some other threads having the discussion about DatGrid are here and here
Link to WPF ToolKit - Latest WPF DatGrid
DataGrids are excellent for displaying large amounts of tabular data bound to a backing store.
But what happened in the WinForms world was that people often used them for everything that required a multi-element scrolling list. Souped-up third-party DataGrids soon became available that allowed columns and fields to contain buttons and ComboBoxes and icons, etc.
The DataGrid became a workhorse because there was a need for something it could be coaxed into behaving like. Similar happened to DataTables before generic collections came along--and when you're using lots of DataTables, presenting it in the UI with a DataGrid is the path of least resistance.
I think that when WPF came out, a lot of programmers like me were still thinking in this fashion, and sought out WPF ports of the DataGrid concept.
Can't think of a better control to display tabular data, especially in business apps where you don't want to reinvent the wheel by templating/developing a (Headered)ItemsControl to make it behave like the good old DGV. I'm sure you saw this.
Nobody is disputing that you can make a DataGrid control in WPF yourself. The same can probably be said about WinForms, although it would be more difficult. I've implemented some functionality with ListView - presenting tabular data is easy, you could even say it's well supported. However, the amount of code, manually written code, needed to make an editing ListView is enormous.
The business applications usually require editing of many tables, and you don't want to be creative, you want to be quick. That's why DataGrid is needed in my opinion.
Yes DataGrids will never go away as essential business UI components. People love their spreadsheets and we want to share in that love!
Note that MS are shipping these extra controls - they have created the WPF Toolkit on CodePlex to provide a fast-turnaround, open-source style of deployment.
It already includes a DataGrid and Calendar.
Yes it is!
Among many other controls that ms failed to deliver. (Datepicker, NumericControl)
MS should first give us the tools to get the job done, that is the least i expect from a programming enviroment with the hype of wpf.
It is essential, but you can achieve nearly the same effect with a ListView that is using a GridView, can't you?
After working with WPF for about 2 years now. I would say that a DataGrid is really just a glorified ListBox (since [almost] everything in WPF is styleless).
One could style a ListBox to take an Entity of some sort and show a "record" control for each entry. Depending on how flexible these are made, they could automatically adjust based on the entity passed.