I'm building a web app that's going to support multiple languages. For the moment, the words are hard-coded in English in the HTML and javascript. I want to use objects that contains the English word as the key and the word to be displayed as the value and have this dictionary object populate the page at runtime. But my question is not about client-side issues.
What's the best way to store and maintain this dictionary on the server. So far, I thought of a database table with columns for the English word and rows for the values to be displayed. I would then load an entire row in an anonymous type that I'd serialize in json and send the client. I think it'd work but I'm wondering if that's the best way to do it so that the dictionary will be easy to maintain.
If you've had some experience dealing with internationalization then please let me know if you have some suggestions.
Thanks.
You can use Resouce files for multiple language support for asp.net web. It is THE BEST method to use for multiple language support in asp.net. http://msdn.microsoft.com/en-us/library/fw69ke6f%28v=vs.100%29.aspx
Related
I'm not an ASP.NET programmer, but, as it happens in life, I had to do some minor projects using it. Now came another one in which I have to implement some custom solutions and I haven't figured it out yet - I need some tip or maybe a piece of advice like "don't go that way" ;)
Previously it was simple - there was a table in DB, there was an adequate model and a view that worked with it - worked like charm. Now it's a little bit more complicated.
The "site" is going to contain, shortly and generally speaking, a survey - but a fully configurable one, unfortunately. In another product there's gonna be a configuration manager that will allow user to define pages, block types, questions, steps and so on and will generate an XML.
For the time being, in accordance with the specification, in the site's database I'm going to have only one table which will contain just a key and the XML generated by the configurator (and maybe some additional, not important information). Now - I need to parse this XML and build the site containing pages and other elements corresponding to it.
And that WOULD not be a problem, but I don't really know how to work that way using asp.net + mvc and can't find any piece of advice that would help me anyhow. Should I create an object that would somehow fake being a model and allow me to work for example on a dataset generated from XML? Or just create a model of the mentioned table and work with the XML directly on the view (I don't like even such an idea itself)? Or - having to do something like that - just give up on MVC and use only "clear" ASP.NET? Or maybe something else?
I'll be very grateful for any help.
And I hope I described what I need understandably ;)
If the XML documents have a schema defined then you can easily generate a class that matches the document using the xsd.exe tool. The document can then be deserialized into an instance of that class using existing functionality in the .Net framework. Just google .Net Xml serialization :-)
Now, if you don't have a schema you could create one if you are sure that you know the format of the Xml. Alternatively you could create a class that matches the format you expect to get and then parse the Xml manually. This last option is much more work, so I wouldn't recommend it.
In any case, the class you end up with should contain all the data you need from the Xml document and can then be used as the Model in your MVC page. As long as you can use the standard Xml deserialization technique then this should be quite easy and painless.
I'm after a general regex for sanitising form input, I want to use it on first name last name fields , which will be stored in DB, and pretty much use it in other general places if I can.
I'm using ASP.net does any on
Sanitising user data is an output problem, not an input problem.
What is considered "sanitary" for a MySQL database is not necessarily "sanitary" for MSSQL or PostGreSQL. What is considered "sanitary" for a database is most likely not the same as what you could safely send in an HTML document. XHTML is a different story again and if you are outputing the user-supplied data into a javascript block or a CSS block it's different yet again. There is no way to sanitise user-supplied data for all output targets.
It's better to use the supplied library functions for sanitising data rather than building your own regex. PHP (which I happen to know better than ASP.net) has mysql_real_escape_string(). I'm sure ASP.net will have a library function for sanitising user-supplied data for use with various databases. It will also likely have library functions for sanitising user-supplied data for HTML as well.
Parameterised queries are even better than sanitising user-supplied data. And it can be done with ASP.net. This is the right way to use a database.
I'm using asp.net and I need to build an application where we can easily create forms without recreating the database, and preferably without changing the create/read/update/delete queries. The goal is to allow customers to create their own forms with dropdowns, textboxes, checkboxes, even many-to-one relationship to another simple form (that's stretching it). The user does not have to be able to create the forms themselves, but I don't want to be adding tables, fields, queries, web page, etc. each time a new form is requested/modified.
2 questions:
1) How do I structure a flexible database to do this (in SQL Server)? I can think of two ways: a) Create a table for each datatype (int, varchar(x), smalldatetime, bit, etc). This would be very difficult to create the adequate queries. b) Create the form table with lots of extra fields and various datatypes in case the user needs 5 integers or 5 date fields. This seems the easiest, but is probably pretty inefficient use of space.
2) How do I build the forms? I thought about creating an xml sheet that had the validations, data type, control to display, etc. as a list. Then I would parse through the xml to build the form on the fly. Probably using css to do the layout (that would have to be manual, which is ok).
Is there a better/best way? Is there something out there that I could look at to get ideas? Any help is much appreciated.
This sounds like a potential candidate for an InfoPath solution. At first blush, it will do most/all of what you are asking.
This article gives a brief overview of creating an InfoPath form that is based on a SQL data source.
http://office.microsoft.com/en-us/infopath-help/design-a-form-template-based-on-a-microsoft-sql-server-database-HP010086639.aspx
I have built a completely custom solution like you are describing, and if I ever did it again I would probably opt for either 1) a third-party product or 2) less functionality. You can spend 90% of your time working on 10% of the feature set.
EDIT: reread your questions and here is additional feedback.
1 - Flexible data structure: A couple things to keep in mind are performance and the ability to write reports against the data. The more generic the data structure, the harder these will be to achieve (again, speaking from experience).
Somewhat contrary to both performance and report-readiness, Microsoft SharePoint uses XML fragments/documents in generic tables for maximum flexibility. I can't argue with the features of SharePoint, so this does get the job done and greatly simplifies the data structure. XML will perform well when done correctly, but most people will find it more difficult to write queries against XML. Even though XML is a "first class citizen" to SQL Server, it may or may not perform as well as an optimized table structure.
2 - Forms: I have implemented custom forms using XML transformed by XSLT. XML is often a good choice for storing form structure; XSLT is a monster unto itself, but it is very powerful. For what it's worth, InfoPath stores its form structure as XML.
I've also implemented dynamic forms using custom controls in .Net. This is a very object-oriented approach, but (depending on the complexity of the UI) can require a significant amount of code.
Lastly (again using SharePoint as an example), Microsoft implemented horrendously complicated XML list/form definitions in SharePoint 2007. The complexity defeats many of the benefits. In other words, if you go the XML route, make your structures clean and simple or you will have a maintenance nightmare on your hands.
EDIT #2: In reference to Scott's question below, here's a high-level data structure that will avoid duplicated data and doesn't rely on XML for the majority of the form definition.
Caveat: I just put this design together in SQL Management Studio...I only spent 10 minutes on it; developing a flexible form system is not a trivial task, so this is an over-simplification. It does not address the storage of user-entered data, just the definition of the form.
The tables:
Form - top-level form table which contains (as you would guess) the collection of fields that comprise the form.
Field - generic fields that could be reused across forms. For example, you don't want 50 different "Last Name" fields for 50 different forms. Note the "DataTypeId" column. You could store any type you wanted in this column, like "number, "free text", even a value that indicates the user should pick from a list.
FormField - allows a form to contain 0-many fields in its definition. You could even extend this table to indicate that the user can ADD as many of this field as they need.
Constraint - basically a lookup table that defines a constraint type (maybe it's max length, max occurrences, required, etc.)
FormFieldConstraint - relates a constraint to a particular instance of a form field. This table combines a specific form with a specific field with a specific constraint. Note the metadata column; this potentially would be a good use for XML to store the specifics of the constraint.
Essentially, I suggest building a normalized database with few or no null values and no duplicated data. A structure as I've described would get you on the path to that goal.
I think if you need truly dynamic forms saved into a database, you'd have to create a sort of "dictionary" data table.
For example...
UserForms
---------
FormID
FieldName
FieldValue
FormID relates back to the parent form (so you can aggregate all of the fields for one form. FieldName is the name of the text field entered from. FieldValue is the value entered/selected for that field.
Obviously this isn't a perfect solution. You could have issues typing your data dynamically, but I leave the implementation of that up to you.
Anyways, hopefully this gives you somewhere to start thinking about how you'd like to accomplish things. Good luck!
P.S. I've found using webforms with .NET to be a total pain when doing dynamic form generation. In the instances I had to do it, I ditched it almost entirely and used native HTML elements. Then rewired my form by using the necessary values from Request. Probably not a perfect solution either, but it worked the best for me.
We created a forms system like the one you're describing with a schema very similar to the one at the end of Tim's post. It has been pretty complicated, and we really had to wrestle with the standard WebForms controls like the DetailsView and GridView to make them be able to perform CRUD operations on groups of answers. They're used to binding straight to properties on an object, and we're forcing them to look up a field ID in a dictionary first. They don't like it. You may want to consider using MVC.
One tricky question is how to store the answers. We ended up using a table that's keyed on FieldId, InstanceId (for example, if 10 people are filling out your form, there are 10 instances), and RowNumber (because we support multi-row forms for things like employment history). Instead of doing it this way, I would recommend making your AnswerRow a first-class concept with its own table tied to an Instance, and having the answers be linked to the AnswerRow and Field.
In order to support different value types, we had to create multiple answer fields on our answer table (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal). Each of these maps to one or more Field Types (Date, Time, Number, etc.). Each Field Type has its own logic to represent the value in the UI, and put the value into the appropriate property on our answer objects.
All in all, it's been a lot of work. It's worth it for us, since this is the crux of the product, but you will definitely want to keep the cost in mind before embarking on a project like this.
I need to add dictionary facilities to an Asp.net MVC app. Does anyone know a library that I could use? Where can I get word definitions from?
Any help is appreciated.
it depends on what you want to do.
if you're trying to add a reference of an actual dictionary of words to use for your application then you'll have to create your own to define the words that you want to use.
if you're trying to find the library that contains the data type dictionary then you should try
System.Collections.Generic, or System.Collections.Specialized
If its still relevant for you, It's not a 'library' but on Dicts.info site you can find raw dictionary files you could use inside your application.
You can also find bilingual dictionaries for various languages or even categorized vocabulary, and even more...
Watch out to respect their respective licences.
As the question is a bit self explanatory, I want to achieve the goal of a multi-language website. I am using an Entity Data Model with MS SQL 2005. I came up with an idea of making a seperate database for each language with exactly the same model and relations. So I can use the Entities constructor that takes a connectionString and switch the site to the selected language.
I am using an ascx as the language control that fires an event, and the parent aspx gets the selected language as an integer (from event args) and call the method containing the same linq queries but Entity context will be created with the connection string of that db (of language)
I could only came up with this solution, because I think adding a new language will require a replication of the english one, imported to Access and sent to the translator. Then will be exported back, and the model will fit (HOPEFULLY).
My question is if this is really a good approach or am I missing anything that will create greater hassle to me. Thanks in advance
multi-database is not a good solution as soon as entities within the different databases have relations to each other. Generally a good approach is to work with labels in one default language. These labels can either be in a well defined format (e.g. 'LABEL.TEXT_HELLO') or just in the base language (e.g. 'Hello World').
So all you have to do is building a table for translations where the base language is the key and hopefully there is for each key a value containing the translation. As soon as you have the translations, you can write a method ont he frontend which writes the labels in the language used by the user.
In Zend Framework for example, you have to write <h1><?= $this->translate('Hello World'); ?></h1> instead of just <h1>Hello World</h1>
The good thing about that is, that if ya translation is missing, you can still use the fallback (in this case english) to show the user at least something.
That way, you can manage your app in one database and users who speak several languages do not have to switch between applications and content.
cheers
My approach: create a table Language that lists all the available languages. Relate each table that should be localized to Language. Now, you can easily access the localized content e.g.
Content[content_ID].HeadLine.Where(hl => hl.Language.id == "en-US")
I look forward to see what other people as I myself is still learning DB design and EDM.
OK, if you want to be able to easily implement a new language, then reinventing the internationalization features already built in to ASP.NET is not the way to go, because it isn't "easy".
At least, not as easy as using a satellite resource DLL. Your translators will use off-the-shelf tooling to translate your resources, and ASP.NET will automatically select the correct DLL based on the user's current culture.
Read up on ASP.NET internationalization/globalization features; there's no need to invent your own.