"Forms" will be an API to simply develop web apps within MoinMoin.

FlorianFesti is currently working on an extension for organising conventions. The forms infrastructure is currently built within this development effort. Because of this, the infrastructure is still in an early stage of development and still in flux.

Discussion

• Why? - Because I need it.
• Where is the code? - Sorry, comming soon.

Basic Architecture

Invokation

There is only one action form and one macro Form. These use the MoinMoin plugin mechanism to load a forms plugin. (rename to form as all other plugins use singular?)

Parameter handling

Parameters can be given either as HTML form parameters or as parameters of the macro. For macros, parameters are separated by commas.

Important parameters are:

• "do" HTML formparameter/first macro parameter: name of the form to load

• "method": the method of the dialog to invoke, the name must be in the methods attribute of the dialog (a list of strings). All names in self.methods must have an implementation and and implementation of "action_" + name. The DialogBase implements view, edit, save.

More specialized Dialogue classes may have other parameters like the (DB) "id" of the data to deal with or next page to show after the user pressed the button.

Classes

Dialog Classes

Dialogues contain the code for the big picture data handling. The default "methods" are:

• view
  • show a dataset, can be invoked as macro or as action
• edit
  • show an edit form, can be invoked as macro or as action
• save
  • read the changed data, process them and show the user the changed data (invoke same code as view)
  • this obviously is only availably as an action

DialogBase

• Attributes
• Methods

  • macro(macroargs) - invoked from the Form macro

  • action(pagename) - invoked from the form action

  • action_view(args), view(args), render_value(value)
  • action_edit(args), edit(args), render_editform(value)
  • action_save(args), save(args), render_savedata(data)
  • get_data(filters)
  • save_data(data)
  • check_acl(dowhat)
  • is_Owner(name) - callback for Owner special user (ACL)
  • is_Member(name) - callback for Member special user (ACL)

Calling sequences:

• macro -> (view | edit | save)

• action -> action_(view|edit|save) -> decorate_action -> (view | edit | save)

• view
  • check_acl("read")
  • get_data()
  • render_value()
• edit
  • check_acl("write")
  • get_data()
  • render_editform()
• save
  • check_acl("write")
  • save_data()
  • render_savedata()

UI Classes

Currently located in MoinMoin/widgets/datatypes.py. Module may be split up in the future.

The UI classes handle the input/output of single values. The support rendering of the values and the editform of these values and of retireving these values from the form data after the user pressed save. The UI classes expect/return a native Python type.

• UI
  • Attributes

    • name - Used to create the unique name of the html input tag

    • description - Text shown in front of the data field

    • description2 - Text describing how to edit this field (may be empty)

    • defaultvalue - Value used when rendering an empty form (empty string for most)

• Methods

  • render_value(value, fmt, name=), render_editform(value, fmt, name=)

    • fmt : Formatter
    • name : Name of the surrounding (calling) UI object

  • get_value(form, msg, name=)

  • is_hidden() return Boolean
• StringUI
• PasswordUI
• UrlUI
• EmailUI
• TextUI
• HiddenUI - e.g. used for dataset ids
• DateUI
• DateTimeUI
• IntUI
• FloatUI
• BoolUI
• SelectUI

  • init(self, name, description, defaultvalue, values, description2=)

    • values : list of tuples (value, text)
• SelectMultipleUI

• GenericButton

  • All Buttons take a number of parameters that can be either set as keyword parameters in the contructor or by the value with must be a dict. One special parameter is fields parameter which also has to be a dict. Its key, values are directly rendered as form parameters. The fields is correctly updated if given in both the constructor and the value.

  • Parameters:
    • text = "Submit"

    • action = "" -- this is the HTML form action use fields : {"action" : "foo"} to invoke MoinMoin actions

• Button -- invokes dialogs if pressed
  • target -- dialog to invoke
  • method -- method of this dialog to invoke (copied to fields["method"])

• EditSaveButton

• ToggleButton -- expects a bool in value["on"]

  • on_text
  • off_text
• SetUI - abstract superclass for UIs containing several other UI objects to render more than one value
  • Methods
    • add(ui) -- Add another UI object as part of this UI element
• FormUI
  • renders as a Table with two/three columns: description, value (and description2 for editing)
  • takes a dict as value. Keys must match the name of added UI objects; values are passed as value to theses UI objects
• TableUI
  • renders as Table with one dataset per row. description is used as column title.
  • takes a list of dicts as value; dicts are used as described in FormUI

Discussion

• Please don't miss the possibility of multiple selections -- ReimarBauer DateTime(2006-04-06T20:46:22Z)

  • Is now implemented.

• I am quite interested in this feature and wanted to know whether this will be part of the core MoinMoin distributin or if it will be available as a plugin. Also, is there any indication as to when it might be available? -- Newbie MoinMoin User

OFF TOPIC: Forms are the structured way of information processing. A wiki is heavily processing unstructured/ semantic information. There are some initiatives to standarise information (e.g. templates, forms). Considering templates there are many degrees of freedom. The user can follow but also ignore conventions. Considering forms, there are forms with some degrees of freedom (i.e. [[NewPage(PageTemplate,ButtonLabel,ParentPage[,NameTemplate])]] in conjunction with CategoryCategory). Other forms like selections have low degrees of freedom. I agree. There is a good reeason for forms and I like the idea to create an infrastructure (better: architecture or framework). I have this off-topic idea of merging structured and unstructured (syntactic and semantic) information.

If you want, follow and invert the pardigm of inline documentation (i.e. PHPDoc, Perl's POD, JavaDoc, see also http://www.hypertextnavigation.com/autodoctools.htm ). Can you think of a concept called inline implementation/ coding. Semantic information and syntactic information combined. As in http://twiki.org/cgi-bin/view/TWiki/TWikiPreferences (this has been implemented in a highly structured way of MoinMoin UserPreferences).

QUESTION: Are there platforms/ sites that process information or control a system with such an idea?

EXAMPLE:

=== VIEW NAME ===

=== QUALIFICATION ===

   * status: done
   * schedule: * * * * * * 

=== DESCRIPTION ===

bla bla

=== IMPLEMENTATION ===

==== DDL ====

{ { {#!SQL
  bla bla 
} } }

==== RUN ====

{ { {#!python
   v = View( 'IA_ANA_V_TEST' )
   v.insertSchema()
   v.convert( filename = 'doc/test.csv', delimiter=";", header=True )
   v.updateView()
   v.commit()
} } }

=== ISSUES ===

  * none

-- MichaelRau DateTime(2006-05-01T22:39:33Z)