Hi,
is there any photo gallery available for Pier? I mean a widget where I
could upload pictures and they are rendered in a nice way. I started
one 4 years ago but I abandoned it.
Bye
--
Damien Cassou
http://damiencassou.seasidehosting.st
i have two new pier sites going up, and i am not sure where the issue
is, but the headless server seems to die after a few hours..
i got the vm from one of the cog prebuilt binaries, but i would have
to go searching around to find out where..
the details are:
VM Version: Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.140]
VM Type: 32bit
Endianness: little
anyway.. i was wondering which one everyone was currently using on
their deployed systems..
thanks!
--
----
peace,
sergio
photographer, journalist, visionary
http://www.CodingForHire.comhttp://www.coffee-black.comhttp://www.painlessfrugality.comhttp://www.twitter.com/sergio_101http://www.facebook.com/sergio101
I have been working on understanding Magritte and tried the First
Example in the Seaside Book (Lulu publication, page 358, section 24.2).
The Example failed to run, apparently because the method keyword,
accessor:, in the descriptions wasn't recognized. When I added my own
getters and setters for the instance variable names (street, plz, etc)
everything in the Example worked fine.
Is the code in the Example perhaps outdated? Could someone suggest what
method I might use? I tried asAccessor: and selectorAccessor: with no
success.
Hi,
Today I checked-in a fix which reverts a change I made to try to stop
multiple PRContextFilter s being added to the session filter chain.
Unfortunately the fix caused unintended side-effects, which I believe
contributed to the problems Sergio mentioned. Hopefully the reversion
should fix some or all of these problems.
However there's still an issue with the interaction of PRContext,
PRContextFilter, cookies, component creation and Restful urls. To
illustrate the issue execute the following:
createSimplestPierPRContextFilterIssue
| app rootPage |
rootPage := (PRPage named: 'rootPage') contents: '+counter+'; yourself.
rootPage localEnvironment: ((PRComponent named: 'contents')
componentClass: PRContentsWidget; yourself).
rootPage addChild: ((PRComponent named: 'counter') componentClass:
WACounter; yourself).
app := PRPierFrame registerAsApplication: 'contexttest' kernel: (PRKernel
named: 'contexttest' root: rootPage).
then browse to http://localhost:8080/contexttest You should see a counter
instance. Increment the value of the counter once. Then in a new window/tab
of the same browser, browse to same url (http://localhost:8080/contexttest)
and decrement the value of the counter once. Now return to the original
value and increment again - the counter displays the value "-1" rather than
"2".
If I try the same test in Pier 1, (note in Pier 1 you'll have to manually
enable cookies through the /config), when I first browse to the second tab,
the counter already displays "1".
What's happening? In the Pier 2 case:
* PRPierFrame>>#initialRequest is called for every Restful url. There is no
distinction between a call when a new session has been created and a call
with an existing session.
* In PRPierFrame>>#initialRequest a new PRContextFilter is added to the
session: "self session addFilter: (PRContextFilter on: self)"
* In WASession>>#handleFiltered: aRequestContext, if there is no
continuation key, #start is called on the session, which creates a new root
component - in this case a new PRPierFrame.
* So every time we browse to a Restful url a new PRPierFrame is created
which holds the PRContext. This context is then "held" by the
PRContextFilter.
What does this mean in our counter example:
In the first tab a new session is created, a new PRPierFrame, a new
PRContextFilter and a new WACounter instance are created. The link to
increment the counter contains a continuation key so #initialRequest isn't
called and callback is fired incrementing the counter which in turn
displays "1".
In the second tab the session already exists, however without a
continuation key a new PRPierFrame, a new PRContextFilter and a new
WACounter instance are created. Decrementing the counter decrements it on
the new WACounter instance.
Now returning to the first tab we again try to increment the counter. The
callback on the first component created is called and the counter is
incremented. However in the rendering phase, the second component created
in the second tab is displayed, with it's counter unincremented and set to
"-1".
What are the problems:
* There is no distinction between #initialRequest called with a newly
created session and #initialRequest called from a session recovered via a
cookie. Neither is there an obvious way of detecting for which case
#initialRequest
has been called.
* Within WASession>>#handleFiltered: if no continuation key exists a new
root component is created.
* A new PRContextFilter is added for each Restful call.
Two possible solutions:
* A new PRPierFrame is only created when a new session is created. This
should then function as Pier 1. However if the root presenter is exchanged
in one open tab e.g. with a #call or #show on the root, then other open
tabs will not operate as intended. The implementation would I think require
a custom session with a custom #handleFiltered: or alternatively a modified
WASession which allows configurable behaviour when there's no continuation
key.
* If however we want to allow for multiple components so that state isn't
maintained between two identical Restful - that is both counters start at
0. Then we could move PRContext into the session, and remove the
PRContextFilter.
I hope this makes sense I've I understood the situation correctly. Any
thoughts?
Nick
Hi,
I've checked-in an initial port of Pier using Magritte with pragma support
into: http://source.lukas-renggli.ch/pier2unstable - all tests are green
and with a cursory test everything appears to be functioning as before.
The port includes the following packages:
pier-model
pier-seaside
pier-security
pier-pharo-model
pier-pharo-persistency
pier-tests-model
pier-test-security
and the following add ons:
pier-blog
pier-book
pier-setup
pier-google
pier-documents
Next steps:
1) Be great if people can try the initial port and report any errors or
different behaviour
2) If success with 1) perhaps we can move to new repositories (e.g.
Magritte3, Pier3, Pier3addons)
3) Continue porting addons. There are many add-ons in both
http://source.lukas-renggli.ch/pieraddons and
http://source.lukas-renggli.ch/pier2addons that would be great to port.
4) Document the changes to Magritte and how they effect Pier.
Porting guide:
*1) search for all instances of #description if they are magritte
descriptions rename the method #magritteDescription
2) remove #magritteDynamic and remove the block around the method.
3) Use the refactoring support to move class-side descriptions to instance
side descriptions with pragmas - making sure that any accessors to class
side methods are either prefixed with ‘class’ or moved to the instance
side. If you move description help methods to instance side be careful if
they contain context := PRCurrentContext value - context will shadow an
instance variable of the same name so either replace context with self
context and remove context := PRCurrentContext value or rename context say
theContext and replace context := PRCurrentContext value with theContext :=
self context.
4) Remove any empty categories on the class side.*
*5) PRWidget derived classes should either by modified to be derived from
PRWidgetPropertyBase or keep derived from **PRWidget but modify the
accessors to store state in instance variable rather than the property
dictionary in **PRWidgetPropertyBase. See PRViewsWidget and PRSearchWidget
for examples of both types of port.*
*6) Modify structure initialisation with PRComponent to use prototype
instance rather than classes. So*
*
(PRComponent named: 'contents')
componentClass: PRContentsWidget;
write: '%c' using: PRContentsWidget descriptionHeading;
yourself
becomes to:
(PRComponent named: 'contents') prototypeInstance: (PRContentsWidget new
heading: '%c'; yourself)
**
yourself
**
you may well have to add setters to allow initial settings to be set on the
prototype instances again see **PRViewsWidget and **PRSearchWidget for
examples.*
*7) P**ut a break point in Object>>description and Object
class>>description to trap any cases you’ve missed (the break-point should
not be hit) and check the add-on.*
*
*
*Hope this makes sense*
*
*
*Nick*
*
*
