Direct Actions - OpenGroupware/OpenGroupware.org GitHub Wiki

Direct actions are essentially deep links into OGo components.

Being WebObjects, OGo components and pages can be instantiated and shown at will using "component actions". Those get dynamic wo links that looks like so:

/ogo-webui-5.woa/wo/14E4C14E4C0166F41BC0/00466f41bc3ec8f3a00.0.17.1.3.1.1.b.teams.3.1.7.3.3.0.1.1.0.1.1.3.1

The wo tells SOPE to use the WOComponentRequestHandler, or in the case of OGo, the little older OWViewRequestHandler which has slightly different behaviour but is generally the same.

Those links are dynamically generated and hence cannot be jumped to directly. This is where (WO)DirectAction's come in. They are an explicit path to a certain entry point. For example the scheduler week view uses:

/ogo-webui-5.woa/wa/newApt?year=2024&month=9&day=25&hour=11&tz=MST&c=12a66f40371cc6fbe80&wosid=11745117450166F2E966

The wa tells SOPE to use the WODirectActionRequestHandler. The newApt is the action, and it has a set of parameters to give it context.

Note: Many actions seem to be directly in categories on WODirectAction, e.g. the newApt in the sample (in WODirectAction+SchedulerViews.m). Others may live in specific classes. They are then listed in the URL path, like /wa/MyClass/MyAction.

In case you wonder, no, this cannot be used to invoke arbitrary methods or classes :-) The methods in WO have to have a specific name to allow access.

Available Entry Points

TODO: document them

• newApt
  • year=2024
  • month=9
  • day=25
  • hour=11
  • tz=MST
  • c=12a66f40371cc6fbe80
  • wosid=11745117450166F2E966

Login

A direct action may still need to login. I think OGo deals with that automagically, i.e. will jump to the login page and back to an action once authenticated.