smallwiki January 2010

smallwiki@list.inf.unibe.ch

23 participants
34 discussions

PRAjaxSearchWidget not working on Seaside3

by Nick Ager

Hi, PRAjaxSearchWidget does not return any results using the latest Seaside3/Pier2 packages Steps to reproduce * download latest build from: http://hudson.lukas-renggli.ch/job/Seaside%203.0/ <http://hudson.lukas-renggli.ch/job/Seaside%203.0/>* open and start web server * open a workspace and execute: PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel named: 'defaultKernel'). * type something into the search box, observe the XHR request/responses; the text typed is being sent, however no results are returned. The problem seems to be that the textInput callback is not called, however I noticed that the callback in SUAutocompleterTest is also never called. By mimicking the code in SUAutocompleterTest I have a local working version of PRAjaxSearchWidget, with the following changes: Old version: PRAjaxSearchWidget>>renderContentOn: .... html scriptaculous autocompleter ... on: #renderItemsOn: of: self modified version: PRAjaxSearchWidget>>renderContentOn: .... html scriptaculous autocompleter ... on: #renderItemsOn:for: of: self Old version: PRAjaxSearchWidget>>renderItemsOn: html html unorderedList: [ self items do: [ :each | html listItem passenger: each; " the only difference to the original " with: [ self renderItem: each on: html ] ] ] Modified version: PRAjaxSearchWidget>>renderItemsOn: html for: aString self searchText: aString. html unorderedList: [ self items do: [ :each | html listItem passenger: each; " the only difference to the original " with: [ self renderItem: each on: html ] ] ] If the above changes make sense, I'll push them into the repository. Nick

14 years, 2 months

[ANN] PDF of Dynamic Web Development with Seaside

by Lukas Renggli

The PDF version of the book "Dynamic Web Development with Seaside" is available for download now: http://book.seaside.st/book/introduction/pdf-book At the end of the payment process (PayPal) you will be redirected to the download area where you are able to get the latest builds of the PDF version of the book. If you bookmark the page you will be able to download fixes and extra chapters as we integrate them into the online version. By buying the PDF version you support our hard work on the book. We wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk and GemStone Smalltalk for generously sponsoring this book. We are looking for additional sponsors. If you are interested, please contact us. If you are a publisher and interested in publishing this material, please let us know. Please distribute this message widely. Cheers, Stef & Lukas -- Lukas Renggli http://www.lukas-renggli.ch

14 years, 2 months

Pier user data stored in filesystem was Re: [squeak-dev] Cuis

by David Corking

On Mon, Jan 25, 2010 at 4:25 PM, keith wrote (on the squeak-dev list) : > pier keeps its data in image. I know the following info is unlikely to help your current application, but, in the interest of completeness, I will observe that at least one Pier application stores its user data in the host filesystem, not the image. That application is WikiServer (John McIntosh's cross-platform personal wiki for the iPhone) I only have superficial familiarity with Pier and WikiServer: as far as I can tell, the persistency code uses MAExternalFileModel, but sadly I can't guess if the effect is available to all Pier developers, or proprietary to WikiServer.

14 years, 2 months

uft-8 MAFileModelHandler

by Nick Ager

In Pier on Seaside 3, if I use a utf-8 encoded Comanche Adapter, I receive a walkback "MNU: ByteArray>>isByteString" The error is generated from: GRPharoUtf8CodecStream>>nextPutAll nextPutAll: aString binary ifTrue: [ stream nextPutAll: aString asString ] ifFalse: [ aString isByteString ifTrue: [ self encodeFast: aString ] ifFalse: [ self encodeDefault: aString ] ] while trying to serve "style.css" which originates from: PRStructure>>defaultEnvironment ^ (PRPage named: 'environment') addChild: ((PRFile named: 'style.css') filename: 'style.css'; mimetype: 'text/css'; contents: '/* blueprint patches */........ To reproduce: 1 Download the one-click 3.0a5 release from seaside.st 2 Select utf-8 encoding on the WAComancheAdapter (right click within Seaside Control Panel -> Encoding...) 3 Browse to localhost:8080/pier There seem to be a number of places where a fix could be made, but I'm not sure which (if any) would be the most appropriate: * MAFileModelHandler>>handleFiltered - the GRPharoUtf8CodecStream response stream is created, without utf-8 encoding, a GRNullCodecStream is created instead. * PRFile>>contents: perhaps PRFile shouldn't always convert the contents to a ByteArray * Perhaps ByteArray should implement isByteString. Any thoughts? Nick

14 years, 2 months

Re: Pier2 addons...

by Reza RAZAVI

At 11:10 23/01/2010, Nick Ager wrote: >The one exception being the Pier-Book package which hasn't been >merged with the latest trunk changes and AFAIK is a port of the book >repository from early September. I'm using the Book package from Pier1 addons repository (http://source.lukas-renggli.ch/pieradons) with a Pier2 image. No specific issues to report till now. /Reza

14 years, 2 months

Pier2 addons...

by Dale Henrichs

I'm also building a configuration for Pier addons and I'm curious which of the addons have been successfully ported to Pier2 ... I've seen that Pier-Blog is apparently working. Are there others? I'm just trying to give an accurate picture of the current Pier2 universe... Dale

14 years, 2 months

Pier-Pharo-Persistency dependency on Pier-Model-Tests

by Dale Henrichs

I'm building Metacello configurations for Pier2 (and Magritte2) and I've run into the fact that the tests for Pier-Pharo-Persistency are included in the package and that those tests depend upon Pier-Model-Tests. Since things have been repackaged for Pier2, it might make sense to split out the Pharo-persistency tests so that things can be loaded without tests. Of course, if this is intentional..."Never mind":) Dale

14 years, 3 months

PRSearchView

by Nick Ager

Hi, PRSearchView raises an exception once the form is submitted. The problem is that in the #refresh method the call to "self context" returns nil, so the following fails: searcher := self context root fullTextSearch. Investigating the problem I noticed that it's immediate super class PRViewComponent implements #setContext: and context and the more distant superclass WAPresenter implements #context: context. I fixed the problem locally by adding "self setContext: PRCurrentContext value.", before the call to "self context" and I see search results, but it feels more like a hack than a fix. Some thoughts: * Does PRViewComponent store context for performance, if I removed these methods (setContext: & #context) the search would function without my change. * There seems to be a naming inconsistency with #setContext: & #context: Any thoughts? Nick PS Thanks again for the all the help - I *really* appreciate it.

14 years, 3 months

Re: PRSearchView

by Reza RAZAVI

At 23:46 21/01/2010, Nick Ager wrote: >* Register a new Pier app as: >PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel >new root: ((PRComponent named: 'search') componentClass: >PRSearchView); name: 'testKernel'). Nick, PRSearchView is a subclass of PRViewComponent, which expects to be instantiated with #on:, instead of #new. The argument to #on: is supposed to be aContext, which is then cached for later use by methods like #refresh. There is an example of such call in PRViewCommand >> viewComponent. The issue is related to the fact that in your case, PRSearchView is instantiated by #new. Here is the call sequence: PRPierFrame >> children PRPierFrame >> buildChildren PRPierFrame >> componentsOf: (PRComponent) PRStructure >> componentsIn: PRContext >> componentFor: PRContext >> buildComponent:for: PRComponent >> componentFor: PRSearchView class (WAComponent)>> owner:link: #owner:link: calls #new, instead of #on: Now, there are PRWidgets that don't cash the context, and can be instantiated by #new. Consequently, the above call sequence works just fine in their case. And, Pier standard distributions use PRAjaxSearchWidget instead of PRSearchView,, which is a kind of PRWidget. So, the following app should work: PRPierFrame registerAsApplication: 'piersearch' kernel: (PRKernel new root: ((PRComponent named: 'search') componentClass: PRAjaxSearchWidget); name: 'testKernel'). Hoping this helps, Regards, Reza

14 years, 3 months

Any Progress on the multi-lingual Pier

by Keith Hodges

Hi folks, Was any progress made on this? Keith

14 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki January 2010