Parameterized magritte components again

I brought up the topic twice already. There is always a few months in between. The topic back then was the parameterization of component links when embedding them into a pier page.

The first problem did Lukas already solve. If I provide a description with parameterName in my component I can get the parameterValue in my component. A

MyMaComponent class>>descriptionChild
        ^ MAStringDescription new
                parameterName: 'child';
                accessor: #child;
                label: 'Child component';
                priority: 100;
                yourself


enables me to specify

+mycomponent|child=title+

on a page and the component will get the "title" value through the child: setter. That is really nice. But the origin of my problem is a step further. In my last project I had big trouble accomplishing the wanted design by using renderers and componentClasses. I wanted to have a more freely doable design.

So the idea was to have a wrapper component around a MAContainerComponent that has the child description. With the child parameter I could select the child of the internal MAContainerComponent to display. Unfortunately the component mycomponent I get by doing

+mycomponent|child=title+
+mycomponent|child=abstract+

are not the same on one page. Is there a way to specify that I want to use the identical component if the embedded label (mycomponent) is the same? May I did something wrong but I always get different objects and it does make sense to me . Would be nice if this would bedoable. Otherwise I guess I need to do my own component-per-page-cache.

Any hints appreciated as always.

Norbert
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> +mycomponent|child=title+
> +mycomponent|child=abstract+
>
> are not the same on one page. Is there a way to specify that I want to use the identical component if the embedded label (mycomponent) is the same? May I did something wrong but I always get different objects and it does make sense to me . Would be nice if this would bedoable. Otherwise I guess I need to do my own component-per-page-cache.

Pier creates one component instance per link that reefers to the component.

I don't think it makes sense to have the same instance of a component
twice on a page. You wouldn't do that in Seaside either. The behavior
in basically undefined since the two components share their state. In
you example it would depend on the initialization order whether the
parameter child would be set to 'title' or 'abstract'.

If you components have no state and are just plain stateless renders
you might want to look at value links.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 12.02.2010, at 08:10, Lukas Renggli wrote:
Well, I don't think there are many use cases where it makes sense, that is right. Usually there is no point in sharing a component. In my case it is different. If you assume that the parameters are functioning as configurators of the component then you are right. The behaviour would dependent on the order of the links.
If you understand the parameters as filters than there is no danger here. My idea is to have something like this

MyMaComponent class>>descriptionChild
        ^ MAStringDescription new
                parameterName: 'child';
                accessor: #child;
                label: 'Child component';
                priority: 100;
                yourself

MyMAComponent class>on: aMAContainerComponent
        ^ self new component: aMAContainerComponent

MyMAComponent>>child: aString
        childDescription := self description detect: [:each| each parameterName = aString]

MyMAComponent>>childDescription
        ^ childDescription

MyMAComponent>>renderContentOn: html
        html render: (self childAt: self childDescription)

If I'm not completley wrong I could spread one MAContainerComponent all over one page. If forms would be nestable than this could work for even more than one component. I hope you see that for this use case I really like to have the same object all the time. Well, but I think I have to figure it out myself. I think I first need to find the place where the components are created and if the label (mycomponent) is available at that time. If yes I could alter my component to create instances over a cache. A cache structure-label to component that resides in the users session should do the trick.

I would be glad if this doesn't sound completely stupid to you and you might have one or two hints how to proceed.
 
> If you components have no state and are just plain stateless renders
> you might want to look at value links.
>

Well, there is state because I'm after forms.

Norbert
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> Well, there is state because I'm after forms.

I guess you could still look after value links, together with a
component that is partially rendered using this technique.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ok, next stop: value links

thanks,

Norbert
On 12.02.2010, at 11:03, Lukas Renggli wrote:

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

I had a look at PRValueLink and indeed this could be a better starting point to implement what I want. And it is the first time I saw how pragmas are used and what they are good for. It is something like pool dictionaries I'm always ignoring.

I have problems understanding the rationale behind the usage of pragmas here. PRLink parses to instances of subclasses that are valid references for the string inside the link (PRValueLink for "value"). Why does PRValueLink not the same? Everything after value: could look up subclasses of PRValueLink that deal with the specified behaviour, no?
So I could subclass the PRValueLink instead of putting extensions on it that use pragmas. Somehow I don't get it. But probably I'm just missing something important.

thanks in advance,

Norbert

On 12.02.2010, at 11:03, Lukas Renggli wrote:


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> I have problems understanding the rationale behind the usage of pragmas here. PRLink parses to instances of subclasses that are valid references for the string inside the link (PRValueLink for "value"). Why does PRValueLink not the same? Everything after value: could look up subclasses of PRValueLink that deal with the specified behaviour, no?

Yes, that could be implemented like this. Pragmas are a different way
of getting extensible systems. They do not pollute the global
namespace.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki