A challenge with this approach is that the Seaside views can get complex, with deeply nested subcanvas components. When debugging a button or input field widget, it's nice to not have to spend time getting to the specific instance. Seaside's Halos work well for that, but not when the view has a lot of components; things get lost is the noise.
A few fields...
...is all it takes to make things messy...
To make things easier we added a hidden 'inspect' icon to each VW based component that is only rendered if 'WAAdmin developmentToolsEnabled' is true. It's toggled by a WAToolPlugin subclass icon. Here is how the same view looks with the inspect anchors visible (the title for each inspect icon is the display string of the objedt that would be inspected when clicked)...
renderInspectOn: html
Seaside.WAAdmin developmentToolsEnabled ifFalse: [^self].
html anchor
class: 'subcanvasInspector';
style: 'display: none; position: absolute; ';
title: self displayString;
onClick: (html jQuery ajax
script: [:s | s << (html jQuery ajax callback: [self inspect])]);
with: [html image style: 'width: 12px; height: 12px; '; url: RepWebFileLibrary / #inspect16Gif].
...and then we toggle the display with...
renderInspectWidgetsToggleOn: html
html anchor
onClick: (html jQuery class: 'subcanvasInspector') toggle;
onClick: (html jQuery class: 'subcanvasInspectorPlus') toggle;
with: [
html image
class: 'subcanvasInspectorPlus';
url: Portal.RepWebFileLibrary / #inspectPlus24Gif.
html image
class: 'subcanvasInspectorPlus';
style: 'display: none; ';
url: Portal.RepWebFileLibrary / #inspectMinus24Gif].
Off...
On...
The other icons are for root component inspect, matching VW component inspect and a button to open the VW view (the deployed Seaside image has no VW domain view classes; these are being used during the application port).
With this setup we're able to port a VW application with 4497 window spec methods and keep our manual code work manageable.
Simple things should be simple. Complex things should be possible.