Hi
Is it possible to use existing descriptions to express a relation with
object existing or not ?
We could imagine choosing a responsible from an existing list of person
defined by a class Person. If the person doens't exist, we can
instanciate a new one.
I will try to create an appropriate description but I don't really know
where to subclass as it is a bit of a mix between a
SingleOptionDescription with instances of a class as option and a
ToOneRelation description with class Person. What do you think ?
I ve tried with a MASingleOption description defining the reference as
Person description and options as my repository of users but that hangs
(due to the reference wich is a Caontainer Description I guess)... I
also tried with MADynamicDescription without result...
that makes me ask another question... Are all MADynamicObject used with
classes or subclasses as it is in my image ?
thanks
Cédrick
>
> I tried to change as a first step the environment (adding my
> own layers and removing the ugly tables) using the following
> statement:
> <div id="divHeader"><div id="divCommands">+commands+</div></div><div
> id="divLeft"><div class="boxes">+tree+</div></div><div
> id="divContents">+contents+</div>
>
> But it seems, that this code gets escaped. Inspecting the
> kernel and its root structure I see my HTML code as part of a
> paragraph which seems to escape all the HTML characters...
>
> Help is welcome! ;-)
>
> Cheers, Chris
Are you sure that is one single string with no carrige returns anywhere?
Hi Lukas
I tried to change as a first step the environment (adding my own layers
and removing the ugly tables) using the following statement:
<div id="divHeader"><div id="divCommands">+commands+</div></div><div
id="divLeft"><div class="boxes">+tree+</div></div><div
id="divContents">+contents+</div>
But it seems, that this code gets escaped. Inspecting the kernel and its
root structure I see my HTML code as part of a paragraph which seems to
escape all the HTML characters...
Help is welcome! ;-)
Cheers, Chris
--
--------------------------------
Christoph Wysseier
Länggassstr. 74
3012 Bern
T +41 31 972 92 08
M +41 78 616 35 35
chris(a)wysseier.net
--------------------------------
> Actually subclasses of WATask should work. In some older
> versions of Pier there was a bug that a WATask rendered empty
> on the first request, however I think this problem is solved
> in current versions of Pier.
>
> Can you give some more details about your task?
>
> Cheers,
> Lukas
My bad, I'd forgotten to add canBeRoot on the class side, wasn't showing
up in the component list. Works fine.
> For security and web, I'm a little bit paranoid, especially at
> such powerful systems like Pier ;-) I've discussed security in
> Seaside/Pier with a friend, and from this I'm not sure today what I
> expect from such systems like seaside/pier. He says, security
> belongs only to buisness logic. I'm not so shure, also what to call
> buisness logic in Pier...... I will post a related question to the
> list later.
If your friend means "model" when talking about "business logic", he
is right: the security decoration is a pure model object, that works
exactly the same for all views, not just seaside one. Thanks to the
nature of visitors one can easily control how security concerns are
handled when performing operations.
> You could help me understand the code answering the following
> question: in your security package, every structure element
> (decorator or the decorated element) has an owner, and the the
> rights of that owner decide what is possible (that the UNIX way, I
> think). Is that right ?
Yes, the code modeling the unix permissions is quite simple to read,
of course you can tweak that behavior if you need to. I think it
comes quite close what unix does, but I no unix expert.
SUSecurity>>isAllowedCommand: aCommandClass in: aContext
(aContext user notNil and: [ aContext user isSuperuser ])
ifTrue: [ ^ true ].
(self owner = aContext user)
ifTrue: [ ^ self ownerCommands includes: aCommandClass ].
(self group notNil and: [ self group includes: aContext user ])
ifTrue: [ ^ self groupCommands includes: aCommandClass ].
^ self otherCommands includes: aCommandClass
> But what about the commandos: is the security given by existence
> (only the commandos in structure exist, which are executable) or by
> right for execution for every commando (as in UNIX file system) ?
> That I have not understand until now.
I am not quite sure if I understand your question, maybe you can
deduce the answer from the above code yourself?
Basically every security decoration knows a list of all allowed
commands for the owner, the group and all the others, like the unix
"rwx", but for all available commands in the system. The security
decoration does not care what it decorates, e.g, when giving the
permission to admin to remove the root page, he still won't be able
to do that simply because the remove-command does not work on the
root, something that is enforced by the command itself.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
