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