gmane.comp.lang.smalltalk.smallwiki

Re: Changing edit form based on user credentials

Michael Davies — 2008-08-07T06:53:29

Exactly what I needed - it works perfectly now. If you keep answering 'em, I'll keep asking 'em! Cheers, Michael _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Re: Changing edit form based on user credentials

Lukas Renggli — 2008-08-06T22:44:04

You can always get the current context using PRCurrentContext value The expression might return nil if there is no current context, but in case of the execution of a command this should be defined. Good question. I added it to the upcoming FAQ: http://www.lukas-renggli.ch/smalltalk/pier/faq If you have more things that you would like to see, please let me know. Cheers, Lukas

Changing edit form based on user credentials

Michael Davies — 2008-08-06T20:19:54

Hi all, I've got a class inherited from PRPage with some additional properties, and I want to hide those properties from all but the page owner at edit time. The problem is that PREditCommand doesn't pass the context to the page before requesting its description, so the page instance doesn't have the necessary information to dynamically change its description. I can get the required functionality to work, by overriding PREditCommand>>description to make decisions about how to render the page, but that seems I wonder if there's a better way to approach this? In other words, is there a sensible way to make PRPage aware of the context in which its edit form is being rendered? I was contemplating adding context as an instance variable on PRPage and setting it from PREditCommand, but I suspect that if that was a sensible approach, it would have been done already! I've only just started using Pier in earnest, so if this question exposes a lack of understanding of anything fundamental, please feel free to point

Re: about the big kernel lock

Lukas Renggli — 2008-08-03T17:24:32

Yes, this is correct. True, this might happen. Since write operations are rare compared to read operations the problem is very unlikely to occur though. Moreover a single edit operation is unlikely to affect a random viewer. In the very unlikely event the viewer might get an inconsistent view. So what? In the absolutely worst case the viewer might get an exception. I have never seen such a situation though. It is certainly feasible, but is it worth the trouble to add a read- write lock to avoid this rare situation? Cheers, Lukas

about the big kernel lock

Philippe Marschall — 2008-08-03T17:04:15

Hi I recently read an article how KDevelop handles threading and that got me thinking. As far as I understand Pier currently uses a global lock for all write operations (where #isView returns false). All good an fine so far. But shouldn't this be a a read-write lock? Imagine the following scenario: - a view command is executed, is starts to read some objects, iterates over some objects - the current process is unscheduled - a new process is with a write command is scheduled, it executes to completion - the original view command is scheduled a again but it has inconsistent information, eg the parent of an already read structure has changed A read-write lock should not affect performance because it allows multiple concurrent readers. Cheers Philippe _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Thanks Lukas!

Rick Flower — 2008-07-30T16:52:19

I'm finally getting around to using Magritte and while I'm only on the edge of learning what its fully capable of doing, I'm finding that it appears to work as advertised (which is great!) and that should really help get rid of a bunch of clutter from my code where I had a bunch of rendering code + validation handlers. I was trying to do my own formatting but will back away from that now and focus on content instead (I've got a short turn-around time).. Once the content and functionality is working then I'll focus on doing the prettying-up of the forms,etc. Anyway, I just wanted to write a quick 'Thanks' note to let you know that your hard work is very appreciated!

Re: Adding conditions for more than the current description

Matthias Berth — 2008-07-29T13:18:33

Danie, try this: http://onsmalltalk.com/programming/smalltalk/multiple-field-validation-rules-in-magritte/ :-) Matthias On Tue, Jul 29, 2008 at 2:29 PM, Danie Roux danieroux.com> wrote: _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Adding conditions for more than the current description

Danie Roux — 2008-07-29T12:29:49

Dear list, This should be an easy answer, I'm just not finding it: How would I rewrite something like this into descriptions? (maxAnnualFee > 0) & (fixedAnnualFee > 0) ifTrue: [InvalidFeeSelection signal].

Re: Question regarding Magritte-Addons package..

Lukas Renggli — 2008-07-29T06:30:54

Magritte didn't change that much over the past few years. These were mostly backwardcompatible bug fixes and small enhancements. If possible, I would contact the original author and try with the latest Magritte on Squeak first. Cheers, Lukas

Question regarding Magritte-Addons package..

Richard E. Flower — 2008-07-29T05:48:18

Lukas et-al, Is it safe to assume that if I want to port parts of Magritte-Addons to the VW version of Magritte (which was taken from the LR251 version of Magritte in Oct 2007), that I should stick with a version that is dated in about the same period of time (up to perhaps December 2007?) to avoid issues with the interfaces changing? Just curious.. Thx!

Re: whats the best way to access the object data when doing customrendering..?

Lukas Renggli — 2008-07-28T07:31:51

MAContainerComponent only triggers (see renderContentOn:) the component renderer (MAComponentRenderer). The component renderer knows how to layout the components of the individual descriptions (subclasses of MAElementComponent). This is the actual place where the data is read and written, according to the displayed editor. Yes, I understand. That's what #cssClass: is used for. It is not an extra DIV that is wrapped around the description, but it is enough to do anything to the layout. Cheers, Lukas

Re: Styling Magritte

Keith Hodges — 2008-07-27T22:49:31

Basic packages which you may or may not want to use... Installer lukas project: 'magritteaddons'; install: 'Magritte-RealMemento'; install: 'Magritte-CustomBuilder'; install: 'Magritte-Scriptaculous. Magritte-RealMemento package uses a real copy of the object as a memento, rather than a dictionary of key value pairs. The real object has behaviour which may relate data items. To use the real memento you have to override #mementoClass for your model. "Magritte-CustomBuilder" sets the default builder to use a numeric in the description selector to set the priority, like so. (I find this very useful) description0250Documents ^ MAToManyRelationDescription new classes: (Array with: DTIExternalFileModel); "Magritte-Scriptaculous extends the accessors so you can do things like this... Where the visibility of this item is determined by #hasOrderNumber." accessor: (#documents asAccessor visible: #hasOrderNumber); componentClass: MAOneToManyDocume

Re: whats the best way to access the object data when doing customrendering..?

Richard E. Flower — 2008-07-27T20:37:29

Thanks Lukas.. I looked in the class you mentioned but didn't see any of the code you show below.. Perhaps my version is older or whatever.. I did poke around on your site at a handful of projects but didn't see anything doing the same sort of thing I'm trying to do (I was specifically looking for code that subclasses MAContainerComponent and goes from there.. Perhaps I'm going about it wrong.. I've got a glorified user record that has the typical address info but also has other fields such as security questions and other stuff.. What I've got in my old (non-Magritte) code was to wrap divs around certain areas of the layout (address info is wrapped in a div and then other areas are wrapped in another div) to get the formatting I want via css.. Is there some other way? Sorry for being a pain in the rear, but I feel a bit lost on how to proceed.. Thx! On Jul 27, 2008, at 12:45 PM, Lukas Renggli wrote: _______________________________________________ SmallWiki, Magritte, Pier and Relate

Re: whats the best way to access the object data when doing customrendering..?

Lukas Renggli — 2008-07-27T19:48:48

What goal? If this is just about styling specific descriptions when using the default Seaside renderer you might want to use aDescription cssClass: 'foo' This adds the CSS CLASS .foo to the description aDescription. Cheers, Lukas

Re: whats the best way to access the object data when doing customrendering..?

Lukas Renggli — 2008-07-27T19:45:22

On Jul 27, 2008, at 17:31 , Richard E. Flower wrote: Have a look at the implementation of MAContainerComponent, it already does what you want. anObject readUsing: aDescription"reading" anObject write: aValue using: aDescription"writing" Essentially you always use the above two constructs, no matter if anObject is a memento or a real object. You just need to know the description. There are several open-source examples on squeaksource.com (Conrad, ical, ...) and source.lukas-rengli.ch (Pier, Audioscrobbler, MSE File Format, Magritte Add-Ons, Magritte Tutorial, More Magritte Add Ons, ...) that use Magritte, but I guess that doesn't help you much if you are on VW. You might still want to have a look at the code though (through the web interface). Cheers, Lukas

Re: whats the best way to access the object data when doing customrendering..?

Richard E. Flower — 2008-07-27T19:10:46

Ok.. In thinking about it further, I believe I may not need direct access to all elements of a description but I would like to be able to wrap divs around certain object descriptions for formatting purposes.. Is this the best way to achieve that goal? TIA!

Re: whats the best way to access the object data when doing customrendering..?

Richard E. Flower — 2008-07-27T16:13:06

I should have mentioned that I'm asking about accessing the memento (proxied) data specifically.. Thx!

whats the best way to access the object data when doing customrendering..?

Richard E. Flower — 2008-07-27T15:31:44

I'm trying to follow "Possibility 3" from the Magritte tutorial (page 54) where I subclass MAContainerComponent and create my own #renderContentOn: and override #descriptionContainer to point to my new subclass.. The tutorial didn't really indicate how to get the component data or other general usage -- so I figured I'd ask.. Also -- for future reference.. Is there an example or two that might be good to use as references for this sort of questioning that doesn't require pier since I'm on the VW platform? I'm a Magritte newbie and examples are very helpful.. Thx!

Re: Showing last updated structures

cdrick — 2008-07-27T14:01:03

Hi, This is icing on the cake :) I want some edit not being displayed in the "pages last updated" component. I guess I need to add a property because checked is use for persistency reason. When unchecked (trough the description) the property record will be set to false so this change won't be considered... I'll give a try soon. Thanks a lot Cédrick _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Re: too many PRContext instances ?

Lukas Renggli — 2008-07-27T08:46:13

I don't know if that's a lot. This depends on your setup. In my development image I have 3403 instances, on www.lukas-renggli.ch I have 13021 instances. Whenever a page is rendered a context is created for every possible navigation path (every link). That could be optimized of course, but never was a problem so far. These contexts should quickly go away, if they are not needed anymore. Furthermore, then are a couple of contexts (default is 1024) stored in PRHistoryPersistency (if you are using this strategy). So if you reset the history and clean the session cache, you should not have any PRContext instances anymore. Lukas

Re: Showing last updated structures

Lukas Renggli — 2008-07-27T08:37:52

I don't understand. There is already a time-stamp recorded within all the commands (see inst-var refs to 'timestamp' in PRCommand). checked is something else (see inst-var refs to 'checked' in PRCommand). As any Magritte or Pier object you can just use #propertyAt: and #propertyAt:put: and a Magritte description for clean extension without having to override or change something in the existing code. This is used in PRPersistency. This is an important part of the persistency mechanism and allows to replay commands at a later point in time without checking the validation conditions. I agree, that the implementation should be improved for readability. Cheers, Lukas