1 Dec
2009
1 Dec
'09
12:04 p.m.
Hi Doru,
I'm working on a browser and I have a problem for communication between pane.
Here is a part of my sourcecode:
=====
| browser|
browser := GLMTabulator new.
browser
row: #browser;
row: #feedback.
browser showOn:#browser; using:[
browser custom: self orionBrowser.
].
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
using:[
|feed|
feed := self feedback.
feed allowNil.
browser custom: feed.
].
^ browser
====
In the "self feedback", I only have selectedVersion. The other values are nil.
Have you an idea of my problem ?
the repository is:'http://www.squeaksource.com/Orion'
and the concerned method is OrionBrowser>>oBrowser.
Thank you for your help.
Cheers
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
1 Dec
1 Dec
12:15 p.m.
Hi Jannik,
Every presentation has a condition that defines when it gets active.
By default, the condition is that all origin ports need to be notNil.
If you specify allowNil, then you will get notified every time any of
the ports change.
In your case, if you set the #selectedVersion the presentation will be
triggered. If you want to control the exact input, you should use a
#when: clause
Cheers,
Doru
On 1 Dec 2009, at 12:04, Laval Jannik wrote:
Hi Doru,
I'm working on a browser and I have a problem for communication
between pane.
Here is a part of my sourcecode:
=====
| browser|
browser := GLMTabulator new.
browser
row: #browser;
row: #feedback.
browser showOn:#browser; using:[
browser custom: self orionBrowser.
].
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
using:[
|feed|
feed := self feedback.
feed allowNil.
browser custom: feed.
].
^ browser
====
In the "self feedback", I only have selectedVersion. The other
values are nil.
Have you an idea of my problem ?
the repository is:'http://www.squeaksource.com/Orion'
and the concerned method is OrionBrowser>>oBrowser.
Thank you for your help.
Cheers
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What we can governs what we wish."
1:24 p.m.
Hi Doru,
I am not sure to understand what you say:
I understand that if I use allowNil, the presentation is triggered when I set
#selectedVersion. But if I set #selectedCat and/or #selectedElement, it should be
triggered differently, no ?
For now, I use when: in the feedback method. The behavior is different if #selectedElement
is not nil.
If I don't allow nil, the presentation is triggered when I set the three elements
(#selectedVersion, #selectedCat and #selectedElement).
But the method oBrowser>>feedback has only the #selectedVersion value.
Maybe the problem come from my method feedback
Here is a part of the source code:
=====
feedback
| browser |
browser := GLMTabulator new.
browser column: #left; column: #mondrian; column: #right.
browser showOn: #left; using: [
browser list
display: [:version | version changes ];
title: 'Actions';
whenKindOf: OrionModel.].
browser showOn: #mondrian; using: [
browser mondrian
painting: [ :view :version |
|group|
group := FAMIXPackageGroup new.
group addAll: version allPackages.
group viewColoredDSMOn: view
]].
browser showOn: #right; using: [
browser table
title: 'Model Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version | version notNil].
browser table
title: 'category Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version :cat | cat notNil].
browser table
title: 'entity Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version :cat :entity | entity notNil].
].
^ browser
=====
Cheers,
Jannik
On Dec 1, 2009, at 12:15 , Tudor Girba wrote:
Hi Jannik,
Every presentation has a condition that defines when it gets active. By default, the
condition is that all origin ports need to be notNil. If you specify allowNil, then you
will get notified every time any of the ports change.
In your case, if you set the #selectedVersion the presentation will be triggered. If you
want to control the exact input, you should use a #when: clause
Cheers,
Doru
On 1 Dec 2009, at 12:04, Laval Jannik wrote:
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
Hi Doru,
I'm working on a browser and I have a problem for communication between pane.
Here is a part of my sourcecode:
=====
| browser|
browser := GLMTabulator new.
browser
row: #browser;
row: #feedback.
browser showOn:#browser; using:[
browser custom: self orionBrowser.
].
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
using:[
|feed|
feed := self feedback.
feed allowNil.
browser custom: feed.
].
^ browser
====
In the "self feedback", I only have selectedVersion. The other values are nil.
Have you an idea of my problem ?
the repository is:'http://www.squeaksource.com/Orion'
and the concerned method is OrionBrowser>>oBrowser.
Thank you for your help.
Cheers
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
2:12 p.m.
On 1 déc. 2009, at 09:24, Laval Jannik wrote:
Hi Doru,
I am not sure to understand what you say:
I understand that if I use allowNil, the presentation is triggered
when I set #selectedVersion. But if I set #selectedCat and/or
#selectedElement, it should be triggered differently, no ?
For now, I use when: in the feedback method. The behavior is
different if #selectedElement is not nil.
If I don't allow nil, the presentation is triggered when I set the
three elements (#selectedVersion, #selectedCat and #selectedElement).
But the method oBrowser>>feedback has only the #selectedVersion value.
Maybe the problem come from my method feedback
Seems like you dont take any parameter in the different subpanes of
your feedback. Then I guess you get only the default parameter of the
browser, which would be the first one, i.e. selectedVersion
Here is a part of the source code:
=====
feedback
| browser |
browser := GLMTabulator new.
browser column: #left; column: #mondrian; column: #right.
browser showOn: #left; using: [
browser list
display: [:version | version changes ];
title: 'Actions';
whenKindOf: OrionModel.].
browser showOn: #mondrian; using: [
browser mondrian
painting: [ :view :version |
|group|
group := FAMIXPackageGroup new.
group addAll: version allPackages.
group viewColoredDSMOn: view
]].
browser showOn: #right; using: [
browser table
title: 'Model Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version | version notNil].
browser table
title: 'category Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version :cat | cat notNil].
browser table
title: 'entity Metrics';
display: [ :version :cat :entity |
"nothing for now"
];
when: [:version :cat :entity | entity notNil].
].
^ browser
=====
Cheers,
Jannik
On Dec 1, 2009, at 12:15 , Tudor Girba wrote:
--
Simon
Hi Jannik,
Every presentation has a condition that defines when it gets
active. By default, the condition is that all origin ports need to
be notNil. If you specify allowNil, then you will get notified
every time any of the ports change.
In your case, if you set the #selectedVersion the presentation will
be triggered. If you want to control the exact input, you should
use a #when: clause
Cheers,
Doru
On 1 Dec 2009, at 12:04, Laval Jannik wrote:
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Doru,
I'm working on a browser and I have a problem for communication
between pane.
Here is a part of my sourcecode:
=====
| browser|
browser := GLMTabulator new.
browser
row: #browser;
row: #feedback.
browser showOn:#browser; using:[
browser custom: self orionBrowser.
].
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
using:[
|feed|
feed := self feedback.
feed allowNil.
browser custom: feed.
].
^ browser
====
In the "self feedback", I only have selectedVersion. The other
values are nil.
Have you an idea of my problem ?
the repository is:'http://www.squeaksource.com/Orion'
and the concerned method is OrionBrowser>>oBrowser.
Thank you for your help.
Cheers
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:26 p.m.
Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
Seems like you dont take any parameter in the
different subpanes of your feedback. Then I guess you get only the default parameter of
the browser, which would be the first one, i.e. selectedVersion
Jannik
2:52 p.m.
Hi Jannik,
I think that the problem is more complicated and I am not sure what is
the right way about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a
presentation. In other words, you get three objects in your block.
However, in the current implementation, after this step the result of
the display: is stored in one port: #entity. And when you look at this
port from inside the browser you only see one object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
--
www.tudorgirba.com
"When people care, great things can happen."
Seems like you dont take any parameter in the
different subpanes of
your feedback. Then I guess you get only the default parameter of
the browser, which would be the first one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:17 p.m.
On 1 déc. 2009, at 10:52, Tudor Girba wrote:
Hi Jannik,
I think that the problem is more complicated and I am not sure what
is the right way about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a
presentation. In other words, you get three objects in your block.
However, in the current implementation, after this step the result
of the display: is stored in one port: #entity. And when you look at
this port from inside the browser you only see one object.
Indeed
I think I had a related problem when I did my demo of Glamour with a
lintBrowser integrated in the smalltalk browser.
Then I have something like that:
browser showOn: #results; from: #rules; from: #outer->#entity; using: [
browser list
display: [:rule :tuple | self getLintResult:
(self runRule: rule forClass: tuple first) result] ].
"tuple = {class. selector} from the browser. We select the class"
#outer->#entity is in fact a tuple {class. selector}
You can see my example in GLMSmalltalkExamples>>stClassicBrowser and
lintBrowser
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
--
Simon
Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Seems like you dont take any parameter in the
different subpanes
of your feedback. Then I guess you get only the default parameter
of the browser, which would be the first one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:18 p.m.
Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
Hi Jannik,
I think that the problem is more complicated and I am not sure what is the right way
about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a presentation. In other
words, you get three objects in your block.
However, in the current implementation, after this step the result of the display: is
stored in one port: #entity. And when you look at this port from inside the browser you
only see one object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Seems like you dont take any parameter in the
different subpanes of your feedback. Then I guess you get only the default parameter of
the browser, which would be the first one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:47 p.m.
Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
Now, when you say that it is difficult to modularize the browser, is
it not due to the inner complexity of the browser? I mean, except for
this detail, is there anything else that stays in your way?
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Hi Jannik,
I think that the problem is more complicated and I am not sure what
is the right way about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a
presentation. In other words, you get three objects in your block.
However, in the current implementation, after this step the result
of the display: is stored in one port: #entity. And when you look
at this port from inside the browser you only see one object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Seems like you dont take any parameter in the
different subpanes
of your feedback. Then I guess you get only the default parameter
of the browser, which would be the first one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
5:39 p.m.
scripts?
versus classes.
Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
Now, when you say that it is difficult to modularize the browser, is it not due to the
inner complexity of the browser? I mean, except for this detail, is there anything else
that stays in your way?
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik,
I think that the problem is more complicated and I am not sure what is the right way
about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a presentation. In other
words, you get three objects in your block.
However, in the current implementation, after this step the result of the display: is
stored in one port: #entity. And when you look at this port from inside the browser you
only see one object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
> Seems like you dont take any parameter in the different subpanes of your feedback.
Then I guess you get only the default parameter of the browser, which would be the first
one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:30 p.m.
Hi,
I do not understand this issue.
Glamour does not force you to get your code in one method. It's more
the other way around. If you get a small browser, then you do not need
to get yourself a class for this. But, if you have a complex browser
just have a dedicated class and place the different parts as methods
in that class.
Please tale a look at GLMCodeBrowser in Glamour-Examples. This
provides an example of how you can decompose a larger browser in small
methods in a dedicated class.
So, I get back to my original question: what are the impediments that
you encountered when trying to build your browsers?
Cheers,
Doru
On 1 Dec 2009, at 17:39, Stéphane Ducasse wrote:
scripts?
versus classes.
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
Now, when you say that it is difficult to modularize the browser,
is it not due to the inner complexity of the browser? I mean,
except for this detail, is there anything else that stays in your
way?
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik,
I think that the problem is more complicated and I am not sure
what is the right way about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a
presentation. In other words, you get three objects in your block.
However, in the current implementation, after this step the
result of the display: is stored in one port: #entity. And when
you look at this port from inside the browser you only see one
object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
> Yes, oki,
>
> Now, how can I specify parameters ?
> I tried to use "from:"
> But if I put "from: #selectedVersion", there is an exception.
>
> What is the syntax to do this ?
>
> Cheers
>
> On Dec 1, 2009, at 14:12 , Simon Denier wrote:
>
>> Seems like you dont take any parameter in the different
>> subpanes of your feedback. Then I guess you get only the
>> default parameter of the browser, which would be the first one,
>> i.e. selectedVersion
>
>
>
> Jannik
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2 Dec
2 Dec
12:26 p.m.
On Dec 1, 2009, at 7:30 PM, Tudor Girba wrote:
Hi,
I do not understand this issue.
Glamour does not force you to get your code in one method. It's more the other way
around. If you get a small browser, then you do not need to get yourself a class for this.
But, if you have a complex browser just have a dedicated class and place the different
parts as methods in that class.
Please tale a look at GLMCodeBrowser in Glamour-Examples. This provides an example of how
you can decompose a larger browser in small methods in a dedicated class.
I know the examples. I'm still skeptical about the fact that I need a dsl to script
browser vs having plain objects with class.
So, I get back to my original question: what are the
impediments that you encountered when trying to build your browsers?
Cheers,
Doru
On 1 Dec 2009, at 17:39, Stéphane Ducasse wrote:
scripts?
versus classes.
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
Now, when you say that it is difficult to modularize the browser, is it not due to the
inner complexity of the browser? I mean, except for this detail, is there anything else
that stays in your way?
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
> Hi Jannik,
>
> I think that the problem is more complicated and I am not sure what is the right way
about it.
>
> When you capture several ports in:
> browser showOn: #feedback;
> from: #browser -> #selectedVersion;
> from: #browser -> #selectedCat;
> from: #browser -> #selectedElement;
>
> you can reason about three things when trying to #display: a presentation. In other
words, you get three objects in your block.
>
> However, in the current implementation, after this step the result of the display: is
stored in one port: #entity. And when you look at this port from inside the browser you
only see one object.
>
> Cheers,
> Doru
>
> On 1 Dec 2009, at 14:26, Laval Jannik wrote:
>
>> Yes, oki,
>>
>> Now, how can I specify parameters ?
>> I tried to use "from:"
>> But if I put "from: #selectedVersion", there is an exception.
>>
>> What is the syntax to do this ?
>>
>> Cheers
>>
>> On Dec 1, 2009, at 14:12 , Simon Denier wrote:
>>
>>> Seems like you dont take any parameter in the different subpanes of your
feedback. Then I guess you get only the default parameter of the browser, which would be
the first one, i.e. selectedVersion
>>
>>
>>
>> Jannik
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "When people care, great things can happen."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:53 p.m.
I do not understand :).
There is nothing magic going on behind the "DSL". You basically
construct objects directly and transparently. Only the factory methods
are a bit more creative, but other than that there is nothing in
between the browser objects and your code. It's very similar in intent
to the Seaside DSL.
In fact, the scripting methods are all extensions to the actual
objects and they are packaged in the Glamour-Scripting package. Also,
if you look at the tests, only in the GLMScriptingTest do you find the
DSL. Everywhere else you find the objects that build the browser.
But, if there are issues I would certainly want to hear them.
Cheers,
Doru
On 2 Dec 2009, at 12:26, Stéphane Ducasse wrote:
On Dec 1, 2009, at 7:30 PM, Tudor Girba wrote:
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Hi,
I do not understand this issue.
Glamour does not force you to get your code in one method. It's
more the other way around. If you get a small browser, then you do
not need to get yourself a class for this. But, if you have a
complex browser just have a dedicated class and place the different
parts as methods in that class.
Please tale a look at GLMCodeBrowser in Glamour-Examples. This
provides an example of how you can decompose a larger browser in
small methods in a dedicated class.
I know the examples. I'm still skeptical about the fact that I need
a dsl to script browser vs having plain objects with class.
So, I get back to my original question: what are
the impediments
that you encountered when trying to build your browsers?
Cheers,
Doru
On 1 Dec 2009, at 17:39, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev scripts?
versus classes.
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
Now, when you say that it is difficult to modularize the browser,
is it not due to the inner complexity of the browser? I mean,
except for this detail, is there anything else that stays in your
way?
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
> Hi Doru,
>
> So, what I do for now is a merging of my methods.
> And I don't have any problem :)
>
> But in fact, it is difficult to modularize my browser :)
>
> Thank you for your help.
>
> Cheers,
> Jannik
>
> On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
>
>> Hi Jannik,
>>
>> I think that the problem is more complicated and I am not sure
>> what is the right way about it.
>>
>> When you capture several ports in:
>> browser showOn: #feedback;
>> from: #browser -> #selectedVersion;
>> from: #browser -> #selectedCat;
>> from: #browser -> #selectedElement;
>>
>> you can reason about three things when trying to #display: a
>> presentation. In other words, you get three objects in your
>> block.
>>
>> However, in the current implementation, after this step the
>> result of the display: is stored in one port: #entity. And when
>> you look at this port from inside the browser you only see one
>> object.
>>
>> Cheers,
>> Doru
>>
>> On 1 Dec 2009, at 14:26, Laval Jannik wrote:
>>
>>> Yes, oki,
>>>
>>> Now, how can I specify parameters ?
>>> I tried to use "from:"
>>> But if I put "from: #selectedVersion", there is an exception.
>>>
>>> What is the syntax to do this ?
>>>
>>> Cheers
>>>
>>> On Dec 1, 2009, at 14:12 , Simon Denier wrote:
>>>
>>>> Seems like you dont take any parameter in the different
>>>> subpanes of your feedback. Then I guess you get only the
>>>> default parameter of the browser, which would be the first
>>>> one, i.e. selectedVersion
>>>
>>>
>>>
>>> Jannik
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "When people care, great things can happen."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:33 p.m.
Hi Doru and Simon
On Dec 1, 2009, at 16:47 , Tudor Girba wrote:
Hi Jannik.
Please follow the suggestion of Simon and let us know if it works.
It does not work in my case.
I don't have a tuple, but only #selectedVersion.
When I put my second part of browser in the main script, it works fine.
But it becomes very hard to read.
Now, when you say that it is difficult to modularize
the browser, is it not due to the inner complexity of the browser? I mean, except for this
detail, is there anything else that stays in your way?
Yes, in fact, when I say it is difficult to modularize, it is for my browser because of
its complexity, not because of something else :)
Cheers,
Jannik
Cheers,
Doru
On 1 Dec 2009, at 15:18, Laval Jannik wrote:
Hi Doru,
So, what I do for now is a merging of my methods.
And I don't have any problem :)
But in fact, it is difficult to modularize my browser :)
Thank you for your help.
Cheers,
Jannik
On Dec 1, 2009, at 14:52 , Tudor Girba wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik,
I think that the problem is more complicated and I am not sure what is the right way
about it.
When you capture several ports in:
browser showOn: #feedback;
from: #browser -> #selectedVersion;
from: #browser -> #selectedCat;
from: #browser -> #selectedElement;
you can reason about three things when trying to #display: a presentation. In other
words, you get three objects in your block.
However, in the current implementation, after this step the result of the display: is
stored in one port: #entity. And when you look at this port from inside the browser you
only see one object.
Cheers,
Doru
On 1 Dec 2009, at 14:26, Laval Jannik wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Yes, oki,
Now, how can I specify parameters ?
I tried to use "from:"
But if I put "from: #selectedVersion", there is an exception.
What is the syntax to do this ?
Cheers
On Dec 1, 2009, at 14:12 , Simon Denier wrote:
> Seems like you dont take any parameter in the different subpanes of your feedback.
Then I guess you get only the default parameter of the browser, which would be the first
one, i.e. selectedVersion
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5499
days inactive
5500
days old
13 comments
5 participants
participants (5)
-
Laval Jannik -
Laval Jannik -
Simon Denier -
Stéphane Ducasse -
Tudor Girba