3 Nov
2010
3 Nov
'10
10:32 a.m.
On Nov 3, 2010, at 10:17 AM, Tudor Girba wrote:
Yes
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.
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.
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.
Still the point is how can we make sure that we can debug it because the model is aligned
with our mental model.
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. 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 |
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 > level > 1 ifTrue: [#()] ifFalse: [1
to: item ] ]].
could not be
child: childObject level: level.... 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. 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.
3 Nov
3 Nov
10:43 a.m.
New subject: Glamour
Hi Stef,
Still the point is how can we make sure that we can debug it because the model is aligned
with our mental model.
Yes, this is important, but I do not have a good answer here. The same thing happens in
Mondrian, and also in Seaside. We would need some interesting Exceptions that would allow
us to translate the internal problems into something that the user can understand. This
would be a good candidate for a research project :)
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.
It is hidden indeed, and that is why the current API tries to limit the amount of block
arguments for 99% of usages to about 2. The case of children: is not quite representative,
and I agree that it is rather obscure.
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.
I know :).
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
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. 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. 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.
12:59 p.m.
New subject: Glamour
hello, there still are things I do not understand in your examples,
and I hope you could help me because I really want to understand how
Glamour works ^^
When you write :
t1 transmit to: #three;
from: #one -> #selectionPath;
what happen ?
Because I have looked for implementors of selectionPath, put a self
halt in each of them, run your browser, but no halt has been thrown,
so I'm confused (again).
Moreover, I now know how to show a list, and how to pass the selected
items from the list to another column/row, but I wonder how to use the
selected item as a parameter for a method and how to get the answer of
this method back to be used in another part.
I keep hope to understand how it works ^^
Benjamin
1:45 p.m.
New subject: Glamour
Hi Benjamin,
Great, it looks like you are getting into the details :).
Before going forward, please read the short design description:
http://www.themoosebook.org/book/internals/glamour/architecture
To get an idea of how a browser looks like inside, we also use a special notation:
http://www.themoosebook.org/book/internals/glamour/sketching
Transmissions connect ports of panes.
When you have #one->#selectionPath, you are basically specifying that we refer to the
#selectionPath port from the #one port. This is a shortcut that will be deprecated in the
future. You will have to explicitly say #to:port:.
When you have "transmit to: #one", you transmit to the default input port of a
pane which is named #entity.
When you have "transmit from: #one", you transmit to the default output port of
a pane which is named #selection.
The ports can be named in any way you want. You can think of them as instance variables of
a pane. It is then up to you to connect the ports correctly. Some of the presentations
know how to populate some ports by default. For example:
- a list will populate the #selection port with the item selected in the ui
- a tree will populate the #selectionPath with a collection holding the items from the
selected item to the root of the tree
I hope this helps. Please continue to ask questions :)
Cheers,
Doru
On 3 Nov 2010, at 12:59, Benjamin wrote:
hello, there still are things I do not understand in
your examples, and I hope you could help me because I really want to understand how
Glamour works ^^
When you write :
t1 transmit to: #three;
from: #one -> #selectionPath;
what happen ?
Because I have looked for implementors of selectionPath, put a self halt in each of them,
run your browser, but no halt has been thrown, so I'm confused (again).
Moreover, I now know how to show a list, and how to pass the selected items from the list
to another column/row, but I wonder how to use the selected item as a parameter for a
method and how to get the answer of this method back to be used in another part.
I keep hope to understand how it works ^^
Benjamin
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
1:54 p.m.
New subject: Glamour
I just succeed to make my first Glamour-designed browser works ^^
Thank you Doru for your advice, I'll read both article and keep asking
questions ^^ So prepare yourself ;)
Benjamin
4926
days inactive
4926
days old
4 comments
3 participants
participants (3)
-
Benjamin -
Stéphane Ducasse -
Tudor Girba