Category: webobjects

Apple’s incredibly powerful and robust web application framework

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.

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.