not easy to share code between formulas

[djay]

User problem

Sometimes you want share methods, values and other things between formulas inside a form, or between fields and a form, or between forms. The include system is very clumsy with having create the methods, and how its not obvious that you have to resave any formula to include changes to the include file. You can't use mechanisms like classes to structure your code, or wrap documents to make them easier to use for a particular app. When an app gets bigger the code gets spread around.

Options

single .py per form + imports

• All formulas in a form a functions within a single .py module with a convention for the function names (shown in mockup on #705)
• Arbitrary classes, functions and expressions can exist elsewhere in the module and normal module scoping applies.
• All formulas in actions, hidewhens and fields are in the same .py module
  • This allows easy sharing code between fields and/or form
  • con: UI copying a field to another form means moving functions too
• you can import and use code between forms/views.
• no more libutils (with its confusing/inefficient includes)
• code is exported/imported via .py files #386 #344 (Ideally the single .py file per form can be edited live on the fs if the server is running in fg mode.)

hook into import so we can import other forms like

from MyFormB import fieldB_validation

def fieldA_validation(doc):
   return fieldB_validation(doc)

similar to the python via in https://github.com/plomino/Plomino/issues/618. This would also allow arbitrary classes or functions to exist in that file as the developer wishes.

so if you wanted to create a convenience wrapper class you could do it like

class BookStoreModel(object):
   def __init__(self, doc)
      self.doc = doc
  def findBookByAuthor(title):
      ...

def fieldA_validation(doc):
   m = Model(document, ‘jimmysbookstorebook’); 
   if m.findBookByAuthor(x): 
      return False

single .py per DB. Forms as classes.

• No imports are needed.
• Every bit of code in a database is effectively in one big python module.
• Scope of forms is handled by forms as classes.
• form formulas become static methods?

[djay]

would likely superseded https://github.com/plomino/Plomino/issues/386 which deals with a single python file per form as an import/export format. If the above is implemented, the import/export format should be made as close as possible.

[djay]

@ebrehault I think "single .py per form + imports" is the way to go here. I'm guessing since the code already exists for rapido this would not be too hard?

[djay]

@ebrehault We'd like to work on improving the import format since json is pretty much unworkable for filesystem development. @displacedaussie

What I propose is this

• switch to internally storing in the db a single untrusted python object per form (ie formulas no longer stored in DX objects)
• make that editible directly using the IDE UI (no need to edit it directly in DX UI I think).
• make the import format use zip only with .html + .py + .yaml per form and view.
• write a converter from the old xml format to this new zip format
• allow imports before form .py
• (hopefully) make these autoreloadable from disk on change.

[djay]

@ebrehault I guess my questions are, do you agree this is the right way to go, and if so, how does this work in with the timeline for the IDE?

[ebrehault]

I agree it is the way to go. I am about to merge IDE in master (as an experimental feature), the IDE hasn't impacted the way formulas are stored, but it can be adapted easily to the changes you described.