Debuging Bindings * Turn on the -vb or -vba options to see messages printed for each event and which bindings are fired. * Go to the generated code and find the line of code which defines the binding - e.g. Bind.arith(..), Bind.method(..), or Bind.bind(..) call. This call returns the initial value of the binding itself so makes a good breakpoint. * To debug firing of a binding, set breakpoints in the setX or getX methods of properties involved in the binding. * When you do need to debug into the data binding code itself, there are two basic passes - the invalidation events and the validation events. On each property change, first the invalidation event is propagated down the binding and it's references. Each valid binding is marked as invalid. Once all invalidation events have been sent, all bindings are validated which walks the same tree, this time invoking methods and setting properties as needed to validate the binding. Note that some frameworks can enable queuing of events - so that bindings are only validated from the eent dispatcher thread on the next view refresh. The two pass approprach, combined with queuing of events, allows you to ensure that bindings are not executed redundantly, for example when you make many changes in the UI before a re-display. In the default mode, the bindings are validated once the event (usually fired in a setX method) is completed.
* If you are using automatic mode and things are not working, first run with -vsa to turn on all synchronized logging (or -vs for a summary). This adds additional messages to the browser's console log and the server's debug log. * Use 'grep addSyncType GenSource.java' against the generated source to see what types and properties in those types are synchronized. Check the generated code for @Sync annotations, and look also for addSyncInst calls to see what's being synchronized. This is particularly useful for layers using @Sync(syncMode = sc.obj.SyncMode.Automatic). You can adjust what gets synchronized by adding @Sync annotations to override the defaults. ** Enable -vl or -v to see the initial layers that are in each runtime. This helps determine which layers are overlapping and so suitable for Automatic SyncMode.
Debugging SCHTML * Go to the generated code to see what the code - the tag object - generated for each schtml file. You can debug these classes by stopping in the getX method, the outputStartTag and outputTag methods of each generated class. * Turn on -vh or -vha to see verbose logs for the client and/server. Messages are printed for important events like tag element invalidations, repeat tag property changes, etc.