D2W: Wildcards beware!

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.

D2W: Grouping fields in edit form

To group your edit form fields use sectionsContents instead of displayPropertyKeys. A rule for a User for might look like this:

LH: pageConfiguration = 'EditUser'
RH: sectionsContents =
(
  (
    "Personal Info",
    "salutation", 
    "firstName", 
    "lastName", 
    "emailAddress", 
    "phone", 
    "phoneExtension", 
    "mobile"), 
  (	
    "Address", 
    "address.address1", 
    "address.address2", 
    "address.city", 
    "address.province", 
    "address.postalCode"), 
  (	
    "Details", 
    "organization", 
    "role", 
    "loginCredential.password", 
    "loginCredential.isActive", 
    "loginCredential.role"
  )
)

This will result in a form that looks something like this:

d2w_segmented_form.gif

Standard assumptions apply: Wonder’s D2W classes are being used.

D2W: List default sort order

Assumptions: Your D2WList page inherits from ERD2WListPage in Wonder (and if it doesn’t it should).

Apply a default sort order on the list with a rule that looks like this:

LH: task = 'list' and entity.name = 'User'
RH: defaultSortOrdering = ( "name",
"compareAscending" )

Class: com.webobjects.directtoweb.Assignment

Also available are:

compareAscending
compareCaseInsensitiveAscending
compareCaseInsensitiveDescending
compareDescending.