[Setools] Gjallar: Questions (2/16)

[goran at krampe.se]

Resending this because somehow it never got through...
---------------
Hi!

Btw, the tooltip library we use is BoxOver: http://boxover.swazz.org

"Thierry Thelliez" <thierry.thelliez.tech at gmail.com> wrote:
> Goran and all,
> 
> Getting deeper in the Gjallar code, I have the following questions.
> Thanks for any help. Thierry 
> 
> 1- What is this method achieving?
> Q2CasesView > reCalculateIfNeeded
> 	"Recalculate if db has changed."
> 
> 	txnMarker = self model txnMarker ifFalse: [
> 		self calculate.
> 		txnMarker := self model txnMarker]

This is a hack that we might look into revisiting eventually. We utilize
the fact that the model can only have changed if there are more added
txn objects.
Thus if we locally keep track of the last known number of txns then we
can use this to check if the model has changed since we looked last
time.

So the above code only does "self calculate" if the model in fact has
changed.

> 2- How could a message be displayed to the users that have been logged
> out because of timeout?

Mmmmm, well, I dunno. :) Scriptaculous?
 
> 3 - Why is this called at user login? Why already returning a form?
> Q2User > tableCaseForm
> 	"Return the table form to use."
> 
> 	self flag: #q2todo.
> 	^self processes ifEmpty: [self model defaultTableCaseForm]
> 		ifNotEmpty: [self processes first tableCaseForms first]

Mmmm, this is called when Q2FilteredCasesViews (its subclasses) are
initialized - and yes, I presume you are correct that we could build the
table lazily when that view is actually rendered the first time instead.

The idea was that we ask the user for the Form to use for presenting
cases in tables. Now... this is half baked code - but ideally I want
each Process to have one or more "premade" Forms for table viewing (to
select from) created by the Process admins. And of course, a default
table case form in the model as can be seen above.

Then I want every user to have their own Q2CasePanels (the domain object
representing a table of cases) and each such panel would know which Form
it uses for presentation (and thus what fields to show etc).

So this is a hack - we shouldn't ask the user this - instead all places
("My View" and "View cases" - is the idea) should use Q2CasePanels and
through those get the Form to use.

Did this clear things up? I am sorry - this is code "half baked" indeed.
It is on the top of my list.
 
> 4- Why does LeftPanel keep track of the viewed cases? (BTW, you can
> see an ongoing attempt on my side to display a list of users. Mostly
> copy/paste from the Case example).

Mmmm, ah! Good catch. As you noticed the instvar viewCases holds onto
the instance of Q2ViewCases - but doesn't use it. This is legacy stuff -
we can remove that instvar. The viewProcesses (which should be called
processesView to be more accurately named) is still used though I
notice.
 
> 5- Could you explain the relationship between Q2ViewCases,
> Q2FilterPanel and Q2FilterViewer? I found that the Filter classes are
> dedicated to cases. Would it make sense to be able to 'filter' the
> existing users (by category, by process,...)? If yes, would ti make
> sense to reuse these classes?

Ok, first of all - this area is "half baked" and connects with the
Q2CasePanels etc I mentioned above. There is still quite a bit of work
to do on filters and "My View" etc.

Anyway, here goes:

Q2ViewCases is the UI component for generic viewing and
filtering/searching of cases. It is today the only component showing
cases in tabular form but this will change when I get Q2UserCentralView
going (the "My View" page). The idea is to show one or *several*
Q2CasePanelViews - where each such case panel view is a filtered subset
of cases presented in tabular form (just like Q2ViewCases is today).

Of course, Q2ViewCases then becomes more or less a trivial special case
with just one Q2CasePanelView.

Q2FilterPanel (which probably should be called Q2FilterStackView instead
to show it is a view) is a component to manipulate a stack of filters.
It should definitely be used in the Q2ViewCases as it is today, but I am
not sure if I want to use the "filter stack" model for the case panels -
it would get to messy. So a Q2CasePanelView would not offer a stack of
filters - only a single filter.

Q2FilterViewer should probably be called Q2FilterView - it is the
component which actually shows the filter, its fields and what
restrictions are set on them. It needs lots more work because the idea
is that you should be able to manipulate not only the predicates but
also to add/remove new predicates.

Ok, I need to present this more clearly obviously. :) :) But perhaps I
made some sense of it. This is indeed parts not yet done. I have quite
advanced plans for the filtering bit, but very little of it shows today
in the Gjallar UI. But it isn't too far away.

regards, Goran