From philippe.marschall at gmail.com  Tue Dec 12 18:23:13 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Tue, 12 Dec 2006 18:23:13 +0100
Subject: [ANN] Audioscrobbler Plugin for Pier
Message-ID: <66666f210612120923s2ed15f62sd87b628b4d94250b@mail.gmail.com>

Hi

There is now an audioscrobbler[1] plugin for Pier at [2]. Margitte is
used for XML data binding. It makes use of traits so you will need a
Squeak 3.9. And the YAXO XML parser.

Currently supported are:
    * Top Artists
    * Top Albums
    * Top Tracks
    * Top Tags
    * Recent Tracks
    * Recent Banned Tracks
    * Recent Loved Tracks
    * Weekly Artist Chart
    * Weekly Album Chart
    * Weekly Track Chart

The Audioscrobbler system is a database that tracks listening habits
and calculates relationships and recommendations based on the music
people listen to.

A screenshot can be found at:
http://img79.imageshack.us/img79/7537/audioscrobblervp6.png

[1] http://www.audioscrobbler.net/
[2] http://mc.lukas-renggli.ch/audioscrobbler/

Cheers
Philippe

From avanos at xs4all.nl  Tue Dec 12 20:26:05 2006
From: avanos at xs4all.nl (Adriaan van Os)
Date: Tue, 12 Dec 2006 20:26:05 +0100 (CET)
Subject: [ANN] Audioscrobbler Plugin for Pier
In-Reply-To: <66666f210612120923s2ed15f62sd87b628b4d94250b@mail.gmail.com>
References: <66666f210612120923s2ed15f62sd87b628b4d94250b@mail.gmail.com>
Message-ID: <17396.213.84.174.51.1165951565.squirrel@webmail.xs4all.nl>

Hi Philippe,

I like Bran Van 3000 ;-)

Adriaan.

> Hi
>
> There is now an audioscrobbler[1] plugin for Pier at [2]. Margitte is
> used for XML data binding. It makes use of traits so you will need a
> Squeak 3.9. And the YAXO XML parser.
>
> Currently supported are:
>     * Top Artists
>     * Top Albums
>     * Top Tracks
>     * Top Tags
>     * Recent Tracks
>     * Recent Banned Tracks
>     * Recent Loved Tracks
>     * Weekly Artist Chart
>     * Weekly Album Chart
>     * Weekly Track Chart
>
> The Audioscrobbler system is a database that tracks listening habits
> and calculates relationships and recommendations based on the music
> people listen to.
>
> A screenshot can be found at:
> http://img79.imageshack.us/img79/7537/audioscrobblervp6.png
>
> [1] http://www.audioscrobbler.net/
> [2] http://mc.lukas-renggli.ch/audioscrobbler/
>
> Cheers
> Philippe
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


-- 
http://vdg38bis.xs4all.nl


From philippe.marschall at gmail.com  Tue Dec 12 21:36:04 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Tue, 12 Dec 2006 21:36:04 +0100
Subject: [ANN] Audioscrobbler Plugin for Pier
In-Reply-To: <17396.213.84.174.51.1165951565.squirrel@webmail.xs4all.nl>
References: <66666f210612120923s2ed15f62sd87b628b4d94250b@mail.gmail.com>
	<17396.213.84.174.51.1165951565.squirrel@webmail.xs4all.nl>
Message-ID: <66666f210612121236h5499b9eap32534d11612b6b87@mail.gmail.com>

2006/12/12, Adriaan van Os <avanos at xs4all.nl>:
> Hi Philippe,
>
> I like Bran Van 3000 ;-)

It's not my profile, I have no idea who Bran Van 3000 is but that can
be corrected easily ;-)

Philippe

> Adriaan.
>
> > Hi
> >
> > There is now an audioscrobbler[1] plugin for Pier at [2]. Margitte is
> > used for XML data binding. It makes use of traits so you will need a
> > Squeak 3.9. And the YAXO XML parser.
> >
> > Currently supported are:
> >     * Top Artists
> >     * Top Albums
> >     * Top Tracks
> >     * Top Tags
> >     * Recent Tracks
> >     * Recent Banned Tracks
> >     * Recent Loved Tracks
> >     * Weekly Artist Chart
> >     * Weekly Album Chart
> >     * Weekly Track Chart
> >
> > The Audioscrobbler system is a database that tracks listening habits
> > and calculates relationships and recommendations based on the music
> > people listen to.
> >
> > A screenshot can be found at:
> > http://img79.imageshack.us/img79/7537/audioscrobblervp6.png
> >
> > [1] http://www.audioscrobbler.net/
> > [2] http://mc.lukas-renggli.ch/audioscrobbler/
> >
> > Cheers
> > Philippe
> >
> > _______________________________________________
> > SmallWiki, Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
>
>
> --
> http://vdg38bis.xs4all.nl
>
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

From norbert at hartl.name  Wed Dec 13 18:05:52 2006
From: norbert at hartl.name (Norbert Hartl)
Date: Wed, 13 Dec 2006 18:05:52 +0100
Subject: HTML Attributes with custom renderers
Message-ID: <1166029552.9805.33.camel@localhost>

Hi,

I'm playing with custom views in Magritte. I have a model 
and overwrote descriptionContainer with my own instance of
MAComponentRenderer.

What I'm trying to achieve is to display a text input the 
following:

<label for="anyid">labeltext</label>
<input type="text" id="anyid"..../>

As a quick test I changed the renderLabel: to

renderLabel: aDescription
   aDescription hasLabel
      ifTrue: [ html 
         label attributeAt: 'for' put: aDescription hash;
         with: [ html render: aDescription label ] ]

I need an id attribute in the <input> tag which has the
same content as the for attribute in the <label> tag. 
I don't have a glue how to insert an id attribute to the
renderControl:. Is there a way to add an attribute if I only 
have a component. I doubt the component description is the 
right place to put.

If I only want to change the behaviour of the text input field,
is it best to overwrite the visitStringDescription?

thanks in advance,

Norbert


From philippe.marschall at gmail.com  Wed Dec 13 18:40:39 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Wed, 13 Dec 2006 18:40:39 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <1166029552.9805.33.camel@localhost>
References: <1166029552.9805.33.camel@localhost>
Message-ID: <66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>

2006/12/13, Norbert Hartl <norbert at hartl.name>:
> Hi,
>
> I'm playing with custom views in Magritte. I have a model
> and overwrote descriptionContainer with my own instance of
> MAComponentRenderer.
>
> What I'm trying to achieve is to display a text input the
> following:
>
> <label for="anyid">labeltext</label>
> <input type="text" id="anyid"..../>
>
> As a quick test I changed the renderLabel: to
>
> renderLabel: aDescription
>    aDescription hasLabel
>       ifTrue: [ html
>          label attributeAt: 'for' put: aDescription hash;
>          with: [ html render: aDescription label ] ]
>
> I need an id attribute in the <input> tag which has the
> same content as the for attribute in the <label> tag.
> I don't have a glue how to insert an id attribute to the
> renderControl:. Is there a way to add an attribute if I only
> have a component. I doubt the component description is the
> right place to put.
>
> If I only want to change the behaviour of the text input field,
> is it best to overwrite the visitStringDescription?
>
> thanks in advance,

This is something that crossed my mind too. To get an id you can use
something like this:
(component childAt: aDescription) ajaxId

Now for the rendering of input tags. I see no way other than changing
or subclassing all the renderer classes.
MAMultiselectListComponent
MASelectListComponent
MATextInputComponent
MATextAreaComponent
MARadioGroupComponent
MARangeComponent
MATextPasswordComponent
MAFileUploadComponent
and whatever I forgot

Honestly I think changing is better because I think it makes sense to
have this as default behavior.

Cheers
Philippe

From renggli at iam.unibe.ch  Wed Dec 13 18:49:35 2006
From: renggli at iam.unibe.ch (Lukas Renggli)
Date: Wed, 13 Dec 2006 18:49:35 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
Message-ID: <A4F02797-64D3-49ED-9934-DD61EF5B5933@iam.unibe.ch>

> Honestly I think changing is better because I think it makes sense to
> have this as default behavior.

Yes please, go ahead ;-)

Lukas

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



From norbert at hartl.name  Fri Dec 15 16:32:17 2006
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Dec 2006 16:32:17 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
Message-ID: <1166196737.9249.6.camel@localhost>

On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > Hi,
> >
> > I'm playing with custom views in Magritte. I have a model
> > and overwrote descriptionContainer with my own instance of
> > MAComponentRenderer.
> >
> > What I'm trying to achieve is to display a text input the
> > following:
> >
> > <label for="anyid">labeltext</label>
> > <input type="text" id="anyid"..../>
> >
> > As a quick test I changed the renderLabel: to
> >
> > renderLabel: aDescription
> >    aDescription hasLabel
> >       ifTrue: [ html
> >          label attributeAt: 'for' put: aDescription hash;
> >          with: [ html render: aDescription label ] ]
> >
> > I need an id attribute in the <input> tag which has the
> > same content as the for attribute in the <label> tag.
> > I don't have a glue how to insert an id attribute to the
> > renderControl:. Is there a way to add an attribute if I only
> > have a component. I doubt the component description is the
> > right place to put.
> >
> > If I only want to change the behaviour of the text input field,
> > is it best to overwrite the visitStringDescription?
> >
> > thanks in advance,
> 
> This is something that crossed my mind too. To get an id you can use
> something like this:
> (component childAt: aDescription) ajaxId
> 
> Now for the rendering of input tags. I see no way other than changing
> or subclassing all the renderer classes.
> MAMultiselectListComponent
> MASelectListComponent
> MATextInputComponent
> MATextAreaComponent
> MARadioGroupComponent
> MARangeComponent
> MATextPasswordComponent
> MAFileUploadComponent
> and whatever I forgot
> 
> Honestly I think changing is better because I think it makes sense to
> have this as default behavior.
> 
I'm not sure what to change. The only way I see is to have writable
attributes in MAComponent. While the attributes in the MADescription
are class side attributes they could initialize the object attributes
of a MAComponent when the component is created. Okay I'm not that of 
an experienced smalltalker but it doesn't sound very good to me, too :)

What do you think?

Norbert





From norbert at hartl.name  Fri Dec 15 17:12:54 2006
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Dec 2006 17:12:54 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
Message-ID: <1166199174.9249.13.camel@localhost>

On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > Hi,
> >
> > I'm playing with custom views in Magritte. I have a model
> > and overwrote descriptionContainer with my own instance of
> > MAComponentRenderer.
> >
> > What I'm trying to achieve is to display a text input the
> > following:
> >
> > <label for="anyid">labeltext</label>
> > <input type="text" id="anyid"..../>
> >
> > As a quick test I changed the renderLabel: to
> >
> > renderLabel: aDescription
> >    aDescription hasLabel
> >       ifTrue: [ html
> >          label attributeAt: 'for' put: aDescription hash;
> >          with: [ html render: aDescription label ] ]
> >
> > I need an id attribute in the <input> tag which has the
> > same content as the for attribute in the <label> tag.
> > I don't have a glue how to insert an id attribute to the
> > renderControl:. Is there a way to add an attribute if I only
> > have a component. I doubt the component description is the
> > right place to put.
> >
> > If I only want to change the behaviour of the text input field,
> > is it best to overwrite the visitStringDescription?
> >
> > thanks in advance,
> 
> This is something that crossed my mind too. To get an id you can use
> something like this:
> (component childAt: aDescription) ajaxId
> 
> Now for the rendering of input tags. I see no way other than changing
> or subclassing all the renderer classes.
> MAMultiselectListComponent
> MASelectListComponent
> MATextInputComponent
> MATextAreaComponent
> MARadioGroupComponent
> MARangeComponent
> MATextPasswordComponent
> MAFileUploadComponent
> and whatever I forgot
> 
> Honestly I think changing is better because I think it makes sense to
> have this as default behavior.
> 
Ok, I changed it for me unless there is a better solution.
(I myself need some more time to get in touch with Magritte)
I did:

MAElementComponent>>attributes
   attributes ifNil: [
      attributes := self description attributes copy.
      ].
   ^ attributes

MAElementComponent>>attributesAt: aKey put: aValue
   self attributes at: aKey put: aValue

I don't know if it is an error if the component is not aware
about changes in the description attributes.

regards, 

Norbert


From philippe.marschall at gmail.com  Fri Dec 15 17:40:21 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Fri, 15 Dec 2006 17:40:21 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <1166196737.9249.6.camel@localhost>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
	<1166196737.9249.6.camel@localhost>
Message-ID: <66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>

2006/12/15, Norbert Hartl <norbert at hartl.name>:
> On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> > 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > > Hi,
> > >
> > > I'm playing with custom views in Magritte. I have a model
> > > and overwrote descriptionContainer with my own instance of
> > > MAComponentRenderer.
> > >
> > > What I'm trying to achieve is to display a text input the
> > > following:
> > >
> > > <label for="anyid">labeltext</label>
> > > <input type="text" id="anyid"..../>
> > >
> > > As a quick test I changed the renderLabel: to
> > >
> > > renderLabel: aDescription
> > >    aDescription hasLabel
> > >       ifTrue: [ html
> > >          label attributeAt: 'for' put: aDescription hash;
> > >          with: [ html render: aDescription label ] ]
> > >
> > > I need an id attribute in the <input> tag which has the
> > > same content as the for attribute in the <label> tag.
> > > I don't have a glue how to insert an id attribute to the
> > > renderControl:. Is there a way to add an attribute if I only
> > > have a component. I doubt the component description is the
> > > right place to put.
> > >
> > > If I only want to change the behaviour of the text input field,
> > > is it best to overwrite the visitStringDescription?
> > >
> > > thanks in advance,
> >
> > This is something that crossed my mind too. To get an id you can use
> > something like this:
> > (component childAt: aDescription) ajaxId
> >
> > Now for the rendering of input tags. I see no way other than changing
> > or subclassing all the renderer classes.
> > MAMultiselectListComponent
> > MASelectListComponent
> > MATextInputComponent
> > MATextAreaComponent
> > MARadioGroupComponent
> > MARangeComponent
> > MATextPasswordComponent
> > MAFileUploadComponent
> > and whatever I forgot
> >
> > Honestly I think changing is better because I think it makes sense to
> > have this as default behavior.
> >
> I'm not sure what to change. The only way I see is to have writable
> attributes in MAComponent. While the attributes in the MADescription
> are class side attributes they could initialize the object attributes
> of a MAComponent when the component is created. Okay I'm not that of
> an experienced smalltalker but it doesn't sound very good to me, too :)
>
> What do you think?

Have a look at: Magritte-Seaside-pmm.206.
It implements it for some elements. It needs a bit of cleanup, it is
not complete and has some rough edges.

Philippe

From norbert at hartl.name  Fri Dec 15 18:08:54 2006
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 15 Dec 2006 18:08:54 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
	<1166196737.9249.6.camel@localhost>
	<66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>
Message-ID: <1166202534.9249.24.camel@localhost>

On Fri, 2006-12-15 at 17:40 +0100, Philippe Marschall wrote:
> 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> > > 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > > > Hi,
> > > >
> > > > I'm playing with custom views in Magritte. I have a model
> > > > and overwrote descriptionContainer with my own instance of
> > > > MAComponentRenderer.
> > > >
> > > > What I'm trying to achieve is to display a text input the
> > > > following:
> > > >
> > > > <label for="anyid">labeltext</label>
> > > > <input type="text" id="anyid"..../>
> > > >
> > > > As a quick test I changed the renderLabel: to
> > > >
> > > > renderLabel: aDescription
> > > >    aDescription hasLabel
> > > >       ifTrue: [ html
> > > >          label attributeAt: 'for' put: aDescription hash;
> > > >          with: [ html render: aDescription label ] ]
> > > >
> > > > I need an id attribute in the <input> tag which has the
> > > > same content as the for attribute in the <label> tag.
> > > > I don't have a glue how to insert an id attribute to the
> > > > renderControl:. Is there a way to add an attribute if I only
> > > > have a component. I doubt the component description is the
> > > > right place to put.
> > > >
> > > > If I only want to change the behaviour of the text input field,
> > > > is it best to overwrite the visitStringDescription?
> > > >
> > > > thanks in advance,
> > >
> > > This is something that crossed my mind too. To get an id you can use
> > > something like this:
> > > (component childAt: aDescription) ajaxId
> > >
> > > Now for the rendering of input tags. I see no way other than changing
> > > or subclassing all the renderer classes.
> > > MAMultiselectListComponent
> > > MASelectListComponent
> > > MATextInputComponent
> > > MATextAreaComponent
> > > MARadioGroupComponent
> > > MARangeComponent
> > > MATextPasswordComponent
> > > MAFileUploadComponent
> > > and whatever I forgot
> > >
> > > Honestly I think changing is better because I think it makes sense to
> > > have this as default behavior.
> > >
> > I'm not sure what to change. The only way I see is to have writable
> > attributes in MAComponent. While the attributes in the MADescription
> > are class side attributes they could initialize the object attributes
> > of a MAComponent when the component is created. Okay I'm not that of
> > an experienced smalltalker but it doesn't sound very good to me, too :)
> >
> > What do you think?
> 
> Have a look at: Magritte-Seaside-pmm.206.
> It implements it for some elements. It needs a bit of cleanup, it is
> not complete and has some rough edges.
> 
Hmmm, I had a quick peek at the code. I couldn't look at the changes.
I'm getting a weird error from monticello. But I guess the changes
are the labelId and the hasLabelId, right? That is a solution for the
problem of setting an id. But what to do if you like to change an other
attribute, let's say the class of an component? Is there a better 
approach for other attributes?

regards,

Norbert


From philippe.marschall at gmail.com  Sat Dec 16 10:46:26 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Sat, 16 Dec 2006 10:46:26 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <1166202534.9249.24.camel@localhost>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
	<1166196737.9249.6.camel@localhost>
	<66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>
	<1166202534.9249.24.camel@localhost>
Message-ID: <66666f210612160146n3442ece8va3c95b03fee5477a@mail.gmail.com>

2006/12/15, Norbert Hartl <norbert at hartl.name>:
> On Fri, 2006-12-15 at 17:40 +0100, Philippe Marschall wrote:
> > 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > > On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> > > > 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > > > > Hi,
> > > > >
> > > > > I'm playing with custom views in Magritte. I have a model
> > > > > and overwrote descriptionContainer with my own instance of
> > > > > MAComponentRenderer.
> > > > >
> > > > > What I'm trying to achieve is to display a text input the
> > > > > following:
> > > > >
> > > > > <label for="anyid">labeltext</label>
> > > > > <input type="text" id="anyid"..../>
> > > > >
> > > > > As a quick test I changed the renderLabel: to
> > > > >
> > > > > renderLabel: aDescription
> > > > >    aDescription hasLabel
> > > > >       ifTrue: [ html
> > > > >          label attributeAt: 'for' put: aDescription hash;
> > > > >          with: [ html render: aDescription label ] ]
> > > > >
> > > > > I need an id attribute in the <input> tag which has the
> > > > > same content as the for attribute in the <label> tag.
> > > > > I don't have a glue how to insert an id attribute to the
> > > > > renderControl:. Is there a way to add an attribute if I only
> > > > > have a component. I doubt the component description is the
> > > > > right place to put.
> > > > >
> > > > > If I only want to change the behaviour of the text input field,
> > > > > is it best to overwrite the visitStringDescription?
> > > > >
> > > > > thanks in advance,
> > > >
> > > > This is something that crossed my mind too. To get an id you can use
> > > > something like this:
> > > > (component childAt: aDescription) ajaxId
> > > >
> > > > Now for the rendering of input tags. I see no way other than changing
> > > > or subclassing all the renderer classes.
> > > > MAMultiselectListComponent
> > > > MASelectListComponent
> > > > MATextInputComponent
> > > > MATextAreaComponent
> > > > MARadioGroupComponent
> > > > MARangeComponent
> > > > MATextPasswordComponent
> > > > MAFileUploadComponent
> > > > and whatever I forgot
> > > >
> > > > Honestly I think changing is better because I think it makes sense to
> > > > have this as default behavior.
> > > >
> > > I'm not sure what to change. The only way I see is to have writable
> > > attributes in MAComponent. While the attributes in the MADescription
> > > are class side attributes they could initialize the object attributes
> > > of a MAComponent when the component is created. Okay I'm not that of
> > > an experienced smalltalker but it doesn't sound very good to me, too :)
> > >
> > > What do you think?
> >
> > Have a look at: Magritte-Seaside-pmm.206.
> > It implements it for some elements. It needs a bit of cleanup, it is
> > not complete and has some rough edges.
> >
> Hmmm, I had a quick peek at the code. I couldn't look at the changes.
> I'm getting a weird error from monticello. But I guess the changes
> are the labelId and the hasLabelId, right?

Not directly more the changes in MA*Component.

> That is a solution for the
> problem of setting an id. But what to do if you like to change an other
> attribute, let's say the class of an component? Is there a better
> approach for other attributes?

Actually yes. You can set #attributes of to an description to an
instance of WAHtmlAttributes. I don't see a need to do this for
classes since the existing markup is so fine grained you should be
able to select anything you want.

Cheers
Philippe

From norbert at hartl.name  Mon Dec 18 17:14:25 2006
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 18 Dec 2006 17:14:25 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <66666f210612160146n3442ece8va3c95b03fee5477a@mail.gmail.com>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
	<1166196737.9249.6.camel@localhost>
	<66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>
	<1166202534.9249.24.camel@localhost>
	<66666f210612160146n3442ece8va3c95b03fee5477a@mail.gmail.com>
Message-ID: <1166458465.20462.6.camel@localhost>

On Sat, 2006-12-16 at 10:46 +0100, Philippe Marschall wrote:
> 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > On Fri, 2006-12-15 at 17:40 +0100, Philippe Marschall wrote:
> > > 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > > > On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> > > > > 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > > > > > Hi,
> > > > > >
> > > > > > I'm playing with custom views in Magritte. I have a model
> > > > > > and overwrote descriptionContainer with my own instance of
> > > > > > MAComponentRenderer.
> > > > > >
> > > > > > What I'm trying to achieve is to display a text input the
> > > > > > following:
> > > > > >
> > > > > > <label for="anyid">labeltext</label>
> > > > > > <input type="text" id="anyid"..../>
> > > > > >
> > > > > > As a quick test I changed the renderLabel: to
> > > > > >
> > > > > > renderLabel: aDescription
> > > > > >    aDescription hasLabel
> > > > > >       ifTrue: [ html
> > > > > >          label attributeAt: 'for' put: aDescription hash;
> > > > > >          with: [ html render: aDescription label ] ]
> > > > > >
> > > > > > I need an id attribute in the <input> tag which has the
> > > > > > same content as the for attribute in the <label> tag.
> > > > > > I don't have a glue how to insert an id attribute to the
> > > > > > renderControl:. Is there a way to add an attribute if I only
> > > > > > have a component. I doubt the component description is the
> > > > > > right place to put.
> > > > > >
> > > > > > If I only want to change the behaviour of the text input field,
> > > > > > is it best to overwrite the visitStringDescription?
> > > > > >
> > > > > > thanks in advance,
> > > > >
> > > > > This is something that crossed my mind too. To get an id you can use
> > > > > something like this:
> > > > > (component childAt: aDescription) ajaxId
> > > > >
> > > > > Now for the rendering of input tags. I see no way other than changing
> > > > > or subclassing all the renderer classes.
> > > > > MAMultiselectListComponent
> > > > > MASelectListComponent
> > > > > MATextInputComponent
> > > > > MATextAreaComponent
> > > > > MARadioGroupComponent
> > > > > MARangeComponent
> > > > > MATextPasswordComponent
> > > > > MAFileUploadComponent
> > > > > and whatever I forgot
> > > > >
> > > > > Honestly I think changing is better because I think it makes sense to
> > > > > have this as default behavior.
> > > > >
> > > > I'm not sure what to change. The only way I see is to have writable
> > > > attributes in MAComponent. While the attributes in the MADescription
> > > > are class side attributes they could initialize the object attributes
> > > > of a MAComponent when the component is created. Okay I'm not that of
> > > > an experienced smalltalker but it doesn't sound very good to me, too :)
> > > >
> > > > What do you think?
> > >
> > > Have a look at: Magritte-Seaside-pmm.206.
> > > It implements it for some elements. It needs a bit of cleanup, it is
> > > not complete and has some rough edges.
> > >
> > Hmmm, I had a quick peek at the code. I couldn't look at the changes.
> > I'm getting a weird error from monticello. But I guess the changes
> > are the labelId and the hasLabelId, right?
> 
> Not directly more the changes in MA*Component.
> 
> > That is a solution for the
> > problem of setting an id. But what to do if you like to change an other
> > attribute, let's say the class of an component? Is there a better
> > approach for other attributes?
> 
> Actually yes. You can set #attributes of to an description to an
> instance of WAHtmlAttributes. I don't see a need to do this for
> classes since the existing markup is so fine grained you should be
> able to select anything you want.
> 
This paragraph I don't understand. Can you explain it once more, please?

thanks,

Norbert



From philippe.marschall at gmail.com  Mon Dec 18 17:48:24 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Mon, 18 Dec 2006 17:48:24 +0100
Subject: HTML Attributes with custom renderers
In-Reply-To: <1166458465.20462.6.camel@localhost>
References: <1166029552.9805.33.camel@localhost>
	<66666f210612130940s48b618a1u6862f3ad33a43f91@mail.gmail.com>
	<1166196737.9249.6.camel@localhost>
	<66666f210612150840s41b73402na06c983428715f99@mail.gmail.com>
	<1166202534.9249.24.camel@localhost>
	<66666f210612160146n3442ece8va3c95b03fee5477a@mail.gmail.com>
	<1166458465.20462.6.camel@localhost>
Message-ID: <66666f210612180848w76caf45aob2a92f3b6c81b327@mail.gmail.com>

2006/12/18, Norbert Hartl <norbert at hartl.name>:
> On Sat, 2006-12-16 at 10:46 +0100, Philippe Marschall wrote:
> > 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > > On Fri, 2006-12-15 at 17:40 +0100, Philippe Marschall wrote:
> > > > 2006/12/15, Norbert Hartl <norbert at hartl.name>:
> > > > > On Wed, 2006-12-13 at 18:40 +0100, Philippe Marschall wrote:
> > > > > > 2006/12/13, Norbert Hartl <norbert at hartl.name>:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm playing with custom views in Magritte. I have a model
> > > > > > > and overwrote descriptionContainer with my own instance of
> > > > > > > MAComponentRenderer.
> > > > > > >
> > > > > > > What I'm trying to achieve is to display a text input the
> > > > > > > following:
> > > > > > >
> > > > > > > <label for="anyid">labeltext</label>
> > > > > > > <input type="text" id="anyid"..../>
> > > > > > >
> > > > > > > As a quick test I changed the renderLabel: to
> > > > > > >
> > > > > > > renderLabel: aDescription
> > > > > > >    aDescription hasLabel
> > > > > > >       ifTrue: [ html
> > > > > > >          label attributeAt: 'for' put: aDescription hash;
> > > > > > >          with: [ html render: aDescription label ] ]
> > > > > > >
> > > > > > > I need an id attribute in the <input> tag which has the
> > > > > > > same content as the for attribute in the <label> tag.
> > > > > > > I don't have a glue how to insert an id attribute to the
> > > > > > > renderControl:. Is there a way to add an attribute if I only
> > > > > > > have a component. I doubt the component description is the
> > > > > > > right place to put.
> > > > > > >
> > > > > > > If I only want to change the behaviour of the text input field,
> > > > > > > is it best to overwrite the visitStringDescription?
> > > > > > >
> > > > > > > thanks in advance,
> > > > > >
> > > > > > This is something that crossed my mind too. To get an id you can use
> > > > > > something like this:
> > > > > > (component childAt: aDescription) ajaxId
> > > > > >
> > > > > > Now for the rendering of input tags. I see no way other than changing
> > > > > > or subclassing all the renderer classes.
> > > > > > MAMultiselectListComponent
> > > > > > MASelectListComponent
> > > > > > MATextInputComponent
> > > > > > MATextAreaComponent
> > > > > > MARadioGroupComponent
> > > > > > MARangeComponent
> > > > > > MATextPasswordComponent
> > > > > > MAFileUploadComponent
> > > > > > and whatever I forgot
> > > > > >
> > > > > > Honestly I think changing is better because I think it makes sense to
> > > > > > have this as default behavior.
> > > > > >
> > > > > I'm not sure what to change. The only way I see is to have writable
> > > > > attributes in MAComponent. While the attributes in the MADescription
> > > > > are class side attributes they could initialize the object attributes
> > > > > of a MAComponent when the component is created. Okay I'm not that of
> > > > > an experienced smalltalker but it doesn't sound very good to me, too :)
> > > > >
> > > > > What do you think?
> > > >
> > > > Have a look at: Magritte-Seaside-pmm.206.
> > > > It implements it for some elements. It needs a bit of cleanup, it is
> > > > not complete and has some rough edges.
> > > >
> > > Hmmm, I had a quick peek at the code. I couldn't look at the changes.
> > > I'm getting a weird error from monticello. But I guess the changes
> > > are the labelId and the hasLabelId, right?
> >
> > Not directly more the changes in MA*Component.
> >
> > > That is a solution for the
> > > problem of setting an id. But what to do if you like to change an other
> > > attribute, let's say the class of an component? Is there a better
> > > approach for other attributes?
> >
> > Actually yes. You can set #attributes of to an description to an
> > instance of WAHtmlAttributes. I don't see a need to do this for
> > classes since the existing markup is so fine grained you should be
> > able to select anything you want.
> >
> This paragraph I don't understand. Can you explain it once more, please?

Which part of it?
You can configure the descriptions. They have a method #attributes:
which you can use to add additional html attributes for descriptions.
Howerver this should not be needed for css classes because the html
Magritte produces should already allow you to select what you need
(yes, there are exceptions imaginable, but no common ones).

Philippe

From renggli at gmail.com  Wed Dec 20 14:39:40 2006
From: renggli at gmail.com (Lukas Renggli)
Date: Wed, 20 Dec 2006 14:39:40 +0100
Subject: Fwd: [Seaside] Magritte for VisualWorks
In-Reply-To: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
Message-ID: <67628d690612200539k42ea4839s52fe27a8d379fff@mail.gmail.com>

---------- Forwarded message ----------
From: Thomas Koschate <koschate at gmail.com>
Date: Dec 20, 2006 2:34 PM
Subject: [Seaside] Magritte for VisualWorks
To: seaside at lists.squeakfoundation.org


I've released a reasonably functional port of Magritte into the Cincom
public StORE.  Load MagritteForVisualWorks - it will prompt you to
load any further required parcels.  There's some chaff left from stuff
that isn't supported in VisualWorks, but nothing that will impede
functionality.
-- 
============================================================
Thomas Koschate


_______________________________________________
Seaside mailing list
Seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

From koschate at gmail.com  Thu Dec 21 19:37:40 2006
From: koschate at gmail.com (Thomas Koschate)
Date: Thu, 21 Dec 2006 13:37:40 -0500
Subject: Magritte/Seaside Bug
Message-ID: <4cb10a4f0612211037p7b18e9e2je3e25caa9c1cc85f@mail.gmail.com>

Lukas, I've uncovered a small bug in MAReportComponent.  While the
#renderContentOn: method calls #labelId, that method is not
implemented in the class hierarchy.  I'm not sure if the
implementation from MAElementComponent should be moved up, or if
something else was intended for the report hierarchy.  For reference,
this is in package Magritte-Seaside-pmm.206.
-- 
============================================================
Thomas Koschate

From renggli at iam.unibe.ch  Thu Dec 21 20:32:21 2006
From: renggli at iam.unibe.ch (Lukas Renggli)
Date: Thu, 21 Dec 2006 20:32:21 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
Message-ID: <6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>

>> May I suggest that you remove #asString from UndefinedObject and  
>> replace all #asString
>> sends by #displayString in Magritte. Once you have an inventory of  
>> all these replacements,
>> you will just need to apply them to the Squeak package and do  
>> another port. I found about
>> 15 occurences of #asString sends in Magritte. Of course this would  
>> have to be
>> negotiated with Lukas. That's why I copied him.
>
> I seem to be haunted by #asString in every Smalltalk dialect I come  
> across.  In my real life (a VisualAge/GemStone/ObjectStudio shop),  
> we've adopted #displayString as well.  While I'm willing to make  
> that change, I'd certainly prefer it if we could prevail upon Lukas  
> to do it, if only to avoid coordination issues.

The problem here is that this will turn the Magritte-Core package  
dependent on the Seaside package, because it already defines  
#displayString. Otherwise I don't see a problem to adopt this in the  
Squeak Code.

>> 2) Among others, the Seaside-VW bundle includes bundle Squeak.  
>> This bundle is intended
>> to group all extensions that are needed by VisualWorks to look  
>> like Squeak. It is used by
>> Seaside but can be used by any project that is ported from Squeak.  
>> I could see that your
>> Magritte port contains a lot of extensions that would be better  
>> placed in the Squeak bundle.
>> May I propose the following. I can create a version of the Squeak  
>> and Seaside bundles in
>> the public store with as many as poissible of the Squeak  
>> extensions needed by Magritte.
>> When it is ready, I let you know, then you will be able to remove  
>> the extensions from your
>> Magritte port.
>
> I'm quite happy to go this route.  I was getting a little dismayed  
> at the number of Squeak-isms that I had to implement for the port,  
> and any work done getting them out of the Magritte package will  
> help other porting efforts.

If you have any idea to reduce these I am happy to accept patches.

> A question for Lukas:  I came across the use of  
> SystemChangeNotifier in Magritte.  I ended up either removing or no- 
> oping operations related to it.  Is there something I'm losing as a  
> result?  I couldn't find any uses outside of Magritte that didn't  
> appear to be related to the development environment itself.

There are two uses of SystemChangeNotifier, they should be probably  
moved to the MACompatiblity class.

1. MAAutoSelectorAccessorTest: this one is only needed to prevent  
from marking the test-package dirty as this tests adds/removes i-vars/ 
accessors.

2. MADescriptionBuilder: this one makes sure that the description  
cache is flushed whenever a description method is changed/added/removed.

The first one isn't critical, as this is only a tweak to make the  
test run clean. The second one is more critical, without it you need  
to flush the description cache manually by executing

	MADescriptionBuilder default flush

There were some concerns in the beginning that rebuilding those  
descriptions over and over again is very costly, therefor I added the  
caching. I don't know if this is still relevant. Probably it hurts  
more than it helps, but we have to check.

> Lukas, I've uncovered a small bug in MAReportComponent.  While the  
> #renderContentOn: method calls #labelId, that method is not  
> implemented in the class hierarchy.  I'm not sure if the  
> implementation from MAElementComponent should be moved up, or if  
> something else was intended for the report hierarchy.  For  
> reference, this is in package Magritte-Seaside-pmm.206.

I think this change was introduced by the latest change of Philippe,  
maybe he can have a look?

Cheers,
Lukas

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



From philippe.marschall at gmail.com  Thu Dec 21 22:59:02 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Thu, 21 Dec 2006 22:59:02 +0100
Subject: Magritte/Seaside Bug
In-Reply-To: <4cb10a4f0612211037p7b18e9e2je3e25caa9c1cc85f@mail.gmail.com>
References: <4cb10a4f0612211037p7b18e9e2je3e25caa9c1cc85f@mail.gmail.com>
Message-ID: <66666f210612211359n67ee7700wa868e0e61a106c5e@mail.gmail.com>

2006/12/21, Thomas Koschate <koschate at gmail.com>:
> Lukas, I've uncovered a small bug in MAReportComponent.  While the
> #renderContentOn: method calls #labelId, that method is not
> implemented in the class hierarchy.  I'm not sure if the
> implementation from MAElementComponent should be moved up, or if
> something else was intended for the report hierarchy.  For reference,
> this is in package Magritte-Seaside-pmm.206.

You're right, thanks for reporting.
Check out Magritte-Seaside-pmm.207 that should fix it.

Cheers
Philippe

From koschate at omasko.com  Thu Dec 21 23:05:57 2006
From: koschate at omasko.com (Thomas Koschate)
Date: Thu, 21 Dec 2006 17:05:57 -0500
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
Message-ID: <2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>


On 2006-12-21, at 14:32, Lukas Renggli wrote:

> The problem here is that this will turn the Magritte-Core package  
> dependent on the Seaside package, because it already defines  
> #displayString. Otherwise I don't see a problem to adopt this in  
> the Squeak Code.

I guess the question that would need answering is, how many users  
would be affected by having load the Seaside package first?  In the  
case of the VW port, I pre-req Seaside anyway.  What how many Squeak  
users are _not_ using Seaside with Magritte?  I think both of those  
users could live with having to load the Seaside code as well.  :{)

> There are two uses of SystemChangeNotifier, they should be probably  
> moved to the MACompatiblity class.

Ah, yes, the "Incompatibility" class, as I call it.  :{)  That, and  
the MADistribution class came over to VW with just about nothing  
working.  I got the test for #referenceStream: working, but only by  
changing the test code.  I have my doubts as to whether the block- 
related stuff will really work properly as well, but I don't think  
it's a big concern for the Seaside-based users that will be the  
biggest (only) consumers in VW.

> 1. MAAutoSelectorAccessorTest: this one is only needed to prevent  
> from marking the test-package dirty as this tests adds/removes i- 
> vars/accessors.

I don't believe this is an issue in VW/StORE - it would be in an ENVY  
environment.  I modified the code to just pass the message send on to  
super.

> There were some concerns in the beginning that rebuilding those  
> descriptions over and over again is very costly, therefor I added  
> the caching. I don't know if this is still relevant. Probably it  
> hurts more than it helps, but we have to check.

Uh oh, the evil spectre of premature optimization rears its ugly head!

For development purposes, I can live with manually flushing the cache  
as needed.  For a runtime environment, my personal preference is to  
use packaged images anyway, so I find it hard to worry too much about  
the impact of code changes.  If we document a need to flush the  
cache, I think that should be sufficient, unless someone more into  
the internals of VW browsers has a better idea.

> I think this change was introduced by the latest change of  
> Philippe, maybe he can have a look?

I'll do another port once we've figured out this one - I've found a  
few other little things I'd like to clean up anyway.
-- 
============================================================
Thomas Koschate
-- 
============================================================
Thomas Koschate                              +1 416.716.5949
koschate at omasko.com                    FAX:  +1 905.451.9268
PGP Key:  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4659702E



From koschate at omasko.com  Fri Dec 22 00:36:08 2006
From: koschate at omasko.com (Thomas Koschate)
Date: Thu, 21 Dec 2006 18:36:08 -0500
Subject: Magritte/Seaside Bug
In-Reply-To: <66666f210612211359n67ee7700wa868e0e61a106c5e@mail.gmail.com>
References: <4cb10a4f0612211037p7b18e9e2je3e25caa9c1cc85f@mail.gmail.com>
	<66666f210612211359n67ee7700wa868e0e61a106c5e@mail.gmail.com>
Message-ID: <0220D7C1-DACE-4FDD-8D36-2C1DB669D218@omasko.com>


On 2006-12-21, at 16:59, Philippe Marschall wrote:

> You're right, thanks for reporting.
> Check out Magritte-Seaside-pmm.207 that should fix it.

I've re-published the VW port incorporating this fix and some other  
minor clean-up.
-- 
============================================================
Thomas Koschate 

From renggli at iam.unibe.ch  Fri Dec 22 09:35:41 2006
From: renggli at iam.unibe.ch (Lukas Renggli)
Date: Fri, 22 Dec 2006 09:35:41 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
Message-ID: <E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>

>> The problem here is that this will turn the Magritte-Core package  
>> dependent on the Seaside package, because it already defines  
>> #displayString. Otherwise I don't see a problem to adopt this in  
>> the Squeak Code.
>
> I guess the question that would need answering is, how many users  
> would be affected by having load the Seaside package first?  In the  
> case of the VW port, I pre-req Seaside anyway.  What how many  
> Squeak users are _not_ using Seaside with Magritte?  I think both  
> of those users could live with having to load the Seaside code as  
> well.  :{)

I am using Magritte without Seaside, but you are right mostly  
Magritte is used together with Seaside :-p

>> There are two uses of SystemChangeNotifier, they should be  
>> probably moved to the MACompatiblity class.
>
> Ah, yes, the "Incompatibility" class, as I call it.  :{)  That, and  
> the MADistribution class came over to VW with just about nothing  
> working.

You can probably remove MADistribution, that's solely needed to  
create automatically create a package on SqueakMap.

>> There were some concerns in the beginning that rebuilding those  
>> descriptions over and over again is very costly, therefor I added  
>> the caching. I don't know if this is still relevant. Probably it  
>> hurts more than it helps, but we have to check.
>
> Uh oh, the evil spectre of premature optimization rears its ugly head!

Well, actually it is relevant:

- Looking for a string-match in a Pier model with hundreds of pages  
can be written with Magritte in 3 lines of code. Caching the  
descriptions speeds up the lookup by magnitudes of 1000. Moreover it  
avoids creating new objects while traversing the whole graph.

> For development purposes, I can live with manually flushing the  
> cache as needed.

It was like this in beginning of Magritte. It is just more convenient  
not to have to worry about invalid caches. Maybe in you case you want  
to disable it altogether, have a look at MANamedBuilder and replace  
its references (should be only one) with your own implementation that  
does not cache.

> For a runtime environment, my personal preference is to use  
> packaged images anyway, so I find it hard to worry too much about  
> the impact of code changes.  If we document a need to flush the  
> cache, I think that should be sufficient, unless someone more into  
> the internals of VW browsers has a better idea.

Yeah, for deployment this doesn't matter anymore. Descriptions you  
bild programmatically (or you end-users are building) are not cached  
anymore.

Lukas

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



From michel.bany at gmail.com  Fri Dec 22 10:24:03 2006
From: michel.bany at gmail.com (Michel Bany)
Date: Fri, 22 Dec 2006 10:24:03 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
	<E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
Message-ID: <C6E2B022-387A-4DDB-852E-F1C5BAEA6CBC@gmail.com>


On 22 Dec 2006, at 09:35 , Lukas Renggli wrote:

>>> The problem here is that this will turn the Magritte-Core package  
>>> dependent on the Seaside package, because it already defines  
>>> #displayString. Otherwise I don't see a problem to adopt this in  
>>> the Squeak Code.
>>
>> I guess the question that would need answering is, how many users  
>> would be affected by having load the Seaside package first?  In  
>> the case of the VW port, I pre-req Seaside anyway.  What how many  
>> Squeak users are _not_ using Seaside with Magritte?  I think both  
>> of those users could live with having to load the Seaside code as  
>> well.  :{)
>
> I am using Magritte without Seaside, but you are right mostly  
> Magritte is used together with Seaside :-p

If #displayString was added (duplicated) to Magritte, wouldn't that  
make Magritte independent of Seaside ?

Michel



From renggli at iam.unibe.ch  Fri Dec 22 10:35:25 2006
From: renggli at iam.unibe.ch (Lukas Renggli)
Date: Fri, 22 Dec 2006 10:35:25 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <C6E2B022-387A-4DDB-852E-F1C5BAEA6CBC@gmail.com>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
	<E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
	<C6E2B022-387A-4DDB-852E-F1C5BAEA6CBC@gmail.com>
Message-ID: <CB48C676-8FE0-49A7-AFBC-078EADA5D635@iam.unibe.ch>

>>>> The problem here is that this will turn the Magritte-Core  
>>>> package dependent on the Seaside package, because it already  
>>>> defines #displayString. Otherwise I don't see a problem to adopt  
>>>> this in the Squeak Code.
>>>
>>> I guess the question that would need answering is, how many users  
>>> would be affected by having load the Seaside package first?  In  
>>> the case of the VW port, I pre-req Seaside anyway.  What how many  
>>> Squeak users are _not_ using Seaside with Magritte?  I think both  
>>> of those users could live with having to load the Seaside code as  
>>> well.  :{)
>>
>> I am using Magritte without Seaside, but you are right mostly  
>> Magritte is used together with Seaside :-p
>
> If #displayString was added (duplicated) to Magritte, wouldn't that  
> make Magritte independent of Seaside ?

Yes, but unfortunately Monticello 1 (as opposed to Monticello 2) does  
not allow a method to be in two different packages. At least as far  
as I know.

Lukas

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



From michel.bany at gmail.com  Fri Dec 22 16:26:06 2006
From: michel.bany at gmail.com (Michel Bany)
Date: Fri, 22 Dec 2006 16:26:06 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <CB48C676-8FE0-49A7-AFBC-078EADA5D635@iam.unibe.ch>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
	<E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
	<C6E2B022-387A-4DDB-852E-F1C5BAEA6CBC@gmail.com>
	<CB48C676-8FE0-49A7-AFBC-078EADA5D635@iam.unibe.ch>
Message-ID: <A7444813-8F2E-462D-BBF4-F20DB761A69A@gmail.com>


On 22 Dec 2006, at 10:35 , Lukas Renggli wrote:

>>>>> The problem here is that this will turn the Magritte-Core  
>>>>> package dependent on the Seaside package, because it already  
>>>>> defines #displayString. Otherwise I don't see a problem to  
>>>>> adopt this in the Squeak Code.
>>>>
>>>> I guess the question that would need answering is, how many  
>>>> users would be affected by having load the Seaside package  
>>>> first?  In the case of the VW port, I pre-req Seaside anyway.   
>>>> What how many Squeak users are _not_ using Seaside with  
>>>> Magritte?  I think both of those users could live with having to  
>>>> load the Seaside code as well.  :{)
>>>
>>> I am using Magritte without Seaside, but you are right mostly  
>>> Magritte is used together with Seaside :-p
>>
>> If #displayString was added (duplicated) to Magritte, wouldn't  
>> that make Magritte independent of Seaside ?
>
> Yes, but unfortunately Monticello 1 (as opposed to Monticello 2)  
> does not allow a method to be in two different packages. At least  
> as far as I know.

Should we give up trying ?
I already did that with different versions of the same method in  
Seaside and SeasideAsync.
It just required extra care, making sure that SeasideAsync was not  
loaded when publishing Seaside.

Michel.






From koschate at omasko.com  Fri Dec 22 22:54:23 2006
From: koschate at omasko.com (Thomas Koschate)
Date: Fri, 22 Dec 2006 16:54:23 -0500
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
	<E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
Message-ID: <C5F96874-521E-47D7-916F-5575749D1A7B@omasko.com>


On 2006-12-22, at 03:35, Lukas Renggli wrote:

>> For development purposes, I can live with manually flushing the  
>> cache as needed.
>
> It was like this in beginning of Magritte. It is just more  
> convenient not to have to worry about invalid caches. Maybe in you  
> case you want to disable it altogether, have a look at  
> MANamedBuilder and replace its references (should be only one) with  
> your own implementation that does not cache.

I was poking around the VW image today, and I've found a spot to hook  
in flushing behavior fairly simply, if it's sufficient to flush just  
the instance returned by MADescriptionBuilder class>>default.   
Otherwise, I think a slightly more ambitious bit of coding will be  
needed.

Otherwise, SeasidePlatformSupport looks like the place to add in some  
hooks to register for change notification, since it already gets sent  
#refactoringChange: when code is modified.  What do you think, Michel?
-- 
============================================================
Thomas Koschate 

From renggli at iam.unibe.ch  Sat Dec 23 09:12:06 2006
From: renggli at iam.unibe.ch (Lukas Renggli)
Date: Sat, 23 Dec 2006 09:12:06 +0100
Subject: [Seaside] Magritte for VisualWorks
In-Reply-To: <C5F96874-521E-47D7-916F-5575749D1A7B@omasko.com>
References: <4cb10a4f0612200534k20bb76edv6417ba86ea49b470@mail.gmail.com>
	<93AC1C01-F877-46B5-8AE0-6F5354213FD9@gmail.com>
	<AA87357B-8456-4846-B92C-2961EC93CF4B@omasko.com>
	<6DD51567-F0EE-4B58-8CAD-4220570C0EF1@iam.unibe.ch>
	<2F6884F5-16CD-42E3-9227-E498DA947825@omasko.com>
	<E2746491-3BF5-491E-8A05-44E458E78F33@iam.unibe.ch>
	<C5F96874-521E-47D7-916F-5575749D1A7B@omasko.com>
Message-ID: <41465739-EE85-43D9-B2D5-49F11AD3AD17@iam.unibe.ch>

>>> For development purposes, I can live with manually flushing the  
>>> cache as needed.
>>
>> It was like this in beginning of Magritte. It is just more  
>> convenient not to have to worry about invalid caches. Maybe in you  
>> case you want to disable it altogether, have a look at  
>> MANamedBuilder and replace its references (should be only one)  
>> with your own implementation that does not cache.
>
> I was poking around the VW image today, and I've found a spot to  
> hook in flushing behavior fairly simply, if it's sufficient to  
> flush just the instance returned by MADescriptionBuilder  
> class>>default.  Otherwise, I think a slightly more ambitious bit  
> of coding will be needed.

MADescriptionBuilder default flush

> Otherwise, SeasidePlatformSupport looks like the place to add in  
> some hooks to register for change notification, since it already  
> gets sent #refactoringChange: when code is modified.  What do you  
> think, Michel?

That's why there is MACompatiblity. All things in there that are  
certainly not compatible with other dialects than Squeak, but  
obviously the change-notification stuff is missing.

I cannot support starting to weaken the boundaries of packages. Just  
have a look at Seaside, we are trying to clean it up a little in 2.7  
now.

Cheers,
Lukas

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



From chris at wysseier.net  Tue Dec 26 23:33:12 2006
From: chris at wysseier.net (Christoph Wysseier)
Date: Tue, 26 Dec 2006 23:33:12 +0100
Subject: [ANN] Adapt Look & Feel of Pier using File Libraries
Message-ID: <4591A328.1040107@wysseier.net>

Hi all!

Pier is using Seaside File Libraries (PRPierLibrary) to store CSS and 
images for the look'n'feel. Using a small extension that I just 
committed it is now very easy to change the look'n'feel by just changing 
the file library to another one.

Name: Pier-Seaside-cw.107
Author: cw
Time: 26 December 2006, 12:56:04 pm

After loading this patch a variable will be available in the seaside 
config that allows you to change the default File Library to any other 
you need to provide before (any subclass of WAFileLibrary is available). 
This way the look'n'feel may be changed on-the-fly and you may store 
your own File Library with your CSS and image files in a repository of 
your choice.

Good night!

Chris
-- 
--------------------------------
Christoph Wysseier
L?nggassstr. 74
3012 Bern

T +41 31 972 92 08
M +41 78 616 35 35
chris at wysseier.net
--------------------------------

From philippe.marschall at gmail.com  Sat Dec 30 15:18:43 2006
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Sat, 30 Dec 2006 15:18:43 +0100
Subject: [ANN] Fear for Pier
Message-ID: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>

Hi

Inspired by fear for Firefox [1] there exists now fear for Pier too [2].

[1] https://addons.mozilla.org/firefox/1645/
[2] http://mc.lukas-renggli.ch/pieraddons.html

Cheers
Philippe

From damien.cassou at laposte.net  Sat Dec 30 15:56:57 2006
From: damien.cassou at laposte.net (Damien Cassou)
Date: Sat, 30 Dec 2006 15:56:57 +0100
Subject: [ANN] Fear for Pier
In-Reply-To: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
References: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
Message-ID: <45967E39.6040204@laposte.net>

Philippe Marschall a ?crit :
> Hi
> 
> Inspired by fear for Firefox [1] there exists now fear for Pier too [2].

Is it really useful ? :-)

http://en.wikipedia.org/wiki/Litany_against_fear


From ducasse at iam.unibe.ch  Sat Dec 30 15:58:25 2006
From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=)
Date: Sat, 30 Dec 2006 15:58:25 +0100
Subject: [ANN] Fear for Pier
In-Reply-To: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
References: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
Message-ID: <305626FB-90CE-49EA-8938-5E730779B6FD@iam.unibe.ch>

philippe  what does fear do?
  I read the firfox link but could not understand

On 30 d?c. 06, at 15:18, Philippe Marschall wrote:

> Hi
>
> Inspired by fear for Firefox [1] there exists now fear for Pier too  
> [2].
>
> [1] https://addons.mozilla.org/firefox/1645/
> [2] http://mc.lukas-renggli.ch/pieraddons.html
>
> Cheers
> Philippe
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From damien.cassou at laposte.net  Sat Dec 30 16:12:52 2006
From: damien.cassou at laposte.net (Damien Cassou)
Date: Sat, 30 Dec 2006 16:12:52 +0100
Subject: [ANN] Fear for Pier
In-Reply-To: <305626FB-90CE-49EA-8938-5E730779B6FD@iam.unibe.ch>
References: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
	<305626FB-90CE-49EA-8938-5E730779B6FD@iam.unibe.ch>
Message-ID: <459681F4.3050509@laposte.net>

st?phane ducasse a ?crit :
> philippe  what does fear do?
>   I read the firfox link but could not understand

Nothing :-) It only displays

     I must not fear.
     Fear is the mind-killer.
     Fear is the little-death that brings total obliteration.
     I will face my fear.
     I will permit it to pass over me and through me.
     And when it has gone past I will turn the inner eye to see its path.
     Where the fear has gone there will be nothing.
     Only I will remain.

Have a look at http://en.wikipedia.org/wiki/Litany_against_fear



Bye

From ducasse at iam.unibe.ch  Sat Dec 30 19:15:09 2006
From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=)
Date: Sat, 30 Dec 2006 19:15:09 +0100
Subject: [ANN] Fear for Pier
In-Reply-To: <459681F4.3050509@laposte.net>
References: <66666f210612300618v772470b6kcb523397cc32cd7@mail.gmail.com>
	<305626FB-90CE-49EA-8938-5E730779B6FD@iam.unibe.ch>
	<459681F4.3050509@laposte.net>
Message-ID: <1A8FD886-23B2-494F-A6CA-23D1C88FD4B1@iam.unibe.ch>

This is fun this one of my recitation when I was in college :)
Quite good!

Dune! Excellent!
Stef

On 30 d?c. 06, at 16:12, Damien Cassou wrote:

> st?phane ducasse a ?crit :
>> philippe  what does fear do?
>>   I read the firfox link but could not understand
>
> Nothing :-) It only displays
>
>      I must not fear.
>      Fear is the mind-killer.
>      Fear is the little-death that brings total obliteration.
>      I will face my fear.
>      I will permit it to pass over me and through me.
>      And when it has gone past I will turn the inner eye to see its  
> path.
>      Where the fear has gone there will be nothing.
>      Only I will remain.
>
> Have a look at http://en.wikipedia.org/wiki/Litany_against_fear
>
>
>
> Bye
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>