From pablogancharov at gmail.com  Sat Oct  2 03:09:06 2010
From: pablogancharov at gmail.com (Pablo Gancharov)
Date: Fri, 1 Oct 2010 22:09:06 -0300
Subject: Pier 2 Question
Message-ID: <AANLkTik-Sz31zyACqP0rT2NQt70jZhKsxi3aungTS-Px@mail.gmail.com>

Hi people, I am triying Pier 2, but I found this issue:

If I try to put :

"<div style="clear: both"></div>"

under an image, I not work as in Pier 1.2.


Can some body help me.
Thanks

From p3anoman at gmail.com  Sat Oct  2 04:15:26 2010
From: p3anoman at gmail.com (John McKeon)
Date: Fri, 1 Oct 2010 22:15:26 -0400
Subject: Pier 2 Question
In-Reply-To: <AANLkTik-Sz31zyACqP0rT2NQt70jZhKsxi3aungTS-Px@mail.gmail.com>
References: <AANLkTik-Sz31zyACqP0rT2NQt70jZhKsxi3aungTS-Px@mail.gmail.com>
Message-ID: <AANLkTik2o1a=aQ9v=MQjmT0_ssSd1QYN16=WLiWxGF4=@mail.gmail.com>

Hi Pablo,

On Fri, Oct 1, 2010 at 9:09 PM, Pablo Gancharov <pablogancharov at gmail.com>wrote:

> Hi people, I am triying Pier 2, but I found this issue:
>
> If I try to put :
>
> "<div style="clear: both"></div>"
>
> under an image, I not work as in Pier 1.2.
>
> Try  {{{<div style="clear: both">}}}    {{{</div>}}}
Inside the contents of a page you have to surround raw html with the triple
brackets

John



> Can some body help me.
> Thanks
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://john-mckeon.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101001/a5f2c70b/attachment.html>

From lenglish5 at cox.net  Sat Oct  2 21:11:11 2010
From: lenglish5 at cox.net (Lawson English)
Date: Sat, 02 Oct 2010 12:11:11 -0700
Subject: More PRValueLink questions
Message-ID: <4CA783CF.1030401@cox.net>

  How do I format text output from my custom link?

I can embed raw HTML by doing:

^PRVerbatim content: '<p>',myString1,'</p>', '<p>',myString2,'</p>'.

and so on. How can I use the   renderContentOn:    syntax so I can take 
advantage of seaside's internal formatting methods... Or can I, or is 
there something more pier-oriented I should do instead?

e.g.  +values:awgvalues|factorialval=300+ goes right of the edge of the 
webpage currently.

Thanks,

Lawson

From renggli at gmail.com  Sat Oct  2 21:22:51 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 2 Oct 2010 21:22:51 +0200
Subject: More PRValueLink questions
In-Reply-To: <4CA783CF.1030401@cox.net>
References: <4CA783CF.1030401@cox.net>
Message-ID: <AANLkTim_aaWbT8EC0_=ybcH+A+OPfN=ME76cNPtP+vz1@mail.gmail.com>

Typically you return a PRDocument composite, as in your example with
PRVerbatim. Also you can return a string, or a collection of strings
or PRDocument items. If you return anything else, the default
#printOn: representation will be displayed.

If you are sure you only want to use the value link in the context of
Seaside you can even return a rendering block, something along ...

    ^ [ :html | html anchor callback: [ ... ]; with: 'some link' ]

Keep in mind that this will break if you try to convert your page to
Text, LaTeX, etc.

Lukas

On 2 October 2010 21:11, Lawson English <lenglish5 at cox.net> wrote:
> ?How do I format text output from my custom link?
>
> I can embed raw HTML by doing:
>
> ^PRVerbatim content: '<p>',myString1,'</p>', '<p>',myString2,'</p>'.
>
> and so on. How can I use the ? renderContentOn: ? ?syntax so I can take
> advantage of seaside's internal formatting methods... Or can I, or is there
> something more pier-oriented I should do instead?
>
> e.g. ?+values:awgvalues|factorialval=300+ goes right of the edge of the
> webpage currently.
>
> Thanks,
>
> Lawson
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Sat Oct  2 21:36:29 2010
From: lenglish5 at cox.net (Lawson English)
Date: Sat, 02 Oct 2010 12:36:29 -0700
Subject: More PRValueLink questions
In-Reply-To: <AANLkTim_aaWbT8EC0_=ybcH+A+OPfN=ME76cNPtP+vz1@mail.gmail.com>
References: <4CA783CF.1030401@cox.net>
	<AANLkTim_aaWbT8EC0_=ybcH+A+OPfN=ME76cNPtP+vz1@mail.gmail.com>
Message-ID: <4CA789BD.1080706@cox.net>

  Thanks very much.  Pier is amazingly powerful.

Lawson

On 10/2/10 12:22 PM, Lukas Renggli wrote:
> Typically you return a PRDocument composite, as in your example with
> PRVerbatim. Also you can return a string, or a collection of strings
> or PRDocument items. If you return anything else, the default
> #printOn: representation will be displayed.
>
> If you are sure you only want to use the value link in the context of
> Seaside you can even return a rendering block, something along ...
>
>      ^ [ :html | html anchor callback: [ ... ]; with: 'some link' ]
>
> Keep in mind that this will break if you try to convert your page to
> Text, LaTeX, etc.
>
> Lukas
>
> On 2 October 2010 21:11, Lawson English<lenglish5 at cox.net>  wrote:
>>   How do I format text output from my custom link?
>>
>> I can embed raw HTML by doing:
>>
>> ^PRVerbatim content: '<p>',myString1,'</p>','<p>',myString2,'</p>'.
>>
>> and so on. How can I use the   renderContentOn:    syntax so I can take
>> advantage of seaside's internal formatting methods... Or can I, or is there
>> something more pier-oriented I should do instead?
>>
>> e.g.  +values:awgvalues|factorialval=300+ goes right of the edge of the
>> webpage currently.
>>
>> Thanks,
>>
>> Lawson
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>


From renggli at me.com  Sun Oct  3 19:48:00 2010
From: renggli at me.com (Lukas Renggli)
Date: Sun, 03 Oct 2010 19:48:00 +0200
Subject: reduce: and lines in Magritte
In-Reply-To: <AANLkTikQrC9Cw35ccbxBvd1nU3xFqvvfpfM2nNiOtipO@mail.gmail.com>
References: <AANLkTikQrC9Cw35ccbxBvd1nU3xFqvvfpfM2nNiOtipO@mail.gmail.com>
Message-ID: <A8D688FF-0053-4D51-9ADD-EE831F334CD6@me.com>

Hi John,

You need to revert the Pharo 1.1 collection packages, because Magritte accidentally overrode the implementation in Pharo.

Lukas

On Oct 3, 2010, at 18:26 , John McKeon wrote:

> Hello Lukas,
> I updated to the latest Magritte-Model last night and found things fairly broken with the removal of these extension methods. Pier still uses reduce: in several places and MAOptionDescription uses lines in MAOptionDescription >>optionsTextual:
> 
> Regards
> John
> 
> -- 
> http://john-mckeon.us

-- 
Lukas Renggli, Software Composition Group (SCG)
Sch?tzenmattstrasse 14, 3012 Bern, Switzerland
Room: 203, Phone: +41 31 631 8643
www.lukas-renggli.ch









From renggli at me.com  Sun Oct  3 20:15:56 2010
From: renggli at me.com (Lukas Renggli)
Date: Sun, 03 Oct 2010 20:15:56 +0200
Subject: reduce: and lines in Magritte
In-Reply-To: <AANLkTikd7RK+8ogXFVboZRHOfmfPWaEwjkE7djofQhwy@mail.gmail.com>
References: <AANLkTikQrC9Cw35ccbxBvd1nU3xFqvvfpfM2nNiOtipO@mail.gmail.com>
	<A8D688FF-0053-4D51-9ADD-EE831F334CD6@me.com>
	<AANLkTikd7RK+8ogXFVboZRHOfmfPWaEwjkE7djofQhwy@mail.gmail.com>
Message-ID: <25A345FE-6F78-46AF-84D0-C53D8D4D50C8@me.com>

Yeah, presumably this should go into the Squeak specific packages of Grease.

On Oct 3, 2010, at 20:12 , John McKeon wrote:

> I see.
> I have been using Squeak 4.1 =)
> What are my options in that case? A squeak compatibility layer?
> 
> 
> On Sun, Oct 3, 2010 at 1:48 PM, Lukas Renggli <renggli at me.com> wrote:
> Hi John,
> 
> You need to revert the Pharo 1.1 collection packages, because Magritte accidentally overrode the implementation in Pharo.
> 
> Lukas
> 
> On Oct 3, 2010, at 18:26 , John McKeon wrote:
> 
> > Hello Lukas,
> > I updated to the latest Magritte-Model last night and found things fairly broken with the removal of these extension methods. Pier still uses reduce: in several places and MAOptionDescription uses lines in MAOptionDescription >>optionsTextual:
> >
> > Regards
> > John
> >
> > --
> > http://john-mckeon.us
> 
> --
> Lukas Renggli, Software Composition Group (SCG)
> Sch?tzenmattstrasse 14, 3012 Bern, Switzerland
> Room: 203, Phone: +41 31 631 8643
> www.lukas-renggli.ch
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> http://john-mckeon.us

-- 
Lukas Renggli
www.lukas-renggli.ch



From frank.shearar at angband.za.org  Mon Oct  4 08:02:35 2010
From: frank.shearar at angband.za.org (Frank Shearar)
Date: Mon, 04 Oct 2010 08:02:35 +0200
Subject: reduce: and lines in Magritte
In-Reply-To: <25A345FE-6F78-46AF-84D0-C53D8D4D50C8@me.com>
References: <AANLkTikQrC9Cw35ccbxBvd1nU3xFqvvfpfM2nNiOtipO@mail.gmail.com>	<A8D688FF-0053-4D51-9ADD-EE831F334CD6@me.com>	<AANLkTikd7RK+8ogXFVboZRHOfmfPWaEwjkE7djofQhwy@mail.gmail.com>
	<25A345FE-6F78-46AF-84D0-C53D8D4D50C8@me.com>
Message-ID: <4CA96DFB.8020906@angband.za.org>

Squeak's had Collection>>reduce: since 2010/04/05, if that helps. So 
that was probably just AFTER 4.1 was released?

frank

On 2010/10/03 20:15, Lukas Renggli wrote:
> Yeah, presumably this should go into the Squeak specific packages of Grease.
>
> On Oct 3, 2010, at 20:12 , John McKeon wrote:
>
>> I see.
>> I have been using Squeak 4.1 =)
>> What are my options in that case? A squeak compatibility layer?
>>
>>
>> On Sun, Oct 3, 2010 at 1:48 PM, Lukas Renggli<renggli at me.com>  wrote:
>> Hi John,
>>
>> You need to revert the Pharo 1.1 collection packages, because Magritte accidentally overrode the implementation in Pharo.
>>
>> Lukas
>>
>> On Oct 3, 2010, at 18:26 , John McKeon wrote:
>>
>>> Hello Lukas,
>>> I updated to the latest Magritte-Model last night and found things fairly broken with the removal of these extension methods. Pier still uses reduce: in several places and MAOptionDescription uses lines in MAOptionDescription>>optionsTextual:
>>>
>>> Regards
>>> John
>>>
>>> --
>>> http://john-mckeon.us
>>
>> --
>> Lukas Renggli, Software Composition Group (SCG)
>> Sch?tzenmattstrasse 14, 3012 Bern, Switzerland
>> Room: 203, Phone: +41 31 631 8643
>> www.lukas-renggli.ch
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> http://john-mckeon.us
>


From lenglish5 at cox.net  Tue Oct  5 19:24:19 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 10:24:19 -0700
Subject: collaborative documentation in pier
Message-ID: <4CAB5F43.9050905@cox.net>

  Has anyone ever used Pier for collaborative documentation?

I realize a wiki is sorta that already, but I'm part of an IETF group 
that is exploring options at the moment and I wonder if there were any 
existing examples of Pier being used that way?


Thanks..

Lawson

From renggli at gmail.com  Tue Oct  5 19:29:10 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 5 Oct 2010 19:29:10 +0200
Subject: collaborative documentation in pier
In-Reply-To: <4CAB5F43.9050905@cox.net>
References: <4CAB5F43.9050905@cox.net>
Message-ID: <AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>

> ?Has anyone ever used Pier for collaborative documentation?

Yes, for example books are being written using Pier.

> I realize a wiki is sorta that already, but I'm part of an IETF group that
> is exploring options at the moment and I wonder if there were any existing
> examples of Pier being used that way?

Probably more, but these are the ones that come to my mind:

  http://book.seaside.st/
  http://book.pharo-project.org/
  http://www.themoosebook.org/book/

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Tue Oct  5 19:43:38 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 10:43:38 -0700
Subject: collaborative documentation in pier
In-Reply-To: <AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
References: <4CAB5F43.9050905@cox.net>
	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
Message-ID: <4CAB63CA.8060307@cox.net>

  On 10/5/10 10:29 AM, Lukas Renggli wrote:
>    http://book.seaside.st/
>    http://book.pharo-project.org/
>    http://www.themoosebook.org/book/
Thanks Lukas, I had thought of the book component just after I clicked send.


I know there's a latex printer. I assume there's a pdf printer as well?

I see mention of a text printer for page components. Does that keep 
table, etc, formatting in some way, also?


IETF document requirements are extremely weird. It would be very kool if 
Pier could be used to create online versions and then have them print 
directly into the standard RFC format.

a potentially HUGE use for Pier

Lawson




From renggli at gmail.com  Tue Oct  5 19:50:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 5 Oct 2010 19:50:11 +0200
Subject: collaborative documentation in pier
In-Reply-To: <4CAB63CA.8060307@cox.net>
References: <4CAB5F43.9050905@cox.net>
	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
	<4CAB63CA.8060307@cox.net>
Message-ID: <AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>

On 5 October 2010 19:43, Lawson English <lenglish5 at cox.net> wrote:
> ?On 10/5/10 10:29 AM, Lukas Renggli wrote:
>>
>> ? http://book.seaside.st/
>> ? http://book.pharo-project.org/
>> ? http://www.themoosebook.org/book/
>
> Thanks Lukas, I had thought of the book component just after I clicked send.
>
> I know there's a latex printer. I assume there's a pdf printer as well?

Yes, your LaTeX compiler is creating a PDF.

> I see mention of a text printer for page components. Does that keep table,
> etc, formatting in some way, also?

Very limited, but if you have a specific idea of how to represent the
formatting it is very easy to create a new subclass of
PRDocumentWriter.

> IETF document requirements are extremely weird. It would be very kool if
> Pier could be used to create online versions and then have them print
> directly into the standard RFC format.

That should be easily possible.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Tue Oct  5 20:01:08 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 11:01:08 -0700
Subject: collaborative documentation in pier
In-Reply-To: <AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
References: <4CAB5F43.9050905@cox.net>	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>	<4CAB63CA.8060307@cox.net>
	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
Message-ID: <4CAB67E4.6080803@cox.net>

  On 10/5/10 10:50 AM, Lukas Renggli wrote:
>
>> IETF document requirements are extremely weird. It would be very kool if
>> Pier could be used to create online versions and then have them print
>> directly into the standard RFC format.
> That should be easily possible.
>
> Lukas
>

Is there a how-to for setting up a book component?

Just adding a book component to the menu doesn't seem to do much 
automatically that I can see.


Lawson



From lenglish5 at cox.net  Tue Oct  5 20:04:38 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 11:04:38 -0700
Subject: collaborative documentation in pier
In-Reply-To: <AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
References: <4CAB5F43.9050905@cox.net>	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>	<4CAB63CA.8060307@cox.net>
	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
Message-ID: <4CAB68B6.9030205@cox.net>

  On 10/5/10 10:50 AM, Lukas Renggli wrote:
>
>> IETF document requirements are extremely weird. It would be very kool if
>> Pier could be used to create online versions and then have them print
>> directly into the standard RFC format.
> That should be easily possible.
>
> Lukas
>

This is what we're using currently (VWRAP is a virtual worlds protocol 
group for the IETF).

Seems to me that this functionality (and more) would be a useful 
alternate default for Pier.


Lawson

From renggli at gmail.com  Tue Oct  5 20:06:22 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 5 Oct 2010 20:06:22 +0200
Subject: collaborative documentation in pier
In-Reply-To: <4CAB67E4.6080803@cox.net>
References: <4CAB5F43.9050905@cox.net>
	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
	<4CAB63CA.8060307@cox.net>
	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
	<4CAB67E4.6080803@cox.net>
Message-ID: <AANLkTikCmKP46oNoDdKkmbfq3M9wzDWOug35Ct+7Yd8q@mail.gmail.com>

On 5 October 2010 20:01, Lawson English <lenglish5 at cox.net> wrote:
> ?On 10/5/10 10:50 AM, Lukas Renggli wrote:
>>
>>> IETF document requirements are extremely weird. It would be very kool if
>>> Pier could be used to create online versions and then have them print
>>> directly into the standard RFC format.
>>
>> That should be easily possible.
>>
>> Lukas
>>
>
> Is there a how-to for setting up a book component?

The One-Click image contains a template on the front-page.

Could you please stop sending mails to my private e-mail and to change
the reply-to to your private e-mail?

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Tue Oct  5 20:07:31 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 11:07:31 -0700
Subject: collaborative documentation in pier
In-Reply-To: <4CAB68B6.9030205@cox.net>
References: <4CAB5F43.9050905@cox.net>	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>	<4CAB63CA.8060307@cox.net>	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
	<4CAB68B6.9030205@cox.net>
Message-ID: <4CAB6963.2030807@cox.net>

  On 10/5/10 11:04 AM, Lawson English wrote:
>
> This is what we're using currently (VWRAP is a virtual worlds protocol 
> group for the IETF).
>
> Seems to me that this functionality (and more) would be a useful 
> alternate default for Pier.
>
>
>
Er, left out the link: http://vwrap-playpen.wikispaces.com/page/notify/home


From renggli at gmail.com  Tue Oct  5 20:12:05 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 5 Oct 2010 20:12:05 +0200
Subject: collaborative documentation in pier
In-Reply-To: <4CAB68B6.9030205@cox.net>
References: <4CAB5F43.9050905@cox.net>
	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
	<4CAB63CA.8060307@cox.net>
	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
	<4CAB68B6.9030205@cox.net>
Message-ID: <AANLkTims_BeNX4r8Crom6dVTiti1bdLF27PY9g74LwWv@mail.gmail.com>

> This is what we're using currently (VWRAP is a virtual worlds protocol group
> for the IETF).
>
> Seems to me that this functionality (and more) would be a useful alternate
> default for Pier.

Sure, if somebody knowledgeable implements it. I never heard about
IETF, VWRAP, ...

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From lenglish5 at cox.net  Tue Oct  5 20:14:36 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 11:14:36 -0700
Subject: collaborative documentation in pier
In-Reply-To: <AANLkTikCmKP46oNoDdKkmbfq3M9wzDWOug35Ct+7Yd8q@mail.gmail.com>
References: <4CAB5F43.9050905@cox.net>	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>	<4CAB63CA.8060307@cox.net>	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>	<4CAB67E4.6080803@cox.net>
	<AANLkTikCmKP46oNoDdKkmbfq3M9wzDWOug35Ct+7Yd8q@mail.gmail.com>
Message-ID: <4CAB6B0C.1020807@cox.net>

  On 10/5/10 11:06 AM, Lukas Renggli wrote:
>
> The One-Click image contains a template on the front-page.
>

Thanks.
> Could you please stop sending mails to my private e-mail and to change
> the reply-to to your private e-mail?
>
> Lukas
>
Is this better?

Lawson


From renggli at gmail.com  Tue Oct  5 20:16:32 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 5 Oct 2010 20:16:32 +0200
Subject: collaborative documentation in pier
In-Reply-To: <4CAB6B0C.1020807@cox.net>
References: <4CAB5F43.9050905@cox.net>
	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>
	<4CAB63CA.8060307@cox.net>
	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>
	<4CAB67E4.6080803@cox.net>
	<AANLkTikCmKP46oNoDdKkmbfq3M9wzDWOug35Ct+7Yd8q@mail.gmail.com>
	<4CAB6B0C.1020807@cox.net>
Message-ID: <AANLkTi=ST0QqvEBgGwh0XpH0wM2drE0_kv-0Wk-FTR0v@mail.gmail.com>

>> Could you please stop sending mails to my private e-mail and to change
>> the reply-to to your private e-mail?
>>
>> Lukas
>>
> Is this better?

Yep, perfect. Thank you.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From lenglish5 at cox.net  Tue Oct  5 21:31:11 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 05 Oct 2010 12:31:11 -0700
Subject: collaborative documentation in pier
In-Reply-To: <AANLkTims_BeNX4r8Crom6dVTiti1bdLF27PY9g74LwWv@mail.gmail.com>
References: <4CAB5F43.9050905@cox.net>	<AANLkTi=9aNXg_H-4gfWgkfqfaZWFHoGgmEr88LFpnL4u@mail.gmail.com>	<4CAB63CA.8060307@cox.net>	<AANLkTikbs9BShWFwzFmhU7WsW4aHGW=udjHNXC0jYbd_@mail.gmail.com>	<4CAB68B6.9030205@cox.net>
	<AANLkTims_BeNX4r8Crom6dVTiti1bdLF27PY9g74LwWv@mail.gmail.com>
Message-ID: <4CAB7CFF.4000504@cox.net>

  On 10/5/10 11:12 AM, Lukas Renggli wrote:
>> This is what we're using currently (VWRAP is a virtual worlds protocol group
>> for the IETF).
>>
>> Seems to me that this functionality (and more) would be a useful alternate
>> default for Pier.
> Sure, if somebody knowledgeable implements it. I never heard about
> IETF, VWRAP, ...
>

IETF is the Internet Engineering Task Force -the official internet RFC 
guys.  http://www.ietf.org/ VWRAP is an ietf working group trying to 
devise protocols to work across multiple virtual worlds, so avatars from 
one virtual world can visit another with minimal complications.





From renggli at gmail.com  Thu Oct  7 14:34:24 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 7 Oct 2010 14:34:24 +0200
Subject: [Pier2] Pier-JQuery-lr.1.mcz in pier2addons
Message-ID: <AANLkTimu08dhV7cmky=9_CXKjzT-VLZajzi9Y=8fqSYF@mail.gmail.com>

@Nick: I committed Pier-JQuery-lr.1.mcz to pier2addons, but I didn't
notice until after the commit that you essentially did the same
already a long time ago. The widget in the package essentially removes
the AJAX search widget from Pier-Seaside, ports it is JQueryUI and
moves it into the new package. Now the question is what implementation
to keep? The code in Pier-JQuery-lr.1.mcz only depends on JQueryUI,
while your changes seem to require more. Also Pier-JQuery-lr.1.mcz
uses some simpler mechanism I introduced into JQueryUI just now.

@Damien: The same package also contains two value links we talked
about yesterday. With the following links it is possible to present
the children (or any other set of structures) within a tab-panel or
within an accordion.

  +value:jq-tabs+
  +value:jq-accordion+

Of course both require the JQuery library, the JQueryUI library and a
JQueryUI theme.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From nick.ager at gmail.com  Thu Oct  7 15:16:42 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Thu, 7 Oct 2010 14:16:42 +0100
Subject: [Pier2] Pier-JQuery-lr.1.mcz in pier2addons
In-Reply-To: <AANLkTimu08dhV7cmky=9_CXKjzT-VLZajzi9Y=8fqSYF@mail.gmail.com>
References: <AANLkTimu08dhV7cmky=9_CXKjzT-VLZajzi9Y=8fqSYF@mail.gmail.com>
Message-ID: <AANLkTim0QykSeE3V1XKMbyEJ=WdBWL_svoyu=9Tnd=O1@mail.gmail.com>

Hi Lucas,

On 7 October 2010 13:34, Lukas Renggli <renggli at gmail.com> wrote:

> @Nick: I committed Pier-JQuery-lr.1.mcz to pier2addons, but I didn't
> notice until after the commit that you essentially did the same
> already a long time ago. The widget in the package essentially removes
> the AJAX search widget from Pier-Seaside, ports it is JQueryUI and
> moves it into the new package. Now the question is what implementation
> to keep? The code in Pier-JQuery-lr.1.mcz only depends on JQueryUI,
> while your changes seem to require more. Also Pier-JQuery-lr.1.mcz
> uses some simpler mechanism I introduced into JQueryUI just now.
>

I've browsed your code, but haven't loaded it.
It does look a lot simpler and neater.
My package is dependant on JQWidgetBox-FormExample as a replacement for the
deprecated WAAbstractTextArea>>exampleText:
I'm currently not using it - so I'm inclined to say you should delete it -
though it would be helpful if you could extend yours to support an
equivalent interface. The two missing methods are:
* descriptionExampleText "specify example text"
* descriptionStructure "specify the root structure for the search"

Are you intending that the default Pier installation in PRDistribution moves
to JQuery rather than Scriptaculous? That was my aim.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101007/0ea8af2f/attachment.html>

From renggli at gmail.com  Thu Oct  7 15:30:50 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 7 Oct 2010 15:30:50 +0200
Subject: [Pier2] Pier-JQuery-lr.1.mcz in pier2addons
In-Reply-To: <AANLkTim0QykSeE3V1XKMbyEJ=WdBWL_svoyu=9Tnd=O1@mail.gmail.com>
References: <AANLkTimu08dhV7cmky=9_CXKjzT-VLZajzi9Y=8fqSYF@mail.gmail.com>
	<AANLkTim0QykSeE3V1XKMbyEJ=WdBWL_svoyu=9Tnd=O1@mail.gmail.com>
Message-ID: <AANLkTim07Usx4ZZJCHi+dH=-EDt0=tOY=NvMDJgADLPt@mail.gmail.com>

> * descriptionExampleText "specify example text"
> * descriptionStructure "specify the root structure for the search"

Ok, I will add those. They got lost.

> Are you intending that the default Pier installation in PRDistribution moves
> to JQuery rather than Scriptaculous? That was my aim.

Yeah, script.aculo.us is essentially dead. However, I would like to
keep the JQuery specific code in a separate package, so that Pier does
not start to depend on a particular Javascript library.

-- 
Lukas Renggli
www.lukas-renggli.ch

From norbert at hartl.name  Fri Oct  8 11:27:16 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 11:27:16 +0200
Subject: commands and value links
Message-ID: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>

I'm trying to create a value link that can display a single command inside a document. But I struggled to create a proper link for the command. This seems only possible if you have a pier context and renderer at the same time which is not really the case as long as you are staying inside PRValueLink.

The only solution I could come up with is the following:

PRValueLink>>commandIn: aContext
	<value: 'command' comment: 'Display command as link'>
	(PRCommand withAllConcreteClasses
		detect: [ :each | each label = (self parameterAt: 'label' ) ]
		ifNone: [ ^ nil ])
			ifNotNilDo: [ :commandClass |
				^ [ :html | 
					html anchor
						goto: (aContext command: commandClass new);
						with: commandClass label]].
	^ nil

I have the impression there might be a solution without using a block. Any ideas? Or is it ok the way it is?

thanks,

Norbert



From renggli at gmail.com  Fri Oct  8 11:36:53 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 11:36:53 +0200
Subject: commands and value links
In-Reply-To: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
Message-ID: <AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>

Actually this is already implemented, for example:

     *value:structure|link|command=Remove*

Also works with all other value-links that list or return structures,
e.g. children, references, parent, previous, random, siblings, find,
...

Lukas

On 8 October 2010 11:27, Norbert Hartl <norbert at hartl.name> wrote:
> I'm trying to create a value link that can display a single command inside a document. But I struggled to create a proper link for the command. This seems only possible if you have a pier context and renderer at the same time which is not really the case as long as you are staying inside PRValueLink.
>
> The only solution I could come up with is the following:
>
> PRValueLink>>commandIn: aContext
> ? ? ? ?<value: 'command' comment: 'Display command as link'>
> ? ? ? ?(PRCommand withAllConcreteClasses
> ? ? ? ? ? ? ? ?detect: [ :each | each label = (self parameterAt: 'label' ) ]
> ? ? ? ? ? ? ? ?ifNone: [ ^ nil ])
> ? ? ? ? ? ? ? ? ? ? ? ?ifNotNilDo: [ :commandClass |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ [ :html |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?html anchor
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goto: (aContext command: commandClass new);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?with: commandClass label]].
> ? ? ? ?^ nil
>
> I have the impression there might be a solution without using a block. Any ideas? Or is it ok the way it is?
>
> thanks,
>
> Norbert
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Fri Oct  8 11:38:36 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 11:38:36 +0200
Subject: commands and value links
In-Reply-To: <AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
Message-ID: <AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>

And in fact you don't need to use a value link for triggering a
command, a normal link with the command parameter is enough:

   */some/page/to/edit|command=Edit*

Note that in both cases this goes through the security system.

Lukas

On 8 October 2010 11:36, Lukas Renggli <renggli at gmail.com> wrote:
> Actually this is already implemented, for example:
>
> ? ? *value:structure|link|command=Remove*
>
> Also works with all other value-links that list or return structures,
> e.g. children, references, parent, previous, random, siblings, find,
> ...
>
> Lukas
>
> On 8 October 2010 11:27, Norbert Hartl <norbert at hartl.name> wrote:
>> I'm trying to create a value link that can display a single command inside a document. But I struggled to create a proper link for the command. This seems only possible if you have a pier context and renderer at the same time which is not really the case as long as you are staying inside PRValueLink.
>>
>> The only solution I could come up with is the following:
>>
>> PRValueLink>>commandIn: aContext
>> ? ? ? ?<value: 'command' comment: 'Display command as link'>
>> ? ? ? ?(PRCommand withAllConcreteClasses
>> ? ? ? ? ? ? ? ?detect: [ :each | each label = (self parameterAt: 'label' ) ]
>> ? ? ? ? ? ? ? ?ifNone: [ ^ nil ])
>> ? ? ? ? ? ? ? ? ? ? ? ?ifNotNilDo: [ :commandClass |
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ [ :html |
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?html anchor
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goto: (aContext command: commandClass new);
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?with: commandClass label]].
>> ? ? ? ?^ nil
>>
>> I have the impression there might be a solution without using a block. Any ideas? Or is it ok the way it is?
>>
>> thanks,
>>
>> Norbert
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Fri Oct  8 12:58:35 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 12:58:35 +0200
Subject: commands and value links
In-Reply-To: <AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
Message-ID: <D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>


On 08.10.2010, at 11:38, Lukas Renggli wrote:

> And in fact you don't need to use a value link for triggering a
> command, a normal link with the command parameter is enough:
> 
>   */some/page/to/edit|command=Edit*
> 
> Note that in both cases this goes through the security system.
> 
Ok, everytime I think I have a useful idea it is already there and better implemented :) It is nice that I can do it either one or the other way. But the link text is always the title of the target structure. I need the link label to be displayed. In the second approach can do it manually with *Label>/some...* (does not work with the first approach *Label>value:...*. Is there a way to display the link label? 

thanks,

norbert


> 
> On 8 October 2010 11:36, Lukas Renggli <renggli at gmail.com> wrote:
>> Actually this is already implemented, for example:
>> 
>>     *value:structure|link|command=Remove*
>> 
>> Also works with all other value-links that list or return structures,
>> e.g. children, references, parent, previous, random, siblings, find,
>> ...
>> 
>> Lukas
>> 
>> On 8 October 2010 11:27, Norbert Hartl <norbert at hartl.name> wrote:
>>> I'm trying to create a value link that can display a single command inside a document. But I struggled to create a proper link for the command. This seems only possible if you have a pier context and renderer at the same time which is not really the case as long as you are staying inside PRValueLink.
>>> 
>>> The only solution I could come up with is the following:
>>> 
>>> PRValueLink>>commandIn: aContext
>>>        <value: 'command' comment: 'Display command as link'>
>>>        (PRCommand withAllConcreteClasses
>>>                detect: [ :each | each label = (self parameterAt: 'label' ) ]
>>>                ifNone: [ ^ nil ])
>>>                        ifNotNilDo: [ :commandClass |
>>>                                ^ [ :html |
>>>                                        html anchor
>>>                                                goto: (aContext command: commandClass new);
>>>                                                with: commandClass label]].
>>>        ^ nil
>>> 
>>> I have the impression there might be a solution without using a block. Any ideas? Or is it ok the way it is?
>>> 
>>> thanks,
>>> 
>>> Norbert
>>> 
>>> 
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>> 
>> 
>> 
>> 
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101008/fc8d240f/attachment.html>

From renggli at gmail.com  Fri Oct  8 13:42:04 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 13:42:04 +0200
Subject: commands and value links
In-Reply-To: <D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
Message-ID: <AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>

> label to be displayed. In the second approach can do it manually with
> *Label>/some...* (does not work with the first approach *Label>value:...*.
> Is there a way to display the link label?

ValueLinks only display the label when they are undefined. Otherwise
they display the default string of the target (e.g. the title) or
whatever display parameter (this is the name of a description on the
object) is set.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From norbert at hartl.name  Fri Oct  8 14:22:22 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 14:22:22 +0200
Subject: commands and value links
In-Reply-To: <AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
Message-ID: <FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>


On 08.10.2010, at 13:42, Lukas Renggli wrote:

>> label to be displayed. In the second approach can do it manually with
>> *Label>/some...* (does not work with the first approach *Label>value:...*.
>> Is there a way to display the link label?
> 
> ValueLinks only display the label when they are undefined. Otherwise
> they display the default string of the target (e.g. the title) or
> whatever display parameter (this is the name of a description on the
> object) is set.

The first sentence I don't get. I understand the default behaviour (title) and the display attribute the choses a selector. But all of this is happening on the structure. I want to have the label from the command that is being used. Compare it to PRCommandWidget it displays the labels of all available commands. I want to have to same as value link.

thanks,

Norbert



From lenglish5 at cox.net  Fri Oct  8 14:37:59 2010
From: lenglish5 at cox.net (Lawson English)
Date: Fri, 08 Oct 2010 05:37:59 -0700
Subject: commands and value links
In-Reply-To: <FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
Message-ID: <4CAF10A7.2050809@cox.net>

  On 10/8/10 5:22 AM, Norbert Hartl wrote:
> On 08.10.2010, at 13:42, Lukas Renggli wrote:
>
>>> label to be displayed. In the second approach can do it manually with
>>> *Label>/some...* (does not work with the first approach *Label>value:...*.
>>> Is there a way to display the link label?
>> ValueLinks only display the label when they are undefined. Otherwise
>> they display the default string of the target (e.g. the title) or
>> whatever display parameter (this is the name of a description on the
>> object) is set.
> The first sentence I don't get. I understand the default behaviour (title) and the display attribute the choses a selector. But all of this is happening on the structure. I want to have the label from the command that is being used. Compare it to PRCommandWidget it displays the labels of all available commands. I want to have to same as value link.
>

+value:commands+ displays all the available value links because it 
displays all selectors of methods that have the proper <pragma> in them. 
You're talking about displaying the options available for a specific 
value link and there's no built-in mechanism for that. You'd have to 
provide it yourself. You could request all parameters for +value:xxx+ 
that was passed to the >>xxxIn:contents      method, but that would only 
give you the parameters/commands that are specified in the text of the 
link. If you want to provide a list of all possible options, you'll have 
to define one yourself:

+value:myValueLink|command=displayAll+    and from inside method 
 >>myValueLink:contents, you'd return a list of all the options you 
defined within >>myValueLink:contents.


Lawson


From norbert at hartl.name  Fri Oct  8 14:50:14 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 14:50:14 +0200
Subject: commands and value links
In-Reply-To: <4CAF10A7.2050809@cox.net>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
Message-ID: <74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>


On 08.10.2010, at 14:37, Lawson English wrote:

> On 10/8/10 5:22 AM, Norbert Hartl wrote:
>> On 08.10.2010, at 13:42, Lukas Renggli wrote:
>> 
>>>> label to be displayed. In the second approach can do it manually with
>>>> *Label>/some...* (does not work with the first approach *Label>value:...*.
>>>> Is there a way to display the link label?
>>> ValueLinks only display the label when they are undefined. Otherwise
>>> they display the default string of the target (e.g. the title) or
>>> whatever display parameter (this is the name of a description on the
>>> object) is set.
>> The first sentence I don't get. I understand the default behaviour (title) and the display attribute the choses a selector. But all of this is happening on the structure. I want to have the label from the command that is being used. Compare it to PRCommandWidget it displays the labels of all available commands. I want to have to same as value link.
>> 
> 
> +value:commands+ displays all the available value links because it displays all selectors of methods that have the proper <pragma> in them. You're talking about displaying the options available for a specific value link and there's no built-in mechanism for that. You'd have to provide it yourself. You could request all parameters for +value:xxx+ that was passed to the >>xxxIn:contents      method, but that would only give you the parameters/commands that are specified in the text of the link. If you want to provide a list of all possible options, you'll have to define one yourself:
> 
> +value:myValueLink|command=displayAll+    and from inside method >>myValueLink:contents, you'd return a list of all the options you defined within >>myValueLink:contents.

Wow, I think I didn't understand a single bit of what you trying to say :) Probably it just does not make any sense what I'm saying.
Again. I have a custom command that creates a special kind of page for me. The command is displayed in the footer along the other pier commands. What I really want to do: I just want to have an easy way to display this single command anywhere on a page. With displaying I mean creating a link that when pressed executes the command.

Norbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101008/b01aec64/attachment.html>

From renggli at gmail.com  Fri Oct  8 14:54:58 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 14:54:58 +0200
Subject: commands and value links
In-Reply-To: <74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
Message-ID: <AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>

With

  Name: Pier-Model-lr.390
  Author: lr
  Time: 8 October 2010, 2:51:59 pm
  UUID: b4990979-0e1b-4e68-97c6-eb316ec0e065
  Ancestors: Pier-Model-DamienCassou.389

  - return the display string of value links

you can do

  *value:structure|link|command=Remove|display=Remove Me*

where the parameter 'display' is the name of a description on the
structure (as previously), or an arbitrary string that is returned
otherwise (newly added). Ok this is not as nice as it could be, but if
I find some more time it might get extended. I imagine something like
...

    Remove %{title}

where title would be a parameter of the structure.

Lukas

On 8 October 2010 14:50, Norbert Hartl <norbert at hartl.name> wrote:
>
> On 08.10.2010, at 14:37, Lawson English wrote:
>
> On 10/8/10 5:22 AM, Norbert Hartl wrote:
>
> On 08.10.2010, at 13:42, Lukas Renggli wrote:
>
> label to be displayed. In the second approach can do it manually with
>
> *Label>/some...* (does not work with the first approach *Label>value:...*.
>
> Is there a way to display the link label?
>
> ValueLinks only display the label when they are undefined. Otherwise
>
> they display the default string of the target (e.g. the title) or
>
> whatever display parameter (this is the name of a description on the
>
> object) is set.
>
> The first sentence I don't get. I understand the default behaviour (title)
> and the display attribute the choses a selector. But all of this is
> happening on the structure. I want to have the label from the command that
> is being used. Compare it to PRCommandWidget it displays the labels of all
> available commands. I want to have to same as value link.
>
>
> +value:commands+ displays all the available value links because it displays
> all selectors of methods that have the proper <pragma> in them. You're
> talking about displaying the options available for a specific value link and
> there's no built-in mechanism for that. You'd have to provide it yourself.
> You could request all parameters for +value:xxx+ that was passed to the
>>>xxxIn:contents ?????method, but that would only give you the
> parameters/commands that are specified in the text of the link. If you want
> to provide a list of all possible options, you'll have to define one
> yourself:
>
> +value:myValueLink|command=displayAll+ ???and from inside method
>>>myValueLink:contents, you'd return a list of all the options you defined
> within >>myValueLink:contents.
>
> Wow, I think I didn't understand a single bit of what you trying to say :)
> Probably it just does not make any sense what I'm saying.
> Again. I have a custom command that creates a special kind of page for me.
> The command is displayed in the footer along the other pier commands. What I
> really want to do: I just want to have an easy way to display this single
> command anywhere on a page. With displaying I mean creating a link that when
> pressed executes the command.
> Norbert
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Fri Oct  8 15:24:15 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 15:24:15 +0200
Subject: commands and value links
In-Reply-To: <AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
Message-ID: <AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>

Name: Pier-Model-lr.391
Author: lr
Time: 8 October 2010, 3:19:12 pm
UUID: ec6a7b61-a129-4fe1-b7dc-1a195b43da2c
Ancestors: Pier-Model-lr.390

- added the possibility to format value links like
*value:contents|link|command=Remove|display=Remove '{title}' owned by
{owner}*

On 8 October 2010 14:54, Lukas Renggli <renggli at gmail.com> wrote:
> With
>
> ?Name: Pier-Model-lr.390
> ?Author: lr
> ?Time: 8 October 2010, 2:51:59 pm
> ?UUID: b4990979-0e1b-4e68-97c6-eb316ec0e065
> ?Ancestors: Pier-Model-DamienCassou.389
>
> ?- return the display string of value links
>
> you can do
>
> ?*value:structure|link|command=Remove|display=Remove Me*
>
> where the parameter 'display' is the name of a description on the
> structure (as previously), or an arbitrary string that is returned
> otherwise (newly added). Ok this is not as nice as it could be, but if
> I find some more time it might get extended. I imagine something like
> ...
>
> ? ?Remove %{title}
>
> where title would be a parameter of the structure.
>
> Lukas
>
> On 8 October 2010 14:50, Norbert Hartl <norbert at hartl.name> wrote:
>>
>> On 08.10.2010, at 14:37, Lawson English wrote:
>>
>> On 10/8/10 5:22 AM, Norbert Hartl wrote:
>>
>> On 08.10.2010, at 13:42, Lukas Renggli wrote:
>>
>> label to be displayed. In the second approach can do it manually with
>>
>> *Label>/some...* (does not work with the first approach *Label>value:...*.
>>
>> Is there a way to display the link label?
>>
>> ValueLinks only display the label when they are undefined. Otherwise
>>
>> they display the default string of the target (e.g. the title) or
>>
>> whatever display parameter (this is the name of a description on the
>>
>> object) is set.
>>
>> The first sentence I don't get. I understand the default behaviour (title)
>> and the display attribute the choses a selector. But all of this is
>> happening on the structure. I want to have the label from the command that
>> is being used. Compare it to PRCommandWidget it displays the labels of all
>> available commands. I want to have to same as value link.
>>
>>
>> +value:commands+ displays all the available value links because it displays
>> all selectors of methods that have the proper <pragma> in them. You're
>> talking about displaying the options available for a specific value link and
>> there's no built-in mechanism for that. You'd have to provide it yourself.
>> You could request all parameters for +value:xxx+ that was passed to the
>>>>xxxIn:contents ?????method, but that would only give you the
>> parameters/commands that are specified in the text of the link. If you want
>> to provide a list of all possible options, you'll have to define one
>> yourself:
>>
>> +value:myValueLink|command=displayAll+ ???and from inside method
>>>>myValueLink:contents, you'd return a list of all the options you defined
>> within >>myValueLink:contents.
>>
>> Wow, I think I didn't understand a single bit of what you trying to say :)
>> Probably it just does not make any sense what I'm saying.
>> Again. I have a custom command that creates a special kind of page for me.
>> The command is displayed in the footer along the other pier commands. What I
>> really want to do: I just want to have an easy way to display this single
>> command anywhere on a page. With displaying I mean creating a link that when
>> pressed executes the command.
>> Norbert
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From jvdsandt at gmail.com  Fri Oct  8 15:27:48 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Fri, 8 Oct 2010 15:27:48 +0200
Subject: Magritte-XMLBinding API question
Message-ID: <AANLkTi=4r5T0rB3KVVGyvn=1wzmt+OjwVBt4foX1+b8U@mail.gmail.com>

Hello,



I?m working on the Magritte-XMLBinding package. With this package you can
export Magritte objects as XML and read Magritte described objects from XML.
I would like to have a nice simple API that is easy to understand. I?m
looking for some feedback.



Assume we have the following description:



MXPerson>>descriptionName



            ^MAStringDescription new

                        accessor: #name;

                        label: 'Name';



If we want to export the name property as a xml element we add the
beXmlElement message. By default it will add an extra element with the
accessor name as the element name and the value as the element contents:



<MXPerson>

            <name>Pete</name>

</MXPerson>



Optionally we can specify an alternative xml element name:



description

            beXmlElement;

            xmlElementName: 'person-name'.



Or do you like this API better?



description

            beXmlElement: 'person-name'.



The output:



<MXPerson>

            <person-name>Pete</person-name>

</MXPerson>



It is also possible to store a property as an xml attribute of the parent
element:



description

            beXmlAttribute.



<MXPerson name='Pete'>

</MXPerson>



Or in a property of a separate element:



description

            beXmlElementWithAttribute



<MXPerson>

            <name value='Pete' />

 </MXPerson>



The element and attribute names can be customized:



description

beXmlElementWithAttribute;

xmlElementName: 'xname';

xmlAttributeName: 'yvalue'.



OR:



description

beXmlElement: 'xname' withAttribute: 'yvalue'.



Is the "be" message with arguments better or should a "be" message always
have zero arguments?

Jan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101008/737c753a/attachment-0001.html>

From norbert at hartl.name  Fri Oct  8 15:32:46 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 15:32:46 +0200
Subject: commands and value links
In-Reply-To: <AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
	<AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
Message-ID: <1DEA33DA-A4BA-47B9-8C66-372AF4E62125@hartl.name>


On 08.10.2010, at 15:24, Lukas Renggli wrote:

> Name: Pier-Model-lr.391
> Author: lr
> Time: 8 October 2010, 3:19:12 pm
> UUID: ec6a7b61-a129-4fe1-b7dc-1a195b43da2c
> Ancestors: Pier-Model-lr.390
> 
> - added the possibility to format value links like
> *value:contents|link|command=Remove|display=Remove '{title}' owned by
> {owner}*
> 
ha ha, you are funny. That was three minutes between the two last mails. I can imagine what worked in your head. Great! Thanks.

Norbert

> On 8 October 2010 14:54, Lukas Renggli <renggli at gmail.com> wrote:
>> With
>> 
>>  Name: Pier-Model-lr.390
>>  Author: lr
>>  Time: 8 October 2010, 2:51:59 pm
>>  UUID: b4990979-0e1b-4e68-97c6-eb316ec0e065
>>  Ancestors: Pier-Model-DamienCassou.389
>> 
>>  - return the display string of value links
>> 
>> you can do
>> 
>>  *value:structure|link|command=Remove|display=Remove Me*
>> 
>> where the parameter 'display' is the name of a description on the
>> structure (as previously), or an arbitrary string that is returned
>> otherwise (newly added). Ok this is not as nice as it could be, but if
>> I find some more time it might get extended. I imagine something like
>> ...
>> 
>>    Remove %{title}
>> 
>> where title would be a parameter of the structure.
>> 
>> Lukas
>> 
>> On 8 October 2010 14:50, Norbert Hartl <norbert at hartl.name> wrote:
>>> 
>>> On 08.10.2010, at 14:37, Lawson English wrote:
>>> 
>>> On 10/8/10 5:22 AM, Norbert Hartl wrote:
>>> 
>>> On 08.10.2010, at 13:42, Lukas Renggli wrote:
>>> 
>>> label to be displayed. In the second approach can do it manually with
>>> 
>>> *Label>/some...* (does not work with the first approach *Label>value:...*.
>>> 
>>> Is there a way to display the link label?
>>> 
>>> ValueLinks only display the label when they are undefined. Otherwise
>>> 
>>> they display the default string of the target (e.g. the title) or
>>> 
>>> whatever display parameter (this is the name of a description on the
>>> 
>>> object) is set.
>>> 
>>> The first sentence I don't get. I understand the default behaviour (title)
>>> and the display attribute the choses a selector. But all of this is
>>> happening on the structure. I want to have the label from the command that
>>> is being used. Compare it to PRCommandWidget it displays the labels of all
>>> available commands. I want to have to same as value link.
>>> 
>>> 
>>> +value:commands+ displays all the available value links because it displays
>>> all selectors of methods that have the proper <pragma> in them. You're
>>> talking about displaying the options available for a specific value link and
>>> there's no built-in mechanism for that. You'd have to provide it yourself.
>>> You could request all parameters for +value:xxx+ that was passed to the
>>>>> xxxIn:contents      method, but that would only give you the
>>> parameters/commands that are specified in the text of the link. If you want
>>> to provide a list of all possible options, you'll have to define one
>>> yourself:
>>> 
>>> +value:myValueLink|command=displayAll+    and from inside method
>>>>> myValueLink:contents, you'd return a list of all the options you defined
>>> within >>myValueLink:contents.
>>> 
>>> Wow, I think I didn't understand a single bit of what you trying to say :)
>>> Probably it just does not make any sense what I'm saying.
>>> Again. I have a custom command that creates a special kind of page for me.
>>> The command is displayed in the footer along the other pier commands. What I
>>> really want to do: I just want to have an easy way to display this single
>>> command anywhere on a page. With displaying I mean creating a link that when
>>> pressed executes the command.
>>> Norbert
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>> 
>> 
>> 
>> 
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From lenglish5 at cox.net  Fri Oct  8 16:30:54 2010
From: lenglish5 at cox.net (Lawson English)
Date: Fri, 08 Oct 2010 07:30:54 -0700
Subject: commands and value links
In-Reply-To: <AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>	<4CAF10A7.2050809@cox.net>	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
	<AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
Message-ID: <4CAF2B1E.1090409@cox.net>

  On 10/8/10 6:24 AM, Lukas Renggli wrote:
> Name: Pier-Model-lr.391
> Author: lr
> Time: 8 October 2010, 3:19:12 pm
> UUID: ec6a7b61-a129-4fe1-b7dc-1a195b43da2c
> Ancestors: Pier-Model-lr.390
>
> - added the possibility to format value links like
> *value:contents|link|command=Remove|display=Remove '{title}' owned by
> {owner}*

Are these options parsed before the xxxIn: method gets to see the 
parameter list?


Lawson


From renggli at gmail.com  Fri Oct  8 16:38:42 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 16:38:42 +0200
Subject: commands and value links
In-Reply-To: <4CAF2B1E.1090409@cox.net>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
	<AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
	<4CAF2B1E.1090409@cox.net>
Message-ID: <AANLkTim-w0HKLmxTAXp7WCxYScCp6_vaCwTxxiV+VHuQ@mail.gmail.com>

Yes, link parameters are parsed at the very beginning and put into a
parameter dictionary of the link.

Lukas

On 8 October 2010 16:30, Lawson English <lenglish5 at cox.net> wrote:
> ?On 10/8/10 6:24 AM, Lukas Renggli wrote:
>>
>> Name: Pier-Model-lr.391
>> Author: lr
>> Time: 8 October 2010, 3:19:12 pm
>> UUID: ec6a7b61-a129-4fe1-b7dc-1a195b43da2c
>> Ancestors: Pier-Model-lr.390
>>
>> - added the possibility to format value links like
>> *value:contents|link|command=Remove|display=Remove '{title}' owned by
>> {owner}*
>
> Are these options parsed before the xxxIn: method gets to see the parameter
> list?
>
>
> Lawson
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Fri Oct  8 17:28:19 2010
From: lenglish5 at cox.net (Lawson English)
Date: Fri, 08 Oct 2010 08:28:19 -0700
Subject: commands and value links
In-Reply-To: <AANLkTim-w0HKLmxTAXp7WCxYScCp6_vaCwTxxiV+VHuQ@mail.gmail.com>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>	<4CAF10A7.2050809@cox.net>	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>	<AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>	<4CAF2B1E.1090409@cox.net>
	<AANLkTim-w0HKLmxTAXp7WCxYScCp6_vaCwTxxiV+VHuQ@mail.gmail.com>
Message-ID: <4CAF3893.3020809@cox.net>

  On 10/8/10 7:38 AM, Lukas Renggli wrote:
> Yes, link parameters are parsed at the very beginning and put into a
> parameter dictionary of the link.
>
> Lukas
So proper use would be:

*value:contents|link|command=Remove|display=Remove '{title}' owned by
{owner}|mystuff=stuff|morestuff=otherstuff*

Assuming that we extended>>contentsIn:   in some way...


Is there a difference between using '+' and '*' in the context of value links?




> On 8 October 2010 16:30, Lawson English<lenglish5 at cox.net>  wrote:
>>   On 10/8/10 6:24 AM, Lukas Renggli wrote:
>>> Name: Pier-Model-lr.391
>>> Author: lr
>>> Time: 8 October 2010, 3:19:12 pm
>>> UUID: ec6a7b61-a129-4fe1-b7dc-1a195b43da2c
>>> Ancestors: Pier-Model-lr.390
>>>
>>> - added the possibility to format value links like
>>> *value:contents|link|command=Remove|display=Remove '{title}' owned by
>>> {owner}*
>> Are these options parsed before the xxxIn: method gets to see the parameter
>> list?
>>
>>
>> Lawson
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>


From renggli at gmail.com  Fri Oct  8 17:44:38 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 8 Oct 2010 17:44:38 +0200
Subject: commands and value links
In-Reply-To: <4CAF3893.3020809@cox.net>
References: <5A1F9A74-9742-4079-A477-420A690BAE04@hartl.name>
	<AANLkTimdBwy8vyhC9XW5aGRPTgdqG4JZp3nB=snXbxeG@mail.gmail.com>
	<AANLkTikJFbKOq2_9kwgJRRU8Sz8MNDVQyhVP4E5kemr8@mail.gmail.com>
	<D9E241EB-5E00-4E33-ACBC-99EBD41AC63B@hartl.name>
	<AANLkTinsEfmLmokQxJSnxCHbks-9Nwt46wCnAKSk4TLk@mail.gmail.com>
	<FFDCD2D5-A2B2-442B-8669-B9DA16ED2B59@hartl.name>
	<4CAF10A7.2050809@cox.net>
	<74E1FDDC-1EA3-467E-BAAD-F66FABDA3505@hartl.name>
	<AANLkTim_h+5vX4jDz037RDDeCxn5TdH-MnSmH0s7xr9W@mail.gmail.com>
	<AANLkTikq8zRvX93TGoXc0Df9_9Z6am318Qzf_5L4C=0L@mail.gmail.com>
	<4CAF2B1E.1090409@cox.net>
	<AANLkTim-w0HKLmxTAXp7WCxYScCp6_vaCwTxxiV+VHuQ@mail.gmail.com>
	<4CAF3893.3020809@cox.net>
Message-ID: <AANLkTi=uinyK0W+vCDKB65DCug6fSghN2G7comu=spu1@mail.gmail.com>

> So proper use would be:
>
> *value:contents|link|command=Remove|display=Remove '{title}' owned by
> {owner}|mystuff=stuff|morestuff=otherstuff*

Yes, look at the senders of #hasParameter:, #parameterAt:,
#parameterAt:ifAbsent:, #parameterAt:ifPresent:, etc.

> Assuming that we extended>>contentsIn: ? in some way...
>
> Is there a difference between using '+' and '*' in the context of value
> links?

In fact the method can ask #isEmbedded to itself to know. This was
currently done using the parameter 'embed', but I changed it in the
latest version which makes more sense.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Fri Oct  8 22:50:23 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 8 Oct 2010 22:50:23 +0200
Subject: PRPath>>isValidName: and extended characters
Message-ID: <97581660-27A7-443D-8120-560A4288F44C@hartl.name>

I like to use unicode characters in pier url paths. Nowadays encodeForHTTP changed in pharo and squeak to do utf-8 url-safe-encoding by default. I updated the implementation in the gemstone squeak package to do the same. So principal there is no need to be very restrictive in pier names. 

I did some tests with changing the implementation to 

PRPath>>isValidName: aString
	^ aString isNil not
		and: [ aString isEmpty not
		and: [ aString ~= self parentStructure
		and: [ aString ~= self currentStructure
		and: [ aString allSatisfy: [ :char | char isAlphaNumeric or: [self validCharacters includes: char] ] ] ] ] ]

and it works well. PRPath>>validCharacters: could be reduced to just contain '-._'. Ok, the naming needs probably to be adjusted. But I think it is worth the change.

What do you think?

Norbert



From yanni at rogers.com  Sat Oct  9 05:45:34 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Fri, 08 Oct 2010 23:45:34 -0400
Subject: duplicate rendering bug
Message-ID: <i8oogu$ra$1@dough.gmane.org>

If you take Pier 2 build #278 from http://hudson.lukas-renggli.ch, and 
look at the PRDistribution example, you'll see the text on the home page 
rendered twice - once big, then again in a smaller font. It looks to be 
a recent problem. A screenshot is included.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pier.jpg
Type: image/jpeg
Size: 49325 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101008/fcc4200b/attachment-0001.jpg>

From renggli at gmail.com  Sat Oct  9 11:34:16 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 9 Oct 2010 11:34:16 +0200
Subject: duplicate rendering bug
In-Reply-To: <i8oogu$ra$1@dough.gmane.org>
References: <i8oogu$ra$1@dough.gmane.org>
Message-ID: <AANLkTinrgMxqJ0e2mcwKRxUVKkJ3RbUMOCj7Xa55VouF@mail.gmail.com>

That should be fixed with:

Name: Pier-Setup-lr.92
Author: lr
Time: 9 October 2010, 11:24:16 am
UUID: a5ddfdb2-405b-49a9-9742-12e701ad1971
Ancestors: Pier-Setup-lr.88

- take into consideration that value links like +value:structure+
embed the target structure, and replace them with *value:structure*
where necessary

Lukas

On 9 October 2010 05:45, Yanni Chiu <yanni at rogers.com> wrote:
> If you take Pier 2 build #278 from http://hudson.lukas-renggli.ch, and look
> at the PRDistribution example, you'll see the text on the home page rendered
> twice - once big, then again in a smaller font. It looks to be a recent
> problem. A screenshot is included.
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From renggli at gmail.com  Sat Oct  9 11:35:01 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 9 Oct 2010 11:35:01 +0200
Subject: PRPath>>isValidName: and extended characters
In-Reply-To: <97581660-27A7-443D-8120-560A4288F44C@hartl.name>
References: <97581660-27A7-443D-8120-560A4288F44C@hartl.name>
Message-ID: <AANLkTim+UOKngzRv6hFp=_nfLTsYj9KhVEt=NaGmFJug@mail.gmail.com>

I integrated this with

Name: Pier-Model-lr.393
Author: lr
Time: 9 October 2010, 11:34:48 am
UUID: e26211c8-e382-44d8-bb18-7222fd290a32
Ancestors: Pier-Model-lr.392

On 8 October 2010 22:50, Norbert Hartl <norbert at hartl.name> wrote:
> I like to use unicode characters in pier url paths. Nowadays encodeForHTTP changed in pharo and squeak to do utf-8 url-safe-encoding by default. I updated the implementation in the gemstone squeak package to do the same. So principal there is no need to be very restrictive in pier names.
>
> I did some tests with changing the implementation to
>
> PRPath>>isValidName: aString
> ? ? ? ?^ aString isNil not
> ? ? ? ? ? ? ? ?and: [ aString isEmpty not
> ? ? ? ? ? ? ? ?and: [ aString ~= self parentStructure
> ? ? ? ? ? ? ? ?and: [ aString ~= self currentStructure
> ? ? ? ? ? ? ? ?and: [ aString allSatisfy: [ :char | char isAlphaNumeric or: [self validCharacters includes: char] ] ] ] ] ]
>
> and it works well. PRPath>>validCharacters: could be reduced to just contain '-._'. Ok, the naming needs probably to be adjusted. But I think it is worth the change.
>
> What do you think?
>
> Norbert
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Sat Oct  9 12:02:22 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Sat, 9 Oct 2010 12:02:22 +0200
Subject: PRPath>>isValidName: and extended characters
In-Reply-To: <AANLkTim+UOKngzRv6hFp=_nfLTsYj9KhVEt=NaGmFJug@mail.gmail.com>
References: <97581660-27A7-443D-8120-560A4288F44C@hartl.name>
	<AANLkTim+UOKngzRv6hFp=_nfLTsYj9KhVEt=NaGmFJug@mail.gmail.com>
Message-ID: <04D98C82-2D64-46B3-BB52-E77009BCD1A0@hartl.name>

Thanks Lukas,

but now the suggestName: is reduced. Probably it is better to implement it like in the attached changeset.

thanks,

Norbert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: prpath-isvalidcharacter.1.cs
Type: application/octet-stream
Size: 970 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101009/bc934c70/attachment.obj>
-------------- next part --------------


On 09.10.2010, at 11:35, Lukas Renggli wrote:

> I integrated this with
> 
> Name: Pier-Model-lr.393
> Author: lr
> Time: 9 October 2010, 11:34:48 am
> UUID: e26211c8-e382-44d8-bb18-7222fd290a32
> Ancestors: Pier-Model-lr.392
> 
> On 8 October 2010 22:50, Norbert Hartl <norbert at hartl.name> wrote:
>> I like to use unicode characters in pier url paths. Nowadays encodeForHTTP changed in pharo and squeak to do utf-8 url-safe-encoding by default. I updated the implementation in the gemstone squeak package to do the same. So principal there is no need to be very restrictive in pier names.
>> 
>> I did some tests with changing the implementation to
>> 
>> PRPath>>isValidName: aString
>>        ^ aString isNil not
>>                and: [ aString isEmpty not
>>                and: [ aString ~= self parentStructure
>>                and: [ aString ~= self currentStructure
>>                and: [ aString allSatisfy: [ :char | char isAlphaNumeric or: [self validCharacters includes: char] ] ] ] ] ]
>> 
>> and it works well. PRPath>>validCharacters: could be reduced to just contain '-._'. Ok, the naming needs probably to be adjusted. But I think it is worth the change.
>> 
>> What do you think?
>> 
>> Norbert
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From renggli at gmail.com  Sat Oct  9 12:43:21 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 9 Oct 2010 12:43:21 +0200
Subject: PRPath>>isValidName: and extended characters
In-Reply-To: <04D98C82-2D64-46B3-BB52-E77009BCD1A0@hartl.name>
References: <97581660-27A7-443D-8120-560A4288F44C@hartl.name>
	<AANLkTim+UOKngzRv6hFp=_nfLTsYj9KhVEt=NaGmFJug@mail.gmail.com>
	<04D98C82-2D64-46B3-BB52-E77009BCD1A0@hartl.name>
Message-ID: <AANLkTikS1jvOfJ3e-beakRX6OtM+FjRniXxO_vsYvS9M@mail.gmail.com>

Thanks this is integrated with

Name: Pier-Model-lr.394
Author: lr
Time: 9 October 2010, 12:42:57 pm
UUID: 91d82b31-5216-453c-9073-1c0037974923
Ancestors: Pier-Model-lr.393

- improved #suggestedName:, thanks go to Norbert for
prpath-isvalidcharacter.1.cs

Name: Pier-Tests-Model-lr.14
Author: lr
Time: 9 October 2010, 12:43:06 pm
UUID: 5dd6f62e-e3ce-4337-91e3-a21dafd47141
Ancestors: Pier-Tests-Model-lr.13

- improved #suggestedName:, thanks go to Norbert for
prpath-isvalidcharacter.1.cs


Note that I also changed the suggested name to only have lowercase
characters. While this is not really necessary I like paths to have
lowercase letters only, and this makes it easier.

Lukas

On 9 October 2010 12:02, Norbert Hartl <norbert at hartl.name> wrote:
> Thanks Lukas,
>
> but now the suggestName: is reduced. Probably it is better to implement it like in the attached changeset.
>
> thanks,
>
> Norbert
>
>
>
>
> On 09.10.2010, at 11:35, Lukas Renggli wrote:
>
>> I integrated this with
>>
>> Name: Pier-Model-lr.393
>> Author: lr
>> Time: 9 October 2010, 11:34:48 am
>> UUID: e26211c8-e382-44d8-bb18-7222fd290a32
>> Ancestors: Pier-Model-lr.392
>>
>> On 8 October 2010 22:50, Norbert Hartl <norbert at hartl.name> wrote:
>>> I like to use unicode characters in pier url paths. Nowadays encodeForHTTP changed in pharo and squeak to do utf-8 url-safe-encoding by default. I updated the implementation in the gemstone squeak package to do the same. So principal there is no need to be very restrictive in pier names.
>>>
>>> I did some tests with changing the implementation to
>>>
>>> PRPath>>isValidName: aString
>>> ? ? ? ?^ aString isNil not
>>> ? ? ? ? ? ? ? ?and: [ aString isEmpty not
>>> ? ? ? ? ? ? ? ?and: [ aString ~= self parentStructure
>>> ? ? ? ? ? ? ? ?and: [ aString ~= self currentStructure
>>> ? ? ? ? ? ? ? ?and: [ aString allSatisfy: [ :char | char isAlphaNumeric or: [self validCharacters includes: char] ] ] ] ] ]
>>>
>>> and it works well. PRPath>>validCharacters: could be reduced to just contain '-._'. Ok, the naming needs probably to be adjusted. But I think it is worth the change.
>>>
>>> What do you think?
>>>
>>> Norbert
>>>
>>>
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From yanni at rogers.com  Sun Oct 10 21:23:28 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Sun, 10 Oct 2010 15:23:28 -0400
Subject: duplicate rendering bug
In-Reply-To: <AANLkTinrgMxqJ0e2mcwKRxUVKkJ3RbUMOCj7Xa55VouF@mail.gmail.com>
References: <i8oogu$ra$1@dough.gmane.org>
	<AANLkTinrgMxqJ0e2mcwKRxUVKkJ3RbUMOCj7Xa55VouF@mail.gmail.com>
Message-ID: <i8t3rd$pl6$1@dough.gmane.org>

Okay, I had to change my Pier pages, and now the pages are appearing 
normally.

Occurrences of:
   +value:structure+ and +value:children+

needed to be changed to:
   *value:structure* and *value:children*



On 09/10/10 5:34 AM, Lukas Renggli wrote:
> That should be fixed with:
>
> Name: Pier-Setup-lr.92
> Author: lr
> Time: 9 October 2010, 11:24:16 am
> UUID: a5ddfdb2-405b-49a9-9742-12e701ad1971
> Ancestors: Pier-Setup-lr.88
>
> - take into consideration that value links like +value:structure+
> embed the target structure, and replace them with *value:structure*
> where necessary
>
> Lukas
>
> On 9 October 2010 05:45, Yanni Chiu<yanni at rogers.com>  wrote:
>> If you take Pier 2 build #278 from http://hudson.lukas-renggli.ch, and look
>> at the PRDistribution example, you'll see the text on the home page rendered
>> twice - once big, then again in a smaller font. It looks to be a recent
>> problem. A screenshot is included.


From nick.ager at gmail.com  Sun Oct 10 21:41:59 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 10 Oct 2010 20:41:59 +0100
Subject: Magritte validation problem with MABooleanDescription
Message-ID: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>

Hi,

I've been struggling with a Magritte validation problem. I find that a
condition I add (using #addCondition:labelled:) to a MABooleanDescription is
only intermittently called.

I've simplified the conditions to reproduce the problem to a component
description comprising of two MABooleanDescription descriptions. The second
description includes the condition which is intermittently called.

If the value of the first description is true (ie the checkbox is checked)
the second description's condition will be executed, however if it is false
it will never be executed.

I suspect the problems lies in the code in
 MAValidatorVisitor>>#visitContainer: which calls
MAGraphVisitor>>#use:during: which is as follows:

MAGraphVisitor >>use: anObject during: aBlock
| previous |
(seen includes: anObject)
ifTrue: [ ^ self ].
anObject isNil
ifFalse: [ seen add: anObject ].
previous := object. object := anObject.
aBlock ensure: [ object := previous ]

If the first check box is false, and the second is also false then (seen
includes: anObject) will return true and method returns early resulting in
block associated with second description (self visit: description) never
being executed.

I've attached a file out of a simple
component TestMagritteValidation illustrating the problem that I tested in
the latest build from Hudson.

Thanks

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101010/9e40289b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestMagritteValidation.st
Type: application/octet-stream
Size: 1899 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101010/9e40289b/attachment-0001.obj>

From renggli at gmail.com  Mon Oct 11 09:32:40 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 11 Oct 2010 09:32:40 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
Message-ID: <AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>

Wow, that's a very nasty bug. Amazing that this hasn't hit anybody
before. Looks like this could happen quite common in systems like
Pier, not only with MABooleanDescription instances.

  http://code.google.com/p/magritte-metamodel/issues/detail?id=7

The validation code is really ugly. And likely this bug was introduced
when trying to support the validation for recursive structures. I
would be happy if someone could rewrite that code? (also get rid of
these nested, resumable exceptions).

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From renggli at gmail.com  Mon Oct 11 10:21:57 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 11 Oct 2010 10:21:57 +0200
Subject: duplicate rendering bug
In-Reply-To: <i8t3rd$pl6$1@dough.gmane.org>
References: <i8oogu$ra$1@dough.gmane.org>
	<AANLkTinrgMxqJ0e2mcwKRxUVKkJ3RbUMOCj7Xa55VouF@mail.gmail.com>
	<i8t3rd$pl6$1@dough.gmane.org>
Message-ID: <AANLkTimkb1BJ=sJr29PWXS4fhU2MPeb6A-=q3=hcWxpC@mail.gmail.com>

Yes, sorry about that, but I think like this it makes more sense and
is more consistent with the rest of the system.

Lukas

On 10 October 2010 21:23, Yanni Chiu <yanni at rogers.com> wrote:
> Okay, I had to change my Pier pages, and now the pages are appearing
> normally.
>
> Occurrences of:
> ?+value:structure+ and +value:children+
>
> needed to be changed to:
> ?*value:structure* and *value:children*
>
>
>
> On 09/10/10 5:34 AM, Lukas Renggli wrote:
>>
>> That should be fixed with:
>>
>> Name: Pier-Setup-lr.92
>> Author: lr
>> Time: 9 October 2010, 11:24:16 am
>> UUID: a5ddfdb2-405b-49a9-9742-12e701ad1971
>> Ancestors: Pier-Setup-lr.88
>>
>> - take into consideration that value links like +value:structure+
>> embed the target structure, and replace them with *value:structure*
>> where necessary
>>
>> Lukas
>>
>> On 9 October 2010 05:45, Yanni Chiu<yanni at rogers.com> ?wrote:
>>>
>>> If you take Pier 2 build #278 from http://hudson.lukas-renggli.ch, and
>>> look
>>> at the PRDistribution example, you'll see the text on the home page
>>> rendered
>>> twice - once big, then again in a smaller font. It looks to be a recent
>>> problem. A screenshot is included.
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From nick.ager at gmail.com  Mon Oct 11 11:49:39 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 11 Oct 2010 10:49:39 +0100
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
Message-ID: <AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>

HI Lukas,

On 11 October 2010 08:32, Lukas Renggli <renggli at gmail.com> wrote:

> Wow, that's a very nasty bug. Amazing that this hasn't hit anybody
> before. Looks like this could happen quite common in systems like
> Pier, not only with MABooleanDescription instances.
>
>  http://code.google.com/p/magritte-metamodel/issues/detail?id=7
>
> The validation code is really ugly. And likely this bug was introduced
> when trying to support the validation for recursive structures. I
> would be happy if someone could rewrite that code? (also get rid of
> these nested, resumable exceptions).
>

I'm happy to help, especially as I'd like a fix for the code I'm
developing.
However I'm struggling to understand the intent of the some of the code for
example I don't understand the intent behind the use of object and previous
in MAGraphVisitor>>#use:during

MAGraphVisitor>>#use: anObject during: aBlock
| previous |
(seen includes: anObject)
ifTrue: [ ^ self ].
anObject isNil
ifFalse: [ seen add: anObject ].
previous := object. object := anObject.
aBlock ensure: [ object := previous ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101011/b27d5e30/attachment.html>

From renggli at gmail.com  Mon Oct 11 11:53:09 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 11 Oct 2010 11:53:09 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
Message-ID: <AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>

> (seen includes: anObject)
> ifTrue: [ ^ self ].
> anObject isNil
> ifFalse: [ seen add: anObject ].

That part just tries to avoid to go into recursion if a described
object refers to another object that descriptions refer back to the
original object. That was requested at some point in the past, but I
never dependent on that myself.

Lukas

On 11 October 2010 11:49, Nick Ager <nick.ager at gmail.com> wrote:
> HI Lukas,
>
> On 11 October 2010 08:32, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> Wow, that's a very nasty bug. Amazing that this hasn't hit anybody
>> before. Looks like this could happen quite common in systems like
>> Pier, not only with MABooleanDescription instances.
>>
>> ?http://code.google.com/p/magritte-metamodel/issues/detail?id=7
>>
>> The validation code is really ugly. And likely this bug was introduced
>> when trying to support the validation for recursive structures. I
>> would be happy if someone could rewrite that code? (also get rid of
>> these nested, resumable exceptions).
>
> I'm happy to help, especially as I'd like a fix for the code I'm
> developing.
> However I'm struggling to understand the intent of the some of the code for
> example I don't understand the intent behind the use of object and previous
> in MAGraphVisitor>>#use:during
> MAGraphVisitor>>#use: anObject during: aBlock
> | previous |
> (seen includes: anObject)
> ifTrue: [ ^ self ].
> anObject isNil
> ifFalse: [ seen add: anObject ].
> previous := object. object := anObject.
> aBlock ensure: [ object := previous ]
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Mon Oct 11 11:53:09 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 11 Oct 2010 11:53:09 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
Message-ID: <AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>

> (seen includes: anObject)
> ifTrue: [ ^ self ].
> anObject isNil
> ifFalse: [ seen add: anObject ].

That part just tries to avoid to go into recursion if a described
object refers to another object that descriptions refer back to the
original object. That was requested at some point in the past, but I
never dependent on that myself.

Lukas

On 11 October 2010 11:49, Nick Ager <nick.ager at gmail.com> wrote:
> HI Lukas,
>
> On 11 October 2010 08:32, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> Wow, that's a very nasty bug. Amazing that this hasn't hit anybody
>> before. Looks like this could happen quite common in systems like
>> Pier, not only with MABooleanDescription instances.
>>
>> ?http://code.google.com/p/magritte-metamodel/issues/detail?id=7
>>
>> The validation code is really ugly. And likely this bug was introduced
>> when trying to support the validation for recursive structures. I
>> would be happy if someone could rewrite that code? (also get rid of
>> these nested, resumable exceptions).
>
> I'm happy to help, especially as I'd like a fix for the code I'm
> developing.
> However I'm struggling to understand the intent of the some of the code for
> example I don't understand the intent behind the use of object and previous
> in MAGraphVisitor>>#use:during
> MAGraphVisitor>>#use: anObject during: aBlock
> | previous |
> (seen includes: anObject)
> ifTrue: [ ^ self ].
> anObject isNil
> ifFalse: [ seen add: anObject ].
> previous := object. object := anObject.
> aBlock ensure: [ object := previous ]
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From nick.ager at gmail.com  Mon Oct 11 12:05:10 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 11 Oct 2010 11:05:10 +0100
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
Message-ID: <AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>

On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:

> > (seen includes: anObject)
> > ifTrue: [ ^ self ].
> > anObject isNil
> > ifFalse: [ seen add: anObject ].
>
> That part just tries to avoid to go into recursion if a described
> object refers to another object that descriptions refer back to the
> original object. That was requested at some point in the past, but I
> never dependent on that myself.


I understood that part but don't understand the intent of:

previous := object. object := anObject.
aBlock ensure: [ object := previous ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101011/3f98686f/attachment-0001.html>

From nick.ager at gmail.com  Mon Oct 11 12:05:10 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 11 Oct 2010 11:05:10 +0100
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
Message-ID: <AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>

On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:

> > (seen includes: anObject)
> > ifTrue: [ ^ self ].
> > anObject isNil
> > ifFalse: [ seen add: anObject ].
>
> That part just tries to avoid to go into recursion if a described
> object refers to another object that descriptions refer back to the
> original object. That was requested at some point in the past, but I
> never dependent on that myself.


I understood that part but don't understand the intent of:

previous := object. object := anObject.
aBlock ensure: [ object := previous ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101011/3f98686f/attachment-0002.html>

From renggli at gmail.com  Mon Oct 11 12:11:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 11 Oct 2010 12:11:11 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
Message-ID: <AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>

That just remembers (in 'previous') and restores the currently
validated object while (in 'object') recursively walking through the
graph (which is a tree in 99% of the cases).

Lukas

On 11 October 2010 12:05, Nick Ager <nick.ager at gmail.com> wrote:
>
>
> On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> > (seen includes: anObject)
>> > ifTrue: [ ^ self ].
>> > anObject isNil
>> > ifFalse: [ seen add: anObject ].
>>
>> That part just tries to avoid to go into recursion if a described
>> object refers to another object that descriptions refer back to the
>> original object. That was requested at some point in the past, but I
>> never dependent on that myself.
>
> I understood that part but don't understand the intent of:
> previous := object. object := anObject.
> aBlock ensure: [ object := previous ]
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From yanni at rogers.com  Mon Oct 11 17:49:37 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Mon, 11 Oct 2010 11:49:37 -0400
Subject: duplicate rendering bug
In-Reply-To: <AANLkTimkb1BJ=sJr29PWXS4fhU2MPeb6A-=q3=hcWxpC@mail.gmail.com>
References: <i8oogu$ra$1@dough.gmane.org>	<AANLkTinrgMxqJ0e2mcwKRxUVKkJ3RbUMOCj7Xa55VouF@mail.gmail.com>	<i8t3rd$pl6$1@dough.gmane.org>
	<AANLkTimkb1BJ=sJr29PWXS4fhU2MPeb6A-=q3=hcWxpC@mail.gmail.com>
Message-ID: <i8vbmj$629$1@dough.gmane.org>

No problem. It was just a few edits, at this point. I was mainly 
documenting it for others, who might run into the same issue.

-- 
Yanni


On 11/10/10 4:21 AM, Lukas Renggli wrote:
> Yes, sorry about that, but I think like this it makes more sense and
> is more consistent with the rest of the system.
>
> Lukas
>
> On 10 October 2010 21:23, Yanni Chiu<yanni at rogers.com>  wrote:
>> Okay, I had to change my Pier pages, and now the pages are appearing
>> normally.
>>
>> Occurrences of:
>>   +value:structure+ and +value:children+
>>
>> needed to be changed to:
>>   *value:structure* and *value:children*


From p3anoman at gmail.com  Tue Oct 12 02:46:19 2010
From: p3anoman at gmail.com (John McKeon)
Date: Mon, 11 Oct 2010 20:46:19 -0400
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
Message-ID: <AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>

I've posted a mcz to
http://code.google.com/p/magritte-metamodel/issues/detail?id=7
It uses the description instead of the object in the collection of
descriptions already visited

<http://code.google.com/p/magritte-metamodel/issues/detail?id=7>John

On Mon, Oct 11, 2010 at 6:11 AM, Lukas Renggli <renggli at gmail.com> wrote:

> That just remembers (in 'previous') and restores the currently
> validated object while (in 'object') recursively walking through the
> graph (which is a tree in 99% of the cases).
>
> Lukas
>
> On 11 October 2010 12:05, Nick Ager <nick.ager at gmail.com> wrote:
> >
> >
> > On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:
> >>
> >> > (seen includes: anObject)
> >> > ifTrue: [ ^ self ].
> >> > anObject isNil
> >> > ifFalse: [ seen add: anObject ].
> >>
> >> That part just tries to avoid to go into recursion if a described
> >> object refers to another object that descriptions refer back to the
> >> original object. That was requested at some point in the past, but I
> >> never dependent on that myself.
> >
> > I understood that part but don't understand the intent of:
> > previous := object. object := anObject.
> > aBlock ensure: [ object := previous ]
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://john-mckeon.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101011/777796bd/attachment.html>

From renggli at gmail.com  Tue Oct 12 08:14:10 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 12 Oct 2010 08:14:10 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
Message-ID: <AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>

I thought about that too, but this is not a solution: It can be that
different objects are described with the same description instances.

Lukas

On 12 October 2010 02:46, John McKeon <p3anoman at gmail.com> wrote:
> I've posted a mcz
> to?http://code.google.com/p/magritte-metamodel/issues/detail?id=7
> It uses the description instead of the object in the collection of
> descriptions already visited
> John
>
> On Mon, Oct 11, 2010 at 6:11 AM, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> That just remembers (in 'previous') and restores the currently
>> validated object while (in 'object') recursively walking through the
>> graph (which is a tree in 99% of the cases).
>>
>> Lukas
>>
>> On 11 October 2010 12:05, Nick Ager <nick.ager at gmail.com> wrote:
>> >
>> >
>> > On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:
>> >>
>> >> > (seen includes: anObject)
>> >> > ifTrue: [ ^ self ].
>> >> > anObject isNil
>> >> > ifFalse: [ seen add: anObject ].
>> >>
>> >> That part just tries to avoid to go into recursion if a described
>> >> object refers to another object that descriptions refer back to the
>> >> original object. That was requested at some point in the past, but I
>> >> never dependent on that myself.
>> >
>> > I understood that part but don't understand the intent of:
>> > previous := object. object := anObject.
>> > aBlock ensure: [ object := previous ]
>> > _______________________________________________
>> > Magritte, Pier and Related Tools ...
>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> --
> http://john-mckeon.us
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Tue Oct 12 08:58:15 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Tue, 12 Oct 2010 08:58:15 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
	<AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
Message-ID: <721C0687-1B78-437A-ABFF-137615320732@hartl.name>

Wow, that's a hairy problem. I just read the thread a few minutes ago. I agree that using a description does not solve the problem. But if I'm not wrong then the problem exists for every object where

anObject copy == anObject

right? (Btw. is there a selector in Smalltalk that can test this?) On the other hand we are talking about preventing infinite loops, right? Is there a chance that any of the objects that meet the condition above can trigger an infinite recursion? I don't think so. So it should be sufficient to manage the seen list only for the object that do no meet the condition. Although the above is neither nice nor fast.

Norbert

On 12.10.2010, at 08:14, Lukas Renggli wrote:

> I thought about that too, but this is not a solution: It can be that
> different objects are described with the same description instances.
> 
> Lukas
> 
> On 12 October 2010 02:46, John McKeon <p3anoman at gmail.com> wrote:
>> I've posted a mcz
>> to http://code.google.com/p/magritte-metamodel/issues/detail?id=7
>> It uses the description instead of the object in the collection of
>> descriptions already visited
>> John
>> 
>> On Mon, Oct 11, 2010 at 6:11 AM, Lukas Renggli <renggli at gmail.com> wrote:
>>> 
>>> That just remembers (in 'previous') and restores the currently
>>> validated object while (in 'object') recursively walking through the
>>> graph (which is a tree in 99% of the cases).
>>> 
>>> Lukas
>>> 
>>> On 11 October 2010 12:05, Nick Ager <nick.ager at gmail.com> wrote:
>>>> 
>>>> 
>>>> On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:
>>>>> 
>>>>>> (seen includes: anObject)
>>>>>> ifTrue: [ ^ self ].
>>>>>> anObject isNil
>>>>>> ifFalse: [ seen add: anObject ].
>>>>> 
>>>>> That part just tries to avoid to go into recursion if a described
>>>>> object refers to another object that descriptions refer back to the
>>>>> original object. That was requested at some point in the past, but I
>>>>> never dependent on that myself.
>>>> 
>>>> I understood that part but don't understand the intent of:
>>>> previous := object. object := anObject.
>>>> aBlock ensure: [ object := previous ]
>>>> _______________________________________________
>>>> Magritte, Pier and Related Tools ...
>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
>> 
>> 
>> --
>> http://john-mckeon.us
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From renggli at gmail.com  Tue Oct 12 09:14:34 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 12 Oct 2010 09:14:34 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <721C0687-1B78-437A-ABFF-137615320732@hartl.name>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
	<AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
	<721C0687-1B78-437A-ABFF-137615320732@hartl.name>
Message-ID: <AANLkTimd-SBQF-jcrf5_GQaneWB2xBeS7WcaYbUQg0iF@mail.gmail.com>

> Wow, that's a hairy problem. I just read the thread a few minutes ago. I agree that using a description does not solve the problem. But if I'm not wrong then the problem exists for every object where
>
> anObject copy == anObject
>
> right?

Yeah, the problem is complex.

And I am tempted to avoid it by not going deeply into the graph, but
by only validating what would be visible (if for example rendered by
Seaside). This was the case a few years back, but then somebody
complained about incomplete validation of 1:1 and 1:n relationships.
Now I do not remember exactly why we changed this, but it seems to me
the cause of all problems :-)

> (Btw. is there a selector in Smalltalk that can test this?)

I don't think so. The code you wrote is probably the only test.

> On the other hand we are talking about preventing infinite loops, right? Is there a chance that any of the objects that meet the condition above can trigger an infinite recursion? I don't think so.

Correct, but there can be other cases.

Imagine multiple 1:1 relationships where the same some of them refer
to the same object, but have different validation conditions.
Similarly, as we saw before, we can have different objects with the
same description instances.

Lukas

> So it should be sufficient to manage the seen list only for the object that do no meet the condition. Although the above is neither nice nor fast.
>
> Norbert
>
> On 12.10.2010, at 08:14, Lukas Renggli wrote:
>
>> I thought about that too, but this is not a solution: It can be that
>> different objects are described with the same description instances.
>>
>> Lukas
>>
>> On 12 October 2010 02:46, John McKeon <p3anoman at gmail.com> wrote:
>>> I've posted a mcz
>>> to http://code.google.com/p/magritte-metamodel/issues/detail?id=7
>>> It uses the description instead of the object in the collection of
>>> descriptions already visited
>>> John
>>>
>>> On Mon, Oct 11, 2010 at 6:11 AM, Lukas Renggli <renggli at gmail.com> wrote:
>>>>
>>>> That just remembers (in 'previous') and restores the currently
>>>> validated object while (in 'object') recursively walking through the
>>>> graph (which is a tree in 99% of the cases).
>>>>
>>>> Lukas
>>>>
>>>> On 11 October 2010 12:05, Nick Ager <nick.ager at gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 11 October 2010 10:53, Lukas Renggli <renggli at gmail.com> wrote:
>>>>>>
>>>>>>> (seen includes: anObject)
>>>>>>> ifTrue: [ ^ self ].
>>>>>>> anObject isNil
>>>>>>> ifFalse: [ seen add: anObject ].
>>>>>>
>>>>>> That part just tries to avoid to go into recursion if a described
>>>>>> object refers to another object that descriptions refer back to the
>>>>>> original object. That was requested at some point in the past, but I
>>>>>> never dependent on that myself.
>>>>>
>>>>> I understood that part but don't understand the intent of:
>>>>> previous := object. object := anObject.
>>>>> aBlock ensure: [ object := previous ]
>>>>> _______________________________________________
>>>>> Magritte, Pier and Related Tools ...
>>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lukas Renggli
>>>> www.lukas-renggli.ch
>>>> _______________________________________________
>>>> Magritte, Pier and Related Tools ...
>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>>
>>>
>>> --
>>> http://john-mckeon.us
>>>
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From nick.ager at gmail.com  Tue Oct 12 09:32:22 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 12 Oct 2010 08:32:22 +0100
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTimd-SBQF-jcrf5_GQaneWB2xBeS7WcaYbUQg0iF@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
	<AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
	<721C0687-1B78-437A-ABFF-137615320732@hartl.name>
	<AANLkTimd-SBQF-jcrf5_GQaneWB2xBeS7WcaYbUQg0iF@mail.gmail.com>
Message-ID: <AANLkTikVynq44VXfNzmTaVK4DDcf55eeXoyhqDFpHkr7@mail.gmail.com>

>
>
> Imagine multiple 1:1 relationships where the same some of them refer
> to the same object, but have different validation conditions.
> Similarly, as we saw before, we can have different objects with the
> same description instances.
>
> Would a hash that combined the description's hash with the container
description's hash work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101012/c4bbcc3f/attachment.html>

From renggli at gmail.com  Tue Oct 12 12:59:28 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 12 Oct 2010 12:59:28 +0200
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTikVynq44VXfNzmTaVK4DDcf55eeXoyhqDFpHkr7@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
	<AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
	<721C0687-1B78-437A-ABFF-137615320732@hartl.name>
	<AANLkTimd-SBQF-jcrf5_GQaneWB2xBeS7WcaYbUQg0iF@mail.gmail.com>
	<AANLkTikVynq44VXfNzmTaVK4DDcf55eeXoyhqDFpHkr7@mail.gmail.com>
Message-ID: <AANLkTi=d=t9fLOsNCt0CWz=NRmUqChwYsse+CCeX-L8G@mail.gmail.com>

I submitted an update to Magritte-Model that attempts to fix the
problem, by not walking through the complete graph but only through
the immediate references. Let's see if this solves more problems than
it introduces?

Lukas

On 12 October 2010 09:32, Nick Ager <nick.ager at gmail.com> wrote:
>>
>> Imagine multiple 1:1 relationships where the same some of them refer
>> to the same object, but have different validation conditions.
>> Similarly, as we saw before, we can have different objects with the
>> same description instances.
>>
> Would a hash that combined the description's hash with the container
> description's hash work?
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From nick.ager at gmail.com  Tue Oct 12 15:14:45 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 12 Oct 2010 14:14:45 +0100
Subject: Magritte validation problem with MABooleanDescription
In-Reply-To: <AANLkTi=d=t9fLOsNCt0CWz=NRmUqChwYsse+CCeX-L8G@mail.gmail.com>
References: <AANLkTina3+gJcqjz4WFjWqDEm8qbW0Ra5LuWQuuity7r@mail.gmail.com>
	<AANLkTinb5i33rVMpdEJ2FgBYhjFN-ZQA2EUvUOfNjxdG@mail.gmail.com>
	<AANLkTimaNUGfK26edae56s24ABEOmiqZ58ju9nh0Ef1k@mail.gmail.com>
	<AANLkTimp14gZB5hNUvR+AJc-a4oyNHnaDv0bBg0rcde1@mail.gmail.com>
	<AANLkTimQR2+mSbGKswwFdwro05TDajGn10kD4YNJg4ma@mail.gmail.com>
	<AANLkTi=Y5ByeJ8OO4QFb=5r_Ep0y=xSnqri_UJjswezv@mail.gmail.com>
	<AANLkTikCFCML=BpQGL03fQn=aN2eGw6rsPW_FrYPEC1e@mail.gmail.com>
	<AANLkTi=Qtan3yDX-hAdFZ=73xc15Bz5fr4QnM7jd_-Tu@mail.gmail.com>
	<721C0687-1B78-437A-ABFF-137615320732@hartl.name>
	<AANLkTimd-SBQF-jcrf5_GQaneWB2xBeS7WcaYbUQg0iF@mail.gmail.com>
	<AANLkTikVynq44VXfNzmTaVK4DDcf55eeXoyhqDFpHkr7@mail.gmail.com>
	<AANLkTi=d=t9fLOsNCt0CWz=NRmUqChwYsse+CCeX-L8G@mail.gmail.com>
Message-ID: <AANLkTik+7oad4KFzQRp+LGh2XRdtAwQEzbvj9Tgic9qU@mail.gmail.com>

Thanks Lukas it solves my problem.

On 12 October 2010 11:59, Lukas Renggli <renggli at gmail.com> wrote:

> I submitted an update to Magritte-Model that attempts to fix the
> problem, by not walking through the complete graph but only through
> the immediate references. Let's see if this solves more problems than
> it introduces?
>
> Lukas
>
> On 12 October 2010 09:32, Nick Ager <nick.ager at gmail.com> wrote:
> >>
> >> Imagine multiple 1:1 relationships where the same some of them refer
> >> to the same object, but have different validation conditions.
> >> Similarly, as we saw before, we can have different objects with the
> >> same description instances.
> >>
> > Would a hash that combined the description's hash with the container
> > description's hash work?
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101012/8b283fcd/attachment.html>

From p3anoman at gmail.com  Tue Oct 12 23:11:04 2010
From: p3anoman at gmail.com (John McKeon)
Date: Tue, 12 Oct 2010 17:11:04 -0400
Subject: Pier SIXX export/import
Message-ID: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>

Hello,

Over the weekend I put together a solution for
http://code.google.com/p/pier/issues/detail?id=96 using SIXX to
export/import Pier websites. It works well with the few simple sites I have
available to test it with.
The mcz package is attached to the issue as I don't have commit rights to
the Pier repository.

Any comments would be welcome.

John

-- 
http://john-mckeon.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101012/e3bcd72c/attachment.html>

From renggli at gmail.com  Tue Oct 12 23:16:02 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 12 Oct 2010 23:16:02 +0200
Subject: Pier SIXX export/import
In-Reply-To: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>
References: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>
Message-ID: <AANLkTikFSh8gL4ZFk4n5kKeY+MQDX=GefO78zmqSTWtG@mail.gmail.com>

Very cool!

I've added you to the Magritte and Pier groups, would you mind
committing it there?

Lukas

On 12 October 2010 23:11, John McKeon <p3anoman at gmail.com> wrote:
> Hello,
> Over the weekend I put together a solution
> for?http://code.google.com/p/pier/issues/detail?id=96?using SIXX to
> export/import Pier websites. It works well with the few simple sites I have
> available to test it with.
> The mcz package is attached to the issue as I don't have commit rights to
> the Pier repository.
> Any comments would be welcome.
> John
>
> --
> http://john-mckeon.us
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Wed Oct 13 00:24:11 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Wed, 13 Oct 2010 00:24:11 +0200
Subject: Pier SIXX export/import
In-Reply-To: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>
References: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>
Message-ID: <4A68F314-9D90-42C2-BFC0-9979079C9D10@hartl.name>


On 12.10.2010, at 23:11, John McKeon wrote:

> Hello,
> 
> Over the weekend I put together a solution for http://code.google.com/p/pier/issues/detail?id=96 using SIXX to export/import Pier websites. It works well with the few simple sites I have available to test it with.
> The mcz package is attached to the issue as I don't have commit rights to the Pier repository.
> 
> Any comments would be welcome.
> 
Nice. So I was just way too slow :) I have an pier exporter nearly finished here in my image. I was just being slowed down with all the xml parser porting and encoding fixes. I had a look into the package but I'm not sure if I found the important stuff. Is it the PierSixxExporterImporter class or did I miss parts?
Can you elaborate what the side links to the pull parser have to do with your work?
I did a tool to export/import pier kernel in order to move them between pharo and gemstone. The xml parser is now the same on gemstone and pharo. I'm not sure if Sixx is the same. I changed Sixx on gemstone to do utf-8 as default encoding. I need to check this again. The version of sixx von Ken Treis does not fit that well into the current situation what is sad. It would be a good idea to extract the pull parser and to reintegrate it in the xml parser package.
What I did is to make the export import working on gemstone and pharo. The code for this is completely different on both platforms. And finally my approach is not to store a file but a directory. Inside this I generate a kernel.xml and a files directory. A visitor walks the kernel structure and copies all external file models into the directory. So you can move all resources in one stroke and have the import tool  read it in again. 

Ok, to keep it a bit short. I could try to get the good parts from my code (if there are any :) ) and integrate it in your package. And some discussions might be useful.

Norbert 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101013/2ac34868/attachment.html>

From p3anoman at gmail.com  Wed Oct 13 01:41:56 2010
From: p3anoman at gmail.com (John McKeon)
Date: Tue, 12 Oct 2010 19:41:56 -0400
Subject: Pier SIXX export/import
In-Reply-To: <4A68F314-9D90-42C2-BFC0-9979079C9D10@hartl.name>
References: <AANLkTi=H2M3TfQQHa=e7758L3EWtjQ3w=ZHx5=g1D3S=@mail.gmail.com>
	<4A68F314-9D90-42C2-BFC0-9979079C9D10@hartl.name>
Message-ID: <AANLkTi=8N8FXHB6PVp4A8N+iW=GOKkdP3_CnAAYBJuA2@mail.gmail.com>

I went the KISS route :)

Basically, I took all of the exporting/importing code out of the widget and
moved into the PRExporterImporter class. Its two subclasses merely return
the proper stream instances for their respective type of export (and the
mime type and file extension).

The SIXX version I was using came from the SIXX website. XMLParser had to be
brought current for its tests to run however (*I am using Squeak 4.1).  I
loaded Ken Treis' XMLPullParser and his latest SIXX changes to test that it
worked with that as well.

I haven't tried to import into a different dialect yet....

John

On Tue, Oct 12, 2010 at 6:24 PM, Norbert Hartl <norbert at hartl.name> wrote:

>
> On 12.10.2010, at 23:11, John McKeon wrote:
>
> Hello,
>
> Over the weekend I put together a solution for
> http://code.google.com/p/pier/issues/detail?id=96 using SIXX to
> export/import Pier websites. It works well with the few simple sites I have
> available to test it with.
> The mcz package is attached to the issue as I don't have commit rights to
> the Pier repository.
>
> Any comments would be welcome.
>
> Nice. So I was just way too slow :) I have an pier exporter nearly finished
> here in my image. I was just being slowed down with all the xml parser
> porting and encoding fixes. I had a look into the package but I'm not sure
> if I found the important stuff. Is it the PierSixxExporterImporter class or
> did I miss parts?
> Can you elaborate what the side links to the pull parser have to do with
> your work?
> I did a tool to export/import pier kernel in order to move them between
> pharo and gemstone. The xml parser is now the same on gemstone and pharo.
> I'm not sure if Sixx is the same. I changed Sixx on gemstone to do utf-8 as
> default encoding. I need to check this again. The version of sixx von Ken
> Treis does not fit that well into the current situation what is sad. It
> would be a good idea to extract the pull parser and to reintegrate it in the
> xml parser package.
> What I did is to make the export import working on gemstone and pharo. The
> code for this is completely different on both platforms. And finally my
> approach is not to store a file but a directory. Inside this I generate a
> kernel.xml and a files directory. A visitor walks the kernel structure and
> copies all external file models into the directory. So you can move all
> resources in one stroke and have the import tool  read it in again.
>
> Ok, to keep it a bit short. I could try to get the good parts from my code
> (if there are any :) ) and integrate it in your package. And some
> discussions might be useful.
>
> Norbert
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://john-mckeon.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101012/0bb29d91/attachment.html>

From lenglish5 at cox.net  Wed Oct 13 05:44:37 2010
From: lenglish5 at cox.net (Lawson English)
Date: Tue, 12 Oct 2010 20:44:37 -0700
Subject: A blog from scratch?
Message-ID: <4CB52B25.9000403@cox.net>

  I'm trying to start a blog from scratch, but I can't get it to use the 
built-in functionality unless I subclass the PRDistribution code and add 
a "first entry" post within the method "blog".

What am I missing, or am I missing anything?

Lawson



From nick.ager at gmail.com  Wed Oct 13 06:26:49 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Wed, 13 Oct 2010 05:26:49 +0100
Subject: A blog from scratch?
In-Reply-To: <4CB52B25.9000403@cox.net>
References: <4CB52B25.9000403@cox.net>
Message-ID: <AANLkTikEZFnAJsWpw3XzyyEoiXKZ1xM4tbQw0v5aUYGA@mail.gmail.com>

Hi Lawson,

 I'm trying to start a blog from scratch, but I can't get it to use the
> built-in functionality unless I subclass the PRDistribution code and add a
> "first entry" post within the method "blog".
>
> What am I missing, or am I missing anything?
>

Not sure I understand what you're asking. Is it how do I create a new blog
entry? If so:

login using admin/pier (login link bottom left)
navigate to /pier/blog
click on commands:add (link bottom left)
click on the add button
on the next form fill in "source title" "contents" and press the "current"
button for the "publication" field then press "save" button

If instead your question is how do I define my own site which incorporates a
blog? Then look at PRDistribution>>root as a starting point for your site's
structure. Experiment by removing and adding components until you end up
with a structure that works for you. In particular you might find the
following lines within PRDistribution>>root a useful starting place for
understanding how to customise the look and feel of your site:

self rootPage localEnvironment: self mainEnvironmentPage.
self blog localEnvironment: self blogEnvironmentPage.

which will lead you into examining:

PRDistribution>> mainEnvironmentPage
PRDistribution>> blogEnvironmentPage

Hope that helps

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101013/09543d30/attachment.html>

From lenglish5 at cox.net  Thu Oct 14 07:44:07 2010
From: lenglish5 at cox.net (Lawson English)
Date: Wed, 13 Oct 2010 22:44:07 -0700
Subject: A blog from scratch?
In-Reply-To: <AANLkTikEZFnAJsWpw3XzyyEoiXKZ1xM4tbQw0v5aUYGA@mail.gmail.com>
References: <4CB52B25.9000403@cox.net>
	<AANLkTikEZFnAJsWpw3XzyyEoiXKZ1xM4tbQw0v5aUYGA@mail.gmail.com>
Message-ID: <4CB698A7.30205@cox.net>

  OK, what I did was subclass PRDistribution with PRCodeWikiDistribution.

I created
PRCodeWikiDistribution>>blog
blog
     ^ blog ifNil: [
         blog := (PBBlog named: 'blog')

         yourself
     ].



Then from within the Blog  page, I added a new Blog post via the web 
interface and saved


However, the first post doesn't show up in the widget listing new blog 
posts. I found that if I manually created a new blog post from within 
 >>blog...

blog
^ blog ifNil: [
         blog := (PBBlog named: 'blog')
         addChild: (
             (PBPost named: 'test')
             title: 'Down to test';
             contents: 'test';
             publication: TimeStamp now
                 );
             yourself

     ].


It works. I just wasn't clear on all the stages required to start from 
scratch. As far as I can tell, the first PBPost has to be created from 
with the >>blog method.


Next up, creating a Pier sidebar that can display existing code, e.g. 
http://www.morphle.org:8502

as well as a login input pane so that my Second Life nano-client written 
in squeak can be used to log into  Second life and display 
incoming/outgoing packets, and eventually inject/modify those packets.


The idea is to create a combination journal/blog/wiki of coding, along 
with a way of annotating/commenting on the live code with UML-type 
diagrams for the SL client and for the SL client-server protocols, with 
an eye to letting people make suggestions on how to improve what is 
already working, while showing what is working.

None of the PRDistribution templates really does what I need, but the 
Blog template seems the closest to what I want to do. Part of the 
process will be getting suggestions from people on how to design the 
wiki/blog thingie.



Lawson

On 10/12/10 9:26 PM, Nick Ager wrote:
> Hi Lawson,
>
>      I'm trying to start a blog from scratch, but I can't get it to
>     use the built-in functionality unless I subclass the
>     PRDistribution code and add a "first entry" post within the method
>     "blog".
>
>     What am I missing, or am I missing anything?
>
>
> Not sure I understand what you're asking. Is it how do I create a new 
> blog entry? If so:
>
> login using admin/pier (login link bottom left)
> navigate to /pier/blog
> click on commands:add (link bottom left)
> click on the add button
> on the next form fill in "source title" "contents" and press the 
> "current" button for the "publication" field then press "save" button
>
> If instead your question is how do I define my own site which 
> incorporates a blog? Then look at PRDistribution>>root as a starting 
> point for your site's structure. Experiment by removing and adding 
> components until you end up with a structure that works for you. In 
> particular you might find the following lines within 
> PRDistribution>>root a useful starting place for understanding how to 
> customise the look and feel of your site:
>
> self rootPage localEnvironment: self mainEnvironmentPage.
> self blog localEnvironment: self blogEnvironmentPage.
>
> which will lead you into examining:
>
> PRDistribution>> mainEnvironmentPage
> PRDistribution>> blogEnvironmentPage
>
> Hope that helps
>
> Nick
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101013/377c3b57/attachment-0001.html>

From norbert at hartl.name  Thu Oct 14 17:01:40 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 14 Oct 2010 17:01:40 +0200
Subject: Returning to the same view after command execution
Message-ID: <5EC3F055-4E07-4AD2-A086-F228D627B62F@hartl.name>

I display a list of items in a custom view in pier. On the custom view there is also a pier command link that adds another item. Now after the command has executed I want to have the same structure and view as before the command execution. The structure is not the problem but the view is somehow lost through command execution.

How can this be done?

Norbert
 

From yanni at rogers.com  Thu Oct 14 17:44:41 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Thu, 14 Oct 2010 11:44:41 -0400
Subject: A blog from scratch?
In-Reply-To: <4CB698A7.30205@cox.net>
References: <4CB52B25.9000403@cox.net>	<AANLkTikEZFnAJsWpw3XzyyEoiXKZ1xM4tbQw0v5aUYGA@mail.gmail.com>
	<4CB698A7.30205@cox.net>
Message-ID: <i978hb$s33$1@dough.gmane.org>

On 14/10/10 1:44 AM, Lawson English wrote:
> Then from within the Blog page, I added a new Blog post via the web
> interface and saved
>
>
> However, the first post doesn't show up in the widget listing new blog
> posts. I found that if I manually created a new blog post from within
>  >>blog...
>
> blog
> ^ blog ifNil: [
> blog := (PBBlog named: 'blog')
> addChild: (
> (PBPost named: 'test')
> title: 'Down to test';
> contents: 'test';
> publication: TimeStamp now
> );
> yourself
>
> ].

When you created the first post using code, you set the publication date 
with "TimeStamp now". When you created your first post using the UI, did 
you set a publication date? If you didn't, then you won't see the post.


From lenglish5 at cox.net  Thu Oct 14 18:06:38 2010
From: lenglish5 at cox.net (Lawson English)
Date: Thu, 14 Oct 2010 09:06:38 -0700
Subject: A blog from scratch?
In-Reply-To: <i978hb$s33$1@dough.gmane.org>
References: <4CB52B25.9000403@cox.net>	<AANLkTikEZFnAJsWpw3XzyyEoiXKZ1xM4tbQw0v5aUYGA@mail.gmail.com>	<4CB698A7.30205@cox.net>
	<i978hb$s33$1@dough.gmane.org>
Message-ID: <4CB72A8E.80300@cox.net>

  On 10/14/10 8:44 AM, Yanni Chiu wrote:
> On 14/10/10 1:44 AM, Lawson English wrote:
>> Then from within the Blog page, I added a new Blog post via the web
>> interface and saved
>>
>>
>> However, the first post doesn't show up in the widget listing new blog
>> posts. I found that if I manually created a new blog post from within
>> >>blog...
>>
>> blog
>> ^ blog ifNil: [
>> blog := (PBBlog named: 'blog')
>> addChild: (
>> (PBPost named: 'test')
>> title: 'Down to test';
>> contents: 'test';
>> publication: TimeStamp now
>> );
>> yourself
>>
>> ].
>
> When you created the first post using code, you set the publication 
> date with "TimeStamp now". When you created your first post using the 
> UI, did you set a publication date? If you didn't, then you won't see 
> the post.
>
>

Oh.

Thanks.  ;-)

Lawson


From renggli at gmail.com  Thu Oct 14 19:24:39 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 14 Oct 2010 19:24:39 +0200
Subject: Returning to the same view after command execution
In-Reply-To: <5EC3F055-4E07-4AD2-A086-F228D627B62F@hartl.name>
References: <5EC3F055-4E07-4AD2-A086-F228D627B62F@hartl.name>
Message-ID: <AANLkTimkuQgF=teHDhKmxUKgNd_n-ePPDDuREjz2LF5e@mail.gmail.com>

You can set the #answer: context on the command.

Look at the 'Browse' view. I just committed a change that goes back to
the browse view. This annoyed me for quite a while already, but I
always forgot to adapt the code.

  Name: Pier-Security-lr.170
  Author: lr
  Time: 14 October 2010, 7:23:21 pm
  UUID: 07c8ffe3-7340-402e-a472-6fc0dbd64f58
  Ancestors: Pier-Security-lr.169

  - when triggering a command from the browse view try to redirect it
back to the browse view after completion

Lukas

On 14 October 2010 17:01, Norbert Hartl <norbert at hartl.name> wrote:
> I display a list of items in a custom view in pier. On the custom view there is also a pier command link that adds another item. Now after the command has executed I want to have the same structure and view as before the command execution. The structure is not the problem but the view is somehow lost through command execution.
>
> How can this be done?
>
> Norbert
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From lenglish5 at cox.net  Thu Oct 14 20:44:23 2010
From: lenglish5 at cox.net (Lawson English)
Date: Thu, 14 Oct 2010 11:44:23 -0700
Subject: How to toggle view?
Message-ID: <4CB74F87.9060308@cox.net>

  How do I make it so that people who are not logged in see one message 
and people who are logged in, see another?


I created an HTML component named "newbies" with permissions for "other" 
set to "view" and permissions for "mygroup" not set.

then I referenced it in a link +newbies+


I still see it even as a member of "mygroup" .

On the otehr hand, I added a component named   "grouponly"  and set 
permission to view for members of "mygroup" and no permission for "other"...


If you login as a member of mygroup, you can see it, but you can't see 
it if you're not logged in.

What am I doing wrong?


Thanks,

Lawson








From lenglish5 at cox.net  Fri Oct 15 02:07:33 2010
From: lenglish5 at cox.net (Lawson English)
Date: Thu, 14 Oct 2010 17:07:33 -0700
Subject: How to toggle view?
In-Reply-To: <4CB74F87.9060308@cox.net>
References: <4CB74F87.9060308@cox.net>
Message-ID: <4CB79B45.6020607@cox.net>

  Here's what I want people to see:

LOGGED OUT:
Landing page
General message
you are not logged in

vs
LOGGED IN:
landing page
general page
extra stuff



what I am seeing is:

LOGGED IN:
landing page
general page
extra stuff
you are not logged in <=== shouldn't be there if you are logged in









On 10/14/10 11:44 AM, Lawson English wrote:
>  How do I make it so that people who are not logged in see one message 
> and people who are logged in, see another?
>
>
> I created an HTML component named "newbies" with permissions for 
> "other" set to "view" and permissions for "mygroup" not set.
>
> then I referenced it in a link +newbies+
>
>
> I still see it even as a member of "mygroup" .
>
> On the otehr hand, I added a component named   "grouponly"  and set 
> permission to view for members of "mygroup" and no permission for 
> "other"...
>
>
> If you login as a member of mygroup, you can see it, but you can't see 
> it if you're not logged in.
>
> What am I doing wrong?
>
>
> Thanks,
>
> Lawson
>
>
>
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


From p3anoman at gmail.com  Fri Oct 15 04:05:43 2010
From: p3anoman at gmail.com (John McKeon)
Date: Thu, 14 Oct 2010 22:05:43 -0400
Subject: How to toggle view?
In-Reply-To: <4CB79B45.6020607@cox.net>
References: <4CB74F87.9060308@cox.net>
	<4CB79B45.6020607@cox.net>
Message-ID: <AANLkTinbUW6-nduMfPv8QPGuwAsjQzt-vuKPYfwsuOHD@mail.gmail.com>

Lawson,
you can do this using +You must log in>value:user|display=+
Combining the standard feature of an alias being displayed for undefined
value links, and the recently added ability to display any arbitrary text
for the link when it is defined (in this case blank). You could also do +You
must log in>value:user|display=You are logged in as {name}+

John

On Thu, Oct 14, 2010 at 8:07 PM, Lawson English <lenglish5 at cox.net> wrote:

>  Here's what I want people to see:
>
> LOGGED OUT:
> Landing page
> General message
> you are not logged in
>
> vs
> LOGGED IN:
> landing page
> general page
> extra stuff
>
>
>
> what I am seeing is:
>
> LOGGED IN:
> landing page
> general page
> extra stuff
> you are not logged in <=== shouldn't be there if you are logged in
>
>
>
>
>
>
>
>
>
>
> On 10/14/10 11:44 AM, Lawson English wrote:
>
>>  How do I make it so that people who are not logged in see one message and
>> people who are logged in, see another?
>>
>>
>> I created an HTML component named "newbies" with permissions for "other"
>> set to "view" and permissions for "mygroup" not set.
>>
>> then I referenced it in a link +newbies+
>>
>>
>> I still see it even as a member of "mygroup" .
>>
>> On the otehr hand, I added a component named   "grouponly"  and set
>> permission to view for members of "mygroup" and no permission for "other"...
>>
>>
>> If you login as a member of mygroup, you can see it, but you can't see it
>> if you're not logged in.
>>
>> What am I doing wrong?
>>
>>
>> Thanks,
>>
>> Lawson
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://john-mckeon.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101014/879479c9/attachment.html>

From lenglish5 at cox.net  Fri Oct 15 06:26:28 2010
From: lenglish5 at cox.net (Lawson English)
Date: Thu, 14 Oct 2010 21:26:28 -0700
Subject: How to toggle view?
In-Reply-To: <AANLkTinbUW6-nduMfPv8QPGuwAsjQzt-vuKPYfwsuOHD@mail.gmail.com>
References: <4CB74F87.9060308@cox.net>	<4CB79B45.6020607@cox.net>
	<AANLkTinbUW6-nduMfPv8QPGuwAsjQzt-vuKPYfwsuOHD@mail.gmail.com>
Message-ID: <4CB7D7F4.3000005@cox.net>

  On 10/14/10 7:05 PM, John McKeon wrote:
> Lawson,
> you can do this using +You must log in>value:user|display=+
> Combining the standard feature of an alias being displayed for 
> undefined value links, and the recently added ability to display any 
> arbitrary text for the link when it is defined (in this case blank). 
> You could also do +You must log in>value:user|display=You are logged 
> in as {name}+
>
> John
>
Thanks, I was trying to use the simplest possible example, however, just 
to isolate the issues with permission and display.

In the "real world" case, I'm actually hoping to have the alternatives 
be data from my own test avatar showing, or, once someone is logged into 
the wiki/blog, they have the option to use an interface to log their own 
avatar into second life and observe how things work and even control it 
in various ways in the context of the wiki/blog

So what I want to do is a bit more than controlling arbitrary text. I 
was hoping for a way to control display of generic components this way, 
but I'm not sure if your solution will do that or not.

Thanks for the suggestion.


Lawson




From renggli at gmail.com  Fri Oct 15 10:10:28 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 15 Oct 2010 10:10:28 +0200
Subject: How to toggle view?
In-Reply-To: <4CB7D7F4.3000005@cox.net>
References: <4CB74F87.9060308@cox.net> <4CB79B45.6020607@cox.net>
	<AANLkTinbUW6-nduMfPv8QPGuwAsjQzt-vuKPYfwsuOHD@mail.gmail.com>
	<4CB7D7F4.3000005@cox.net>
Message-ID: <AANLkTinXuQ7PXc2T+-aXN06B93LmgUcG1rp_hwi7TWDA@mail.gmail.com>

"Pier Unix Security" does not allow you to remove permissions.

If you give some permission to the other permissions, these
permissions will be given to anybody even if the owner or group does
not match. It is kind of hard to explain in a mail, but I think the
code is pretty explanatory:

PUSecurity>>hasPermission: aPermission for: aUser
	"Test if the user aUser has the permission aPermission. This is the
central method to test for permissions in Pier."

	(aUser notNil and: [ aUser isSuperuser ])
		ifTrue: [ ^ true ].
	(self owner = aUser and: [ self ownerPermissions includes: aPermission ])
		ifTrue: [ ^ true ].
	(self group notNil and: [ (self group includes: aUser) and: [ (self
groupPermissions includes: aPermission) ] ])
		ifTrue: [ ^ true ].
	(self otherPermissions includes: aPermission)
		ifTrue: [ ^ true ].
	^ false

In your particular case I suggest that use CSS so that when the user
is logged in the other message is hidden below the logged-in DOM
element. Alternatively you can create your own Seaside component,
similar to PUSecurityWidget.

Lukas

On 15 October 2010 06:26, Lawson English <lenglish5 at cox.net> wrote:
> ?On 10/14/10 7:05 PM, John McKeon wrote:
>>
>> Lawson,
>> you can do this using +You must log in>value:user|display=+
>> Combining the standard feature of an alias being displayed for undefined
>> value links, and the recently added ability to display any arbitrary text
>> for the link when it is defined (in this case blank). You could also do +You
>> must log in>value:user|display=You are logged in as {name}+
>>
>> John
>>
> Thanks, I was trying to use the simplest possible example, however, just to
> isolate the issues with permission and display.
>
> In the "real world" case, I'm actually hoping to have the alternatives be
> data from my own test avatar showing, or, once someone is logged into the
> wiki/blog, they have the option to use an interface to log their own avatar
> into second life and observe how things work and even control it in various
> ways in the context of the wiki/blog
>
> So what I want to do is a bit more than controlling arbitrary text. I was
> hoping for a way to control display of generic components this way, but I'm
> not sure if your solution will do that or not.
>
> Thanks for the suggestion.
>
>
> Lawson
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Fri Oct 15 12:58:25 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Oct 2010 12:58:25 +0200
Subject: PRKernel subclasses and pier configuration
Message-ID: <6FAB7F67-0693-409D-A2A1-E5BC0314B380@hartl.name>

I started to use my custom kernel classes and couldn't see them in the pier configuration drop-down. So I changed the implementation that the drop-down displays not only all instances of PRKernel but all instances of PRKernel and subclasses. 

Norbert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-subinstances.1.cs
Type: application/octet-stream
Size: 643 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101015/21871043/attachment.obj>

From norbert at hartl.name  Fri Oct 15 16:02:55 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Oct 2010 16:02:55 +0200
Subject: Upgrade Pier-Model-lr.392
Message-ID: <22B9D490-807E-4525-93CA-ED7D89CEEC9B@hartl.name>

The change in */+ detection has some strange side effects. In my old templates there were things like "+value:structure|level=2+". That display the page again as title. I changed it to include "display=title". That is ok for me.
But the contents widget is somewhat strang. I have the actual defaul structure layout including

/system
   /management
   /templates
   /components

On all the pages the children pages or components are included in the display. I can't get rid of them. If I make the /system/components/contents a ** link then I only get the link. If I have a ++ link then I get the page plus all subpages included. 

Any ideas?

Norbert

From renggli at gmail.com  Fri Oct 15 16:30:26 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 15 Oct 2010 16:30:26 +0200
Subject: Upgrade Pier-Model-lr.392
In-Reply-To: <22B9D490-807E-4525-93CA-ED7D89CEEC9B@hartl.name>
References: <22B9D490-807E-4525-93CA-ED7D89CEEC9B@hartl.name>
Message-ID: <AANLkTi=0gnn62XUwHLfRyu25AUF-85+wAe8+CsSCrpi-@mail.gmail.com>

I don't understand the problem you are describing, but the change of
value links can be fixed by replacing all +value:...+ with
*value:...*, if they do not have the parameter 'embed'. I guess that
could be even scripted.

Lukas

On 15 October 2010 16:02, Norbert Hartl <norbert at hartl.name> wrote:
> The change in */+ detection has some strange side effects. In my old templates there were things like "+value:structure|level=2+". That display the page again as title. I changed it to include "display=title". That is ok for me.
> But the contents widget is somewhat strang. I have the actual defaul structure layout including
>
> /system
> ? /management
> ? /templates
> ? /components
>
> On all the pages the children pages or components are included in the display. I can't get rid of them. If I make the /system/components/contents a ** link then I only get the link. If I have a ++ link then I get the page plus all subpages included.
>
> Any ideas?
>
> Norbert
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Fri Oct 15 17:19:04 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 15 Oct 2010 17:19:04 +0200
Subject: PRKernel subclasses and pier configuration
In-Reply-To: <6FAB7F67-0693-409D-A2A1-E5BC0314B380@hartl.name>
References: <6FAB7F67-0693-409D-A2A1-E5BC0314B380@hartl.name>
Message-ID: <AANLkTi=+73mc-4qL0=dke1=+sxvfMMHxcWqFtGHRaL7W@mail.gmail.com>

Integrating the change is a no-brainer.

The question is why you feel the need to subclass the kernel? I've
never seen anybody doing this.

Lukas

On 15 October 2010 12:58, Norbert Hartl <norbert at hartl.name> wrote:
> I started to use my custom kernel classes and couldn't see them in the pier configuration drop-down. So I changed the implementation that the drop-down displays not only all instances of PRKernel but all instances of PRKernel and subclasses.
>
> Norbert
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From norbert at hartl.name  Fri Oct 15 17:26:25 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Oct 2010 17:26:25 +0200
Subject: PRKernel subclasses and pier configuration
In-Reply-To: <AANLkTi=+73mc-4qL0=dke1=+sxvfMMHxcWqFtGHRaL7W@mail.gmail.com>
References: <6FAB7F67-0693-409D-A2A1-E5BC0314B380@hartl.name>
	<AANLkTi=+73mc-4qL0=dke1=+sxvfMMHxcWqFtGHRaL7W@mail.gmail.com>
Message-ID: <1392A9EC-828E-4B27-964B-638C7C0C9280@hartl.name>


On 15.10.2010, at 17:19, Lukas Renggli wrote:

> Integrating the change is a no-brainer.
> 
> The question is why you feel the need to subclass the kernel? I've
> never seen anybody doing this.
> 
You are right in my case there isn't one. Well, I subclassed it to add an instance variable to it but as soon as I hit the reply button to answer you I remembered that I could put it in properties instead. But anyway it is a personal choice how to do it so offering subclasses in the configuration is a good idea.

Norbert

> 
> On 15 October 2010 12:58, Norbert Hartl <norbert at hartl.name> wrote:
>> I started to use my custom kernel classes and couldn't see them in the pier configuration drop-down. So I changed the implementation that the drop-down displays not only all instances of PRKernel but all instances of PRKernel and subclasses.
>> 
>> Norbert
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101015/fd5d3658/attachment.html>

From norbert at hartl.name  Fri Oct 15 17:31:11 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Oct 2010 17:31:11 +0200
Subject: Upgrade Pier-Model-lr.392
In-Reply-To: <AANLkTi=0gnn62XUwHLfRyu25AUF-85+wAe8+CsSCrpi-@mail.gmail.com>
References: <22B9D490-807E-4525-93CA-ED7D89CEEC9B@hartl.name>
	<AANLkTi=0gnn62XUwHLfRyu25AUF-85+wAe8+CsSCrpi-@mail.gmail.com>
Message-ID: <B826CEE4-97AC-48D1-8D4A-C67FDFD2D78F@hartl.name>

Ah, I'm sorry. I didn't see that there is a +value+ link on my system page as well

Norbert

On 15.10.2010, at 16:30, Lukas Renggli wrote:

> I don't understand the problem you are describing, but the change of
> value links can be fixed by replacing all +value:...+ with
> *value:...*, if they do not have the parameter 'embed'. I guess that
> could be even scripted.
> 
> Lukas
> 
> On 15 October 2010 16:02, Norbert Hartl <norbert at hartl.name> wrote:
>> The change in */+ detection has some strange side effects. In my old templates there were things like "+value:structure|level=2+". That display the page again as title. I changed it to include "display=title". That is ok for me.
>> But the contents widget is somewhat strang. I have the actual defaul structure layout including
>> 
>> /system
>>   /management
>>   /templates
>>   /components
>> 
>> On all the pages the children pages or components are included in the display. I can't get rid of them. If I make the /system/components/contents a ** link then I only get the link. If I have a ++ link then I get the page plus all subpages included.
>> 
>> Any ideas?
>> 
>> Norbert
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From renggli at gmail.com  Fri Oct 15 17:35:29 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 15 Oct 2010 17:35:29 +0200
Subject: PRKernel subclasses and pier configuration
In-Reply-To: <1392A9EC-828E-4B27-964B-638C7C0C9280@hartl.name>
References: <6FAB7F67-0693-409D-A2A1-E5BC0314B380@hartl.name>
	<AANLkTi=+73mc-4qL0=dke1=+sxvfMMHxcWqFtGHRaL7W@mail.gmail.com>
	<1392A9EC-828E-4B27-964B-638C7C0C9280@hartl.name>
Message-ID: <AANLkTikOxHUgHoCRoQ5UkcKPmzPRrPqx2FAck-3+_0nb@mail.gmail.com>

The problem is that creating subclasses likely also breaks other
places, for example serialization. We have to check that.

Lukas

On 15 October 2010 17:26, Norbert Hartl <norbert at hartl.name> wrote:
>
> On 15.10.2010, at 17:19, Lukas Renggli wrote:
>
> Integrating the change is a no-brainer.
>
> The question is why you feel the need to subclass the kernel? I've
> never seen anybody doing this.
>
> You are right in my case there isn't one. Well, I subclassed it to add an
> instance variable to it but as soon as I hit the reply button to answer you
> I remembered that I could put it in properties instead. But anyway it is a
> personal choice how to do it so offering subclasses in the configuration is
> a good idea.
> Norbert
>
> On 15 October 2010 12:58, Norbert Hartl <norbert at hartl.name> wrote:
>
> I started to use my custom kernel classes and couldn't see them in the pier
> configuration drop-down. So I changed the implementation that the drop-down
> displays not only all instances of PRKernel but all instances of PRKernel
> and subclasses.
>
> Norbert
>
>
> _______________________________________________
>
> Magritte, Pier and Related Tools ...
>
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From razavi at acm.org  Sun Oct 17 15:55:00 2010
From: razavi at acm.org (Reza Razavi)
Date: Sun, 17 Oct 2010 15:55:00 +0200
Subject: An on-line programmable CMS
Message-ID: <2a60de$2ne8n@smtp.pt.lu>

Dear all,

I would like to bring to your attention the availability of an 
on-line programmable content management system at:
<http://www.afacms.com/>http://www.afacms.com/.

It is implemented by a home-made software platform that reuses and 
extends Seaside and Pier CMS. For more information, please check the 
following post (also copied below for your convenience):
<http://www.afacms.com/blog/pontoon-app>http://www.afacms.com/blog/pontoon-app

I would like to take this opportunity to thank You, and all Smalltalk 
communities for their outstanding contributions that have made this 
work possible.
Best regards,
Reza Razavi

The goal of this website is to illustrate the concept of on-line 
programmable CMS, i.e., a web application that behaves both as a 
content management and an on-line programming system. This web site 
is a distribution of [1]. It's by no means a production site. It 
actually runs on a VPS with quite limited resources.

New functionality may be implemented and integrated on-line by 
composing atomic services (in the sense of SOA). The site provides 
Seaside jQuery-based graphical interfaces for service composition 
[2]. For a step-by-step on-line programming guide, please check [3]. 
For any further inquiries, please contact me.

Atomic services may be of different kinds:
- Interactive web components, like Seaside components,
- Pure computational components, like mathematical algorithms,
- Sensing components, like measurement requests in industrial metrology,
- Actuation components, like robot commands in manufacturing, and, 
last but not least,
- Control flow components, like iterations and conditionals.

Websites like this one describe their atomic services as "contracts", 
and makes them available on-line [4]. To illustrate the applicability 
of this concept to diverse domains, this website proposes a variety 
of (rather simple) atomic services, which relate to areas such as 
on-line shopping (for the Seaside sushi example) [5], communication 
[6], e-learning for students [7], e-teaching for Older Adults [8], 
and entertainment [9]. Flow control constructions are also 
represented explicitly as contracts [10], and may be defined 
according to the application requirements. Other kinds of atomic 
services may also be added, even dynamically, depending on the 
application requirements.

Domain concepts that end-users care about and their instances may 
also be managed on-line, via a sort of on-line class and instance 
browser [11].

In real-life deployments, the above-mentioned on-line programming 
tools that are made here publicly available may be only made 
accessible to qualified end-users.

This web site is an example of pontoon application as I presented at 
IWST'2010 [12]. It's implemented by reusing and extending Seaside and 
Pier CMS, as also presented in an IWST'2010 paper, which will shortly 
be available via [13] and also the ACM DL [14]. In the meanwhile, I 
can provide a copy to interested parties upon request.

Application domains may be diverse [15]. We are currently 
investigating opportunities for very large scale deployments related 
to the concept of web as a service innovation platform.

References:
[1] http://www.aas-platform.com
[2] http://www.afacms.com/cats/activities/
[3] http://www.afacms.com/examples
[4] 
<http://www.afacms.com/cats/contracts/>http://www.afacms.com/cats/contracts/
[5] http://www.afacms.com/cats/contracts/shopping/
[6] 
<http://www.afacms.com/cats/contracts/communication/>http://www.afacms.com/cats/contracts/communication/ 

[7] http://www.afacms.com/cats/contracts/maths/
[8] 
<http://www.afacms.com/cats/contracts/elderly/>http://www.afacms.com/cats/contracts/elderly/ 

[9] http://www.afacms.com/cats/contracts/music/
[10] 
<http://www.afacms.com/cats/contracts/controlflow/>http://www.afacms.com/cats/contracts/controlflow/ 

[11] http://www.afacms.com/cats/concepts/
[12] 
http://www.esug.org/wiki/pier/Conferences/2010/International%20Workshop%20on%20Smalltalk%20Technologies 

[13] 
http://www.hpi.uni-potsdam.de/forschung/publikationen/technische_berichte.html?L=1
[14] <http://portal.acm.org/dl.cfm>http://portal.acm.org/dl.cfm
[15] http://www.aas-platform.com/about/applications/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101017/a90a1e70/attachment.html>

From nick.ager at gmail.com  Tue Oct 19 15:05:13 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 19 Oct 2010 14:05:13 +0100
Subject: removing the session and action field from the Url
Message-ID: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>

Hi,

I remember reading or someone saying that in Pier it's possible to remove
the _s and _k from a Url? I've searched my image and the repositories and
drawn a blank. Any pointers?

Thanks

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101019/1215d081/attachment.html>

From renggli at gmail.com  Tue Oct 19 15:54:25 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 19 Oct 2010 15:54:25 +0200
Subject: removing the session and action field from the Url
In-Reply-To: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>
References: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>
Message-ID: <AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.com>

That should be the default from Pier 1.2 on (see
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137375.html).
The reason why you are asking is probably because it is broken in Pier
2.0? I will try to have a look later this year, unless somebody else
could identify the source of the problem :-)

Lukas

On 19 October 2010 15:05, Nick Ager <nick.ager at gmail.com> wrote:
> Hi,
> I remember reading or someone saying that in Pier it's possible to remove
> the _s and _k from a Url? I've searched my image and the repositories and
> drawn a blank. Any pointers?
> Thanks
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From nick.ager at gmail.com  Tue Oct 19 16:15:50 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 19 Oct 2010 15:15:50 +0100
Subject: removing the session and action field from the Url
In-Reply-To: <AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.com>
References: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>
	<AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.com>
Message-ID: <AANLkTikAogajFkJ0N1c+LCoT36Wi2CDcKJoqgPx2y8FU@mail.gmail.com>

Thanks Lukas, If I get a chance I'll investigate further, though currently I
seem to be better at reporting bugs than fixing them

On 19 October 2010 14:54, Lukas Renggli <renggli at gmail.com> wrote:

> That should be the default from Pier 1.2 on (see
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137375.html
> ).
> The reason why you are asking is probably because it is broken in Pier
> 2.0? I will try to have a look later this year, unless somebody else
> could identify the source of the problem :-)
>
> Lukas
>
> On 19 October 2010 15:05, Nick Ager <nick.ager at gmail.com> wrote:
> > Hi,
> > I remember reading or someone saying that in Pier it's possible to remove
> > the _s and _k from a Url? I've searched my image and the repositories and
> > drawn a blank. Any pointers?
> > Thanks
> > Nick
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101019/ce38371d/attachment-0001.html>

From renggli at gmail.com  Tue Oct 19 16:20:27 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 19 Oct 2010 16:20:27 +0200
Subject: removing the session and action field from the Url
In-Reply-To: <AANLkTikAogajFkJ0N1c+LCoT36Wi2CDcKJoqgPx2y8FU@mail.gmail.com>
References: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>
	<AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.com>
	<AANLkTikAogajFkJ0N1c+LCoT36Wi2CDcKJoqgPx2y8FU@mail.gmail.com>
Message-ID: <AANLkTinOKsLZBS=p=9XjcsQxju8JzxhCB5js9AymgxBR@mail.gmail.com>

I've created a bug report
<http://code.google.com/p/pier/issues/detail?id=123> so that it does
not get forgotten. It is generally a good idea to also report it here
tough, so that it gets attention.

Lukas

On 19 October 2010 16:15, Nick Ager <nick.ager at gmail.com> wrote:
> Thanks Lukas, If I get a chance I'll investigate further, though currently I
> seem to be better at reporting bugs than fixing them
>
> On 19 October 2010 14:54, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> That should be the default from Pier 1.2 on (see
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137375.html).
>> The reason why you are asking is probably because it is broken in Pier
>> 2.0? I will try to have a look later this year, unless somebody else
>> could identify the source of the problem :-)
>>
>> Lukas
>>
>> On 19 October 2010 15:05, Nick Ager <nick.ager at gmail.com> wrote:
>> > Hi,
>> > I remember reading or someone saying that in Pier it's possible to
>> > remove
>> > the _s and _k from a Url? I've searched my image and the repositories
>> > and
>> > drawn a blank. Any pointers?
>> > Thanks
>> > Nick
>> > _______________________________________________
>> > Magritte, Pier and Related Tools ...
>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From razavi at acm.org  Wed Oct 20 14:41:50 2010
From: razavi at acm.org (Reza Razavi)
Date: Wed, 20 Oct 2010 14:41:50 +0200
Subject: New Pier-based websites
Message-ID: <e69f63$3teig@smtp.pt.lu>

Hi Lukas,

Please find below a few new websites that run Pier.

For your convenience, I've organised them according to the categories 
in your "installations" page at 
<http://www.piercms.com/doc/examples>http://www.piercms.com/doc/examples.

Good luck for your PhD defense.
Regards,
Reza

Projects
- AAS-Platform (<http://aas-platform.com/>http://aas-platform.com/)
- User-Generated Services: a demo website 
(<http://afacms.com/>http://afacms.com/)

Organizations and Groups
- Pontoon Community (<http://pontoonity.com/>http://pontoonity.com/)

Companies
- Ambient Activity Systems (<http://www.urfid.biz/>http://www.urfid.biz/)

Individuals
- Reza Razavi (<http://rezarazavi.com/>http://rezarazavi.com/)
- Goya Razavi (<http://goyarazavi.com/>http://goyarazavi.com/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101020/587802cf/attachment.html>

From razavi at acm.org  Wed Oct 20 14:55:19 2010
From: razavi at acm.org (Reza Razavi)
Date: Wed, 20 Oct 2010 14:55:19 +0200
Subject: removing the session and action field from the Url
In-Reply-To: <AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.c
 om>
References: <AANLkTikWgK79NVvm6BKPSSGm16TeU_avR=g=fNjNbAXC@mail.gmail.com>
	<AANLkTimy74HTR3bUm1-=d6tSoze9KBj=oLJHMZPXng4W@mail.gmail.com>
Message-ID: <e69f63$3tkj7@smtp.pt.lu>

At 15:54 19/10/2010, Lukas Renggli wrote:
>That should be the default from Pier 1.2 on (see
>http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137375.html).
>The reason why you are asking is probably because it is broken in Pier
>2.0?

If I remember well, I lost that feature after you integrated the 
#isRestful test in PRContext >> urlOn:. Unfortunately, I don't have 
access right now to my working image to investigate it more.

Hoping this helps,
Reza


From norbert at hartl.name  Thu Oct 21 11:30:11 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 21 Oct 2010 11:30:11 +0200
Subject: parameter and accessor
Message-ID: <B51D7FA6-BA46-4F41-AEA7-B777171989CD@hartl.name>

I'm embedding a component in a page like this

+component|className=HRWine+

On the embedded component I have

descriptionContextClassName
	^ MAStringDescription new
		parameterName: 'className';
		accessor: #contextClassName;
		priority: 100;
		label: 'Name of the context class';
		beRequired;
		yourself

What I get is an entry in the components properties with an association description -> value. That is good so far. I'm asking myself what is the best way to access the value. If I don't specify an accessor on the description magritte creates one itself leading to equality check failing in properties when doing

self propertyAt: self class descriptionContextClassName.

But if I have to specify an accessor I'm wondering why the accessor isn't used to store the value in the component.

Do I misunderstand something or is there a preferred way of accessing parameter values?

thanks,

Norbert

From renggli at gmail.com  Thu Oct 21 12:22:18 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 21 Oct 2010 12:22:18 +0200
Subject: New Pier-based websites
In-Reply-To: <e69f63$3teig@smtp.pt.lu>
References: <e69f63$3teig@smtp.pt.lu>
Message-ID: <AANLkTi=JEr8KXGJYJAMWnDXarRBx8iP1F7snYQZAqNzy@mail.gmail.com>

Wow, thank you, that's a wealth of new sites. I've added them to the list on

     http://www.piercms.com/doc/examples

Lukas

On 20 October 2010 14:41, Reza Razavi <razavi at acm.org> wrote:
> Hi Lukas,
>
> Please find below a few new websites that run Pier.
>
> For your convenience, I've organised them according to the categories in
> your "installations" page at http://www.piercms.com/doc/examples.
>
> Good luck for your PhD defense.
> Regards,
> Reza
>
> Projects
> - AAS-Platform (http://aas-platform.com/)
> - User-Generated Services: a demo website (http://afacms.com/)
>
> Organizations and Groups
> - Pontoon Community (http://pontoonity.com/)
>
> Companies
> - Ambient Activity Systems (http://www.urfid.biz/)
>
> Individuals
> - Reza Razavi (http://rezarazavi.com/)
> - Goya Razavi (http://goyarazavi.com/)
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch

From razavi at acm.org  Thu Oct 21 15:27:47 2010
From: razavi at acm.org (Reza Razavi)
Date: Thu, 21 Oct 2010 15:27:47 +0200
Subject: New Pier-based websites
In-Reply-To: <AANLkTi=JEr8KXGJYJAMWnDXarRBx8iP1F7snYQZAqNzy@mail.gmail.c
 om>
References: <e69f63$3teig@smtp.pt.lu>
	<AANLkTi=JEr8KXGJYJAMWnDXarRBx8iP1F7snYQZAqNzy@mail.gmail.com>
Message-ID: <2a60de$4ied9@smtp.pt.lu>

Thanks Lukas for your feedback and integration! Let me add that this 
is just the "starter". As an extension to the OLPC project idea and 
implementation, I continue to believe that there is space to deploy 
one server per citizen, and a batch of 100000 servers in already 
being planned for a relatively close future (so, you would probably 
need to somehow automate their integration in your "installations" 
page ;-)). I'll keep you informed.
/Reza

At 12:22 21/10/2010, Lukas Renggli wrote:
>Wow, thank you, that's a wealth of new sites. I've added them to the list on
>
>      http://www.piercms.com/doc/examples
>
>Lukas
>
>On 20 October 2010 14:41, Reza Razavi <razavi at acm.org> wrote:
> > Hi Lukas,
> >
> > Please find below a few new websites that run Pier.
> >
> > For your convenience, I've organised them according to the categories in
> > your "installations" page at http://www.piercms.com/doc/examples.
> >
> > Good luck for your PhD defense.
> > Regards,
> > Reza
> >
> > Projects
> > - AAS-Platform (http://aas-platform.com/)
> > - User-Generated Services: a demo website (http://afacms.com/)
> >
> > Organizations and Groups
> > - Pontoon Community (http://pontoonity.com/)
> >
> > Companies
> > - Ambient Activity Systems (http://www.urfid.biz/)
> >
> > Individuals
> > - Reza Razavi (http://rezarazavi.com/)
> > - Goya Razavi (http://goyarazavi.com/)
> >
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
>
>--
>Lukas Renggli
>www.lukas-renggli.ch
>_______________________________________________
>Magritte, Pier and Related Tools ...
>https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From norbert at hartl.name  Fri Oct 22 13:57:47 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 22 Oct 2010 13:57:47 +0200
Subject: onAnswerCommand and structure change
Message-ID: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>

I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked.

Basically I do something like this

	html anchor
		goto: (self context 
				structure: self structureWhileCommandIsExecuting
				command: MyPierCommand new);
		with: 'do it' ]

In MyPierCommand>>doExecute I do at the end

self answer: (self context structure: self structureAfterCommandHasBeingCommited )

This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at 

PRContentsWidget>>onAnswerCommand: aCommand
	aCommand isNil
		ifTrue: [ ^ self context: (self context structure: self context structure) ].
	[ aCommand execute ]
		on: MAError
		do: [ :err | ^ self component errors add: err ].
	self context: aCommand answer

we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change 

buildComponent: aContext
	^ aContext command asComponent
		onAnswer: [ :value | self onAnswerCommand: value ];
		yourself

to

buildComponent: aContext
	^ aContext command asComponent
		onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ];
		yourself

this way 

PRCommand>>doAnswer
	self answer ifNil: [ self answer: (self context structure: self structure) ]

would the same but some could overwrite the answer when creating the link

what do you think?

Norbert

From nick.ager at gmail.com  Fri Oct 22 17:12:02 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 22 Oct 2010 16:12:02 +0100
Subject: getitmade.com
Message-ID: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>

Hi

The rush of Pier powered sites continues unabated .... We've just made
getitmade.com live.

Still lots to do - not least of which is to find some launch customers who
want to turn their prototype creations into products....

Thanks to everyone and especially Lukas for patiently answering my
Seaside/Magritte/Pier questions.

I'm particularly pleased with our Magritte forms - see attached image. It's
a fantastically powerful, yet flexible framework.

Thanks again

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/a5e88fae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getitmade-magritte form.png
Type: image/png
Size: 111226 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/a5e88fae/attachment-0001.png>

From razavi at acm.org  Fri Oct 22 17:22:09 2010
From: razavi at acm.org (Reza Razavi)
Date: Fri, 22 Oct 2010 17:22:09 +0200
Subject: getitmade.com
In-Reply-To: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.c
 om>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
Message-ID: <ae3f9f$3fuqiq@smtp.pt.lu>

Impressive; congratulations Nick!
This is exactly what I've been looking for; I'll be posting product 
ideas soon...
Good luck,
/Reza

At 17:12 22/10/2010, Nick Ager wrote:
>Hi
>
>The rush of Pier powered sites continues unabated .... We've just 
>made <http://getitmade.com>getitmade.com live.
>
>Still lots to do - not least of which is to find some launch 
>customers who want to turn their prototype creations into products....
>
>Thanks to everyone and especially Lukas for patiently answering my 
>Seaside/Magritte/Pier questions.
>
>I'm particularly pleased with our Magritte forms - see attached 
>image. It's a fantastically powerful, yet flexible framework.
>
>Thanks again
>
>Nick
>
>
>Content-Type: image/png; name="getitmade-magritte form.png"
>Content-Disposition: attachment; filename="getitmade-magritte form.png"
>X-Attachment-Id: f_gfl768py0
>
>_______________________________________________
>Magritte, Pier and Related Tools ...
>https://www.iam.unibe.ch/mailman/listinfo/smallwiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/24ad898c/attachment.html>

From renggli at gmail.com  Fri Oct 22 17:35:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 22 Oct 2010 17:35:11 +0200
Subject: getitmade.com
In-Reply-To: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
Message-ID: <AANLkTim0WQCXCaCH-KmxGq-j-QPF-CAJPCJ=snW6NOih@mail.gmail.com>

Hi Nick,

Very cool design. I've already added the link to the known sites after
reading you tweet :-)

Lukas

On Friday, October 22, 2010, Nick Ager <nick.ager at gmail.com> wrote:
> Hi
> The rush of Pier powered sites continues unabated .... We've just made getitmade.com live.
> Still lots to do - not least of which is to find some launch customers who want to turn their prototype creations into products....
>
> Thanks to everyone and especially Lukas for patiently answering my Seaside/Magritte/Pier questions.
> I'm particularly pleased with our Magritte forms - see attached image. It's a fantastically powerful, yet flexible framework.
>
> Thanks again
> Nick
>
>
>

-- 
Lukas Renggli
www.lukas-renggli.ch

From pennell.david at gmail.com  Fri Oct 22 18:05:44 2010
From: pennell.david at gmail.com (David Pennell)
Date: Fri, 22 Oct 2010 11:05:44 -0500
Subject: getitmade.com
In-Reply-To: <AANLkTinLC46yzy6ryQd=Gzdg_ZjGA8iC9MEL03WoBNz0@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTim0WQCXCaCH-KmxGq-j-QPF-CAJPCJ=snW6NOih@mail.gmail.com>
	<AANLkTinLC46yzy6ryQd=Gzdg_ZjGA8iC9MEL03WoBNz0@mail.gmail.com>
Message-ID: <AANLkTikW_Y8X3ssxQRoM_vi2yqo323F2QQpypFr4aPZ9@mail.gmail.com>

Very nice!  It would be wonderful to see a little write-up on how you
constructed this.  Which parts you were able to re-use and what you had to
build yourself.

-david

On Fri, Oct 22, 2010 at 11:02 AM, David Pennell <dpennell at good-cloud.com>wrote:

> Very nice!  It would be wonderful to see a little write-up on how you
> constructed this.  Which parts you were able to re-use and what you had to
> build yourself.
>
> -david
>
>
> On Fri, Oct 22, 2010 at 10:35 AM, Lukas Renggli <renggli at gmail.com> wrote:
>
>> Hi Nick,
>>
>> Very cool design. I've already added the link to the known sites after
>> reading you tweet :-)
>>
>> Lukas
>>
>> On Friday, October 22, 2010, Nick Ager <nick.ager at gmail.com> wrote:
>> > Hi
>> > The rush of Pier powered sites continues unabated .... We've just made
>> getitmade.com live.
>> > Still lots to do - not least of which is to find some launch customers
>> who want to turn their prototype creations into products....
>> >
>> > Thanks to everyone and especially Lukas for patiently answering my
>> Seaside/Magritte/Pier questions.
>> > I'm particularly pleased with our Magritte forms - see attached image.
>> It's a fantastically powerful, yet flexible framework.
>> >
>> > Thanks again
>> > Nick
>> >
>> >
>> >
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/1031a7ff/attachment.html>

From nick.ager at gmail.com  Fri Oct 22 18:11:57 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 22 Oct 2010 17:11:57 +0100
Subject: getitmade.com
In-Reply-To: <AANLkTikW_Y8X3ssxQRoM_vi2yqo323F2QQpypFr4aPZ9@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTim0WQCXCaCH-KmxGq-j-QPF-CAJPCJ=snW6NOih@mail.gmail.com>
	<AANLkTinLC46yzy6ryQd=Gzdg_ZjGA8iC9MEL03WoBNz0@mail.gmail.com>
	<AANLkTikW_Y8X3ssxQRoM_vi2yqo323F2QQpypFr4aPZ9@mail.gmail.com>
Message-ID: <AANLkTinBBz-kzvc4RUZTZ=w9Wd9w_XegxnQ+oJpy070r@mail.gmail.com>

Hi David,

On 22 October 2010 17:05, David Pennell <pennell.david at gmail.com> wrote:

> Very nice!  It would be wonderful to see a little write-up on how you
> constructed this.  Which parts you were able to re-use and what you had to
> build yourself.


Thanks.  It's definitely on my to-do list. I'll see what I can do...

Nick




> -david
>
> On Fri, Oct 22, 2010 at 11:02 AM, David Pennell <dpennell at good-cloud.com>wrote:
>
>> Very nice!  It would be wonderful to see a little write-up on how you
>> constructed this.  Which parts you were able to re-use and what you had to
>> build yourself.
>>
>> -david
>>
>>
>> On Fri, Oct 22, 2010 at 10:35 AM, Lukas Renggli <renggli at gmail.com>wrote:
>>
>>> Hi Nick,
>>>
>>> Very cool design. I've already added the link to the known sites after
>>> reading you tweet :-)
>>>
>>> Lukas
>>>
>>> On Friday, October 22, 2010, Nick Ager <nick.ager at gmail.com> wrote:
>>> > Hi
>>> > The rush of Pier powered sites continues unabated .... We've just made
>>> getitmade.com live.
>>> > Still lots to do - not least of which is to find some launch customers
>>> who want to turn their prototype creations into products....
>>> >
>>> > Thanks to everyone and especially Lukas for patiently answering my
>>> Seaside/Magritte/Pier questions.
>>> > I'm particularly pleased with our Magritte forms - see attached image.
>>> It's a fantastically powerful, yet flexible framework.
>>> >
>>> > Thanks again
>>> > Nick
>>> >
>>> >
>>> >
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>
>>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/15459238/attachment.html>

From nick.ager at gmail.com  Fri Oct 22 19:01:11 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 22 Oct 2010 18:01:11 +0100
Subject: onAnswerCommand and structure change
In-Reply-To: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
Message-ID: <AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>

Hi Norbert,

I think I might have solved a similar problem in a different way.  I created
a "clean" environment specifically for non-view commands.

Then I derived from PRPierFrame and implemented:

environment
^ self context command useEditingEnvironment ifTrue: [
self kernel editingEnvironment
] ifFalse: [
self context structure environment
]

Then:

PRCommand>>useEditingEnvironment
^ (self isView or: [self isQuick]) not


---

Other ways round would be to create your own PRContents widget or return a
command with the structure you want to display, instead of returning nil

---

I only mention the above work-arounds as I don't have enough knowledge to
say for certain that your changes wouldn't cause unintended side-effects..


Hope this helps

Nick





On 22 October 2010 12:57, Norbert Hartl <norbert at hartl.name> wrote:

> I like to execute a command in a way that the structure is changed while
> the command is being executed. If the command is commited I like to advance
> the structure to another structure. If the command is aborted than I like to
> return to the structure from where the command has been invoked.
>
> Basically I do something like this
>
>        html anchor
>                goto: (self context
>                                structure: self
> structureWhileCommandIsExecuting
>                                command: MyPierCommand new);
>                with: 'do it' ]
>
> In MyPierCommand>>doExecute I do at the end
>
> self answer: (self context structure: self
> structureAfterCommandHasBeingCommited )
>
> This way I have chose a structure for command execution and the structure
> if the command is commited. But on abort it stays where it has been executed
> (structureWhileCommandIsExecuting). Looking at
>
> PRContentsWidget>>onAnswerCommand: aCommand
>        aCommand isNil
>                ifTrue: [ ^ self context: (self context structure: self
> context structure) ].
>        [ aCommand execute ]
>                on: MAError
>                do: [ :err | ^ self component errors add: err ].
>        self context: aCommand answer
>
> we see that if aCommand isNil (abort) the structure is nailed to the
> current one (while executing). Would it be ok to change that so it is
> answering every time? I simple change would be to change
>
> buildComponent: aContext
>        ^ aContext command asComponent
>                onAnswer: [ :value | self onAnswerCommand: value ];
>                yourself
>
> to
>
> buildComponent: aContext
>        ^ aContext command asComponent
>                onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand:
> value ] ifNil: [ aContext command doAnswer ] ];
>                yourself
>
> this way
>
> PRCommand>>doAnswer
>        self answer ifNil: [ self answer: (self context structure: self
> structure) ]
>
> would the same but some could overwrite the answer when creating the link
>
> what do you think?
>
> Norbert
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/3660b93e/attachment-0001.html>

From hernan.wilkinson at 10pines.com  Fri Oct 22 23:10:05 2010
From: hernan.wilkinson at 10pines.com (Hernan Wilkinson)
Date: Fri, 22 Oct 2010 18:10:05 -0300
Subject: getitmade.com
In-Reply-To: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
Message-ID: <AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>

congratulation Nick! really cool design and idea!

Hernan.

On Fri, Oct 22, 2010 at 12:12 PM, Nick Ager <nick.ager at gmail.com> wrote:

> Hi
>
> The rush of Pier powered sites continues unabated .... We've just made
> getitmade.com live.
>
> Still lots to do - not least of which is to find some launch customers who
> want to turn their prototype creations into products....
>
> Thanks to everyone and especially Lukas for patiently answering my
> Seaside/Magritte/Pier questions.
>
> I'm particularly pleased with our Magritte forms - see attached image. It's
> a fantastically powerful, yet flexible framework.
>
> Thanks again
>
> Nick
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
*Hern?n Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkinson at 10Pines.com
site: http://www.10Pines.com <http://www.10pines.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/a09f8299/attachment.html>

From marianopeck at gmail.com  Fri Oct 22 23:15:42 2010
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Fri, 22 Oct 2010 23:15:42 +0200
Subject: getitmade.com
In-Reply-To: <AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
Message-ID: <AANLkTinTk2wxC4GFa77U8aAnJ1cXYsqBEteGSx9dBtK6@mail.gmail.com>

Nick, this is awesome. Seriously, I really hope you can do bussiness with
this. It seems very very nice :)

Congrats

mariano

On Fri, Oct 22, 2010 at 11:10 PM, Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> congratulation Nick! really cool design and idea!
>
> Hernan.
>
> On Fri, Oct 22, 2010 at 12:12 PM, Nick Ager <nick.ager at gmail.com> wrote:
>
>> Hi
>>
>> The rush of Pier powered sites continues unabated .... We've just made
>> getitmade.com live.
>>
>> Still lots to do - not least of which is to find some launch customers who
>> want to turn their prototype creations into products....
>>
>> Thanks to everyone and especially Lukas for patiently answering my
>> Seaside/Magritte/Pier questions.
>>
>> I'm particularly pleased with our Magritte forms - see attached image.
>> It's a fantastically powerful, yet flexible framework.
>>
>> Thanks again
>>
>> Nick
>>
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> *Hern?n Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: hernan.wilkinson at 10Pines.com
> site: http://www.10Pines.com <http://www.10pines.com/>*
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101022/a1691ed8/attachment.html>

From tudor.girba at gmail.com  Fri Oct 22 23:42:07 2010
From: tudor.girba at gmail.com (Tudor Girba)
Date: Fri, 22 Oct 2010 23:42:07 +0200
Subject: getitmade.com
In-Reply-To: <AANLkTinTk2wxC4GFa77U8aAnJ1cXYsqBEteGSx9dBtK6@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
	<AANLkTinTk2wxC4GFa77U8aAnJ1cXYsqBEteGSx9dBtK6@mail.gmail.com>
Message-ID: <C25A9970-B101-48A2-BA12-188381AF6956@gmail.com>

Congratulations!

Cheers,
Doru


On 22 Oct 2010, at 23:15, Mariano Martinez Peck wrote:

> Nick, this is awesome. Seriously, I really hope you can do bussiness with this. It seems very very nice :)
> 
> Congrats
> 
> mariano
> 
> On Fri, Oct 22, 2010 at 11:10 PM, Hernan Wilkinson <hernan.wilkinson at 10pines.com> wrote:
> congratulation Nick! really cool design and idea!
> 
> Hernan.
> 
> On Fri, Oct 22, 2010 at 12:12 PM, Nick Ager <nick.ager at gmail.com> wrote:
> Hi
> 
> The rush of Pier powered sites continues unabated .... We've just made getitmade.com live. 
> 
> Still lots to do - not least of which is to find some launch customers who want to turn their prototype creations into products....
> 
> Thanks to everyone and especially Lukas for patiently answering my Seaside/Magritte/Pier questions. 
> 
> I'm particularly pleased with our Magritte forms - see attached image. It's a fantastically powerful, yet flexible framework. 
> 
> Thanks again
> 
> Nick
> 
> 
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> Hern?n Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: hernan.wilkinson at 10Pines.com
> site: http://www.10Pines.com
> 
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

--
www.tudorgirba.com

"Reasonable is what we are accustomed with."



From jacaetevha at gmail.com  Sat Oct 23 00:54:23 2010
From: jacaetevha at gmail.com (Jason Rogers)
Date: Fri, 22 Oct 2010 18:54:23 -0400
Subject: getitmade.com
In-Reply-To: <AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
Message-ID: <AANLkTimJ_96vtoG6RmTkksp0xdBPb1rGtKyj9YfApom+@mail.gmail.com>

Yes! Nice job with the site. Can you give particulars about your
setup? Apache? Number of images? Backend?

I hope the business takes off!

On Fri, Oct 22, 2010 at 5:10 PM, Hernan Wilkinson
<hernan.wilkinson at 10pines.com> wrote:
> congratulation Nick! really cool design and idea!
> Hernan.
>
> On Fri, Oct 22, 2010 at 12:12 PM, Nick Ager <nick.ager at gmail.com> wrote:
>>
>> Hi
>> The rush of Pier powered sites continues unabated .... We've just made
>> getitmade.com live.
>> Still lots to do - not least of which is to find some launch customers who
>> want to turn their prototype creations into products....
>> Thanks to everyone and especially Lukas for patiently answering my
>> Seaside/Magritte/Pier questions.
>> I'm particularly pleased with our Magritte forms - see attached image.
>> It's a fantastically powerful, yet flexible framework.
>> Thanks again
>> Nick
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> --
> Hern?n Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: hernan.wilkinson at 10Pines.com
> site:?http://www.10Pines.com
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Jason Rogers

"I am crucified with Christ: nevertheless I live;
yet not I, but Christ liveth in me: and the life
which I now live in the flesh I live by the faith of
the Son of God, who loved me, and gave
himself for me."
? ? Galatians 2:20


From nick.ager at gmail.com  Sat Oct 23 13:08:46 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sat, 23 Oct 2010 12:08:46 +0100
Subject: getitmade.com
In-Reply-To: <AANLkTimJ_96vtoG6RmTkksp0xdBPb1rGtKyj9YfApom+@mail.gmail.com>
References: <AANLkTikX3mQXKFKqQm3Oh5UQuKbuHpCivohPvntBZXRy@mail.gmail.com>
	<AANLkTimyMXMT8yYuujM=ZVY+9-tOguEkNCsL_shX1UbU@mail.gmail.com>
	<AANLkTimJ_96vtoG6RmTkksp0xdBPb1rGtKyj9YfApom+@mail.gmail.com>
Message-ID: <AANLkTim5QC24b2ubDio9w2a6VqVJMwk-vKN2Zumq89m2@mail.gmail.com>

Hi Jason,

Yes! Nice job with the site. Can you give particulars about your
> setup? Apache? Number of images? Backend?
>
>
I'm using Nginx at the front end and three GemStone "Gems" on the backend
responding to FastCGI requests from the webserver.
I initially went with lighttp as the webserver, but ended up using Nginx
instead so I could use it's reverse proxy support for https to a payment
service. You can read more about the setup from Sean Allen's helpful blog
post on the matter:
http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seaside-with-nginx.html

Cheers

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101023/586d931b/attachment.html>

From renggli at gmail.com  Mon Oct 25 08:28:30 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 25 Oct 2010 08:28:30 +0200
Subject: onAnswerCommand and structure change
In-Reply-To: <AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
	<AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
Message-ID: <AANLkTinH+aDc7ppwnUkYPw0O4yxLq15Wmw2drJzCEmUL@mail.gmail.com>

Norbert,

While what Nick proposes is a nice workaround, I think it would be
useful to let the command decide on the cancel continuation. However
the logic for that should go into the Model, not the View. Also we
have to pay attention not to use #ifNil:ifNotNil: and friends, because
that doesn't work across all supported platforms. Norbert, can you
provide a change?

Lukas

On 22 October 2010 19:01, Nick Ager <nick.ager at gmail.com> wrote:
> Hi Norbert,
> I think I might have solved a similar problem in a different way. ?I created
> a "clean" environment specifically for non-view commands.
> Then I derived from PRPierFrame and implemented:
> environment
> ^ self context command useEditingEnvironment ifTrue: [
> self kernel editingEnvironment
> ] ifFalse: [
> self context structure environment
> ]
> Then:
> PRCommand>>useEditingEnvironment
> ^ (self isView or: [self isQuick])?not
>
> ---
> Other ways round would be to create your own PRContents widget or return a
> command with the structure you want to display, instead of returning nil
> ---
> I only mention the above work-arounds as I don't have enough knowledge to
> say for certain that your changes wouldn't cause unintended side-effects..
>
> Hope this helps
> Nick
>
>
>
>
> On 22 October 2010 12:57, Norbert Hartl <norbert at hartl.name> wrote:
>>
>> I like to execute a command in a way that the structure is changed while
>> the command is being executed. If the command is commited I like to advance
>> the structure to another structure. If the command is aborted than I like to
>> return to the structure from where the command has been invoked.
>>
>> Basically I do something like this
>>
>> ? ? ? ?html anchor
>> ? ? ? ? ? ? ? ?goto: (self context
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?structure: self
>> structureWhileCommandIsExecuting
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?command: MyPierCommand new);
>> ? ? ? ? ? ? ? ?with: 'do it' ]
>>
>> In MyPierCommand>>doExecute I do at the end
>>
>> self answer: (self context structure: self
>> structureAfterCommandHasBeingCommited )
>>
>> This way I have chose a structure for command execution and the structure
>> if the command is commited. But on abort it stays where it has been executed
>> (structureWhileCommandIsExecuting). Looking at
>>
>> PRContentsWidget>>onAnswerCommand: aCommand
>> ? ? ? ?aCommand isNil
>> ? ? ? ? ? ? ? ?ifTrue: [ ^ self context: (self context structure: self
>> context structure) ].
>> ? ? ? ?[ aCommand execute ]
>> ? ? ? ? ? ? ? ?on: MAError
>> ? ? ? ? ? ? ? ?do: [ :err | ^ self component errors add: err ].
>> ? ? ? ?self context: aCommand answer
>>
>> we see that if aCommand isNil (abort) the structure is nailed to the
>> current one (while executing). Would it be ok to change that so it is
>> answering every time? I simple change would be to change
>>
>> buildComponent: aContext
>> ? ? ? ?^ aContext command asComponent
>> ? ? ? ? ? ? ? ?onAnswer: [ :value | self onAnswerCommand: value ];
>> ? ? ? ? ? ? ? ?yourself
>>
>> to
>>
>> buildComponent: aContext
>> ? ? ? ?^ aContext command asComponent
>> ? ? ? ? ? ? ? ?onAnswer: [ :value | value ifNotNil: [ self
>> onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ];
>> ? ? ? ? ? ? ? ?yourself
>>
>> this way
>>
>> PRCommand>>doAnswer
>> ? ? ? ?self answer ifNil: [ self answer: (self context structure: self
>> structure) ]
>>
>> would the same but some could overwrite the answer when creating the link
>>
>> what do you think?
>>
>> Norbert
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Mon Oct 25 08:30:43 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 25 Oct 2010 08:30:43 +0200
Subject: parameter and accessor
In-Reply-To: <B51D7FA6-BA46-4F41-AEA7-B777171989CD@hartl.name>
References: <B51D7FA6-BA46-4F41-AEA7-B777171989CD@hartl.name>
Message-ID: <AANLkTimCrJ6Y3WMRERKLiZBrzSOM6E5TRETNkAnYnFfd@mail.gmail.com>

> Do I misunderstand something or is there a preferred way of accessing parameter values?

Magritte uses the accessor also to establish the identity between
different descriptions, that's why you should always specify an
accessor even if you don't use it.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From renggli at gmail.com  Mon Oct 25 09:21:47 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 25 Oct 2010 09:21:47 +0200
Subject: onAnswerCommand and structure change
In-Reply-To: <AANLkTinH+aDc7ppwnUkYPw0O4yxLq15Wmw2drJzCEmUL@mail.gmail.com>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
	<AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
	<AANLkTinH+aDc7ppwnUkYPw0O4yxLq15Wmw2drJzCEmUL@mail.gmail.com>
Message-ID: <AANLkTinZwmHSeisafFtnoiw-Szs-nKOZFy+y_9UMkvVO@mail.gmail.com>

I posted some changes that should be mostly backward compatible. The
changes give much more control over the flow of commands. It is
already used in the halo-view and the security-browser. Let me know
what you think.

Name: Pier-Model-lr.398
Author: lr
Time: 25 October 2010, 9:19:02 am
UUID: d92bbefb-5cfe-4323-8eff-8d39323b5aaf
Ancestors: Pier-Model-lr.397

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow

Name: Pier-Seaside-lr.497
Author: lr
Time: 25 October 2010, 9:19:07 am
UUID: f04066ae-fabc-4a66-863b-0adaf5980374
Ancestors: Pier-Seaside-lr.496

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow

Name: Pier-Security-lr.172
Author: lr
Time: 25 October 2010, 9:19:12 am
UUID: 57dc8ba1-cedb-49c9-92ac-5990b30be64e
Ancestors: Pier-Security-lr.171

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow

Name: Pier-EditorEnh-lr.59
Author: lr
Time: 25 October 2010, 9:19:23 am
UUID: 1fe5b2a7-e6cb-4f48-ba76-da58e136e3f3
Ancestors: Pier-EditorEnh-lr.57

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow


Name: Pier-Tests-Model-lr.16
Author: lr
Time: 25 October 2010, 9:19:15 am
UUID: 76a4502d-c534-445f-b4cc-49396a4fabc4
Ancestors: Pier-Tests-Model-lr.15

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow

Name: Pier-Security-lr.172
Author: lr
Time: 25 October 2010, 9:19:12 am
UUID: 57dc8ba1-cedb-49c9-92ac-5990b30be64e
Ancestors: Pier-Security-lr.171

- replaced PRCommand>>#answer: with #successAnswer: and #cancelAnswer:
to give more control over the flow
On 25 October 2010 08:28, Lukas Renggli <renggli at gmail.com> wrote:
> Norbert,
>
> While what Nick proposes is a nice workaround, I think it would be
> useful to let the command decide on the cancel continuation. However
> the logic for that should go into the Model, not the View. Also we
> have to pay attention not to use #ifNil:ifNotNil: and friends, because
> that doesn't work across all supported platforms. Norbert, can you
> provide a change?
>
> Lukas
>
> On 22 October 2010 19:01, Nick Ager <nick.ager at gmail.com> wrote:
>> Hi Norbert,
>> I think I might have solved a similar problem in a different way. ?I created
>> a "clean" environment specifically for non-view commands.
>> Then I derived from PRPierFrame and implemented:
>> environment
>> ^ self context command useEditingEnvironment ifTrue: [
>> self kernel editingEnvironment
>> ] ifFalse: [
>> self context structure environment
>> ]
>> Then:
>> PRCommand>>useEditingEnvironment
>> ^ (self isView or: [self isQuick])?not
>>
>> ---
>> Other ways round would be to create your own PRContents widget or return a
>> command with the structure you want to display, instead of returning nil
>> ---
>> I only mention the above work-arounds as I don't have enough knowledge to
>> say for certain that your changes wouldn't cause unintended side-effects..
>>
>> Hope this helps
>> Nick
>>
>>
>>
>>
>> On 22 October 2010 12:57, Norbert Hartl <norbert at hartl.name> wrote:
>>>
>>> I like to execute a command in a way that the structure is changed while
>>> the command is being executed. If the command is commited I like to advance
>>> the structure to another structure. If the command is aborted than I like to
>>> return to the structure from where the command has been invoked.
>>>
>>> Basically I do something like this
>>>
>>> ? ? ? ?html anchor
>>> ? ? ? ? ? ? ? ?goto: (self context
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?structure: self
>>> structureWhileCommandIsExecuting
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?command: MyPierCommand new);
>>> ? ? ? ? ? ? ? ?with: 'do it' ]
>>>
>>> In MyPierCommand>>doExecute I do at the end
>>>
>>> self answer: (self context structure: self
>>> structureAfterCommandHasBeingCommited )
>>>
>>> This way I have chose a structure for command execution and the structure
>>> if the command is commited. But on abort it stays where it has been executed
>>> (structureWhileCommandIsExecuting). Looking at
>>>
>>> PRContentsWidget>>onAnswerCommand: aCommand
>>> ? ? ? ?aCommand isNil
>>> ? ? ? ? ? ? ? ?ifTrue: [ ^ self context: (self context structure: self
>>> context structure) ].
>>> ? ? ? ?[ aCommand execute ]
>>> ? ? ? ? ? ? ? ?on: MAError
>>> ? ? ? ? ? ? ? ?do: [ :err | ^ self component errors add: err ].
>>> ? ? ? ?self context: aCommand answer
>>>
>>> we see that if aCommand isNil (abort) the structure is nailed to the
>>> current one (while executing). Would it be ok to change that so it is
>>> answering every time? I simple change would be to change
>>>
>>> buildComponent: aContext
>>> ? ? ? ?^ aContext command asComponent
>>> ? ? ? ? ? ? ? ?onAnswer: [ :value | self onAnswerCommand: value ];
>>> ? ? ? ? ? ? ? ?yourself
>>>
>>> to
>>>
>>> buildComponent: aContext
>>> ? ? ? ?^ aContext command asComponent
>>> ? ? ? ? ? ? ? ?onAnswer: [ :value | value ifNotNil: [ self
>>> onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ];
>>> ? ? ? ? ? ? ? ?yourself
>>>
>>> this way
>>>
>>> PRCommand>>doAnswer
>>> ? ? ? ?self answer ifNil: [ self answer: (self context structure: self
>>> structure) ]
>>>
>>> would the same but some could overwrite the answer when creating the link
>>>
>>> what do you think?
>>>
>>> Norbert
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From norbert at hartl.name  Mon Oct 25 10:04:00 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 25 Oct 2010 10:04:00 +0200
Subject: parameter and accessor
In-Reply-To: <AANLkTimCrJ6Y3WMRERKLiZBrzSOM6E5TRETNkAnYnFfd@mail.gmail.com>
References: <B51D7FA6-BA46-4F41-AEA7-B777171989CD@hartl.name>
	<AANLkTimCrJ6Y3WMRERKLiZBrzSOM6E5TRETNkAnYnFfd@mail.gmail.com>
Message-ID: <8D601EDC-54E7-4745-9305-9A2B8C4AF56B@hartl.name>


On 25.10.2010, at 08:30, Lukas Renggli wrote:

>> Do I misunderstand something or is there a preferred way of accessing parameter values?
> 
> Magritte uses the accessor also to establish the identity between
> different descriptions, that's why you should always specify an
> accessor even if you don't use it.
> 
Ok. But what about using the accesor to store the parameter value into the object?

Norbert



From norbert at hartl.name  Mon Oct 25 10:22:18 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 25 Oct 2010 10:22:18 +0200
Subject: onAnswerCommand and structure change
In-Reply-To: <AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
	<AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
Message-ID: <D9805101-2721-43C8-836E-68C936A0B38D@hartl.name>

Nick,

thanks for your answer. Comments inline!

On 22.10.2010, at 19:01, Nick Ager wrote:

> Hi Norbert,
> 
> I think I might have solved a similar problem in a different way.  I created a "clean" environment specifically for non-view commands.
> 
> Then I derived from PRPierFrame and implemented:
> 
> environment
> 	^ self context command useEditingEnvironment ifTrue: [
> 		self kernel editingEnvironment
> 	] ifFalse: [
> 		self context structure environment
> 	]
> 
> Then:
> 
> PRCommand>>useEditingEnvironment
> 	^ (self isView or: [self isQuick]) not
> 
> 
> ---
> 
> Other ways round would be to create your own PRContents widget or return a command with the structure you want to display, instead of returning nil
> 
> ---
> 
> I only mention the above work-arounds as I don't have enough knowledge to say for certain that your changes wouldn't cause unintended side-effects..
> 
I think what you did is quite nice but for a different use case :) What I'm actually after is to have complete control over the visual transition while a command is being executed. A command is being valid on a certain page and is active if permissions are sufficient. So you have a starting structure. While executing the command every command not being a quick command displays a component. The transitional component is embedded in an environement as well. You solved this with a default environment. But you seem to use this for every command execution. And that is difference. I need different environments while executing commans. That is easy to achieve because you can specify the target structure along with the command which looks natural to me. 
If I see it correctly than you don't leave the structure while editing, right? You change the environment to display different stuff. On cancel time the old environment is restored and while you didn't leave the structure you are back there, right? That is a nice and pragmatic approach to it.
I think it is an advantage to specify a command starting from one structure A, while being executed being embedded in a structure B. On commit/save time it will end on structure C. If the action was abort/cancel instead it would land on structure D. This way it is clearer what will happen. I'm playing with chaining commands and this way you could specify it more like a state machine if things get complex.

Norbert



> 
> 
> On 22 October 2010 12:57, Norbert Hartl <norbert at hartl.name> wrote:
> I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked.
> 
> Basically I do something like this
> 
>        html anchor
>                goto: (self context
>                                structure: self structureWhileCommandIsExecuting
>                                command: MyPierCommand new);
>                with: 'do it' ]
> 
> In MyPierCommand>>doExecute I do at the end
> 
> self answer: (self context structure: self structureAfterCommandHasBeingCommited )
> 
> This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at
> 
> PRContentsWidget>>onAnswerCommand: aCommand
>        aCommand isNil
>                ifTrue: [ ^ self context: (self context structure: self context structure) ].
>        [ aCommand execute ]
>                on: MAError
>                do: [ :err | ^ self component errors add: err ].
>        self context: aCommand answer
> 
> we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change
> 
> buildComponent: aContext
>        ^ aContext command asComponent
>                onAnswer: [ :value | self onAnswerCommand: value ];
>                yourself
> 
> to
> 
> buildComponent: aContext
>        ^ aContext command asComponent
>                onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ];
>                yourself
> 
> this way
> 
> PRCommand>>doAnswer
>        self answer ifNil: [ self answer: (self context structure: self structure) ]
> 
> would the same but some could overwrite the answer when creating the link
> 
> what do you think?
> 
> Norbert
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101025/a45bf143/attachment-0001.html>

From nick.ager at gmail.com  Mon Oct 25 11:18:59 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 25 Oct 2010 10:18:59 +0100
Subject: onAnswerCommand and structure change
In-Reply-To: <D9805101-2721-43C8-836E-68C936A0B38D@hartl.name>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
	<AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
	<D9805101-2721-43C8-836E-68C936A0B38D@hartl.name>
Message-ID: <AANLkTikjPTb+1cuMqtGDcHY0ajmfQBJ_DXqbzOQZES5j@mail.gmail.com>

Hi Norbert,

I think what you did is quite nice but for a different use case :)
>

Yes now I understand your use case I realise mine is completely different.
It's more about creating a simple environment for edit  commands (and
others) when my page environments contain a lot of template components; the
content area is small relative to the environment.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101025/5703e416/attachment.html>

From norbert at hartl.name  Wed Oct 27 16:58:19 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Wed, 27 Oct 2010 16:58:19 +0200
Subject: Bug: URL not updated on quick command
Message-ID: <56F64867-F681-4C41-9282-3890A66B2FD1@hartl.name>

I have a command that is a quick command and on execute time I do something like

thisStructure := self context structure.
parentStructure := thisStructure parent.
self answer: (self context structure: parentStructure)

The context then contains the right structure (parentStructure) but the url line in the browser still tells the url of thisStructure. The only thing I could confirm is that this doen't happen if isQuick is false. Then the url is updated correctly.

Any ideas?

Norbert



From norbert at hartl.name  Wed Oct 27 23:25:42 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Wed, 27 Oct 2010 23:25:42 +0200
Subject: MAContainerComponent and updateRoot:
Message-ID: <857BB58D-1882-4740-B7F8-2E8B130AF5CF@hartl.name>

I have a magritte component clas that uses some javascript stuff. But I couldn't get it to run. It seems that magritte components don't get the chance to. I think that MAContainerComponent is supposed to give its children the chance to update the root as well.

The attached changeset adds it to MAContainerComponent.

What do you think?

Norbert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MAContainerComponent-updateRoot.1.cs
Type: application/octet-stream
Size: 850 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20101027/c6a678ba/attachment.obj>

From norbert at hartl.name  Wed Oct 27 23:32:41 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Wed, 27 Oct 2010 23:32:41 +0200
Subject: MAContainerComponent and updateRoot:
In-Reply-To: <857BB58D-1882-4740-B7F8-2E8B130AF5CF@hartl.name>
References: <857BB58D-1882-4740-B7F8-2E8B130AF5CF@hartl.name>
Message-ID: <458154C6-EEA8-425A-9019-A43187EEB8D7@hartl.name>

Oops, there are a lot of words missing :) I wanted to say that the children components of a MAContainerComponent don't get the chance to do update the html root via updateRoot: . And I think MAContainerComponent as being a container for components should invoke updateRoot: on its children.

Norbert

On 27.10.2010, at 23:25, Norbert Hartl wrote:

> I have a magritte component clas that uses some javascript stuff. But I couldn't get it to run. It seems that magritte components don't get the chance to. I think that MAContainerComponent is supposed to give its children the chance to update the root as well.
> 
> The attached changeset adds it to MAContainerComponent.
> 
> What do you think?
> 
> Norbert
> 
> <MAContainerComponent-updateRoot.1.cs>_______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From renggli at gmail.com  Thu Oct 28 09:01:21 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 28 Oct 2010 09:01:21 +0200
Subject: MAContainerComponent and updateRoot:
In-Reply-To: <458154C6-EEA8-425A-9019-A43187EEB8D7@hartl.name>
References: <857BB58D-1882-4740-B7F8-2E8B130AF5CF@hartl.name>
	<458154C6-EEA8-425A-9019-A43187EEB8D7@hartl.name>
Message-ID: <AANLkTin7GgvjFKsaWYUkUs=zXCL86figxmMGsvL_ZGbt@mail.gmail.com>

I cannot reproduce the problem. Seaside automatically calls
#updateRoot: on all children. With your changeset #updateRoot: is
called twice on the children of MAContainerComponent.

Lukas

On 27 October 2010 23:32, Norbert Hartl <norbert at hartl.name> wrote:
> Oops, there are a lot of words missing :) I wanted to say that the children components of a MAContainerComponent don't get the chance to do update the html root via updateRoot: . And I think MAContainerComponent as being a container for components should invoke updateRoot: on its children.
>
> Norbert
>
> On 27.10.2010, at 23:25, Norbert Hartl wrote:
>
>> I have a magritte component clas that uses some javascript stuff. But I couldn't get it to run. It seems that magritte components don't get the chance to. I think that MAContainerComponent is supposed to give its children the chance to update the root as well.
>>
>> The attached changeset adds it to MAContainerComponent.
>>
>> What do you think?
>>
>> Norbert
>>
>> <MAContainerComponent-updateRoot.1.cs>_______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Lukas Renggli
www.lukas-renggli.ch


From renggli at gmail.com  Thu Oct 28 09:22:46 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 28 Oct 2010 09:22:46 +0200
Subject: Bug: URL not updated on quick command
In-Reply-To: <56F64867-F681-4C41-9282-3890A66B2FD1@hartl.name>
References: <56F64867-F681-4C41-9282-3890A66B2FD1@hartl.name>
Message-ID: <AANLkTikQtUxoAz0fbovtVrFHU+vbUPwew0iuZiHTKFjE@mail.gmail.com>

On 27 October 2010 16:58, Norbert Hartl <norbert at hartl.name> wrote:
> I have a command that is a quick command and on execute time I do something like
>
> thisStructure := self context structure.
> parentStructure := thisStructure parent.
> self answer: (self context structure: parentStructure)

First of all: Commands are supposed to change something in the model,
they are supposed to be persistent and recorded in the history. Pure
navigation should be done with (value-)links.

> The context then contains the right structure (parentStructure) but the url line in the browser still tells the url of thisStructure. The only thing I could confirm is that this doen't happen if isQuick is false. Then the url is updated correctly.

The URL of a command is RESTful and points to where the command is
supposed to be executed. For quick commands that do not show an UI a
redirect would be necessary to update the URL after execution.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From norbert at hartl.name  Thu Oct 28 09:35:44 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 28 Oct 2010 09:35:44 +0200
Subject: Bug: URL not updated on quick command
In-Reply-To: <AANLkTikQtUxoAz0fbovtVrFHU+vbUPwew0iuZiHTKFjE@mail.gmail.com>
References: <56F64867-F681-4C41-9282-3890A66B2FD1@hartl.name>
	<AANLkTikQtUxoAz0fbovtVrFHU+vbUPwew0iuZiHTKFjE@mail.gmail.com>
Message-ID: <AEDB7266-B116-4FA6-9257-119E8FBB1B61@hartl.name>


On 28.10.2010, at 09:22, Lukas Renggli wrote:

> On 27 October 2010 16:58, Norbert Hartl <norbert at hartl.name> wrote:
>> I have a command that is a quick command and on execute time I do something like
>> 
>> thisStructure := self context structure.
>> parentStructure := thisStructure parent.
>> self answer: (self context structure: parentStructure)
> 
> First of all: Commands are supposed to change something in the model,
> they are supposed to be persistent and recorded in the history. Pure
> navigation should be done with (value-)links.
> 

Yes, that is right. In my case I'm on a child page and the command is a remove command. The model and page are deleted and then I want to return to the parent page. 

>> The context then contains the right structure (parentStructure) but the url line in the browser still tells the url of thisStructure. The only thing I could confirm is that this doen't happen if isQuick is false. Then the url is updated correctly.
> 
> The URL of a command is RESTful and points to where the command is
> supposed to be executed. For quick commands that do not show an UI a
> redirect would be necessary to update the URL after execution.
> 
What is the best place to do a redirect? I think in execute it might be to early. 

Norbert



From renggli at gmail.com  Thu Oct 28 09:38:38 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 28 Oct 2010 09:38:38 +0200
Subject: Bug: URL not updated on quick command
In-Reply-To: <AEDB7266-B116-4FA6-9257-119E8FBB1B61@hartl.name>
References: <56F64867-F681-4C41-9282-3890A66B2FD1@hartl.name>
	<AANLkTikQtUxoAz0fbovtVrFHU+vbUPwew0iuZiHTKFjE@mail.gmail.com>
	<AEDB7266-B116-4FA6-9257-119E8FBB1B61@hartl.name>
Message-ID: <AANLkTikp7t3govG2j_dqfU2uM8Sdv5gLn06jOagoXqg7@mail.gmail.com>

>>> The context then contains the right structure (parentStructure) but the url line in the browser still tells the url of thisStructure. The only thing I could confirm is that this doen't happen if isQuick is false. Then the url is updated correctly.
>>
>> The URL of a command is RESTful and points to where the command is
>> supposed to be executed. For quick commands that do not show an UI a
>> redirect would be necessary to update the URL after execution.
>>
> What is the best place to do a redirect? I think in execute it might be to early.

#execute is in the model, so that's definitely the wrong place to do
something Seaside related.

I guess the right place would be in
PRContentsWidget>>#onAnswerContext:command:, but I am not entirely
sure of how to do that.

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch

From norbert at hartl.name  Thu Oct 28 11:09:33 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 28 Oct 2010 11:09:33 +0200
Subject: MAContainerComponent and updateRoot:
In-Reply-To: <AANLkTin7GgvjFKsaWYUkUs=zXCL86figxmMGsvL_ZGbt@mail.gmail.com>
References: <857BB58D-1882-4740-B7F8-2E8B130AF5CF@hartl.name>
	<458154C6-EEA8-425A-9019-A43187EEB8D7@hartl.name>
	<AANLkTin7GgvjFKsaWYUkUs=zXCL86figxmMGsvL_ZGbt@mail.gmail.com>
Message-ID: <E81F6478-0EB4-4C61-AC7B-0E643728D052@hartl.name>

I'm sorry. I tested it only with one of my components. I don't know exactly why it happens but I'm quite sure the error  is on my side.

thanks,

Norbert

On 28.10.2010, at 09:01, Lukas Renggli wrote:

> I cannot reproduce the problem. Seaside automatically calls
> #updateRoot: on all children. With your changeset #updateRoot: is
> called twice on the children of MAContainerComponent.
> 
> Lukas
> 
> On 27 October 2010 23:32, Norbert Hartl <norbert at hartl.name> wrote:
>> Oops, there are a lot of words missing :) I wanted to say that the children components of a MAContainerComponent don't get the chance to do update the html root via updateRoot: . And I think MAContainerComponent as being a container for components should invoke updateRoot: on its children.
>> 
>> Norbert
>> 
>> On 27.10.2010, at 23:25, Norbert Hartl wrote:
>> 
>>> I have a magritte component clas that uses some javascript stuff. But I couldn't get it to run. It seems that magritte components don't get the chance to. I think that MAContainerComponent is supposed to give its children the chance to update the root as well.
>>> 
>>> The attached changeset adds it to MAContainerComponent.
>>> 
>>> What do you think?
>>> 
>>> Norbert
>>> 
>>> <MAContainerComponent-updateRoot.1.cs>_______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From norbert at hartl.name  Thu Oct 28 11:21:19 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 28 Oct 2010 11:21:19 +0200
Subject: onAnswerCommand and structure change
In-Reply-To: <AANLkTinZwmHSeisafFtnoiw-Szs-nKOZFy+y_9UMkvVO@mail.gmail.com>
References: <347A6F04-B649-41C6-8FD8-46B1707F2307@hartl.name>
	<AANLkTik1EVW=TWGySefUe8j0FTO43w_=FYhZsuZk47-7@mail.gmail.com>
	<AANLkTinH+aDc7ppwnUkYPw0O4yxLq15Wmw2drJzCEmUL@mail.gmail.com>
	<AANLkTinZwmHSeisafFtnoiw-Szs-nKOZFy+y_9UMkvVO@mail.gmail.com>
Message-ID: <A829996A-6AE3-45E0-B001-7CBFACFE97DB@hartl.name>


On 25.10.2010, at 09:21, Lukas Renggli wrote:

> I posted some changes that should be mostly backward compatible. The
> changes give much more control over the flow of commands. It is
> already used in the halo-view and the security-browser. Let me know
> what you think.

I didn't use it in code already but the change looks good to me. But why did you call it success? I'm not that lucky that there is a new word in the mix. To me the cancel operation is of stable meaning. It seems to be cancel everywhere. On the other hand there is save and commit. And now there is even success. Even though it is not nice to call it saveAnswer I think it would be the better name for it.

Norbert