I'm evaluating XAF for our organization. It seems great and so powerful. But have some problems with its UI customization.
For example, I want to design a PersianDatePicker UI element and tell XAF to use it for DateTime properties.
Question 1: How can I design custom UI Elements (like PersianDatePicker) in Web and Win?
Question 2: How to tell XAF to use my custom UI controls in the layouts?
You can customize built-in DateTime property editors:
https://documentation.devexpress.com/#eXpressAppFramework/CustomDocument113104
https://documentation.devexpress.com/#eXpressAppFramework/CustomDocument113114.
You can then make them to be used as defaults or to set them in Model where it is appropriate.
Related
I am developing a web application using ASP.NET Core 1.1 with VS.2017. I am using some custom attributes that I apply to objects like classes, structs, etc.
I was wondering if it is possible (and how) to "tag" a Razor view with one such custom attribute. I mean, those views are compiled so that probably means some sort of class is generated for each view.
Please concentrate on answering the question rather than questioning why I want to do it. There is a need -in my application- and therefore I seek a way to do it.
I want to create a view that can be used twice on the same page, each time with a unique id.
At the moment I'm using two approaches to do this kind of thing
Editor Templates
stevensanderson's approach for having controls created on the fly
Editor Templates are the easiest as they take of the name mangling (e.g. parent1_parent2_childId) but Editor Templates can't be used across Areas and I really like Areas
Is there a 3rd option?
thanks
You can pass a model to a child view in the RenderPartial extension method. Use this mode to pass a desired id, or something from which it can be obtained.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would like to create a quiz with dart. Checkboxes, radiobuttons, dropdownmenu, inputfields, ...
Furthermore I would like to load the quiz from a database, display it on a website and store also the results of a specific user to a database. Redis or mysql.
The big question for me: Should I use polymer.dart or angular.dart? Both are capeable of doing it but what would be the obvious choice?
Polymer and Angular might look very similar because they both have templating and data-binding, but they're actually quite different.
Polymer isn't really a full application framework so much as it is a framework for creating W3C Custom Elements1. It relies on new, upcoming, and hopeful standards like Shadow DOM, Object.observe, Mutation Observers, Scoped CSS, the element, Template Binding, Node.bind(), Custom Elements and HTML Imports and basically makes it easier to use them together to create custom elements. You actually don't need to use Polymer at all to create custom elements, it would just be more tedious. The Polymer project has also built polyfills for those standards, so it's sometimes confusing to tell which parts are the actual "polymer" part. In Dart-land it's only things in the polymer package, mostly the Polymer class, everything else is in packages like observe, template_binding, or already integrated into dart:html, like Shadow DOM.
Once you implement a custom element in Polymer, users of the element don't need to be aware of Polymer at all, it's an implementation detail. They might need to know about custom element upgrading or Node.bind(), but not Polymer. In fact, Polymer is so focused on elements, that there isn't really such a thing as a "Polymer app", there's just an app built out of custom elements, which happen to be implemented with Polymer, but they could just as easily be implemented with Mozilla's X-Tags library[2]
Angular is definitely more full featured and what I would call an "application framework", rather than a custom element framework. It provides directives (mixin behaviors for nodes), dependency injection, all kinds of services like http and routing, and has this whole mutable inherited scope idea that permeates the app, and has global state, among other things I'm probably missing. Angular currently won't help you build custom elements, instead you create Angular components that work in Angular apps.
An Angular app can use Polymer elements, since Polymer elements are just elements. One way data-binding should[3] just work, while two-way data binding will require either a custom directive (to use Object.observe or Node.bind to listen to property changes), or for Angular to add support for Node.bind(), which would allow Angular to generically two-way-bind to any element, from s to Polymer elements, to X-Tag elements.
In the end, I don't think there is a fair apples-to-apple comparison between the two, and the overlap is smaller that it might appear on the surface, because people seem to either over-estimate how big Polymer is or how under-estimate how big Angular is, or maybe they aren't aware of the differences in philosophy. I fully expect more Angular-like frameworks to appear in the future that build on top of custom elements that will be more comparable to Angular than Polymer is, and Polymer will still be a nice way, among other options, to implement the elements.
SOURCE
I worked a lot with Polymer (https://github.com/ErikGrimes/polymer_elements, https://github.com/ErikGrimes/polymer_ui_elements) and worked on a webapp based on Polymer.
I like building apps out of components a lot.
Recently I immersed into AngularDart.
Angular allows to create components too.
At the current state I would say that I find Angular more lightweight.
Not everything has to be a component, there are more lightweight constructs (direcitve, controller)
The hierarchical scope easily allows to connect everything.
I have yet to do more advanced things (like I already did with Polymer) to learn the limitations of Angular and be able to do a fair comparsion.
Both have still some glitches and limitations and are still pre 1.0
but both already allow building advanced applications
and as #Nidzaaa 's noted, they can be used in combination.
On a number of different document types, I have to add the same 3 native Umbraco data types
content picker
TextString
TextString
It was suggested to me to see if there is a way to create a new custom data type that would basically wrap those 3 datatypes into a new datatype.
I looked at nibble.be's site and see there is a couple different ways to go about creating custom data types (using the usercontrol wrapper, or 3 class approach). However, I am not sure that a custom data type for grouping existing datatypes would be the correct route.
For one thing, we are using MVC along side Umbraco with a heavy use of Razor views. Since the document type property alias is used to acquire values from Umbraco from the content page, I don't see how this would still be possible or how you would go about getting the property value of a custom datatype that has embedded datatypes.
Would there be a working way or a better way to accomplish this solution for having to add the same fields on any document type that they are needed? I though about hierarchical approach with a document type parent with only these 3 data types (content picker and 2 textstrings), but that would mean having to put any document type that a page would need under this parent document type simply for the fact to inherit these group of properties.
If you're looking to embed multiple properties into a single datatype:
There are a number of embedded datatypes available; DataType Grid, Embedded Content, and Repeatable Custom Content are the three I know of. All three store their information as xml which allows easy access via both xslt and razor.
The DataType Grid is part of uComponents and is therefore actively developed. It is also open source and therefore contributions are encouraged. Embedded Content and Repeatable Custom Content, while still useful, don't appear to have any current support and therefore no plans for improvement. I think they are licensed as open source, but the source isn't publicly available as far as I can tell.
I don't think you can set a limit on the number of rows/items stored in the DataType Grid, like you can in Embedded Content (perhaps a feature request).
Take a look at some of these solutions before you plan on rolling your own. But if you still feel the urge to code out your own data type, I'd recommend Tim Geyssens' articles on created custom datatypes using the user control wrapper, with data editor settings, and serializing the data as xml. His "Master of Datatypes" video is also really helpful and covers those topics as well.
If you're looking to organize your properties into groups:
Tom Fulton published a new package/data type recently called Document Type Fieldsets that may fit your needs. It allows you to group fields together in a fieldset. Here's a screen shot:
I realize this is an old question, so I'm just adding this for anyone searching for this functionality in the future: This is almost exactly what we use Widget Builder for in Umbraco 6.
Widget Builder is the predecessor to Umbraco 7's Archetype which is being pushed by the core team for near universal use. I believe it's going to become a part of the core.
Internally, WidgetBuilder and Archetype store their data as JSON and make it very easy to copy a custom data type from one project to another with an import/export feature.
I used to work with Archetype for some time until I discovered Nested Content which does the same thing but much easier to work with because it nests Document Types instead of Data Types which is much easier to work with, especially for Content Editors. Plus the resulting Data Types is normal built-in Umbraco ones, not Archetype Objects which add a new layer of Entity Mapping in your views.
What is the best way to structure a VB.NET Windows Forms application so that code can be reused and the application can be extended easily?
I used to create lots of new forms. This lead to lots of repeated code and forms which did similar things.
Now, for forms which do similar jobs, such as view/edit/delete items from a specific database table, I create a form with the required controls, have the form create an instance of a class with parameters such as a collection of the controls and a string containing the database table name. Then the individual controls call functions of the class.
Advanced forms will inherit and extend this basic form class.
Has there already been work done in this area?
Are there books / articles available which discuss the options available on this topic?
I had great success with this Passive Screen pattern.
In my opinion, the big problem of the traditional MVC architecture is that people stuff way too much into the form classes. This increases the amount of manual testing you have to do.
The more automated testing you can do after you compile, the more bugs you will catch at your desk. In a complex application, the side effects from even minor changes occur all too often.
The trick to solving this is making a controller assembly that the form assembly (or EXE) references. Every form has a corresponding class in the assembly. Clicking a button will call ThisForm.ThisButton(<args>) which will then fire objects lower in your framework. Each form implements an interface so that, if the controller class needs additional information from the form, it has a interface to retrieve it.
Then for your unit testing you simulate an operator performing complex operations by implementing dummy classes to fire events and feed information to the controller classes. The controller classes don't know any different as the dummy classes implement all the expected interfaces.
There is an important exception and that is for trivial dialogs. For dialogs that have a few check boxes I feel this organization is overkill. I use the command pattern a lot. So in the assembly where I define the Command objects, I put the SIMPLE dialog associated with that command. How simple a dialog has to be to get this treatment is up to you.
I like to structure my applications as follows.
Utility - This is an assembly that has stuff I use all the time - Math functions, file function, etc.
Objects - This has the specific objects I am using for this application.
UIFramework - This defines all form and controller interfaces.
Commands - This has all the Command objects that manipulate my application objects.
UI - Objects that implement the controller interfaces
EXE - Forms that implement the form interface and calls the controller objects.
You may want to check out a Rocky Lhotka's popular CSLA Framework. It provides a very structured way to implement business objects so you can keep the non-UI code out of your forms. Beyond just separating your business logic though, it provides built in n-level undo, validation, security, data binding support, etc.
The one complaint most commonly directed at CSLA is that it makes test driven development difficult, so that may be something to consider as well.
Something that can help a lot is the use of User Controls. With user controls you can reuse the same UI in different forms. Also, you can have many user controls on one form, so if you have a form with a tabcontrol that has 5 tabs, the content of each tab could be a user control, so instead of having hundreds of controls all mixed up in one form, each user control has its own controls and validation logic, and you end up with just six controls in the form: the tabcontrol and the 5 user controls.
This doesn't help in separating UI code from application logic, but it enables you to have small, structured entities instead of forms with thousands of lines of code.