Agile Tortoise

mod_datejs has been updated to version 0.6, incorporating the latest trunk code from the Date.js library. See mod_datejs page for details.

I will be presenting at the March 18th Servoy Virtual User Group meeting. Excerpt from the agenda:

New module that implements the date.js advanced date stuff! Greg will demonstrate how the Date.js library — http://www.datejs.com — can be integrated and deployed in a Servoy solution to provide lots of convenient coding methods for Dates and also allow your users to do natural language date entry in date controls using global method converters.

I’ve checked in mod_datejs v0.5 to Google Code. This is a Servoy module that adapts the functions of the excellent Date.js library for use in Servoy, and is distributed under the same MIT-style license.

I haven’t fully adapted the test suite from the original, but I have pretty good test coverage and everything in the library is now functional, so you should be able reference the documentation at the Date.js site.

This version finally works out a little niggle I was having with the parse method, so Date.parse() now works with all the varieties of cool options for translating natural language dates. When used in combination with “converter” field types in Servoy, you can get rid of the clunky default date control and just let users type things in your date fields. I’ll post documentation, and probably a screencast, on this technique in the coming weeks.

Enjoy!

I’ve updated my Servoy module, mod_js_core, to version 0.4. This is the first version which includes not only the adapted extensions from the Prototype.js library, but also some Servoy specific convenience methods for working with forms and foundsets.

In a Servoy solution, often you have a record and you want to access a record that is related via an n:1 relation. Say, for example, you have a relationship from contacts to companies. You are working with a contact record, and you need to fetch the related company into a variable to work with.

The proper way to do this is first to test for the presence of a record, and then fetch it through the relation you have defined. If it’s something you’re going to do often, you can wrap that logic in a dataprovider calculation on the contacts table, however. Try defining a “MEDIA” type calculation something like this:

1
2
3
4
5

function get_company()
{
   return databaseManager.hasRecords(contacts_to_companies) ? 
                       contacts_to_companies.getRecord(1) : null;
}

Then, when you need to access the related record in code, use that calculation instead of reproducing the logic to fetch the related company….like:

1
2

var contact = foundset.getRecord(foundset.getSelectedIndex(); // fetch a contact from anywhere
var company = contact.get_company;

I find this a very handy shortcut to have around and try to define a “get_xxx” method on all my child tables that allow me to fetch the related parent in the relation.

View at blip.tv

Learn about using the mod_console JavaScript interpreter module in your solutions.