Running Titanium Apps from the Command Line

To run a Titanium app using a command line script as opposed to starting it up through the Titanium Developer App, we placed the following in a file named run.sh inside our app’s directory.

export PATH=$PATH:/Library/Application\ Support/Titanium/sdk/osx/0.6.0/
tibuild.py -d . -s /Library/Application\ Support/Titanium -r -a /Library/Application\ Support/Titanium/sdk/osx/0.6.0 ./

The tibuild.py does our work for us and running ./run.sh from the command line starts our app up without having to open the Titanium Developer App.

Logging

This is a short blurb on the difference between Titanium logging and Firebug’s logging. At the top of our Javascript file we have the following try/catch statement to setup our log var.

try {
    var log = Titanium.App.stdout; // Titanium's logging to the command line
} catch (squash) {
    var log = console.log; // console logging for Webkit/Firebug
}

The try/catch is an easy way to ensure we have the right logging for the right environment. We want TItanium logging when running Titanium and console.log as the default.
Calling logging is simple from this point:

 log('HELLO!');

Technorati Tags: DATA series, logging, PushToTest, titanium

Opening an XML file dialog in Titanium

The props variable specifies that only xml files will be highlighted and accepted in the file dialog. In order to highlight and accept all file types, just make props and empty array: var props = {};

var props = {multiple:false,types:['xml']};
Titanium.UI.openFileChooserDialog(function(filenames) {
	if (filenames[0]){
		Editor.load_file(filenames[0]);
	}
},props);

Reading an XML file

Here are the ways to read an xml (or any) file using both jQuery and Titanium. In both examples, lambda represents a function pointer.

jQuery

	$.get(filename,lambda);

Titanium

	var f = Titanium.Filesystem.getFile(filename);
	var xml = ""+f.read();
	lambda(xml);

Writing an XML file

This of course can only be done with Titanium. Below is how we formatted the xml to pretty print the xml string before writing out to the file. The raw xml string doesn’t lay out nicely so we have to add some spacing.

formatXml: function(xml, lambda) {
    var formatted = '';
    var reg = /(>)(<)(\/*)/g;
    xml = xml.replace(reg, '$1\r\n$2$3');
    var pad = 0;
    jQuery.each(xml.split('\r\n'), function(index, node) {
        var indent = 0;
        if (node.match( /.+<\/\w[^>]*>$/ )) {
            indent = 0;
        } else if (node.match( /^<\/\w/ )) {
            if (pad != 0) {
                pad -= 1;
            }
        } else if (node.match( /^<\w[^>]*[^\/]>.*$/ )) {
            indent = 1;
		} else {
            indent = 0;
		}
 
        var padding = '';
        for (var i = 0; i < pad; i++) {
            padding += '  ';
		}
 
        formatted += padding + node + '\r\n';
        pad += indent;
	});
    lambda(formatted);
},

Below is the code that actually writes out to the filesystem. If the file represented by the filename already exists, the write simply overwrites it. If the file doesn’t exist, a new one with that filename is created. Because of the way we had to parse the xml read in, it was necessary to tack on the the xml header.

try {
	var TFS = Titanium.Filesystem;
	var file = TFS.getFile(filename);
	Editor.formatXml(Editor.currentopenfile.filexml, function(xml) {
		header = '<?xml version="1.0" encoding="UTF-8"?>';
		file.write(header+xml);
		var contents = file.read();
	});
} catch (squash) {
	alert("Failed to write to File");
}

Technorati Tags: DATA series, File I/O, jQuery, PushToTest, titanium

The many ways to access the DOM with jQuery

In part 1 of this series, I ended the post with stating that I would follow up with how we accessed the DOM with jQuery and why we weren’t always using the best way to do it. Given more time, we would likely have gone back and changed all methods of accessing the DOM to be consistent.
Below are 3 ways that we used to access the DOM. It is almost a chronological journey through how we figured out the different methods.
For this part, as I did in my last post, I’ll be using the PushToTest datasource as an example.

Here again is the html used to render a datasource.

<div id="datasources_iterator${id}" class="datasource_container">
	<input type="hidden" name="id" value="${id}" fieldset="datasource"/>
	<table cellpadding="0" cellspacing="0" border="0">
		<tr>
			<td>Name</td>
			<td><input type="text" name="name" value="${name}" fieldset="datasource" class="name"/></td>
			<td><input type="image" name="delete" value="${id}" src="images/cross.png" fieldset="datasource"/></td>
		</tr>
		<tr>
			<td>Type</td>
			<td>
				<select id="datatypeselect${id}" name="datatypeselect" fieldset="datasource">
				  	<option value="HashDPL">HashDPL</option>
				  	<option value="CSVDPL">CSVDPL</option>
				  	<option value="RDBMSDPL">RDBMSDPL</option>
				  	<option value="TheLocker">TheLocker</option>
				</select>
			</td>
		</tr>
		<tr>
			<td>Resource Name</td>
			<td><select id="rscname${id}" datasourceid="${id}" name="rscname" fieldset="datasource"></select> (From Resources)</td>
		</tr>
	</table>
</div>

The Unique ID Approach

The simplest way to manipulate the DOM with jQuery is using the id based method.
In the html we have datatypeselect drop down menus.

<select id="datatypeselect${id}" name="datatypeselect" fieldset="datasource">
  	<option value="HashDPL">HashDPL</option>
  	<option value="CSVDPL">CSVDPL</option>
  	<option value="RDBMSDPL">RDBMSDPL</option>
  	<option value="TheLocker">TheLocker</option>
</select>

For each individual datasource displayed, there is a datatypeselect drop down with a unique id associated with that element.
Here is the javascript to set the value of the datatypeselect for a given datasource object. This follows the method for populating the html we covered in part 1 of this series.

$("#datatypeselect"+datasource.id).val(datasource.datatypeselect);

The ‘#’ at the beginning of the selector signifies that we’re selecting based on the id attribute of the html element. The value is being set to the datasource object’s datatypeselect field.

The div ID Approach

This approach is similar to the Unique ID Approach, but instead of using the id for the particular element, we can use the id for a parent of this element. This forces us to only have a unique id at the parent level instead of a unique id for each individual html element.

The parent of the datatypeselect element in the html:

<div id="datasources_iterator${id}" class="datasource_container">

Here’s the javascript for this approach to accessing the datatypeselect element:

var divid = '#datasources_iterator'+datasource.id;
$(divid+ ' select[name=datatypeselect]').val(datasource.datatypeselect);

The Parent Selector Approach

This approach uses the same divid as the div ID Approach above but we pass the selector as an argument. Here we also use the fieldset attribute to give greater specificity to the jQuery selector.

$('select[name=datatypeselect][fieldset=datasource]', $(divid)).val(datasource.datatypeselect);

Ultimately we want to strip our html elements to the bare minimum of what we really need to access and manipulate their values and get away from using unique ids for each element.

Technorati Tags: DATA series, DOM manipulation, jQuery, PushToTest, titanium

As part of our work on the PushToTest TestMaker open source project, we ran into numerous issues and resolutions that we felt should be shared.

Some background on what we used:
- Appcelerator Titanium Developer
- Javascript
- jQuery 1.3.2
- jQuery template plugin
- jQuery scrollTo plugin
- ExtJS 3.0 rc 3

First Issue To Address

One of the key first issues we ran into was how to render the html using jQuery on the client side for the Titanium application without doing too much manual DOM manipulation. Also, since most of the information being rendered would be in arrays, it would preferably make displaying arrays easier.

The Solution

Our solution came in the form of the jQuery template plugin.
For our implementation, we created html code snippets that we placed in individual html files. Each html file would be loaded and be passed into the $.template method which would then be passed into a .append method along with an object whose values would be injected into the html.

The reason why templating and more specifically why breaking the html into snippets was necessary is almost entirely because we wanted to be able to iterate through multiple objects and display them the cleanest and most efficient way possible.

Example with the PushToTest Datasource

For an example I’ve lain out how we rendered the information for datasources. Datasources are objects that have names, types, and resource names.
First we created a datasources.hmtl page that will be a container for all the datasources rendered:

<div class="panelmessage">
Make this a data-driven test.
</div>
 
<div class="form">
	<div class="title">
		Data Production Libraries (DPLs) provide operational test data to the tests as they operate. For example, a DPL reads data from a relational database, comma-separated-value (CSV) file, or data generating object and injects it into a test script. <a id="ShowTutorials" name="ShowTutorials" class="link">Read more about it.</a>
	</div>
	<div id="datasources_iterator" style="display:none" class="">
	</div>
	<div class="adddatasource">
		<a id="adddatasource" name="adddatasource" class="link" dirty="true">Add DPL</a>
	</div>
</div>

Then, we created a _datasourcestemplate.html file with all the attributes for a datasource specified:

<div id="datasources_iterator${id}" class="datasource_container">
	<input type="hidden" name="id" value="${id}" fieldset="datasource"/>
	<table cellpadding="0" cellspacing="0" border="0">
		<tr>
			<td>Name</td>
			<td><input type="text" name="name" value="${name}" fieldset="datasource" class="name"/></td>
			<td><input type="image" name="delete" value="${id}" src="images/cross.png" fieldset="datasource"/></td>
		</tr>
		<tr>
			<td>Type</td>
			<td>
				<select id="datatypeselect${id}" name="datatypeselect" fieldset="datasource">
				  	<option value="HashDPL">HashDPL</option>
				  	<option value="CSVDPL">CSVDPL</option>
				  	<option value="RDBMSDPL">RDBMSDPL</option>
				  	<option value="TheLocker">TheLocker</option>
				</select>
			</td>
		</tr>
		<tr>
			<td>Resource Name</td>
			<td><select id="rscname${id}" datasourceid="${id}" name="rscname" fieldset="datasource"></select> (From Resources)</td>
		</tr>
	</table>
</div>

Then in the javascript we use this code to get that content and template it:

	$.get('content/_datasourcestemplate.html', function(html) {
        Editor.datasourcesTemplate = $.template(html);
    });
 
	for (var i=0;i<Editor.currentopenfile.datasources.length;i++) {
		var datasource = Editor.currentopenfile.datasources[i];
		$('#datasources_iterator').append(Editor.datasourcesTemplate, datasource);
	}

Using this method we were able to iterate through the datasource objects and inject them into the template, then append it to the datasources.html page.

Post implementation lessons

As you can see in the _datasourcestemplate.html code, we placed the datasource object’s id all over the place. Originally this was needed because of the way we were using jQuery to get values from the DOM. After doing some more research we found out better ways to gain access to the DOM which is what I will cover in the next post.

Technorati Tags: DATA series, jQuery, PushToTest, templating, titanium

• jedi mind tricks - reciprocity, commitment & consistency, social proof, authority, scarcity, reactities, liking, contacts, and co-operation. Dont you think that those are some very keen tactics? answer “those are some very keen tactics.
• an open source talk
• a political discussion - i caught the end of it
• a preso on fluid
• iphone sdk 101
• and my favorite poker till 4am - honed up my skills in omaha and texas hold-em

While there i presented a session on Appcelerator and TestMonkey. It was a great weekend and I really like our atlanta community and glad to see it unite for a weekend. Looking forward to atlanta startup weekend 2 here in a few weeks.

Technorati Tags: barcamp

• Groovy by Scott Davis. Scott has a tremendous amount of energy and did a very good job of covering some of the lesser known aspects of groovy as well as grails
• GWT by David Geary. David is local to Atlanta and provided some humor while explaining the internals of GWT
• Agile and Architecture by David Hussman. David is an agile coach and had a very open and interactive session that was very enjoyable
• Cloud Computing by Michael Nygard - helped answer a lot of my questions with practical examples. He knows his stuff and I cant wait to start using AWS on some of my upcoming projects.

While at the conference I ended up tweeting with some of the other attendees. That was pretty cool. It was a very long weekend and made for a tiring Monday, but I’m glad that I had the opportunity to attend the sessions.

Technorati Tags: nfjs

Just implementing resource bundles to localize your application doesn’t quite cut it. You need to do things like work with localized dates in the browser (including formatting), numbers, currencies, and who knows what else to munge your data. It sure would be nice if there were a way to transparently make this happen in a message oriented way that does not require server side awareness for services, can you help me with this problem? sure.

Built in ‘ization’ support in Appcelerator

Globalization (G11N) and Localization (L10N) both get lumped into Internationalization (I18N) - how to deal with languages, time, data formats and everything else that goes on making it so that people in different places in the world can use your glorious application. Appcelerator localization helps you out with this on some really simple levels with the langid attribute:

  <span langid="account.number.title"></span>:<input type="text"></input>

This should arm you successfully with an ability to deal with things like simple messages and labeling in your application. Now if you want to blend in your data payload to render localized text, you can make use of appcelerator javascript functions Appcelerator.Localization.get and the more powerful but less documented Appcelerator.Localization.getWithFormat.

<script>
  var en_lang_bundle = {
	"invalidlogin.message": "Dear sir/madame, the username you provided '#{username}' does not exist:"
  }
  Appcelerator.Localization.addLanguageBundle("en",English",$H(en_lang_bundle));
</script>
<span on="l:invalidlogin.response then value[text]"></span>
<app:script on="r:invalidlogin.response then execute">
  var text = Appcelerator.Localization.getWithFormat('invalidlogin.message',null,null,{username:'azuercher'});
  $MQ('l:invalidlogin.response',{text:text});
</app:script>

This is a nice way to use message indirection for munging messages, but really is quite messy and anything but transparent. There must be a better way!

Interceptors

A lesser known feature of Appcelerator is the concept of interceptors - client side behavior that you can have play in-between the delivery of queued messages to their recipients. In the case for client-2-server orchestration all server requests and their corresponding response messages are enqueued and subject to perversion by interceptors. You just have to know how to implement them. Lets say that whenever I send a CRUD request to the server called ‘r:createorder.request’ I want to add a new attribute called last_modified_utc which is a numerical representation of a utc date as a long. I can add that to the payload to the back end service completely transparently with the Appcelerator.Util.ServiceBroker.addInterceptor method - the method takes a callback to the following:

• interceptQueue - where requests from client to server are intercepted
• interceptSendToListener - where responses from server to client are intercepted

In the example below I

• add ‘last_modified_utc’ as a current utc long to r:createorder.request which is consumed by my back end service
• transform ‘last_modified_utc’ in the r:createorder.response from utc to a localized string in the browser

<app:script>
	var interceptor = {
	    interceptQueue: function(msg, callback, messageType, scope) {
			if (messageType=='remote:createorder.request') {
				msg.data.last_modified_utc = new Date().getTime();
			}
	        return true;
	    },
	    interceptDispatch: function (requestid, type, data, datatype) {
	        return true;
	    },
	    interceptSendToListener: function (listener, messageType, data, datatype) {
			if (messageType=='createorder.response') {
				date = new Date(data.last_modified_utc);
				data.last_modified = date.toString();
			}
	        return true;
	    }
	};
	Appcelerator.Util.ServiceBroker.addInterceptor(interceptor);
	$MQ('r:createorder.request',{hi:'there'});
</app:script>

Obviously, you can take this a step further and then add interceptors that munge your data conditionally based on the current locale defined in Appcelerator.Localization. The benefit here is that this data transformation happens at a layer outside of my normal pub/sub for messages in Appceleator - the normal pattern is to either replace or add attributes in the payload.

wrap up

Although not a shrink wrapped solution for I18N in all its glory, its not hard to implement interceptors to do so. Beyond I18N, a lot of other aspects for your messages can be mutated in the browser non-intrusively. Although the key demonstration here is data transformation, you would potentially add other horizontal services into your application.

this article cross posted at http://www.appcelerant.com/using-appcelerator-interceptors-for-i18n-l10n-g11n.html

Technorati Tags: appcelerator, i18n, ria

Technorati Tags: wordpress, zuerchtech