Gjallar brainstorm (was Re: [Setools] Gjallar (previously known as Q2) next steps!)

[goran at krampe.se]

Hi!

Have just gone through the original design document and revised it for
public consumption:

	http://swiki.krampe.se/gjallar/uploads/1/OriginalDesign.pdf

=?ISO-8859-1?Q?St=E9phane_Ducasse?= <stephane.ducasse at univ-savoie.fr>
wrote:
> > These filters can then be constructed by the user and are typically
> > owned by the user. Think of a filter as a complex select:  
> > expression (or
> > SQL expression). :)
> 
> Yes I understood that but I could not link that to the rest. Where  
> filter were coming into play.

Mainly searching in the web UI, producing reports and exports and in the
email notification mechanism.
 
> > One way is to create a Process called "Todo lists", then create a very
> > simple workflow for it, like New->Working->Done. Then make a simple  
> > form
> > - all cases already have Subject, Description, Reporter, Responsible,
> > Attachments and a few other things built in. But you can add more  
> > fields
> > or even extra forms, which will appear as separate tabs in the tab UI
> > for the case.
> 
> Why are you talking about forms.
> Forms for me are UI elements that render some data (which can be  
> readonly, selected from lists, editable...)

Well, a Form in Gjallar is the *domain object* representing a collection
of Fields. It is not the runtime Seaside component that renders it (that
is called FormComponent).

So we tell the user that he can "add forms to cases". In the UI he sees
a drop down list with named Forms and when he picks one it is being
added to the tab book of the case. Then he can select that tab and enter
data into the fields. In the domain model an instance of Q2Form is added
to an OrderedCollection in the Q2Case. So each Case knows that Forms
have been added to it.

This way a case first has perhaps only a single tab with the most basic
information entered. Then during the lifecycle of the case users can
decide to add extra Forms as extra tabs. It can even be done
automatically if the case enters a stage where there are rules that says
that a specific named Form must exist in the case before it can move to
the next stage.

> > Then to "classify" todo list items you typically create a CustomObject
> > which is like a table with fields. The simplest CustomObject could be
> > one called say... "Severity" with values like "Annoying", "Minor",
> > "Major", "Disaster".
> >
> > Then you tie that CustomObject to a drop down list box in a Form, like
> > for example the default case creation form.
> 
> Why this domain object is linked with a UI element that way.
> Do I care that I get a drop down list when I'm talking about the  
> domain: ie that my bug has
> a status taken out of several possible choices.

Well, this is because a case (the domain object) has a dynamic set of
fields added to it (in the form of Forms).

Or in other words - when the case is being rendered we ask the case what
Forms it has. Then we render each such Form as a tab in a tab book - or
rather we create Q2FormComponents and Q2FieldComponents that are Seaside
components representing that Form and its Fields. Each field component
in those form components then ask the case what value it has - and the
case has all such field values in a single Dictionary. So let's say it
has the value "Disaster" in the Dictionary keyed by the field id.

The values are typically atomic - they do not know the value domain.

So instead the list field knows a "values provider" that it asks to get
the list it should present. Normally in this case that would be the
CustomObjectType (Severity) which knows all CustomObjects in it
(Annoying, Minor etc).

Not sure if this explained it, but that is how it works today. :)

> >> 	- bugs life-cyle that could be attached to different squeak  
> >> projects.
> >
> > The life cycle is described by the Workflow. We could either create a
> > standard Workflow for bugs, then createt a Process prototype with that
> > workflow and clone it once for each Squeak project. But that would
> > create a bit too many Processes, so again, a good way is to express
> > which Squeak project a bug belongs to by using a CustomObject and a  
> > drop
> > down list to select from - much like in Mantis.
> >
> > So typically you use one Process if all cases can share the same
> > workflow (same stages and transitions with rules), the same permission
> > model and the same set of users (but the permission model can let
> > different people do different things).
> 
> What kind of nodes and transitions do you have in your workflow:  
> join? split?

The nodes are only of one class at the moment (Q2WorkflowStage) but they
are distinguished using isNew and isClosed which gives us three "types"
- new, open and closed. Several (ehm, this is actually a recent change)
stages can be considered "new" (if they are marked as isNew) and several
are "closed" (if marked with isClosed). Only one stage isInbox (and
automatically isNew) - by convention the first stage in the collection
of stages.

I think we did this right before vacation so that cases could actually
move between some initial stages and still be considered "new". When
they eventually move to a stage that is not marked isNew or isClosed
then they are considered "open" (being worked at typically).

The transitions are directed. The case can only be in a single stage at
a given point in time so we have no split/join functionality - we felt
it would make the model and system too complex for its use.

Then we attach Criteria to the stages and transitions to restrict
movement of the cases based on their content (entered values in forms
and fields etc). This means that most of the validation rules are
expressed as Criteria in the Workflow graph - and not as attributes of
the Forms and Fields themselves. So you can edit the case, enter a "bad"
value, and save. But then the case will be restricted in movement to the
next stages.

regards, Göran