I'm using some option descriptions. For resolving possible options of to be referenced objects I use something like
options: [ HRExampleObject instances ] magritteDynamicObject;
Now I'm trying to avoid using globals. Especially when dealing with gemstone it is not advizable to have class side instances management. Is there a way to specify some lookup environment to lookup something like the above?
Norbert
I have a problem understanding the scope of using MADescription>>kind. It does not work when being used on a priority container.
If used on a MAContainer the validation fails because in
MADescription>>validateKind: anObject
"Validate ==anObject== to be of the right kind."
(anObject isKindOf: self kind)
ifFalse: [ MAKindError description: self signal: self kindErrorMessage ]
anObject will be the memento and therefor it can not work unless self kind is Object. Is the scope of kind not meant to be used that way or is this a problem within magritte?
thanks,
Norbert
ConfigurationOfPierAddOns2 version '2.0.7' released.
ConfigurationOfPier2 version '2.0.7' released.
ConfigurationOfMagritte2 version '2.0.6' released.
ConfigurationOfGrease version '1.0.1' released.
ConfigurationOfSeaside30 version '3.0.1' released.
ConfigurationOfKomHttpServer version '1.0.6' released.
Tested against:
- GLASS 1.0-beta8.4
- Squeak4.1
- Pharo1.0
- Pharo1.1.1-11414
All tests are green except on Squeak4.1 where
MAExtensionsTest>>testTimePrintOn: is failing ... the
Time>>print24:showSeconds:on: prints milliseconds in addition to
seconds, so presumably this is a minor error.
Dale
I've been looking at Pier-FilesystemPersistence, and have a few questions.
The version comments seem to indicate it is still a work in progress.
What work remains to be done?
It looks like the change history is not persisted. What's a good way to
do that - individual xml files, or a change log?
The usage scenario seems to be: start image, import kernel, save pages.
Would it be possible to do a lazy read of the kernel, instead of reading
it in entirely, at image start up?
How does it compare with SIXX persistence done for VA Smalltalk?
--
Yanni Chiu
> Just a short extension to Lawsons mail. It depends what you need to do.
> Pier is a system based on Magritte and Seaside. And that is reflected in the
> object hierarchie. To be able to do just a web component you need to
> subclass WAComponent. This component has just a dependency on seaside and
> can be run without pier. If you subclass MAComponent you can make use of
> Magritte related stuff. But then you also need Magritte to able to run your
> component. And finally PRWidget eases your use in a pier environment. And
> again pier is your dependency then.
>
> So if you only want to display a text box and a list that you define
> yourself than you should subclass WAComponent.
>
> hope this helps,
>
Thanks guys, that's very helpful.
I am hoping to build a component that can access various attributes in the
pier, logged in username - just for example. Would I be right in assuming
that subclassing PRWidget is therefore my safest bet? I realise that this
means I have more to learn, but it seems like a worthwhile investment.
Cheers
Andy
I suspect this is a very basic question.
I would like to use Pier as the basis of a group brainstorming system. In
order to do this, I need to build a new component that would have a small
text entry box, and a list display holding all the entries.
It seems as though some other components have subclassed PRWidget, but not
all of them. So, before I go shooting off down the wrong path, could someone
explain if there is a best starting point?
Cheers
Andy
Hi all,
I just implemented a proof-of-concept extension for Pier: PRMath.
It uses MathJax, http://http://www.mathjax.org/, to display math formulae
with style: you can use [La]TeX syntax!
I created a squeak source project open to all to contribute at
http://www.squeaksource.com/PRMath
and there are ToDo's for anybody (more knowledgeable than me) to contribute.
Just to give you an idea of what it is, I attach a snapshot of it in action.
Hope you like it and contribute (or even copy/enhance/fork/use/misuse...)
Bye
Enrico
PS: note that current PRMath implementation refers to MathJax
deployment, which is
_NOT_ polite, as explicitly written in MathJax site:
Please do not link to the copy of MathJax at www.mathjax.org, as we do not have
the resources to act as a web service for all the sites on the web
that would like to
display mathematics.
--
Enrico Spinielli
"Do Androids dream of electric sheep?"— Philip K. Dick
"Hear and forget; see and remember;do and understand."—Mitchel Resnick
I like to execute a command in a way that the structure is changed while the command is being executed. If the command is commited I like to advance the structure to another structure. If the command is aborted than I like to return to the structure from where the command has been invoked.
Basically I do something like this
html anchor
goto: (self context
structure: self structureWhileCommandIsExecuting
command: MyPierCommand new);
with: 'do it' ]
In MyPierCommand>>doExecute I do at the end
self answer: (self context structure: self structureAfterCommandHasBeingCommited )
This way I have chose a structure for command execution and the structure if the command is commited. But on abort it stays where it has been executed (structureWhileCommandIsExecuting). Looking at
PRContentsWidget>>onAnswerCommand: aCommand
aCommand isNil
ifTrue: [ ^ self context: (self context structure: self context structure) ].
[ aCommand execute ]
on: MAError
do: [ :err | ^ self component errors add: err ].
self context: aCommand answer
we see that if aCommand isNil (abort) the structure is nailed to the current one (while executing). Would it be ok to change that so it is answering every time? I simple change would be to change
buildComponent: aContext
^ aContext command asComponent
onAnswer: [ :value | self onAnswerCommand: value ];
yourself
to
buildComponent: aContext
^ aContext command asComponent
onAnswer: [ :value | value ifNotNil: [ self onAnswerCommand: value ] ifNil: [ aContext command doAnswer ] ];
yourself
this way
PRCommand>>doAnswer
self answer ifNil: [ self answer: (self context structure: self structure) ]
would the same but some could overwrite the answer when creating the link
what do you think?
Norbert
