Hi,
I forgot to mention in my previous mail how to load refactoring
support (currently
refactoring tool support doesn't load by default):
Gofer it
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfMagritte3';
load.
ConfigurationOfMagritte3 project stableVersion load: 'Magritte-Pharo-Tools'
This will load refactoring support to move Magritte 1 or 2 described
objects to instance-side pragma descriptions.
It also loads deprecated code such as #description with redirects to
#magritteDescription with a deprecation warning.
-----
So that everything is the same place here are the porting guidelines I
posted previously:
1) search for all senders and implementors of #description in your code, if
they are magritte descriptions rename the selector from #description to
#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' as 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:
(PRComponent named: 'contents')
prototypeInstance: (PRContentsWidget new
heading: '%c';
yourself);
yourself
add setters to allow initial settings to be set on the prototype instances
again see PRViewsWidget and PRSearchWidget for examples.
7) Put 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. Note Object>>#description and Object class>>#description
are only present if you load 'Magritte-Deprecated'
Hi,
I've completed an initial port of Pier to Magritte with pragma instance
side descriptions - now known as Magritte 3. The Pier port is now named
Pier 3.
In addition to base systems I've ported the following:
Magritte 3 ported addons:
--------
Magritte-Json
MAgritte-XMLBinding
Pier 3 ported addons:
-----
Pier-Admin
Pier-Blog
Pier-Book
Pier-Desihn
Pier-Documents
Pier-EditorEnh
Pier-FileUpload-*
Pier-Google
Pier-JQuery
Pier-Kernel-Distributions
Pier-LinkChecker
Pier-Shout
Pier-Wysiwyg
Pier-Exporter-Code
Pier-Randomizer
Pier-Setup
Pier-Twitter
Note I've moved the Pier-Blog and Pier-Book to the Pier 3 add-ons
repository (http://source.lukas-renggli.ch/pier3addons)
The repositories are:
http://source.lukas-renggli.ch/pier3http://source.lukas-renggli.ch/magritte3http://source.lukas-renggli.ch/magritte3addonshttp://source.lukas-renggli.ch/pier3addons
Note: I've deleted "Pier 2 unstable" and "Magritte 2 unstable" repositories
- all the code has migrated to the repositories above.
There are four supporting configurations:
ConfigurationOfMagritte3
ConfigurationOfMagritte3AddOns
ConfigurationOfPier3
ConfigurationOfPier3AddOns
Try it out with:
Gofer it
squeaksource: 'MetacelloRespository';
package: 'ConfigurationOfPier3AddOns';
load.
ConfigurationOfPier3AddOns project stableVersion load: 'Pier-Admin'
the above will pull in a significant portion of the add ons and core
libraries and give you a sense of how stable the code is.
Caveats:
----
All the tests are green, but I've only applied limited testing.
I've tested the above 'Pier-Admin' loading on a clean Pharo 1.3 image.
I've removed the Gemstone information from the configurations. I guess once
everything is stable on Pharo we can consider a Gemstone port.
Let me know how you get on
Nick
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*
*
*