when i teach coda to developers who know OOP, i say that
tables are like CLASSES
rows are like OBJECTS
columns are like object ATTRIBUTES
column-formulas are like object FUNCTIONS
and
column-BUTTONS are like object METHODS
and the metaphor works very well in most cases
but
a BUTTON does not return a result (one exception below)
so we cannot define a true METHOD that returns an object or a value, and be chained in a formula
(eg. in Colujure the (do …) form is similar to RunActions() but it returns the result of the last expression in the list)
(eg. in Smalltalk, a method returns the SELF object by default (ie the THISROW in CFL))
that would be extremely useful in coding business logic
also
when we need a user-interaction inside a method, we use the OpenRow() to simulate that
but
when the OpenRow() dialog is closed it does not RETURN to the calling formula!
so we cannot continue the logic is a simple way
instead we must have a button in the dialog that does a ‘goto’ another action formula to continue the logic. so we might need to create several such buttons that are shown/hidden in several views
the business logic is now fragmented across several buttons
if the OpenRow() returned control to the calling formula, we could have all the workflow logic in a single place
the one exception…
if the last action in a button creates or modifies a table row
then that button ‘returns’ a reference to that row that CAN be use in a limited way
eg;
button ADD ends with… Table1.AddRow(Col1, Today())
button SHOW ends with… RunActions( ADD).OpenRow()
pushing the SHOW button…
calls ADD which creates a new row, which is returned to the SHOW button and used in the OpenRow() to display a dialog of the newly added row
THATS the kind of ‘return’ functionality i am looking for in general
(i am struggling to explain what i need, hope oop developers can understand me?)
respect
max