30 Jan
2007
30 Jan
'07
10:15 p.m.
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&…
30 Jan
30 Jan
11:27 p.m.
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
3 Feb
3 Feb
7:36 p.m.
New subject: Status of Pier (Update)
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.
8:57 p.m.
New subject: Status of Pier (Update)
Ausome, that's great. Pier is really getting solid.
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 (Update)
Date: Sat, 3 Feb 2007 19:36:23 +0100
The Pier context object (representing the current browsing context of
the user) has now two additional methods:
- #url returns a REST-full instance of WAUrl. All session information
will is discarded when using this URL, but the current structure and
command and view are preserved. It is save to bookmark this URL and
to give it to your friends.
- #urlOn: what returns a Seaside URL triggering an action callback
that sets the receiving context. This URL can also be bookmarked but
should not be passed to your friends. As long as your Seaside session
is valid, it will remember all the state. After the Seaside session
expired the URL has the same effect as #url.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_________________________________________________________________
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://im…
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. 
11:05 p.m.
New subject: Status of Pier (Update)
2007/2/3, Lukas Renggli <renggli(a)iam.unibe.ch>ch>:
The Pier context object (representing the current browsing context of
the user) has now two additional methods:
- #url returns a REST-full instance of WAUrl. All session information
will is discarded when using this URL, but the current structure and
command and view are preserved. It is save to bookmark this URL and
to give it to your friends.
- #urlOn: what returns a Seaside URL triggering an action callback
that sets the receiving context. This URL can also be bookmarked but
should not be passed to your friends. As long as your Seaside session
is valid, it will remember all the state. After the Seaside session
expired the URL has the same effect as #url.
Was about time ;)
Now I need to update my plug-ins :(
Philippe
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.
4 Feb
4 Feb
11:11 p.m.
New subject: Another bug :) (was Re: Status of Pier)
I use a login and no persistency at the moment, so when I tried to log in I
got a DNU on #critical. PULogin tries to call #execute: in the perstistancy
which calls #critical on it's mutex, but since PRNullPersistancy doesn't
have a mutex (it is nil), I get a DNU. I just did an override in
PRNullPersistancy for #execute: to simply call #apply: to get it working for
me.
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
_________________________________________________________________
Check out all that glitters with the MSN Entertainment Guide to the Academy
Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2
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
5 Feb
5 Feb
7:22 a.m.
New subject: Another bug :) (was Re: Status of Pier)
I use a login and no persistency at the moment, so
when I tried to
log in I got a DNU on #critical. PULogin tries to call #execute:
in the perstistancy which calls #critical on it's mutex, but since
PRNullPersistancy doesn't have a mutex (it is nil), I get a DNU. I
just did an override in PRNullPersistancy for #execute: to simply
call #apply: to get it working for me.
I guess you have to re-initialize the persistency in the kernel. I
just recently moved the session mutex from the kernel to the place
where it really belongs, the persistency.
PRKernel instances do: [ :each |
each persistency: PRNullPersistency new ]
After that everything should work without modifying PRNullPersistency.
The Semaphore is important in PRNullPersistency, as this ensures that
the model does not get corrupted by concurrent modifications.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
7:31 a.m.
New subject: Another bug :) (was Re: Status of Pier)
Ah ok, done. Thanks.
In testing this, I just noticed that when I come back to a session that is
old and expired and do login I get a DNU on nil again. This time it looks
like PULogin is calling anscestor and there is nothing there.
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: Another bug :) (was Re: Status of Pier)
Date: Mon, 5 Feb 2007 07:22:53 +0100
_________________________________________________________________
Invite your Hotmail contacts to join your friends list with Windows Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://sp…
I use a login and no persistency at the moment,
so when I tried to
log in I got a DNU on #critical. PULogin tries to call #execute:
in the perstistancy which calls #critical on it's mutex, but since
PRNullPersistancy doesn't have a mutex (it is nil), I get a DNU. I
just did an override in PRNullPersistancy for #execute: to simply
call #apply: to get it working for me.
I guess you have to re-initialize the persistency in the kernel. I
just recently moved the session mutex from the kernel to the place
where it really belongs, the persistency.
PRKernel instances do: [ :each |
each persistency: PRNullPersistency new ]
After that everything should work without modifying PRNullPersistency.
The Semaphore is important in PRNullPersistency, as this ensures that
the model does not get corrupted by concurrent modifications.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
8:21 a.m.
New subject: Another bug :) (was Re: Status of Pier)
In testing this, I just noticed that when I come back
to a session
that is
old and expired and do login I get a DNU on nil again. This time
it looks
like PULogin is calling anscestor and there is nothing there.
Nice catch. It is fixed in:
Name: Pier-Security-lr.68
Author: lr
Time: 5 February 2007, 8:19:33 am
UUID: 0ba0f70b-1f5f-4592-b314-878fdb10c9dd
Ancestors: Pier-Security-lr.67
Thanks for reporting!
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
7:58 p.m.
New subject: Another bug :) (was Re: Status of Pier)
Thanks for the fix! My site is pretty well perfect at this point.
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: Another bug :) (was Re: Status of Pier)
Date: Mon, 5 Feb 2007 08:21:29 +0100
_________________________________________________________________
FREE online classifieds from Windows Live Expo buy and sell with people
you know
http://clk.atdmt.com/MSN/go/msnnkwex0010000001msn/direct/01/?href=http://ex…
In testing this, I just noticed that when I come
back to a session
that is
old and expired and do login I get a DNU on nil again. This time
it looks
like PULogin is calling anscestor and there is nothing there.
Nice catch. It is fixed in:
Name: Pier-Security-lr.68
Author: lr
Time: 5 February 2007, 8:19:33 am
UUID: 0ba0f70b-1f5f-4592-b314-878fdb10c9dd
Ancestors: Pier-Security-lr.67
Thanks for reporting!
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
6538
days inactive
6544
days old
9 comments
3 participants
participants (3)
-
J J -
Lukas Renggli -
Philippe Marschall