Hi, works :-) And how to prevent that everyone can call the ../seaside/config page ? ;-) I think the removing the config is not the best :-) (Ok, this are now very basic seaside questions....) Regards Hans Am 14.04.2006 um 17:24 schrieb Lukas Renggli:

Hi Am 14.04.2006 um 17:46 schrieb Cédrick Béler: don't worry, I've got the idea :-) hmm, I have loaded the Pier in a clean 3.8 image (and the Pier unix security package), and there was no password needed to get the config site...... is there any default login ? Regards Hans

Hi, So now I've looked a little bit in the mailing archive, and I'm a little bit confused: It seems, - that Seaside and Pier (or any other application in Seaside) can have different security models. Both can handle its own user lists and capabilities - that there are 2 different security packages (unix inspired / ACL based) - both Seaside and Pier can add users (or user management in general) only by typing something (what ?) in workspace So if this is all true - what are the plans to make this all more integrated, so that there is only one user management, and an application may only extend the basic mechanism from seaside ? Or I'm completly wrong here ? Regards Hans Am 14.04.2006 um 18:37 schrieb Cédrick Béler:

Yes, however you need to specify the second description on the instance-side to be able to define it according to the state of your model. There are some examples on how to change descriptions on an instance-bases in the slides of my Magritte Tutorial (Dynamic Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/ magritte>. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Lukas Renggli wrote: Have you tried to remove caching from existing Magritte programs to test if it is really slower?

Well, being slower, doesn't at all imply that it's too slow, so a better question is in the overall rendering of a page, say a complex edit form, what percentage of total rendering time is taken by retrieving the description both cached and uncached. I mean, it could be dwarfed by the call to goods(or whatever db you use) to actually retrieve the objects, and if that's the case, running uncached may not even be noticeable. Caching may not be necessary at all, in the larger scheme of things, and frankly, I find myself flushing the cache constantly, especially during development.

Ah, I hadn't considered querying. Maybe just a habit I got into, looking over other code, I see use of MADynamicObject to handle binding of lists that may change and can't be cached, I think this was the original reason I started flushing the cache. Also, while in development, sometimes I feel like the cache didn't flush when I changed a description, however, there's a good chance that's just a bad perception on my part, like last night when I was trying to do an instance side description override... felt the cache wasn't flushing, turned out instead that SettingsComponent had a bug instead.

... Why it can be cached anymore? Can't just be posible to refactor the cache subsystem to work instance based intead of class based? I know that some systems allready have instance based caches. Some of them: GOODS client by Avi Bryant, rST, OmniBase support regards, Sebsatian PD: I'm not familiar with Magritte and recently interested in it because I think it make archivable that an application could have a maintainable web interface and desktop interface at a reasonably cost.

Lukas Renggli wrote: Ok, doesn't seem to work, but let me explain what I'm doing. I'm writing a component meant to be hosted in Pier, the component has several settings it needs, and I was using class side descriptions to provide the "settings" interface that Pier offers on any component. However, looking at PRSettingsComponent, I see that it's not asking the instance for it's description, it's asking the class directly, bypassing any overrides I may have attempted on the instance side. Is that the intention? Am I writing components wrong? Should I be subclassing something in Pier rather than my own WAComponent subclass? The Magritte tutorial is great btw, is there something similar for Pier? Now that Pier seems somewhat stable, I'm starting to explore it more as an application container with configurable widgets, digging it so far, just need to get a few things done so I grok the do's and dont's a little better. Great work though, keep it up!

And the documents I wrote: http://smallwiki.unibe.ch/smallwiki/pier -- Damien Cassou