12 Feb
2010
12 Feb
'10
12:36 a.m.
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
12 Feb
12 Feb
8:10 a.m.
+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
10:59 a.m.
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.
+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.
Well, there is state because I'm after forms.
Norbert
11:03 a.m.
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
11:07 a.m.
Ok, next stop: value links
thanks,
Norbert
On 12.02.2010, at 11:03, Lukas Renggli wrote:
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
1:38 p.m.
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:
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
2 p.m.
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
5426
days inactive
5427
days old
6 comments
2 participants
participants (2)
-
Lukas Renggli -
Norbert Hartl