On Nov 3, 2010, at 10:17 AM, Tudor Girba wrote:
Hi Stef,
Thanks for pushing this.
I definitely understand these issues, and a solution will follow in the near future. It is just a matter of effort, and until now the main goal was to get things going at the model level. This is now working quite well, so now it's time to focus on the rendering and on the API.
good to hear that.
The only thing is that the API will only grow from people using it. With Mondrian, we could do it by having it used by a small amount of people. Glamour is a more complicated engine, and getting the right API right is not as straightforward. What you have right now is already the third version.
I imagine
The rest of the comments are inlined.
I asked several guys around here to have a look at Glamour and gives you feedback and to see if we can build some cool tools with glamour. Alain told me that he will have a look too.
Now the problem of benjamin is also really interesting in the sense that we could not debug it and find the problem ourselves and that was frustrating: mismatch of block arguments or something like that.
This was a mismatch of the returned type.
Still the point is how can we make sure that we can debug it because the model is aligned with our mental model.
This is this aspect of glamour that I would like to see lowered. You see even reading your answer and looking at the code I do not get it. :(
then some questions:
why children: [:item :x :level |
level > 1 ifTrue: [#()] ifFalse: [1 to: item ] ]].could not be
child: childObject level: level....
Basically, for every item, we want to know how to build the children collection. When you need to reason about multiple things, you need to pass them as a parameter in the block.
Perhaps we can have something like:
children: aBlock children: aBlock atLevel: anInteger children: aBlock atLevelHigherThan: anInteger
Yes
I have no idea what is x.
in this case, the second variable is not used inside the block, so I just marked it with x to document that fact. The object is the presentation object.
This is an hidden assumption and without an example I would have no idea that I should pass 3 arg block. Blocks used at their limits are evil since they do not have names.
So for me there is an overuse of block and blocks have no name contrary to method so we miss a lot of the hidden context. So any solution lowering the amount of blocks would be good may be using methods instead and (in that case having less scripting and more programming api would help).
The blocks are just a convenience to construct and parameterize your presentations. Of course, this is only one way, and not the only way :). There really isn't anything magic about it. But, as I said, I will follow with another mail in the following days.
Good. I'm eager to see that. Now consider that your focus should not be on scripting (you have that API) but on how to build classes and use the power of classes to achieve build the same browsers.