Photo gallery?
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
5 years, 4 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
12 years, 3 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
12 years, 8 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
12 years, 8 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
>>
>>
>>
12 years, 8 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
>>
>>
>>
12 years, 8 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
12 years, 8 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
12 years, 8 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
12 years, 8 months
