[Moose-dev] Re: reporting system for pharo

I also understand why 'generic' concernc (like distributionMap) doesnt really feat with the concept of Concern having a result and a status. Only The user that want a specific DistributionMap know which kind of information he want to retrieve from it, and therefore what will be the 'status'. Am I right ? In this case it's better to let the user create its own subclass 2010/8/25 Cyrille Delaunay <cy.delaunay(a)gmail.com> By looking at the onMooseReport, I understand wht you mean :) 2010/8/24 Cyrille Delaunay <cy.delaunay(a)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(a)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(a)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(a)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(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 "It's not what we do that matters most, it's how we do it." _______________________________________________ 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