By looking at the onMooseReport, I understand wht you mean :)

2010/8/24 Cyrille Delaunay <cy.delaunay@gmail.com>
So each time I want to create a concern with specific parameters, I create a subclass with accessors returning directly the concrete value of those parameters?

For example, If we take the DistributionMap I did. I have several parameters that I can specified when creating such a concern : label, explanation, containers, elements, property. 
If I want a report ('CyrilleReport') containing a DistributionMapConcern, with specific values fore these parameters. I should crate a new subclass of DistributionMapConcern returning directly the specific values, Am I write?

But even with that solution, if I want to save the 'template' of a report, I still have to specify somewhere: 'CyrilleReport' is composed by this Concern' subclass.

I have the impression that there is two kind of informations we want to keep:
- the 'template' of the report. Once created, we can apply it on any model we want. From a concern point of view, we want to save its parameters not model-specific: for example label, explanation for any kind of Concern (abel, explanation, containers, elements, property in our example). 
This is what it's done in your solution (and also my current solution). 

- the 'result' of a report. we want to keep information relative to each concern's computation/result. That means informations relative to a specific MooseModel. For now nothing is provided to do that. I don't know what could be the more appropriated solution ?

2010/8/23 Tudor Girba <tudor.girba@gmail.com>
Hi Cyrille,

Right now, you are instantiating a generic class and then you have objects that you serialize in an array. I suggest to create a subclass of the generic class and save the value of the fields (e.g., label, explanation) as methods of that class.

Like that you could have best of both worlds. As I mentioned before, you could solve it with Magritte, or directly having a specialized editor that edits these fields for you.

Cheers,
Doru


On 23 Aug 2010, at 14:19, Cyrille Delaunay wrote:

Ok, it should be ok for the override.
But I think I still do not understand how should be saved the concerns :)
When I finish to build a report, I have a collection of REPConcern's objects. Then I do not see how to save directly those objects as Methods. What should I do with those objects?


2010/8/23 Tudor Girba <tudor.girba@gmail.com>
Hi Cyrille,

I took a look. As I mentioned in a private email, it is a nice start, but I think it would be nicer to get the saving of concerns towards directly compiling as methods in the concern class.

Now, an important issue: you are still overriding REPConcernSpecification>>open. Please delete this override.

Cheers,
Doru



On 20 Aug 2010, at 17:23, Cyrille Delaunay wrote:

Hello,
 In order to provide a reporting system for pharo, I implemented some tools over arki, build some concerns, work on way to save reports.
There still work to do, but you can already test it and give me feedback if you want :):

Download the package 'MooseComputedConcerns' at: www.squeaksource.com/MooseDemoReport.
A message will tell you to resolve depencies by first loading 'System-Benchmarks'.
As the concern about benchmarks is not finished you can choose to 'proceed' (the benchmarkConcern will just not been working).
Otherwise you can load 'System-Benchmarks' from the same repository (allow 'block argument assignement' in the settings before).

Then you will be able, in the moose panel, to right click on a model and open a arki reporter.
You can then play a bit with the browser.

pay attencion : load the last version of 'Refactoring-core' to be able to use the LintRules-Concern
--------------------


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

--
www.tudorgirba.com

"Being happy is a matter of choice."



_______________________________________________
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

"It's not what we do that matters most, it's how we do it."


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