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:

...

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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

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

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:

...

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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- Simon

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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Every successful trip needs a suitable vehicle."

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.

...

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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"What is more important: To be happy, or to make happy?"

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:

...

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.

...

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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"What is more important: To be happy, or to make happy?"

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Sometimes the best solution is not the best solution."