[Fwd: Tosca widgets, only half the battle]

[Toshio Kuratomi]

Forwarding to fedora-infrastructure-list soit canget more exposure and 
discussion.

-------- Original Message --------
Subject: Tosca widgets, only half the battle
Date: Sun, 11 May 2008 12:27:36 -0400
From: John (J5) Palmieri <johnp at redhat.com>
To: Toshio Kuratomi <a.badger at gmail.com>
CC: tcallawa at redhat.com, lmacken at redhat.com, mmcgrath at redhat.com

After hacking away at MyFedora and producing a lot of ugly code in the
process I finally sat down the last two weeks to organize everything
into a framework make it much more extensible and have patterns for
people to easily create content.  Most of the technologies are
solidifying into my head and I have been working on hashing out an API
design behind the user interaction design I had started with.  The issue
I am running into now is the fact that Turbo Gears and related
technology come from a monolithic design and adhere too stringently to
the Model/View/Controller design pattern.  This is really an issue when
your models, views and controllers can come from different applications
or even different servers.  MyFedora is of course a mashup of different
tools and does not fit the, I'm grabbing data from a single database and
displaying it via a self contained template, mold.  What I need is a
complete plugin system where a person can write their own self contained
controllers, templates and static files which then drop in and are
loaded on the fly, while integrating with the global project.

Before I go further let me describe my design.

Vocabulary:

Resource - This is the starting point for MyFedora plugins.  A resource
is any abstract grouping such as "packages", "people" and "projects"
which contain tools for viewing and manipulating data within the
resource's context.

Tools - A tool is a web app for viewing or manipulating data.  For
example Builds would be a tool for the package resource.

Data Id - The data id is a pointer to a specific dataset the tools work
on.  For example the package resource considers each fedora package name
to be a data_id.

The way things work are Resources are placed in the resources/ directory
and contain the logic for routing requests to a specific tool.  They
also contain the master template which is a cause of path problems with
the current TG setup (include paths are relative to the including
template)

Tools are placed in the tools/ directory and are controllers just like
any other TG controller.  The exception is there is a standard for
including the master template and the tool pulls templates and static
files from its own directory.  Tools can register with more than one
resource and must modify its behavior based on the resource calling it.
For instance the Build tool would be able to register with the package
and people resource and depending which resource is being used it would
display either a specific person's builds or the build history of a
package.  Based on the resource being used the master template is pulled
in by the tool's templates.

Data id's are simply what the resource passes to the tool and the tool
needs to be able to accept when dealing with a particular resource.  For
instance the Packages resource would send a package name as a data id
and the Peoples resource would send a person's FAS username.

The issue here is I need the tools to be self contained but still
integrate correctly with the global assests such as master templates and
graphics.  Tosca widgets seemed to be the answer until I looked further
and found out they are just a higher level display layer than a self
contained controller/template system.  It seems to be confusing because
it breaks the connection between the controller, data and the display
when I want that all to be encapsulated.  Basically I don't want the
master page dolling out the data because the master page is just a
container to display the tool and links to other tools.  The tools
should know where to get their data from.

One solution is to use ToscaWidgets as a replacement for templates (or
more apt another layer between the controller and the template).  That
makes things more complicated and throws away a lot of the concepts of
TG controllers.  I guess I am probably just hung up on how I first
learned TG and we can just document around those issues.  But another
thing to think about is stuff like WSGI.

What do you guys think? Given my design and goals such as the ability to
display tools on the portal page, what is our plan of attack?  How do we
concoct a plugin system to make it easy for others to create integrated
content while really just concentrating on their bits and not the wider
integration infrastructure?  Are there systems/libraries out there that
already do this? Tosca is only part of the solution because it only
deals with encapsulating display and is mostly geared to generic widgets
like lists and not complete pages.  I would like to have a framework
that is simple, focused and easy to use.

-- 
John (J5) Palmieri <johnp at redhat.com>