Category: d2w

Direct to Web – rule based development with WebObjects

Screencast: Using ERExcelLook

Posted on by david

Project Wonder’s ERExcelLook is a framework that leverages Direct To Web and the ExcelGenerator framework to easily generate Excel exports. I just finished a short screencast on adding it to an existing project. The topics covered are:

  • Adding Direct To Web to an existing project
  • Adding and action to trigger an .xls export for an array of entities
  • Creating a new model file
  • Modifying the rules

Links for the screencast:

  • There is an archive of the completed sample project available here.
  • The project is based on the Movies database, and a MySQL dump is available here.
  • The Rule Modeler tool used in the screencast can be found here.
  • The screencast itself can be found here.

I hope you enjoy it, let me know what you think.

Update: Dave Holt points out that you can specify the worksheet name by adding it in parenthesis as the first item in your displayPropertyKeys array. i.e:

(
    "(WorksheetName)",
    "title",
    "dateReleased",
    "category",
    "studio.name"
)

Alternate D2W Looks

Posted on by david

A Direct To Web Look is a set of templates for the common task pages that defines the look and feel of the application. In the bad old days the templates were heavily table based and many of your rules would end up setting display parameters (like table cell background colour etc.)

Thankfully this is changing. I demoed Ravi Mendis’ amazing ERDivaLook (now part of Project Wonder) at WOWODC 2009 West, but since then several others have come to light. So here is a list of the Looks that I know about (excluding the ones from Apple)

  • Project Wonder – ERDirectToWeb – Though technically not a Look, the templates in ERDirectToWeb can be duplicated with Wonder’s Template_creator.pl script and can be used as the basis for your own look. Heavily leverages the power of D2W to offer massive flexibility. Not a good choice for a first attempt at creating your own look but definitely worth looking at for ideas.
  • Project Wonder – ERNeutralLook – A nasty old school Look with lots of table based layout. However, ERNeutralLook can easily be duplicated using the Template_creator.pl script and is simple enough to be useable as the basis for your first attempt at creating your own Look
  • Project Wonder – AjaxLook – I’ve not used or investigate this Look at all. However my understanding is this it is an experiment only and not ready for prime time.
  • Project Wonder – ExcelLook – This very useful Look is a bit of an oddity in that it is not designed to create an end user interface. It does however, generate easily customizable Excel exports to any application. Look for a screencast on this one soon.
  • Project Wonder – ERDivaLook – A very powerful Ajax enabled, XHTML 1.0 strict, semantic markup based Look that looks like it will be amazing once it is completed. It is currently under heavy development and has dependencies on the new WO2 framework and requires WebObjects 5.4.x. Keep an eye on this one.
  • DMSimpleLook – Used by Denis Frolov as part of his SiteMonitor demo at WOWODC 2009 West. It is a simple look with only a few templates but may be a good starting point as the basis for your own look. The SiteMontior project is available here.
  • R2D2W – Ramsey Lee Gurley’s custom Look. This look boasts XHTML 1.1 strict compliance, Section 508 compliance for accessibility, RSS, inline SVG, and user management. I haven’t explored this one in detail yet, but it definitely looks interesting. The project page is here.
  • EVDirectToWeb – Guido Neitzer’s custom Look. Currently listed as unstable pre-alpha so take that under advisment. The project page including screen shots is here.

If you know of any other D2W Looks that are released into the wild, or have any additional experience with any of these. Let me know.

Update: Oops, forgot Guido’s EVDirectToWeb

Direct To Web

Posted on by david

At WOWODC this weekend I gave a talk on Direct To Web that spurred a lot of interest which I was thrilled to see.

Getting started with D2W is not an easy task and I owe a massive debt to the two chapters in the Wrox book: Professional WebObjects 5.0 with Java which is sadly out of print. The book was a team effort but I believe that Jim Roepcke wrote those two chapters and is still involved in the WebObjects community. I would like to send a big thanks his way.

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.