When I merged the latest Pier code with the Pier for Seaside 3.0 branch I
noticed that the Pier logo wasn't appearing on the initial screen, although
it appeared on the 3.0 branch prior to the merge.
I traced the difference in behaviour down to a code change in
PRViewCommand>>initialRequest
the pre-merge version:
initialRequest: aRequest
| viewClass |
super initialRequest: aRequest.
viewClass := PRPierFrame
classFromRequest: aRequest
name: 'view'
base: PRViewComponent.
(viewClass isNil and: [ self structure isFile ])
ifTrue: [ viewClass := PRDownloadView ].
(viewClass notNil and: [ viewClass isValidIn: self context ])
ifTrue: [ self viewComponentClass: viewClass ].
self viewComponent visiblePresentersDo: [ :each | each initialRequest:
aRequest ].
(self viewComponent isFullResponse)
ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
post-merge version:
initialRequest: aRequest
| viewClass |
super initialRequest: aRequest.
viewClass := PRPierFrame
classFromRequest: aRequest
name: 'view'
base: PRViewComponent.
(viewClass notNil and: [ viewClass isValidIn: self context ])
ifTrue: [ self viewComponentClass: viewClass ].
self viewComponent visiblePresentersDo: [ :each | each initialRequest:
aRequest ].
(self viewComponent isFullResponse)
ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
the pre-merge version has the addition of the code: (viewClass isNil and: [
self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].
However this code isn't present in the main 2.8 code-base. The problem is
more subtle. The pier environment stylesheet requests an image from:
'/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by
the code in WAOldPathComptibilityRequestHandler which issues a 301 moved
permanently redirect to '/pier/environment/pier.png'. The problem is that
during the redirection the url parameters have been lost. I've fixed the
problem locally by changing
WAOldPathComptibilityRequestHandler>>handleFiltered: from:
handleFiltered: aRequestContext
| url |
url := aRequestContext request url copy.
url path removeFirst.
aRequestContext response
movedPermanently;
location: url.
aRequestContext respond
to:
handleFiltered: aRequestContext
| url |
url := aRequestContext request url copy.
url path removeFirst.
url parameters: aRequestContext request fields.
aRequestContext response
movedPermanently;
location: url.
aRequestContext respond
I copy the parameters from the request to the url. Should I save this change
into seaside 3.0 repositories? Or is there something else that needs fixing
higher up the call stack to account for why the parameters haven't been
added to the WAUrl object?
Hope this all makes sense
Nick
I reviewed all my merges and discovered I'd lost changes in:
PRPierFrame>>initialRequest
PRViewCommand>>initialRequest
MAOneToManyComponent>>add
With the corrections in place, Pier appears to working once again. There are
a couple of anomalies - the Pier logo doesn't appear on the home screen and
I received one walkback while clicking around. I'll investigate these
problems later. I've also yet to look at any add-ons including the
Pier-Blog.
I've loaded the code into a fresh seaside3.0a5 image (with updated Gofer)
and the code loads cleanly.
For reference the load script I used was:
"Load Magritte for Seaside 3"
Gofer new
renggli: 'magritte2';
package: 'Magritte-Model';
package: 'Magritte-Pharo-Model';
package: 'Magritte-Tests-Model';
package: 'Magritte-Tests-Pharo-Model';
package: 'Magritte-Seaside';
package: 'Magritte-Pharo-Seaside';
package: 'Magritte-Morph';
load.
"Load Pier for Seaside 3"
Gofer new
renggli: 'pier2';
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';
load.
PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
(PRPage new title: 'test'; contents: 'Pier on Seaside 3.0'))
As I'm still not terribly comfortable with the merging tools in Pharo, I've
tried to be as cautious as possible:
1) check there are no changes against in my image from magritte2 or pier2
repositories.
2) merge with magritte or pier repository - if uncertain check changes over
last few months in 2.8 repositories
3) check the merged code for expected differences in the magritte2 or pier2
repositories
Magritte-Model & Magritte-Pharo-Model
Merge was straightforward. examining the differences after merge between the
two repositories I noticed:
MACompatibility doesn't exist with most of the methods being moved to
GRPlatform. However request:default: has been added in MACompatibility for
which there doesn't appear to be a equivalent in GRPlatform Also I couldn't
find an equivalent of openWorkspace:titled: in GRPlatform. So I added
magritteRequest:default: and magritteOpenWorkspace:title to GRPlatform with
Pharo implementations in GRPharoPlatform.
Magritte-Tests
Lots of merge conflicts, but then I realised that I'd only
loaded Magritte-Tests-Model and Magritte-Tests-Pharo-Model
*not* Magritte-Tests - Suddenly what was being said previously in the list
about maintaining version history made sense. I reloaded the tests and tried
to merge again. No merge conflicts, only three updated methods.
-all tests pass-
Magritte-Morph
No changes - though I fixed the load error in MAFileMorph>>choose I changed
FileList2 -> FileList
Magritte-Seaside & Magritte-Pharo-Seaside
Straightforward merge, didn't spot anything which needed to be changed for
cross-platform
Pier
------
What's the purpose of the Magritte-Model, Magritte-Seaside and
Magritte-Tests packages in the pier2 repository? I used the packages in the
magritte2 repository. Hope that was the plan.
Pier-Core - empty package
Pier-Model
lots of changes but only a couple of merge conflicts and a couple of
s/asString/greaseString/ and one
s/allSubInstancesOf:do:/magritteAllSubInstancesOf:do:/
Pier-Seaside
lots of changes, but again only a couple of merge conflicts and one
s/displayString/greaseString/
Pier-Security
only a couple of methods had changed, one merge conflict
Pier-Tests
lots of changes, only one merge conflict
-all tests pass-
I'm about the save the merged code, but when I try I get an Error: HTTP1.1
401 Unauthorized
Does someone need to give me write permissions to
http://source.lukas-renggli.ch/magritte2 and
http://source.lukas-renggli.ch/pier2
Cheers
Nick
Happy New Year to the list.
I've been developing a site using vanilla seaside 3.0a5, and have belated
released that there's much functionality in base Pier and the add-ons which
would save me significant time. From what I can gather from a brief search
of the list there is an early port to 3.0, though I've struggled to load it
into my image. Is there a load script I can use for 3.0? Is it really
sensible to try an early 3.0 port when I'm still struggling to get to grips
with the basic concepts - would I be better off using 2.8 and revert my
jQuery code to prototype/scriptaculous?
Thanks Nick
Folks,
I'm producing a internal website for my employer, (essentially a front
end for an ancient, somewhat-relation database...), and I've built a few
seaside components (by subclassing WAComponent) for this purpose.
I'm thinking that maybe the best way to structure the site is to allow
these seaside components (tabular displays, forms, etc) to be embedded
within Pier.
I've downloaded the Pier 1.2 image from the piercms.com site, have
loaded my seaside components in, and am able to create links to the
components fine.
My question is: how do I go about preserving the state of my components?
For example, a tabular report will have an ivar which holds a reference
to a query object, which itself holds (among other things) the name of
the database table. After creating the component and setting the table
name via the web browser, returning to the pier home page, and folling
the links to go back to my component, I'm actually given a new instance
of my component, which of course has newly initialized variables. (I can
see the new instances accrewing in the image by exploring
#allInstances.)
Presumably there is some mechanism within Pier for dealing with this.
What do I need to do with my components to tie into this?
Also, note that I'm not talking about achieving Magma-style object
persistence here; saving the image periodically will do just fine for my
purpose.
Thanks,
Nick
Pier experts,
Does anyone know if it is possible to get the user's IP address from
the Session object? Inspecting into it doesn't show anything like
this, but I didn't know if anyone has made a custom session that
stores this.
Thanks,
John
Also - Does anyone know why seasidehosting.st is down?
Hi!
I and a collegue are building a "form engine portal"-kinda-thingie and
we are using Seaside3.0 and Magritte. The goal is to create a "standard"
for describing wizard-like-forms and then to use Magritte to create a
good looking "engine" for these wizards.
Now, as I can see it seems that Magritte has no notion of "pages" as in
a wizard or anything wizard-like, right? So my current conclusion is
that it would be best for us to create the Wizard component that uses a
dynamically generated Magritte component for each "page", seems reasonable?
Secondly, how hard is it - or can Magritte already use say JQuery to do
"immediate" validation etc on fields? We need to be a biz snazzy here
and make it look good so I want to be able to do validation when the
user moves focus from a field etc.
Anyway, it is fun to get into Magritte (last time I looked it was
slightly immature and we opted to build our own "similar" thing in
Gjallar instead of reusing Magritte) - but could someone point to more
good examples perhaps? The unit tests are written in an ... "economic"
style which doesn't leave them as easily digested examples IMHO. ;)
regards, Göran
Hi there,
when I include an image into my pier page, I don't find the point in
time where I may set the size of the image in the browser. I'm looking
for something like the Wikipedia [[Image:wiki.png|30 px|Wikipedia
Encyclopedia]], which woul dinclude the image wiki.png in 30 px size.
Cheers,
Niko
--
http://scg.unibe.ch/staff/Schwarztwitter.com/nes1983
Tel: +41 076 235 8683
2009/7/31 Mariano Martinez Peck <marianopeck(a)gmail.com>
>
> On Thu, Jul 30, 2009 at 11:35 PM, John McKeon <p3anoman(a)gmail.com> wrote:
>
>> Hi Mariano!
>> Try using the Browse command.
>
>
> As always, John giving me the light ;)
>
> Yeah!!! That did the trick. As I cannot go to that file, I went to the
> parent and used the browse command and all the childs were also listed. Then
> I selected the child (the file I wanted to remove) and I removed!!!
>
>
Yes, that works. But the problem is still there: unable to manage files
(pictures for example) like other ('usual') components. The picture is just
rendered as is, without any Pier tools around. How can I fix this?
--
Dennis Schetinin
