From p3anoman at gmail.com  Mon Feb  1 01:33:42 2010
From: p3anoman at gmail.com (John McKeon)
Date: Sun, 31 Jan 2010 19:33:42 -0500
Subject: PRFile, MAFileModel and friends
In-Reply-To: <1264974382.11406.12.camel@corn.betterworld.us>
References: <1264974382.11406.12.camel@corn.betterworld.us>
Message-ID: <40f637ec1001311633mecac013q66e653489b5cc787@mail.gmail.com>

Hi Ross,

On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross at biostat.ucsf.edu> wrote:

> I am trying to figure out the relation between PRFile, MAFileModel,
> MAFileDescription, and possibly others.  They seem to duplicate a lot of
> information, such as mimetype and filename.
>
> I'm using the Pier-1.2 download.
>
> PRFile says it references an instance of MAFileModel, but a lot of test
> code for seems to get by without an MAFileModel.
>

Look at the class side of PRFile. Its in the descriptionFile method.

>
> I've looked for references to the classes, but have found either
> extremely terse and trivial tests or the setupup for, e.g., defaultCSS.
>
> I also don't know which of the classes is intended for display, or how
> to display them.
>
> Initially, I just want to use these to display links to files that are
> on the disk.  Presumably that will use MAExternalFileModel somehow.
>

You really don't need to worry about all that in Pier I don't think. Just
use the Add command and select PRFile from the combo box. Then edit the page
to put a reference to it. Given that it is named MyFile the reference would
look like +/MyFile+ (also given that it is added to the root page)

Hope this helps
John


> Later on, I may want to have pseudo files that include the ability to
> select a format in which to download the file or to display the file
> inline on the web page.




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



-- 
http://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100131/b2ceaff6/attachment.html>

From ross at biostat.ucsf.edu  Mon Feb  1 02:32:29 2010
From: ross at biostat.ucsf.edu (Ross Boylan)
Date: Sun, 31 Jan 2010 17:32:29 -0800
Subject: PRFile, MAFileModel and friends
In-Reply-To: <40f637ec1001311633mecac013q66e653489b5cc787@mail.gmail.com>
References: <1264974382.11406.12.camel@corn.betterworld.us>
	<40f637ec1001311633mecac013q66e653489b5cc787@mail.gmail.com>
Message-ID: <1264987949.11406.19.camel@corn.betterworld.us>

On Sun, 2010-01-31 at 19:33 -0500, John McKeon wrote:
> Hi Ross,
> 
> On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross at biostat.ucsf.edu>
> wrote:
>         I am trying to figure out the relation between PRFile,
>         MAFileModel,
>         MAFileDescription, and possibly others.  They seem to
>         duplicate a lot of
>         information, such as mimetype and filename.
>         
>         I'm using the Pier-1.2 download.
>         
>         PRFile says it references an instance of MAFileModel, but a
>         lot of test
>         code for seems to get by without an MAFileModel.
> 
> 
> Look at the class side of PRFile. Its in the descriptionFile method. 
Ah: the file instance is lazily initialized with this, and then
PRFile>>filename: and PRFile>>contents, for example, pass through to the
file instance.
>         
>         I've looked for references to the classes, but have found
>         either
>         extremely terse and trivial tests or the setupup for, e.g.,
>         defaultCSS.
>         
>         I also don't know which of the classes is intended for
>         display, or how
>         to display them.
>         
>         Initially, I just want to use these to display links to files
>         that are
>         on the disk.  Presumably that will use MAExternalFileModel
>         somehow.
> 
> 
> You really don't need to worry about all that in Pier I don't think.
> Just use the Add command and select PRFile from the combo box. 
I need to generate these programmatically by scanning a directory on the
server.

But PRFile itself has no display logic, and so I'm not sure how that
gets hooked up.

Is the idea to add PRFile as a child of the PRPage?
> Then edit the page to put a reference to it. Given that it is named
> MyFile the reference would look like +/MyFile+ (also given that it is
> added to the root page)
> 
> 
> Hope this helps
> John
> 
> 
>         
>         Later on, I may want to have pseudo files that include the
>         ability to
>         select a format in which to download the file or to display
>         the file
>         inline on the web page.
>          
>         
>         Ross Boylan
>         
>         _______________________________________________
>         Magritte, Pier and Related Tools ...
>         https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> http://jmck.seasidehosting.st
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From p3anoman at gmail.com  Mon Feb  1 03:25:33 2010
From: p3anoman at gmail.com (John McKeon)
Date: Sun, 31 Jan 2010 21:25:33 -0500
Subject: PRFile, MAFileModel and friends
In-Reply-To: <1264987949.11406.19.camel@corn.betterworld.us>
References: <1264974382.11406.12.camel@corn.betterworld.us>
	<40f637ec1001311633mecac013q66e653489b5cc787@mail.gmail.com>
	<1264987949.11406.19.camel@corn.betterworld.us>
Message-ID: <40f637ec1001311825l26d5ed8ds97ab2467fbb64a02@mail.gmail.com>

On Sun, Jan 31, 2010 at 8:32 PM, Ross Boylan <ross at biostat.ucsf.edu> wrote:

> On Sun, 2010-01-31 at 19:33 -0500, John McKeon wrote:
> > Hi Ross,
> >
> > On Sun, Jan 31, 2010 at 4:46 PM, Ross Boylan <ross at biostat.ucsf.edu>
> > wrote:
> >         I am trying to figure out the relation between PRFile,
> >         MAFileModel,
> >         MAFileDescription, and possibly others.  They seem to
> >         duplicate a lot of
> >         information, such as mimetype and filename.
> >
> >         I'm using the Pier-1.2 download.
> >
> >         PRFile says it references an instance of MAFileModel, but a
> >         lot of test
> >         code for seems to get by without an MAFileModel.
> >
> >
> > Look at the class side of PRFile. Its in the descriptionFile method.
> Ah: the file instance is lazily initialized with this, and then
> PRFile>>filename: and PRFile>>contents, for example, pass through to the
> file instance.
> >
> >         I've looked for references to the classes, but have found
> >         either
> >         extremely terse and trivial tests or the setupup for, e.g.,
> >         defaultCSS.
> >
> >         I also don't know which of the classes is intended for
> >         display, or how
> >         to display them.
> >
> >         Initially, I just want to use these to display links to files
> >         that are
> >         on the disk.  Presumably that will use MAExternalFileModel
> >         somehow.
> >
> >
> > You really don't need to worry about all that in Pier I don't think.
> > Just use the Add command and select PRFile from the combo box.
> I need to generate these programmatically by scanning a directory on the
> server.
>

That would probably take some custom code. Depending on how you would use it
it could be a plain old Seaside component (easier) or a Pier component which
would be a little more involved.


> But PRFile itself has no display logic, and so I'm not sure how that
> gets hooked up.
>

A PRFile is a structure, when added to the tree of structures that make up
the site, Pier renders it with the proper PRViewComponent. Pier is very
sophisticated that way.

>
> Is the idea to add PRFile as a child of the PRPage?
>

Yes, exactly. Doing it this way, you can add all the files you like without
writing any code. I.e. content management from the web browser.


> > Then edit the page to put a reference to it. Given that it is named
> > MyFile the reference would look like +/MyFile+ (also given that it is
> > added to the root page)
> >
> >
> > Hope this helps
> > John
> >
> >
> >
> >         Later on, I may want to have pseudo files that include the
> >         ability to
> >         select a format in which to download the file or to display
> >         the file
> >         inline on the web page.
> >
> >
> >         Ross Boylan
> >
> >         _______________________________________________
> >         Magritte, Pier and Related Tools ...
> >         https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
> >
> >
> > --
> > http://jmck.seasidehosting.st
> > _______________________________________________
> > 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://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100131/4bada82e/attachment.html>

From renggli at gmail.com  Mon Feb  1 07:25:27 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 1 Feb 2010 07:25:27 +0100
Subject: PRFile, MAFileModel and friends
In-Reply-To: <1264974382.11406.12.camel@corn.betterworld.us>
References: <1264974382.11406.12.camel@corn.betterworld.us>
Message-ID: <67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com>

> I also don't know which of the classes is intended for display, or how
> to display them.

MAFileModel represents a file in Smalltalk. It knows the filename,
mimetype, size, contents, etc. MAExternalFileModel is no different,
other than it stores the file contents externally to the image (see
class comment). The location and naming of this file is managed
automatically, you cannot change it.

> Initially, I just want to use these to display links to files that are
> on the disk. ?Presumably that will use MAExternalFileModel somehow.

AFAIK other people have written MAFileModel subclasses that refer to a
specific external file.

Lukas

>
> Later on, I may want to have pseudo files that include the ability to
> select a format in which to download the file or to display the file
> inline on the web page.
>
> Ross Boylan
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

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


From ross at biostat.ucsf.edu  Mon Feb  1 19:56:34 2010
From: ross at biostat.ucsf.edu (Ross Boylan)
Date: Mon, 01 Feb 2010 10:56:34 -0800
Subject: PRFile, MAFileModel and friends
In-Reply-To: <67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com>
References: <1264974382.11406.12.camel@corn.betterworld.us>
	<67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com>
Message-ID: <1265050594.11406.42.camel@corn.betterworld.us>

On Mon, 2010-02-01 at 07:25 +0100, Lukas Renggli wrote:
> > I also don't know which of the classes is intended for display, or how
> > to display them.
> 
> MAFileModel represents a file in Smalltalk. It knows the filename,
> mimetype, size, contents, etc. MAExternalFileModel is no different,
> other than it stores the file contents externally to the image (see
> class comment). The location and naming of this file is managed
> automatically, you cannot change it.
> 
> > Initially, I just want to use these to display links to files that are
> > on the disk.  Presumably that will use MAExternalFileModel somehow.
> 
> AFAIK other people have written MAFileModel subclasses that refer to a
> specific external file.
> 
I hadn't realized that MAExternalFileModel was for an uploaded file,
stored on disk.  Making a new subclass to handle files originating on
the server, in "random" directories, sounds straightforward.

I remain puzzled by how to hook these up to output, as well as what the
responsibility of PRFile is.  I've been using a custom component to
display the files, but since PRFile is a model it doesn't seem to belong
there.

I think a natural procedure would be to make a PRPage and then use
addChild: to stick PRFile's into it.  However, the list of files is
dynamic (depending on what's in the directory).  How can I handle that?

Thanks.
Ross


From renggli at gmail.com  Mon Feb  1 20:43:58 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 1 Feb 2010 20:43:58 +0100
Subject: PRFile, MAFileModel and friends
In-Reply-To: <1265050594.11406.42.camel@corn.betterworld.us>
References: <1264974382.11406.12.camel@corn.betterworld.us> 
	<67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com> 
	<1265050594.11406.42.camel@corn.betterworld.us>
Message-ID: <67628d691002011143v5cfceb00hb9486575fe9598bb@mail.gmail.com>

> I hadn't realized that MAExternalFileModel was for an uploaded file,
> stored on disk. ?Making a new subclass to handle files originating on
> the server, in "random" directories, sounds straightforward.

That's the model of a file as a bytearray with a name and mimetype.

> I remain puzzled by how to hook these up to output, as well as what the
> responsibility of PRFile is. ?I've been using a custom component to
> display the files, but since PRFile is a model it doesn't seem to belong
> there.

That's the model of a file anywhere in the Pier structure tree. As it
was previously said, it refers to a MAFileModel.

> I think a natural procedure would be to make a PRPage and then use
> addChild: to stick PRFile's into it.

That's what people do when they upload files through the web.

> However, the list of files is
> dynamic (depending on what's in the directory). ?How can I handle that?

What directory? In Pier there are only structures that form a
"virtual" directory tree of pages, files, seaside components, books,
chapters, blogs, posts, etc.

Lukas

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


From ross at biostat.ucsf.edu  Mon Feb  1 20:54:47 2010
From: ross at biostat.ucsf.edu (Ross Boylan)
Date: Mon, 01 Feb 2010 11:54:47 -0800
Subject: PRFile, MAFileModel and friends
In-Reply-To: <67628d691002011143v5cfceb00hb9486575fe9598bb@mail.gmail.com>
References: <1264974382.11406.12.camel@corn.betterworld.us>
	<67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com>
	<1265050594.11406.42.camel@corn.betterworld.us>
	<67628d691002011143v5cfceb00hb9486575fe9598bb@mail.gmail.com>
Message-ID: <1265054087.11406.60.camel@corn.betterworld.us>

On Mon, 2010-02-01 at 20:43 +0100, Lukas Renggli wrote:
> > However, the list of files is
> > dynamic (depending on what's in the directory).  How can I handle
> that?
> 
> What directory? In Pier there are only structures that form a
> "virtual" directory tree of pages, files, seaside components, books,
> chapters, blogs, posts, etc.
"directory" refers to a directory on the server's file system. 
The list of files presented by Pier is taken from the list of files in
that directory.  Files will appear and disappear, as well as changing
contents.

So the problem is that if I create a Pier page that is correct at one
time, it won't necessarily be correct, in the sense of matching the
contents of the directory on disk, later.

Ross


From renggli at gmail.com  Mon Feb  1 20:59:31 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Mon, 1 Feb 2010 20:59:31 +0100
Subject: PRFile, MAFileModel and friends
In-Reply-To: <1265054087.11406.60.camel@corn.betterworld.us>
References: <1264974382.11406.12.camel@corn.betterworld.us> 
	<67628d691001312225o2955c619kfde5f90b34ba80df@mail.gmail.com> 
	<1265050594.11406.42.camel@corn.betterworld.us>
	<67628d691002011143v5cfceb00hb9486575fe9598bb@mail.gmail.com> 
	<1265054087.11406.60.camel@corn.betterworld.us>
Message-ID: <67628d691002011159n2e252a3ela997c48c6a30a6d7@mail.gmail.com>

> "directory" refers to a directory on the server's file system.
> The list of files presented by Pier is taken from the list of files in
> that directory. ?Files will appear and disappear, as well as changing
> contents.

Ok, I see.

> So the problem is that if I create a Pier page that is correct at one
> time, it won't necessarily be correct, in the sense of matching the
> contents of the directory on disk, later.

Yes, such a use case is not out-of-the-box supported. You'll need to
do some programming here. Depending on how close you want to integrate
it, you can create your own PRStructure subclass that handles this for
you; or, as others already suggested, have a Seaside component that
does something meaningful with the file directory.

Lukas

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


From nick.ager at gmail.com  Mon Feb  1 23:14:59 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 1 Feb 2010 22:14:59 +0000
Subject: JQuery search widget
Message-ID: <3a06f76f1002011414n7df4931cg84bce3832605e46f@mail.gmail.com>

Hi,

I've created a PRJQuerySearchWidget as a plug in replacement for the
existing PRAjaxSearchWidget. It uses the new Seaside JQuery autocomplete
widget, which Lukas has recently added. I implemented it as I'm using other
JQuery widgets on my page and didn't want to be without autocomplete search
AND I haven't found a satisfactory way to mix scriptaculous and jquery
widgets on the same page.

I'll check it in as soon as a couple of fixes go into Seaside:
http://lists.squeakfoundation.org/pipermail/seaside/2010-January/022458.html
http://lists.squeakfoundation.org/pipermail/seaside/2010-February/022485.html

Currently if you create an default pier instance with:
   PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named:
'pier')

..Scriptaculous libraries (if present) are added in PRPierFrame
class>>configureApplication:

Perhaps we should allow either JQuery or Scripaculous to be specified for
this default implementation, or at least add the JQuery libraries (if
present), if the Scriptaculous libraries are absent.

Thoughts?

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

From renggli at gmail.com  Tue Feb  2 08:08:18 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 2 Feb 2010 08:08:18 +0100
Subject: JQuery search widget
In-Reply-To: <3a06f76f1002011414n7df4931cg84bce3832605e46f@mail.gmail.com>
References: <3a06f76f1002011414n7df4931cg84bce3832605e46f@mail.gmail.com>
Message-ID: <67628d691002012308x892c5c0hd38246a6eea3c788@mail.gmail.com>

> I've created a PRJQuerySearchWidget as a plug in replacement for the
> existing PRAjaxSearchWidget. It uses the new Seaside JQuery autocomplete
> widget, which Lukas has recently added. I implemented it as I'm using other
> JQuery widgets on my page and didn't want to be without autocomplete search
> AND I haven't found a satisfactory way to mix scriptaculous and jquery
> widgets on the same page.

Pay attention, the JQueryUI Autocompleter and the JQueryUI Buttons are
not fully integrated into Seaside yet. Also they base on unstable
Javascript code.

> I'll check it in as soon as a couple of fixes go into Seaside:
> http://lists.squeakfoundation.org/pipermail/seaside/2010-January/022458.html
> http://lists.squeakfoundation.org/pipermail/seaside/2010-February/022485.html

I will have a look at that today.

> Perhaps we should allow either JQuery or Scripaculous to be specified for
> this default implementation, or at least add the JQuery libraries (if
> present), if the Scriptaculous libraries are absent.
> Thoughts?

I think the default installation should not depend any of these large
Javascript libraries. Pier-Seaside should remain agnostic from the
library used. That's also why we rewrote the editor plugin using bare
Javascript, and not build on top of Scriptaculous.

Lukas

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

From estebanlm at gmail.com  Tue Feb  2 16:33:47 2010
From: estebanlm at gmail.com (Esteban Lorenzano)
Date: Tue, 2 Feb 2010 12:33:47 -0300
Subject: PRWidget>>#inform:
Message-ID: <hk9gkp$e5k$1@ger.gmane.org>

Hi,
Does anybody knows why PRWidget>>#inform: is an empty method?

Cheers,
Esteban




From nick.ager at gmail.com  Tue Feb  2 23:55:30 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 2 Feb 2010 22:55:30 +0000
Subject: JQuery search widget
In-Reply-To: <67628d691002012308x892c5c0hd38246a6eea3c788@mail.gmail.com>
References: <3a06f76f1002011414n7df4931cg84bce3832605e46f@mail.gmail.com>
	<67628d691002012308x892c5c0hd38246a6eea3c788@mail.gmail.com>
Message-ID: <3a06f76f1002021455o296f953et5a24ad8c2aa68d98@mail.gmail.com>

Hi Lukas,

Pay attention, the JQueryUI Autocompleter and the JQueryUI Buttons are
> not fully integrated into Seaside yet. Also they base on unstable
> Javascript code.


So do you think my PRJQuerySearchWidget should be added to Pier to provide
the JQuery counterpoint to the scriptaculous version - PRAjaxSearchWidget -
that's already the repository? Would you like to review the code first? It's
working OK for me, though I'm happy to wait for the JQuery implementation
to stabilise, if you'd prefer.

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

From renggli at gmail.com  Wed Feb  3 00:13:00 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Wed, 3 Feb 2010 00:13:00 +0100
Subject: JQuery search widget
In-Reply-To: <3a06f76f1002021455o296f953et5a24ad8c2aa68d98@mail.gmail.com>
References: <3a06f76f1002011414n7df4931cg84bce3832605e46f@mail.gmail.com> 
	<67628d691002012308x892c5c0hd38246a6eea3c788@mail.gmail.com> 
	<3a06f76f1002021455o296f953et5a24ad8c2aa68d98@mail.gmail.com>
Message-ID: <67628d691002021513w521bb91qf396ff90c68b6eb7@mail.gmail.com>

> So do you think my?PRJQuerySearchWidget should be added to Pier to provide
> the JQuery counterpoint to the scriptaculous version - PRAjaxSearchWidget -
> that's already the repository? Would you like to review the code first? It's
> working OK for me, though I'm happy to wait for the JQuery implementation
> to?stabilise, if you'd prefer.

I would prefer to remove PRAjaxSerachWidget from Pier-Seaside. It is
sort of alien, because it is the only component that depends on some
Javascript library. I guess both components could go into a plugin as
soon as JQueryUI stabilizes ... hopefully soon.

Lukas

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



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


From nickbrown at fastmail.fm  Wed Feb  3 17:00:22 2010
From: nickbrown at fastmail.fm (Nick Brown)
Date: Wed, 03 Feb 2010 16:00:22 +0000
Subject: Rendering a structure's children.
Message-ID: <1265212822.11276.1358076591@webmail.messagingengine.com>

I've been writing a couple of Pier components, let's call them
StructureA and StructureB (both subclassed from PRStructure), and each
has a corresponding view (answered by #viewComponentClass), ViewA and
ViewB (subclassed from PRDefaultView).

Now I find I want to embed a 'B' inside of an 'A', so that ViewB gets
rendered inside of ViewA.

I've added a StructureB instance as a child of the StructureA instance.

What I can't figure out is, from within ViewA>>renderContentOn:, how do
I go about getting hold of an instance of ViewB, so that I can pass it
as an arg to "html render: ... "  ?

(I could instantiate ViewB myself, but presumably I would at a minimum
have to set the context ivar to something, but I know not what.)

Or am I going about this the wrong way?

Cheers,
Nick Brown

From renggli at gmail.com  Wed Feb  3 21:30:31 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Wed, 3 Feb 2010 21:30:31 +0100
Subject: Rendering a structure's children.
In-Reply-To: <1265212822.11276.1358076591@webmail.messagingengine.com>
References: <1265212822.11276.1358076591@webmail.messagingengine.com>
Message-ID: <67628d691002031230t4e84928cmc79b016f9e32b90d@mail.gmail.com>

> I've been writing a couple of Pier components, let's call them
> StructureA and StructureB (both subclassed from PRStructure), and each
> has a corresponding view (answered by #viewComponentClass), ViewA and
> ViewB (subclassed from PRDefaultView).
>
> Now I find I want to embed a 'B' inside of an 'A', so that ViewB gets
> rendered inside of ViewA.
>
> I've added a StructureB instance as a child of the StructureA instance.
>
> What I can't figure out is, from within ViewA>>renderContentOn:, how do
> I go about getting hold of an instance of ViewB, so that I can pass it
> as an arg to "html render: ... " ??

Views do not really nest well. It probably can be done, but is
certainly tricky. What I would do is to extract the rendering code of
ViewA and ViewB to separate classes (components, renderable objects,
visitors, ...) that can then be arbitrarily composed in ViewA and B.
This is also what the blog is to display the posts in different ways.

Lukas

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


From nickbrown at fastmail.fm  Wed Feb  3 21:55:15 2010
From: nickbrown at fastmail.fm (Nick Brown)
Date: Wed, 03 Feb 2010 20:55:15 +0000
Subject: Rendering a structure's children.
In-Reply-To: <67628d691002031230t4e84928cmc79b016f9e32b90d@mail.gmail.com>
References: <1265212822.11276.1358076591@webmail.messagingengine.com>
	<67628d691002031230t4e84928cmc79b016f9e32b90d@mail.gmail.com>
Message-ID: <4B69E2B3.5060907@fastmail.fm>

On 03/02/2010 20:30, Lukas Renggli wrote:
> Views do not really nest well. It probably can be done, but is
> certainly tricky. What I would do is to extract the rendering code of
> ViewA and ViewB to separate classes (components, renderable objects,
> visitors, ...) that can then be arbitrarily composed in ViewA and B.
> This is also what the blog is to display the posts in different ways.
>
> Lukas
>
>    
OK, thanks Lukas. I'll proceed along those lines.

Cheers,
Nick Brown

From johnmci at smalltalkconsulting.com  Thu Feb  4 21:34:51 2010
From: johnmci at smalltalkconsulting.com (John M McIntosh)
Date: Thu, 4 Feb 2010 12:34:51 -0800
Subject: WAKom versus WAKomEncoded
Message-ID: <09B58FF9-47A7-43D4-92E4-E37AB2F2D2C0@smalltalkconsulting.com>

First let me assume that WAKomEncoded is what I should be starting, versus WAKom  ?

Us old Smalltalkers remember starting WAKom so in WikiServer startup that is what happens. 

I *guess* it really should be WAKomEncoded?

So what's the fall out, I mean I can stuff UTF8 chars into PRPages...  Happy Happy. 

Well not quite, I got a support email out of South Korea that the UTF8 character that was entered for the 
Page title was being mangled. In fact if they use the *wrong* character the app would hang as it's loading
from binary storage to instantiate the PRPage. 

In looking at this it turns out that because WAKom is used, the UTF8 data from the request is being passed 
as a String into PRStructure (instance var name). Later lazy initialization is used to populate title

title
	"Answer the title of the receiver, essentially the name but starting uppercase."

	^ title ifNil: [ title := self name capitalized]
	
Now here is the bad part, the capitalized runs Character>>asUppercase which actually is kinda unicode aware
so it's attempting only to deal with wide characters but since the UTF8 character is multiple bytes in a String then it mangles
the first byte to uppercase thus destroying the meaning of the UTF8 sequence.

However now if I restart with WAKomEncoded the  squeak to utf8 process then messes the UTF8 data that was 
stored in the binary data file.

So thoughts on how to fix things when I load the PRPages from storage, and what fields would need fixing are welcome
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================






From philippe.marschall at gmail.com  Thu Feb  4 22:03:29 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Thu, 4 Feb 2010 22:03:29 +0100
Subject: WAKom versus WAKomEncoded
In-Reply-To: <09B58FF9-47A7-43D4-92E4-E37AB2F2D2C0@smalltalkconsulting.com>
References: <09B58FF9-47A7-43D4-92E4-E37AB2F2D2C0@smalltalkconsulting.com>
Message-ID: <66666f211002041303x1bb1d0e9p58a864ca4b312075@mail.gmail.com>

2010/2/4 John M McIntosh <johnmci at smalltalkconsulting.com>:
> First let me assume that WAKomEncoded is what I should be starting, versus WAKom ??

We are talking about Seaside 2.8, right?
WAKom: takes the bytes (!) as sent from the client and creates a
ByteString from them without any decoding, which means a character
that is encoded in two bytes in UTF-8 will take up two Charaters with
their values being the values of the bytes
WAKomEncoded: does UTF-8 de/encoding on the input, which will create
WideStrings for non-Latin-1 strings

> Us old Smalltalkers remember starting WAKom so in WikiServer startup that is what happens.
>
> I *guess* it really should be WAKomEncoded?

Judging on your problems below: yes (assuming you're cool with WideStrings)

> So what's the fall out, I mean I can stuff UTF8 chars into PRPages... ?Happy Happy.
>
> Well not quite, I got a support email out of South Korea that the UTF8 character that was entered for the
> Page title was being mangled. In fact if they use the *wrong* character the app would hang as it's loading
> from binary storage to instantiate the PRPage.
>
> In looking at this it turns out that because WAKom is used, the UTF8 data from the request is being passed
> as a String into PRStructure (instance var name). Later lazy initialization is used to populate title
>
> title
> ? ? ? ?"Answer the title of the receiver, essentially the name but starting uppercase."
>
> ? ? ? ?^ title ifNil: [ title := self name capitalized]
>
> Now here is the bad part, the capitalized runs Character>>asUppercase which actually is kinda unicode aware
> so it's attempting only to deal with wide characters but since the UTF8 character is multiple bytes in a String then it mangles
> the first byte to uppercase thus destroying the meaning of the UTF8 sequence.

Yeah, that's expected. ;-)

> However now if I restart with WAKomEncoded the ?squeak to utf8 process then messes the UTF8 data that was
> stored in the binary data file.
>
> So thoughts on how to fix things when I load the PRPages from storage, and what fields would need fixing are welcome

Assuming you don't already have corrupted data in your image and want
to do a migration:

Option 1:
Do a utf-8 decoding on the Strings in your model and use WAKomEncoded
from that point on.

Option 2:
Hack #title method (and the other senders of #capitalized) to first do
a utf-8 decoding, then #capitalized and then utf-8 encoding. Continue
using WAKom.

Now if you already have corrupted data in your image you'll have to
clean that up. That can be tricky:
- find the potential places (senders of #capitalized, can't think of
anything else right now)
- find the actual places, eg. try to do a utf-8 decoding on each
candidate and see if you get an exception
- undo the "capitalization", if you can't replace the String with
"ERROR" or something
- chose one of the options above

Sorry for the inconvenience
Philippe


From johnmci at smalltalkconsulting.com  Thu Feb  4 22:11:29 2010
From: johnmci at smalltalkconsulting.com (John M McIntosh)
Date: Thu, 4 Feb 2010 13:11:29 -0800
Subject: WAKom versus WAKomEncoded
In-Reply-To: <66666f211002041303x1bb1d0e9p58a864ca4b312075@mail.gmail.com>
References: <09B58FF9-47A7-43D4-92E4-E37AB2F2D2C0@smalltalkconsulting.com>
	<66666f211002041303x1bb1d0e9p58a864ca4b312075@mail.gmail.com>
Message-ID: <C2E76B93-359F-4088-95C2-72953C746544@smalltalkconsulting.com>

Ok, for WikiServer 1.5.1 which I push to the app store review team last night I'm doing 
(2)  I actually run the   self name squeakToUTF8 capitalized utf8ToSqueak 

This converts the String to a utf8 widestring then capitalized, then back to String. 

There fortunately is only one usage of capitalized in Pier, so the fix was easy. 

As for the Option 1, I guess I'll have to look at all the Pier objects and see where the data comes from, then 
build a post loader that decides if the database is not UTF8 clean that it runs the UTF8 converter on all the instances
fields that are being targeted.  Once the Pier data model is saved I can mark it clean.   


On 2010-02-04, at 1:03 PM, Philippe Marschall wrote:

> Assuming you don't already have corrupted data in your image and want
> to do a migration:
> 
> Option 1:
> Do a utf-8 decoding on the Strings in your model and use WAKomEncoded
> from that point on.
> 
> Option 2:
> Hack #title method (and the other senders of #capitalized) to first do
> a utf-8 decoding, then #capitalized and then utf-8 encoding. Continue
> using WAKom.
> 
> Now if you already have corrupted data in your image you'll have to
> clean that up. That can be tricky:
> - find the potential places (senders of #capitalized, can't think of
> anything else right now)
> - find the actual places, eg. try to do a utf-8 decoding on each
> candidate and see if you get an exception
> - undo the "capitalization", if you can't replace the String with
> "ERROR" or something
> - chose one of the options above
> 
> Sorry for the inconvenience
> Philippe

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================






From philippe.marschall at gmail.com  Fri Feb  5 08:59:13 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Fri, 5 Feb 2010 08:59:13 +0100
Subject: WAKom versus WAKomEncoded
In-Reply-To: <66666f211002041303x1bb1d0e9p58a864ca4b312075@mail.gmail.com>
References: <09B58FF9-47A7-43D4-92E4-E37AB2F2D2C0@smalltalkconsulting.com>
	<66666f211002041303x1bb1d0e9p58a864ca4b312075@mail.gmail.com>
Message-ID: <66666f211002042359k1b6bf236i166f790d292ef2a9@mail.gmail.com>

2010/2/4 Philippe Marschall <philippe.marschall at gmail.com>:
> 2010/2/4 John M McIntosh <johnmci at smalltalkconsulting.com>:
>> First let me assume that WAKomEncoded is what I should be starting, versus WAKom ??
>
> We are talking about Seaside 2.8, right?
> WAKom: takes the bytes (!) as sent from the client and creates a
> ByteString from them without any decoding, which means a character
> that is encoded in two bytes in UTF-8 will take up two Charaters with
> their values being the values of the bytes
> WAKomEncoded: does UTF-8 de/encoding on the input, which will create
> WideStrings for non-Latin-1 strings
>
>> Us old Smalltalkers remember starting WAKom so in WikiServer startup that is what happens.
>>
>> I *guess* it really should be WAKomEncoded?
>
> Judging on your problems below: yes (assuming you're cool with WideStrings)
>
>> So what's the fall out, I mean I can stuff UTF8 chars into PRPages... ?Happy Happy.
>>
>> Well not quite, I got a support email out of South Korea that the UTF8 character that was entered for the
>> Page title was being mangled. In fact if they use the *wrong* character the app would hang as it's loading
>> from binary storage to instantiate the PRPage.
>>
>> In looking at this it turns out that because WAKom is used, the UTF8 data from the request is being passed
>> as a String into PRStructure (instance var name). Later lazy initialization is used to populate title
>>
>> title
>> ? ? ? ?"Answer the title of the receiver, essentially the name but starting uppercase."
>>
>> ? ? ? ?^ title ifNil: [ title := self name capitalized]
>>
>> Now here is the bad part, the capitalized runs Character>>asUppercase which actually is kinda unicode aware
>> so it's attempting only to deal with wide characters but since the UTF8 character is multiple bytes in a String then it mangles
>> the first byte to uppercase thus destroying the meaning of the UTF8 sequence.
>
> Yeah, that's expected. ;-)
>
>> However now if I restart with WAKomEncoded the ?squeak to utf8 process then messes the UTF8 data that was
>> stored in the binary data file.
>>
>> So thoughts on how to fix things when I load the PRPages from storage, and what fields would need fixing are welcome
>
> Assuming you don't already have corrupted data in your image and want
> to do a migration:
>
> Option 1:
> Do a utf-8 decoding on the Strings in your model and use WAKomEncoded
> from that point on.
>
> Option 2:
> Hack #title method (and the other senders of #capitalized) to first do
> a utf-8 decoding, then #capitalized and then utf-8 encoding. Continue
> using WAKom.

On second thought:
Option 3:
Don't the the #capitalized at all and use CSS:
text-transform: capitalize

Cheers
Philippe


From garduino at gmail.com  Fri Feb  5 22:57:06 2010
From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=)
Date: Fri, 5 Feb 2010 18:57:06 -0300
Subject: Pier2 - Look and seaside components
Message-ID: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>

Hi:

I installed (using the Metacello configuration) the Seaside 3.0 and
migrated one of my applications.

Now, playing with the new Pier 2:

1. Reading this list I managed how to configure and setup, but I can't
make it show the look of the
older version nor the possibility of change to the old Events look.
These features are not availables?

2. I want to add an own seaside component on a Pier page, but the
combo to select only show the
examples and so.....how I can add to this list my own seaside components?

Thanks.

-- 
=================================================
Germ?n S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=================================================


From jfitzell at gmail.com  Fri Feb  5 23:46:52 2010
From: jfitzell at gmail.com (Julian Fitzell)
Date: Fri, 5 Feb 2010 14:46:52 -0800
Subject: Pier2 - Look and seaside components
In-Reply-To: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
Message-ID: <4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>

On Fri, Feb 5, 2010 at 1:57 PM, Germ?n Arduino <garduino at gmail.com> wrote:
> 2. I want to add an own seaside component on a Pier page, but the
> combo to select only show the
> examples and so.....how I can add to this list my own seaside components?

Have you defined #canBeRoot on the class-side of your component to
return true? I'm assuming Pier uses that mechanism just like the
Seaside config app does... (but I could be wrong).

Julian


From garduino at gmail.com  Sat Feb  6 16:11:10 2010
From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=)
Date: Sat, 6 Feb 2010 12:11:10 -0300
Subject: Pier2 - Look and seaside components
In-Reply-To: <4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>
Message-ID: <d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>

Yes, I didn't code the #canBeRoot but I understood that not needed
anymore on Seaside 3.0, else
how may be that any WAComponent based class is shown on the config application?


And about the look and feel of the old Pier I can't find explanation
on the lists and so... :(


Cheers.
Germ?n.


2010/2/5 Julian Fitzell <jfitzell at gmail.com>:
> On Fri, Feb 5, 2010 at 1:57 PM, Germ?n Arduino <garduino at gmail.com> wrote:
>> 2. I want to add an own seaside component on a Pier page, but the
>> combo to select only show the
>> examples and so.....how I can add to this list my own seaside components?
>
> Have you defined #canBeRoot on the class-side of your component to
> return true? I'm assuming Pier uses that mechanism just like the
> Seaside config app does... (but I could be wrong).
>
> Julian
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


From renggli at gmail.com  Sat Feb  6 16:34:52 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 6 Feb 2010 16:34:52 +0100
Subject: Pier2 - Look and seaside components
In-Reply-To: <d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com> 
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com> 
	<d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>
Message-ID: <67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com>

> Yes, I didn't code the #canBeRoot but I understood that not needed
> anymore on Seaside 3.0, else
> how may be that any WAComponent based class is shown on the config application?

I cannot reproduce that problem. I get a list with all the Pier
Widgets and all the Seaside Components (see components.png).

> And about the look and feel of the old Pier I can't find explanation
> on the lists and so... :(

I do not understand this question.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: components.png
Type: image/png
Size: 63630 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100206/9faa05a7/attachment-0001.png>

From garduino at gmail.com  Sat Feb  6 23:02:43 2010
From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=)
Date: Sat, 6 Feb 2010 19:02:43 -0300
Subject: Pier2 - Look and seaside components
In-Reply-To: <67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>
	<d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>
	<67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com>
Message-ID: <d88976921002061402v59826a88t8b610e64d7526792@mail.gmail.com>

Hi Lukas:

Lets me explain better:

2010/2/6 Lukas Renggli <renggli at gmail.com>:
>> Yes, I didn't code the #canBeRoot but I understood that not needed
>> anymore on Seaside 3.0, else
>> how may be that any WAComponent based class is shown on the config application?
>
> I cannot reproduce that problem. I get a list with all the Pier
> Widgets and all the Seaside Components (see components.png).
>

I also saw this complete list, but my own components (inherited from
WAComponent are not
displayed unless I code the #canBeRoot method as Julian suggested).

This is the expected behaviour? Sorry If I'm missing things about
Seaside 3.0, but I can see on
the config app any class inherited from WAComponent, without having
#canBeRoot method.

>> And about the look and feel of the old Pier I can't find explanation
>> on the lists and so... :(
>
> I do not understand this question.
>

I means that the Pier version I was using, show an orange look and
feel that may be changed
on the main page with another that have a grey bar and orange buttons
(named Events or so).

On the new version (Pier 2) I'm not seeing that looks, that is ok?

Some doc about how to add an own look and feel to Pier?

Thanks.
Germ?n.

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


From renggli at gmail.com  Sat Feb  6 23:19:46 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 6 Feb 2010 23:19:46 +0100
Subject: Pier2 - Look and seaside components
In-Reply-To: <d88976921002061402v59826a88t8b610e64d7526792@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com> 
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com> 
	<d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com> 
	<67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com> 
	<d88976921002061402v59826a88t8b610e64d7526792@mail.gmail.com>
Message-ID: <67628d691002061419r556b5523i4469cb12f97a5028@mail.gmail.com>

>> I cannot reproduce that problem. I get a list with all the Pier
>> Widgets and all the Seaside Components (see components.png).
>
> I also saw this complete list, but my own components (inherited from
> WAComponent are not
> displayed unless I code the #canBeRoot method as Julian suggested).
>
> This is the expected behaviour? Sorry If I'm missing things about
> Seaside 3.0, but I can see on
> the config app any class inherited from WAComponent, without having
> #canBeRoot method.

Strange, in my Seaside 3.0 image I have more than 200 subclasses of
WAComponent, but only those 20 that return true from #canBeRoot are
displayed in the configuration interface. That exact same behavior was
already part of Seaside 2.8, and probably earlier versions too.

>>> And about the look and feel of the old Pier I can't find explanation
>>> on the lists and so... :(
>>
>> I do not understand this question.
>
> I means that the Pier version I was using, show an orange look and
> feel that may be changed
> on the main page with another that have a grey bar and orange buttons
> (named Events or so).
>
> On the new version (Pier 2) I'm not seeing that looks, that is ok?
>
> Some doc about how to add an own look and feel to Pier?

I think that orange look comes from Pier-Setup package. Evaluate
PRDistribution new register to get a default setup.

Lukas

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

From garduino at gmail.com  Sat Feb  6 23:43:49 2010
From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=)
Date: Sat, 6 Feb 2010 19:43:49 -0300
Subject: Pier2 - Look and seaside components
In-Reply-To: <67628d691002061419r556b5523i4469cb12f97a5028@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>
	<d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>
	<67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com>
	<d88976921002061402v59826a88t8b610e64d7526792@mail.gmail.com>
	<67628d691002061419r556b5523i4469cb12f97a5028@mail.gmail.com>
Message-ID: <d88976921002061443g2e8d3f8ftcc6023afd7ea3462@mail.gmail.com>

Hi Lukas:

2010/2/6 Lukas Renggli <renggli at gmail.com>:
>>> I cannot reproduce that problem. I get a list with all the Pier
>>> Widgets and all the Seaside Components (see components.png).
>>
>> I also saw this complete list, but my own components (inherited from
>> WAComponent are not
>> displayed unless I code the #canBeRoot method as Julian suggested).
>>
>> This is the expected behaviour? Sorry If I'm missing things about
>> Seaside 3.0, but I can see on
>> the config app any class inherited from WAComponent, without having
>> #canBeRoot method.
>
> Strange, in my Seaside 3.0 image I have more than 200 subclasses of
> WAComponent, but only those 20 that return true from #canBeRoot are
> displayed in the configuration interface. That exact same behavior was
> already part of Seaside 2.8, and probably earlier versions too.
>

I get the behaviour you comment only on the combo of Pier (when adding
a component) but on the Seaside config app any class inherited of WAComponent
is displayed....(have or not the #canBeRoot method). I'm using Pharo RC2.


>>>> And about the look and feel of the old Pier I can't find explanation
>>>> on the lists and so... :(
>>>
>>> I do not understand this question.
>>
>> I means that the Pier version I was using, show an orange look and
>> feel that may be changed
>> on the main page with another that have a grey bar and orange buttons
>> (named Events or so).
>>
>> On the new version (Pier 2) I'm not seeing that looks, that is ok?
>>
>> Some doc about how to add an own look and feel to Pier?
>
> I think that orange look comes from Pier-Setup package. Evaluate
> PRDistribution new register to get a default setup.
>

Tried this now I can change the look, but never I get the colors and buttons
of the previous versions. May be the .css are missing...?

Also, selecting the Book look I get:

MessageNotUnderstood: receiver of "named:" is nil
Your request could not be completed. An exception occurred.

Thanks by the help.

Germ?n.


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



-- 
=================================================
Germ?n S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=================================================


From garduino at gmail.com  Sun Feb  7 00:34:44 2010
From: garduino at gmail.com (=?ISO-8859-1?Q?Germ=E1n_Arduino?=)
Date: Sat, 6 Feb 2010 20:34:44 -0300
Subject: Pier2 - Look and seaside components
In-Reply-To: <d88976921002061443g2e8d3f8ftcc6023afd7ea3462@mail.gmail.com>
References: <d88976921002051357n5d530e3ama89308e5d68a8e1a@mail.gmail.com>
	<4a5dbd431002051446w6a4c6cf3g3cf1fc1b1b216633@mail.gmail.com>
	<d88976921002060711o7e263764o43d2bf60731d1e1d@mail.gmail.com>
	<67628d691002060734x647764cejbc2ee879dff8d7c0@mail.gmail.com>
	<d88976921002061402v59826a88t8b610e64d7526792@mail.gmail.com>
	<67628d691002061419r556b5523i4469cb12f97a5028@mail.gmail.com>
	<d88976921002061443g2e8d3f8ftcc6023afd7ea3462@mail.gmail.com>
Message-ID: <d88976921002061534j5f60fa03g52c3296cfbfe5a82@mail.gmail.com>

2010/2/6 Germ?n Arduino <garduino at gmail.com>:
> Hi Lukas:
>
> 2010/2/6 Lukas Renggli <renggli at gmail.com>:
>>>> I cannot reproduce that problem. I get a list with all the Pier
>>>> Widgets and all the Seaside Components (see components.png).
>>>
>>> I also saw this complete list, but my own components (inherited from
>>> WAComponent are not
>>> displayed unless I code the #canBeRoot method as Julian suggested).
>>>
>>> This is the expected behaviour? Sorry If I'm missing things about
>>> Seaside 3.0, but I can see on
>>> the config app any class inherited from WAComponent, without having
>>> #canBeRoot method.
>>
>> Strange, in my Seaside 3.0 image I have more than 200 subclasses of
>> WAComponent, but only those 20 that return true from #canBeRoot are
>> displayed in the configuration interface. That exact same behavior was
>> already part of Seaside 2.8, and probably earlier versions too.
>>
>
> I get the behaviour you comment only on the combo of Pier (when adding
> a component) but on the Seaside config app any class inherited of WAComponent
> is displayed....(have or not the #canBeRoot method). I'm using Pharo RC2.
>
>

Not, sorry, sorry, I was using a subclassification of Magritte Reports and one
of the ancestors have a registration at class level... :(

My big fault, not saw all the inherited tree.

Sorry again.







>>>>> And about the look and feel of the old Pier I can't find explanation
>>>>> on the lists and so... :(
>>>>
>>>> I do not understand this question.
>>>
>>> I means that the Pier version I was using, show an orange look and
>>> feel that may be changed
>>> on the main page with another that have a grey bar and orange buttons
>>> (named Events or so).
>>>
>>> On the new version (Pier 2) I'm not seeing that looks, that is ok?
>>>
>>> Some doc about how to add an own look and feel to Pier?
>>
>> I think that orange look comes from Pier-Setup package. Evaluate
>> PRDistribution new register to get a default setup.
>>
>
> Tried this now I can change the look, but never I get the colors and buttons
> of the previous versions. May be the .css are missing...?
>
> Also, selecting the Book look I get:
>
> MessageNotUnderstood: receiver of "named:" is nil
> Your request could not be completed. An exception occurred.
>
> Thanks by the help.
>
> Germ?n.
>

This is only the pending question then.

Cheers.
Germ?n.


From estebanlm at gmail.com  Mon Feb  8 15:05:58 2010
From: estebanlm at gmail.com (Esteban Lorenzano)
Date: Mon, 8 Feb 2010 11:05:58 -0300
Subject: pier syntax questions
Message-ID: <hkp5o5$3uf$1@ger.gmane.org>

Hi,
I want to add some attributes to a generated embeded link (an image I'm 
embedding)... for instance, I want to say something like this:

+style:'width: 500px' myImage+

is there a way to do something like this?

Cheers,
Esteban



From tudor.girba at gmail.com  Mon Feb  8 15:19:33 2010
From: tudor.girba at gmail.com (Tudor Girba)
Date: Mon, 8 Feb 2010 15:19:33 +0100
Subject: pier syntax questions
In-Reply-To: <hkp5o5$3uf$1@ger.gmane.org>
References: <hkp5o5$3uf$1@ger.gmane.org>
Message-ID: <973FD46E-132A-4F86-8361-0E0CB514449D@gmail.com>

Hi,

You can use:

+myImage|style=width: 500px+

Cheers,
Doru

On 8 Feb 2010, at 15:05, Esteban Lorenzano wrote:

> Hi,
> I want to add some attributes to a generated embeded link (an image  
> I'm embedding)... for instance, I want to say something like this:
>
> +style:'width: 500px' myImage+
>
> is there a way to do something like this?
>
> Cheers,
> Esteban
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot  
be done."


From estebanlm at gmail.com  Mon Feb  8 17:40:21 2010
From: estebanlm at gmail.com (Esteban Lorenzano)
Date: Mon, 8 Feb 2010 13:40:21 -0300
Subject: pier syntax questions
References: <hkp5o5$3uf$1@ger.gmane.org>
	<973FD46E-132A-4F86-8361-0E0CB514449D@gmail.com>
Message-ID: <hkpepk$6d1$1@ger.gmane.org>

cool, thanks!

Esteban

On 2010-02-08 11:19:33 -0300, Tudor Girba <tudor.girba at gmail.com> said:

> Hi,
> 
> You can use:
> 
> +myImage|style=width: 500px+
> 
> Cheers,
> Doru
> 
> On 8 Feb 2010, at 15:05, Esteban Lorenzano wrote:
> 
>> Hi,
>> I want to add some attributes to a generated embeded link (an image
>> I'm embedding)... for instance, I want to say something like this:
>> 
>> +style:'width: 500px' myImage+
>> 
>> is there a way to do something like this?
>> 
>> Cheers,
>> Esteban
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki




From marianopeck at gmail.com  Mon Feb  8 22:14:09 2010
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Mon, 8 Feb 2010 22:14:09 +0100
Subject: New Smalltalk-Research group
Message-ID: <a38fadc51002081314y201d7f21g30aa5a2dc3a30ce9@mail.gmail.com>

Hi folks.

We were discussing about this in the Pharo mailing list but the idea is for
all Smalltalkers. I am not sure if this will work, but it is worth to try it
as I don't have anything to loose.

We were thinking to have a place, an environment and hopefully a community,
where we can freely discuss about Smalltalk papers or OO in general. All
smalltalkers of all flavors can join, discuss, tell their experiences and
thoughts, share and learn.

The main purpose about that list is:

- be able to FREELY discuss about papers about Smalltalk or OO in general. I
say freely because maybe someone gives an opinion of a paper that the person
who wrote it is also in this place. We are all professional and I think we
can discuss with respect.
- LEARN.

Other uses:
- Don't reinvent the wheel. Maybe I wanted to do something and I read that
XXX person did YYY. So, I can look at it.
- Be aware of what other people is doing, working, writing and learning.
- Have different opinions of a certain topic / paper.
- A little step to join all the Smalltalk community in one place. We can
meet people, join forces, etc.
- Help in the preparation, ANN, collaborate, etc in Workshops, conferences,
and so on.
- Ask for help on review. Several times someone has several papers to review
for a certain conference. This can be a place to ask for that help.
- Publish papers that were rejected from someone. How many times some papers
where rejected but do you still read it and find it useful ?
- Educate people and being educated.
- Share latex template, commands, or tricks related to smalltalk code for
example.
- Discuss about research in general.
- Ask for a certain topic. Suppose I want to start to work in XXX topic, I
can ask to see if someone knows related papers or work.
- others

In two words: DISCUSS AND LEARN.

FAQ:

1) Which is the address?
http://groups.google.com/group/smalltalk-research

2) Do I need to be "Researcher" to join ?
Not necessary. You may just be interested.

3) Is there a Nabble interface?
Yes: http://n4.nabble.com/Smalltalk-Research-f1473466.html

Now, please what I would appreciate is if you can help me to you distribute
(I am not in Gemstone, Cincom or GNU for example) this ANN. It would be cool
to create a community.  I know there are a lot of Smalltalk researchers that
doesn't have time to follow the active smalltalks lists. If you can send
private mails to them would be fantastic!

Thank you very much.

Mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100208/3e31323e/attachment.html>

From matthias.berth at googlemail.com  Tue Feb  9 01:47:10 2010
From: matthias.berth at googlemail.com (Matthias Berth)
Date: Tue, 9 Feb 2010 01:47:10 +0100
Subject: In-place editing of pier pages, anyone?
Message-ID: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>

Hi,

I'm trying to do in-place editing on Pier pages (or rather I want to
use pier wiki markup in user comments in my app). Has anyone done
something like that before? I am using the seaside 3.0 one-click
image.

I can do in-place editing with 'normal' text, the problem with pier
seems to be that the text that you want to edit (pier's wiki source)
is different from what you have on the displayed page (the HTML
rendering of the wiki text).

The Scriptaculous documentation mentions this:

http://wiki.github.com/madrobby/scriptaculous/ajax-inplaceeditor
How to edit server side formatted text (formatted with eg. textile)

Format the text on the server when the initial page is rendered. Add a
new server side action that returns the unformatted text in the
reponse and specify the load Text URL? option as a URL to this action.
The control will load the text from the server instead of using the
text on the page. The action that receives the updated text should
save it and return the formatted text as an HTML snippet in the
reponse.

The relevant option in Scriptaculous Ajax.InPlaceEditor is

loadTextURL  	 V1.5  	 null  	 Will cause the text to be loaded from
the server (useful if your text is actually textile and formatted on
the server)

Now I see nothing related to this in SUInPlaceEditor.


Do you have any hints how this combination of in-place editing and
wiki markup could be done?

Thanks in advance

Matthias

From matthias.berth at googlemail.com  Tue Feb  9 01:52:14 2010
From: matthias.berth at googlemail.com (Matthias Berth)
Date: Tue, 9 Feb 2010 01:52:14 +0100
Subject: Where does the raw wiki markup on a pier page come from?
Message-ID: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>

Hi,


I know that a PRDocument is a tree of objects that correspond to the
structure of a HTML document, such as paragraphs (PRParagraph), list
items (PRListItem) etc. When I edit an existing wiki page, where does
the raw wiki text come from? Is it re-generated from the objects
inside the PRDocument (how?), or is it kept somewhere in a separate
place?

Thanks

Matthias

From keith_hodges at yahoo.co.uk  Tue Feb  9 02:45:06 2010
From: keith_hodges at yahoo.co.uk (keith)
Date: Tue, 9 Feb 2010 01:45:06 +0000
Subject: Where does the raw wiki markup on a pier page come from?
In-Reply-To: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>
References: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>
Message-ID: <3DE59449-87DC-4FA6-8D86-9747B17DC8AA@yahoo.co.uk>


On 9 Feb 2010, at 00:52, Matthias Berth wrote:

> Hi,
>
>
> I know that a PRDocument is a tree of objects that correspond to the
> structure of a HTML document, such as paragraphs (PRParagraph), list
> items (PRListItem) etc. When I edit an existing wiki page, where does
> the raw wiki text come from? Is it re-generated from the objects
> inside the PRDocument (how?),

yes, it is regenerated by the PRWikiWriter visitor which traverses the  
object tree.

Keith



From renggli at gmail.com  Tue Feb  9 08:54:52 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 9 Feb 2010 08:54:52 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>
Message-ID: <67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com>

If I understood you correctly you want something along Stackoverflow,
where you see the resulting HTML along when you type.

I think the in-place editor does not help much in this case. What you
want to do is a normal text area that triggers an AJAX action that
serializes the textarea and that updates a preview with the freshly
rendered HTML.

Lukas

On 9 February 2010 01:47, Matthias Berth <matthias.berth at googlemail.com> wrote:
> Hi,
>
> I'm trying to do in-place editing on Pier pages (or rather I want to
> use pier wiki markup in user comments in my app). Has anyone done
> something like that before? I am using the seaside 3.0 one-click
> image.
>
> I can do in-place editing with 'normal' text, the problem with pier
> seems to be that the text that you want to edit (pier's wiki source)
> is different from what you have on the displayed page (the HTML
> rendering of the wiki text).
>
> The Scriptaculous documentation mentions this:
>
> http://wiki.github.com/madrobby/scriptaculous/ajax-inplaceeditor
> How to edit server side formatted text (formatted with eg. textile)
>
> Format the text on the server when the initial page is rendered. Add a
> new server side action that returns the unformatted text in the
> reponse and specify the load Text URL? option as a URL to this action.
> The control will load the text from the server instead of using the
> text on the page. The action that receives the updated text should
> save it and return the formatted text as an HTML snippet in the
> reponse.
>
> The relevant option in Scriptaculous Ajax.InPlaceEditor is
>
> loadTextURL ? ? ?V1.5 ? ?null ? ?Will cause the text to be loaded from
> the server (useful if your text is actually textile and formatted on
> the server)
>
> Now I see nothing related to this in SUInPlaceEditor.
>
>
> Do you have any hints how this combination of in-place editing and
> wiki markup could be done?
>
> Thanks in advance
>
> Matthias
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From renggli at gmail.com  Tue Feb  9 08:59:57 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 9 Feb 2010 08:59:57 +0100
Subject: Where does the raw wiki markup on a pier page come from?
In-Reply-To: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>
References: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>
Message-ID: <67628d691002082359n21aeee77o22fb3d81a8260671@mail.gmail.com>

> I know that a PRDocument is a tree of objects that correspond to the
> structure of a HTML document, such as paragraphs (PRParagraph), list
> items (PRListItem) etc. When I edit an existing wiki page, where does
> the raw wiki text come from? Is it re-generated from the objects
> inside the PRDocument (how?), or is it kept somewhere in a separate
> place?

  PRDocumentParser parse: aString
     gives you a document tree from a wiki string.

and the opposite

  PRWikiWriter write: aDocument
     gives you the wiki string.

  PRTextWriter write: aDocument
     gives you a plain text string.

  PRViewRenderer new start: aDocument in: aComponent on: html
     renders a document as HTML

  ...

and there are some other output formats, such as LaTeX, RSS, ...

Lukas

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

From matthias.berth at googlemail.com  Tue Feb  9 09:30:54 2010
From: matthias.berth at googlemail.com (Matthias Berth)
Date: Tue, 9 Feb 2010 09:30:54 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>
	<67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com>
Message-ID: <9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com>

On Tue, Feb 9, 2010 at 8:54 AM, Lukas Renggli <renggli at gmail.com> wrote:
> If I understood you correctly you want something along Stackoverflow,
> where you see the resulting HTML along when you type.

No,  I want the simpler thing: I click on some text and get a text
area where I can edit the wiki source. No live preview necessary.

Thanks

Matthias

> I think the in-place editor does not help much in this case. What you
> want to do is a normal text area that triggers an AJAX action that
> serializes the textarea and that updates a preview with the freshly
> rendered HTML.
>
> Lukas
>
> On 9 February 2010 01:47, Matthias Berth <matthias.berth at googlemail.com> wrote:
>> Hi,
>>
>> I'm trying to do in-place editing on Pier pages (or rather I want to
>> use pier wiki markup in user comments in my app). Has anyone done
>> something like that before? I am using the seaside 3.0 one-click
>> image.
>>
>> I can do in-place editing with 'normal' text, the problem with pier
>> seems to be that the text that you want to edit (pier's wiki source)
>> is different from what you have on the displayed page (the HTML
>> rendering of the wiki text).
>>
>> The Scriptaculous documentation mentions this:
>>
>> http://wiki.github.com/madrobby/scriptaculous/ajax-inplaceeditor
>> How to edit server side formatted text (formatted with eg. textile)
>>
>> Format the text on the server when the initial page is rendered. Add a
>> new server side action that returns the unformatted text in the
>> reponse and specify the load Text URL? option as a URL to this action.
>> The control will load the text from the server instead of using the
>> text on the page. The action that receives the updated text should
>> save it and return the formatted text as an HTML snippet in the
>> reponse.
>>
>> The relevant option in Scriptaculous Ajax.InPlaceEditor is
>>
>> loadTextURL ? ? ?V1.5 ? ?null ? ?Will cause the text to be loaded from
>> the server (useful if your text is actually textile and formatted on
>> the server)
>>
>> Now I see nothing related to this in SUInPlaceEditor.
>>
>>
>> Do you have any hints how this combination of in-place editing and
>> wiki markup could be done?
>>
>> Thanks in advance
>>
>> Matthias
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


From matthias.berth at googlemail.com  Tue Feb  9 09:32:41 2010
From: matthias.berth at googlemail.com (Matthias Berth)
Date: Tue, 9 Feb 2010 09:32:41 +0100
Subject: Where does the raw wiki markup on a pier page come from?
In-Reply-To: <67628d691002082359n21aeee77o22fb3d81a8260671@mail.gmail.com>
References: <9aa6ae271002081652i75773a46i9b4ea1b9d7df0e71@mail.gmail.com>
	<67628d691002082359n21aeee77o22fb3d81a8260671@mail.gmail.com>
Message-ID: <9aa6ae271002090032q3bed3b58y53a097904f3a47ac@mail.gmail.com>

Ah, thanks a lot, Lukas and Keith.

Matthias

On Tue, Feb 9, 2010 at 8:59 AM, Lukas Renggli <renggli at gmail.com> wrote:
>> I know that a PRDocument is a tree of objects that correspond to the
>> structure of a HTML document, such as paragraphs (PRParagraph), list
>> items (PRListItem) etc. When I edit an existing wiki page, where does
>> the raw wiki text come from? Is it re-generated from the objects
>> inside the PRDocument (how?), or is it kept somewhere in a separate
>> place?
>
> ?PRDocumentParser parse: aString
> ? ? gives you a document tree from a wiki string.
>
> and the opposite
>
> ?PRWikiWriter write: aDocument
> ? ? gives you the wiki string.
>
> ?PRTextWriter write: aDocument
> ? ? gives you a plain text string.
>
> ?PRViewRenderer new start: aDocument in: aComponent on: html
> ? ? renders a document as HTML
>
> ?...
>
> and there are some other output formats, such as LaTeX, RSS, ...
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


From renggli at gmail.com  Tue Feb  9 09:44:44 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 9 Feb 2010 09:44:44 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com> 
	<67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com> 
	<9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com>
Message-ID: <67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com>

>> If I understood you correctly you want something along Stackoverflow,
>> where you see the resulting HTML along when you type.
>
> No, ?I want the simpler thing: I click on some text and get a text
> area where I can edit the wiki source. No live preview necessary.

That's far more complicated.

Have a look at PRHaloRenderer in Pier-EditorEnh this is somehow
similar. This adds a halo around each structure as it is rendered to
HTML. In your case you would do something similar but render an
in-place editor around each paragraph.

Some versions of Pier back in 2005 or 2006 had such a functionality.
You might get some ideas looking at that code, although I don't
remember if it every worked. Directly editing the document AST becomes
quite tricky if you go beyond simple paragraphs.

Lukas

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


From cdrick65 at gmail.com  Tue Feb  9 10:21:06 2010
From: cdrick65 at gmail.com (=?UTF-8?B?Q8OpZHJpY2sgQsOpbGVy?=)
Date: Tue, 9 Feb 2010 10:21:06 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>
	<67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com>
	<9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com>
	<67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com>
Message-ID: <a49ceb01002090121g23456fbet88c786fdb240a514@mail.gmail.com>

What do you think of CKEditor ?
Do you think we could integrate it (it's open source and integrable with
JQuery - but I think there's a license for commercial apps)?


2010/2/9 Lukas Renggli <renggli at gmail.com>

> >> If I understood you correctly you want something along Stackoverflow,
> >> where you see the resulting HTML along when you type.
> >
> > No,  I want the simpler thing: I click on some text and get a text
> > area where I can edit the wiki source. No live preview necessary.
>
> That's far more complicated.
>
> Have a look at PRHaloRenderer in Pier-EditorEnh this is somehow
> similar. This adds a halo around each structure as it is rendered to
> HTML. In your case you would do something similar but render an
> in-place editor around each paragraph.
>
> Some versions of Pier back in 2005 or 2006 had such a functionality.
> You might get some ideas looking at that code, although I don't
> remember if it every worked. Directly editing the document AST becomes
> quite tricky if you go beyond simple paragraphs.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
C?drick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100209/d32bf2c4/attachment.html>

From renggli at gmail.com  Tue Feb  9 10:32:54 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 9 Feb 2010 10:32:54 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <a49ceb01002090121g23456fbet88c786fdb240a514@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com> 
	<67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com> 
	<9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com> 
	<67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com> 
	<a49ceb01002090121g23456fbet88c786fdb240a514@mail.gmail.com>
Message-ID: <67628d691002090132r5f4608cdi3de78ecd7bfc3940@mail.gmail.com>

> What do you think of CKEditor ?

CKEditor is a HTML editor. Unless you write a HTML parser you will
loose the ability to render to different output formats, to keep
references between pages and automatically rewrite them as things move
around, etc.

Lukas

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

From norbert at hartl.name  Tue Feb  9 11:22:40 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Tue, 9 Feb 2010 11:22:40 +0100
Subject: Web Interface and XML binding
Message-ID: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>

Hi,

at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.

Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.

I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.

thanks  in advance,

Norbert




From jvdsandt at gmail.com  Tue Feb  9 11:59:22 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Tue, 9 Feb 2010 11:59:22 +0100
Subject: Web Interface and XML binding
In-Reply-To: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
Message-ID: <50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>

Hello Norbert,

I have developed some code to serialize object to XML and visa versa using
their Magritte descriptions. It is not completely finished yet but for
standard scenario's it works fine.

Here an example where an instance of MAXMLTestPerson is serialized to XML.

   <MAXMLTestPerson>
        <name>Bill Gates</name>
        <address>
            <MAXMLTestAddress>
                <city>Amsterdam</city>
                <street>Mainstreet</street>
            </MAXMLTestAddress>
        </address>
        <birthDate>1966-10-20</birthDate>
    </MAXMLTestPerson>

It can be de-serialized using MAXMLParser:

    MAXMLParser parse: self personWithAddressXML readStream.

The serialization process can be customized. I still have to add proper
error handling. My intention was to add it to the Magritte add-ons
repository when the error handling was fully working. If you want I can add
it sooner so you can have a look.

Jan.




On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name> wrote:

> Hi,
>
> at the moment I'm thinking about a new project. The project will need a Web
> API to communicate with an iphone. To me it is quite obvious to implement
> the API part as a request handler. But when it comes to generation of e.g.
> XML I'm not sure what is the best way to do.
>
> Sure, the seaside way to do it is to create my own canvas and every object
> needs to draw itself onto the canvas. But then I have magritte and a lot
> could be done automatically. Using xpath in the descriptions I could use
> Pastell to deserialize objects. To produce the output there could be a
> similar way. This would be some kind of XML binding then.
>
> I wanted to ask if there is anything already available that could help me
> on my way or if there dedicated ideas how to solve this in seaside.
>
> thanks  in advance,
>
> Norbert
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
Jan van de Sandt
gsm: +31 (0)6 3039 5998
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100209/ae1ed79d/attachment.html>

From matthias.berth at googlemail.com  Tue Feb  9 12:05:02 2010
From: matthias.berth at googlemail.com (Matthias Berth)
Date: Tue, 9 Feb 2010 12:05:02 +0100
Subject: In-place editing of pier pages, anyone?
In-Reply-To: <67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com>
References: <9aa6ae271002081647o3976466eh4c2fbbf6fce57744@mail.gmail.com>
	<67628d691002082354o1d78fa0cu4aeb36d5d01fa06b@mail.gmail.com>
	<9aa6ae271002090030x3fc79251we4e378344df09005@mail.gmail.com>
	<67628d691002090044q40e8ea5fpa623fdd179483862@mail.gmail.com>
Message-ID: <9aa6ae271002090305j4c67fe81i78f8cabf5a8d6954@mail.gmail.com>

Ah, OK. I still want something simpler: just edit the whole document
in-place. Anyway, the basic problem (from my point of view) remains:
the text you want to edit is different from the text that is already
in the html.

Using Scriptaculous Ajax.InPlaceEditor's loadTextURL would allow pier
to put the wiki-source text into the textarea when the in-place editor
starts.

I'll keep looking around the source then, maybe I find something
similar in the Scriptaculous seaside package :)

Matthias

On Tue, Feb 9, 2010 at 9:44 AM, Lukas Renggli <renggli at gmail.com> wrote:
>>> If I understood you correctly you want something along Stackoverflow,
>>> where you see the resulting HTML along when you type.
>>
>> No, ?I want the simpler thing: I click on some text and get a text
>> area where I can edit the wiki source. No live preview necessary.
>
> That's far more complicated.
>
> Have a look at PRHaloRenderer in Pier-EditorEnh this is somehow
> similar. This adds a halo around each structure as it is rendered to
> HTML. In your case you would do something similar but render an
> in-place editor around each paragraph.
>
> Some versions of Pier back in 2005 or 2006 had such a functionality.
> You might get some ideas looking at that code, although I don't
> remember if it every worked. Directly editing the document AST becomes
> quite tricky if you go beyond simple paragraphs.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>


From norbert at hartl.name  Tue Feb  9 12:23:20 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Tue, 9 Feb 2010 12:23:20 +0100
Subject: Web Interface and XML binding
In-Reply-To: <50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
Message-ID: <4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>

Hi Jan,

that looks great. I really would like to have a look at the code. May I have a few questions upfront:

- I assume MAXMLTestPerson is the class name of the instance you are serializing. I would avoid exposing an implementation detail to the outside world. Do you use that information on parse time? I would expect that you know how to parse the top level object (by service context etc.). Regarding references the detail about what to parse is in MAReferenceDescription you are using for e.g. the address. If this is all right you could go with <Person> and <Address>. This would make it possible to parse the XML with a subclass of e.g. MAXMLTestPerson

- You inlined the address instance into the person. Is this exchangable? I'm not sure I'll go for REST but if yes then I would like to do it by reference. Let's say <adress id="http://my.service.srv/address/12345"> ...

- What do you do with the date field in birthday? Is this a fixed format or do you specify this over magritte?

Thanks,

Norbert


On 09.02.2010, at 11:59, Jan van de Sandt wrote:

> Hello Norbert,
> 
> I have developed some code to serialize object to XML and visa versa using their Magritte descriptions. It is not completely finished yet but for standard scenario's it works fine. 
> 
> Here an example where an instance of MAXMLTestPerson is serialized to XML.
> 
>    <MAXMLTestPerson>
>         <name>Bill Gates</name>
>         <address>
>             <MAXMLTestAddress>
>                 <city>Amsterdam</city>
>                 <street>Mainstreet</street>
>             </MAXMLTestAddress>
>         </address>
>         <birthDate>1966-10-20</birthDate>
>     </MAXMLTestPerson>
> 
> It can be de-serialized using MAXMLParser:
> 
>     MAXMLParser parse: self personWithAddressXML readStream.
> 
> The serialization process can be customized. I still have to add proper error handling. My intention was to add it to the Magritte add-ons repository when the error handling was fully working. If you want I can add it sooner so you can have a look.
> 
> Jan.
> 
> 
> 
> 
> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name> wrote:
> Hi,
> 
> at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
> 
> Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
> 
> I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.
> 
> thanks  in advance,
> 
> Norbert
> 
> 
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> _______________________________________________
> 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/20100209/a90e72c6/attachment.html>

From jvdsandt at gmail.com  Tue Feb  9 13:15:21 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Tue, 9 Feb 2010 13:15:21 +0100
Subject: Web Interface and XML binding
In-Reply-To: <4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
	<4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
Message-ID: <50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>

Hello,

On Tue, Feb 9, 2010 at 12:23 PM, Norbert Hartl <norbert at hartl.name> wrote:

> Hi Jan,
>
> that looks great. I really would like to have a look at the code. May I
> have a few questions upfront:
>
> Ok, I will upload the code this evening.


> - I assume MAXMLTestPerson is the class name of the instance you are
> serializing. I would avoid exposing an implementation detail to the outside
> world. Do you use that information on parse time? I would expect that you
> know how to parse the top level object (by service context etc.). Regarding
> references the detail about what to parse is in MAReferenceDescription you
> are using for e.g. the address. If this is all right you could go with
> <Person> and <Address>. This would make it possible to parse the XML with a
> subclass of e.g. MAXMLTestPerson
>
> Yes MAXMLTestPerson is the class name. This was the easiest way to
serialize instances of classes that have the same Magritte description. This
behaviour is implemented in MAXMLWriter, a subclass of MAWriter. It can be
easily customized by creating your own subclass of this visitor.



> - You inlined the address instance into the person. Is this exchangable?
> I'm not sure I'll go for REST but if yes then I would like to do it by
> reference. Let's say <adress id="http://my.service.srv/address/12345"> ...
>
> The current implementation inlines the first occurrence of an object and
adds an id attribute. If an object occurs multiple times than a reference to
the id is inlined. For example:

Smalltalk:

personWithFriendsCycle

    | bill john carl |

    bill := MAXMLTestPerson new
        name: 'Bill';
        yourself.
    john := MAXMLTestPerson new
        name: 'John';
        yourself.
    carl := MAXMLTestPerson new
        name: 'Carl';
        friends: (OrderedCollection with: bill with: john);
        yourself.

    bill friends: (OrderedCollection with: john with: carl).
    john friends: (OrderedCollection with: bill with: carl).

    ^carl

XML:

<MAXMLTestPerson id="1">
    <name>Carl</name>
    <friends>
        <OrderedCollection>
            <MAXMLTestPerson id="2">
                <name>Bill</name>
                <friends>
                    <OrderedCollection>
                        <MAXMLTestPerson id="3">
                            <name>John</name>
                            <friends>
                                <OrderedCollection>
                                    <MAXMLTestPerson ref="2"/>
                                    <MAXMLTestPerson ref="1"/>
                                </OrderedCollection>
                            </friends>
                        </MAXMLTestPerson>
                        <MAXMLTestPerson ref="1"/>
                    </OrderedCollection>
                </friends>
            </MAXMLTestPerson>
            <MAXMLTestPerson ref="3"/>
        </OrderedCollection>
    </friends>
</MAXMLTestPerson>



> - What do you do with the date field in birthday? Is this a fixed format or
> do you specify this over magritte?
>
> This is also implemented using the MAXMLWriter visitor and can be easily
customized per description class.

Jan.


>
>
> On 09.02.2010, at 11:59, Jan van de Sandt wrote:
>
> Hello Norbert,
>
> I have developed some code to serialize object to XML and visa versa using
> their Magritte descriptions. It is not completely finished yet but for
> standard scenario's it works fine.
>
> Here an example where an instance of MAXMLTestPerson is serialized to XML.
>
>    <MAXMLTestPerson>
>         <name>Bill Gates</name>
>         <address>
>             <MAXMLTestAddress>
>                 <city>Amsterdam</city>
>                 <street>Mainstreet</street>
>             </MAXMLTestAddress>
>         </address>
>         <birthDate>1966-10-20</birthDate>
>     </MAXMLTestPerson>
>
> It can be de-serialized using MAXMLParser:
>
>     MAXMLParser parse: self personWithAddressXML readStream.
>
> The serialization process can be customized. I still have to add proper
> error handling. My intention was to add it to the Magritte add-ons
> repository when the error handling was fully working. If you want I can add
> it sooner so you can have a look.
>
> Jan.
>
>
>
>
> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name> wrote:
>
>> Hi,
>>
>> at the moment I'm thinking about a new project. The project will need a
>> Web API to communicate with an iphone. To me it is quite obvious to
>> implement the API part as a request handler. But when it comes to generation
>> of e.g. XML I'm not sure what is the best way to do.
>>
>> Sure, the seaside way to do it is to create my own canvas and every object
>> needs to draw itself onto the canvas. But then I have magritte and a lot
>> could be done automatically. Using xpath in the descriptions I could use
>> Pastell to deserialize objects. To produce the output there could be a
>> similar way. This would be some kind of XML binding then.
>>
>> I wanted to ask if there is anything already available that could help me
>> on my way or if there dedicated ideas how to solve this in seaside.
>>
>> thanks  in advance,
>>
>> Norbert
>>
>>
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> _______________________________________________
> 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
>



-- 
Jan van de Sandt
gsm: +31 (0)6 3039 5998
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100209/23c16995/attachment.html>

From jvdsandt at gmail.com  Tue Feb  9 20:00:05 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Tue, 9 Feb 2010 20:00:05 +0100
Subject: Web Interface and XML binding
In-Reply-To: <50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
	<4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
	<50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>
Message-ID: <50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>

Hello,

I have uploaded the package Magritte-XMLSupport to
http://source.lukas-renggli.ch/magritteaddons. The package has a dependency
on XMLParser from http://www.squeaksource.com/XMLSupport.

I have developed this package using "Magritte for Seaside 3.0". But is also
works with "Magritte for Seaside 2.8", in this case you need to add the the
Grease package from the Seaside 3.0 as an extra dependency.

Have a look at the unit tests to see how to use the package. Note that the
API is not yet stable. I use it to export and import my Magritte domain
objects in a readable format. I'm now working on export & import
functionality for Pier using this library, this could lead to
changes/improvements in the package API.

Jan.



On Tue, Feb 9, 2010 at 1:15 PM, Jan van de Sandt <jvdsandt at gmail.com> wrote:

> Hello,
>
> On Tue, Feb 9, 2010 at 12:23 PM, Norbert Hartl <norbert at hartl.name> wrote:
>
>> Hi Jan,
>>
>> that looks great. I really would like to have a look at the code. May I
>> have a few questions upfront:
>>
>> Ok, I will upload the code this evening.
>
>
>> - I assume MAXMLTestPerson is the class name of the instance you are
>> serializing. I would avoid exposing an implementation detail to the outside
>> world. Do you use that information on parse time? I would expect that you
>> know how to parse the top level object (by service context etc.). Regarding
>> references the detail about what to parse is in MAReferenceDescription you
>> are using for e.g. the address. If this is all right you could go with
>> <Person> and <Address>. This would make it possible to parse the XML with a
>> subclass of e.g. MAXMLTestPerson
>>
>> Yes MAXMLTestPerson is the class name. This was the easiest way to
> serialize instances of classes that have the same Magritte description. This
> behaviour is implemented in MAXMLWriter, a subclass of MAWriter. It can be
> easily customized by creating your own subclass of this visitor.
>
>
>
>> - You inlined the address instance into the person. Is this exchangable?
>> I'm not sure I'll go for REST but if yes then I would like to do it by
>> reference. Let's say <adress id="http://my.service.srv/address/12345">
>> ...
>>
>> The current implementation inlines the first occurrence of an object and
> adds an id attribute. If an object occurs multiple times than a reference to
> the id is inlined. For example:
>
> Smalltalk:
>
> personWithFriendsCycle
>
>     | bill john carl |
>
>     bill := MAXMLTestPerson new
>         name: 'Bill';
>         yourself.
>     john := MAXMLTestPerson new
>         name: 'John';
>         yourself.
>     carl := MAXMLTestPerson new
>         name: 'Carl';
>         friends: (OrderedCollection with: bill with: john);
>         yourself.
>
>     bill friends: (OrderedCollection with: john with: carl).
>     john friends: (OrderedCollection with: bill with: carl).
>
>     ^carl
>
> XML:
>
> <MAXMLTestPerson id="1">
>     <name>Carl</name>
>     <friends>
>         <OrderedCollection>
>             <MAXMLTestPerson id="2">
>                 <name>Bill</name>
>                 <friends>
>                     <OrderedCollection>
>                         <MAXMLTestPerson id="3">
>                             <name>John</name>
>                             <friends>
>                                 <OrderedCollection>
>                                     <MAXMLTestPerson ref="2"/>
>                                     <MAXMLTestPerson ref="1"/>
>                                 </OrderedCollection>
>                             </friends>
>                         </MAXMLTestPerson>
>                         <MAXMLTestPerson ref="1"/>
>                     </OrderedCollection>
>                 </friends>
>             </MAXMLTestPerson>
>             <MAXMLTestPerson ref="3"/>
>         </OrderedCollection>
>     </friends>
> </MAXMLTestPerson>
>
>
>
>> - What do you do with the date field in birthday? Is this a fixed format
>> or do you specify this over magritte?
>>
>> This is also implemented using the MAXMLWriter visitor and can be easily
> customized per description class.
>
> Jan.
>
>
>>
>>
>> On 09.02.2010, at 11:59, Jan van de Sandt wrote:
>>
>> Hello Norbert,
>>
>> I have developed some code to serialize object to XML and visa versa using
>> their Magritte descriptions. It is not completely finished yet but for
>> standard scenario's it works fine.
>>
>> Here an example where an instance of MAXMLTestPerson is serialized to XML.
>>
>>    <MAXMLTestPerson>
>>         <name>Bill Gates</name>
>>         <address>
>>             <MAXMLTestAddress>
>>                 <city>Amsterdam</city>
>>                 <street>Mainstreet</street>
>>             </MAXMLTestAddress>
>>         </address>
>>         <birthDate>1966-10-20</birthDate>
>>     </MAXMLTestPerson>
>>
>> It can be de-serialized using MAXMLParser:
>>
>>     MAXMLParser parse: self personWithAddressXML readStream.
>>
>> The serialization process can be customized. I still have to add proper
>> error handling. My intention was to add it to the Magritte add-ons
>> repository when the error handling was fully working. If you want I can add
>> it sooner so you can have a look.
>>
>> Jan.
>>
>>
>>
>>
>> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name>wrote:
>>
>>> Hi,
>>>
>>> at the moment I'm thinking about a new project. The project will need a
>>> Web API to communicate with an iphone. To me it is quite obvious to
>>> implement the API part as a request handler. But when it comes to generation
>>> of e.g. XML I'm not sure what is the best way to do.
>>>
>>> Sure, the seaside way to do it is to create my own canvas and every
>>> object needs to draw itself onto the canvas. But then I have magritte and a
>>> lot could be done automatically. Using xpath in the descriptions I could use
>>> Pastell to deserialize objects. To produce the output there could be a
>>> similar way. This would be some kind of XML binding then.
>>>
>>> I wanted to ask if there is anything already available that could help me
>>> on my way or if there dedicated ideas how to solve this in seaside.
>>>
>>> thanks  in advance,
>>>
>>> Norbert
>>>
>>>
>>>
>>> _______________________________________________
>>> Magritte, Pier and Related Tools ...
>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>
>>
>>
>>
>> --
>> Jan van de Sandt
>> gsm: +31 (0)6 3039 5998
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
>



-- 
Jan van de Sandt
gsm: +31 (0)6 3039 5998
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100209/15376a74/attachment-0001.html>

From norbert at hartl.name  Tue Feb  9 21:08:12 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Tue, 9 Feb 2010 21:08:12 +0100
Subject: Web Interface and XML binding
In-Reply-To: <50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
	<4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
	<50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>
	<50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>
Message-ID: <369FA6E5-DB48-4C69-9FDC-FB8A229AF339@hartl.name>

Hi,

On 09.02.2010, at 20:00, Jan van de Sandt wrote:

> Hello,
> 
> I have uploaded the package Magritte-XMLSupport to http://source.lukas-renggli.ch/magritteaddons. The package has a dependency on XMLParser from http://www.squeaksource.com/XMLSupport.
> 
thanks for sharing. I'll have some time this weekend to investigate this. 

> I have developed this package using "Magritte for Seaside 3.0". But is also works with "Magritte for Seaside 2.8", in this case you need to add the the Grease package from the Seaside 3.0 as an extra dependency.
> 
I don't think there is that much of a difference. I will see. As long as the pier2 for gemstone isn't ready I'll go with magritte for 2.8. Afterwards I'll port it. Than I'll see.

> Have a look at the unit tests to see how to use the package. Note that the API is not yet stable. I use it to export and import my Magritte domain objects in a readable format. I'm now working on export & import functionality for Pier using this library, this could lead to changes/improvements in the package API.
> 
Fair enough. I will start to plug it onto a HTTP Interface. I'll send you a status when I have something running.

Btw. how do you do object resolving? Or better do you assume that always the whole object graph is pulled in or is there an update of existing objects? 

Norbert

> Jan.
> 
> 
> 
> On Tue, Feb 9, 2010 at 1:15 PM, Jan van de Sandt <jvdsandt at gmail.com> wrote:
> Hello,
> 
> On Tue, Feb 9, 2010 at 12:23 PM, Norbert Hartl <norbert at hartl.name> wrote:
> Hi Jan,
> 
> that looks great. I really would like to have a look at the code. May I have a few questions upfront:
> 
> Ok, I will upload the code this evening.
>  
> - I assume MAXMLTestPerson is the class name of the instance you are serializing. I would avoid exposing an implementation detail to the outside world. Do you use that information on parse time? I would expect that you know how to parse the top level object (by service context etc.). Regarding references the detail about what to parse is in MAReferenceDescription you are using for e.g. the address. If this is all right you could go with <Person> and <Address>. This would make it possible to parse the XML with a subclass of e.g. MAXMLTestPerson
> 
> Yes MAXMLTestPerson is the class name. This was the easiest way to serialize instances of classes that have the same Magritte description. This behaviour is implemented in MAXMLWriter, a subclass of MAWriter. It can be easily customized by creating your own subclass of this visitor.
> 
>  
> - You inlined the address instance into the person. Is this exchangable? I'm not sure I'll go for REST but if yes then I would like to do it by reference. Let's say <adress id="http://my.service.srv/address/12345"> ...
> 
> The current implementation inlines the first occurrence of an object and adds an id attribute. If an object occurs multiple times than a reference to the id is inlined. For example:
> 
> Smalltalk:
> 
> personWithFriendsCycle
> 
>     | bill john carl |
>     
>     bill := MAXMLTestPerson new
>         name: 'Bill';
>         yourself.
>     john := MAXMLTestPerson new
>         name: 'John';
>         yourself.
>     carl := MAXMLTestPerson new
>         name: 'Carl';
>         friends: (OrderedCollection with: bill with: john);
>         yourself.
>         
>     bill friends: (OrderedCollection with: john with: carl).
>     john friends: (OrderedCollection with: bill with: carl).
>     
>     ^carl
> 
> XML:
> 
> <MAXMLTestPerson id="1">
>     <name>Carl</name>
>     <friends>
>         <OrderedCollection>
>             <MAXMLTestPerson id="2">
>                 <name>Bill</name>
>                 <friends>
>                     <OrderedCollection>
>                         <MAXMLTestPerson id="3">
>                             <name>John</name>
>                             <friends>
>                                 <OrderedCollection>
>                                     <MAXMLTestPerson ref="2"/>
>                                     <MAXMLTestPerson ref="1"/>
>                                 </OrderedCollection>
>                             </friends>
>                         </MAXMLTestPerson>
>                         <MAXMLTestPerson ref="1"/>
>                     </OrderedCollection>
>                 </friends>
>             </MAXMLTestPerson>
>             <MAXMLTestPerson ref="3"/>
>         </OrderedCollection>
>     </friends>
> </MAXMLTestPerson>
> 
>  
> - What do you do with the date field in birthday? Is this a fixed format or do you specify this over magritte?
> 
> This is also implemented using the MAXMLWriter visitor and can be easily customized per description class.
> 
> Jan.
>  
> 
> 
> On 09.02.2010, at 11:59, Jan van de Sandt wrote:
> 
>> Hello Norbert,
>> 
>> I have developed some code to serialize object to XML and visa versa using their Magritte descriptions. It is not completely finished yet but for standard scenario's it works fine. 
>> 
>> Here an example where an instance of MAXMLTestPerson is serialized to XML.
>> 
>>    <MAXMLTestPerson>
>>         <name>Bill Gates</name>
>>         <address>
>>             <MAXMLTestAddress>
>>                 <city>Amsterdam</city>
>>                 <street>Mainstreet</street>
>>             </MAXMLTestAddress>
>>         </address>
>>         <birthDate>1966-10-20</birthDate>
>>     </MAXMLTestPerson>
>> 
>> It can be de-serialized using MAXMLParser:
>> 
>>     MAXMLParser parse: self personWithAddressXML readStream.
>> 
>> The serialization process can be customized. I still have to add proper error handling. My intention was to add it to the Magritte add-ons repository when the error handling was fully working. If you want I can add it sooner so you can have a look.
>> 
>> Jan.
>> 
>> 
>> 
>> 
>> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name> wrote:
>> Hi,
>> 
>> at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
>> 
>> Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
>> 
>> I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.
>> 
>> thanks  in advance,
>> 
>> Norbert
>> 
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
>> 
>> 
>> -- 
>> Jan van de Sandt
>> gsm: +31 (0)6 3039 5998
>> _______________________________________________
>> 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
> 
> 
> 
> -- 
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> 
> 
> 
> -- 
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> _______________________________________________
> 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/20100209/46bc0c7d/attachment.html>

From philippe.marschall at gmail.com  Tue Feb  9 21:43:22 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Tue, 9 Feb 2010 21:43:22 +0100
Subject: Web Interface and XML binding
In-Reply-To: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
Message-ID: <66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>

2010/2/9 Norbert Hartl <norbert at hartl.name>:
> Hi,
>
> at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
>
> Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
>
> I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.

The AudioScrobbler [1] and TopFeeder [2] projects uses Magritte for
XML to object binding.

 [1] http://source.lukas-renggli.ch/audioscrobbler.html
 [2] http://source.lukas-renggli.ch/topfeeder.html

Cheers
Philippe


From norbert at hartl.name  Thu Feb 11 21:25:58 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 11 Feb 2010 21:25:58 +0100
Subject: Web Interface and XML binding
In-Reply-To: <50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
	<4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
	<50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>
	<50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>
Message-ID: <8E10E16B-21BF-4163-881B-109A7A73B197@hartl.name>

Hi,

thanks for uploading. I had some time to take a look. Do you know SIXX?

http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html

This is also about complete object graph serialization/deserialization and has been ported to most of the smalltalk dialects. I does not depend on magritte. I used this to transfer my objects from my squeak deployment into the new gemstone deployment. I can imagine that you can offer another level of control of the serialization/deserialization process. But I'm looking for something much more simple.

thanks very much,

Norbert


On 09.02.2010, at 20:00, Jan van de Sandt wrote:

> Hello,
> 
> I have uploaded the package Magritte-XMLSupport to http://source.lukas-renggli.ch/magritteaddons. The package has a dependency on XMLParser from http://www.squeaksource.com/XMLSupport.
> 
> I have developed this package using "Magritte for Seaside 3.0". But is also works with "Magritte for Seaside 2.8", in this case you need to add the the Grease package from the Seaside 3.0 as an extra dependency.
> 
> Have a look at the unit tests to see how to use the package. Note that the API is not yet stable. I use it to export and import my Magritte domain objects in a readable format. I'm now working on export & import functionality for Pier using this library, this could lead to changes/improvements in the package API.
> 
> Jan.
> 
> 
> 
> On Tue, Feb 9, 2010 at 1:15 PM, Jan van de Sandt <jvdsandt at gmail.com> wrote:
> Hello,
> 
> On Tue, Feb 9, 2010 at 12:23 PM, Norbert Hartl <norbert at hartl.name> wrote:
> Hi Jan,
> 
> that looks great. I really would like to have a look at the code. May I have a few questions upfront:
> 
> Ok, I will upload the code this evening.
>  
> - I assume MAXMLTestPerson is the class name of the instance you are serializing. I would avoid exposing an implementation detail to the outside world. Do you use that information on parse time? I would expect that you know how to parse the top level object (by service context etc.). Regarding references the detail about what to parse is in MAReferenceDescription you are using for e.g. the address. If this is all right you could go with <Person> and <Address>. This would make it possible to parse the XML with a subclass of e.g. MAXMLTestPerson
> 
> Yes MAXMLTestPerson is the class name. This was the easiest way to serialize instances of classes that have the same Magritte description. This behaviour is implemented in MAXMLWriter, a subclass of MAWriter. It can be easily customized by creating your own subclass of this visitor.
> 
>  
> - You inlined the address instance into the person. Is this exchangable? I'm not sure I'll go for REST but if yes then I would like to do it by reference. Let's say <adress id="http://my.service.srv/address/12345"> ...
> 
> The current implementation inlines the first occurrence of an object and adds an id attribute. If an object occurs multiple times than a reference to the id is inlined. For example:
> 
> Smalltalk:
> 
> personWithFriendsCycle
> 
>     | bill john carl |
>     
>     bill := MAXMLTestPerson new
>         name: 'Bill';
>         yourself.
>     john := MAXMLTestPerson new
>         name: 'John';
>         yourself.
>     carl := MAXMLTestPerson new
>         name: 'Carl';
>         friends: (OrderedCollection with: bill with: john);
>         yourself.
>         
>     bill friends: (OrderedCollection with: john with: carl).
>     john friends: (OrderedCollection with: bill with: carl).
>     
>     ^carl
> 
> XML:
> 
> <MAXMLTestPerson id="1">
>     <name>Carl</name>
>     <friends>
>         <OrderedCollection>
>             <MAXMLTestPerson id="2">
>                 <name>Bill</name>
>                 <friends>
>                     <OrderedCollection>
>                         <MAXMLTestPerson id="3">
>                             <name>John</name>
>                             <friends>
>                                 <OrderedCollection>
>                                     <MAXMLTestPerson ref="2"/>
>                                     <MAXMLTestPerson ref="1"/>
>                                 </OrderedCollection>
>                             </friends>
>                         </MAXMLTestPerson>
>                         <MAXMLTestPerson ref="1"/>
>                     </OrderedCollection>
>                 </friends>
>             </MAXMLTestPerson>
>             <MAXMLTestPerson ref="3"/>
>         </OrderedCollection>
>     </friends>
> </MAXMLTestPerson>
> 
>  
> - What do you do with the date field in birthday? Is this a fixed format or do you specify this over magritte?
> 
> This is also implemented using the MAXMLWriter visitor and can be easily customized per description class.
> 
> Jan.
>  
> 
> 
> On 09.02.2010, at 11:59, Jan van de Sandt wrote:
> 
>> Hello Norbert,
>> 
>> I have developed some code to serialize object to XML and visa versa using their Magritte descriptions. It is not completely finished yet but for standard scenario's it works fine. 
>> 
>> Here an example where an instance of MAXMLTestPerson is serialized to XML.
>> 
>>    <MAXMLTestPerson>
>>         <name>Bill Gates</name>
>>         <address>
>>             <MAXMLTestAddress>
>>                 <city>Amsterdam</city>
>>                 <street>Mainstreet</street>
>>             </MAXMLTestAddress>
>>         </address>
>>         <birthDate>1966-10-20</birthDate>
>>     </MAXMLTestPerson>
>> 
>> It can be de-serialized using MAXMLParser:
>> 
>>     MAXMLParser parse: self personWithAddressXML readStream.
>> 
>> The serialization process can be customized. I still have to add proper error handling. My intention was to add it to the Magritte add-ons repository when the error handling was fully working. If you want I can add it sooner so you can have a look.
>> 
>> Jan.
>> 
>> 
>> 
>> 
>> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name> wrote:
>> Hi,
>> 
>> at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
>> 
>> Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
>> 
>> I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.
>> 
>> thanks  in advance,
>> 
>> Norbert
>> 
>> 
>> 
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> 
>> 
>> 
>> -- 
>> Jan van de Sandt
>> gsm: +31 (0)6 3039 5998
>> _______________________________________________
>> 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
> 
> 
> 
> -- 
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> 
> 
> 
> -- 
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> _______________________________________________
> 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/20100211/8f43ae39/attachment-0001.html>

From norbert at hartl.name  Thu Feb 11 21:30:08 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Thu, 11 Feb 2010 21:30:08 +0100
Subject: Web Interface and XML binding
In-Reply-To: <66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
Message-ID: <4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>

Hi Philippe,

that is close to what I was searching for. I was glad to see that top feeder is using the audioscrobbler code (only a few tweaks). Did I miss somehting or is this just the parsing of the format?

The code does not seem to be audioscrobbler dependent. Is there a chance to rip the XML part out of the package? Adding a writer to this code base would already lead to a descent magritte XML handling as far as I could see from a short peek.

Norbert

On 09.02.2010, at 21:43, Philippe Marschall wrote:

> 2010/2/9 Norbert Hartl <norbert at hartl.name>:
>> Hi,
>> 
>> at the moment I'm thinking about a new project. The project will need a Web API to communicate with an iphone. To me it is quite obvious to implement the API part as a request handler. But when it comes to generation of e.g. XML I'm not sure what is the best way to do.
>> 
>> Sure, the seaside way to do it is to create my own canvas and every object needs to draw itself onto the canvas. But then I have magritte and a lot could be done automatically. Using xpath in the descriptions I could use Pastell to deserialize objects. To produce the output there could be a similar way. This would be some kind of XML binding then.
>> 
>> I wanted to ask if there is anything already available that could help me on my way or if there dedicated ideas how to solve this in seaside.
> 
> The AudioScrobbler [1] and TopFeeder [2] projects uses Magritte for
> XML to object binding.
> 
> [1] http://source.lukas-renggli.ch/audioscrobbler.html
> [2] http://source.lukas-renggli.ch/topfeeder.html
> 
> Cheers
> Philippe
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From jvdsandt at gmail.com  Thu Feb 11 21:42:18 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Thu, 11 Feb 2010 21:42:18 +0100
Subject: Web Interface and XML binding
In-Reply-To: <8E10E16B-21BF-4163-881B-109A7A73B197@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<50d1d2c91002090259y3be8f810m1dd0150419e52c68@mail.gmail.com>
	<4372D4B5-21A3-42F2-B91D-3BDD4BDC8618@hartl.name>
	<50d1d2c91002090415j186e1337o8916ce08ceef3f3f@mail.gmail.com>
	<50d1d2c91002091100r36d153c4r826da80e949976d@mail.gmail.com>
	<8E10E16B-21BF-4163-881B-109A7A73B197@hartl.name>
Message-ID: <50d1d2c91002111242v1ac8fe7and9033cd578fbbc70@mail.gmail.com>

Hi,

Yes, I know SIXX. I think it is well suited for serializing and
de-serializing objects to XML. But the resulting XML will look a bit strange
to non-smalltalkers, so for exchanging information with other platforms it
is not the best solution I think.

I am now incorporating some of the ideas from XStream (
http://xstream.codehaus.org/) into the MAXMLSupport library. This will offer
a simple facade for the conversion and this facade can be used to configure
the conversion to and from XML. For example by specifying aliases for
elements.

Jan.

On Thu, Feb 11, 2010 at 9:25 PM, Norbert Hartl <norbert at hartl.name> wrote:

> Hi,
>
> thanks for uploading. I had some time to take a look. Do you know SIXX?
>
> http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html<http://www.mars.dti.ne.jp/%7Eumejava/smalltalk/sixx/index.html>
>
> This is also about complete object graph serialization/deserialization and
> has been ported to most of the smalltalk dialects. I does not depend on
> magritte. I used this to transfer my objects from my squeak deployment into
> the new gemstone deployment. I can imagine that you can offer another level
> of control of the serialization/deserialization process. But I'm looking for
> something much more simple.
>
> thanks very much,
>
> Norbert
>
>
> On 09.02.2010, at 20:00, Jan van de Sandt wrote:
>
> Hello,
>
> I have uploaded the package Magritte-XMLSupport to
> http://source.lukas-renggli.ch/magritteaddons. The package has a
> dependency on XMLParser from http://www.squeaksource.com/XMLSupport.
>
> I have developed this package using "Magritte for Seaside 3.0". But is also
> works with "Magritte for Seaside 2.8", in this case you need to add the the
> Grease package from the Seaside 3.0 as an extra dependency.
>
> Have a look at the unit tests to see how to use the package. Note that the
> API is not yet stable. I use it to export and import my Magritte domain
> objects in a readable format. I'm now working on export & import
> functionality for Pier using this library, this could lead to
> changes/improvements in the package API.
>
> Jan.
>
>
>
> On Tue, Feb 9, 2010 at 1:15 PM, Jan van de Sandt <jvdsandt at gmail.com>wrote:
>
>> Hello,
>>
>> On Tue, Feb 9, 2010 at 12:23 PM, Norbert Hartl <norbert at hartl.name>wrote:
>>
>>> Hi Jan,
>>>
>>> that looks great. I really would like to have a look at the code. May I
>>> have a few questions upfront:
>>>
>>> Ok, I will upload the code this evening.
>>
>>
>>> - I assume MAXMLTestPerson is the class name of the instance you are
>>> serializing. I would avoid exposing an implementation detail to the outside
>>> world. Do you use that information on parse time? I would expect that you
>>> know how to parse the top level object (by service context etc.). Regarding
>>> references the detail about what to parse is in MAReferenceDescription you
>>> are using for e.g. the address. If this is all right you could go with
>>> <Person> and <Address>. This would make it possible to parse the XML with a
>>> subclass of e.g. MAXMLTestPerson
>>>
>>> Yes MAXMLTestPerson is the class name. This was the easiest way to
>> serialize instances of classes that have the same Magritte description. This
>> behaviour is implemented in MAXMLWriter, a subclass of MAWriter. It can be
>> easily customized by creating your own subclass of this visitor.
>>
>>
>>
>>> - You inlined the address instance into the person. Is this exchangable?
>>> I'm not sure I'll go for REST but if yes then I would like to do it by
>>> reference. Let's say <adress id="http://my.service.srv/address/12345">
>>> ...
>>>
>>> The current implementation inlines the first occurrence of an object and
>> adds an id attribute. If an object occurs multiple times than a reference to
>> the id is inlined. For example:
>>
>> Smalltalk:
>>
>> personWithFriendsCycle
>>
>>     | bill john carl |
>>
>>     bill := MAXMLTestPerson new
>>         name: 'Bill';
>>         yourself.
>>     john := MAXMLTestPerson new
>>         name: 'John';
>>         yourself.
>>     carl := MAXMLTestPerson new
>>         name: 'Carl';
>>         friends: (OrderedCollection with: bill with: john);
>>         yourself.
>>
>>     bill friends: (OrderedCollection with: john with: carl).
>>     john friends: (OrderedCollection with: bill with: carl).
>>
>>     ^carl
>>
>> XML:
>>
>> <MAXMLTestPerson id="1">
>>     <name>Carl</name>
>>     <friends>
>>         <OrderedCollection>
>>             <MAXMLTestPerson id="2">
>>                 <name>Bill</name>
>>                 <friends>
>>                     <OrderedCollection>
>>                         <MAXMLTestPerson id="3">
>>                             <name>John</name>
>>                             <friends>
>>                                 <OrderedCollection>
>>                                     <MAXMLTestPerson ref="2"/>
>>                                     <MAXMLTestPerson ref="1"/>
>>                                 </OrderedCollection>
>>                             </friends>
>>                         </MAXMLTestPerson>
>>                         <MAXMLTestPerson ref="1"/>
>>                     </OrderedCollection>
>>                 </friends>
>>             </MAXMLTestPerson>
>>             <MAXMLTestPerson ref="3"/>
>>         </OrderedCollection>
>>     </friends>
>> </MAXMLTestPerson>
>>
>>
>>
>>> - What do you do with the date field in birthday? Is this a fixed format
>>> or do you specify this over magritte?
>>>
>>> This is also implemented using the MAXMLWriter visitor and can be easily
>> customized per description class.
>>
>> Jan.
>>
>>
>>>
>>>
>>> On 09.02.2010, at 11:59, Jan van de Sandt wrote:
>>>
>>> Hello Norbert,
>>>
>>> I have developed some code to serialize object to XML and visa versa
>>> using their Magritte descriptions. It is not completely finished yet but for
>>> standard scenario's it works fine.
>>>
>>> Here an example where an instance of MAXMLTestPerson is serialized to
>>> XML.
>>>
>>>    <MAXMLTestPerson>
>>>         <name>Bill Gates</name>
>>>         <address>
>>>             <MAXMLTestAddress>
>>>                 <city>Amsterdam</city>
>>>                 <street>Mainstreet</street>
>>>             </MAXMLTestAddress>
>>>         </address>
>>>         <birthDate>1966-10-20</birthDate>
>>>     </MAXMLTestPerson>
>>>
>>> It can be de-serialized using MAXMLParser:
>>>
>>>     MAXMLParser parse: self personWithAddressXML readStream.
>>>
>>> The serialization process can be customized. I still have to add proper
>>> error handling. My intention was to add it to the Magritte add-ons
>>> repository when the error handling was fully working. If you want I can add
>>> it sooner so you can have a look.
>>>
>>> Jan.
>>>
>>>
>>>
>>>
>>> On Tue, Feb 9, 2010 at 11:22 AM, Norbert Hartl <norbert at hartl.name>wrote:
>>>
>>>> Hi,
>>>>
>>>> at the moment I'm thinking about a new project. The project will need a
>>>> Web API to communicate with an iphone. To me it is quite obvious to
>>>> implement the API part as a request handler. But when it comes to generation
>>>> of e.g. XML I'm not sure what is the best way to do.
>>>>
>>>> Sure, the seaside way to do it is to create my own canvas and every
>>>> object needs to draw itself onto the canvas. But then I have magritte and a
>>>> lot could be done automatically. Using xpath in the descriptions I could use
>>>> Pastell to deserialize objects. To produce the output there could be a
>>>> similar way. This would be some kind of XML binding then.
>>>>
>>>> I wanted to ask if there is anything already available that could help
>>>> me on my way or if there dedicated ideas how to solve this in seaside.
>>>>
>>>> thanks  in advance,
>>>>
>>>> Norbert
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Magritte, Pier and Related Tools ...
>>>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>>>
>>>
>>>
>>>
>>> --
>>> Jan van de Sandt
>>> gsm: +31 (0)6 3039 5998
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Jan van de Sandt
>> gsm: +31 (0)6 3039 5998
>>
>
>
>
> --
> Jan van de Sandt
> gsm: +31 (0)6 3039 5998
> _______________________________________________
> 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
>



-- 
Jan van de Sandt
gsm: +31 (0)6 3039 5998
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100211/6933590e/attachment.html>

From philippe.marschall at gmail.com  Thu Feb 11 22:05:35 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Thu, 11 Feb 2010 22:05:35 +0100
Subject: Web Interface and XML binding
In-Reply-To: <4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
	<4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
Message-ID: <66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>

2010/2/11 Norbert Hartl <norbert at hartl.name>:
> Hi Philippe,
>
> that is close to what I was searching for. I was glad to see that top feeder is using the audioscrobbler code (only a few tweaks). Did I miss somehting or is this just the parsing of the format?

Right, it's just parsing.

> The code does not seem to be audioscrobbler dependent. Is there a chance to rip the XML part out of the package?

Sure, it's simply a matter of doing it. Just move the -Magritte
package and ASObject.

> Adding a writer to this code base would already lead to a descent magritte XML handling as far as I could see from a short peek.

Right you'd just have to do the inverse and create nodes.

Cheers
Philippe

From norbert at hartl.name  Fri Feb 12 00:36:16 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 12 Feb 2010 00:36:16 +0100
Subject: Parameterized magritte components again
Message-ID: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>

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

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

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


enables me to specify

+mycomponent|child=title+

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

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

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

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

Any hints appreciated as always. 

Norbert

From jborden23 at mac.com  Fri Feb 12 05:24:46 2010
From: jborden23 at mac.com (John Borden)
Date: Thu, 11 Feb 2010 22:24:46 -0600
Subject: Line graph in Pier
Message-ID: <50945694673694095358476928859792380735-Webmail@me.com>

Pier Group,
For a small site, I have a list of the item costs and the day:

|! Date | ! Cost of Item 1 |! Cost of Item 2
| 2010-Feb-11 | $2.50 | $2.25 
| 2010-Feb-10 | $2.45 | $2.23 
| 2010-Feb-9 | $2.41 | $2.26 
| 2010-Feb-8 | $2.52 | $2.24 

My customer is perfectly happy entering the text each day, however he wants a line graph showing the rise and fall of the two items for the last few weeks.  Is there anything in pier which will display this sort of data?  Maybe something in Squeak/Pharo which would generate a morph, that can be turned into a jpg?

Thanks,
John

From renggli at gmail.com  Fri Feb 12 07:52:32 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 12 Feb 2010 07:52:32 +0100
Subject: Line graph in Pier
In-Reply-To: <50945694673694095358476928859792380735-Webmail@me.com>
References: <50945694673694095358476928859792380735-Webmail@me.com>
Message-ID: <67628d691002112252t548bf57ap3e9674fa97228b5b@mail.gmail.com>

You might want to have a look at Google Chart:

    http://www.lukas-renggli.ch/blog/pairprogramming

Lukas

On 12 February 2010 05:24, John Borden <jborden23 at mac.com> wrote:
> Pier Group,
> For a small site, I have a list of the item costs and the day:
>
> |! Date | ! Cost of Item 1 |! Cost of Item 2
> | 2010-Feb-11 | $2.50 | $2.25
> | 2010-Feb-10 | $2.45 | $2.23
> | 2010-Feb-9 | $2.41 | $2.26
> | 2010-Feb-8 | $2.52 | $2.24
>
> My customer is perfectly happy entering the text each day, however he wants a line graph showing the rise and fall of the two items for the last few weeks. ?Is there anything in pier which will display this sort of data? ?Maybe something in Squeak/Pharo which would generate a morph, that can be turned into a jpg?
>
> Thanks,
> John
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From renggli at gmail.com  Fri Feb 12 08:10:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 12 Feb 2010 08:10:11 +0100
Subject: Parameterized magritte components again
In-Reply-To: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>
Message-ID: <67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com>

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

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

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

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

Lukas

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


From norbert at hartl.name  Fri Feb 12 10:59:07 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 12 Feb 2010 10:59:07 +0100
Subject: Parameterized magritte components again
In-Reply-To: <67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>
	<67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com>
Message-ID: <D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>


On 12.02.2010, at 08:10, Lukas Renggli wrote:

>> +mycomponent|child=title+
>> +mycomponent|child=abstract+
>> 
>> are not the same on one page. Is there a way to specify that I want to use the identical component if the embedded label (mycomponent) is the same? May I did something wrong but I always get different objects and it does make sense to me . Would be nice if this would bedoable. Otherwise I guess I need to do my own component-per-page-cache.
> 
> Pier creates one component instance per link that reefers to the component.
> 
> I don't think it makes sense to have the same instance of a component
> twice on a page. You wouldn't do that in Seaside either. The behavior
> in basically undefined since the two components share their state. In
> you example it would depend on the initialization order whether the
> parameter child would be set to 'title' or 'abstract'.
> 
Well, I don't think there are many use cases where it makes sense, that is right. Usually there is no point in sharing a component. In my case it is different. If you assume that the parameters are functioning as configurators of the component then you are right. The behaviour would dependent on the order of the links. 
If you understand the parameters as filters than there is no danger here. My idea is to have something like this

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

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

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

MyMAComponent>>childDescription
	^ childDescription

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

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

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

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

Norbert

From renggli at gmail.com  Fri Feb 12 11:03:25 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 12 Feb 2010 11:03:25 +0100
Subject: Parameterized magritte components again
In-Reply-To: <D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name> 
	<67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com> 
	<D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>
Message-ID: <67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com>

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

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

Lukas

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

From norbert at hartl.name  Fri Feb 12 11:07:13 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 12 Feb 2010 11:07:13 +0100
Subject: Parameterized magritte components again
In-Reply-To: <67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>
	<67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com>
	<D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>
	<67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com>
Message-ID: <E4548049-45DE-4C02-A19D-3226D6465289@hartl.name>

Ok, next stop: value links

thanks,

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

>> Well, there is state because I'm after forms.
> 
> I guess you could still look after value links, together with a
> component that is partially rendered using this technique.
> 
> Lukas
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From norbert at hartl.name  Fri Feb 12 13:38:12 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 12 Feb 2010 13:38:12 +0100
Subject: Parameterized magritte components again
In-Reply-To: <67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name>
	<67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com>
	<D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>
	<67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com>
Message-ID: <BA4A78AC-1FFB-43BD-A14E-4BB40B7DE054@hartl.name>

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

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

thanks in advance,

Norbert

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

>> Well, there is state because I'm after forms.
> 
> I guess you could still look after value links, together with a
> component that is partially rendered using this technique.
> 
> Lukas
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From renggli at gmail.com  Fri Feb 12 14:00:53 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 12 Feb 2010 14:00:53 +0100
Subject: Parameterized magritte components again
In-Reply-To: <BA4A78AC-1FFB-43BD-A14E-4BB40B7DE054@hartl.name>
References: <E9493671-39E2-4CF3-BA4B-9AB1E451A740@hartl.name> 
	<67628d691002112310m6ef3a53etfdc7a98c7c1a77d6@mail.gmail.com> 
	<D4DC5B18-00C4-41F0-96F8-683A4F1AD3E2@hartl.name>
	<67628d691002120203h3d065f78p7e1b08e9b4032325@mail.gmail.com> 
	<BA4A78AC-1FFB-43BD-A14E-4BB40B7DE054@hartl.name>
Message-ID: <67628d691002120500y2b693a7fx1252a28db41b230c@mail.gmail.com>

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

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

Lukas

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


From stephan at stack.nl  Fri Feb 12 20:46:40 2010
From: stephan at stack.nl (Stephan Eggermont)
Date: Fri, 12 Feb 2010 20:46:40 +0100
Subject: Line graph in Pier
In-Reply-To: <50945694673694095358476928859792380735-Webmail@me.com>
References: <50945694673694095358476928859792380735-Webmail@me.com>
Message-ID: <FD7FE5DD-3381-4927-A28A-EE312E47BDAB@stack.nl>


On Feb 12, 2010, at 5:24 AM, John Borden wrote:
> My customer is perfectly happy entering the text each day, however  
> he wants a line graph showing the rise and fall of the two items for  
> the last few weeks.  Is there anything in pier which will display  
> this sort of data?  Maybe something in Squeak/Pharo which would  
> generate a morph, that can be turned into a jpg?

You might want to use Raphael (on squeaksource) to generate the images.

Stephan

From norbert at hartl.name  Mon Feb 15 12:26:17 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 15 Feb 2010 12:26:17 +0100
Subject: Web Interface and XML binding
In-Reply-To: <66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
	<4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
	<66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
Message-ID: <3A753AFD-7A28-44C2-8719-E3FBB0F8CF0D@hartl.name>


On 11.02.2010, at 22:05, Philippe Marschall wrote:

> 2010/2/11 Norbert Hartl <norbert at hartl.name>:
>> Hi Philippe,
>> 
>> that is close to what I was searching for. I was glad to see that top feeder is using the audioscrobbler code (only a few tweaks). Did I miss somehting or is this just the parsing of the format?
> 
> Right, it's just parsing.
> 
>> The code does not seem to be audioscrobbler dependent. Is there a chance to rip the XML part out of the package?
> 
> Sure, it's simply a matter of doing it. Just move the -Magritte
> package and ASObject.
> 
I started to factor the code out into a package Magritte-XMLBinding. I divided ASObject into MXObject and ASObject containing the XML stuff and its subclass ASObject containing the network stuff (curl etc.). I moved all magritte stuff to the the Magritte-XMLBinding package. I try to reconstruct a working Audioscrobbler and Topfeeder package. Maybe you are willing to use the new package then. 

I've found a reference to NAUrlDescription which I don't have. Package install didn't complain and I don't know where I can get it. 
 
>> Adding a writer to this code base would already lead to a descent magritte XML handling as far as I could see from a short peek.
> 
> Right you'd just have to do the inverse and create nodes.
> 
Yes, this should be straight forward. This will be step 2 after the refactoring.

Norbert

From norbert at hartl.name  Mon Feb 15 12:40:31 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 15 Feb 2010 12:40:31 +0100
Subject: Web Interface and XML binding
In-Reply-To: <66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
	<4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
	<66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
Message-ID: <E201F04A-04C0-47EB-BB7B-65DE5646E452@hartl.name>

One other thing. I use a pier-1.2 image. The Magritte contained in here seems pretty new. All of the class methods that AudioScrobbler uses seem to have vanished. Is there a compat package that gives to class side methods and calls the instance methods instead?  Otherwise I'll have a look and I could upgrade AudioScrobbler to a newer magritte.

Norbert

On 11.02.2010, at 22:05, Philippe Marschall wrote:

> 2010/2/11 Norbert Hartl <norbert at hartl.name>:
>> Hi Philippe,
>> 
>> that is close to what I was searching for. I was glad to see that top feeder is using the audioscrobbler code (only a few tweaks). Did I miss somehting or is this just the parsing of the format?
> 
> Right, it's just parsing.
> 
>> The code does not seem to be audioscrobbler dependent. Is there a chance to rip the XML part out of the package?
> 
> Sure, it's simply a matter of doing it. Just move the -Magritte
> package and ASObject.
> 
>> Adding a writer to this code base would already lead to a descent magritte XML handling as far as I could see from a short peek.
> 
> Right you'd just have to do the inverse and create nodes.
> 
> Cheers
> Philippe
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



From philippe.marschall at gmail.com  Mon Feb 15 21:18:12 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Mon, 15 Feb 2010 21:18:12 +0100
Subject: Web Interface and XML binding
In-Reply-To: <3A753AFD-7A28-44C2-8719-E3FBB0F8CF0D@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
	<4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
	<66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
	<3A753AFD-7A28-44C2-8719-E3FBB0F8CF0D@hartl.name>
Message-ID: <66666f211002151218n66a8d068v7dca1fa9185da0@mail.gmail.com>

2010/2/15 Norbert Hartl <norbert at hartl.name>:
>
> On 11.02.2010, at 22:05, Philippe Marschall wrote:
>
>> 2010/2/11 Norbert Hartl <norbert at hartl.name>:
>>> Hi Philippe,
>>>
>>> that is close to what I was searching for. I was glad to see that top feeder is using the audioscrobbler code (only a few tweaks). Did I miss somehting or is this just the parsing of the format?
>>
>> Right, it's just parsing.
>>
>>> The code does not seem to be audioscrobbler dependent. Is there a chance to rip the XML part out of the package?
>>
>> Sure, it's simply a matter of doing it. Just move the -Magritte
>> package and ASObject.
>>
> I started to factor the code out into a package Magritte-XMLBinding. I divided ASObject into MXObject and ASObject containing the XML stuff and its subclass ASObject containing the network stuff (curl etc.). I moved all magritte stuff to the the Magritte-XMLBinding package. I try to reconstruct a working Audioscrobbler and Topfeeder package. Maybe you are willing to use the new package then.

Sure, absolutely.

> I've found a reference to NAUrlDescription which I don't have. Package install didn't complain and I don't know where I can get it.

NetworkAddress from:
http://source.lukas-renggli.ch/magritteaddons.html

Cheers
Philippe


From philippe.marschall at gmail.com  Mon Feb 15 21:20:19 2010
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Mon, 15 Feb 2010 21:20:19 +0100
Subject: Web Interface and XML binding
In-Reply-To: <E201F04A-04C0-47EB-BB7B-65DE5646E452@hartl.name>
References: <CAABB845-B4A5-4407-BE34-A892FE920D00@hartl.name>
	<66666f211002091243k541516a5r22254e8aedab7e8f@mail.gmail.com>
	<4B46422F-235E-4B24-B388-B18A47DD1071@hartl.name>
	<66666f211002111305r229528dbg8211ab10f5606c5@mail.gmail.com>
	<E201F04A-04C0-47EB-BB7B-65DE5646E452@hartl.name>
Message-ID: <66666f211002151220n266dcf75l77da1176dbb7f241@mail.gmail.com>

2010/2/15 Norbert Hartl <norbert at hartl.name>:
> One other thing. I use a pier-1.2 image. The Magritte contained in here seems pretty new. All of the class methods that AudioScrobbler uses seem to have vanished. Is there a compat package that gives to class side methods and calls the instance methods instead? ?Otherwise I'll have a look and I could upgrade AudioScrobbler to a newer magritte.

Yepp, just adding a #new and a cascade. But I can do that as well.

Cheers
Philippe


From norbert at hartl.name  Tue Feb 16 00:41:43 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Tue, 16 Feb 2010 00:41:43 +0100
Subject: Magritte XMLBinding
Message-ID: <F96CD1E8-9C25-4316-906A-9E1DDA09EBE8@hartl.name>

Hi,

I touched some packages I want you to take notice of. I found the code in AudioScrobbler useful that does xml binding stuff with magritte. I decided to rip it out into a new package to enhance it for write support.

Basically I just divided ASObject from AudioScrobbler in two classes:

- MXObject carries all the xml binding stuff
- ASObject deal with network stuff (curl etc.)

All *Reader classes in AudioScrobbler moved into the new package as well as the extensions to MADescription etc. The prefix changed from AS to MX. 

I wanted to leave a clean state behind. There are dependencies between AudioScrobbler, Topfeeder and NetworkAddress. All used old magritte semantics so I had to change all of them.

So I touched 4 packages:

- NetworkAddress (magritteaddons repo)
- Magritte-XMLBinding (created in magritteaddons repo)
- AudioScrobbler (audioscrobbler repo)
- TopFeeder (topfeeder repo)

All tests were green afterwards while top feeder takes ages. There is a starting implementation for write support that is just at its beginning. I checked the package in to resolve all inter-package dependencies. As far as I can tell there hasn't been a side effect so far regarding the refactoring.

Norbert

From dtrussardi at tiscali.it  Tue Feb 16 12:34:44 2010
From: dtrussardi at tiscali.it (dtrussardi at tiscali.it)
Date: Tue, 16 Feb 2010 12:34:44 +0100
Subject: WAPlugin for manage MADescription priority 
Message-ID: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>

Hi,

i'm interested to display and change the priority of MADescription components when the browser display  Halos.

For example i have a class with descriptionA, descriptionB.

For display the priority  i change the WAClassnameHaloPlugin renderOn: method.


For change i create the WAPriorityHaloPlugin.

In the relative  execute method i test if component is anMAComponent :  self target description respondTo: #priority .

If yes i,m interested to open the Browser or WABrowser on the relative descriptionA.



The first question is:  how i can define the name of descriptionA from anObject with magritte structure  ?

	into execute context of WAPriorityHaloPlugin  i see aObject with memento, description, accessor .....  but i d'ont found link to the relative generating descriptionA.



The second question is: after change the descriptionA with the WABrowser and return to the halo browser how i can update the view to reflect the change ?

	i have do some test but for now ti need to close and reopen the view.


Thanks for any considerations.

	Dario

From p3anoman at gmail.com  Tue Feb 16 14:53:16 2010
From: p3anoman at gmail.com (John McKeon)
Date: Tue, 16 Feb 2010 08:53:16 -0500
Subject: WAPlugin for manage MADescription priority
In-Reply-To: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
References: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
Message-ID: <40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>

Hey Dario,
I can try and help.

On Tue, Feb 16, 2010 at 6:34 AM, dtrussardi at tiscali.it <
dtrussardi at tiscali.it> wrote:

> Hi,
>
> i'm interested to display and change the priority of MADescription
> components when the browser display  Halos.
>
> For example i have a class with descriptionA, descriptionB.
>
> For display the priority  i change the WAClassnameHaloPlugin renderOn:
> method.
>
>
> For change i create the WAPriorityHaloPlugin.
>
> In the relative  execute method i test if component is anMAComponent :
>  self target description respondTo: #priority .
>
> If yes i,m interested to open the Browser or WABrowser on the relative
> descriptionA.
>
>
>
> The first question is:  how i can define the name of descriptionA from
> anObject with magritte structure  ?
>
>        into execute context of WAPriorityHaloPlugin  i see aObject with
> memento, description, accessor .....  but i d'ont found link to the relative
> generating descriptionA.
>
> Given that aObject's description is a container you can iterate through the
contained descriptions looking for a match on the selector of the
description.
  aObject description detect: [ :each | each accessor selector =
#theSelectorIWant ]


>
> The second question is: after change the descriptionA with the WABrowser
> and return to the halo browser how i can update the view to reflect the
> change ?
>
>        i have do some test but for now ti need to close and reopen the
> view.
>

Descriptions are cached so sending #flush to MANamedBuilder default forces
the (container) descriptions to be rebuilt with the modified descripitons. I
dont know if that will work well in your situation.

Best of luck with it
John


>
> Thanks for any considerations.
>
>        Dario
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100216/f3456871/attachment.html>

From dtrussardi at tiscali.it  Tue Feb 16 16:58:12 2010
From: dtrussardi at tiscali.it (dtrussardi at tiscali.it)
Date: Tue, 16 Feb 2010 16:58:12 +0100
Subject: WAPlugin for manage MADescription priority
In-Reply-To: <40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>
References: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
	<40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>
Message-ID: <601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>

Hey John,

> Hey Dario,
> I can try and help.
> 
> On Tue, Feb 16, 2010 at 6:34 AM, dtrussardi at tiscali.it <dtrussardi at tiscali.it> wrote:
> Hi,
> 
> i'm interested to display and change the priority of MADescription components when the browser display  Halos.
> 
> For example i have a class with descriptionA, descriptionB.
> 
> For display the priority  i change the WAClassnameHaloPlugin renderOn: method.
> 
> 
> For change i create the WAPriorityHaloPlugin.
> 
> In the relative  execute method i test if component is anMAComponent :  self target description respondTo: #priority .
> 
> If yes i,m interested to open the Browser or WABrowser on the relative descriptionA.
> 
> 
> 
> The first question is:  how i can define the name of descriptionA from anObject with magritte structure  ?
> 
>        into execute context of WAPriorityHaloPlugin  i see aObject with memento, description, accessor .....  but i d'ont found link to the relative generating descriptionA.
> 
> Given that aObject's description is a container you can iterate through the contained descriptions looking for a match on the selector of the description.
>   aObject description detect: [ :each | each accessor selector = #theSelectorIWant ]

The problem is: 	at  this level i d'ont understand the description name ( descriptionA )relative to the magritte component.

Any magritte component ( create with descriptionA descriptionB descriptionX  relative to one class )  when rendering with halo view, is display with the relative WAPriorityHaloPlugin anchor.

Now    assume to  click on anchor relative to component create with descriptionA    i go into relative  'execute' context of WAPriorityHaloPlugin  where i found a specific aObject with memento, description, accessor,

but i d'ont found,  a this level, any link to the original descriptionA.


I can add property to the descriptionA define method:

	descriptionA

	^(MABooleanDescription new)
		autoAccessor: #attivo;
		checkboxLabel: 'Account attivo';
		label: 'Attivo';
		priority: 4030;


		propertyAt: #descriptionName put: #'descriptionA';
		.........


but with this solution i need to change all the descriptions.


> 
> The second question is: after change the descriptionA with the WABrowser and return to the halo browser how i can update the view to reflect the change ?
> 
>        i have do some test but for now ti need to close and reopen the view.
> 
> Descriptions are cached so sending #flush to MANamedBuilder default forces the (container) descriptions to be rebuilt with the modified descripitons. I dont know if that will work well in your situation.
> 


I do MANamedBuilder default flush  but not work ( the view is rendering with no change ).

I need to close and reopen the view.

I can flush the cache relative to one specific class ?

> Best of luck with it
> John
> 


Thank,

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

From p3anoman at gmail.com  Tue Feb 16 17:29:59 2010
From: p3anoman at gmail.com (John McKeon)
Date: Tue, 16 Feb 2010 11:29:59 -0500
Subject: WAPlugin for manage MADescription priority
In-Reply-To: <601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>
References: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
	<40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>
	<601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>
Message-ID: <40f637ec1002160829l212d3719ga004f6849ca2aa76@mail.gmail.com>

On Tue, Feb 16, 2010 at 10:58 AM, dtrussardi at tiscali.it <
dtrussardi at tiscali.it> wrote:

> Hey John,
>
> Hey Dario,
> I can try and help.
>
> On Tue, Feb 16, 2010 at 6:34 AM, dtrussardi at tiscali.it <
> dtrussardi at tiscali.it> wrote:
>
>> Hi,
>>
>> i'm interested to display and change the priority of MADescription
>> components when the browser display  Halos.
>>
>> For example i have a class with descriptionA, descriptionB.
>>
>> For display the priority  i change the WAClassnameHaloPlugin renderOn:
>> method.
>>
>>
>> For change i create the WAPriorityHaloPlugin.
>>
>> In the relative  execute method i test if component is anMAComponent :
>>  self target description respondTo: #priority .
>>
>> If yes i,m interested to open the Browser or WABrowser on the relative
>> descriptionA.
>>
>>
>>
>> The first question is:  how i can define the name of descriptionA from
>> anObject with magritte structure  ?
>>
>>        into execute context of WAPriorityHaloPlugin  i see aObject with
>> memento, description, accessor .....  but i d'ont found link to the relative
>> generating descriptionA.
>>
>> Given that aObject's description is a container you can iterate through
> the contained descriptions looking for a match on the selector of the
> description.
>   aObject description detect: [ :each | each accessor selector =
> #theSelectorIWant ]
>
>
> The problem is: at  this level i d'ont understand the description name (
> descriptionA )relative to the magritte component.
>
> Any magritte component ( create with descriptionA descriptionB descriptionX
>  relative to one class )  when rendering with halo view, is display with the
> relative WAPriorityHaloPlugin anchor.
>
> Now    assume to  click on anchor relative to component create with
> descriptionA    i go into relative  'execute' context of
> WAPriorityHaloPlugin  where i found a specific aObject with memento,
> description, accessor,
>
> but i d'ont found,  a this level, any link to the original descriptionA.
>
>
> I can add property to the descriptionA define method:
>
> descriptionA
>
> ^(MABooleanDescription new) autoAccessor: #attivo; checkboxLabel: 'Account
> attivo'; label: 'Attivo'; priority: 4030;
>
>
> propertyAt: #descriptionName put: #'descriptionA';
> .........
>
>
> but with this solution i need to change all the descriptions.
>

Maybe extend MADescription with #descriptionName that returns a reasonable
default?
   ^self propertyAt: #descriptionName ifAbsent: [ 'Description for ' , self
label ]

>
>
>
>> The second question is: after change the descriptionA with the WABrowser
>> and return to the halo browser how i can update the view to reflect the
>> change ?
>>
>>        i have do some test but for now ti need to close and reopen the
>> view.
>>
>
> Descriptions are cached so sending #flush to MANamedBuilder default forces
> the (container) descriptions to be rebuilt with the modified descripitons. I
> dont know if that will work well in your situation.
>
>
>
> I do MANamedBuilder default flush  but not work ( the view is rendering
> with no change ).
>
> I need to close and reopen the view.
>

I was afraid that would be the case, but once you change the priorities it
would have to rebuild the container component no? I am not really that
familiar with the halo/plugin stuff....maybe senders of the open: method
might provide some clues


> I can flush the cache relative to one specific class ?
>
> Best of luck with it
> John
>
>
>
> Thank,
>
> Dario
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100216/f23b4064/attachment-0001.html>

From razavi at acm.org  Tue Feb 16 17:47:56 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Tue, 16 Feb 2010 17:47:56 +0100
Subject: Book navigation rendering issue report
In-Reply-To: <601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>
References: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
	<40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>
	<601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>
Message-ID: <89dhun$sg26j@smtp.pt.lu>

Hi,

After having upgraded to the latest Seaside 3 and Pier 2 packages, I 
encounter a minor issue that could be regenerated as follows:
1) Evaluate in a workspace "PRBookDistribution new register"
2) Point to http://localhost:8080/pier/book/table-of-contents

The navigation arrows are not rendered anymore. Instead, appear their 
textual encoding (&rarr and &larr). It is the same for non-breaking 
space that appears as &nbsp (See for example 
http://localhost:8080/pier/book), as well as other codifications like &sect.

Otherwise, I was wondering if in:
	BOLatexWriter >> convertHtmlEntities:

the following:
	copyReplaceAll: '&rarr;' with: '<-'

shouldn't be rather:
	copyReplaceAll: '&rarr;' with: '->'

Cheers,
Reza


From dtrussardi at tiscali.it  Tue Feb 16 20:01:26 2010
From: dtrussardi at tiscali.it (dtrussardi at tiscali.it)
Date: Tue, 16 Feb 2010 20:01:26 +0100
Subject: WAPlugin for manage MADescription priority
In-Reply-To: <40f637ec1002160829l212d3719ga004f6849ca2aa76@mail.gmail.com>
References: <7A8DF7B5-795A-45AD-B7B2-34390302E68F@tiscali.it>
	<40f637ec1002160553n76ed4ee0vfacaeb095ee2a6f5@mail.gmail.com>
	<601002CD-3FF5-454D-951B-55D9D38159FF@tiscali.it>
	<40f637ec1002160829l212d3719ga004f6849ca2aa76@mail.gmail.com>
Message-ID: <388D534A-A35B-432B-933B-6ADE804E2482@tiscali.it>


Hi,

i do some test but i d'ont found the solution.

I think one possible  solution can is to set an specific  property when i the system instance one new Description.

	descriptionDescrizione
		^(MAStringDescription new)
		autoAccessor: 'descrizione';
		label: 'Descrizione';
		priority: 1110;
		comment: 'Descrizione';
		beRequired...


The ^(MAStringDescription new) 	create a new instance and i can intercept it with MAObject initialize method.



	 MAObject initialize
			
			super initialize.
			self propertyAt: #descriptionMessage  put:   ????

Question: it's possible into  MAObject initialize method define the "caller" method ? ( in this case : descriptionDescrizione ).

I need create new: method
	
	descriptionDescrizione
		^(MAStringDescription new:  descriptionDescrizione)

		autoAccessor: 'descrizione';
		label: 'Descrizione';
		priority: 1110;
		comment: 'Descrizione';
		beRequired...



Question:  i can in the descriptionDescrizione method manage the reference to method name ?

	descriptionDescrizione

		^(MAStringDescription new:  ' a this level define automatic  reference to the method name '  )
		........

Thank,

	Dario


> 
> 
> On Tue, Feb 16, 2010 at 10:58 AM, dtrussardi at tiscali.it <dtrussardi at tiscali.it> wrote:
> Hey John,
> 
>> Hey Dario,
>> I can try and help.
>> 
>> On Tue, Feb 16, 2010 at 6:34 AM, dtrussardi at tiscali.it <dtrussardi at tiscali.it> wrote:
>> Hi,
>> 
>> i'm interested to display and change the priority of MADescription components when the browser display  Halos.
>> 
>> For example i have a class with descriptionA, descriptionB.
>> 
>> For display the priority  i change the WAClassnameHaloPlugin renderOn: method.
>> 
>> 
>> For change i create the WAPriorityHaloPlugin.
>> 
>> In the relative  execute method i test if component is anMAComponent :  self target description respondTo: #priority .
>> 
>> If yes i,m interested to open the Browser or WABrowser on the relative descriptionA.
>> 
>> 
>> 
>> The first question is:  how i can define the name of descriptionA from anObject with magritte structure  ?
>> 
>>        into execute context of WAPriorityHaloPlugin  i see aObject with memento, description, accessor .....  but i d'ont found link to the relative generating descriptionA.
>> 
>> Given that aObject's description is a container you can iterate through the contained descriptions looking for a match on the selector of the description.
>>   aObject description detect: [ :each | each accessor selector = #theSelectorIWant ]
> 
> The problem is: 	at  this level i d'ont understand the description name ( descriptionA )relative to the magritte component.
> 
> Any magritte component ( create with descriptionA descriptionB descriptionX  relative to one class )  when rendering with halo view, is display with the relative WAPriorityHaloPlugin anchor.
> 
> Now    assume to  click on anchor relative to component create with descriptionA    i go into relative  'execute' context of WAPriorityHaloPlugin  where i found a specific aObject with memento, description, accessor,
> 
> but i d'ont found,  a this level, any link to the original descriptionA.
> 
> 
> I can add property to the descriptionA define method:
> 
> 	descriptionA
> 
> 	^(MABooleanDescription new)
> 		autoAccessor: #attivo;
> 		checkboxLabel: 'Account attivo';
> 		label: 'Attivo';
> 		priority: 4030;
> 
> 
> 		propertyAt: #descriptionName put: #'descriptionA';
> 		.........
> 
> 
> but with this solution i need to change all the descriptions.
> 
> Maybe extend MADescription with #descriptionName that returns a reasonable default?
>    ^self propertyAt: #descriptionName ifAbsent: [ 'Description for ' , self label ]
> 
> 
>> 
>> The second question is: after change the descriptionA with the WABrowser and return to the halo browser how i can update the view to reflect the change ?
>> 
>>        i have do some test but for now ti need to close and reopen the view.
>> 
>> Descriptions are cached so sending #flush to MANamedBuilder default forces the (container) descriptions to be rebuilt with the modified descripitons. I dont know if that will work well in your situation.
>> 
> 
> 
> I do MANamedBuilder default flush  but not work ( the view is rendering with no change ).
> 
> I need to close and reopen the view.
> 
> I was afraid that would be the case, but once you change the priorities it would have to rebuild the container component no? I am not really that familiar with the halo/plugin stuff....maybe senders of the open: method might provide some clues
> 
> 
> I can flush the cache relative to one specific class ?
> 
>> Best of luck with it
>> John
>> 
> 
> 
> Thank,
> 
> 		Dario
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> http://jmck.seasidehosting.st
> _______________________________________________
> 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/20100216/5eb792e3/attachment.html>

From nick.ager at gmail.com  Wed Feb 17 19:56:35 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Wed, 17 Feb 2010 18:56:35 +0000
Subject: confused by PRWidget initialisation
Message-ID: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>

Hi,

I'm writing this as PRWidget initialisation had me confused for a while, and
I guess it might confuse other newcomers. I'd also like to check with the
list that my understanding is correct.

For example given the code below:

PRDistribution>>childrenWidget
^ childrenWidget ifNil: [childrenWidget := (PRComponent named: 'children')
componentClass: PRChildrenWidget;
write: 2
using: PRChildrenWidget descriptionLevel;
write: true
using: PRChildrenWidget descriptionExpand;
yourself
]
and:

PRChildrenWidget class>>descriptionExpand
^ MABooleanDescription new
default: self defaultExpand;
parameterName: 'expand';
accessor: #expand;
label: 'Expand';
priority: 310;
yourself

I would have expected an accessor "PRChildWidget>>expand:" to be called with
the value: 'true'.  I created my PRWidget derived class based on this
assumption. However my equivalent setter was not being called and a closer
look showed PRChildWidget to have no setters only getters. The getter reads
as:

PRChildWidget>>expand
^ self read: #descriptionExpand


What's actually happening is "PRComponent>>description" is being called, not
as I'd imagined: "PRChildWidget>>description".

tracing through the following code:

PRComponent>>write: anObject using: aDescription
(self basicDescription includes: aDescription)
ifTrue: [ super write: anObject using: aDescription ]
ifFalse: [
(anObject notNil and: [ aDescription isDocumentDescription ])
ifTrue: [ anObject owner: self ].
self settings at: aDescription put: anObject ]

reveals the code: "self settings at: aDescription put: anObject" is called,
so "true" is placed in a settings Dictionary keyed by: #descriptionExpand

I've just about understood the code so far, and though I haven't traced
through PRChildrenWidget instantiation it looks like in
WAComponent>>initializeOwner:link: that the settings are copied to the newly
created PRChildrenWidget object.

Phew.

I think I can see why there's complexity, but seems a shame that it in
WAComponent>>initializeOwner:link: the code couldn't call the accessors of
the componentClass assuming that the Magritte descriptions were configured
to use an accessor pattern.

Or perhaps I've misunderstood??

Cheers

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

From razavi at acm.org  Wed Feb 17 21:07:19 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Wed, 17 Feb 2010 21:07:19 +0100
Subject: confused by PRWidget initialisation
In-Reply-To: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
Message-ID: <8bbtuf$107hbs@smtp.pt.lu>

Hi Nick,

My understating is the following:
1) For each specific Distribution, PRComponents keep track of the 
default attribute values for each Widget (i.e., user preferences for 
that Distribution). PRDistribution>>childrenWidget is an example of 
such specification.
2) At runtime, when Widgets are instantiated for each Session, these 
default values are affected to their respective Widget attribute by 
WAComponent >> initializeOwner:link:, itself called by PRComponent >> 
componentFor:, in turn called by PRContext >> buildComponent:for:.

PRWidgets overrides #write:using: to keep track of its attribute 
values in its properties dictionary (instead of widget specific 
accessors). This design decision facilitates the implementation and 
maintenance of specific Widgets.

Hoping this helps,
Reza

At 19:56 17/02/2010, Nick Ager wrote:
>Hi,
>
>I'm writing this as PRWidget initialisation had me confused for a 
>while, and I guess it might confuse other newcomers. I'd also like 
>to check with the list that my understanding is correct.
>
>For example given the code below:
>
>PRDistribution>>childrenWidget
>^ childrenWidget ifNil: [childrenWidget := (PRComponent named: 'children')
>componentClass: PRChildrenWidget;
>write: 2
>using: PRChildrenWidget descriptionLevel;
>write: true
>using: PRChildrenWidget descriptionExpand;
>yourself
>]
>and:
>
>PRChildrenWidget class>>descriptionExpand
>^ MABooleanDescription new
>default: self defaultExpand;
>parameterName: 'expand';
>accessor: #expand;
>label: 'Expand';
>priority: 310;
>yourself
>
>I would have expected an accessor "PRChildWidget>>expand:" to be 
>called with the value: 'true'.  I created my PRWidget derived class 
>based on this assumption. However my equivalent setter was not being 
>called and a closer look showed PRChildWidget to have no setters 
>only getters. The getter reads as:
>
>PRChildWidget>>expand
>^ self read: #descriptionExpand
>
>
>What's actually happening is "PRComponent>>description" is being 
>called, not as I'd imagined: "PRChildWidget>>description".
>
>tracing through the following code:
>
>PRComponent>>write: anObject using: aDescription
>(self basicDescription includes: aDescription)
>ifTrue: [ super write: anObject using: aDescription ]
>ifFalse: [
>(anObject notNil and: [ aDescription isDocumentDescription ])
>ifTrue: [ anObject owner: self ].
>self settings at: aDescription put: anObject ]
>
>reveals the code: "self settings at: aDescription put: anObject" is 
>called, so "true" is placed in a settings Dictionary keyed by: 
>#descriptionExpand
>
>I've just about understood the code so far, and though I haven't 
>traced through PRChildrenWidget instantiation it looks like in 
>WAComponent>>initializeOwner:link: that the settings are copied to 
>the newly created PRChildrenWidget object.
>
>Phew.
>
>I think I can see why there's complexity, but seems a shame that it 
>in WAComponent>>initializeOwner:link: the code couldn't call the 
>accessors of the componentClass assuming that the Magritte 
>descriptions were configured to use an accessor pattern.
>
>Or perhaps I've misunderstood??
>
>Cheers
>
>Nick
>_______________________________________________
>Magritte, Pier and Related Tools ...
>https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From renggli at gmail.com  Wed Feb 17 21:40:38 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Wed, 17 Feb 2010 21:40:38 +0100
Subject: confused by PRWidget initialisation
In-Reply-To: <8bbtuf$107hbs@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<8bbtuf$107hbs@smtp.pt.lu>
Message-ID: <67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>

As Reza writes the components (or widgets) cannot carry their own
configuration, because they are instantiated later on and on a
per-session based. So the configuration happens on a generic model
object (PRComponent) that takes the description of the component and
stores its values in the settings dictionary. Whenever a component is
instantiated it is initialized with the settings from the model, that
can be overridden with the settings given in the link that embeds the
component.

It could well be that the current implementation is not as strait
forward as it could be. Over the time Magritte and Pier both changed
quite heavily and maybe it could be done simpler today?

Lukas

On 17 February 2010 21:07, Reza RAZAVI <razavi at acm.org> wrote:
> Hi Nick,
>
> My understating is the following:
> 1) For each specific Distribution, PRComponents keep track of the default
> attribute values for each Widget (i.e., user preferences for that
> Distribution). PRDistribution>>childrenWidget is an example of such
> specification.
> 2) At runtime, when Widgets are instantiated for each Session, these default
> values are affected to their respective Widget attribute by WAComponent >>
> initializeOwner:link:, itself called by PRComponent >> componentFor:, in
> turn called by PRContext >> buildComponent:for:.
>
> PRWidgets overrides #write:using: to keep track of its attribute values in
> its properties dictionary (instead of widget specific accessors). This
> design decision facilitates the implementation and maintenance of specific
> Widgets.
>
> Hoping this helps,
> Reza
>
> At 19:56 17/02/2010, Nick Ager wrote:
>>
>> Hi,
>>
>> I'm writing this as PRWidget initialisation had me confused for a while,
>> and I guess it might confuse other newcomers. I'd also like to check with
>> the list that my understanding is correct.
>>
>> For example given the code below:
>>
>> PRDistribution>>childrenWidget
>> ^ childrenWidget ifNil: [childrenWidget := (PRComponent named: 'children')
>> componentClass: PRChildrenWidget;
>> write: 2
>> using: PRChildrenWidget descriptionLevel;
>> write: true
>> using: PRChildrenWidget descriptionExpand;
>> yourself
>> ]
>> and:
>>
>> PRChildrenWidget class>>descriptionExpand
>> ^ MABooleanDescription new
>> default: self defaultExpand;
>> parameterName: 'expand';
>> accessor: #expand;
>> label: 'Expand';
>> priority: 310;
>> yourself
>>
>> I would have expected an accessor "PRChildWidget>>expand:" to be called
>> with the value: 'true'. ?I created my PRWidget derived class based on this
>> assumption. However my equivalent setter was not being called and a closer
>> look showed PRChildWidget to have no setters only getters. The getter reads
>> as:
>>
>> PRChildWidget>>expand
>> ^ self read: #descriptionExpand
>>
>>
>> What's actually happening is "PRComponent>>description" is being called,
>> not as I'd imagined: "PRChildWidget>>description".
>>
>> tracing through the following code:
>>
>> PRComponent>>write: anObject using: aDescription
>> (self basicDescription includes: aDescription)
>> ifTrue: [ super write: anObject using: aDescription ]
>> ifFalse: [
>> (anObject notNil and: [ aDescription isDocumentDescription ])
>> ifTrue: [ anObject owner: self ].
>> self settings at: aDescription put: anObject ]
>>
>> reveals the code: "self settings at: aDescription put: anObject" is
>> called, so "true" is placed in a settings Dictionary keyed by:
>> #descriptionExpand
>>
>> I've just about understood the code so far, and though I haven't traced
>> through PRChildrenWidget instantiation it looks like in
>> WAComponent>>initializeOwner:link: that the settings are copied to the newly
>> created PRChildrenWidget object.
>>
>> Phew.
>>
>> I think I can see why there's complexity, but seems a shame that it in
>> WAComponent>>initializeOwner:link: the code couldn't call the accessors of
>> the componentClass assuming that the Magritte descriptions were configured
>> to use an accessor pattern.
>>
>> Or perhaps I've misunderstood??
>>
>> Cheers
>>
>> Nick
>> _______________________________________________
>> 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
http://www.lukas-renggli.ch


From nick.ager at gmail.com  Thu Feb 18 02:18:12 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Thu, 18 Feb 2010 01:18:12 +0000
Subject: confused by PRWidget initialisation
In-Reply-To: <67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
Message-ID: <3a06f76f1002171718q4de810b1y1f282174516c0cc2@mail.gmail.com>

Thanks for the replies, as ever very helpful.

>> PRWidgets overrides #write:using: to keep track of its attribute values
in its properties dictionary (instead of widget
>> specific accessors). This design decision facilitates the implementation
and maintenance of specific Widgets.

This helped me understand  the mechanism why PRWidget derived objects store
their properties in a directory rather than via an accessor. I experimented
by overriding #write:using in my PRWidget derived class, to reinstating the
default implementation in Object thus:

write: anObject using: aDescription
aDescription accessor write: anObject to: self

Then magically the setters in my derived class where called as I'd
originally anticipated.

I understand that sometimes it's handy to be able to dynamically add fields
to an object, which is when it makes sense to use a Dictionary, however to
aid my understanding it seems much simpler to store properties in instance
variables accessed via accessors. Will I fall into any problems if I use an
accessor pattern on my PRWidget derived classes by ensuring that
#write:using: reimplements the Object>>write:using: ?

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

From razavi at acm.org  Thu Feb 18 07:00:35 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Thu, 18 Feb 2010 07:00:35 +0100
Subject: confused by PRWidget initialisation
In-Reply-To: <3a06f76f1002171718q4de810b1y1f282174516c0cc2@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<3a06f76f1002171718q4de810b1y1f282174516c0cc2@mail.gmail.com>
Message-ID: <8bbtuf$109m99@smtp.pt.lu>

At 02:18 18/02/2010, Nick Ager wrote:
>I understand that sometimes it's handy to be able to dynamically add 
>fields to an object, which is when it makes sense to use a 
>Dictionary, however to aid my understanding it seems much simpler to 
>store properties in instance variables accessed via accessors. Will 
>I fall into any problems if I use an accessor pattern on my PRWidget 
>derived classes by ensuring that #write:using: reimplements the 
>Object>>write:using: ?

Pier provides a general mechanism for handling the issue we 
discussed. It could be done differently, like the solution above. 
But, in that case you break the logic of your implementation 
framework, Pier, which means that you take an additional maintenance 
responsibility to keep your logic in synch. with that of Pier (that 
may change with time). I'd avoid this, and would keep the Property 
Pattern of Pier that works just fine. After all, widgets are 
transient objects that provide users a view on your model objects 
during a session. I'd therefore recommend to focus on model objects, 
and just reuse the solution provided by Pier.

Hoping this helps,
Reza 


From razavi at acm.org  Thu Feb 18 07:47:45 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Thu, 18 Feb 2010 07:47:45 +0100
Subject: confused by PRWidget initialisation
In-Reply-To: <67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com
 >
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
Message-ID: <89dhun$stl3a@smtp.pt.lu>

At 21:40 17/02/2010, Lukas Renggli wrote:
>It could well be that the current implementation is not as strait
>forward as it could be. Over the time Magritte and Pier both changed
>quite heavily and maybe it could be done simpler today?

Hi Lukas,

Most of the complexity is related to the layers of abstraction that 
necessarily come into play when implementing such a sophisticated and 
flexible system. However, in this specific case roles and 
responsibilities could probably be made a little bit more explicit. A 
quick fix is suggested attached. It is based on the following ideas:

1) Give a name to the different portions of the logic, and dispatch 
their implementation to responsible objects. This helps by making 
object collaboration flows more explicit (while providing also 
application developers with more hooks to override that specific 
portion of code, based on their specific requirements).

2) PRComponents have a structural role, where WAComponents have a 
visual role. It could help to make this distinction explicit in the 
code naming conventions. For example, PRStructuralComponent instead 
of PRComponent, and WAVisualComponent instead of WAComponent.

Regards,
Reza



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PRWidget-init refactoring.st
Type: application/octet-stream
Size: 2089 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100218/50a0f34b/attachment-0001.obj>

From renggli at gmail.com  Thu Feb 18 11:36:18 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 18 Feb 2010 11:36:18 +0100
Subject: confused by PRWidget initialisation
In-Reply-To: <89dhun$stl3a@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com> 
	<89dhun$stl3a@smtp.pt.lu>
Message-ID: <67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>

I've integrated your changes in the latest Pier.

Thank you for submitting the patch.

Lukas

On 18 February 2010 07:47, Reza RAZAVI <razavi at acm.org> wrote:
> At 21:40 17/02/2010, Lukas Renggli wrote:
>>
>> It could well be that the current implementation is not as strait
>> forward as it could be. Over the time Magritte and Pier both changed
>> quite heavily and maybe it could be done simpler today?
>
> Hi Lukas,
>
> Most of the complexity is related to the layers of abstraction that
> necessarily come into play when implementing such a sophisticated and
> flexible system. However, in this specific case roles and responsibilities
> could probably be made a little bit more explicit. A quick fix is suggested
> attached. It is based on the following ideas:
>
> 1) Give a name to the different portions of the logic, and dispatch their
> implementation to responsible objects. This helps by making object
> collaboration flows more explicit (while providing also application
> developers with more hooks to override that specific portion of code, based
> on their specific requirements).
>
> 2) PRComponents have a structural role, where WAComponents have a visual
> role. It could help to make this distinction explicit in the code naming
> conventions. For example, PRStructuralComponent instead of PRComponent, and
> WAVisualComponent instead of WAComponent.
>
> Regards,
> Reza
>
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From razavi at acm.org  Thu Feb 18 14:13:20 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Thu, 18 Feb 2010 14:13:20 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
Message-ID: <89dhun$t1b8u@smtp.pt.lu>

At 11:36 18/02/2010, Lukas Renggli wrote:
>I've integrated your changes in the latest Pier.

Thanks for the integration Lukas!

In the same vein of ideas, I'd like to share the attached change set. 
It contains:
- A tiny framework that facilitates the *transformation" of Pier 
Widgets to Pier Commands through code reuse.
- Its application to transform the following Widgets to Commands:
         PRExportImportWidget
         PRFileSettings
         PUGroupsWidget
         PRKernelSettings
         PRPersistencySettings
         PRSystemWidget
         PUUsersWidget
         PUSecurityWidget

The second file contains a few patches to the Pier code, to get a 
'Close' button while remaining fully compatible with the current behavior.

If you find this useful, please don't hesitate to integrate it as you 
would find it better fitting into Pier (specifically, I don't like my 
patches to get the close button, but this was the most straitforward 
way to get it working).

Regards,
Reza


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier Commands-Widget Adaptors.st
Type: application/octet-stream
Size: 5910 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100218/86ff10d0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier Commands-Widget Adaptors-Pier patches.st
Type: application/octet-stream
Size: 2632 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100218/86ff10d0/attachment-0001.obj>

From renggli at gmail.com  Thu Feb 18 15:22:07 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 18 Feb 2010 15:22:07 +0100
Subject: Widget to Command adaptor
In-Reply-To: <89dhun$t1b8u@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com> 
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com> 
	<89dhun$t1b8u@smtp.pt.lu>
Message-ID: <67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>

Thank you for the contributions, I will look at these changes tonight.

In the future, it would make merging easier if you submitted
Monticello (mcz) files. You can post them directly to my repository
(it is still publicly writeable contrary to many other repositories
that we had to close do to a proliferation of unrelated changes), any
other public repository, or even send them by mail as you do with the
.st files now.

Lukas

On 18 February 2010 14:13, Reza RAZAVI <razavi at acm.org> wrote:
> At 11:36 18/02/2010, Lukas Renggli wrote:
>>
>> I've integrated your changes in the latest Pier.
>
> Thanks for the integration Lukas!
>
> In the same vein of ideas, I'd like to share the attached change set. It
> contains:
> - A tiny framework that facilitates the *transformation" of Pier Widgets to
> Pier Commands through code reuse.
> - Its application to transform the following Widgets to Commands:
> ? ? ? ?PRExportImportWidget
> ? ? ? ?PRFileSettings
> ? ? ? ?PUGroupsWidget
> ? ? ? ?PRKernelSettings
> ? ? ? ?PRPersistencySettings
> ? ? ? ?PRSystemWidget
> ? ? ? ?PUUsersWidget
> ? ? ? ?PUSecurityWidget
>
> The second file contains a few patches to the Pier code, to get a 'Close'
> button while remaining fully compatible with the current behavior.
>
> If you find this useful, please don't hesitate to integrate it as you would
> find it better fitting into Pier (specifically, I don't like my patches to
> get the close button, but this was the most straitforward way to get it
> working).
>
> Regards,
> Reza
>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From razavi at acm.org  Thu Feb 18 15:55:53 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Thu, 18 Feb 2010 15:55:53 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>
Message-ID: <8bbtuf$10f57u@smtp.pt.lu>

At 15:22 18/02/2010, Lukas Renggli wrote:
>You can post them directly to my repository

Well noted; thanks for the precision!

I just uploaded a Monticello package to your Pier2 repo. It contains 
the code for the first .st file sent previously, and some comments on 
how to get easily the 'Close' button (code contained in the 2nd .st 
file sent previously).

Please don't hesitate to remove it (and the future posts) once you 
have looked at it.

BTW, I assume that you automatically get a notification upon each 
upload. If this is not the case, please let me know to send then an email.

Regards,
Reza


From renggli at gmail.com  Thu Feb 18 22:14:28 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Thu, 18 Feb 2010 22:14:28 +0100
Subject: Widget to Command adaptor
In-Reply-To: <8bbtuf$10f57u@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com> 
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com> 
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com> 
	<8bbtuf$10f57u@smtp.pt.lu>
Message-ID: <67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com>

> I just uploaded a Monticello package to your Pier2 repo. It contains the
> code for the first .st file sent previously, and some comments on how to get
> easily the 'Close' button (code contained in the 2nd .st file sent
> previously).

I think that makes a good addition to Pier as an extension. I don't
feel like adding it to Pier-Seasde though, as commands are normally
designed to work on a specific structures. The widgets you wrapped do
work on the complete system though. Also your strategy of wrapping the
widgets into commands makes security sort of fragile.

> Please don't hesitate to remove it (and the future posts) once you have
> looked at it.
>
> BTW, I assume that you automatically get a notification upon each upload. If
> this is not the case, please let me know to send then an email.

Sure, there is a public RSS feed on the repository. Maybe better write
a short mail to the list explaining the change, this is more likely to
get noticed. Sometimes there are so many commits that I simply skip
over the individual ones.

Lukas

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

From razavi at acm.org  Fri Feb 19 09:41:04 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 19 Feb 2010 09:41:04 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com>
Message-ID: <89dhun$t85ff@smtp.pt.lu>

Hi Lukas,

Thanks for your feedback!

At 22:14 18/02/2010, Lukas Renggli wrote:
>I think that makes a good addition to Pier as an extension.

I understand your choice, and I'd basically do the same. However, let 
me emphasize that I decided to develop this as an alternative to 
http://localhost:8080/pier/system/management, which is proposed as a 
default solution in PRDistribution, since I had two issues with that tool page:
1) 'Save' and 'Cancel' buttons in that page have a somehow 
non-standard behavior.
2) To close that page, I only found the following two options:
   (a) close the page
   (b) use the back button

I had an issue with (a) since I simply wanted  to keep using my page.
Option (b) undos your modifications, since Seaside backtracks the state.
  This could be tested easily. For example:
- In "Kernel Settings" just rename the Kernel from "Pier" to "Pier2"
- Push the "Save" button. The kernel is modified and the page title 
changes from "Pier" to "Pier2"
- Push the back button (actually twice, in this specific example) to 
quite the page. Seaside brings back the previous Kernel named "Pier".

This is obviously not what we wanted. Am I missing something here?

>I don't
>feel like adding it to Pier-Seasde though, as commands are normally
>designed to work on a specific structures.

Yes, this mismatch is in fact a concern, although, the WtC adaptor 
refers too to a structure (the dummy PRComponent created by 
#widgetHolder, which is not the current structure). But, in my case, 
the practical benefit justifies a kind of conceptual compromise.

>The widgets you wrapped do
>work on the complete system though.

You are right. To make this difference explicit, I'm actually making 
these widget adaptors available in a separate toolbar, that looks like this:

PRDistribution >> admintoolsPage

         admintoolsPage ifNotNil: [^admintoolsPage].

         adminComp := PRComponent named: 'widget'.
         adminComp
                 componentClass: PRCommandsWidget;
                 write: AAsWidgetAdaptorCommand allSubclasses using: 
PRCommandsWidget descriptionCommandClasses.

         admintoolsPage:= (PRPage named: 'admintools')
                 addChild: adminComp;
                 contents: 'Admin tools: +widget+';
                 yourself.

         ^admintoolsPage

This assumes that those widget adaptors are additionally excluded 
from #commandsPage.

>Also your strategy of wrapping the
>widgets into commands makes security sort of fragile.

This is an important issue. Could you develop this a little more please?

As far as the current widget adaptor commands are concerned, the 
security is the same as the management page: the are only available 
to admin users. Additionally, Pier allows reenforcing this policy 
quite easily, for example, by attaching specific permissions to the 
admintoolsPage proposed above. Won't this suffice?

>Maybe better write
>a short mail to the list explaining the change,

Sure; well noted.

Regards,
Reza 


From norbert at hartl.name  Fri Feb 19 16:03:49 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Fri, 19 Feb 2010 16:03:49 +0100
Subject: magrite toOne relationship and component creation
Message-ID: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>

In the MARelationDescription it is possible to specify a variety of target clases that can be used. If I have more than one I cannot set the reference at the same time. This gives me trouble using MAExternalEditorComponent.

Shouldn't

MARelationComponent>>editorFor: anObject
	^ (self description reference asComponentOn: anObject)
		addValidatedForm;
		yourself

be rather

MARelationComponent>>editorFor: anObject
	^ (anObject description asComponentOn: anObject)
		addValidatedForm;
		yourself

?

Norbert

From dtrussardi at tiscali.it  Fri Feb 19 17:05:23 2010
From: dtrussardi at tiscali.it (dtrussardi at tiscali.it)
Date: Fri, 19 Feb 2010 17:05:23 +0100
Subject: Pier questions
Message-ID: <32327224-4F29-42DE-AC14-60C1F90C0188@tiscali.it>

Hi, 

i'am new about Pier.

I do some test with Pharo1-0.10509 and Pier-Seaside-lr.448

I have some questions :

1)  i have remove some item from commands.

	Now when go  into commands edit to add item i can't save the change because the error :
 
Command Classes: Invalid input given
2) i d'ont understund how i can release the 'project' for deploy.

	How i can manage the development with the environment and the command

	and the deploy with only 'end user' informations ?

3) i read into Frequently Asked Questions :
	Put a link *Top>.* to the bottom of your page. 

	You can also use the ?@-? syntax to jump to particular locations in a page


	But i don't know how manage it.

	How i can found example  ?
  

Thanks, 

	Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100219/9254bd49/attachment.html>

From razavi at acm.org  Fri Feb 19 19:42:49 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 19 Feb 2010 19:42:49 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com>
Message-ID: <89dhun$tdl65@smtp.pt.lu>

At 22:14 18/02/2010, you wrote:
>I think that makes a good addition to Pier as an extension.

I just wrapped it with Pier-Setup, and uploaded it to Pier2 repo.
For more details, please see the package comments.
If you don't like it, please feel free to delete the package.

Regards,
Reza 


From renggli at gmail.com  Sat Feb 20 09:45:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 09:45:11 +0100
Subject: magrite toOne relationship and component creation
In-Reply-To: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>
References: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>
Message-ID: <67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com>

> Shouldn't
>
> MARelationComponent>>editorFor: anObject
> ? ? ? ?^ (self description reference asComponentOn: anObject)
> ? ? ? ? ? ? ? ?addValidatedForm;
> ? ? ? ? ? ? ? ?yourself
>
> be rather
>
> MARelationComponent>>editorFor: anObject
> ? ? ? ?^ (anObject description asComponentOn: anObject)
> ? ? ? ? ? ? ? ?addValidatedForm;
> ? ? ? ? ? ? ? ?yourself
>
> ?

It depends what you want to do. I suggest that you create a subclass
that works for your use-case.

As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.

Lukas

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


From renggli at gmail.com  Sat Feb 20 09:48:21 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 09:48:21 +0100
Subject: Pier questions
In-Reply-To: <32327224-4F29-42DE-AC14-60C1F90C0188@tiscali.it>
References: <32327224-4F29-42DE-AC14-60C1F90C0188@tiscali.it>
Message-ID: <67628d691002200048h1899c453v9aa5bf2dece899b2@mail.gmail.com>

> 1) ?i have remove some item from commands.
> Now when go ?into commands edit to add item?i can't save the change because
> the error :
>
>
> Command Classes: Invalid input given

That's a bug, I've seen that too at some time, but never managed to
reliably reproduce.

I'll have a look at this again.

> 2) i d'ont understund how i can release the 'project' for deploy.
> How i can manage the development with the environment and the command
> and?the deploy with only 'end user' informations ?

You mark the root page of the environment as hidden to unauthenticated users.

> 3) i read into Frequently Asked Questions :
>
> Put a link *Top>.* to the bottom of your page.
>
> You can also use the ?@-? syntax to jump to particular locations in a page
>
> But i don't know how manage it.
> How i can found example ??

@top

*jump to top>. at top*

Lukas

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


From razavi at acm.org  Sat Feb 20 11:12:36 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sat, 20 Feb 2010 11:12:36 +0100
Subject: Pier questions
In-Reply-To: <67628d691002200048h1899c453v9aa5bf2dece899b2@mail.gmail.co
 m>
References: <32327224-4F29-42DE-AC14-60C1F90C0188@tiscali.it>
	<67628d691002200048h1899c453v9aa5bf2dece899b2@mail.gmail.com>
Message-ID: <8bbtuf$10v9c7@smtp.pt.lu>

At 09:48 20/02/2010, Lukas Renggli wrote:
>That's a bug, I've seen that too at some time, but never managed to
>reliably reproduce.

It looks like being related to a mismatch between the actual and 
cached values in MAMultipleOptionDescription >> validateKind:. I 
don't have the exact context within within the bug appears, but was 
wondering if it could be caused by MADynamicObject. 


From renggli at gmail.com  Sat Feb 20 12:23:42 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 12:23:42 +0100
Subject: Widget to Command adaptor
In-Reply-To: <89dhun$t85ff@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com> 
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com> 
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com> 
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com> 
	<89dhun$t85ff@smtp.pt.lu>
Message-ID: <67628d691002200323y58da8e6bo98f38b167f15eab1@mail.gmail.com>

> I had an issue with (a) since I simply wanted ?to keep using my page.
> Option (b) undos your modifications, since Seaside backtracks the state.
> ?This could be tested easily. For example:
> - In "Kernel Settings" just rename the Kernel from "Pier" to "Pier2"
> - Push the "Save" button. The kernel is modified and the page title changes
> from "Pier" to "Pier2"
> - Push the back button (actually twice, in this specific example) to quite
> the page. Seaside brings back the previous Kernel named "Pier".
>
> This is obviously not what we wanted. Am I missing something here?

I cannot reproduce that. The name of the kernel is certainly not
backtracked by Seaside.

Did you press 'refresh' to see the change? Just hitting the back
button only shows you the page from the browser cache.

>> The widgets you wrapped do
>> work on the complete system though.
>
> You are right. To make this difference explicit, I'm actually making these
> widget adaptors available in a separate toolbar, that looks like this:
>
> PRDistribution >> admintoolsPage
>
> ? ? ? ?admintoolsPage ifNotNil: [^admintoolsPage].
>
> ? ? ? ?adminComp := PRComponent named: 'widget'.
> ? ? ? ?adminComp
> ? ? ? ? ? ? ? ?componentClass: PRCommandsWidget;
> ? ? ? ? ? ? ? ?write: AAsWidgetAdaptorCommand allSubclasses using:
> PRCommandsWidget descriptionCommandClasses.
>
> ? ? ? ?admintoolsPage:= (PRPage named: 'admintools')
> ? ? ? ? ? ? ? ?addChild: adminComp;
> ? ? ? ? ? ? ? ?contents: 'Admin tools: +widget+';
> ? ? ? ? ? ? ? ?yourself.
>
> ? ? ? ?^admintoolsPage
>
> This assumes that those widget adaptors are additionally excluded from
> #commandsPage.

I think the wrappers are conceptually wrong in the way Pier-Setup
creates a default distribution. The wrappers violate the principle of
providing functionality at one place and through one mechanism only.
For example, in my setup I don't see I reason why I would want to be
able to edit the name of the kernel from anywhere.

Maybe there are other setups where that might make sense? That's why I
suggested to package the wrappers separately so that people that want
to use it can load it. And other are not forced to have to deal with a
proliferation of unrelated commands.

>> Also your strategy of wrapping the
>> widgets into commands makes security sort of fragile.
>
> This is an important issue. Could you develop this a little more please?

If anywhere -- on potentially thousands of pages (like in the seaside
book) -- you (accidentally) give the permissions to edit the kernel
name, anybody is able to change it. In the current default setup you
just have to make sure that the system page and its children are
protected.

Lukas


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


From renggli at gmail.com  Sat Feb 20 12:48:29 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 12:48:29 +0100
Subject: Pier questions
In-Reply-To: <8bbtuf$10v9c7@smtp.pt.lu>
References: <32327224-4F29-42DE-AC14-60C1F90C0188@tiscali.it> 
	<67628d691002200048h1899c453v9aa5bf2dece899b2@mail.gmail.com> 
	<8bbtuf$10v9c7@smtp.pt.lu>
Message-ID: <67628d691002200348p6d3b8138l4fe5954b80538c7f@mail.gmail.com>

Loading the latest code for Magritte and Pier should solve the problem
in both, version 1 and 2.

Lukas

On 20 February 2010 11:12, Reza RAZAVI <razavi at acm.org> wrote:
> At 09:48 20/02/2010, Lukas Renggli wrote:
>>
>> That's a bug, I've seen that too at some time, but never managed to
>> reliably reproduce.
>
> It looks like being related to a mismatch between the actual and cached
> values in MAMultipleOptionDescription >> validateKind:. I don't have the
> exact context within within the bug appears, but was wondering if it could
> be caused by MADynamicObject.
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From nick.ager at gmail.com  Sat Feb 20 12:50:15 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sat, 20 Feb 2010 11:50:15 +0000
Subject: fix for PREditorHelp in Pier-EditorEnh
Message-ID: <3a06f76f1002200350o53494dfxef01f810253f72a5@mail.gmail.com>

Hi,

I noticed that the help button on the enhanced editor was broken in
Pier/Seaside 3.0. I've attached a simple fix, though as I don't entirely
understand the intent of the implementation, it would be good if someone can
review it to check the bug shouldn't be fixed elsewhere.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100220/7af7a2b5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-EditorEnh-NickAger.55.mcz
Type: application/octet-stream
Size: 45901 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100220/7af7a2b5/attachment-0001.obj>

From renggli at gmail.com  Sat Feb 20 13:26:34 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 13:26:34 +0100
Subject: fix for PREditorHelp in Pier-EditorEnh
In-Reply-To: <3a06f76f1002200350o53494dfxef01f810253f72a5@mail.gmail.com>
References: <3a06f76f1002200350o53494dfxef01f810253f72a5@mail.gmail.com>
Message-ID: <67628d691002200426n1764d7bdqe7afc186b5c09134@mail.gmail.com>

Good catch.

I've committed your code and a few minor changes to the repository.

Lukas

On 20 February 2010 12:50, Nick Ager <nick.ager at gmail.com> wrote:
> Hi,
> I noticed that the help button on the enhanced editor was broken in
> Pier/Seaside 3.0. I've attached a simple fix, though as I don't entirely
> understand the intent of the implementation, it would be good if someone can
> review it to check the bug shouldn't be fixed elsewhere.
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From p3anoman at gmail.com  Sat Feb 20 15:20:53 2010
From: p3anoman at gmail.com (John McKeon)
Date: Sat, 20 Feb 2010 09:20:53 -0500
Subject: magrite toOne relationship and component creation
In-Reply-To: <67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com>
References: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>
	<67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com>
Message-ID: <40f637ec1002200620l2982e89fn4dfdc326b2dbb3d@mail.gmail.com>

Hello Lukas,

On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli at gmail.com> wrote:

> > Shouldn't
> >
> > MARelationComponent>>editorFor: anObject
> >        ^ (self description reference asComponentOn: anObject)
> >                addValidatedForm;
> >                yourself
> >
> > be rather
> >
> > MARelationComponent>>editorFor: anObject
> >        ^ (anObject description asComponentOn: anObject)
> >                addValidatedForm;
> >                yourself
> >
> > ?
>
> It depends what you want to do. I suggest that you create a subclass
> that works for your use-case.
>
> As I already explained here several times, I've personally never used
> the relationships. I rarely found the default behavior useful, and
> another default behavior was not useful in other contexts.
>

I have always found this statement to be somewhat disturbing on each of
those several occasions.
Could you elaborate on this a little? What *would* you use to describe a
collection? Do you mean that you always subclass the needed relationship
classes to suit your needs?

Thanks
John


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



-- 
http://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100220/b7a2bea8/attachment.html>

From norbert at hartl.name  Sat Feb 20 19:27:56 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Sat, 20 Feb 2010 19:27:56 +0100
Subject: magrite toOne relationship and component creation
In-Reply-To: <40f637ec1002200620l2982e89fn4dfdc326b2dbb3d@mail.gmail.com>
References: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>
	<67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com>
	<40f637ec1002200620l2982e89fn4dfdc326b2dbb3d@mail.gmail.com>
Message-ID: <E4D306B7-26DF-47E4-B9D4-E0EEAEA4F1DD@hartl.name>

Lukas,

I must agree with John. I never understood your quick and anti-relationship responses. I think it is an important part of the meta model that you can try to model a complex scenario with relationships. I agree that it is difficult to find a default behaviour of all those. I would like to hear your answers to Johns questions as well.

Just to repeat myself. You can specify a relationship to a variety of possible target classes. I'm not sure what reference is meant for exaclty but I can't barely imagine a case where the component to build is not dependent on the object being edited. I would be glad to hear something that conflicts with this.

thanks,

Norbert
 
On 20.02.2010, at 15:20, John McKeon wrote:

> Hello Lukas,
> 
> On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli at gmail.com> wrote:
> > Shouldn't
> >
> > MARelationComponent>>editorFor: anObject
> >        ^ (self description reference asComponentOn: anObject)
> >                addValidatedForm;
> >                yourself
> >
> > be rather
> >
> > MARelationComponent>>editorFor: anObject
> >        ^ (anObject description asComponentOn: anObject)
> >                addValidatedForm;
> >                yourself
> >
> > ?
> 
> It depends what you want to do. I suggest that you create a subclass
> that works for your use-case.
> 
> As I already explained here several times, I've personally never used
> the relationships. I rarely found the default behavior useful, and
> another default behavior was not useful in other contexts.
> 
> I have always found this statement to be somewhat disturbing on each of those several occasions. 
> Could you elaborate on this a little? What *would* you use to describe a collection? Do you mean that you always subclass the needed relationship classes to suit your needs? 
> 
> Thanks
> John
> 
> 
> Lukas
> 
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> 
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 
> 
> 
> -- 
> http://jmck.seasidehosting.st
> _______________________________________________
> 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/20100220/fab62d70/attachment.html>

From renggli at gmail.com  Sat Feb 20 19:52:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 19:52:11 +0100
Subject: magrite toOne relationship and component creation
In-Reply-To: <E4D306B7-26DF-47E4-B9D4-E0EEAEA4F1DD@hartl.name>
References: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name> 
	<67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com> 
	<40f637ec1002200620l2982e89fn4dfdc326b2dbb3d@mail.gmail.com> 
	<E4D306B7-26DF-47E4-B9D4-E0EEAEA4F1DD@hartl.name>
Message-ID: <67628d691002201052k46b2ec9ch4bf74b4780c349b2@mail.gmail.com>

> I must agree with John. I never understood your quick and anti-relationship
> responses. I think it is an important part of the meta model that you can
> try to model a complex scenario with relationships. I agree that it is
> difficult to find a default behaviour of all those. I would like to hear
> your answers to Johns questions as well.

The relationships work for simple things. In practice however I have
always felt the need to customize the descriptions through one or more
of the extension mechanisms in Magritte, either for usability or to
satisfy particular customer requests.

I must say that the current implementation is more at the state of a
proof of concept. I never used relationships in any project (other
than the Magritte meta editor in Magritte itself), it is largely
untested in practice. The only changes relationships have seen since
my Master in 2006 were fixes that other people have submitted. The
fact that some of these fixes got reverted again by newer fixes has
led me to the conclusion that at least in the current form the
implementation of relationships is fragile and I refrain from
suggesting its use.

I found it more flexible and user-friendly to let Magritte create
simple components only. I would then compose these individual
components in a master component. This allows one to easily create
arbitrary complex forms with custom navigation between different
objects that exactly match the wishes of the customer with relatively
little glue code.

I know that other web and meta-frameworks go much further here. I
would not mind somebody talking over the issue an implement (and
maintain) better working and well tested relationship descriptions
that solve the current problems.

Lukas






> Just to repeat myself. You can specify a relationship to a variety of
> possible target classes. I'm not sure what reference is meant for exaclty
> but I can't barely imagine a case where the component to build is not
> dependent on the object being edited. I would be glad to hear something that
> conflicts with this.
> thanks,
> Norbert
>
> On 20.02.2010, at 15:20, John McKeon wrote:
>
> Hello Lukas,
>
> On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli at gmail.com> wrote:
>>
>> > Shouldn't
>> >
>> > MARelationComponent>>editorFor: anObject
>> > ? ? ? ?^ (self description reference asComponentOn: anObject)
>> > ? ? ? ? ? ? ? ?addValidatedForm;
>> > ? ? ? ? ? ? ? ?yourself
>> >
>> > be rather
>> >
>> > MARelationComponent>>editorFor: anObject
>> > ? ? ? ?^ (anObject description asComponentOn: anObject)
>> > ? ? ? ? ? ? ? ?addValidatedForm;
>> > ? ? ? ? ? ? ? ?yourself
>> >
>> > ?
>>
>> It depends what you want to do. I suggest that you create a subclass
>> that works for your use-case.
>>
>> As I already explained here several times, I've personally never used
>> the relationships. I rarely found the default behavior useful, and
>> another default behavior was not useful in other contexts.
>
> I have always found this statement to be somewhat disturbing on each of
> those several occasions.
> Could you elaborate on this a little? What *would* you use to describe a
> collection? Do you mean that you always subclass the needed relationship
> classes to suit your needs?
> Thanks
> John
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> --
> http://jmck.seasidehosting.st
> _______________________________________________
> 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
http://www.lukas-renggli.ch


From razavi at acm.org  Sat Feb 20 21:01:24 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sat, 20 Feb 2010 21:01:24 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002200323y58da8e6bo98f38b167f15eab1@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<8bbtuf$107hbs@smtp.pt.lu>
	<67628d691002171240u5720cf4sdb68c4cce1368b56@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com>
	<89dhun$t85ff@smtp.pt.lu>
	<67628d691002200323y58da8e6bo98f38b167f15eab1@mail.gmail.com>
Message-ID: <89dhun$tjuc0@smtp.pt.lu>

Hi Lukas,

Thanks again for your time and precisions!

At 12:23 20/02/2010, Lukas Renggli wrote:
>Did you press 'refresh' to see the change?

No.

>Just hitting the back
>button only shows you the page from the browser cache.

Just double checked it, and you are perfectly right. The new value is 
maintained. What I observed when using the back button was the value 
cached by the browser.

>Maybe there are other setups where that might make sense?

Sure. For example, for practical reasons, I've preferred replacing 
the *management* page with a specific *admin toolbar*, which is 
actually only accessible to the *root* (and not users with *admin* rights).

>That's why I
>suggested to package the wrappers separately.

There is some progress in that direction, but some extra work is 
necessary. The first package that I posted lacks usage examples. The 
2nd package addresses this issue, but patches PRDistribution. Now, 
I'm going to sub-class PRDistribution. However, before posting the 
final package, would you please tell me your preference for one of 
the followings:
1) The warper commands and the new distribution class integrated in 
Pier-Setup as package.
2) The warper commands and the new distribution class integrated in a 
new package.

I'd prefer the first one to avoid an additional package for a piece 
of code that addresses basically the same needs than "Pier-Setup".

>If anywhere -- on potentially thousands of pages (like in the seaside
>book)

That's an interesting use case indeed. Would it be possible to 
communicate more precisely the number of Pier structures that 
contains Seaside book (just curious)?

>  -- you (accidentally) give the permissions to edit the kernel
>name, anybody is able to change it. In the current default setup you
>just have to make sure that the system page and its children are
>protected.

Well noted; thanks for the precision. In my current experimental 
distribution, I've addressed this issue as follows:
1) Added a "root" user (called *master*), and
2) Overridden PRCommand class >> #valideIn: for wrapper widgets to 
return true only if the current user is master (and not superusers).

Regards,
Reza


From renggli at gmail.com  Sat Feb 20 21:14:55 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 20 Feb 2010 21:14:55 +0100
Subject: Widget to Command adaptor
In-Reply-To: <89dhun$tjuc0@smtp.pt.lu>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com> 
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com> 
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com> 
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com> 
	<89dhun$t85ff@smtp.pt.lu>
	<67628d691002200323y58da8e6bo98f38b167f15eab1@mail.gmail.com> 
	<89dhun$tjuc0@smtp.pt.lu>
Message-ID: <67628d691002201214p549e5fcbp23b2dbf60f5fcb4f@mail.gmail.com>

>> Maybe there are other setups where that might make sense?
>
> Sure. For example, for practical reasons, I've preferred replacing the
> *management* page with a specific *admin toolbar*, which is actually only
> accessible to the *root* (and not users with *admin* rights).

That's not how the one-click images are setup, thus I would prefer if
you created your own package.

>> If anywhere -- on potentially thousands of pages (like in the seaside
>> book)
>
> That's an interesting use case indeed. Would it be possible to communicate
> more precisely the number of Pier structures that contains Seaside book
> (just curious)?

Not that many, only 673.

Lukas

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

From razavi at acm.org  Sun Feb 21 00:14:42 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sun, 21 Feb 2010 00:14:42 +0100
Subject: Widget to Command adaptor
In-Reply-To: <67628d691002201214p549e5fcbp23b2dbf60f5fcb4f@mail.gmail.co
 m>
References: <3a06f76f1002171056q7423b355uafd027a33d445266@mail.gmail.com>
	<89dhun$stl3a@smtp.pt.lu>
	<67628d691002180236i5bfe6409l30745b74b0f41680@mail.gmail.com>
	<89dhun$t1b8u@smtp.pt.lu>
	<67628d691002180622j77c53f99n37841ddab30bc6b6@mail.gmail.com>
	<8bbtuf$10f57u@smtp.pt.lu>
	<67628d691002181314m1996fdd0o148ab369cbffab98@mail.gmail.com>
	<89dhun$t85ff@smtp.pt.lu>
	<67628d691002200323y58da8e6bo98f38b167f15eab1@mail.gmail.com>
	<89dhun$tjuc0@smtp.pt.lu>
	<67628d691002201214p549e5fcbp23b2dbf60f5fcb4f@mail.gmail.com>
Message-ID: <89dhun$tkjov@smtp.pt.lu>

At 21:14 20/02/2010, you wrote:
>That's not how the one-click images are setup, thus I would prefer if
>you created your own package.

I just uploaded AAS-Pier-Widget Adaptors that:
- Adds a new *system administration* toolbar, which contains the 
*widget adaptor commands*, and is only accessible to the *master* user.
- Moves all toolbars to the top of the page (instead of the bottom).
- Patches Pier code to add a Close button to system administration widgets.

May I ask you please to remove from your repository the deprecated 
"AAS- Pier Commands-Widget Adaptors".

>673.

Great work; thanks for the information.
Regards,
Reza


From razavi at acm.org  Sun Feb 21 00:31:09 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sun, 21 Feb 2010 00:31:09 +0100
Subject: BookDistribution update & a few minor Book issues report
Message-ID: <89dhun$tkl4a@smtp.pt.lu>

Hi Lukas,

I also uploaded *Pier-Setup-razavi_acm_org.80* that fixes a minor 
issue with PRBookDistribution. For more info, please see that package 
and its comments.

Additionally, I'd like your attention to:
- The fact that * Pier-Book-lr.138* calls in several places 
#trimBlanks, specifically in BOLatexWriter and BONote, while my Pharo 
image does not contain this method and consequently the execution fails.
- The two other minor issues exposed in an email sent a few days ago, 
and reproduced below.

Regards,
Reza

>Date: Tue, 16 Feb 2010 17:47:56 +0100
>To: "Magritte, Pier and Related Tools ..." <smallwiki at iam.unibe.ch>
>From: Reza RAZAVI <razavi at acm.org>
>Subject: Book navigation rendering issue report
>
>Hi,
>
>After having upgraded to the latest Seaside 3 and Pier 2 packages, I 
>encounter a minor issue that could be regenerated as follows:
>1) Evaluate in a workspace "PRBookDistribution new register"
>2) Point to http://localhost:8080/pier/book/table-of-contents
>
>The navigation arrows are not rendered anymore. Instead, appear 
>their textual encoding (&rarr and &larr). It is the same for 
>non-breaking space that appears as &nbsp (See for example 
>http://localhost:8080/pier/book), as well as other codifications like &sect.
>
>Otherwise, I was wondering if in:
>         BOLatexWriter >> convertHtmlEntities:
>
>the following:
>         copyReplaceAll: '&rarr;' with: '<-'
>
>shouldn't be rather:
>         copyReplaceAll: '&rarr;' with: '->'
>
>Cheers,
>Reza


From p3anoman at gmail.com  Sun Feb 21 03:57:06 2010
From: p3anoman at gmail.com (John McKeon)
Date: Sat, 20 Feb 2010 21:57:06 -0500
Subject: magrite toOne relationship and component creation
In-Reply-To: <67628d691002201052k46b2ec9ch4bf74b4780c349b2@mail.gmail.com>
References: <3F6E1B86-4FAA-4923-AD46-B25E319B5BCE@hartl.name>
	<67628d691002200045o2871d2b1yb297c0b4080e6337@mail.gmail.com>
	<40f637ec1002200620l2982e89fn4dfdc326b2dbb3d@mail.gmail.com>
	<E4D306B7-26DF-47E4-B9D4-E0EEAEA4F1DD@hartl.name>
	<67628d691002201052k46b2ec9ch4bf74b4780c349b2@mail.gmail.com>
Message-ID: <40f637ec1002201857u4fbb763x2895c7d2685d0998@mail.gmail.com>

On Sat, Feb 20, 2010 at 1:52 PM, Lukas Renggli <renggli at gmail.com> wrote:

> > I must agree with John. I never understood your quick and
> anti-relationship
> > responses. I think it is an important part of the meta model that you can
> > try to model a complex scenario with relationships. I agree that it is
> > difficult to find a default behaviour of all those. I would like to hear
> > your answers to Johns questions as well.
>
> The relationships work for simple things. In practice however I have
> always felt the need to customize the descriptions through one or more
> of the extension mechanisms in Magritte, either for usability or to
> satisfy particular customer requests.
>
> I must say that the current implementation is more at the state of a
> proof of concept. I never used relationships in any project (other
> than the Magritte meta editor in Magritte itself), it is largely
> untested in practice. The only changes relationships have seen since
> my Master in 2006 were fixes that other people have submitted. The
> fact that some of these fixes got reverted again by newer fixes has
> led me to the conclusion that at least in the current form the
> implementation of relationships is fragile and I refrain from
> suggesting its use.
>
> I found it more flexible and user-friendly to let Magritte create
> simple components only. I would then compose these individual
> components in a master component. This allows one to easily create
> arbitrary complex forms with custom navigation between different
> objects that exactly match the wishes of the customer with relatively
> little glue code.
>
> I know that other web and meta-frameworks go much further here. I
> would not mind somebody talking over the issue an implement (and
> maintain) better working and well tested relationship descriptions
> that solve the current problems.
>
> Lukas
>
>
>
Thank you for your reply Lukas. This is very illuminating. I have not
ventured much further than the typical "invoice/line item" type of
relationships so I have yet to run into any problems that cannot be overcome
by overriding and adding some special behavior. For now I find them quite
useful.

I am thinking over the last paragraph before committing to anything, though
it is an enticing offer. Does it pay well?

Thanks again

John


>
>
>
> > Just to repeat myself. You can specify a relationship to a variety of
> > possible target classes. I'm not sure what reference is meant for exaclty
> > but I can't barely imagine a case where the component to build is not
> > dependent on the object being edited. I would be glad to hear something
> that
> > conflicts with this.
> > thanks,
> > Norbert
> >
> > On 20.02.2010, at 15:20, John McKeon wrote:
> >
> > Hello Lukas,
> >
> > On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli at gmail.com>
> wrote:
> >>
> >> > Shouldn't
> >> >
> >> > MARelationComponent>>editorFor: anObject
> >> >        ^ (self description reference asComponentOn: anObject)
> >> >                addValidatedForm;
> >> >                yourself
> >> >
> >> > be rather
> >> >
> >> > MARelationComponent>>editorFor: anObject
> >> >        ^ (anObject description asComponentOn: anObject)
> >> >                addValidatedForm;
> >> >                yourself
> >> >
> >> > ?
> >>
> >> It depends what you want to do. I suggest that you create a subclass
> >> that works for your use-case.
> >>
> >> As I already explained here several times, I've personally never used
> >> the relationships. I rarely found the default behavior useful, and
> >> another default behavior was not useful in other contexts.
> >
> > I have always found this statement to be somewhat disturbing on each of
> > those several occasions.
> > Could you elaborate on this a little? What *would* you use to describe a
> > collection? Do you mean that you always subclass the needed relationship
> > classes to suit your needs?
> > Thanks
> > John
> >>
> >> Lukas
> >>
> >> --
> >> Lukas Renggli
> >> http://www.lukas-renggli.ch
> >>
> >> _______________________________________________
> >> Magritte, Pier and Related Tools ...
> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
> >
> >
> > --
> > http://jmck.seasidehosting.st
> > _______________________________________________
> > 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
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



-- 
http://jmck.seasidehosting.st
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100220/a304d7cf/attachment.html>

From renggli at gmail.com  Sun Feb 21 09:42:00 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 09:42:00 +0100
Subject: BookDistribution update & a few minor Book issues report
In-Reply-To: <89dhun$tkl4a@smtp.pt.lu>
References: <89dhun$tkl4a@smtp.pt.lu>
Message-ID: <67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com>

> Additionally, I'd like your attention to:
> - The fact that * Pier-Book-lr.138* calls in several places #trimBlanks,
> specifically in BOLatexWriter and BONote, while my Pharo image does not
> contain this method and consequently the execution fails.

Thank you, I've replaced those.

> - The two other minor issues exposed in an email sent a few days ago, and
> reproduced below.

Sorry, I've must have missed that. I've fixed that as well.

Lukas

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

From razavi at acm.org  Sun Feb 21 10:03:31 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sun, 21 Feb 2010 10:03:31 +0100
Subject: BookDistribution update & a few minor Book issues report
In-Reply-To: <67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.co
 m>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com>
Message-ID: <89dhun$tm6op@smtp.pt.lu>

At 09:42 21/02/2010, Lukas Renggli wrote:
>I've replaced those.

I integrated them; thank you so much!
Reza 


From nick.ager at gmail.com  Sun Feb 21 11:23:45 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 21 Feb 2010 10:23:45 +0000
Subject: PREnumberableVisitor detect: protocol
Message-ID: <3a06f76f1002210223g3c873593m4282eb04f0e40563@mail.gmail.com>

Hi,

In a couple of places in my app I found that I was writing in effect a
detect: method using PREnumberableVisitor>>do. So I thought I'd add detect:
to PREnumberableVisitor which makes the intent of my code much clearer.
Would this be useful addition generally? I've attached an mcz of
the PREnumberableVisitor additions and another of tests to exercise the
additions.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100221/7315faaa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-Model-NickAger.382.mcz
Type: application/octet-stream
Size: 119748 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100221/7315faaa/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-Tests-Model-NickAger.10.mcz
Type: application/octet-stream
Size: 49791 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100221/7315faaa/attachment-0003.obj>

From razavi at acm.org  Sun Feb 21 11:35:36 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sun, 21 Feb 2010 11:35:36 +0100
Subject: Another minor rendering issue 
In-Reply-To: <67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.co
 m>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com>
Message-ID: <8bbtuf$1156u8@smtp.pt.lu>

At 09:42 21/02/2010, you wrote:
>I've fixed that as well.

Hi Lukas,

Please note that there are other minor rendering 
issues since you added PRVerbatim. Here are two examples:
1) I had a blog post with html markups inside as 
follows: <b>some text</b>. Before verbatim, I was 
getting *some text* in bold as expected. Now, I get <b>some text</b>.

2) In my experimental distribution, I instantiate 
a book with the following title in French:

book title: 'Maintien et d?veloppement de la qualit? de l''enseignement';

Now, if I try to remove the book node, here is what happens:

2.a) *PRRemoveCommand >> confirmation* generates the following wiki string:

'!Do you really want to remove ''Maintien et 
d?veloppement de la qualit? de l''''enseignement''?
There are 8 child structures:
# */book/table-of-contents*
# */book/table-of-figures*
# */book/index*
# */book/introduction*
There is 1 incoming reference:
# */system/menu*
'

2.b) The above wiki text is parsed by 
PRDocumentParser, but rendered verbatim, exactly 
as above, and is not interpreted (specifically, 
the internal links do not appear).

However, the issue disappears when I remove 
*l''enseignement* from the title. It is then 
certainly related to the double ' in that French word.

Regards,
Reza



From renggli at gmail.com  Sun Feb 21 11:35:24 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 11:35:24 +0100
Subject: PREnumberableVisitor detect: protocol
In-Reply-To: <3a06f76f1002210223g3c873593m4282eb04f0e40563@mail.gmail.com>
References: <3a06f76f1002210223g3c873593m4282eb04f0e40563@mail.gmail.com>
Message-ID: <67628d691002210235n752d6adax92e997182dea2cae@mail.gmail.com>

Sounds cool, I've uploaded it to the repository.

Lukas

On 21 February 2010 11:23, Nick Ager <nick.ager at gmail.com> wrote:
> Hi,
> In a couple of places in my app I found that I was writing in effect a
> detect: method using PREnumberableVisitor>>do. So I thought I'd add detect:
> to?PREnumberableVisitor which makes the intent of my code much clearer.
> Would this be useful addition generally? I've attached an mcz of
> the?PREnumberableVisitor additions?and another of tests to exercise the
> additions.
> Nick
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From renggli at gmail.com  Sun Feb 21 11:37:07 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 11:37:07 +0100
Subject: Another minor rendering issue
In-Reply-To: <8bbtuf$1156u8@smtp.pt.lu>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com> 
	<8bbtuf$1156u8@smtp.pt.lu>
Message-ID: <67628d691002210237q8a3ff07wc99b4e1e418c6b9a@mail.gmail.com>

> Please note that there are other minor rendering issues since you added
> PRVerbatim. Here are two examples:

Could you add tests?

Lukas


> 1) I had a blog post with html markups inside as follows: <b>some text</b>.
> Before verbatim, I was getting *some text* in bold as expected. Now, I get
> <b>some text</b>.
>
> 2) In my experimental distribution, I instantiate a book with the following
> title in French:
>
> book title: 'Maintien et d?veloppement de la qualit? de l''enseignement';
>
> Now, if I try to remove the book node, here is what happens:
>
> 2.a) *PRRemoveCommand >> confirmation* generates the following wiki string:
>
> '!Do you really want to remove ''Maintien et d?veloppement de la qualit? de
> l''''enseignement''?
> There are 8 child structures:
> # */book/table-of-contents*
> # */book/table-of-figures*
> # */book/index*
> # */book/introduction*
> There is 1 incoming reference:
> # */system/menu*
> '
>
> 2.b) The above wiki text is parsed by PRDocumentParser, but rendered
> verbatim, exactly as above, and is not interpreted (specifically, the
> internal links do not appear).
>
> However, the issue disappears when I remove *l''enseignement* from the
> title. It is then certainly related to the double ' in that French word.
>
> Regards,
> Reza
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From renggli at gmail.com  Sun Feb 21 11:44:42 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 11:44:42 +0100
Subject: Another minor rendering issue
In-Reply-To: <8bbtuf$1156u8@smtp.pt.lu>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com> 
	<8bbtuf$1156u8@smtp.pt.lu>
Message-ID: <67628d691002210244g79ed0791vd38f80be83348ebd@mail.gmail.com>

> Please note that there are other minor rendering issues since you added
> PRVerbatim. Here are two examples:

Sorry, I thought you were referring to some bugs in the parser, I
should properly read the mail first before answering.

> 1) I had a blog post with html markups inside as follows: <b>some text</b>.
> Before verbatim, I was getting *some text* in bold as expected. Now, I get
> <b>some text</b>.

That's the expected behavior. If you want HTML tags in your code you
need to put it inside a verbatim part. Mixing HTML with wiki is
problematic, because it destroys the independence of the output
format. This is especially problematic for Pier-Book, for example.

To get bold text you should use the markup ""some text"", not the HTML tags.

> 2) In my experimental distribution, I instantiate a book with the following
> title in French:
>
> book title: 'Maintien et d?veloppement de la qualit? de l''enseignement';
>
> Now, if I try to remove the book node, here is what happens:
>
> 2.a) *PRRemoveCommand >> confirmation* generates the following wiki string:
>
> '!Do you really want to remove ''Maintien et d?veloppement de la qualit? de
> l''''enseignement''?
> There are 8 child structures:
> # */book/table-of-contents*
> # */book/table-of-figures*
> # */book/index*
> # */book/introduction*
> There is 1 incoming reference:
> # */system/menu*
> '
>
> 2.b) The above wiki text is parsed by PRDocumentParser, but rendered
> verbatim, exactly as above, and is not interpreted (specifically, the
> internal links do not appear).
>
> However, the issue disappears when I remove *l''enseignement* from the
> title. It is then certainly related to the double ' in that French word.

Ok, that was a stupid hack. I'll fix that.

Lukas

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


From razavi at acm.org  Sun Feb 21 12:31:46 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sun, 21 Feb 2010 12:31:46 +0100
Subject: Another minor rendering issue
In-Reply-To: <67628d691002210244g79ed0791vd38f80be83348ebd@mail.gmail.co
 m>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com>
	<8bbtuf$1156u8@smtp.pt.lu>
	<67628d691002210244g79ed0791vd38f80be83348ebd@mail.gmail.com>
Message-ID: <8bbtuf$115h21@smtp.pt.lu>

At 11:44 21/02/2010, Lukas Renggli wrote:
>Mixing HTML with wiki is
>problematic, because it destroys the independence of the output
>format.
[...]
>To get bold text you should use the markup ""some text"", not the HTML tags.

Sure, but in that case I wouldn't have encountered that issue, and 
consequently learnt the above interesting point -:)

>I'll fix that.

Already integrated, and tested; many thanks again!

BTW, may I ask you considering the integration of the following minor 
change into your code base:

PRListWidget >> renderContentOn: html
         | items |
         items := self items.
         items isEmpty
                 ifFalse: [ self renderItems: "self" items on: html ]

It just avoids computing twice the items list, and would allow me 
removing this from my patch list.

Regards,
Reza 


From renggli at gmail.com  Sun Feb 21 13:17:54 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 13:17:54 +0100
Subject: Another minor rendering issue
In-Reply-To: <8bbtuf$115h21@smtp.pt.lu>
References: <89dhun$tkl4a@smtp.pt.lu>
	<67628d691002210042h1e148666r47a0ddf829982598@mail.gmail.com> 
	<8bbtuf$1156u8@smtp.pt.lu>
	<67628d691002210244g79ed0791vd38f80be83348ebd@mail.gmail.com> 
	<8bbtuf$115h21@smtp.pt.lu>
Message-ID: <67628d691002210417v5df036cds305d469a1b991cbb@mail.gmail.com>

> BTW, may I ask you considering the integration of the following minor change
> into your code base:
>
> PRListWidget >> renderContentOn: html
> ? ? ? ?| items |
> ? ? ? ?items := self items.
> ? ? ? ?items isEmpty
> ? ? ? ? ? ? ? ?ifFalse: [ self renderItems: "self" items on: html ]
>
> It just avoids computing twice the items list, and would allow me removing
> this from my patch list.

Ahh, thanks for spotting that.

Lukas

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


From nick.ager at gmail.com  Sun Feb 21 15:26:15 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 21 Feb 2010 14:26:15 +0000
Subject: PRTagCloudWidget and PRVerbatim
Message-ID: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>

Hi,
I'm using a PRTagCloudWidget and I've noticed that I'm seeing "div" appear
as popular tag - which comes from the verbatim sections of my page's
environment. I'd have thought that ideally verbatim sections shouldn't be
included in tag cloud tokenisation???

Assuming I haven't missed some simple mechanism for extracting a pages
contents without the verbatim section, I've been pondering how I'd
 implement it. I can see that by creating a visitor, say
PRTagCloudTextWriter,  and leaving the implementation
of PRTagCloudTextWriter>>visitVerbatim: blank the resulting text will be
free of any PRVerbatim objects. However I'm unsure how to wire it all
together. Currently PRTagCloudWidget reads a page contents via  PRCase
class>>descriptionDocument which uses the PRCase>>document accessor, which
give wiki text output. My initial implementation thoughts would be:
1) add a new accessor to PRCase say cloudText (as a PRTagCloudWidget
extension)
2) PRCase>>cloudText would use PRTagCloudTextWriter to extract plain text
without PRVerbatim content
3) PRTagCloudWidget, then needs a mechanism for tagging PRCase>>cloudText as
the accessor it should use, in preference to  PRCase
class>>descriptionDocument. How about introducing PRCase
class>>cloudTextdescriptionDocument  (as a PRTagCloudWidget extension),
which
PRTagCloudWidget would find and realise that it should be used in preference
to PRCase class>>descriptionDocument??

Or perhaps I've missed something really simple???

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

From renggli at gmail.com  Sun Feb 21 15:35:44 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 21 Feb 2010 15:35:44 +0100
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
Message-ID: <67628d691002210635w71180665q321be494d7452881@mail.gmail.com>

On 21 February 2010 15:26, Nick Ager <nick.ager at gmail.com> wrote:
> Hi,
> I'm using a?PRTagCloudWidget and I've noticed that I'm seeing "div" appear
> as popular tag - which comes from the verbatim sections of my page's
> environment. I'd have thought that ideally verbatim sections shouldn't be
> included in tag cloud tokenisation???

I think the PRTextWriter should probably not include the verbatim
text. I'll remove it from there.

Lukas


> Assuming I haven't missed some simple mechanism for extracting a pages
> contents without the verbatim section, I've been pondering how I'd
> ?implement it.?I can see that by creating a visitor, say
> PRTagCloudTextWriter, ?and leaving the implementation
> of?PRTagCloudTextWriter>>visitVerbatim: blank the resulting text will be
> free of any PRVerbatim objects. However I'm unsure how to wire it all
> together. Currently?PRTagCloudWidget reads a page contents via??PRCase
> class>>descriptionDocument which uses the PRCase>>document accessor, which
> give wiki text output. My initial implementation thoughts would be:
> 1) add a new accessor to PRCase say cloudText (as a?PRTagCloudWidget
> extension)
> 2)?PRCase>>cloudText would use?PRTagCloudTextWriter to extract plain text
> without PRVerbatim content
> 3)?PRTagCloudWidget, then needs a mechanism for tagging?PRCase>>cloudText as
> the accessor it should use, in preference to??PRCase
> class>>descriptionDocument. How about introducing PRCase
> class>>cloudTextdescriptionDocument??(as a?PRTagCloudWidget extension),
> which
> PRTagCloudWidget would find and realise that it should be used in preference
> to?PRCase class>>descriptionDocument??
> Or perhaps I've missed something really simple???
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From nick.ager at gmail.com  Sun Feb 21 15:44:58 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 21 Feb 2010 14:44:58 +0000
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <67628d691002210635w71180665q321be494d7452881@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com>
Message-ID: <3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com>

>
>
> I think the PRTextWriter should probably not include the verbatim
> text. I'll remove it from there.
>
>
Makes sense, though there's still the problem of how to make the
PRTagCloudWidget
have access to plain text rather than the current description which calls
PRCase>>document - wiki text.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100221/19fd0b47/attachment.html>

From nick.ager at gmail.com  Mon Feb 22 01:39:13 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Mon, 22 Feb 2010 00:39:13 +0000
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com>
	<3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com>
Message-ID: <3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com>

It turns out to be simpler than I original thought:
1) PRCase already includes an accessor #plainText
2) I added PRCase class>>descriptionPlainText and set it to #readOnly and
#beTagCloud
3) I removed PRCase class>>descriptionDocumentTextTagCloud: so that the wiki
text from the document is no longer included in the tag cloud.

Pier-TagCloud and Pier-Model mcz files are attached.

Nick

On 21 February 2010 14:44, Nick Ager <nick.ager at gmail.com> wrote:

>
>> I think the PRTextWriter should probably not include the verbatim
>> text. I'll remove it from there.
>>
>>
> Makes sense, though there's still the problem of how to make the PRTagCloudWidget
> have access to plain text rather than the current description which calls
> PRCase>>document - wiki text.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100222/d28909f0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-Model-NickAger.384.mcz
Type: application/octet-stream
Size: 119947 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100222/d28909f0/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-TagCloud-NickAger.13.mcz
Type: application/octet-stream
Size: 7547 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100222/d28909f0/attachment-0003.obj>

From norbert at hartl.name  Mon Feb 22 23:16:45 2010
From: norbert at hartl.name (Norbert Hartl)
Date: Mon, 22 Feb 2010 23:16:45 +0100
Subject: testing and pier
Message-ID: <293B34CF-6EAB-4E71-82D4-37D4212AEB59@hartl.name>

At the moment I'm doing a fun web project. The complete thing tries to go as close with pier as possible. When it comes to testing I used seaside testing so far. I'm interested what you guys are using mainly for testing your applications (seaside or pier). Is there any special kind of testing if it is about pier widgets and the like? 

I can imagine that using albatross it doesn't matter if it is plain seaside or pier. But probably there are neat things I don't even know off.

thanks in advance,

Norbert

From razavi at acm.org  Tue Feb 23 13:29:40 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Tue, 23 Feb 2010 13:29:40 +0100
Subject: PRSlideshow undeclared references to SUElement
In-Reply-To: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.co
 m>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
Message-ID: <89dhun$u9lut@smtp.pt.lu>

Hi Lukas,

What would be the best solution to get ride of those references to to 
SUElement in #updateAnimateOn: ?

Based-on the comments in *Scriptaculous-Core-lr.86*, I'd expect to 
find SUElement in *Scriptaculous-Core*. But this is not the case.

Thank you in advance,
Regards,
Reza


From renggli at gmail.com  Tue Feb 23 14:13:11 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 23 Feb 2010 14:13:11 +0100
Subject: PRSlideshow undeclared references to SUElement
In-Reply-To: <89dhun$u9lut@smtp.pt.lu>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com> 
	<89dhun$u9lut@smtp.pt.lu>
Message-ID: <67628d691002230513rd0d1db2mb9ec42247e85fa76@mail.gmail.com>

I don't think that PRSlideshow has been ported to Seaside 3 and Pier 2
yet. In Seaside 3 SUElement is called PTElement.

Lukas

On 23 February 2010 13:29, Reza RAZAVI <razavi at acm.org> wrote:
> Hi Lukas,
>
> What would be the best solution to get ride of those references to to
> SUElement in #updateAnimateOn: ?
>
> Based-on the comments in *Scriptaculous-Core-lr.86*, I'd expect to find
> SUElement in *Scriptaculous-Core*. But this is not the case.
>
> Thank you in advance,
> Regards,
> Reza
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From nickbrown at fastmail.fm  Tue Feb 23 14:19:53 2010
From: nickbrown at fastmail.fm (Nick Brown)
Date: Tue, 23 Feb 2010 13:19:53 +0000
Subject: Bug in PRCommandsWidget?
Message-ID: <1266931193.12020.1361439729@webmail.messagingengine.com>

Hi. 

I'm getting an error, "Command Classes: Invalid input given", after
adding a command to a PRCommandsWidget and clicking save.

Here's the simplest way that I can reproduce it:

Starting with the Pier-1.2 app image downloaded from piercms.com, log in
as admin, browse to environment >> commands >> widget, click edit. Move
the 'add' command over to the left hand list. Save the component. Edit
it again, move the 'add' command back to the right hand list, and click
save.

Thanks,
Nick Brown

From renggli at gmail.com  Tue Feb 23 14:22:54 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 23 Feb 2010 14:22:54 +0100
Subject: Bug in PRCommandsWidget?
In-Reply-To: <1266931193.12020.1361439729@webmail.messagingengine.com>
References: <1266931193.12020.1361439729@webmail.messagingengine.com>
Message-ID: <67628d691002230522w74565b7bmf05eb7b33fbad3aa@mail.gmail.com>

I fixed that problem a few days ago (see in the discussion in the
list). If you update Magritte to the very latest version the problem
should disappear.

Lukas


On 23 February 2010 14:19, Nick Brown <nickbrown at fastmail.fm> wrote:
> Hi.
>
> I'm getting an error, "Command Classes: Invalid input given", after
> adding a command to a PRCommandsWidget and clicking save.
>
> Here's the simplest way that I can reproduce it:
>
> Starting with the Pier-1.2 app image downloaded from piercms.com, log in
> as admin, browse to environment >> commands >> widget, click edit. Move
> the 'add' command over to the left hand list. Save the component. Edit
> it again, move the 'add' command back to the right hand list, and click
> save.
>
> Thanks,
> Nick Brown
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From nickbrown at fastmail.fm  Tue Feb 23 14:58:32 2010
From: nickbrown at fastmail.fm (Nick Brown)
Date: Tue, 23 Feb 2010 13:58:32 +0000
Subject: Bug in PRCommandsWidget?
In-Reply-To: <67628d691002230522w74565b7bmf05eb7b33fbad3aa@mail.gmail.com>
References: <1266931193.12020.1361439729@webmail.messagingengine.com>
	<67628d691002230522w74565b7bmf05eb7b33fbad3aa@mail.gmail.com>
Message-ID: <1266933512.21870.1361446219@webmail.messagingengine.com>

Ah, I didn't spot that. It looks like source.lukas-renggli.ch is down at
the moment; I'll update and try again when I can.

Cheers,
Nick Brown

On Tue, 23 Feb 2010 14:22 +0100, "Lukas Renggli" <renggli at gmail.com>
wrote:
> I fixed that problem a few days ago (see in the discussion in the
> list). If you update Magritte to the very latest version the problem
> should disappear.
> 
> Lukas
> 
> 
> On 23 February 2010 14:19, Nick Brown <nickbrown at fastmail.fm> wrote:
> > Hi.
> >
> > I'm getting an error, "Command Classes: Invalid input given", after
> > adding a command to a PRCommandsWidget and clicking save.
> >
> > Here's the simplest way that I can reproduce it:
> >
> > Starting with the Pier-1.2 app image downloaded from piercms.com, log in
> > as admin, browse to environment >> commands >> widget, click edit. Move
> > the 'add' command over to the left hand list. Save the component. Edit
> > it again, move the 'add' command back to the right hand list, and click
> > save.
> >
> > Thanks,
> > Nick Brown
> > _______________________________________________
> > Magritte, Pier and Related Tools ...
> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> >
> 
> 
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> 

From nickbrown at fastmail.fm  Tue Feb 23 15:50:41 2010
From: nickbrown at fastmail.fm (Nick Brown)
Date: Tue, 23 Feb 2010 14:50:41 +0000
Subject: Bug in PRCommandsWidget?
In-Reply-To: <1266933512.21870.1361446219@webmail.messagingengine.com>
References: <1266931193.12020.1361439729@webmail.messagingengine.com><67628d691002230522w74565b7bmf05eb7b33fbad3aa@mail.gmail.com>
	<1266933512.21870.1361446219@webmail.messagingengine.com>
Message-ID: <1266936641.3288.1361452589@webmail.messagingengine.com>

I've updated Magritte and it's working fine. Thanks Lukas.

While I was playing with it I decided to also upgrade Pier to the latest
version of the Pier-All package. A very minor thing I noticed after that
is that when I'm in the browse view, clicking the edit command always
takes me to edit the root component, rather than the component I was
looking at. In the normal view, edit seems to work fine.

Cheers,
Nick Brown


On Tue, 23 Feb 2010 13:58 +0000, "Nick Brown" <nickbrown at fastmail.fm>
wrote:
> Ah, I didn't spot that. It looks like source.lukas-renggli.ch is down at
> the moment; I'll update and try again when I can.
> 
> Cheers,
> Nick Brown
> 
> On Tue, 23 Feb 2010 14:22 +0100, "Lukas Renggli" <renggli at gmail.com>
> wrote:
> > I fixed that problem a few days ago (see in the discussion in the
> > list). If you update Magritte to the very latest version the problem
> > should disappear.
> > 
> > Lukas
> > 
> > 
> > On 23 February 2010 14:19, Nick Brown <nickbrown at fastmail.fm> wrote:
> > > Hi.
> > >
> > > I'm getting an error, "Command Classes: Invalid input given", after
> > > adding a command to a PRCommandsWidget and clicking save.
> > >
> > > Here's the simplest way that I can reproduce it:
> > >
> > > Starting with the Pier-1.2 app image downloaded from piercms.com, log in
> > > as admin, browse to environment >> commands >> widget, click edit. Move
> > > the 'add' command over to the left hand list. Save the component. Edit
> > > it again, move the 'add' command back to the right hand list, and click
> > > save.
> > >
> > > Thanks,
> > > Nick Brown
> > > _______________________________________________
> > > Magritte, Pier and Related Tools ...
> > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
> > >
> > 
> > 
> > 
> > -- 
> > Lukas Renggli
> > http://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
> 

From razavi at acm.org  Tue Feb 23 17:00:49 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Tue, 23 Feb 2010 17:00:49 +0100
Subject: PRSlideshow undeclared references to SUElement
In-Reply-To: <67628d691002230513rd0d1db2mb9ec42247e85fa76@mail.gmail.com
 >
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<89dhun$u9lut@smtp.pt.lu>
	<67628d691002230513rd0d1db2mb9ec42247e85fa76@mail.gmail.com>
Message-ID: <89dhun$uc47a@smtp.pt.lu>

At 14:13 23/02/2010, you wrote:
>I don't think that PRSlideshow has been ported to Seaside 3 and Pier 2
>yet.

This is actually why I'm having a look at it.

*Pier-Slideshow-lr.12* seems working just fine, but now I won't have 
time to test the animation.

As for *Pier-Slideshow-MMP.13*, it seems more tricky since looks like 
there are references to absent methods (e.g. #descriptionLooping & 
#descriptionWidth). I couldn't explain that. Maybe I'm missing something.

>In Seaside 3 SUElement is called PTElement.

Thanks Lukas! If the *Pier-Slideshow-lr.12* that I've in my current 
Pier 2 image, and have a little bit hacked, seems you useful as a 
basis for a full port to Pier 2, please let me know to upload it to 
your repository (Pier 2).

Cheers,
Reza


From renggli at gmail.com  Tue Feb 23 17:23:46 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 23 Feb 2010 17:23:46 +0100
Subject: PRSlideshow undeclared references to SUElement
In-Reply-To: <89dhun$uc47a@smtp.pt.lu>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com> 
	<89dhun$u9lut@smtp.pt.lu>
	<67628d691002230513rd0d1db2mb9ec42247e85fa76@mail.gmail.com> 
	<89dhun$uc47a@smtp.pt.lu>
Message-ID: <67628d691002230823o68956364k68710a34e3a141ce@mail.gmail.com>

> *Pier-Slideshow-lr.12* seems working just fine, but now I won't have time to
> test the animation.
>
> As for *Pier-Slideshow-MMP.13*, it seems more tricky since looks like there
> are references to absent methods (e.g. #descriptionLooping &
> #descriptionWidth). I couldn't explain that. Maybe I'm missing something.

I've never used Pier-Slideshow-MMP.13, I think it is broken and should
maybe removed form the repository? I use Pier-Slideshow-lr.12.

Lukas

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

From nick.ager at gmail.com  Tue Feb 23 19:02:46 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 23 Feb 2010 18:02:46 +0000
Subject: PRAddCommand #children
Message-ID: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com>

Hi,

I have a container component that renders a series of subcomponents. The
number of subcomponents is based on the number children within my structure.
My initial implementation cached the components and returned the cache
within #children and iterated over the cache within #renderContentOn:.

A problem arises when I add a new child to my structure. The container
component needs to invalidate it's cache when the structure changes or once
I rendering cycle completes. I tried hooking into #initialRequest: but that
didn't seem to be called each time I visited the page. I guess I could use
Announcements but wonder if there is a simpler solution? Thanks in advance

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

From renggli at gmail.com  Tue Feb 23 21:32:59 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 23 Feb 2010 21:32:59 +0100
Subject: PRAddCommand #children
In-Reply-To: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com>
References: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com>
Message-ID: <67628d691002231232q1f39c02cw22102f86db969ac4@mail.gmail.com>

> I rendering cycle completes. I tried hooking into #initialRequest: but that
> didn't seem to be called each time I visited the page.

WAPresenter>>initialRequest: aRequest
	"When a new session is started, all visible presenters (components or
tasks) receive this message with the request as argument.
	...

> I guess I could use
> Announcements but wonder if there is a simpler solution? Thanks in advance

Why don't you just enumerate and update the children with each
request? This is also what Pier does for the embedded documents.

Lukas

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

From nick.ager at gmail.com  Tue Feb 23 23:24:17 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Tue, 23 Feb 2010 22:24:17 +0000
Subject: PRAddCommand #children
In-Reply-To: <67628d691002231232q1f39c02cw22102f86db969ac4@mail.gmail.com>
References: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com>
	<67628d691002231232q1f39c02cw22102f86db969ac4@mail.gmail.com>
Message-ID: <3a06f76f1002231424x7f8d19barfe5c6a00d5a725c1@mail.gmail.com>

>
> Why don't you just enumerate and update the children with each
> request? This is also what Pier does for the embedded documents.
>

That's what I'd like to do. However I'm not clear how to detect the start of
a request from within a component. To explain - I put a #halt in children
and found that it was called five times, for one request. I was hoping that
I could hook into a message that marked the start of a request - as
#initialRequest isn't suitable is there some other call? Failing that, would
it confuse the calling components to return a different set of objects for
each of the five calls to #children?

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

From renggli at gmail.com  Tue Feb 23 23:38:34 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Tue, 23 Feb 2010 23:38:34 +0100
Subject: PRAddCommand #children
In-Reply-To: <3a06f76f1002231424x7f8d19barfe5c6a00d5a725c1@mail.gmail.com>
References: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com> 
	<67628d691002231232q1f39c02cw22102f86db969ac4@mail.gmail.com> 
	<3a06f76f1002231424x7f8d19barfe5c6a00d5a725c1@mail.gmail.com>
Message-ID: <67628d691002231438o6f383a61w52948dd2a7e96cae@mail.gmail.com>

On 23 February 2010 23:24, Nick Ager <nick.ager at gmail.com> wrote:
>> Why don't you just enumerate and update the children with each
>> request? This is also what Pier does for the embedded documents.
>
> That's what I'd like to do. However I'm not clear how to detect the start of
> a request from within a component. To explain - I put a #halt in children
> and found that it was called five times, for one request. I was hoping that
> I could hook into a message that marked the start of a request - as
> #initialRequest isn't suitable is there some other call? Failing that, would
> it confuse the calling components to return a different set of objects for
> each of the five calls to #children?

Pier itself does it lazily when #children is called for the first time.

Lukas


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



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

From nick.ager at gmail.com  Wed Feb 24 10:53:28 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Wed, 24 Feb 2010 09:53:28 +0000
Subject: PRAddCommand #children
In-Reply-To: <67628d691002231438o6f383a61w52948dd2a7e96cae@mail.gmail.com>
References: <3a06f76f1002231002v3cffc48dyd0c4f7cc0778c1d@mail.gmail.com>
	<67628d691002231232q1f39c02cw22102f86db969ac4@mail.gmail.com>
	<3a06f76f1002231424x7f8d19barfe5c6a00d5a725c1@mail.gmail.com>
	<67628d691002231438o6f383a61w52948dd2a7e96cae@mail.gmail.com>
Message-ID: <3a06f76f1002240153q20a10149mb1b7d75bcc7e7a81@mail.gmail.com>

>
> Pier itself does it lazily when #children is called for the first time.
>

Thanks for the pointer. I've solved my problem using PRPierFrame as the
inspiration. Within PRPierFrame children are cleared in
PRPierFrame>>context: and lazily constructed within PRPierFrame>>children.

In my display object I cleared my children collection cache in
#onChangeContext: and lazily constructed it in #children

Thanks again for the help

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

From razavi at acm.org  Wed Feb 24 10:19:28 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Wed, 24 Feb 2010 10:19:28 +0100
Subject: PRSlideshow undeclared references to SUElement
In-Reply-To: <67628d691002230823o68956364k68710a34e3a141ce@mail.gmail.co
 m>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<89dhun$u9lut@smtp.pt.lu>
	<67628d691002230513rd0d1db2mb9ec42247e85fa76@mail.gmail.com>
	<89dhun$uc47a@smtp.pt.lu>
	<67628d691002230823o68956364k68710a34e3a141ce@mail.gmail.com>
Message-ID: <89dhun$ui4hp@smtp.pt.lu>

At 17:23 23/02/2010, Lukas Renggli wrote:
>I've never used Pier-Slideshow-MMP.13, I think it is broken and should
>maybe removed form the repository?

Well, sooner or later people will need a Slideshow component for 
Pier2. Since *Pier-Slideshow-lr.12* is working in Pier2 almost as it 
is, I'd vote to use it as a basis for the port to Pier2, except if 
somebody decides to take the responsibility to port *Pier-Slideshow-MMP.13*.

I actually had a look at *Pier-Slideshow-MMP.13*, and am not 
convinced that its design is 100% percent consistent with that of 
*Pier-Slideshow-lr.12*. But, there are interesting ideas that could 
be integrated into *Pier-Slideshow-lr.12*. I've started some work in 
this direction, but unfortunately won't have time now to finish it. 
If somebody is interested in having a look at it and eventually 
finish the integration and port work, please tell me to send you my package.

Regards,
Reza


From razavi at acm.org  Thu Feb 25 12:14:42 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Thu, 25 Feb 2010 12:14:42 +0100
Subject: Verbatim in tables
Message-ID: <8bbtuf$12j3o7@smtp.pt.lu>

Hi Lukas,

If I type the following in a page:

{{{""This is a bold text""}}}

I get the following after interpretation:

""This is a bold text""

Which is what I was expecting.

But, if I type the same text in a table cell as follows:
||{{{""This is a bold text""}}}|

I get the following in a table:

This is a bold text}}}

Which I wasn't expecting.

May I ask you please what I'm missing there?
Thank you in advance for your response,
Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100225/80065eb3/attachment.html>

From razavi at acm.org  Fri Feb 26 08:40:38 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 26 Feb 2010 08:40:38 +0100
Subject: MAExternalFileModel class >> baseDirectory update
  responsibility 
Message-ID: <8bbtuf$12vcmq@smtp.pt.lu>

Hi,

MAExternalFileModel does not belong to the Smalltalk start-up list, 
and the cached *baseDirectory* value is not updated by program. 
Consequently, when a Pier image is moved from directory A to B, 
PRFiles keep referencing 'A/files' instead of 'B/files'.

Has this been designed this way by purpose?

Regards,
Reza







From renggli at gmail.com  Fri Feb 26 08:59:41 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 08:59:41 +0100
Subject: MAExternalFileModel class >> baseDirectory update responsibility
In-Reply-To: <8bbtuf$12vcmq@smtp.pt.lu>
References: <8bbtuf$12vcmq@smtp.pt.lu>
Message-ID: <67628d691002252359v1937ea6ep74d172bf6fc46b6f@mail.gmail.com>

> MAExternalFileModel does not belong to the Smalltalk start-up list, and the
> cached *baseDirectory* value is not updated by program. Consequently, when a
> Pier image is moved from directory A to B, PRFiles keep referencing
> 'A/files' instead of 'B/files'.
>
> Has this been designed this way by purpose?

Yeah, FileDirectory always represents an absolute path.

Maybe using FileDirectory wasn't such a good idea in the first place.
Maybe we should change it to a string to do a relative/absolute lookup
from the image directory? Or, oh well, we could use the Filesystem
framework

Lukas

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

From razavi at acm.org  Fri Feb 26 09:42:00 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 26 Feb 2010 09:42:00 +0100
Subject: MAExternalFileModel class >> baseDirectory update responsibility
In-Reply-To: <67628d691002252359v1937ea6ep74d172bf6fc46b6f@mail.gmail.co
 m>
References: <8bbtuf$12vcmq@smtp.pt.lu>
	<67628d691002252359v1937ea6ep74d172bf6fc46b6f@mail.gmail.com>
Message-ID: <8bbtuf$1306ap@smtp.pt.lu>

At 08:59 26/02/2010, you wrote:
>Maybe using FileDirectory wasn't such a good idea in the first place.
>Maybe we should change it to a string to do a relative/absolute lookup
>from the image directory? Or, oh well, we could use the Filesystem
>framework

Thank you for your prompt response!

The current implementation works just fine. It looks like that we 
just need to separate the *default base directory*, from another 
*application-specific base directory*. I'd *simply* do the followings:
- Add MAExternalFileModel to the Smalltalk start-up list to ensure 
that the default value gets automatically updated.
- Add an alternative class instance variable, for those applications 
that would need to reference a specific directory (without automated update).

Does this make sense?

Otherwise, the issue appeared since I'm used to copy my image from a 
*dev* directory to a *prod* directory, before executing my 
distribution generation script (sort of "PRDistribution new 
register"). I addressed the issue by simply adding to that script 
*MAExternalFileModel initialize*.

Regards,
Reza 


From renggli at gmail.com  Fri Feb 26 10:08:30 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 10:08:30 +0100
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com> 
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com> 
	<3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com> 
	<3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com>
Message-ID: <67628d691002260108i319140f6g97281474d25355ef@mail.gmail.com>

I've integrated the changes a while ago.

Lukas

On 22 February 2010 01:39, Nick Ager <nick.ager at gmail.com> wrote:
> It turns out to be simpler than I original thought:
> 1) PRCase already includes an accessor #plainText
> 2) I added PRCase class>>descriptionPlainText and set it to #readOnly and
> #beTagCloud
> 3) I removed PRCase class>>descriptionDocumentTextTagCloud: so that the wiki
> text from the document is no longer included in the tag cloud.
> Pier-TagCloud and Pier-Model mcz files are attached.
> Nick
>
> On 21 February 2010 14:44, Nick Ager <nick.ager at gmail.com> wrote:
>>>
>>> I think the PRTextWriter should probably not include the verbatim
>>> text. I'll remove it from there.
>>>
>>
>> Makes sense, though there's still the problem of how to make the
>> PRTagCloudWidget have access to plain text rather than the current
>> description which calls PRCase>>document - wiki text.
>>
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From nick.ager at gmail.com  Fri Feb 26 12:32:38 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 26 Feb 2010 11:32:38 +0000
Subject: PRContentsWidget and PREditCommand
Message-ID: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>

Hi,

When I edit a structure (or perform any command), the command renders itself
in the position defined by the PRContentsWidget. Unfortunately on the site
I'm building the content is often surround by other widgets and it's not
always visually appealing to render the command 'in-place'.

I've experimented with a couple of different approaches when the command is
"aContext command isView not":
1) replacing the application's root component with a decorated component
generated from the command as:
    self session presenter show: commandComponent
2) my second attempt modified the nearest ancestor with a local environment
to a more suitable "plain" environment.

Unfortunately both attempts have limitations. In the first all the
environment is lost and I've realised that in the second, environment
changes are visible to all users...

Rethinking my approach another alternative would be to goto another page for
the command and return on command completion.

Has anyone else solved a similar problem? All thoughts gratefully received

Thanks

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

From nick.ager at gmail.com  Fri Feb 26 12:36:00 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 26 Feb 2010 11:36:00 +0000
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <67628d691002260108i319140f6g97281474d25355ef@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com>
	<3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com>
	<3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com>
	<67628d691002260108i319140f6g97281474d25355ef@mail.gmail.com>
Message-ID: <3a06f76f1002260336s2d413b4es441f4d7035dc30e7@mail.gmail.com>

> I've integrated the changes a while ago.


Thanks Lukas. I noticed that you'd fixed the coupling I unintentionally
introduced between Pier and the TagCloud. Hopefully one day I'll submit a
patch which doesn't itself require patching...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100226/643b4cd3/attachment.html>

From renggli at gmail.com  Fri Feb 26 13:23:50 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 13:23:50 +0100
Subject: PRContentsWidget and PREditCommand
In-Reply-To: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
Message-ID: <67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>

> 2) my second attempt modified the nearest ancestor with a local environment
> to a more suitable "plain" environment.

What about having two environments, one for editing (that would
default to the default one) and one for viewing? Or is this what you
describe above?

Lukas

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

From renggli at gmail.com  Fri Feb 26 13:36:19 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 13:36:19 +0100
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <3a06f76f1002260336s2d413b4es441f4d7035dc30e7@mail.gmail.com>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com> 
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com> 
	<3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com> 
	<3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com> 
	<67628d691002260108i319140f6g97281474d25355ef@mail.gmail.com> 
	<3a06f76f1002260336s2d413b4es441f4d7035dc30e7@mail.gmail.com>
Message-ID: <67628d691002260436p2bd3ce45vdbc6442504ffef51@mail.gmail.com>

>> I've integrated the changes a while ago.
>
> Thanks Lukas. I noticed that you'd fixed the coupling I unintentionally
> introduced between Pier and the TagCloud. Hopefully one day I'll submit a
> patch which doesn't itself require patching...

That's no problem. Please just commit your changes to the main
repository. Your code is generally of very high quality.

I suggest we create a new public repository called 'pieraddons2' where
we can collect all the different plugins and extensions, and that we
make the main repository read-only. I've already added the top 99%
committers (Julian, Dale, Nick, Doru and me) as developers. If anybody
else would like to commit directly to the Magritte and Pier
repositories, please ask in the list.

Lukas

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

From nick.ager at gmail.com  Fri Feb 26 14:10:33 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 26 Feb 2010 13:10:33 +0000
Subject: PRContentsWidget and PREditCommand
In-Reply-To: <67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>
Message-ID: <3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>

>
> > 2) my second attempt modified the nearest ancestor with a local
> environment
> > to a more suitable "plain" environment.
>
> What about having two environments, one for editing (that would
> default to the default one) and one for viewing?


That's what I'd like to achieve, but my attempts haven't been successful.
If I change the local "viewing" environment for an "editing" environment
unfortunately other users will see the change, until the environment is
restored. It feels like ideally I'd use a show:onAnswer or call: but for
Pier pages, but I'm stuck on the implementation

Any thoughts?

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

From razavi at acm.org  Fri Feb 26 14:24:26 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 26 Feb 2010 14:24:26 +0100
Subject: PRTagCloudWidget and PRVerbatim
In-Reply-To: <67628d691002260436p2bd3ce45vdbc6442504ffef51@mail.gmail.co
 m>
References: <3a06f76f1002210626k1f791692mbf905fb11ada0cf9@mail.gmail.com>
	<67628d691002210635w71180665q321be494d7452881@mail.gmail.com>
	<3a06f76f1002210644o7b425ea4w45c0f9d9205508bd@mail.gmail.com>
	<3a06f76f1002211639i673196e9tcdacaa74b9c92793@mail.gmail.com>
	<67628d691002260108i319140f6g97281474d25355ef@mail.gmail.com>
	<3a06f76f1002260336s2d413b4es441f4d7035dc30e7@mail.gmail.com>
	<67628d691002260436p2bd3ce45vdbc6442504ffef51@mail.gmail.com>
Message-ID: <8bbtuf$133gdo@smtp.pt.lu>

At 13:36 26/02/2010, Lukas Renggli wrote:
>I suggest we create a new public repository called 'pieraddons2' where
>we can collect all the different plugins and extensions, and that we
>make the main repository read-only.

Good idea!

>If anybody
>else would like to commit directly to the Magritte and Pier
>repositories, please ask in the list.

I'm using Pier as a core component in a major project. I may 
consequently have some patches to propose here and there. However, at 
least at this point, I don't feel that it will need to commit 
directly to the main repository. The integration, when found useful, 
could be done by one of the main developers, after having discussed 
the proposition through the list.

Regards,
Reza



From renggli at gmail.com  Fri Feb 26 16:02:01 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 16:02:01 +0100
Subject: PRContentsWidget and PREditCommand
In-Reply-To: <3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com> 
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com> 
	<3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>
Message-ID: <67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com>

>> > 2) my second attempt modified the nearest ancestor with a local
>> > environment
>> > to a more suitable "plain" environment.
>>
>> What about having two environments, one for editing (that would
>> default to the default one) and one for viewing?
>
> That's what I'd like to achieve, but my attempts haven't been successful.
> If I change the local "viewing" environment for an "editing" environment
> unfortunately other users will see the change, until the environment is
> restored. It feels like ideally I'd use a show:onAnswer or call: but for
> Pier pages, but I'm stuck on the implementation
> Any thoughts?

I thought that you would store two environments in PRStructure and
that PRPierFrame (or your custom subclass) would depending on the
context (the command) use a different one.

Lukas

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

From nick.ager at gmail.com  Fri Feb 26 17:36:33 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 26 Feb 2010 16:36:33 +0000
Subject: PRContentsWidget and PREditCommand
In-Reply-To: <67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>
	<3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>
	<67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com>
Message-ID: <3a06f76f1002260836g54a1f04dqc68756f42b7b719a@mail.gmail.com>

>
>
> I thought that you would store two environments in PRStructure and
> that PRPierFrame (or your custom subclass) would depending on the
> context (the command) use a different one.


Thanks for idea of using overriding the behaviour in PRPierFrame -
previously I'd struggled modifying environments in PRContentsWidget.

The solution I've finally arrived at is:
1) I've added a method to my custom kernel #editingEnvironment
2) I've overridden #environment in PRPierFrame so that it now reads:

 environment
| environment |
 (self context command isView or: [self context command isQuick]) ifTrue: [
environment := self context structure environment
] ifFalse: [
environment := self kernel editingEnvironment
].

^ environment

So much simpler than my other two attempts - thanks again

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

From nick.ager at gmail.com  Fri Feb 26 20:50:24 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Fri, 26 Feb 2010 19:50:24 +0000
Subject: PRContentsWidget & WAAnswerHandler
Message-ID: <3a06f76f1002261150r4b6942a9lee433e1648c78750@mail.gmail.com>

Hi,

I've been experimenting with the code in PRContentsWidget all day and I've
noticed that an #onAnswer callback was added for all components regardless
of whether the command was a view command or not. I experimented with only
adding the #onAnswer callback for non-view commands and all appears to
continue to function, plus a WAAnswerHandler decorator is only added when (I
presume) it's required.

Is there a reason for calling #onAnswer on view components? Do view
components sometimes #answer:?

If not I attach an mcz with my changes.

Cheers

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100226/e4061ddd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pier-Seaside-NickAger.484.mcz
Type: application/octet-stream
Size: 127004 bytes
Desc: not available
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100226/e4061ddd/attachment-0001.obj>

From razavi at acm.org  Fri Feb 26 22:58:29 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Fri, 26 Feb 2010 22:58:29 +0100
Subject: RFBServer on Pier2 
In-Reply-To: <3a06f76f1002260836g54a1f04dqc68756f42b7b719a@mail.gmail.co
 m>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>
	<3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>
	<67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com>
	<3a06f76f1002260836g54a1f04dqc68756f42b7b719a@mail.gmail.com>
Message-ID: <89dhun$vl6ff@smtp.pt.lu>

Hi,

I'm getting trouble to connect to a remote image using RealVNC. I get 
a "Connection time out" error message.

The configuration is:
- PharoCore1.0rc1 (Latest update: #10505)
+ Seaside 3
+ Pier 2
+ RFB-lr.13 from 
<http://source.lukas-renggli.ch/unsorted/>http://source.lukas-renggli.ch/unsorted/, 


I successfully launch RFBServer thanks to Seaside VNC Controller, and 
Pier continues serving in spite of that connection failure.

However, I tried to connect to a local image using "localhost:0", but 
I get "Unknown rect encoding". If I ask RealVNC to retry connecting, 
my image freezes. Its the same after upgrading to *RFB-DamienCassou.28*.

I'd greatly appreciate any feedback on this issue.
Thank you in advance,
Regards,
Reza 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100226/6f0e652f/attachment.html>

From renggli at gmail.com  Fri Feb 26 23:18:43 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 23:18:43 +0100
Subject: PRContentsWidget & WAAnswerHandler
In-Reply-To: <3a06f76f1002261150r4b6942a9lee433e1648c78750@mail.gmail.com>
References: <3a06f76f1002261150r4b6942a9lee433e1648c78750@mail.gmail.com>
Message-ID: <67628d691002261418q631c18e0mb0a7f4ff36115d26@mail.gmail.com>

> Is there a reason for calling #onAnswer on view components? Do view
> components sometimes #answer:?

Not that I know one that does, but they theoretically could to execute
a command and follow up with another command (like for example the Add
command is followed by an Edit command).

Lukas

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

From renggli at gmail.com  Fri Feb 26 23:28:44 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 23:28:44 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
Message-ID: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com>

I've slightly reorganized the repositories for Pier and Magritte 2, as
it was discussed in the thread with the subject "PRTagCloudWidget and
PRVerbatim".

The codebase of Pier and Magritte for Seaside 3.0 is located at:

   Magritte 2: http://source.lukas-renggli.ch/magritte2
   Pier 2: http://source.lukas-renggli.ch/pier2

Both repositories are readable by public, to write you have to be
added to the developers though. Just drop a mail to the list if you
want to commit something and we will add you.

   Pier 2 Addons: http://source.lukas-renggli.ch/pier2addons

Furthermore I created a public repository for the numerous Pier
plugins that already exist and that (hopefully) will continue to grow.
Read and write on that repository does not require any registration.
Feel free to post your extensions there.

@Reza: I tried to move your commit that wraps widgets into commands to
the plugin folder, but there seems to be problems because the package
name contains spaces. Monticello wouldn't even load that package.
Could you please recommit the package without spaces?

Lukas

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

From jvdsandt at gmail.com  Fri Feb 26 23:44:28 2010
From: jvdsandt at gmail.com (Jan van de Sandt)
Date: Fri, 26 Feb 2010 23:44:28 +0100
Subject: Pier 2: ? in resfull url's
Message-ID: <50d1d2c91002261444h4f0880f5wacf8ed98cccfbcc9@mail.gmail.com>

Hello,

When I switch my pier 2 website to use session cookies I get nice restful
URL's. Only there is a question mark behind the URL even if there are no
query parameters.

I tracked this down to the WUrl>>purgeSeasideFields method. The question
marks disappears when I change the method to:

purgeSeasideFields
    self queryFields keys do: [ :each |
        (self isSeasideField: each)
            ifTrue: [
                self queryFields removeKey: each ifAbsent: [ ].
                self queryFields isEmpty
                    ifTrue: [ self queryFields: nil ] ] ]

It is also possible to change the WAUrl>>encodeOn: method to check for an
empty queryFields collection.

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

From renggli at gmail.com  Fri Feb 26 23:50:19 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Fri, 26 Feb 2010 23:50:19 +0100
Subject: Pier 2: ? in resfull url's
In-Reply-To: <50d1d2c91002261444h4f0880f5wacf8ed98cccfbcc9@mail.gmail.com>
References: <50d1d2c91002261444h4f0880f5wacf8ed98cccfbcc9@mail.gmail.com>
Message-ID: <67628d691002261450x1e10481ep8be379b85d4a0b0c@mail.gmail.com>

I prefer to fix encodeOn: in Seaside. I've created a bug report:

    http://code.google.com/p/seaside/issues/detail?id=550

Thanks for reporting.

Lukas

On 26 February 2010 23:44, Jan van de Sandt <jvdsandt at gmail.com> wrote:
> Hello,
>
> When I switch my pier 2 website to use session cookies I get nice restful
> URL's. Only there is a question mark behind the URL even if there are no
> query parameters.
>
> I tracked this down to the WUrl>>purgeSeasideFields method. The question
> marks disappears when I change the method to:
>
> purgeSeasideFields
> ??? self queryFields keys do: [ :each |
> ??? ??? (self isSeasideField: each)
> ??? ??? ??? ifTrue: [
> ??? ??? ??? ??? self queryFields removeKey: each ifAbsent: [ ].
> ??? ??? ??? ??? self queryFields isEmpty
> ??? ??? ??? ??? ??? ifTrue: [ self queryFields: nil ] ] ]
>
> It is also possible to change the WAUrl>>encodeOn: method to check for an
> empty queryFields collection.
>
> Jan.
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From dale.henrichs at gemstone.com  Sat Feb 27 01:31:23 2010
From: dale.henrichs at gemstone.com (Dale Henrichs)
Date: Fri, 26 Feb 2010 16:31:23 -0800 (PST)
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com>
Message-ID: <453692836.237611267230683724.JavaMail.root@gir>

I plan on making a pass through the Magritte2 and Pier2 Metacello configurations this weekend to make sure that they are getting the packages from the correct repositories...

Dale

----- "Lukas Renggli" <renggli at gmail.com> wrote:

| I've slightly reorganized the repositories for Pier and Magritte 2,
| as
| it was discussed in the thread with the subject "PRTagCloudWidget and
| PRVerbatim".
| 
| The codebase of Pier and Magritte for Seaside 3.0 is located at:
| 
|    Magritte 2: http://source.lukas-renggli.ch/magritte2
|    Pier 2: http://source.lukas-renggli.ch/pier2
| 
| Both repositories are readable by public, to write you have to be
| added to the developers though. Just drop a mail to the list if you
| want to commit something and we will add you.
| 
|    Pier 2 Addons: http://source.lukas-renggli.ch/pier2addons
| 
| Furthermore I created a public repository for the numerous Pier
| plugins that already exist and that (hopefully) will continue to
| grow.
| Read and write on that repository does not require any registration.
| Feel free to post your extensions there.
| 
| @Reza: I tried to move your commit that wraps widgets into commands
| to
| the plugin folder, but there seems to be problems because the package
| name contains spaces. Monticello wouldn't even load that package.
| Could you please recommit the package without spaces?
| 
| Lukas
| 
| -- 
| Lukas Renggli
| http://www.lukas-renggli.ch
| _______________________________________________
| Magritte, Pier and Related Tools ...
| https://www.iam.unibe.ch/mailman/listinfo/smallwiki

From renggli at gmail.com  Sat Feb 27 09:07:53 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 27 Feb 2010 09:07:53 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <453692836.237611267230683724.JavaMail.root@gir>
References: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com> 
	<453692836.237611267230683724.JavaMail.root@gir>
Message-ID: <67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.com>

> I plan on making a pass through the Magritte2 and Pier2 Metacello configurations this weekend to make sure that they are getting the packages from the correct repositories...

Ohh, I sorry, I forgot about that (again).

I moved the packages

    Pier-Documents
    Pier-EditorEnh
    Pier-Google
    Pier-LinkChecker
    Pier-Setup
    Pier-TagCloud
    Pier-Twitter
    Pier-VASTExporter

from

    http://source.lukas-renggli.ch/pier2/

to

    http://source.lukas-renggli.ch/pier2addons/


For now I left the package Pier-Security, Pier-Blog, Pier-Book in the
main repository. These are very big packages and somehow belong to the
core, I thought. But, I am open for discussion.

Lukas

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

From razavi at acm.org  Sat Feb 27 09:23:12 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sat, 27 Feb 2010 09:23:12 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.co
 m>
References: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com>
Message-ID: <89dhun$vn3hn@smtp.pt.lu>

At 23:28 26/02/2010, Lukas Renggli wrote:
>@Reza: ...
>Could you please recommit the package without spaces?

Just done; also added some more comments.
Regards,
Reza


From razavi at acm.org  Sat Feb 27 09:30:34 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sat, 27 Feb 2010 09:30:34 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.co
 m>
References: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com>
	<453692836.237611267230683724.JavaMail.root@gir>
	<67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.com>
Message-ID: <89dhun$vn5dk@smtp.pt.lu>

At 09:07 27/02/2010, Lukas Renggli wrote:
>For now I left the package Pier-Security, Pier-Blog, Pier-Book in the
>main repository. These are very big packages and somehow belong to the
>core, I thought. But, I am open for discussion.

Pier-Security and Pier-Blog are major components that I plan to 
integrate in all my distributions. So, for me, certainly part of the 
main repository.

Pier-Book is, somehow more specific, although also a major component.

Regards,
Reza



From renggli at gmail.com  Sat Feb 27 10:25:30 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 27 Feb 2010 10:25:30 +0100
Subject: RFBServer on Pier2
In-Reply-To: <89dhun$vl6ff@smtp.pt.lu>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com> 
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com> 
	<3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com> 
	<67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com> 
	<3a06f76f1002260836g54a1f04dqc68756f42b7b719a@mail.gmail.com> 
	<89dhun$vl6ff@smtp.pt.lu>
Message-ID: <67628d691002270125i3bafce6ck941c048ba64fc9f7@mail.gmail.com>

Load the latest Seaside-Pharo-Tools-Web and the latest RBF server. I
fixed various minor problems, but it basically worked already before.

Lukas

On 26 February 2010 22:58, Reza RAZAVI <razavi at acm.org> wrote:
> Hi,
>
> I'm getting trouble to connect to a remote image using RealVNC. I get a
> "Connection time out" error message.
>
> The configuration is:
> - PharoCore1.0rc1 (Latest update: #10505)
> + Seaside 3
> + Pier 2
> + RFB-lr.13 from http://source.lukas-renggli.ch/unsorted/,
>
> I successfully launch RFBServer thanks to Seaside VNC Controller, and Pier
> continues serving in spite of that connection failure.
>
> However, I tried to connect to a local image using "localhost:0", but I get
> "Unknown rect encoding". If I ask RealVNC to retry connecting, my image
> freezes. Its the same after upgrading to *RFB-DamienCassou.28*.
>
> I'd greatly appreciate any feedback on this issue.
> Thank you in advance,
> Regards,
> Reza
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From razavi at acm.org  Sat Feb 27 16:11:19 2010
From: razavi at acm.org (Reza RAZAVI)
Date: Sat, 27 Feb 2010 16:11:19 +0100
Subject: RFBServer on Pier2
In-Reply-To: <67628d691002270125i3bafce6ck941c048ba64fc9f7@mail.gmail.co
 m>
References: <3a06f76f1002260332t3f6af2fbq9bfe51766a5f1285@mail.gmail.com>
	<67628d691002260423p13d05f9bxd8d535fddeba8b2a@mail.gmail.com>
	<3a06f76f1002260510x4af97109hc8fbbe3cf7dd33f0@mail.gmail.com>
	<67628d691002260702j17a9c03co26b4cfb9d5135aa7@mail.gmail.com>
	<3a06f76f1002260836g54a1f04dqc68756f42b7b719a@mail.gmail.com>
	<89dhun$vl6ff@smtp.pt.lu>
	<67628d691002270125i3bafce6ck941c048ba64fc9f7@mail.gmail.com>
Message-ID: <89dhun$vpa9v@smtp.pt.lu>

At 10:25 27/02/2010, Lukas Renggli wrote:
>Load the latest Seaside-Pharo-Tools-Web and the latest RBF server. I
>fixed various minor problems, but it basically worked already before.

Thank you so mush Lukas for having considered so professionally my request!

After the above upgrade, I just had once *VNC Free Edition for 
Windows* from RealVNC rendering correctly my image display via 
"localhost:0". But no interaction was possible, and my image was again frozen.

Now, I'm moving my image to my experimental Linux / Debian / Apache 
2.2 / Firewall server, and will give you feedback asap.

Regards,
Reza  


From yanni at rogers.com  Sat Feb 27 19:08:24 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Sat, 27 Feb 2010 13:08:24 -0500
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <89dhun$vn5dk@smtp.pt.lu>
References: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com>	<453692836.237611267230683724.JavaMail.root@gir>	<67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.com>
	<67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.co m>
	<89dhun$vn5dk@smtp.pt.lu>
Message-ID: <hmbn2o$kjj$1@dough.gmane.org>

Reza RAZAVI wrote:
> At 09:07 27/02/2010, Lukas Renggli wrote:
>> For now I left the package Pier-Security, Pier-Blog, Pier-Book in the
>> main repository. These are very big packages and somehow belong to the
>> core, I thought. But, I am open for discussion.
> 
> Pier-Security and Pier-Blog are major components that I plan to 
> integrate in all my distributions. So, for me, certainly part of the 
> main repository.
> 
> Pier-Book is, somehow more specific, although also a major component.

I think security is "core", and a blog and a book are "addons". If the 
addon is big, then it can have its own repository.

I only load:

	package: 'Pier-Core';
	package: 'Pier-Pharo-Core';
	package: 'Pier-Model';
	package: 'Pier-Pharo-Model';
	package: 'Pier-Tests-Model';
	package: 'Pier-Seaside';
	package: 'Pier-Pharo-Seaside';
	package: 'Pier-Security';
	package: 'Pier-Pharo-Persistency';
	package: 'Pier-Tests-Security';

so I never even noticed that the addon packages were moved.

I would like to load the tests separately too. IIRC, there were 
testcases whose superclass caused a load dependency. Please add me as 
developer (initials: yc), and I'll have a look at it.

-- 
Yanni


From dale.henrichs at gemstone.com  Sat Feb 27 21:03:13 2010
From: dale.henrichs at gemstone.com (Dale Henrichs)
Date: Sat, 27 Feb 2010 12:03:13 -0800 (PST)
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <hmbn2o$kjj$1@dough.gmane.org>
Message-ID: <38907558.241301267300993466.JavaMail.root@gir>

Yanni,

When you take care of the test dependencies let me know so I can update the ConfigurationOfPier...

Dale
----- "Yanni Chiu" <yanni at rogers.com> wrote:

| Reza RAZAVI wrote:
| > At 09:07 27/02/2010, Lukas Renggli wrote:
| >> For now I left the package Pier-Security, Pier-Blog, Pier-Book in
| the
| >> main repository. These are very big packages and somehow belong to
| the
| >> core, I thought. But, I am open for discussion.
| > 
| > Pier-Security and Pier-Blog are major components that I plan to 
| > integrate in all my distributions. So, for me, certainly part of the
| 
| > main repository.
| > 
| > Pier-Book is, somehow more specific, although also a major
| component.
| 
| I think security is "core", and a blog and a book are "addons". If the
| 
| addon is big, then it can have its own repository.
| 
| I only load:
| 
| 	package: 'Pier-Core';
| 	package: 'Pier-Pharo-Core';
| 	package: 'Pier-Model';
| 	package: 'Pier-Pharo-Model';
| 	package: 'Pier-Tests-Model';
| 	package: 'Pier-Seaside';
| 	package: 'Pier-Pharo-Seaside';
| 	package: 'Pier-Security';
| 	package: 'Pier-Pharo-Persistency';
| 	package: 'Pier-Tests-Security';
| 
| so I never even noticed that the addon packages were moved.
| 
| I would like to load the tests separately too. IIRC, there were 
| testcases whose superclass caused a load dependency. Please add me as
| 
| developer (initials: yc), and I'll have a look at it.
| 
| -- 
| Yanni
| 
| _______________________________________________
| Magritte, Pier and Related Tools ...
| https://www.iam.unibe.ch/mailman/listinfo/smallwiki

From renggli at gmail.com  Sat Feb 27 21:13:08 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sat, 27 Feb 2010 21:13:08 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <hmbn2o$kjj$1@dough.gmane.org>
References: <67628d691002261428h53e68594r62d24148ec9ef9c8@mail.gmail.com> 
	<453692836.237611267230683724.JavaMail.root@gir>
	<67628d691002270007h5c664568t241b5eb90e2d8218@mail.gmail.com> 
	<89dhun$vn5dk@smtp.pt.lu> <hmbn2o$kjj$1@dough.gmane.org>
Message-ID: <67628d691002271213r48c3871em2353db3eecee30c5@mail.gmail.com>

>>> For now I left the package Pier-Security, Pier-Blog, Pier-Book in the
>>> main repository. These are very big packages and somehow belong to the
>>> core, I thought. But, I am open for discussion.
>>
>> Pier-Security and Pier-Blog are major components that I plan to integrate
>> in all my distributions. So, for me, certainly part of the main repository.
>>
>> Pier-Book is, somehow more specific, although also a major component.
>
> I think security is "core", and a blog and a book are "addons". If the addon
> is big, then it can have its own repository.

I would like to avoid too many repositories.

> I only load:
>
> ? ? ? ?package: 'Pier-Core';
> ? ? ? ?package: 'Pier-Pharo-Core';
> ? ? ? ?package: 'Pier-Model';
> ? ? ? ?package: 'Pier-Pharo-Model';
> ? ? ? ?package: 'Pier-Tests-Model';
> ? ? ? ?package: 'Pier-Seaside';
> ? ? ? ?package: 'Pier-Pharo-Seaside';
> ? ? ? ?package: 'Pier-Security';
> ? ? ? ?package: 'Pier-Pharo-Persistency';
> ? ? ? ?package: 'Pier-Tests-Security';
>
> so I never even noticed that the addon packages were moved.

I just moved them 2 hours ago :-)

> I would like to load the tests separately too. IIRC, there were testcases
> whose superclass caused a load dependency. Please add me as developer
> (initials: yc), and I'll have a look at it.

What is the problem with the test cases?

I've added you.

Lukas




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



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


From dale.henrichs at gemstone.com  Sun Feb 28 00:54:35 2010
From: dale.henrichs at gemstone.com (Dale Henrichs)
Date: Sat, 27 Feb 2010 15:54:35 -0800 (PST)
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <888638630.242191267314719055.JavaMail.root@gir>
Message-ID: <398052244.242241267314875420.JavaMail.root@gir>

When I created the Pier2 configuration I noticed that 'Pier-Pharo-Persistency' has embedded tests that caused a dependency upon 'Pier-Tests-Model'. I seem to remember mentioning it at the time on this list (or maybe someone else commented)...

In Pier1, it appears the Pier-Security and 'Pier-Squeak-Persistency' also has a dependency upon Pier-Tests.

In Pier2, Pier-Security has had the tests broken out separately...

Dale
----- "Lukas Renggli" <renggli at gmail.com> wrote:

| >>> For now I left the package Pier-Security, Pier-Blog, Pier-Book in
| the
| >>> main repository. These are very big packages and somehow belong to
| the
| >>> core, I thought. But, I am open for discussion.
| >>
| >> Pier-Security and Pier-Blog are major components that I plan to
| integrate
| >> in all my distributions. So, for me, certainly part of the main
| repository.
| >>
| >> Pier-Book is, somehow more specific, although also a major
| component.
| >
| > I think security is "core", and a blog and a book are "addons". If
| the addon
| > is big, then it can have its own repository.
| 
| I would like to avoid too many repositories.
| 
| > I only load:
| >
| > ? ? ? ?package: 'Pier-Core';
| > ? ? ? ?package: 'Pier-Pharo-Core';
| > ? ? ? ?package: 'Pier-Model';
| > ? ? ? ?package: 'Pier-Pharo-Model';
| > ? ? ? ?package: 'Pier-Tests-Model';
| > ? ? ? ?package: 'Pier-Seaside';
| > ? ? ? ?package: 'Pier-Pharo-Seaside';
| > ? ? ? ?package: 'Pier-Security';
| > ? ? ? ?package: 'Pier-Pharo-Persistency';
| > ? ? ? ?package: 'Pier-Tests-Security';
| >
| > so I never even noticed that the addon packages were moved.
| 
| I just moved them 2 hours ago :-)
| 
| > I would like to load the tests separately too. IIRC, there were
| testcases
| > whose superclass caused a load dependency. Please add me as
| developer
| > (initials: yc), and I'll have a look at it.
| 
| What is the problem with the test cases?
| 
| I've added you.
| 
| Lukas
| 
| 
| 
| 
| >
| > --
| > Yanni
| >
| > _______________________________________________
| > Magritte, Pier and Related Tools ...
| > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
| >
| 
| 
| 
| -- 
| Lukas Renggli
| http://www.lukas-renggli.ch
| 
| _______________________________________________
| Magritte, Pier and Related Tools ...
| https://www.iam.unibe.ch/mailman/listinfo/smallwiki


From ch.l.ngre at online.de  Sun Feb 28 01:27:38 2010
From: ch.l.ngre at online.de (Ch Lamprecht)
Date: Sun, 28 Feb 2010 01:27:38 +0100
Subject: Perl does Magritte
Message-ID: <4B89B87A.4050104@online.de>

Hello,

for quite some time I have been experimenting with a Perl implementation of 
Magritte. It was great fun and a good way to learn about OO design. I'm not a 
professional and there are probably lots of bugs, but the basic things seem to work.
If anyone is intrested and wants to take a look, it can be found here:
http://sites.google.com/site/vlclamprecht/Home/perl

Thanks to Lukas for his work!

Cheers, Christoph

From yanni at rogers.com  Sun Feb 28 02:01:59 2010
From: yanni at rogers.com (Yanni Chiu)
Date: Sat, 27 Feb 2010 20:01:59 -0500
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <398052244.242241267314875420.JavaMail.root@gir>
References: <888638630.242191267314719055.JavaMail.root@gir>
	<398052244.242241267314875420.JavaMail.root@gir>
Message-ID: <hmcfa7$u48$1@dough.gmane.org>

Dale Henrichs wrote:
> When I created the Pier2 configuration I noticed that 'Pier-Pharo-Persistency' has embedded tests that caused a dependency upon 'Pier-Tests-Model'. I seem to remember mentioning it at the time on this list (or maybe someone else commented)...
> 
> In Pier1, it appears the Pier-Security and 'Pier-Squeak-Persistency' also has a dependency upon Pier-Tests.
> 
> In Pier2, Pier-Security has had the tests broken out separately...

Pier2 is fixed now. I split off PRImagePersistencyTest (whose superclass 
in in Pier-Tests-Model) into a new Pier-Tests-Pharo-Persistency package.

My build script now does:

Gofer new
	renggli: 'pier2';
	package: 'Pier-Model';
	package: 'Pier-Pharo-Model';
	package: 'Pier-Seaside';
	package: 'Pier-Pharo-Seaside';
	package: 'Pier-Pharo-Persistency';
	package: 'Pier-Security';
	load.

and, for tests, it also does:

Gofer new
	renggli: 'pier2';
	package: 'Pier-Tests-Model';
	package: 'Pier-Tests-Pharo-Persistency';
	package: 'Pier-Tests-Security';
	load.


From merlyn at stonehenge.com  Sun Feb 28 04:02:46 2010
From: merlyn at stonehenge.com (Randal L. Schwartz)
Date: Sat, 27 Feb 2010 19:02:46 -0800
Subject: Perl does Magritte
In-Reply-To: <4B89B87A.4050104@online.de> (Ch Lamprecht's message of "Sun,
	28 Feb 2010 01:27:38 +0100")
References: <4B89B87A.4050104@online.de>
Message-ID: <86k4tynju1.fsf@blue.stonehenge.com>

>>>>> "Ch" == Ch Lamprecht <ch.l.ngre at online.de> writes:

Ch> for quite some time I have been experimenting with a Perl implementation
Ch> of Magritte. It was great fun and a good way to learn about OO design. I'm
Ch> not a professional and there are probably lots of bugs, but the basic
Ch> things seem to work.  If anyone is intrested and wants to take a look, it
Ch> can be found here: http://sites.google.com/site/vlclamprecht/Home/perl

And two of my worlds have collided. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

From renggli at gmail.com  Sun Feb 28 10:46:44 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 28 Feb 2010 10:46:44 +0100
Subject: Perl does Magritte
In-Reply-To: <4B89B87A.4050104@online.de>
References: <4B89B87A.4050104@online.de>
Message-ID: <67628d691002280146t747e4327pa529449fc9902ccc@mail.gmail.com>

Excellent, thank you for sharing this. I will put a link on the Magritte page.

Lukas

On 28 February 2010 01:27, Ch Lamprecht <ch.l.ngre at online.de> wrote:
> Hello,
>
> for quite some time I have been experimenting with a Perl implementation of
> Magritte. It was great fun and a good way to learn about OO design. I'm not
> a professional and there are probably lots of bugs, but the basic things
> seem to work.
> If anyone is intrested and wants to take a look, it can be found here:
> http://sites.google.com/site/vlclamprecht/Home/perl
>
> Thanks to Lukas for his work!
>
> Cheers, Christoph
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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

From renggli at gmail.com  Sun Feb 28 12:03:54 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 28 Feb 2010 12:03:54 +0100
Subject: Reorganization of Pier 2 and Magritte 2 Repositories
In-Reply-To: <hmcfa7$u48$1@dough.gmane.org>
References: <888638630.242191267314719055.JavaMail.root@gir> 
	<398052244.242241267314875420.JavaMail.root@gir>
	<hmcfa7$u48$1@dough.gmane.org>
Message-ID: <67628d691002280303i610be4beid3363873aef7501@mail.gmail.com>

> My build script now does:
>
> Gofer new
> ? ? ? ?renggli: 'pier2';
> ? ? ? ?package: 'Pier-Model';
> ? ? ? ?package: 'Pier-Pharo-Model';
> ? ? ? ?package: 'Pier-Seaside';
> ? ? ? ?package: 'Pier-Pharo-Seaside';
> ? ? ? ?package: 'Pier-Pharo-Persistency';
> ? ? ? ?package: 'Pier-Security';
> ? ? ? ?load.
>
> and, for tests, it also does:
>
> Gofer new
> ? ? ? ?renggli: 'pier2';
> ? ? ? ?package: 'Pier-Tests-Model';
> ? ? ? ?package: 'Pier-Tests-Pharo-Persistency';
> ? ? ? ?package: 'Pier-Tests-Security';
> ? ? ? ?load.

That looks good. I've adapted my build scripts as well.

Lukas

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


From nick.ager at gmail.com  Sun Feb 28 13:22:53 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 28 Feb 2010 12:22:53 +0000
Subject: checkins: PUSecurityWidget and PRTagCloudWidget
Message-ID: <3a06f76f1002280422t4b963b1bgb8b17cb2071d7863@mail.gmail.com>

Hi,

I've checked in a couple of changes:

Pier-Security-NickAger.162
"removed editUser hack from PUSecurityWidget by adding PUEditUser command"
The motivation for this change was that the existing edit user hack was
ignoring the editing environment I wanted to use (see
http://www.iam.unibe.ch/pipermail/smallwiki/2010-February/005763.html)

Pier-TagCloud-NickAger.16
"added additional stop words"

Hope these work for everyone

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

From renggli at gmail.com  Sun Feb 28 17:42:14 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 28 Feb 2010 17:42:14 +0100
Subject: checkins: PUSecurityWidget and PRTagCloudWidget
In-Reply-To: <3a06f76f1002280422t4b963b1bgb8b17cb2071d7863@mail.gmail.com>
References: <3a06f76f1002280422t4b963b1bgb8b17cb2071d7863@mail.gmail.com>
Message-ID: <67628d691002280842wca8450av8dd4c352dbe664a9@mail.gmail.com>

Could you please also add a test? ;-)

I tried to keep all commands (and generally every model method) tested.

Lukas

On 28 February 2010 13:22, Nick Ager <nick.ager at gmail.com> wrote:
> Hi,
> I've checked in a couple of changes:
> Pier-Security-NickAger.162
> "removed editUser hack from PUSecurityWidget by adding PUEditUser command"
> The motivation for this change was that the existing edit user hack was
> ignoring the editing environment I wanted to use
> (see?http://www.iam.unibe.ch/pipermail/smallwiki/2010-February/005763.html)
> Pier-TagCloud-NickAger.16
> "added additional stop words"
> Hope these work for everyone
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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


From nick.ager at gmail.com  Sun Feb 28 18:23:00 2010
From: nick.ager at gmail.com (Nick Ager)
Date: Sun, 28 Feb 2010 17:23:00 +0000
Subject: checkins: PUSecurityWidget and PRTagCloudWidget
In-Reply-To: <67628d691002280842wca8450av8dd4c352dbe664a9@mail.gmail.com>
References: <3a06f76f1002280422t4b963b1bgb8b17cb2071d7863@mail.gmail.com>
	<67628d691002280842wca8450av8dd4c352dbe664a9@mail.gmail.com>
Message-ID: <3a06f76f1002280923r1897e609ha64f0048c89843b9@mail.gmail.com>

> Could you please also add a test? ;-)
>

Yes I will ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100228/debf3feb/attachment.html>

From renggli at gmail.com  Sun Feb 28 18:28:18 2010
From: renggli at gmail.com (Lukas Renggli)
Date: Sun, 28 Feb 2010 18:28:18 +0100
Subject: checkins: PUSecurityWidget and PRTagCloudWidget
In-Reply-To: <3a06f76f1002280923r1897e609ha64f0048c89843b9@mail.gmail.com>
References: <3a06f76f1002280422t4b963b1bgb8b17cb2071d7863@mail.gmail.com> 
	<67628d691002280842wca8450av8dd4c352dbe664a9@mail.gmail.com> 
	<3a06f76f1002280923r1897e609ha64f0048c89843b9@mail.gmail.com>
Message-ID: <67628d691002280928o137f577fy54a6d20d0c9f8ef0@mail.gmail.com>

No problem ... I am writing one right now.

Lukas

On 28 February 2010 18:23, Nick Ager <nick.ager at gmail.com> wrote:
>
>> Could you please also add a test? ;-)
>
> Yes I will ...
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>



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