For the last year, I have delivered several relatively simple single-page apps, essentially almost-alike mortgage and financing calculators, to various customers. These have either been the sole focus of a page, or sidebar apps beside some main content. Since these apps differ by very little else than styling, layout, and a few customer specific parameters, it would mean a high ROI if these SPAs could be consolidated into some kind of library.
How one would go about in doing it in practice is a bit more unclear. What are the key points to consider and/or avoid when creating a library of pre-made interactive components?
They need to
be custom-styled per customer (custom widths, heights, fonts, etc)
not clash with other page elements
... ?
It seems unwise (inflexible) to pre-render html and inline css on the server side, and maybe some kind of half-baked JSON representation would be more appropriate, where the actual assembly would be controlled by some javascript, and styling would be done on the client based on some default stylesheet we provide. Or maybe somehow use GWT (we are a Java shop) to create the widgets.
I am out of my depths here so input would be most welcome.
in this case, possibly a better way to think of this is not creating a library, but creating a "calculator" application (widget) that can be configured for different kinds of calculations and to be themeable
So your focus is on how to create it so you can configure it for different functionality.
Related
I'm currently building a VueJS app the will have map components in different formats on multiple pages. I'm therefore evaluating some existing components: vue-mapbox and vue-mapbox-gl (listed as mapbox-gl-vue on npmjs.com) and would like input on a choice criteria.
vue-mapbox has 37 stars on github and has peaked at about 86 downloads a week on npm.
vue-mapbox-gl has 87 stars on github and has seen a much more popular download history at around 1000 per week on npm.
Both projects seem to be under active development.
Apart from this difference in popularity, the main difference I see between the packages is vue-mapbox has adopted a more granular approach to creating sub-components (like markers and controls), whereas vue-mapbox-gl gives you a single map component and then you implement markers, clusters, controls, etc., withing the script tags of your base component. To my way of thinking, this is not really the 'vuejs way' where you create reusable components. However, vue-mapbox-gl is significantly more popular.
How would you choose? Or, would you skip component packages completely and write your own?
EDIT
Based on comments, I've updated this question.
My requirements:
An overview map that has thousands of points and supports clustering.
A per location map that displays a single point
Ability a edit a single point location and integrate geocoding
Popups on all points
Consistent styling and features across all map variants
Nuxt app with SSR, so ability to block SSR on maps.
Given that maps will appear on different kinds of pages, there will be some code reuse.
In a VueJS/Nuxt environment, what are the pros and cons of using vue-mapbox, mapbox-gl-vue, or writing from scratch?
I am making a web browser made in VB.Net, and I do have people using it from around the world, but I don't think all of them can understand everything it can do. Does anyone know how to create a sort of language pack that users can change the language of every label on the form? The only way I can think of is editing all the labels to another language, then publishing the application again, but that is a lot of work because I do use a lot of labels... any help would be appreciated. Thanks!
What you're looking to do is called "localization." While localization itself is not a difficult topic to understand, depending on the complexity of your application, and the number and diversity of languages you want to support, it can become a rather involved task.
The general concept behind localizing an application is separating translatable elements (like all of the strings in your buttons, labels, and menus, or any images containing words) from the application itself, and storing them as resources which can then be chosen appropriately based on user preference or region, and then loaded into the application dynamically. There are a vast number of ways to accomplish this, and which you choose is entirely up to you, and how much effort you're willing to support. Techniques can range from loading strings from text files, storing and retrieving resources from a database, to using .NET's built-in localization functionality which stores assets in external resource files.
Localization as a topic is incredibly broad, so there is no single method that can be discussed without first knowing your specific goals and constraints. Your best plan of action is to start researching, and find a technique which seems most suitable for your project.
Google: ".net localization"
I wonder if it is possible to configure MediaWiki (or other wiki tools) as a modular predefined wiki. For instance, on a regular wiki page one can freely edit sections, text, everything.
I am looking for a solution that predefines a number of sections (or modules) that can be added to each wiki page. Then users are free to edit inside those sections within their predefined formats.
Hope someone can help, thanks.
As for MediaWiki, there is at least one extension that can work that way: Semantic Forms, usually used together with Semantic MediaWiki (though that is not necessary). With SF, you will define one or more templates that receives the data entered in the form, and the form can be divided into sections.
A more lighweight solution might be using one of the many boiler plate extensions available.
Either way, with a wiki you can never force your users to follow a certain scheme. The whole philosophy, making wiki's unique among collaborative tools, is that the users, not you, create not only the content but also the structure for the content!
The former Semantic Forms is now called Page_Forms and it is not dependent on SMW https://www.mediawiki.org/wiki/Extension:Page_Forms and can also make use of the Cargo extension https://www.mediawiki.org/wiki/Extension:Cargo
I would disagree that wiki users cannot or should not be forced to follow a scheme for some types of information, though the default is that they do control the categories and namespaces and can create those at will as the data evolves. All this means though is that you manage such issues socially rather than with complex permissions structures, i.e. someone undoes your change and says "do it this way instead". So it's a different kind of forcing, but, still, someone has to make sure categories don't proliferate with bad names, capitalization, etc.
The typical use of forms data is when it must be used to satisfy some legal or professional requirement (say logging for what reason a change was made for Sarbanes-Oxley, or logging what precedents were consulted for logging legal time), or will be providing input strictly to some application (like maps). It would not be a good idea to rigorize literally every page of a wiki this way.
I have many Normalized tables - might be more than 50... I was wondering what is the best approach for defining ViewModels - individual ViewModel for each form or making Common ViewModel for multiple Forms. Because making individual forms might increase the size of the data that needs to be downloaded and it might increase the redundancy of data on the client. i.e. using Category on each form has different set of data for each of them. and On the otherside making common viewmodel for set of Forms might increase the complexity in managing stuff.
Is there any proper article describing such aspect of Development. What is the best practices for managing overall Application so that it will offer optimal performance. (Fetching minimum Data from Server)
Thanks for your time and help.
The amount of views & models will increase the size of your XAP file, which is downloaded completely on open, this can be compressed. Actual performance during use is different and depends on other factors as well, try using SilverlightSpy to get an idea of actual browser performance. It is possible to download parts of your silverlight app as required, but this is an advanced technique.
If Messaging is your main concern, then check out Binary Messaging.
I recommend using a new ViewModel for every view, or nested Usercontrol, then use an event aggregator for communication between models.
Typically you'll want to create a View Model for each View. If two Views display the same data and allow the user to perform the same actions but differ only in UI implementation then they can share a View Model but the goal is to keep your View Models cohesive. If your View Models contain code to operate multiple views you run the risk of implementing the "God Object" anti-pattern. If you find that your View Models all share a certain amount of common code, consider moving that code to a common base class.
Remember that two completely different View Models can manipulate the same Models. This might be the case if two views display the same data but each allows the user to interact with it in a unique way.
I would highly recommend reading Pro WPF and Silverlight MVVM by Gary Hall. It's a great book to get started with MVVM, particularly for use with WPF and/or Silverlight.
In the Apple Docs they say that a Nib enables internationalization by just translating the Nib into many languages. I am thinking now about a worse but realistic scenario: You have made a huge user interface. Then you translate this into 25 languages. So you get 25 different Nibs. You also get a huge redundancy in styling and defining the UI: 25 times the same stuff. Same Bindings, same everything. Just text is different.
So, I really think this is a very bad approach. Instead, I would prefer to just link in all texts from a resource bundle or something like that. Just a file with text strings, which is linked in at run time from the appropriate language resource. Then you only have "trouble" linking in the text which really doesnt make any fun. But then, you can do changes on your UI ONCE without having to do the same step 25 times over and over again. A new Binding in every nib. That would be so horrible!!
Now, please tell me I got that wrong. Apple does not assume that we do something so creazy?
The localization situation is not ideal. Although Cocoa UI elements support some dynamic flexibility in their sizing (the ausosizing flags), it's very difficult to arrange them in a view so that they will accommodate any sized text.
As Heng-Cheong points out, this usually means that some adjustment to layout is required on a per-localization basis. Apple supports a process called incremental localization with a tool called "ibtool", bundled with your developer tools. The process is far from intuitive and seems to have some subtle bugs, but it helps to make the process easier than, say, separately maintaining 25 different nibs manually. The process essentially involves mapping changes you make to your primary nib onto the other localized nibs. Apple describes the process in more detail:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html
In order to avoid this painful process, some people take a different approach. If you compromise on the layout of your views, you can achieve a situation where every UI element accommodates the largest localized string. Using the alignment features of text fields, etc., you can thus arrange an acceptable layout, though the extra spacing required for the localization with the largest strings often causes a less-than-ideal layout for the language whose strings are shortest. If you take this approach, you need to design your nibs so that a controller class populates the nib's UI elements with the correct localized strings at runtime.
Finally, some developers go so far as to apply their own relayout to the elements in a nib, optimizing them for the sizes of the strings that have been set upon them. This would be a refinement of the strategy above, where a single nib is used and manipulated at runtime to achieve the desired effect.
Sometimes, localization involve more than just replacing text, but changes in layout too. For example, strings in one locale/language may be significantly longer than in another, forcing a change in layout. Right-to-left language often will mean some changes in layout too.
Building on the previous two answers, there's a tool called iLocalize that aims to make the process easier than ibtool does (and it's older than ibtool). I've never used it myself, but my friend Evan uses it on both Adium and Growl and loves it.