Dojo custom widgets can be internationalized via the _templated mixin following the steps outlined here and here. Then placeholders within the widget template like this: ${i18n.username} are automatically replaced with the appropriate language translation.
What is the simplest way to do similar nls language substitution outside of a widget? Ideally, I would like to add an attribute to a tag to have all the placeholders within substituted, including nested tags. Is there some type of container widget that already does this?
Or does Dojo development assume everything will be in a (custom) widget? I need to localize already existing code which doesn't use widgets.
The best solutions I have found so far are:
Using dojox.mobile.i18n, which is a "a thin wrapper around dojo.i18n, and has ability to replace strings, such as CDATA or attribute values, in dojo markup." However I'm afraid this is limited to a certain subset of mobile tags/widgets.
Disabling automatic parsing and manually searching/replacing the appropriate text before explicitly calling the parser in dojo.addOnLoad().
I assumed that the notation in the external html is ${i18n.username}.This will find any node that has class="i18nReplace" and replace the innerHTML of the node. I didn't test any of this, but I hope you can use it as a starting point.
dojo.require("dojo.i18n");
dojo.require("dojo.query");
dojo.requireLocalization("myI18n", "myI18N"); // This will need to be modified to get your i18n files
dojo.addOnLoad(function() {
var i18n = dojo.i18n.getLocalization("myI18n", "myI18N");
dojo.query(".i18nReplace").forEach(function(node, index, arr){
node.innerHTML = dojo.replace(node.innerHTML, { i18n: i18n } );
// blindly doing this, does not support nested tags.
// you could add conditional logic to check for children
// and if they exist separately process them, otherwise
// replace the html.
});
});
Related
I want to change features style according to in features style property. But style is not in properties. A sample feature is like that,
{
type:"feature",
style:{polygon:{"line-color":"#FF0000"}},
properties:{...},
geometry:{...}
}
So, according to documents 'get' expression does not work. Because, it looks for property section Document Mapbox Expressions.
I was wondering, are there any method to get information from style section in the features?
No, in a style, there is no way to access any part of an object other than in the properties section. (The one exception to this is the id property).
You will need to process your data differently.
I am using EditorTemplates to style all my input fields. Works like a charm, however now I want two themes of EditorTemplates, one for normal forms, and then one for my wizard forms.
I am already using an overloaded Html.BeginWizardForm() around those Html.EditorFor - but how do I make the MVC logic react on being inside Html.BeginWizardForm() ?
EditorTemplates are designed to be somewhat global. You can override them, though, just like any other view, because they are just views. For example, assuming you have something like Views\Shared\EditorTemplates\String.cshtml, you can then create a another view at Views\Foo\EditorTemplates\String.cshtml, and for any action called from FooController, the latter editor template will be used instead of the one from Shared. You might be able to make this work in your scenario if the wizard form is used in a specific controller or area context.
Short of that, though, there's no way to have this occur automatically. Some manual options still exist, though.
You can decorate the properties of the view model used within the context of the wizard with UIHint attributes. For example, assuming the same shared editor template above, you could do something like:
[UIHint("WizardString")]
public string Foo { get; set; }
That would cause it to look for Views\Shared\EditorTemplates\WizardString.cshtml instead.
You can pass the editor template to use in the call to EditorFor:
#Html.EditorFor(m => m.Foo, "WizardString")
All that said, the biggest problem here is that you seem to be violating a pretty core principal of good web design. HTML is about structure, not presentation. CSS is for presentation. As a result, if you want something to look different in a certain context, the correct approach is to apply different CSS. If things are designed well, your HTML shouldn't really have to change.
It seems is as stated by Chris Pratt not possible to have multiple EditorTemplates.
I however found a workaround by extending the MvcForm and created a WizardForm which adds a value to the ViewContext (in my case "wizardContext" => true) and on disposing setting wizardContext => false.
This allows me in the EditorTemplates to add a check for if I am inside or outside the wizardContext, which will propagate through the nested EditorFor, and in this way allow me to have different themes, without having to be specific in EditorFor.
I am trying to integrate CKEditor into an internal PHP application, where in the past I was just pasting my HTML into a textarea field in a form.
This HTML that I am submitting in the form is for a custom template system that uses custom tags. These custom tags would then be replaced with real data by my backend. For example, an invoice would have the custom tag <%INVOICE#%>, which my backend would replace with the correct invoice number.
When using CKEditor, these types of tags are being converted into htmlentities such as <%INVOICE#>, which breaks my string replacement on the backend.
Is there a way to make CKEditor recognize tags that are in the format <%*%> and not convert them in any way?
The simplest way to protect those tags against modifications would be to use config.protectedSource. With Show Protected plugin (3rd party addon), you could even see the protected code in wysiwyg area.
A more user friendly solution would be to adopt the widget-based Placeholder plugin to recognize the syntax you use for custom tags. This plugin is just a proof of concept solution, so you can improve it in any way you like. E.g. by offering a select element to the end user with the list of valid placeholders instead of asking to type them manually.
Widgets are powerful, which means that it is technically possible to write even a plugin that returns <%INVOICE#%> in source code, but shows the real invoice number in wysiwyg area.
I have an application where I need to display metrics. The application needs to display a separate vertical section for each metric. When I started this, there were only 5 metrics so I naively created a template with 5 regions, one for each metric I needed to display. Now, new metrics need to be added and I want to avoid adding "hardcoded" region divs in the template. I want to refactor this and create the required regions dynamically at startup time based on some configuration data.
So I have been looking at the latest Marionette release and in question "Dynamically add regions to Marionette layout", Derick Bailey mentions that Marionette v1.0 supports dynamic regions in Layouts through addRegion(), as in:
var layout = new MyLayout();
layout.render()
layout.addRegion("someRegion", "#some-element");
layout.someRegion.show(new MyView());
I have tried that in my code (using Marionette 1.0.2) and I am not getting it to work. I don't have a div with id="some-element" in my template and I suspect this could be the reason. I was hoping that Marionette would create that div itself.
Perhaps my expectation of what dynamically adding a region means is wrong. So my first question is: when adding regions dynamically to a layout, must the element id passed in the addRegion() function already exist in the layout?
If so, then I am back to the problem of having to "burn" in the template those divs for the regions to attach themselves too. My follow-up question is then: What is the best way of doing this in a data-driven fashion? Is it a matter of writing my own render() function so that the right set of divs get created? Or perhaps providing my Layout with a model object that will contain data which the template can then iterate through to create the necessary divs? How do we add regions dynamically to a Layout object if we don't know in advance how many regions we will actually need?
Aa #aaronfay specified, we need to use jQuery to create the element on the page. Here is some sample code:
var layout = new MyLayout();
layout.render()
var regionName = "dynamicRegion";
layout.$el.append('<div id="'+regionName+'"></div>');
layout.addRegion("someRegion", "#"+regionName);
layout.someRegion.show(new MyView());
I believe you would need to use jQuery (or similar) to create the element on the page. A Region expects the element to exist.
Otherwise, I believe your answer is here.
Is there a way to use a different styles, or redefine a style, based on a report parameter locale? I need to modify font sizes for certain languages.
I have implemented this in the past using external style templates. There is a sample on jasperforge that illustrates how to do this.
Once you've moved your styles to external templates, you can create locale specific templates. The templating mechanism allows you to inherit from and override specific styles, so the locale specific versions don't get overly bloated. The example I linked above includes inheriting from and overriding base styles.
In your reports, you can then load the appropriate template at render time.
One easy way to do this is:
provide the path to the template that you want to use as a parameter
to the report
include a template tag in the jrxml file that references the
parameter:
<template><![CDATA[$P{TEMPLATE_PATH}]]></template>
Then, in the code that renders the report, just set the TEMPLATE_PATH parameter appropriately for the report locale.
Again, the linked documentation mentions how to do this.