> 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
Hi Hans,
> hope you have has a nice trip to Toronto :-)
yep, Canada is great! The Pier & Magritte presentation was a success.
> One Question: in the PRContext>>user, there will be set property
> user to nil if this property does not exist. Could that be
> dangorous ? Should there be set some default user with smallest
> rights ? (And should this user come from PRKernel as the smallest
> user in current kernel or come from PRUser class as the smallest
> thinkable user ?)
Yeah, this is not a nice design. Similar as the 'admin' user and
'admin' role, there should be an 'anonymous' user and an 'anonymous'
role. There are several checks for nil now, what makes it quite ugly
in the oo-world, however I don't think this imposes any security
risk ;-)
I will have a look at this as soon as possible.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi, where is the code that pier uses to deep link into a site? I have a
few installations that seem to have lost the ability to deep link,
despite being the latest code, yet deep link just fine if I create a new
site. Thought I could save a little time if someone already had the
issue, or knows that bit of code.
> > Hi, where is the code that pier uses to deep link into a
> site? I have
> > a few installations that seem to have lost the ability to
> deep link,
> > despite being the latest code, yet deep link just fine if I
> create a
> > new site. Thought I could save a little time if someone
> already had
> > the issue, or knows that bit of code.
>
> Mhh, not much changed in this area for the past few months.
> The last big change was to make a difference between the
> title and the name of a page, but the lookup should work for
> name and title, check-out the mailing-list archive.
>
> Can you give some more hints what is not properly working?
> There are also tests that check all kinds of deep- and
> relative linking.
>
> Cheers,
> Lukas
I'll see if I can take a look at it tonight, at the moment, I only know
it's not working, but haven't fired up the debugger yet.
Hi :)
I try to use a MARelationDescription with an object that fetch its
description automatically from instances... and I have a problem...
To illustrate, let's take the Magritte tutorial example with 2 model
classes MAPersonModel and MAAdressModel.
In MAPersonModel we have an inst var homeAdress with the corresponding
description on the class side:
MAPersonModel class>>descriptionHomeAddress
^ (MAToOneRelationDescription auto: 'homeAddress' label: 'Home
Address' priority: 40)
componentClass: MAInternalEditorComponent;
classes: (Array with: MAAddressModel);
yourself.
and that is enough because MAAdressModel has its descriptions defined
(class side). But if descriptions were accessed from instance of
MAAdressModel like:
MAAdressModel>>descriptionGenerated
^MAPriorityDescription new add: (MAStringDescription auto:
'street' label: 'Street' priority: 10);
add:
(MAStringDescription auto: 'place' label: 'Place' priority: 30);
...
yourself.
Then I was thinking it was possible to create the previous description
in the following way (say there are no more desciption in the class side
of MAAdressModel):
MAPersonModel class>>descriptionHomeAddress
^ (MAToOneRelationDescription auto: 'homeAddress' label: 'Home
Address' priority: 40)
***reference: MAAdessModel new descriptionGenerated;***
componentClass: MAInternalEditorComponent;
classes: (Array with: MAAddressModel); *no more description in
the class side of MAAddressModel*
yourself.
I know in this exemple, the interest of doing that is not obvious but
this is because in my case, I have specific description for instances
(one part is general whereas the other is created with values affected
to the object).
Is it possible to do that way ?
what is the correct use of #reference: for a MARelationDescription ?
choosing a kind of container ?
Is there a built-in way to use different descriptions (filtered for
instance) than the one accessed from the classe that are in ToOne or
ToMany relation ?
Thank you
Cédrick
Hi Sebastian,
I'm in the process of putting together a tutorial that covers this
information, along with some other aspects of customizing the appearance
of Pier using css. I hope to have it completed soon. Until it's
finished, here is some info that should help you:
* Configure Comanche to serve files
Rather than starting Comanche like this:
WAEncodedKom startOn: 8080.
Go to
http://www.shaffer-consulting.com/david/Seaside/GettingSoftware/index.html
and use David Shaffer's scripts to kill all existing server instances and
start a new instance that serves file from the 'FileRoot' folder. You can
rename 'FileRoot' to whatever you want. Just make sure that the directory
you choose is in the same directory as your image file.
* Get default stylesheets
Download the default stylesheets from here:
http://impara.de/pipermail/smallwiki/attachments/20060219/5e4f4ed8/css-0001…
Create a 'styles' dir under 'FileRoot', and expand the zip file in the
styles dir.
* Use the new stylesheets
Change the style accessor method in PRStyleLibrary to return the path to
your main style sheet
style
^ '@import "/styles/style.css";'
Brian
> Dear Frank,
>
> thanks for your answer. As a http server is not available for me at
> this time, I wonder if I can setup it to get the style from local .css
> files. Do you know if this is feasible?
>
> thanks again,
>
> Sebastian
>
>> -----Mensaje original-----
>> De: smallwiki-bounces(a)iam.unibe.ch
>> [mailto:smallwiki-bounces@iam.unibe.ch] En nombre de Frank Urbach
>> Enviado el: Miércoles, 12 de Abril de 2006 17:03
>> Para: SmallwikiList
>> Asunto: AW: Pier customized look
>>
>> Hi, Sebastián!
>>
>> Try to get the original css-files. Move these files into a
>> structure of an webserver where you can access over.
>> http-protocoll. Alter in class PRPierLibary the accessor
>> style to the location of yor css-files.Then you can edit the
>> file style-contents at point .header .title. Now you can. use
>> fonts you like.
>>
>> Hope this helps.
>>
>> Cheers,
>> Frank,
>>
>> -----Original Message-----
>> From: ssastre(a)seaswork.com.ar
>> Date: Wed, 12 Apr 2006 14:39:55
>> To:smallwiki@iam.unibe.ch
>> Subject: Pier customized look
>>
>> HI All,
>>
>> how do I (in a *polite* fashion) customize the fonts and
>> header of pier to install a wiki?
>>
>> thanks,
>>
>> Sebastián
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> SmallWiki, Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
>
> _______________________________________________
> SmallWiki, Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
Hi, Sebastián!
Try to get the original css-files. Move these files into a structure of an webserver where you can access over. http-protocoll. Alter in class PRPierLibary the accessor style to the location of yor css-files.Then you can edit the file style-contents at point .header .title. Now you can. use fonts you like.
Hope this helps.
Cheers,
Frank,
-----Original Message-----
From: ssastre(a)seaswork.com.ar
Date: Wed, 12 Apr 2006 14:39:55
To:smallwiki@iam.unibe.ch
Subject: Pier customized look
HI All,
how do I (in a *polite* fashion) customize the fonts and header of pier
to install a wiki?
thanks,
Sebastián
Hi
I was having a look at the last exercices of the tutorial and I'm having
a problem with the last exercice with custom descriptions.
the custom description are doubled each time I access to them in the
container...
decription is overriden in MAPersonModel
MAPersonModel>>description
^super description copy;
addAll: self class customDescription;
yourself.
copy sould prevent to change the description stored in the cache. Is it
correct ?
This makes me ask you another question. When a description (class side)
is changed, how the cache of the builder is refreshed ? I have no idea
Thank you
Cédrick
