I want to translate my web page to 7 different languages and I'm curious about what is the best way to handle this?
I know this subject opened multiple times but I didn't get a reasonable answer.
Actually, all the topics are about php and gettext but I use classic asp (vbscript).
The method I'm using now is that;
I have en.asp and tr.asp which contains
lang_home="Home Page" and lang_home="Ana Sayfa"
and in my pages, I display them like <%=lang_home%>. I don't want to use lots of bracelets because I believe they slow down my site.
Evan, I thought that <%=GetTranslatedText(lang_home)%>
What I need to know is what is the best approach for multi-language web sites for asp and is there any solution like gettext for asp?
Thanks in advance.
There are only two ways to send dynamic text to the browser in ASP:
Write the entire HTML page with Response.Write calls
Embedded calls to Response.Write in otherwise-static HTML.
I think you're on the right path, balancing the need to have easily-editable HTML code with a fast lookup and replacement of language-specific strings. At least faster than, say, a bunch of SELECT CASE statetments, or a lookup against a Collection.
(If performance is really an issue, why not move over to ASP.NET?)
One other option is to pre-compile your ASP pages... keep a template of, say, "default.asp.template" that contains variables, separate language files (like you have now), and some code to generate "default-en.asp", "default-en.asp", etc. each time you change your template. Then, set the "default.asp" to simply and silently transfer execution to the correct page based on the user language.
An excellent (but commercial) app I've used for pre-compilation of ASP pages is WebGecko APGen (http://www.webgecko.com/).
Related
I've been working with an ASP Classic site with over 500 files, some of which aren't used and some of which are; along with a database with hundreds of procs and functions and tables, in the same shape.
I need a way to get a grip on the project so I can eventually migrate it. I don't have time yet to walk through every single page and look at the SQL (stored procedures are in the database and are called properly within the ASP pages), so I'm at a loss as to how to get a handle on this.
My immediate thought is to make ASP classes and put them into the pages as I go - they'd pretty much be used for getting and setting fields, validation, and sending recordsets into display functions.
Is this a reasonable approach? Am I missing some strategy?
How would you approach this? A migration to another platform at this point is considered, but not feasible for the short term (next couple of months)
You can try to compile the project using http://aspclassiccompiler.codeplex.com/ or you can migrate to ASP.net MVC one page at a time (when needed) and using a mix of both in the meantime.
My simple advice is stop think about code. Spend more time with the UI actually using it and spend time examining in detail the database schema.
Edit
If you are trying to determine what pages are active then use IIS logging to harvest distinct pages hit. Also do some scripting to collect the names of files and text search the files in the site looking for any occurance of those files. This info should identify parts of the site that are rarely used or dead.
However in all probability there will considerable content in the "active" files which are also dead. Let me re-iterate do not actually to add classes or refactor the code at this stage you should concentrate on understanding what it does not how it does it. Understanding the DB Schema is a vital step and then understanding what UI interactions bring about specific changes in the DB.
I have this textbox in asp.net webform page used to enter a city. On entering some text it provides suggestions just like facebook does of matching results.
I tried these two methods to implement this.
I first used onTextChanged event and AJAX and found out it only works when the textbox loses focus. I wanted a solution to work as you type. Advantage of using this was that I could use a database and it would be fast, because no xml files will be transferred in the process.
2.I used ajax, clientside using js. But the problem is the xml containing cities, there states, country is a massive 30MB file. So, it was impossible to use it, so thought of making 26 small xml files of each alphabet out of that big one but still they would be big enough to actually use. So, now I am planning to use 26*26 files containing the cities with same first two alphabets but I think its ineffective way to do what I want.
Is there any other efficient way of accomplishing it?
The best way would be to use a database, if I could.
You need to use onkeypress and/or onkeyup events instead.
Did you know that there are plug-and-play auto-complete components out there that are free? For example http://jqueryui.com/demos/autocomplete/
Use JSON! It's much more compact. You'll probably save 30-40% on the size of that data.
Did you know that you don't need to pass the whole data set for that to work? You can have it live on the server (e.g. in the database, or cached on the webserver for faster access and less db traffic), and have clients only pull small set of data at a time, based on characters that they type. That JQuery UI AutoComplete supports that feature.
If you cannot use JQuery and JQuery UI (not wanting would be an unacceptable answer), then I'm pretty sure there are other free alternatives, including this one: http://www.asp.net/ajaxLibrary/AjaxControlToolkitSampleSite/AutoComplete/AutoComplete.aspx
I'm trying to get a high-level understanding of ASP.Net MVC, and it has started to occur to me that it looks a lot like the original ASP script. Back in the day, we were organizing our "model"/business logic code into VBScript classes, or into VB COM components.
Of course, now we have the additional power of c# and the .net framework classes. Besides the high-level oo and other capabilities in c# and .Net, what are the other major differences between the original ASP and ASP.Net MVC?
There are three main differences: URL mapping, separation of logic from presentation, and strong typing.
URL Mapping
With classic ASP there is a smooth transition from writing HTML pages to writing HTML pages with dynamic content. As with static HTML files, each URL has a direct mapping to a file in the filesystem. The same thing is more or less true of ASP.NET, for what it's worth.
In ASP.NET MVC, each "family" of URLs maps to a Controller object (stored in the /Controllers directory, by default), where each member of the family calls a method when accessed. At the end of each method (typically), you tell it to render a particular view (stored in a folder named after the controller in the /Views directory), which is a lot like a classic ASP page with all of the logic separated out.
This gives you logical and SEO-friendly URLs and groups related functionality together.
Separation of Logic from Presentation
In classic ASP it's common to find pages where a bit of HTML is included at the top, and then a database connection is opened and some things are read from the database while being output to the user, and then some more html, and then another database statement, and so on.
In ASP.NET MVC, your business logic (e.g. validation) goes in the model layer (you can choose from one of several dozen, but popular choices are LINQ-to-SQL and LINQ-to-Entity-Framework), your human interface logic goes in the controller (e.g. populating a State/Province menu based on the Country selection), and your presentation (the actual HTML you can hand to a designer to edit) goes in the view.
Aside from keeping things organized, this helps a great deal with being able to write automated tests for things. You can send a mocked-up object to your view and make sure it looks good, you can send bad data to your model and make sure it complains, and you can make sure that the object your controller sends out to your view is consistent with what it reads from the model.
Strong Typing and Compilation
ASP.NET is strongly typed and compiled. This is a double-edged sword. On the one hand, it will catch a lot of stupid programmer mistakes at compile time. On the other hand it, that means you're left with "infinity minus one" possible errors in your code (unit testing can make it infinity minus some larger number). Also, you'll have to do things like:
if (MyArray.Length > 0)
rather than
if (MyArray.Length)
But IMHO that's a small price to pay for the speed and sanity-checking you get from strong typing.
The bigger downside to compiled languages in a big framework is that deployment becomes much more of a production than it is with something like Classic ASP. You can't just copy a couple of files to the web server to update your app. You typically have to take the webserver down (hopefully you have a redundant pair) and recompile, which can take minutes.
ASP.NET MVC has a lot of plumbing infrastructure: for example, the routing engine which automatically invokes the right controller and action and can extract bits from the URL to pass as action arguments; or the convention-based location of views. It also provides more structure for passing data from the controller into the view (the ViewData object).
Also, crucially, MVC supports view engines. You can write raw HTML with helpers in it, but you can also use view engines like Web Forms, Spark, NHaml, etc. which allow you to write more concise view code, create reusable components (e.g. Web Forms controls), etc. This wasn't possible in ASP Classic.
Classic ASP used VBScript, which does not have classes. It's not object-oriented at all.
Very often with different technologies we can achieve the same
final result.
To create simple sites is almost irrelevant to the choice of technology.
But when you want to make a large complex site the presence or absence of a framework that allows to optimize the code, keep well organized and efficiently divide may play a role
crucial and greatly reduce the work.
ASP Classic does not achieve the same results reached by asp
net mvc.
If we omit the obvious differences between c # vb script I would say that the difference
main is that you can keep your code better organized.
As with classic ASP is very easy to make "spaghetti code and, with asp
mvc, on the contrary, it is very easy to keep everything tidy and separate the code
business logic from display.
Not only that.
Asp Net Mvc seamlessly integrates with technologies such as that EntityFramework
allow a further breakdown and organization of the code.
For many years I have had an objective of moving out of ASP/VBScript to a "better" language - my preference would be C# as I have skills in C - but I would consider other languages too (including PHP etc. so not just DotNet)
Objective is to have the code base in a language which does more for us. I hate the lack of data typing in VBScript, I would like a number of different "container objects" - rather than just a Dictionary Object, and so on - in fact I wonder why, having moved from Basic to C in the 80's, and then C++ a while after that, I managed to move "back" to Basic in to 00's.
(I could program the container objects in VBScript, but my instinct is that they would be slow in operation; we have a significant cache of "snippets" of HTML used in the rendering of the page, the ASP Application Object is a pretty blunt instrument!)
My ASP/VBScript is a single large application that is basically an "engine" to deliver web content.
It has been many years in the making, and now the ASP code changes seldom. (So I do need to justify moving it at all, or just living with VBScript "for ever")
It is driven from data in an MS SQL database.
There is only one .ASP page (made up of several include files).
Based on the query string parameters Skin and CMS templates for the page are loaded from database and suitable database Sprocs are run to acquire data which is merged into the CMS templates.
Data about the page (methods to use, etc.) is also retrieved from the database, along with details of access permissions and so on.
From what I have read some these things may make migration easier:
ASP sessions are not used - a session cookie is used to retrieve session data from the DB (so I could easily share a session half-and-half with ASPX
The VBScript uses OPTION EXPLICIT throughout, so all variables are predefined.
All output is via Response.Write (in fact most content is merged into a single variable and then output). There is no mix of HTML and <% server code %>.
I have some VBScript classes, but not many.
I have lots of VBScript functions, and a few Subroutines.
I have a test suite. This catches screen shots from the browser and graphically compares them with master images - thus I have the ability to do a regression test.
I don't have the resource to do a complete rewrite; maintenance of the existing code needs to continue during migration; but having said that 99% of our work is in CMS or SQL Sprocs, so the changes to ASP code are infrequent.
I have read of MS's utility to migrate ASP code to VB.NET. Given that my code is 100% VBScript and no mix of HTML/Script I would appreciate opinions on whether this would help me a lot or a little?
I would be happy to refactor STAYING IN VBscript with a view to making the migration to DotNet easier later on (but I'd need to know what my objectives were in doing that :) ). I could, for example, move some/all the functions to a COM object, and could probably do that piecemeal?
Thanks for your help
I have a large ASP classic intranet that I was maintaining until last year, and it was getting old, but new pieces were still being added in ASP classic because there was so much library code invested already. You already have a good setup if you are not changing the ASP code often and have some form of testing in place. (I have to admit it's the first time I have heard of the screenshot approach). If everything is driven off the DataBase and working. don't break it.
PHP will give you same problem of variant types, but will give you a world of options and choices that makes ASP classic seem like a childs toy. Out the box PHP does everything I've ever needed to do.
ASP.net is a BIG framework. Understanding it properly and fully is not an easy task, and it surprises me very often. it tries to do things for developers coming from a forms environment automatically that get very obtrusive when you come from a very precise rendering methodology like you sound you have. I found myself fighting the technology all the time, until ASP.net MVC came around. It fit my mind better because of how it worked and did what I asked it to, and nothing more. C# is an awesome language, with brilliant features and the DOT.net framework lets you do anything, if you can just find the right pieces. There is so much of it you will find yourself occasionally writing something that has been done in the framework already, only to find it just after finishing your own implementation.
Actually migrating could lead to some interesting problems. Even though you CAN run a ASP.net page much like an ASP classic page, you will loose many of the benefits of the environment as it is intended. That being said, I did do some test towards looking at migrating the site in question to ASP.net and managed to find ways around most of the stumbling blocks and reached the conclusion that such a migration would in fact be "mere work". The sheer quantity of man-hours it would take to do such a migration though made the undertaking infeasible.
Personally I would not suggest such a migration unless you have a few ASP.net projects under you belt successfully and are aware of the gotchas that asp.net brings with-it.
I have not seen the ASP to ASP.net conversion tool you speak of, but would love to get a link to it.
If you are staying in VBScript and are not aware of the AXE (ASP Xtreme Evolution) project here I can highly suggest looking into it for inspiration on getting past/around several of the ASP classic "limitations" and for the library of functionality it provides.
If you are looking for a way to justify the project to management, it will become increasingly more difficult to find classic ASP developers to continue maintaining the application. Any developer that has a choice would probably not choose to maintain an application built using VBScript. Developers that do take the job might consider it temporary and continue to look for other work.
Although I haven't heard anything from Microsoft, it can't be too many years before they decide to retire classic ASP entirely.
So I have our MVC web application up and running and we'd like to introduce printing into the solution. We have an interface (using SharePoint Service 3.0) that displays many files (all Word files) for a particular product. What we'd like to have happen is for the user to checkbox all the files they want to print, select a printer, and go at it.
The checkbox implementation is easy, I'm trying to think of a good print solution (if there is any). I'm looking for "out of the box" type solutions. One thing I was thinking about was creating a web service on SharePoint that takes all the files selected, merges them (somehow), and temporarily posts one big doc that, when finished, the client will print, and then the document gets purged. Not exactly the fastest operation but seems like it could work.
What's your thoughts on an implementation?
What kind of Doc Files do you have?
Are they already in the DocX format?
If so you can merge them quite easy with the documentAPI