I have an ASP.NET MVC3 application which has multilingual support. Almost every word has multilingual support and at each page request I get all the words in the currently selected language from the database into a List and I use it for each Word: I hold MeaningID for each element and print out the matched one from the List. Costly approach, but better than reaching to database for every Word.
Still, I wonder if there's a data structure I can use globally throughout the project, which is only loaded from the database when the user changes the selected language. Is there a session like list structure can I use for such a purpose?
EDIT: To make things clearer I'm posting my database tables.
--Word-- --WordBase-- --Language--
ID ID ID
Text Text Name
BaseID
LanguageID
As it's seen, WordBases are meanings that Words depend on by a Language. Example data is:
--Word-- --Base-- --Language--
1;Hallo;1;1 1;Hello 1-Deutsch
2;Hello;1;2 2;Good 2-English
3;Gut; 2;1
4;Good; 2;2
Your web app is like a dictionary? I mean... your "words" are the data of your application... or are you talking about internationalization?
If it is internationalization, I think there are better ways to do it... using the tools built in. Check this: http://afana.me/post/aspnet-mvc-internationalization.aspx
If the translatable data is too large... may be you could have an hybrid approach... keeping tokens in database... and translation in resource files. Then, caching would be useful, specially if your data doesn't change very often (you can set caching for 30min... and for that time you avoid SQL queries to retrieve words in every request).
You should cache this using Cache. Then, you can manage the Cache to hold the information during the user session or by time expiration.
Take a look here: Walkthrough: Caching Application Data in ASP.NET.
Related
A website I am currently developing with Neos / Flow includes a self-developed shop system implemented as a Flow Plugin. The products, variants and vouchers are kept as domain models.
Since the customer wants to provide their website in different languages I need to find a way to manage translations for the domain objects.
I cannot find a way which is baked into Neos/Flow so my first thought was to simply insert translation identifiers inside the translatable fields (description & stuff like that) which are then used inside the view with the translation viewhelper. This would work totally fine if the customer would not want to edit those fields by themselves.
My next idea was to just implement an extra field for each language-dimension and each translatable field (like description_en; description_es, …). But this would be the worst approach in terms of maintainability and changeability.
I usually worked on TYPO3 projects where translation of domain objects is really easy and working out of the box. So this experience inside Neos is very frustrating.
Does anybody came across a similar problem or even has found a solution to this?
whenever we've got the requirement to have multi-language content so far, we've solved that, by storing the data within the Neos Content Repository. This way language handling aka dimensions work out of the box. Also, building a UI for that records is very easy by using inline editing or the inspector of the content module.
Note, that storing data in the CR does not necessarily means, that you have to store it under the /site root node. You could also add a new root node /products to store your products.
You could have a look at https://github.com/neos/metadata-contentrepositoryadapter where meta data is stored under its own root.
Hope that helps,
Cheers, Daniel
For the record, something like that could also be achieved with the Doctrine Translateable extension in pure Flow:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
See http://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#on-the-doctrine-event-system on how to activate the extension in Flow.
However, the cleaner aproach indeed is to actually separate domain model and content (unless you build a CMS and the content is your domain ;)
I'm developing a web app with two languages, German and English. I have implemented searching on my webpage, and I want to keep track of the user's locale when searching.
How can I achieve this:
http://localhost:8080/user/search?search=pax?lang=de
instead of:
http://localhost:8080/user/search?search=pax
In my form I have:
action="/user/search"
I tried
action="<spring:message code="user.search.movie.link"/>
user.search.movie.link = /user/search or /user/search?lang=de
but it doesn't work.
Putting information in URL parameters is good in some cases*, but probably not this one. It seems likely that a user chooses their language setting once, around login time, and then rarely if ever changes it. Or it might even be set automatically. If so, language is something you might want to store in the user's session, or a persistent store like a database if you're using one. You seem to be using Spring, and I don't know a lot about their session handling, but their docs are at https://docs.spring.io/spring-session/docs/current/reference/html5/.
*: for more on this, you might want to read up on the differences between GET requests and POST requests (here's one of many SO posts on the topic). The most relevant part for you is that GETs are the ones that have visible parameters in the URL, but there are lots of other reasons to use one over the other.
Is there another way to view the profiling results of MiniProfiler (I'm specifically interested in EF5 version)?
Every tutorial that I've seen uses MiniProfiler.RenderIncludes(); but since my MVC app mostly returns JSON, that is not an option for me.
Is there a way to write results to file or something like that?
You can read and write results to just about anywhere by changing the MiniProfiler.Settings.Storage to a different IStorage implementation from the default (which stores to http cache). If you wanted to, this could store to and read from a file pretty easily (you would have to write your own custom implementation for that).
The files served by RenderIncludes are the html templates for displaying the results and the script to retrieve the results from the server and render them on the client (all found here). But you are by no means obliged to use this mechanism. If you want to write your own logic for retrieving and displaying results, you should base this off of the logic found in MiniProfilerHandler.GetSingleProfilerResult. This function roughly performs the following (putting in the siginificant steps for your purposes):
Gets Id of next results to retrieve (through MiniProfiler.Settings.Storage.List())
Retrieves the actual results (MiniProfiler.Settings.Storage.Load(id))
Marks the results as viewed so that they wont be retrieved again (MiniProfiler.Settings.Storage.SetViewed(user, id))
Converts these to ResultsJson and returns it
With access to MiniProfiler.Settings.Storage, you should be able to retrieve, serve and consume the profile results in any way that you want. And if you are interested in using the RenderIncludes engine but want to mess around with the html/js being served, you can provide your own custom ui templates that will replace the default behavior.
What is the standard convention to save data in textboxes and other form data to be loaded the next time the program is opened?
I personally do not know of any convention, however you could look into the following methods:
Using the registry: http://radio-weblogs.com/0111551/stories/2002/10/14/registryRwInC.html
Using profile strings: http://dotnet-snippets.com/dns/c-read-and-write-ini-files-SID574.aspx
Not sure of the standard convention, or if there is one, but saving to a text file would be a simple-to-implement solution.
It depends on the kind of data that you are trying to save. If this is a relatively small amount of user specific data associated with their user preferences, then user settings are the way to go.
If this is large amount of application data (for example like an entire address book), then you are probably better off writing to an external file or database in whatever format suits your needs.
You should be looking at Windows Forms data binding - that is the best way to save data from and reload data into a Windows Forms application. Once you have set up your form controls for data binding, you have a choice of where to store the data, as explained here.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.