> I looked at your code and you placed self error: there too (basically
> in
> #validateChild:titled:in:). But if I do this, I break my kernel. So how
> should I do this?
Strang, I've never seen this and I'm unable to reproduce.
The error and validation handling in Magritte is certainly a dark part
of the framework, it is trying to collect all errors by resuming
certain exceptions and therefor jumps around in the code. However this
doesn't work quite well as I expect, it definitely needs a different
concept and some more work.
Try to load the latest packages, I added an exception hander around the
command validation so that any error is transformed into a Magritte
error. Does this help?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
> The way I broke the kernel I think is in a #doValidate I did a self
> error:
> 'foo'. I thought this was a the correct way to signal that there's
> something
> wrong with the user input. It obviously wasn't because I didn't get a
> SW2 or
> MA error but a Seaside error. So what is the correct way?
Today I am in a paper writing mode, so let me try to explain this a
little bit more than usual:
The lock in the SmallWiki kernel makes sure that only one command is
executed at once. It makes sure that the model doesn't get into an
invalid state due to concurrent write accesses. However, having locks
especially during the development phase, can be pretty boring: say if
you are using the debugger to step through a critical section, restart,
jump out of it, ... you might run into troubles because its semaphores
are not properly reset.
This is neither an implementation error of SmallWiki nor one of the the
lock-implementation in Smalltalk, but a common and well known issue in
powerful languages such as Smalltalk or Scheme, where the exception
handling is done at the language and not at the VM level. Java, C#,
C++, PHP, ... don't show this issue since their execution stack is not
a first class object and the exception handling is out of the scope of
the programmer, after an unhanded exception your application needs to
be restarted anyway.
A greatly simplified implementation of a lock might look the following
piece of code. The critical piece is the ensure block, that ensures
that the lock is opened after doing the critical thing in aBlock. So
whatever happens inside aBlock (finishing the evaluation of the block,
doing a non-local return from within the block, raising an exception,
etc.) first the ensure-block is evaluated before continuing with the
default executing. So if you have a self halt in there the ensure-block
will be evaluated because the debugger is opened in a exception handler
at the very top of the stack. However with the debugger we are able to
jump back into aBlock and continue the execution, but now within the
unlocked context. Of course when exiting again from aBlock the
ensure-block will be evaluated again and the lock might get into a bad
state.
lock: aBlock
self waitUntilUnlocked; lock.
aBlock ensure: [ self unlock ].
Especially when using Seaside you have to be aware and take care about
the use of ensure-blocks: say if you are using continuations to jump
into aBlock or out of aBlock the semantics of the #ensure: are
basically undefined! Should it be evaluated multiple times? Only the
first time? Only the last time? How do we know when we leave aBlock for
the last time? Actually I suggest, not to mix continuations and
ensure-blocks.
> Are there better/saver ways to fix such isses?
No, it is a known problem, without good solutions. Search Google for
"continuation unwind" and you will find a lot of material about this.
> Is there some way of resting the kernel lock if a a command goes wild?
SW2Kernel kernels do: [ :each |
each instVarAt: 'lock' put: each defaultLock ].
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
>> Why didn't you put the images in the style library? It seems
>> strange to me to have them at a different location.
>
> Yes, I felt the same, but I didn't know what's the correct way of
> putting
> images into the library and I couldn't find any example for that, so I
> was a
> bit lost.
> I have found a way to store images in the Squeak image, but is it
> really
> possible to link to these images from within a CSS definition?
Yeah, of course in Smalltalk everything is possible ;-) Have a look at
the smilies, however I doubt that this code works, it has been written
back in the VisualWorks days. And for the style-sheets the tricky part
is somewhere else, maybe ask that to the Seaside list ...
Thanks for your submissions, I merged them in and published the new
code in the repository. Some comments:
- I kept the old style-include in SW2MainFrame till we get the thing
with the images ironed out. There was something wrong with the
line-feeds (as usual), so I pasted in the original files, I hope this
is fine for everyone now?
- I enhanced your enhancement to reject possible commands slightly, so
that the structure instance is asked with the command-class and the
context if this command is valid. I need this, in some of my newly
created classes. I hope this suits your needs as well?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi,
I think I have followed both the archives and the FAQ in order to prevent
access to part of my (Squeak) SmallWiki by the anonymous user:
server root roles: (OrderedCollection with: server defaultRoleAnonymous).
(server root at: 'Secret') roles:
(OrderedCollection with: (SWBasicRole name: 'anonymous'))
However this doesn't work for me and I don't understand why. I would really
appreciate some pointers to diagnose this.
I have stepped through the code but I can't see what is responsible for
preventing the permissions being added from the root role when the role is
specified on the child with an empty set of permissions. I can see the
barrier logic, but this isn't a barrier role, and all the rest of the
behaviour seems to add the permissions from the root back. Hence I can see
the page as the anonymous user?
Thanks
Mike
Hi David,
thanks a lot for your patches, I really appreciate submissions like
this!
However, could you please resubmit them as Monticello files (just add a
directory repository or even simple a SMTP repository and send the
changed packages to me)? Since I continued working on SmallWiki and
Magritte it isn't possible to load your change-sets without creating a
huge mess. Having a proper tree-way merge would avoid that I have to
look out for the changes and copy them manually into my code.
Why didn't you put the images in the style library? It seems strange to
me to have them at a different location.
Thanks,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hello,
I have appended three patches, one for Magritte and two for SW2.
The one for Magritte adds #renderButtonOn: to MATextInputComponent, so the
several subclasses have to override just this method to provide a button
after the text input field.
Then the first patch for SW2 adds SW2Styles, a style library that includes
all the CSS styles that were stored in an external CSS file so far.
The second patch gives some more possibilites for adding/rejecting commands
for a given structure. Any structure class can specify a collection of
commands that shall be rejected, whereas a command can specify now a
collection of structure classes where this command should be available. A
command will only appear in the widget for a structure that has not rejected
this command and only if the command should be displayed in this structure
(specified with MyCommand class >> defaultStructureClasses).
This solution may not be the best one to solve the problem, but at least I
can now do what I need. ;)
For instance, it's now possible to determine that a command should not
appear in the command widget for any structure by providing an empty
collection in MyCommand class >> defaultStructureClasses. Or a structure
class can determine that some commands should never appear in the widget
when a instance of this structure class is active.
I hope that these patches are useful for others too.
Kind regards,
David
Hi,
> I read through your excellent presentation via Ian Prince's proaises
> on his blog and I was intrigued by the Magriette framework that was
> mentioned. I tried looking for the SmallWiki2 code in the VW code
> repository and SqueakMap but came up empty. I did find SmallWiki2 on
> the VW repository, but it seemed old. SmallWiki2 looks very cool and I
> would love to play with it. I'm especially interested in the magriette
> framework. Is there any chance that I could try out the code?
> Everything in the presentation sounded very exciting!
thanks a lot for your compliments!
some time ago, I decided to change the primary development environment
to Squeak. See the mailing-list archive for a discussion about this.
Since I started out in VisualWorks there are still some very old
packages in the public repository.
There are no packages of SmallWiki2 and Magritte on SqueakSource yet,
basically because both frameworks are still in a pre-alpha phase and
the interface is still changing slightly. However you can always get
the latest source code from http://mc.lukas-renggli.ch/smallwiki2 and
http://mc.lukas-renggli.ch/magritte. Ready made preview-images can be
downloaded from
http://www.iam.unibe.ch/~scg/Teaching/AdvancedLabs/swimages.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hello,
check out: http://decomp.ulb.ac.be:8082/ : it works with Safari (under
Mac) or Firefox (under Windows), but *not* with Internet Explorer. Any
ideas on what the problem is and how I can fix this ?
--
Roel Wuyts
DeComp
roel.wuyts(a)ulb.ac.be Université Libre de
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/
Belgique
Vice-President of the European Smalltalk Users Group: www.esug.org
> would it be a great effort to create a new type of link, that points
> to a page in a different branche of the tree? I would like to do
> something like this:
>
> SmallWiki 2
> |-Page 1
> |-Page 2
> |- Page 3 (This page has a Link to the page "SmallWiki 2")
>
> Perhaps a *singelton:SmallWiki 2* tag? :-)
No, but you have full support of absolute and relative links simulating
the unix file-system. In your case you could chose from any of the
following:
absolute: */* or nicer */>Back 2 Root*
relative: *../..* or nicer *../..>2 Levels Up*
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
>> In my opinion the properties of the Seaside component should be stored
>> in the structure. The description for this could be built from the
>> command object (SW2EditComponentCommand) that is dynamically enhanced
>> with the description of the currently selected component class.
Okay, this is now in the latest code, load Magritte-All-lr.11 and
SmallWiki2-All-lr.66. Just to be sure, reinitialize the environment and
try out the new settings command on the Counter and the Tree-Widget.
However there are not that many possible settings yet, but now it is
just a matter of writing some descriptions and we will soon have more
flexibility as we had in SmallWiki 1 with the templates. I also fixed
some other bugs all over SmallWiki.
> Right now I'm trying to edit the count of a WACounter (added a
> descritption). I know Seaside2 components just live for the session but
> that's not a problem for now.
>
> We can store arbitary objects in dictionary in the user. So we can
> write a
> structure that has a string and uses this as a key to fetch an object
> from
> the current user. I want do display and edit them. So we can pretend
> we edit persistent objects instead of seaside components.
>
> Fine with me. Just how do I do that? I tried something like
>
> MyComponent class>>descriptionModel
> ^ MADynamicObject on: [
> SW2CurrentContextHolder value contents in: [ :context |
> (context componentFor: context structure) in: [ :component |
> component description ] ] ].
>
> but that didn't work.
Okay, I see, you are probably not interested too much into the stuff I
wrote above :-)
Even-tough I again tried hard to understand what you want to do with
the above code, I could not get it. Mhh, so I guess that you want to
know how to use a description on a different model than it has been
defined on?
Answer: Suppose you have aDescription and aModel from anywhere in your
image, you can plug them together and get a Seaside component by
sending:
aDescription asComponentOn: aModel
>> Another thing I don't like in your code is that you don't store the
>> modifications in the command object. This means that the changes won't
>> be logged.
>
> Yes, right. This was thought to be a proof of concept prototype, not
> the
> final version. But how should I do that? Add a Dictionary and override
> #doesNotUnderstand?
Magritte is always doing a dispatch over the model using #readUsing:
and #write:using:, so you should override those. See their implementors
for some more documentation.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
