RTNest should be explicit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RTNest should be explicit

Tudor Girba-2
Hi,

I promised to follow with suggestions for improvement in Roassal.

Currently, my main concern is about the fact that RTNest is not explicit. 

Let me explain. I want to debug things related to nesting, and for that I would like to extend the Elements tab of the view with nesting information (essentially, I would like a tree). I cannot build this easily, and this shows me that we have a model problem. This is the side-effect of building custom tools: if the tool costs too much, you might have to think again about the model (it's similar with the relationship between tests and models).

RTNest works at the Trachel level, but it should work at the Roassal level. I would prefer to have in the RTElement links to the nested elements and have the nesting not done via a loose Trachel callback but by an explicit relationship. Alex?

Cheers,
Doru

--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: RTNest should be explicit

abergel
Hi!

I agree with your analysis. However, RTElement should not have an instance variable “children” or “elements". RTElement simply cannot be a composite, as it is not a composite in other frameworks (e.g., RafaelJS).
I’ve spend a couple of hours on working on RTNest. This has become a beast. But I was able to work on it without breaking anything. In Roassal1, I spent too many
nights (and days) on working on the nesting. It is much easier for now.
If we have a variable “children”, may one may rightfully ask why renderOn: does not iterate over it. Why not adding methods such as #add: and #remove: on RTElement. And no… We will not have this. This is too painful to maintain.

I was thinking about adding the list of children as an attribute. Looks like to be the best solution for now.

Cheers,
Alexandre


On Oct 4, 2014, at 1:48 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> I promised to follow with suggestions for improvement in Roassal.
>
> Currently, my main concern is about the fact that RTNest is not explicit.
>
> Let me explain. I want to debug things related to nesting, and for that I would like to extend the Elements tab of the view with nesting information (essentially, I would like a tree). I cannot build this easily, and this shows me that we have a model problem. This is the side-effect of building custom tools: if the tool costs too much, you might have to think again about the model (it's similar with the relationship between tests and models).
>
> RTNest works at the Trachel level, but it should work at the Roassal level. I would prefer to have in the RTElement links to the nested elements and have the nesting not done via a loose Trachel callback but by an explicit relationship. Alex?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: RTNest should be explicit

Tudor Girba-2
Hi Alex,

I did not ask for a composite. I asked for having an explicit method for getting to the nested nodes, just like there is one for getting to the outgoing and incoming edges.

The logic of nesting should still be external. In Mondrian we had only one semantics for nesting, and so it was straightforward to maintain the nesting logic inside the element. Now, we have several meaning for nesting, so it is clear that the logic has to be factored out separately.

So, yes, a nestedElements variable would do just fine for now.

Cheers,
Doru



On Mon, Oct 6, 2014 at 3:24 AM, Alexandre Bergel <[hidden email]> wrote:
Hi!

I agree with your analysis. However, RTElement should not have an instance variable “children” or “elements". RTElement simply cannot be a composite, as it is not a composite in other frameworks (e.g., RafaelJS).
I’ve spend a couple of hours on working on RTNest. This has become a beast. But I was able to work on it without breaking anything. In Roassal1, I spent too many
nights (and days) on working on the nesting. It is much easier for now.
If we have a variable “children”, may one may rightfully ask why renderOn: does not iterate over it. Why not adding methods such as #add: and #remove: on RTElement. And no… We will not have this. This is too painful to maintain.

I was thinking about adding the list of children as an attribute. Looks like to be the best solution for now.

Cheers,
Alexandre


On Oct 4, 2014, at 1:48 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> I promised to follow with suggestions for improvement in Roassal.
>
> Currently, my main concern is about the fact that RTNest is not explicit.
>
> Let me explain. I want to debug things related to nesting, and for that I would like to extend the Elements tab of the view with nesting information (essentially, I would like a tree). I cannot build this easily, and this shows me that we have a model problem. This is the side-effect of building custom tools: if the tool costs too much, you might have to think again about the model (it's similar with the relationship between tests and models).
>
> RTNest works at the Trachel level, but it should work at the Roassal level. I would prefer to have in the RTElement links to the nested elements and have the nesting not done via a loose Trachel callback but by an explicit relationship. Alex?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: RTNest should be explicit

abergel
Done.

You have have a look at testNestedElements testNestedElements2 and testNestedElements3

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



On Oct 6, 2014, at 1:07 AM, Tudor Girba <[hidden email]> wrote:

Hi Alex,

I did not ask for a composite. I asked for having an explicit method for getting to the nested nodes, just like there is one for getting to the outgoing and incoming edges.

The logic of nesting should still be external. In Mondrian we had only one semantics for nesting, and so it was straightforward to maintain the nesting logic inside the element. Now, we have several meaning for nesting, so it is clear that the logic has to be factored out separately.

So, yes, a nestedElements variable would do just fine for now.

Cheers,
Doru



On Mon, Oct 6, 2014 at 3:24 AM, Alexandre Bergel <[hidden email]> wrote:
Hi!

I agree with your analysis. However, RTElement should not have an instance variable “children” or “elements". RTElement simply cannot be a composite, as it is not a composite in other frameworks (e.g., RafaelJS).
I’ve spend a couple of hours on working on RTNest. This has become a beast. But I was able to work on it without breaking anything. In Roassal1, I spent too many
nights (and days) on working on the nesting. It is much easier for now.
If we have a variable “children”, may one may rightfully ask why renderOn: does not iterate over it. Why not adding methods such as #add: and #remove: on RTElement. And no… We will not have this. This is too painful to maintain.

I was thinking about adding the list of children as an attribute. Looks like to be the best solution for now.

Cheers,
Alexandre


On Oct 4, 2014, at 1:48 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> I promised to follow with suggestions for improvement in Roassal.
>
> Currently, my main concern is about the fact that RTNest is not explicit.
>
> Let me explain. I want to debug things related to nesting, and for that I would like to extend the Elements tab of the view with nesting information (essentially, I would like a tree). I cannot build this easily, and this shows me that we have a model problem. This is the side-effect of building custom tools: if the tool costs too much, you might have to think again about the model (it's similar with the relationship between tests and models).
>
> RTNest works at the Trachel level, but it should work at the Roassal level. I would prefer to have in the RTElement links to the nested elements and have the nesting not done via a loose Trachel callback but by an explicit relationship. Alex?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev