Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Version 4 (modified by David Bernard <dwayne@…>, 13 years ago) (diff)

add controller features to sample

I started a proof of concept about another way to create and customize Widget. It's a work in progress, but feedback (goals/approach, style, tips,...) will be appreciated. The P.O.C include an API definition and implementation of part of it.

The result are Python packages (part are attached) and proposition about TG Widgets' futur (some proposition were based on idea found in mailing-list (Michele Cella,...)) :


  • define the simplest api that allow integration of widget with TG :
    • the name of the method/attribute to retreive css js for a widget
    • Resource and children class (don't need to be full widget)
    • the methode to call to register static directory
    • the signature/API of the method to display a value (value could be a dict)
    • the signature/API of the method to validate/update values and error
  • instead of render, source, sample, register, define an entry_points (like for template engine) use by Toolbox.
        class WidgetFamilySamples(controllers.Root):
            """ Global description of the widget family """
            def list():
                """return the list of samples'name (string)"""
            def display(sample_name):
                """return the sample (like a call to widget.insert(...) or widget.display(...) (in my widgetit)"""
            def description(sample_name):
                """return the description of the sample as string (ReST format ?)"""
            def categories(sample_name):
                """return the list of categories (string)"""
            #define exposed methods used to illustrate some special features (validation/AJAX,...)
    The advantages are:
    • provide sample are optionnal for widget developer
    • several samples could be provide to illustrate usage of a widget
    • sample could illustrate usage of a group/assemblage of widget
    • sample could use server-side features
  • don't force the internal implementation of widgets (with attribute like template, or method like creat_dict())