I just began working with ASP.NET and I'm trying to bring with me some coding standards I find healthy. Among such standards there is the multilingual support and the use of resources for easily handling future changes.
Back when I used to code desktop applications, every text had to be translated, so it was a common practice to have the language files for every languages I would want to offer to the customers. In those files I would map every single text, from button labels to error messages. In ASP.NET, with the help of Visual Studio, I have the resort of using the IDE to generate such Resource Files (from Tools -> Generate Local Resource), but then I would have to fill my webpages with labels - at least that is what I've learned from articles and tutorials. However, such approach looks a bit odd and I'm tempted to guess it doesn't smell that good as well. Now to the question:
Should I keep every single text in my website as labels and manage its contents in the resource files? It looks/feels odd especially when considering a text with several paragraphs.
Whenever I add/remove something, e.g.: a button, to an aspx file I would have to add it to the resource file as well, because generating the resource file again would simply override all my previous changes to it. That doesn't feel like a reusable code at all for me.
Perhaps I got it all wrong from tutorials as it doesn't seem like a standardized matter - specially if it required recompiling the entire application whenever some change has to be done.
Best practices for ASP.NET Web Forms localization have not really changed much over the years. If you don't have much dynamic content then you can get away with implicit localization and bind web forms controls (form elements and yes, even labels) to resource files. Explicit localization is useful if you want a bit more control over where localized text is rendered in a control with multiple captions or something you've created yourself. You don't need to look very far for instructional steps from MS on how to do either of these.
Walkthrough: Using Resources for Localization with ASP.NET
If your localization requirements are more dynamic, for example, you want to easily provision new languages, centralize resources, or you need to provision new string captions on a new dimension (like per client), then you need to get a bit more creative. .NET allows you to extend the
the resource provider and you can implement a database backend that allows for easy administration of localized resources.
Extending the ASP.NET 2.0 Resource-Provider Model, Building a Database Resource Provider
Extending Resource-Provider for storing resources in the database * A more recent implementation
Or you could just roll your own!
I've also dug up a duplicate SO post. It's a few years old, but speaking from experience I believe the advice found on the referenced code project page are still true (for Web Forms): Globalization and localization demystified in ASP.NET 2.0
I hope that helps! If you have any more specific questions regarding localization please add them to your Questions or comments.
I have been doing dynamic PDF creation via ASP.net for some time -- in the form of HTML to PDF conversion. It works well for us, but we have accessibility requirements from the State to make everything is accessible. For static PDFs, we simply "tag" the files manually using Adobe's accessibility tools. Of course this does not work for dynamically created files. PDFs that I create dynamically fail the Acrobat Pro Accessibility test.
Does anyone have any ideas about create PDFs dynamically in ASP.net, but producing PDFs that are tagged and can pass the Adobe Accessiblity test? I have researched many components, but none that I have found support tagging.
Thanks.
I would look seriously at iText. AFAIK, this is the definitive library for creating dynamic PDF's, for Java and .NET.
You will need the book iText in Action.
Here's a quote from iText in Action on accessibility:
"You can use iText to create a document that passes all the criteria that are listed in Section 508."
I have recently been investigating methods of creating web-based forms for an ASP.NET web application that can be edited and managed at runtime. For example an administrator might wish to add a new validation rule or a new set of fields.
The holy grail would provide a means of specifying a form along with (potentially very complex) arbitrary validation rules, and allocation of data sources for each field. The specification would then be used to update the deployed form in the web application which would then validate submissions both on the client side and on the server side.
My investigations led me to Xforms and a number of technologies that support it. One solution appears to be IBM Lotus Forms, but this requires a very large investment in terms of infrastructure, which makes it infeasible, although the forms designer may be useful as a stand-alone tool for creating the forms. I have also discounted browser plug-ins as the form must be publicly visible and cross-browser compliant.
I have noticed that there are numerous javascript libraries that provide client side implementations given an Xforms schema. These would provide a partial solution but server side validation is still a requirement.
Another option seems to involve the use of server side solutions such as the Java application Orbeon. Orbeon provides a tool for specifying the forms (although not as rich as Lotus Forms Designer), but the most interesting point is that it can translate an XForms schema into an XHTML form complete with validation. The fact that it is written in Java is not a big problem if it is possible to integrate with the existing ASP.NET application.
So my question is whether anyone has done this before. It sounds like a problem that should have been solved but is inherently very complex. It seems possible to use an off-the-shelf tool to design the form and export it to an Xforms schema and xhtml form, and it seems possible to take that xforms schema and form and publish it using a client side library. What seems to be difficult is providing a means of validating the form submission on the server side and integrating the process nicely with .NET (although it seems the .NET community doesn't involve themselves with XForms; please correct me if I'm wrong on this count).
I would be more than happy if a product provided something simple like a web service that could validate a submission against a schema. Maybe Orbeon does this but I'd be grateful if somebody in the know could point me in the right direction before I research it further.
Many thanks.
I'm probably missing something but...
The way I've done this sort of thing in the pass is to create a schema for form declaration & an xslt to convert that xml to html. You can then add all sorts of validation, based on the xml schema you've designed. What I am usually missing is the form designer though.
You can use XHTML for the forms, or like Simon suggested, a custom language as an abstraction layer. The application can load the form at runtime, transform/style it and serve it to the user. You can edit the form and make changes without the need to recompile/redeploy.
For validation you can use Schematron, this can also be easily edited at runtime using XML-aware tools.
You can use Javascript to produce XML data in the browser, or you can transform application/x-www-form-urlencoded to XML on the server (that is what I do on this page).
I want to implement rich reporting features in one of our asp.net mvc based web applications. The required features in the reports are
Graphs
Charts
Grouping, sub totals, page breaking, etc
Ability to export to excel, pdf, csv and other formats
Printing Support
We are ready to purchase commercial controls(if free ones are not available). Please suggest us the best of available options.
I do not know what rich reporting packages are out there that are 100% ASP.NET MVC-driven. I've seen a few talk about MVC.
But technically, you don't need an MVC-version of reporting controls. ASP.NET MVC allows you to use standard ASP.NET functions, such as WebForms, postbacks, server controls, etc. This is easy as a drop-in-place solution because ASP.NET MVC's default Convention-over-Configuration programming checks to see if a directory or file exists first, before being routed through the controller logic.
So, if there are no Asp.Net Mvc versions of graphs and charts you like - then fear not, you can fall back to the ones you've used for your previous asp.net forms projects. Even though I recommend sticking it into a dedicated directory (i.e. /reports) to keep a clean website.
I suggest you try and use a regular web form for the reports, with graphic, charts, and any other ontrol you might need. MVC views and web forms can live in the same project, noting wrong with that. At least until you find a way to do it using a MVC view.
In my own opinion, you don't have to do everything MVC in a project, you are "allowed" to do whatever you need to do to make your application work the way you want to.
You can use the asp.net chart control which is free to download and supported with ASP.net MVC
I found this while searching for something similar.
http://www.componentsource.com/products/syncfusion-essential-studio-aspnet-mvc/index-gbp.html
I haven't used it though. There is a trial download.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?