Month: September 2007

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.