Ticket #233 (closed defect: worksforme)

Opened 19 years ago

Last modified 19 years ago

You can no longer override scaffold events

Reported by: Bryan S Owned by: somebody
Priority: high Milestone:
Version: 2.0.304 Severity: major
Keywords: Cc:

Description

It is no longer possible to override a scaffold event without actually commenting out the event you want to override in scaffolds.xml. I have worked with this rather extensively in the past so I feel comfortable saying it is new behavior.

I was careful to put the override event below the scaffold tag as I had discovered that caused problems in the past.

The additional broadcast only gets fired if the original event in scaffold.xml is commented out.

You can use the attachments to Ticket #226 to recreate the database if needed.

in ModelGlue?.xml

<event-handler name="APP_ROLE.list" access="public">

<broadcasts>

<message name="getAllAppRoles" />

</broadcasts>

</event-handler>

in Scaffold.xml

<event-handler name="APP_ROLE.list" access="public">

<broadcasts>

<message name="ModelGlue?.genericList">

<argument name="criteria" value="" /> <argument name="object" value="APP_ROLE" /> <argument name="queryName" value="APP_ROLEQuery" />

</message>

</broadcasts> <views>

<view name="body" template="dspAPP_ROLEList.cfm" append="true">

<value name="xe.view" value="APP_ROLE.view" overwrite="true" /> <value name="xe.delete" value="APP_ROLE.delete" overwrite="true" /> <value name="xe.edit" value="APP_ROLE.edit" overwrite="true" />

</view>

</views> <results>

<result name="" do="view.template" redirect="false" append="" preserveState="true" />

</results>

</event-handler>

Change History

Changed 19 years ago by joe.rinehart

  • status changed from new to closed
  • resolution set to worksforme

Hi Bryan,

I think the issue is around the new "(re)scaffold=true" bits in the framework. Instead of always having rescaffolds regenerated, the default is now to have to state rescaffold=true in the URL to invoke the scaffold generator - it makes working in development mode a much more pleasant experience.

I've tested what you outline in the following manner, and I received a blank screen, as I should, showing that the second widget.list event overrides the first. This isn't the "best" way to cause the scaffold-generated widget.list to be ignored, though: the best is to use the TYPE attribute of <scaffold> to state that a list event should not be generated.

-Joe

Test code:

<scaffold object="widget">

<results>

<result do="view.template" />

</results>

</scaffold>

<event-handler name="widget.list"> </event-handler>

Note: See TracTickets for help on using tickets.