Tapestry provides a great localization support for their pages and components.
I would like to send localized e-mail corresponding to the users language preference.
Anybody has come across a solution for localizing e-mail templates that integrates well with Tapestry?
(I don't mind if it is a not using Tapestry's templating engine)
I have created a separate directory/package for each language and retrieve the template file. And then used ThreadLocale..getLocale().getLanguage() to retrieve the current user's so I can send the e-mail on that language too.
Here is the relevant code snippet:
public class MailSender {
private static final String EMAIL_TEMPLATE_ROOT = "com/xxx/emailtemplate/";
#Inject
private ThreadLocale locale;
public void sendEmail(..., final String emailTemplateFileName) {
String emailTemplateFilePath = getEmailTemplateFilePath(emailTemplateFileName);
....
}
private String getEmailTemplateFilePath(String templateLocation) {
String language = locale.getLocale().getLanguage();
return EMAIL_TEMPLATE_ROOT + language + "/" + templateLocation;
}
}
This is not specific to a templating engine. You can use this technique with your favourite. (I kept Velocity as it was used by the project already)
Related
Most times when using DevEx MVC extensions, I find myself having to use repetitive code to generate the controls/layouts that I use on a regular basis. For example, I tend to prefer left-aligned captions to controls. Ideally, I'd be able to do something like this and have it "just work":
#Html.DevExpress().TextBoxFor(m => m.Notes).GetHtml()
However, in order to place the caption on the left, I need to also pass in a settings object for it, or dome something much more verbose such as:
#Html.DevExpress().TextBox(
s => {
// ...
s.Properties.CaptionCellStyle.Width = 100;
// ...
}
).Bind(Model.Notes).GetHtml()
What I thought to do was create my own set of extensions that would wrap the DevEx extensions, giving me some sort of common/core customization layer, so I could do something like this:
#Html.MyComponents().TextBoxFor(m => m.Notes)
This call would in turn call the DevExpress TextBoxExtension with a common set of settings and output the DevEx textbox as desired.
I've worked this up via custom html extensions (code below), but have two issues with this basic implementation:
The control renders at the very top of the Body element, not at the position in which it's placed in the view, and
There's a JavaScript error "ASPxClientTextBox" is not defined (this is part of the client-side scripting that DevEx uses with their controls).
I was hoping this would be an easy "wrap it and go" type of scenario. Is there some basic concept of these custom HTML extensions that I'm missing? Or does anyone know if this is a general limitation in trying to wrap another company's pre-existing extensions?
Here's the code I have implemented (which is not yet fully fleshed out, just trying for proof of concept here):
public static class HtmlHelpers
{
public static MyComponentsHtmlHelpers<TModel> MyComponents<TModel>(this HtmlHelper<TModel> html) {
return new MyComponentsHtmlHelpers<TModel>(html);
}
}
public class MyComponentsHtmlHelpers<TModel>
{
private HtmlHelper<TModel> html;
public MyComponentsHtmlHelpers(HtmlHelper<TModel> html) {
this.html = html;
}
public MvcHtmlString TextBoxFor<TValue>(Expression<Func<TModel, TValue>> expression) {
var data = ModelMetadata.FromLambdaExpression(expression, html.ViewData);
string propertyName = data.PropertyName;
System.Diagnostics.Debug.WriteLine("PROPERTY NAME: " + propertyName);
TextBoxSettings s = new TextBoxSettings();
s.Name = "textbox_" + propertyName;
s.Properties.Caption = propertyName;
s.Properties.CaptionCellStyle.Width = 100;
TextBoxExtension tb = new TextBoxExtension(s);
return tb.GetHtml();
}
}
Nevermind - cleaning the solution and rebuilding as well as force refreshing the test browser a few times and ensure there's no cache and... now everything works as intended.
(not sure if I ought to delete this question or leave it around in case someone wants to attempt the same... I'll leave it for now, feel free to remove)
I am using .LESS variables in my files. I have a LessTransform in my Bundler, which allows all my .less to see the variables. But when I turn bundling off, obviously it no longer works!
Can I see just a single bundle to always be bundled? (even when compilation debug=true)
Unfortunately it's an all or nothing setup (determined very early on by AssetManager.DeterminePathsToRender which, based on EnableOptimizations, either emits a bundle URL or individual script paths).
You could look into using the WebEssentials extension which handles .less (as well as other) files natively. At least then you'll be able to include the compiled version and let you move onto more important matters. Once you've finalized, you can bring bundling back into the equation.
I do not work on/for WebEssentials, I just find the extension very helpful
In the main application that I work with, we use the DotLess compiler directly to serve our stylesheets.
We store custom .LESS variables in the database and combine them with the .less file on the fly.
using System.Web.Mvc;
using dotless.Core;
using System.Web.Helpers;
public class SkinController : Controller
{
private const int TwentyMinutes = 1200;
[OutputCache(Duration = TwentyMinutes, VaryByParam = "*", VaryByContentEncoding = "gzip;deflate", VaryByCustom = "Scheme")]
public ActionResult Index()
{
string variablesFromDatabase = "these came from the database";
string lessFileContents = "this was read from the disk";
string content = Less.Parse(string.Concat(variablesFromDatabase, lessFileContents));
SetEtag(content);
return Content(content, "text/css");
}
private void SetEtag(string content)
{
string acceptEncoding = Request.Headers["Accept-Encoding"];
string value = string.Concat(content, acceptEncoding);
Response.AppendHeader("etag", string.Format("\"{0}\"", Crypto.Hash(value, "md5")));
}
}
We are using Tapestry 5.4-beta-4. My problem is:
I need to keep files with locale data in an external location and under different file name then tapestry usual app.properties or pageName_locale.properties. Those files pool messages that should be then used on all pages as required (so no tapestry usual one_page-one_message_file). The files are retrieved and loaded into tapestry during application startup. Currently i am doing it like this:
#Contribute(ComponentMessagesSource.class)
public void contributeComponentMessagesSource(OrderedConfiguration<Resource> configuration, List<String> localeFiles, List<String> languages) {
for(String language: languages){
for(String fileName : localeFiles){
String localeFileName = fileName + "_" + language + ".properties";
Resource resource = new Resource(localeFileName );
configuration.add(localeFileName, resource, "before:AppCatalog");
}
}
}
The above code works in that the message object injected into pages is populated with all the messages. Unfortunatly these are only the messages that are in the default ( first on the tapestry.supported-locales list) locale. This never changes.
We want the locale to be set to the browser locale, send to the service in the header. This works for those messages passed to tapestry in the traditional way (through app.properties) but not for those set in the above code. Actually, if the browser language changes, the Messages object changes too but only those keys that were in the app.properties are assigned new values. Keys that were from external files always have the default values.
My guess is that tapestry doesn't know which keys from Messages object it should refresh (the keys from external files ale not beeing linked to any page).
Is there some way that this could be solved with us keeping the current file structure?
I think the problem is that you add the language (locale) to the file name that you contribute to ComponentMessagesSource.
For example if you contribute
example_de.properties
Tapestry tries to load
example_de_<locale>.properties
If that file does not exist, it will fall back to the original file (i.e. example_de.properties).
Instead you should contribute
example.properties
and Tapestry will add the language to the file name automatically (see MessagesSourceImpl.findBundleProperties() for actual implementation).
#Contribute(ComponentMessagesSource.class)
public void contributeComponentMessagesSource(OrderedConfiguration<Resource> configuration, List<String> localeFiles, List<String> languages) {
for(String language: languages){
for(String fileName : localeFiles){
String localeFileName = fileName + ".properties";
Resource resource = new Resource(localeFileName );
configuration.add(localeFileName, resource, "before:AppCatalog");
}
}
}
I'm currently working on ASP.NET MVC application. I'm planning to create a static class where I plan to hold all the global string constants like session names.
The reason I'm hesitant is because it's kind of smell but I'm not aware of better alternative.
Please show me the light how to define global constants.
vadim,
i do exactly as you propose and use a static class for this purpose. You then get the advantage of strongly typed accessors PLUS the ability to add overrides (in the form of methods), should you require them.
here's a snippet:
public static class Config
{
private const string NotSet = "**VALUE NOT SET**";
private const int pageSize = 5;
public static string CustomCache
{
get
{
return ConfigurationManager.AppSettings["CustomCache"] ?? NotSet;
}
}
public static int PageSize
{
get
{
// simple default - no setter
return pageSize;
}
}
}
typical usage:
items = _repository.GetPaged(pageNumber, Config.PageSize)
in the above class, some settings are called '2nd generation' from the app settings in the web.config but with strong typing in the classes to ensure runtime error checking etc.. others are purely static settings defined in the class.
it's the flexibility to do all of the above that (in my opinion) gives this approach both appeal and a real strength.
Another alternative would be to create a resources (.resx) file. Or if these are configurable values, they can go in web.config or a database configuration table.
Whether it is MVC or Web forms, I use a combination of database entries (for site settings that can be modified by dashboard) and web.config appSettings (for site settings that do not change often or at all, i.e. constant).
You can use global.asax file for this purpose - I would use accessors for them e.g.
private static int var ;
public static int VAR
{
get { return var ; }
}
I'm working on a biztalk project and use a map to create the new message.
Now i want to map a datefield to a string.
I thought i can do it on this way with an Function Script with inline C#
public string convertDateTime(DateTime param)
{
return System.Xml.XmlConvert.ToString(param,ÿyyyMMdd");
}
But this doesn't work and i receive an error. How can i do the convert in the map?
It's a Biztalk 2006 project.
Without the details of the error you are seeing it is hard to be sure but I'm quite sure that your map is failing because all the parameters within the BizTalk XSLT engine are passed as strings1.
When I try to run something like the function you provided as inline C# I get the following error:
Object of type 'System.String' cannot be converted to type 'System.DateTime'
Replace your inline C# with something like the following:
public string ConvertDateTime(string param1)
{
DateTime inputDate = DateTime.Parse(param1);
return inputDate.ToString("yyyyMMdd");
}
Note that the parameter type is now string, and you can then convert that to a DateTime and perform your string format.
As other answers have suggested, it may be better to put this helper method into an external class - that way you can get your code under test to deal with edge cases, and you also get some reuse.
1 The fact that all parameters in the BizTalk XSLT are strings can be the source of a lot of gotchas - one other common one is with math calculations. If you return numeric values from your scripting functoids BizTalk will helpfully convert them to strings to map them to the outbound schema but will not so helpfully perform some very random rounding on the resulting values. Converting the return values to strings yourself within the C# will remove this risk and give you the expected results.
If you're using the mapper, you just need a Scripting Functiod (yes, using inline C#) and you should be able to do:
public string convertDateTime(DateTime param)
{
return(param.ToString("YYYYMMdd");
}
As far as I know, you don't need to call the System.Xml namespace in anyway.
I'd suggest
public static string DateToString(DateTime dateValue)
{
return String.Format("{0:yyyyMMdd}", dateValue);
}
You could also create a external Lib which would provide more flexibility and reusability:
public static string DateToString(DateTime dateValue, string formatPicture)
{
string format = formatPicture;
if (IsNullOrEmptyString(formatPicture)
{
format = "{0:yyyyMMdd}";
}
return String.Format(format, dateValue);
}
public static string DateToString(DateTime dateValue)
{
return DateToString(dateValue, null);
}
I tend to move every function I use twice inside an inline script into an external lib. Iit will give you well tested code for all edge cases your data may provide because it's eays to create tests for these external lib functions whereas it's hard to do good testing on inline scripts in maps.
This blog will solve your problem.
http://biztalkorchestration.blogspot.in/2014/07/convert-datetime-format-to-string-in.html?view=sidebar
Regards,
AboorvaRaja
Bangalore
+918123339872
Given that maps in BizTalk are implemented as XSL stylesheets, when passing data into a msxsl scripting function, note that the data will be one of types in the Equivalent .NET Framework Class (Types) from this table here. You'll note that System.DateTime isn't on the list.
For parsing of xs:dateTimes, I've generally obtained the /text() node and then parse the parameter from System.String:
<CreateDate>
<xsl:value-of select="userCSharp:GetDateyyyyMMdd(string(s0:StatusIdChangeDate/text()))" />
</CreateDate>
And then the C# script
<msxsl:script language="C#" implements-prefix="userCSharp">
<![CDATA[
public System.String GetDateyyyyMMdd(System.String p_DateTime)
{
return System.DateTime.Parse(p_DateTime).ToString("yyyyMMdd");
}
]]>