smallwiki September 2010

smallwiki@list.inf.unibe.ch

16 participants
19 discussions

by Damien Cassou

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

6 years, 11 months

Magritte description for e-mail

by dtrussardi＠tiscali.it

Hi, i have some descriptions and one based on MAStringDescription for manage the e-mail reference. Now i'm interested to create a MAReport with fields for management email. Where for management i think a link to open new email directly from report : html anchor attributeAt: 'href' put: 'mailto:', anObject emailBase. How i can do it ? Anyone create a specific MADescription for define e management email reference ? Thank, Dario

13 years, 9 months

XML: Magritte <-> SOAP/webservice

by Damien Cassou

Hi, does any of you know about Philippe's work to map SOAP to described objects and vice versa? I would like to have a look at it. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

14 years, 2 months

how to create new PRValueLink

by Lawson English

I'm subclassing PRValueLink in order to add new +value:xxx+ markup capabilities. However, when I subclass it, it seems to disable all +value:xxx+ markups period. All I did was create a new MyValueLink>>awgValuesIn: aContext " example " | | <value: 'awgValues' comment: 'Sample Markup valueLInk for AWG.'> ^'oops' "oops" never shows and all the existing +value:xxx+ now show "xxx" What am I doing wrong? Lawson

14 years, 2 months

adding gadgets to pier not working?

by Lawson English

I allow users to add gadgets but nothing shows up http://www.gmodules.com/ig/ifr?url=http://bejeweledg.googlecode.com/svn/tru… pasted into the URL box for the gadget doesn't work. However, {{{<script src="http://www.gmodules.com/ig/ifr?url=http://bejeweledg.googlecode.com/svn/tru…"></script>}}} added to the edit box of the page, does. Suggestions? Thanks. Lawson

14 years, 2 months

Re: [GS/SS Beta] Gemstone and Magritte caching and classHistory

by Dale Henrichs

Otto Behrens wrote: > Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH I have been thinking about making these caches into session-based caches rather persistent caches ... weak collections are used in Pharo (which we don't have in GemStone) so persistent caches _are_ overkill.. Dale > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >>

14 years, 2 months

Re: [GS/SS Beta] Gemstone and Magritte caching and classHistory

by Norbert Hartl

Hi Otto, can you explain what particular problem you are solving with this? Norbert On 29.09.2010, at 10:54, Otto Behrens wrote: > Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >>

14 years, 2 months

Gemstone and Magritte caching and classHistory

by Nick Ager

Hi, I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. I've a model component which define's it's own class side descriptionContainer: MyModel class descriptionContainer ^ super descriptionContainer componentClass: IZUIProjectEditor; yourself. However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" The solution I found was to flush the Magritte description cache: MADescriptionBuilder default flush Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >From the Gemstone side should I worry that: IZUIProjectEditor classHistory size = 6 How do I go about chasing down other references to old classes within Gemstone? Nick

14 years, 2 months

Re: PUUser class>>descriptionFullName

by Lukas Renggli

Hi Damien, > here is a description that can be found in Pier: > > PUUser class>>descriptionFullName > ^ MAStringDescription new > parameterName: 'full-name'; > accessor: #fullName; > beReadonly; > beHidden; > yourself > > > The write selector #fullName: (with the $:) is not defined in PUUser. > It is probably not a problem, but I wanted to know if it would not be > safer to write the following instead: The description is read-only, so the write accessor is never used anyway. > PUUser class>>descriptionFullName > ... > accessor: (MAAccessor read: #fullName); > ... > > what do you think?' The #read: and #write constructor methods are leftovers from very old Magritte versions. They should not be used any longer (and I removed them just now). The accessors shouldn't know about readonly or not, only if the object can be read and can be written (physically). Thanks for pointing out. Lukas -- Lukas Renggli www.lukas-renggli.ch

14 years, 2 months

permissions system use-cases

by Lawson English

I guess a better way to ask my questions is to give a series of use cases. I've tried this with the one-click Seaside 3.0 final with Pier2 installed and with Squeak 4.1 with Seaside 3.0 and Pier2 installed. I installed pier on both via ConfigurationOfPier2 and ConfigurationofPierAddOns2 and still can't figure it out... Most important use case right now: have a group that is allowed to add new blog posts, as well as comment on existing blog posts, but can't otherwise affect the Pier installation. I honestly can't figure out how to do this. Thanks. Lawson

14 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki September 2010