Hi Lukas,
Please have a look at
http://smallwiki.unibe.ch/moose/mseformat/
there are three links on resources which are not rendered as HTML
links. For each link an MSE file has been uploaded, but after
successful upload the link just showed up as text.
cheers,
-- Adrian
Hello everyone,
I'm working on a widget that could display the complete structure of Pier
(actually based on something like PRTreeWidget). The widget is here for
displaying purpose and it instanciates a visitor which walk over the
structure and gather the information. I assume that I need this visitor if I
want
to achieve my goal but a question remains: what if I want to list
every piece of content like images,...?
For example, I have a page with an image and my widget shows:
a PRDocument
PRInternalLink
PRText
How can I know if there is an image here? In other words how could I display
more details?
Cheers,
Sébastien
Hi Eric,
> I am looking into using Pier just so that I can use a wiki based on
> Smalltalk and get more experience with it (Pier and Smalltalk). My
> question is based on the persistence... it seems all of the data is
> being saved in the image. Is there any 'safe usage' suggestions?
> Or do I just save the image from time to time? I noticed there was
> a magma backend, and I was curious as to whether one could start
> out with using the image for persistence and later move to magma?
> I'm thinking of this, as I just don't want to start with magma
> (yet). One step at a time. Do you have any suggestions or tips
> for persisting the data safely? (Just don't want to lose
> everything I put in it)
please check the mailing list archive, there has been a lot of
discussion on this topic.
Personally I use the image persistency for all my running instances,
and it works well so far. Of course there is also a certain danger,
if you don't have backups and screw up your image. With OSProcess
loaded the snapshots are taken in a forked instance of the vm, doing
the whole thing transparently in the background.
The magma persistency is certainly very interesting, but I don't know
if it works with the latest version of Pier. As far as I know the
Magma persistency can be activated later on as well, but you have to
ask Keith, the author of this plug-in.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
> What are the odds of getting the code you use for doing the image
> persistancy with OSProcess? (Or is that already in Pier)
Yes, it is already in Pier. You just have to load OSProcess from
SqueakMap and use an Unix VM.
Cheers,
Lukas
>
> :-)
>
> Cheers,
>
> Brian
>
> On Feb 8, 2007, at 1:06 PM, Lukas Renggli wrote:
>
>> Hi Eric,
>>
>>> I am looking into using Pier just so that I can use a wiki based on
>>> Smalltalk and get more experience with it (Pier and Smalltalk). My
>>> question is based on the persistence... it seems all of the data is
>>> being saved in the image. Is there any 'safe usage' suggestions?
>>> Or do I just save the image from time to time? I noticed there was
>>> a magma backend, and I was curious as to whether one could start
>>> out with using the image for persistence and later move to magma?
>>> I'm thinking of this, as I just don't want to start with magma
>>> (yet). One step at a time. Do you have any suggestions or tips
>>> for persisting the data safely? (Just don't want to lose
>>> everything I put in it)
>>
>> please check the mailing list archive, there has been a lot of
>> discussion on this topic.
>>
>> Personally I use the image persistency for all my running instances,
>> and it works well so far. Of course there is also a certain danger,
>> if you don't have backups and screw up your image. With OSProcess
>> loaded the snapshots are taken in a forked instance of the vm, doing
>> the whole thing transparently in the background.
>>
>> The magma persistency is certainly very interesting, but I don't know
>> if it works with the latest version of Pier. As far as I know the
>> Magma persistency can be activated later on as well, but you have to
>> ask Keith, the author of this plug-in.
>>
>> Cheers,
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>>
>>
>> _______________________________________________
>> SmallWiki, Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
--
Lukas Renggli
http://www.lukas-renggli.ch
I'm playing with porting an existing model driven application to
magritte and I'm hitting very frequent conflicts on the method name
#description. I would urge you to change this in the future to
something less generic like modelDescription.
Just sharing my pain. :-)
-Todd Blanchard
Hello all,
I have been working with Pier a bit lately, and I noticed a couple of things
I was curious about.
First, in my image, if you go to a page and then go to lunch, come back and
hour later and click a link you get dropped back to the front page because
your session has expired. But I thought Pier used the URL to be able
bookmark, surf the side via URL etc. In fact, I thought it even worked this
way before I put the security package in.
Has this been fixed? It seems like if you click on a link that has a URL,
but an old session Pier could just make a new session and apply that to the
page the user is trying to go to. If the user is not allowed to see that
resource with the blank session then kick them back to the front like now,
but if the page is not restricted they should see it.
Second, is there any plan to expand on the RESTfulness of Pier? I mean, I'm
not a die-hard REST person or anything, but there are times it would be nice
to use URL's. I think the above suggested handling would probably be
enough.
One thing that makes me want this is the difficulty of pointing to another
page in your Pier site from a custom component. I know you have the #goto:
message on anchor, but (1) I need it anywhere a URL could be used, since I
am using "html tag:" to do some tags not in seaside (an HTML image map to be
specific). And (2) the #goto: message expects a structure that can be tough
to get a hold of sometimes. The easiest thing for me would be if I could
simply point my image map at the URL as a string, since that part is public
and I don't care if the user is logged in or not.
And lastly, I have had some users complain about the ugly URL's. I know you
can say that they shouldn't look at the URL, etc. etc., but if we can make
this better why not?
What I was thinking was, how hard would it be to change Pier so that the URL
part stays, but at least the session (and maybe the command and view fields
as well) could optionally be cookies. And this could even be something
configured in the /seaside/config/pier page.
Thanks in advance. You may have ways to do all these things by now, but I
thought I would check.
Jason
_________________________________________________________________
Valentines Day -- Shop for gifts that spell L-O-V-E at MSN Shopping
http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tco…
Hi,
I have a question about PRReportView.
In Pier-Seaside-lr.125, PRReportView reveals all contents for any user.
PRReportView>>buildStructures
^ self context enumerator all contents
I think that the pages which are prohibited for the user should not be
reported. So that, the code will be modifyed like this.
PRReportView>>buildStructures
^ Array
streamContents: [:stream | self context structure enumerator all
do: [:each | (each isValidCommand: self context command class in: self context)
ifTrue: [stream nextPut: each]]]
-- !
Koji Yokokawa <koubo2006(a)yengawa.jpn.org>
http://yengawa.com/
^self new!
Hi,
I was trying out the Blog component and it doesn't seem to work for me. After adding the Blog component, I get this error:
WARenderedHtmlRoot(Object)>>doesNotUnderstand: #rss
Surely enough I can't find any implementors of #rss in Seaside or Pier. The following method is the one that's sending #rss to a WARenderedHtmlRoot object.
PRRecentView(PRBlogView)>>updateRoot: aHtmlRoot
super updateRoot: aHtmlRoot.
aHtmlRoot rss
title: self blog feedTitle;
url: self subscriptionUrl
Since the Blog component works in your screencast, I guess you might be missing an update to the to repository (Seaside?) somewhere.
I am using Pier-All-lr.151, Pier-Blog-lr.29, and Seaside2.7a1-lr.166.
-Bill
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
> (PRCompatibility confirm: 'Would you like to create a Seaside
> application for Pier?')
> ifTrue: [^ self].
>
> This seems to cause the application to not create a Pier
> application if you say yes, so I clicked no and sure enough, it
> built everything. I could fix it, but I thought I would check with
> you first.
Ohh yeah, this is a bug. I just recently re-factored this method and
introduced this error. The latest version fixes this issue.
Lukas
>
> Thanks,
> Jason
>
>
>> From: Lukas Renggli <renggli(a)iam.unibe.ch>
>> Reply-To: "Magritte, Pier and Related Tools ..."
>> <smallwiki(a)iam.unibe.ch>
>> To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
>> Subject: Re: Status of Pier
>> Date: Tue, 30 Jan 2007 23:27:30 +0100
>>
>> > First, in my image, if you go to a page and then go to lunch, come
>> > back and hour later and click a link you get dropped back to the
>> > front page because your session has expired. But I thought Pier
>> > used the URL to be able bookmark, surf the side via URL etc. In
>> > fact, I thought it even worked this way before I put the security
>> > package in.
>>
>> Yes, it should work and remember the page even if the session
>> expired.
>>
>> > Has this been fixed? It seems like if you click on a link that has
>> > a URL, but an old session Pier could just make a new session and
>> > apply that to the page the user is trying to go to. If the user is
>> > not allowed to see that resource with the blank session then kick
>> > them back to the front like now, but if the page is not restricted
>> > they should see it.
>>
>> This is a bug in Seaside. I fixed it, and the scenario you describe
>> works when you load the latest version:
>>
>> Name: Seaside2.7a1-lr.162
>> Author: lr
>> Time: 30 January 2007, 11:23:44 pm
>> UUID: b22fe0c4-77c1-4e3d-99f7-331a368c4337
>> Ancestors: Seaside2.7a1-pmm.161
>>
>> > Second, is there any plan to expand on the RESTfulness of Pier? I
>> > mean, I'm not a die-hard REST person or anything, but there are
>> > times it would be nice to use URL's. I think the above suggested
>> > handling would probably be enough.
>>
>> Yep, that's a requirement. Thanks that you reported this, I probably
>> wouldn't have noticed it myself.
>>
>> > One thing that makes me want this is the difficulty of pointing to
>> > another page in your Pier site from a custom component. I know you
>> > have the #goto: message on anchor, but (1) I need it anywhere a URL
>> > could be used, since I am using "html tag:" to do some tags not in
>> > seaside (an HTML image map to be specific). And (2) the #goto:
>> > message expects a structure that can be tough to get a hold of
>> > sometimes. The easiest thing for me would be if I could simply
>> > point my image map at the URL as a string, since that part is
>> > public and I don't care if the user is logged in or not.
>>
>> Glad that you ask. For the blog component I also felt the need to
>> have just the url and not only an anchor. I think I will need to add
>> that sooner or later. Shouldn't be too difficult though.
>>
>> > And lastly, I have had some users complain about the ugly URL's. I
>> > know you can say that they shouldn't look at the URL, etc. etc.,
>> > but if we can make this better why not?
>> >
>> > What I was thinking was, how hard would it be to change Pier so
>> > that the URL part stays, but at least the session (and maybe the
>> > command and view fields as well) could optionally be cookies. And
>> > this could even be something configured in the /seaside/config/pier
>> > page.
>>
>> Go to the Seaside configuration page and enable 'Use Session
>> Cookies'. This will put the session key into a cookie, if possible.
>>
>> > Thanks in advance. You may have ways to do all these things by
>> > now, but I thought I would check.
>>
>> Cheers,
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>>
>>
>> _______________________________________________
>> SmallWiki, Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
> _________________________________________________________________
> Talk now to your Hotmail contacts with Windows Live Messenger.
> http://get.live.com/messenger/overview
>
--
Lukas Renggli
http://www.lukas-renggli.ch
