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, 7 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, 6 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

13 years, 11 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

13 years, 11 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

13 years, 11 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 >> >> >>

13 years, 11 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 >> >> >>

13 years, 11 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

13 years, 11 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

13 years, 11 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

13 years, 11 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