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@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
setools@lists.squeakfoundation.org