I've been struggling with a Magritte validation problem. I find that a
condition I add (using #addCondition:labelled:) to a MABooleanDescription is
only intermittently called.
I've simplified the conditions to reproduce the problem to a component
description comprising of two MABooleanDescription descriptions. The second
description includes the condition which is intermittently called.
If the value of the first description is true (ie the checkbox is checked)
the second description's condition will be executed, however if it is false
it will never be executed.
I suspect the problems lies in the code in
MAValidatorVisitor>>#visitContainer: which calls
MAGraphVisitor>>#use:during: which is as follows:
MAGraphVisitor >>use: anObject during: aBlock
| previous |
(seen includes: anObject)
ifTrue: [ ^ self ].
ifFalse: [ seen add: anObject ].
previous := object. object := anObject.
aBlock ensure: [ object := previous ]
If the first check box is false, and the second is also false then (seen
includes: anObject) will return true and method returns early resulting in
block associated with second description (self visit: description) never
I've attached a file out of a simple
component TestMagritteValidation illustrating the problem that I tested in
the latest build from Hudson.
If you take Pier 2 build #278 from http://hudson.lukas-renggli.ch, and
look at the PRDistribution example, you'll see the text on the home page
rendered twice - once big, then again in a smaller font. It looks to be
a recent problem. A screenshot is included.
I like to use unicode characters in pier url paths. Nowadays encodeForHTTP changed in pharo and squeak to do utf-8 url-safe-encoding by default. I updated the implementation in the gemstone squeak package to do the same. So principal there is no need to be very restrictive in pier names.
I did some tests with changing the implementation to
^ aString isNil not
and: [ aString isEmpty not
and: [ aString ~= self parentStructure
and: [ aString ~= self currentStructure
and: [ aString allSatisfy: [ :char | char isAlphaNumeric or: [self validCharacters includes: char] ] ] ] ] ]
and it works well. PRPath>>validCharacters: could be reduced to just contain '-._'. Ok, the naming needs probably to be adjusted. But I think it is worth the change.
What do you think?
I'm trying to create a value link that can display a single command inside a document. But I struggled to create a proper link for the command. This seems only possible if you have a pier context and renderer at the same time which is not really the case as long as you are staying inside PRValueLink.
The only solution I could come up with is the following:
<value: 'command' comment: 'Display command as link'>
detect: [ :each | each label = (self parameterAt: 'label' ) ]
ifNone: [ ^ nil ])
ifNotNilDo: [ :commandClass |
^ [ :html |
goto: (aContext command: commandClass new);
with: commandClass label]].
I have the impression there might be a solution without using a block. Any ideas? Or is it ok the way it is?
I’m working on the Magritte-XMLBinding package. With this package you can
export Magritte objects as XML and read Magritte described objects from XML.
I would like to have a nice simple API that is easy to understand. I’m
looking for some feedback.
Assume we have the following description:
If we want to export the name property as a xml element we add the
beXmlElement message. By default it will add an extra element with the
accessor name as the element name and the value as the element contents:
Optionally we can specify an alternative xml element name:
Or do you like this API better?
It is also possible to store a property as an xml attribute of the parent
Or in a property of a separate element:
<name value='Pete' />
The element and attribute names can be customized:
beXmlElement: 'xname' withAttribute: 'yvalue'.
Is the "be" message with arguments better or should a "be" message always
have zero arguments?
@Nick: I committed Pier-JQuery-lr.1.mcz to pier2addons, but I didn't
notice until after the commit that you essentially did the same
already a long time ago. The widget in the package essentially removes
the AJAX search widget from Pier-Seaside, ports it is JQueryUI and
moves it into the new package. Now the question is what implementation
to keep? The code in Pier-JQuery-lr.1.mcz only depends on JQueryUI,
while your changes seem to require more. Also Pier-JQuery-lr.1.mcz
uses some simpler mechanism I introduced into JQueryUI just now.
@Damien: The same package also contains two value links we talked
about yesterday. With the following links it is possible to present
the children (or any other set of structures) within a tab-panel or
within an accordion.
Of course both require the JQuery library, the JQueryUI library and a
Has anyone ever used Pier for collaborative documentation?
I realize a wiki is sorta that already, but I'm part of an IETF group
that is exploring options at the moment and I wonder if there were any
existing examples of Pier being used that way?
Yeah, presumably this should go into the Squeak specific packages of Grease.
On Oct 3, 2010, at 20:12 , John McKeon wrote:
> I see.
> I have been using Squeak 4.1 =)
> What are my options in that case? A squeak compatibility layer?
> On Sun, Oct 3, 2010 at 1:48 PM, Lukas Renggli <renggli(a)me.com> wrote:
> Hi John,
> You need to revert the Pharo 1.1 collection packages, because Magritte accidentally overrode the implementation in Pharo.
> On Oct 3, 2010, at 18:26 , John McKeon wrote:
> > Hello Lukas,
> > I updated to the latest Magritte-Model last night and found things fairly broken with the removal of these extension methods. Pier still uses reduce: in several places and MAOptionDescription uses lines in MAOptionDescription >>optionsTextual:
> > Regards
> > John
> > --
> > http://john-mckeon.us
> Lukas Renggli, Software Composition Group (SCG)
> Schützenmattstrasse 14, 3012 Bern, Switzerland
> Room: 203, Phone: +41 31 631 8643
You need to revert the Pharo 1.1 collection packages, because Magritte accidentally overrode the implementation in Pharo.
On Oct 3, 2010, at 18:26 , John McKeon wrote:
> Hello Lukas,
> I updated to the latest Magritte-Model last night and found things fairly broken with the removal of these extension methods. Pier still uses reduce: in several places and MAOptionDescription uses lines in MAOptionDescription >>optionsTextual:
Lukas Renggli, Software Composition Group (SCG)
Schützenmattstrasse 14, 3012 Bern, Switzerland
Room: 203, Phone: +41 31 631 8643
How do I format text output from my custom link?
I can embed raw HTML by doing:
^PRVerbatim content: '<p>',myString1,'</p>', '<p>',myString2,'</p>'.
and so on. How can I use the renderContentOn: syntax so I can take
advantage of seaside's internal formatting methods... Or can I, or is
there something more pier-oriented I should do instead?
e.g. +values:awgvalues|factorialval=300+ goes right of the edge of the