Author: david

Connection Dictionary Twiddling

Posted on by david

Another “so I don’t have to look it up” post:

Connection dictionaries are the collection of information in your eomodel that configures your access through jdbc to your database.

It is possible to set/modify this information through code and I, along with many others, have built classes that read these settings from your Properties file on app launch. Project Wonder has ERXConfigurationManager that will do this for you as well.

Example:

  • dbConnectURLGLOBAL=jdbc:mysql://host/dbname
  • dbConnectUserGLOBAL=dbuser
  • dbConnectPasswordGLOBAL=dbpassword

Just drop those entries into your Properties file and away you go. Also, because the ERXConfigurationManager reads all your Properties files, you can override the settings in your project with personal ones in your ~/WebObjects.properties resulting in fewer changes to make when deploying. In fact that little trick works great for er.javamail and log4j settings as well.

KnoppMyth R5F27

Posted on by david

Zap2It pulled the plug on their free tv listings service earlier this month (my listings run out on the 17 th), luckily Schedules Direct (SD for those in the know) stepped up to the plate with a replacement service (not free but cheap enough).

Cecil from KnoppMyth posted instructions on getting SD to work on KnoppMyth R5F1 by installing XMLTV and the latest MythTV fixes but I’m too lazy.

Anyway, the KnoppMyth R5F27 .iso was just released with SD support and more, Xtorrent is downloading it now.

Suppressing the wosid in a DirectAction

Posted on by david

Two common means of generating DirectAction URLs in WebObjects are by using the directActionName bindings available in WOHyperLink (and it’s brethren) and by using the WOContext method: directActionURLForActionNamed(String name, NSDictionary).

Kol. Panic offered a tip on suppressing the Session ID (wosid) in DirectAction urls generated from a WOHyperLink in the comments of this post.

It turns out that there is a similar method if you are generating the URL in your code from a WOContext:

  public String loginUrl() {
    NSDictionary dict = new NSDictionary(
        new Object[] {Boolean.FALSE},
        new String[] {"wosid"});
    return context().directActionURLForActionNamed("login", dict);
  }

D2W: Wildcards beware!

Posted on by david

Don’t you just hate it when you outsmart yourself (and make your self feel stupid in the process)?

In Direct To Web it is possible to have wildcards in the rules and these are often used to automatically determine pageConfiguration values. For instance you might have a set of rules that look like this:

50 pageConfiguration like *Applicant* --> entity = "Applicant"
50 pageConfiguration like *Contact* --> entity = "Contact"
50 pageConfiguration like *Division* --> entity = "Division"

And another set of rules that looks like this:

50 pageConfiguration like Edit* --> task = "edit"
50 pageConfiguration like Inspect* --> task = "inspect"
50 pageConfiguration like List* --> task = "list"

So far so good. You get some nice pageConfigurations that kinda configure themselves wrapping your common tasks and model objects (ie: pageConfiguration EditApplicant -> task = ‘edit’ and entity = ‘Applicant’). But…

Add one more rule:

50 pageConfiguration like EditRelationship* --> task = "editRelationship"

And things get icky, now there is a conflict between Edit* or EditRelationship* so the rule engine goes with the first match… but not always, once in a blue moon it will do what you wanted it to do. Just enough to keep you thinking there’s something broken in your templates or EOModel. It can’t be the rules… “‘Cause, heck it worked a minute ago!”

I knew about this! I did! I ran into it with compound names in my EOs (ie: Contact, BigContact) but that didn’t stop me from wasting a ton of time on it anyway.

Oh, the fix is easy. Just take the second rule and give it a higher precedence:

55 pageConfiguration like EditRelationship* --> task = "editRelationship"

It’s the beating your head against a wall of your own making that is hard.