I've been using config transformations a lot, but I'm struggling with one bit: the changing of "inner text" as opposed to attributes.
As an example, I've got the following in a config file (Sitecore's webforms for marketers if anyone's interested):
<param desc="connection string">Database=sitecore_webforms;Data Source=CHANGEME;user id=CHANGEME;password=CHANGEME;Connect Timeout=30</param>
and I want to change it to the proper connection string. Usually that would be part of an attribute which I can do fine but in this case it's not.
Is this possible using either the "vanilla" transformations or Sayed Ibrahim Hashimi's SlowCheetah?
You need to use the Replace transform. In your case, something like
<param desc="connection string" xdt:Transform="Replace">new connection string here</param>
You'll need to also add the right xdt:Locator attribute, to select the element.
I have an inputText component on a custom control and I am trying to bind the value to a viewScope, but the viewScope name is computed using a compositeData value and string.
If I hardcode the value binding it works, for example:
value="${viewScope['BillingDate_From']}"
The viewScope name is computed using the following javascript code:
compositeData.dateRangeFilter[0].from_fieldname + '_From'
I have tried many ways of achieving this but with no success, sometimes it errors, usually unexpected character errors but most of the time the inputText box is empty.
The code I have most recently tried:
value="${viewScope[#{javascript:compositeData.dateRangeFilter[0].from_fieldname + '_From'}]}"
I have found, and I don't know the reason for this, that trying to bind dynamically doesn't work if there's any string concatenation in the evaluation. The way I got around this was by creating a custom control that accepts a bindingValue and dataSource as parameters, then passing in the document and field name I want to use. For whatever reason, if the code uses composite data, it still allows for editing when the page loads.
Hi try this to build what you need:
The Control:
<xp:inputText id="inputText1">
<xp:this.value><![CDATA[${javascript:"#{"+compositeData.scopeName+"}";}]]></xp:this.value>
</xp:inputText>
<xp:text escape="true" id="computedField1">
<xp:this.value><![CDATA[${javascript:"#{"+compositeData.scopeName+"}";}]]></xp:this.value>
</xp:text>
The XPage using the Control:
<xc:cc id="xx">
<xc:this.scopeName><![CDATA[#{javascript:return "viewScope." + " calculatedScopeVarName";}]]></xc:this.scopeName>
</xc:cc>
<xp:button value="Beschriftung" id="button1">
<xp:eventHandler event="onclick" submit="true"
refreshMode="partial" refreshId="xx">
<xp:this.action><![CDATA[#{javascript://}]]></xp:this.action>
</xp:eventHandler>
</xp:button>
Instead of "viewScope" you cant add session or another scope and instead of calculatedScopeVar you can enter the name of your var. But this has a limit, it only works if the calculatedScopeVar is accesable through the component onLoad. For example it will not work if you use this control in a Repeat control and try to use the repeated array as calculatedScopeVar.
I want to add an attribute to the dataset declared below whose value is the value of one of the field in the row.
So I want to add the id as shown below.
<root>
<Table id="GAS-405">
<apple>2009FA</apple>
<orange>3.00</orange>
<pear>BGPR</pear>
<banana>GAS-405</banana>
</Table>
</root>
This will help me identify the node later in my application.
Is this possible? Is this easier to do using XMLDocument?
Dim sdaFoo As SqlDataAdapter = New SqlDataAdapter("SELECT BLAH FROM BLAHBLAH", conn)
Dim dsFoo As DataSet = New DataSet()
dsFoo.DataSetName = "apple"
sdaFoo.Fill(dsFoo)
dsFoo.WriteXml("C:\Inetpub\wwwroot\foo.xml")
Dataset.WriteXml() is really a convenience method rather than a flexible way of dealing with XML.
You'll need to take another approach. There are a few options:
If you're just adding a single attribute, you could hack it into the resulting xml by re-opening the file as an XDocument, adding the attribute to the necessary element, and saving it again. Not too elegant, but easy, and sometimes easy is best. Even better, just use WriteXml() to put your xml into a string, then load the string as your XDocument.
Generate the XML from your query directly, rather than as a dataset. Sql Server 2005 and 2008 have some good XML methods that allow you to select a set of rows as XML (SELECT ... FOR XML) and specify what it looks like.
Use XmlSerialization for your dataset and inject the attribute using custom control of the serialization process.... which will be way more trouble than it's worth.
Store the attribute somewhere else outside of your XML and use some kind of object to keep track of it. Not really sure what your code is like, but that might be a great option.
Use GetXML() method of DataSet to get whole XML as a string. Then add your custom attributes and write that string into xml file using StreamWriter.
I am using a control for a popup calendar date picker. This uses a javascript function, SetText, to set the textbox to the given date. I can't change anything in the calendar control itself but I can override the SetText function. The SetText javascript just takes the TextBox name and the date value in string format and sets the TextBox to the string.
The problem:
I need to display the date in the format "April 30".
Easy to do. Use getMonth() and getDate() where I can parse the information from there.
Now, I need to make sure this shows correctly for different cultures. For example, the UK shows dates as "30 April". Since the code-behind(c#) could be sending the date in the UK format how do I know in the javascript that they're using UK(dd/mm/yyyy) and not US(mm/dd/yyyy)?
The browsers navigator language could be set to one setting while the server is set to another to cause a January 4 as April 1 mismatch.
You are using the Microsoft Ajax Framework, this framework defines a set of "client-side type extensions" which provide added functions or "extensions" to the JavaScript base types.
The Date Type Extensions is what you're looking for, specifically the Date.parseLocale function.
With this function you can parse a string, using a given format.
You can synchronize your server-side and client-side culture by setting the ScriptManager.EnableScriptGlobalization property to true, and use the Date.parseLocale function without specifying any format.
Give a look to this article:
Walkthrough: Globalizing a Date by Using Client Script
See toLocaleString and related functions.
If you control the backend, why not just send a timestamp and push it into Date object?
As for formatting on the client side, since I was already using Dojo, I solved this problem by using dojo.date.locale.format. It was completely painless.
Locale is detected automatically or can be set arbitrarily.
Shorthand format options (e.g.: long short)
Data selectors (e.g.: time, date)
Ability to specify an arbitrary date/time pattern (probably not application to this application, but still useful).
Tutorial: http://docs.dojocampus.org/dojo/date/locale
API doc:
http://api.dojotoolkit.org/jsdoc/1.3/dojo.date.locale.format
Date format descriptions: http://www.unicode.org/reports/tr35/tr35-4.html#Date_Format_Patterns
Three things you could use:
1) toLocaleString - As suggested already. The problem with this is when sending a string of "4/1/2009" this can result in a couple things. January 4 or April 1.
2) navigator.language and navigator.systemLanguage - After you get the date string you can check to see what language the system is in and parse the date from there. The problem with this and solution 1 is what if you have a UK server and the browsers machine is US. You will have the code behind sending April 1 as 1/4/2009 where the javascript will read the string as whatever language the clients browsers is. So, UK server and US browser will give you a wrong result.
3) Use Code Behinds Culture - Create a variable in your javascript that when the page loads, it will call a function in your code behind that returns this.Page.Culture from there, you will know what culture the string is being sent back as. This will eliminate the mismatch that the first two solutions can cause. It will take a little extra work to make sure it's displayed correctly but at least you will be able to use the string without having the possibility of mismatching cultures.
toLocaleDateString would be a better solution than toLocaleString for your problem as it doesn't include the time (as you only are requesting the date).
The open-source JavaScript library Date.js has some great methods for formatting dates, as well as it supports a bunch of languages:
Date.js at Google Code: http://code.google.com/p/datejs/
If you want nicely formatted dates / times, you can just pass a formatting string (nearly identical to those used in .NET Framework) into any Date object's .toString() method.
It also has a whole set of cultures which allow you to simply include the appropriate script for that culture.
If you want to manage that yourself (as we do in our apps), you can find resources which give you the list of appropriate resource strings for a given culture. Here's one that shows proper formatting strings for a ton of cultures: http://www.transactor.com/misc/ranges.html
As you are using ASP.NET then you may also be using ASP.NET Ajax. If so, there are two properties on the ScriptManager that are of use to you:
EnableScriptLocalization - Gets or sets a value that indicates whether the ScriptManager control renders localized versions of script files.
EnableScriptGlobalization - Gets or sets a value that indicates whether the ScriptManager control renders script that supports parsing and formatting of culture-specific information.
<asp:ScriptManager ID="AjaxManager" runat="Server" EnablePartialRendering="true"
EnableScriptGlobalization="true" EnableScriptLocalization="true" />
When you enable both of these (set to true) then ASP.NET Ajax extenders etc. should automatically be localised into the culture specified in web.config:
<configuration>
<system.web>
<globalization
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8"
culture="en-GB"
uiCulture="en-GB" />
</system.web>
</configuration>
For instance, setting this will localise the AjaxControlToolkit Calendar into your specificed culture.
Even if you are NOT using ASP.NET Ajax adding a ScriptManager and enabling localisation will give you a useful javascript variable called __cultureInfo that contains a JSON array of localised formate, such as currencies, dates etc.
"CalendarType":1,"Eras":[1],"TwoDigitYearMax":2029,"IsReadOnly":true},"DateSeparator":"/","FirstDayOfWeek":1,"CalendarWeekRule":0,"FullDateTimePattern":"dd MMMM yyyy HH:mm:ss","LongDatePattern":"dd MMMM yyyy","LongTimePattern":"HH:mm:ss","MonthDayPattern":"dd MMMM","PMDesignator":"PM","RFC1123Pattern":"ddd, dd MMM yyyy HH\u0027:\u0027mm\u0027:\u0027ss etc....
I solved this problem by using Datejs as
In codebehind(aspx.cs) I get the culture for an employee and add the appropriate js to the header as
string path =
"http://datejs.googlecode.com/svn/trunk/build/date-"
+ GetCulture() + ".js"; Helper.AddJavaScript(this, path);
(in your case you can get the culture from navigator.systemLanguage (or navigator.browserLanguge etc) and add a script tag to the header with src attribute pointing to the appropriate path)
On the client-side I use
d.toString(Date.CultureInfo.formatPatterns.shortDate)
where d is any date object
(I tried using Date.today().toShortDateString() but it was throwing exception. (the CultureInfo JSON object had a different structure than what the function expects).
I have a simple struts2 from:
<s:form ...>
<s:textfield name="initialTime" maxlength="5" size="5" />
</s:form>
Where the user has to enter a time in HH:mm format. In the corresponding Action, I have a property:
private Date initialTime;
along with its getter/setter.
I am getting a validation problem, as the received initialTime (i.e. 10:20) is not understood as a valid Date.
What is the good approach to retrieve times ? Should I use a private String initialTime field instead of a Date ?
Thanks.
I think you'll have to change the property to a String and programatically transform it to whatever final format you want.
While I may see cases where the conversion from HH:mm to a Date may make sense, I think we can agree this is not a general scenario.
./alex