As far as I know it is cheap.

Main method in builder is #renderIn: which accepts a view and put’s there everything that you need. So if you have a script (by the way, is there a definition for “roassal script” or it’s a general term?) you just need to copy main functionality into #renderIn:, and other methods as they are to the builder. Also you you need additional data for it, you can add it as setters/initialisation. 

Uko

On 01 Sep 2014, at 13:01, Tudor Girba <tudor@tudorgirba.com> wrote:

Ok, but then it follows that any visualization that is now handled in a self-contained script should be a builder as well.

This can well be, but this definition will probably lead us in a slightly different direction than where we are now. That is because we would need to make it very cheap to create a builder out of a script. Would anyone want to explore this?

Doru


On Mon, Sep 1, 2014 at 12:52 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
I think that Blueprint has a good reason to be a builder :), and if you want to make your thing reusable it’s reasonable to make a builder for it.

(thou maybe I’m not very familiar with Roassal philosophy)

Uko



On 01 Sep 2014, at 11:23, Tudor Girba <tudor@tudorgirba.com> wrote:

I think we are not talking about the same thing. You seem to say that every visualization script should be a builder. I think this is not particularly useful. Or did I get something wrong?

Doru


On Mon, Sep 1, 2014 at 11:08 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
I think that we should stick to builders.

Because you anyway have some questions open like should script create view or populate existing one and so on. If we create a builder, then potential users will work with familiar interface + will be able to combine your work with other visualisations and so on. I was really frustrated with Roassal 1 because everyone was creating his own thing, and then one builder returned a view, another one - view stack, and some of them required you to provide a view.

Uko

On 01 Sep 2014, at 06:51, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

Exactly. A builder offers an API with which for the same input you can produce multiple outputs. If you can only produce one output then you probably have a script in your hand.

On the other hand, if you do not place the script in the class of the input object, then you probably want to have a separate class for the visualization. In that case, it might still make sense to have this class be a subclass of builder. What do you think?

Doru


On Mon, Sep 1, 2014 at 12:02 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
If it is not a builder, then it is a simple script.
My stake on this is that you never know whether you want to customize a view or not.
Having a builder is also a way to compose with other visualization.

Alexandre


On Aug 29, 2014, at 2:31 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

> I do not see why you would create a builder for this. I think a builder is only useful when you want to customize something. Or would you like to customize something in the blueprint?
>
> Doru
>
>
> On Fri, Aug 29, 2014 at 12:31 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
> It would be great to have the class blueprint available for plain Pharo class. This should not be complicated. Creating a builder is indeed the way to do it.
>
> Alexandre
>
> > Le 28-08-2014 à 4:49, Yuriy Tymchuk <yuriy.tymchuk@me.com> a écrit :
> >
> > Hi,
> >
> > is blueprint diagram only available in moose panel? Because I want to use it outside of Moose, so I wander if there is some Roassal builder for that.
> >
> >
> > Uko
> > _______________________________________________
> > 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 thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> Moose-dev@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




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



--

"Every thing has its own flow"
_______________________________________________
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




--

"Every thing has its own flow"
_______________________________________________
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 thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev