From renggli at iam.unibe.ch Mon Oct 1 01:35:10 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 30 Sep 2007 18:35:10 -0500 Subject: PRHider In-Reply-To: <46FC9F8B.6070603@yahoo.co.uk> References: <41EDE0D7-53B5-47A1-8199-8BD9D1FFF23D@iam.unibe.ch> <46FC5873.40405@yahoo.co.uk> <76AAB47B-BD84-48CE-8447-2EFA26DADF30@iam.unibe.ch> <46FC9F8B.6070603@yahoo.co.uk> Message-ID: <30ED5740-8510-4451-8B85-CF6779DA18CF@iam.unibe.ch> > self withContextDo: [] - is called in #buildChildren and in all of > the methods #buildChildren calls > > or is being up all night getting to me? You are right. Removing the unnecessary #withContextDo: calls will make the code a bit faster ;-) > also, how about: > > MAFileUploadComponent-remove > > remove > self value ifNotNilDo: [ :fileModel | fileModel delete ]. > self value: nil > > (and at least a dummy #delete method on MAFileModel) > > for those file models which handle removal. Ok, I added that to the latest version. I called it #finalize, because the deletion is (in my opinion) on a different level of abstraction. This is rather a cleanup that is done (as opposed to the initialization). Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Mon Oct 1 01:38:10 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 30 Sep 2007 18:38:10 -0500 Subject: Pier: Help please - cannot embed / call WATask In-Reply-To: References: <9aa6ae270709251009q1b8d85cbs7596072c55312f43@mail.gmail.com> <07003051-4D79-45E9-B14D-14FFC5314736@iam.unibe.ch> Message-ID: >> I suggest that you start from a clean image (not a dev image, the >> last time I tried it didn't work) > > That's funny, I downloaded the Squeak-web-dev image before I went on > vacation and just tried it due to this email and I was able to embed > the store inside pier on the first try. The only thing I see is that > it seems overly slow. The Squeak-Web-Dev images are broken in several ways: - The version of Seaside does not work with the version of Scriptaculous. - The version of Pier does not work with the version of Seaside. The situation should be better soon, as I am now actively maintaining the Universe Packages. However it the conversion is not quite finished yet. If you want to test please take a Squeak-Dev image and load the desired web packages manually. I guess these will be part of upcoming Squeak-Web-Dev images? Lukas -- Lukas Renggli http://www.lukas-renggli.ch From girba at iam.unibe.ch Mon Oct 1 14:28:40 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 1 Oct 2007 14:28:40 +0200 Subject: commands rights Message-ID: <68E824AC-0C08-4105-A152-8AD60E43B79C@iam.unibe.ch> Hi, I am building a site using Pier and I have the following problem related to user rights. The explanations are rather long. I have two groups of users: - admins - An admin can do anything, including changing rights. - editors - An editor can only Edit, Move, Remove, Add, Copy and Logout. I have two users (and will have more in the future): - admin - belongs to both the admin and editors groups. - editor - belongs to the editor group. I created 2 Commands components and embedded both in the page: - completeCommands - this component include all commands. It has the following rights: owner mode: --aaa-ccccemrsv group mode: --aaa-ccccemrsv other mode: --------------v owner: admin group: admins - editorCommands - this contains only the editor commands. It has the following rights: owner mode: --aaa-ccccemrsv group mode: --aaa-ccccemrsv other mode: --------------v owner: admin group: editors When I login as admin, I see both components, as I expected. The problem is that when I login as editor, I only see the Logout command from the editorCommands. What am I doing wrong? Cheers, Doru -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Problem solving efficiency grows with the abstractness level of problem understanding." From renggli at iam.unibe.ch Mon Oct 1 14:38:33 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 1 Oct 2007 07:38:33 -0500 Subject: commands rights In-Reply-To: <68E824AC-0C08-4105-A152-8AD60E43B79C@iam.unibe.ch> References: <68E824AC-0C08-4105-A152-8AD60E43B79C@iam.unibe.ch> Message-ID: <1B5952FA-1D36-469A-80F0-1B73EC47CAE1@iam.unibe.ch> > When I login as admin, I see both components, as I expected. The > problem is that when I login as editor, I only see the Logout command > from the editorCommands. What am I doing wrong? The list of commands the command widget shows is always reduced to a list of currently useable commands (permission and context wise). This means if you setup your widget to show 'Edit', 'Add' and 'Logout', it won't show 'Edit' if the user has not the permission to edit the current page or the current page has no edit command at all. It also won't show 'Add' if the current structure doesn't allow children. And the last example, it won't show 'Logout' if the hasn't been logged in. Does that help? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From girba at iam.unibe.ch Tue Oct 2 14:34:46 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Tue, 2 Oct 2007 14:34:46 +0200 Subject: commands rights In-Reply-To: <1B5952FA-1D36-469A-80F0-1B73EC47CAE1@iam.unibe.ch> References: <68E824AC-0C08-4105-A152-8AD60E43B79C@iam.unibe.ch> <1B5952FA-1D36-469A-80F0-1B73EC47CAE1@iam.unibe.ch> Message-ID: Hi Lukas, Yep, it helped quite a bit :). It works now. Cheers, Doru On Oct 1, 2007, at 2:38 PM, Lukas Renggli wrote: >> When I login as admin, I see both components, as I expected. The >> problem is that when I login as editor, I only see the Logout command >> from the editorCommands. What am I doing wrong? > > The list of commands the command widget shows is always reduced to a > list of currently useable commands (permission and context wise). > > This means if you setup your widget to show 'Edit', 'Add' and > 'Logout', it won't show 'Edit' if the user has not the permission to > edit the current page or the current page has no edit command at all. > It also won't show 'Add' if the current structure doesn't allow > children. And the last example, it won't show 'Logout' if the hasn't > been logged in. > > Does that help? > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "To lead is not to demand things, it is to make them happen." From keith_hodges at yahoo.co.uk Wed Oct 3 11:08:38 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 03 Oct 2007 10:08:38 +0100 Subject: File Upload Message-ID: <47035C16.8000203@yahoo.co.uk> I have attempted to use the MAFileUploadComponent slightly more manually than usual. e.g. getComponent ^ widget childrenCache at: {item. field} ifAbsentPut: [ (field componentClass memento: (MAStraitMemento model: item description: field) description: field parent: widget). ]. However, the value returned to the callback is the filename string, rather than the file itself. I feel I am missing something somewhere, any ideas what it might be? Keith From renggli at iam.unibe.ch Wed Oct 3 20:29:33 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 3 Oct 2007 13:29:33 -0500 Subject: File Upload In-Reply-To: <47035C16.8000203@yahoo.co.uk> References: <47035C16.8000203@yahoo.co.uk> Message-ID: <14393346-D7DF-4DE5-96D1-D9554B6E4049@iam.unibe.ch> > However, the value returned to the callback is the filename string, > rather than the file itself. I feel I am missing something somewhere, > any ideas what it might be? Is your form declared as a multipart form? Magritte normally does that automatically, but only if it knows that there is a file-upload component somewhere. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Thu Oct 4 15:45:50 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Thu, 04 Oct 2007 14:45:50 +0100 Subject: File Upload In-Reply-To: <14393346-D7DF-4DE5-96D1-D9554B6E4049@iam.unibe.ch> References: <47035C16.8000203@yahoo.co.uk> <14393346-D7DF-4DE5-96D1-D9554B6E4049@iam.unibe.ch> Message-ID: <4704EE8E.4040400@yahoo.co.uk> Lukas Renggli wrote: >> However, the value returned to the callback is the filename string, >> rather than the file itself. I feel I am missing something somewhere, >> any ideas what it might be? >> > > Is your form declared as a multipart form? Magritte normally does > that automatically, but only if it knows that there is a file-upload > component somewhere. > > Lukas > That will be it, thank you so much. I do find the whole forms handling in seaside a confusing thing... I dont see how my inner components are supposed to know whether or not they are in a form. I am not sure how much seaside does for me in this respect etc etc... anyways... thanks again for your help Keith From renggli at iam.unibe.ch Thu Oct 4 15:53:29 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 4 Oct 2007 08:53:29 -0500 Subject: File Upload In-Reply-To: <4704EE8E.4040400@yahoo.co.uk> References: <47035C16.8000203@yahoo.co.uk> <14393346-D7DF-4DE5-96D1-D9554B6E4049@iam.unibe.ch> <4704EE8E.4040400@yahoo.co.uk> Message-ID: <9467571E-6376-4A71-AB71-8D58A0FE4CD6@iam.unibe.ch> > I dont see how my inner components are supposed to know whether or not > they are in a form. I am not sure how much seaside does for me in this > respect etc etc... You can find that out by walking up the stack. Something like this should work (but it is not nice): isWithinForm current := thisContext. [ current isNil ] whileFalse: [ current selector = #form ifTrue: [ ^ true ]. current := current sender ]. ^ false In Magritte the model tells Seaside if it requires a multipart form or not. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Fri Oct 5 03:48:22 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 05 Oct 2007 02:48:22 +0100 Subject: Magritte #save inform the model? Message-ID: <470597E6.6020604@yahoo.co.uk> Hello, I have a settings model which initializes from description defaults and keeps its values as a properties dictionary. If when coding I happen to change or remove a description, when I edit and save the settings the stale description still remains in the properties dictionary. I am looking for a hook with which I can tell the Memento, to clear the old settings and write the new ones. Is there such a thing? For example if the model knew it was about to be saved to it could clear out/reset its values in anticipation. best regards Keith From cappadonza at hotmail.com Sat Oct 6 12:03:03 2007 From: cappadonza at hotmail.com (Isaiah Perumalla) Date: Sat, 6 Oct 2007 03:03:03 -0700 (PDT) Subject: Magritte MAConditionBuilder Message-ID: <13072248.post@talk.nabble.com> hey guys in magritte MAConditionBuilder is a subclass of protoObject not object. what is the reason for this. -- View this message in context: http://www.nabble.com/Magritte-MAConditionBuilder-tf4579297.html#a13072248 Sent from the SmallWiki mailing list archive at Nabble.com. From renggli at iam.unibe.ch Sat Oct 6 15:47:33 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 6 Oct 2007 08:47:33 -0500 Subject: Magritte MAConditionBuilder In-Reply-To: <13072248.post@talk.nabble.com> References: <13072248.post@talk.nabble.com> Message-ID: <4EAF8778-7177-4C83-8A82-D5C09F89A8AC@iam.unibe.ch> > hey guys in magritte MAConditionBuilder is a subclass of > protoObject not > object. what is the reason for this. Check out the references of MAConditionBuilder. The comment says: BlockContext>>asCondition "Convert the receiver to a condition, e.g. a parse tree representing the condition within the block. This is done by passing a proxy into the block and manually building a tree of conditions. This doesn't work for all code, but has the big advantage to make it fully serializeable." I rarely use this feature anymore. This is only useful if you want your conditions not to be block contexts (e.g. to serialize them). I guess the whole condition code could be removed, unless somebody opposes? Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Sat Oct 6 15:51:57 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 6 Oct 2007 08:51:57 -0500 Subject: Magritte #save inform the model? In-Reply-To: <470597E6.6020604@yahoo.co.uk> References: <470597E6.6020604@yahoo.co.uk> Message-ID: <9B763644-788D-427F-BCD5-C4568A5FFE53@iam.unibe.ch> > I am looking for a hook with which I can tell the Memento, to clear > the > old settings and write the new ones. Is there such a thing? > For example if the model knew it was about to be saved to it could > clear > out/reset its values in anticipation. You could implement your own Memento, but usually it is more complicated as the same descriptions could be used in many different objects. For me, most of the time I don't worry about these old settings. Maybe you could run from time to time a batch job, that cleans up orphaned settings? Lukas -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Sat Oct 6 22:43:33 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Sat, 6 Oct 2007 20:43:33 +0000 Subject: Magritte MAConditionBuilder In-Reply-To: <4EAF8778-7177-4C83-8A82-D5C09F89A8AC@iam.unibe.ch> References: <13072248.post@talk.nabble.com> <4EAF8778-7177-4C83-8A82-D5C09F89A8AC@iam.unibe.ch> Message-ID: i'm attempting to port magritte to GemStone, from what i understand main reason MACondition class exist is so that block context can be serialized and stored. Phillipe pointed out that GemStone support block directly. so in GemStone MACondition would not be needed, i was going to remove MAConditons for the GemStone port, and implement #asCondition on a Block to return self, so any code that used #asConditon would still work Gemstone. is that okay. > From: renggli at iam.unibe.ch> Subject: Re: Magritte MAConditionBuilder> Date: Sat, 6 Oct 2007 08:47:33 -0500> To: smallwiki at iam.unibe.ch> > > hey guys in magritte MAConditionBuilder is a subclass of > > protoObject not> > object. what is the reason for this.> > Check out the references of MAConditionBuilder.> > The comment says:> > BlockContext>>asCondition> "Convert the receiver to a condition, e.g. a parse tree > representing the condition within the block. This is done by passing > a proxy into the block and manually building a tree of conditions. > This doesn't work for all code, but has the big advantage to make it > fully serializeable."> > I rarely use this feature anymore. This is only useful if you want > your conditions not to be block contexts (e.g. to serialize them).> > I guess the whole condition code could be removed, unless somebody > opposes?> > Lukas> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ New music from the Rogue Traders - listen now! http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=832&referral=hotmailtaglineOct07&URL=http://music.ninemsn.com.au/roguetraders -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071006/6021b535/attachment.html From renggli at iam.unibe.ch Sat Oct 6 22:52:27 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 6 Oct 2007 15:52:27 -0500 Subject: Magritte MAConditionBuilder In-Reply-To: References: <13072248.post@talk.nabble.com> <4EAF8778-7177-4C83-8A82-D5C09F89A8AC@iam.unibe.ch> Message-ID: <169EE58F-8F46-4464-AAE0-6B5FFE36DB37@iam.unibe.ch> > Phillipe pointed out that GemStone support block directly. so in > GemStone MACondition would not be needed, i was going to remove > MAConditons for the GemStone port, and implement #asCondition on a > Block to return self, so any code that used #asConditon would still > work Gemstone. is that okay. Yes, that makes sense. Cheers, Lukas > > > > > From: renggli at iam.unibe.ch > > Subject: Re: Magritte MAConditionBuilder > > Date: Sat, 6 Oct 2007 08:47:33 -0500 > > To: smallwiki at iam.unibe.ch > > > > > hey guys in magritte MAConditionBuilder is a subclass of > > > protoObject not > > > object. what is the reason for this. > > > > Check out the references of MAConditionBuilder. > > > > The comment says: > > > > BlockContext>>asCondition > > "Convert the receiver to a condition, e.g. a parse tree > > representing the condition within the block. This is done by passing > > a proxy into the block and manually building a tree of conditions. > > This doesn't work for all code, but has the big advantage to make it > > fully serializeable." > > > > I rarely use this feature anymore. This is only useful if you want > > your conditions not to be block contexts (e.g. to serialize them). > > > > I guess the whole condition code could be removed, unless somebody > > opposes? > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > Listen now! New music from the Rogue Traders. > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Mon Oct 8 14:02:11 2007 From: cappadonza at hotmail.com (Isaiah Perumalla) Date: Mon, 8 Oct 2007 05:02:11 -0700 (PDT) Subject: Magritte object serialization #testReferenceStream Message-ID: <13095132.post@talk.nabble.com> hey guys In Magritte in MAObjectTest class there is a method #testReferenceStream which basically ensures every object is serializable and after the object is deserialized, the original and serialized object are equal but have different references. (ie serialized object is a copy of the original object). In Magritte what and where is object serialization used for ? so i can get a better understanding on how to test this in GemStone/s thanks Isaiah -- View this message in context: http://www.nabble.com/Magritte-object-serialization--testReferenceStream-tf4587701.html#a13095132 Sent from the SmallWiki mailing list archive at Nabble.com. From renggli at iam.unibe.ch Mon Oct 8 16:00:13 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 8 Oct 2007 16:00:13 +0200 Subject: Magritte object serialization #testReferenceStream In-Reply-To: <13095132.post@talk.nabble.com> References: <13095132.post@talk.nabble.com> Message-ID: > In Magritte what and where is object serialization used for ? so i > can get a better understanding on how to test this in GemStone/s Actually, this is not used anymore. Earlier versions of Pier had a simple Magritte based binary file-format, that never worked out as I wanted. I will remove that test, together with the conditions (as nobody opposed). Lukas -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Mon Oct 8 16:03:22 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Mon, 8 Oct 2007 14:03:22 +0000 Subject: Magritte object serialization #testReferenceStream In-Reply-To: References: <13095132.post@talk.nabble.com> Message-ID: Cool Thanks Lukas> From: renggli at iam.unibe.ch> Subject: Re: Magritte object serialization #testReferenceStream> Date: Mon, 8 Oct 2007 16:00:13 +0200> To: smallwiki at iam.unibe.ch> > > In Magritte what and where is object serialization used for ? so i > > can get a better understanding on how to test this in GemStone/s> > Actually, this is not used anymore. Earlier versions of Pier had a > simple Magritte based binary file-format, that never worked out as I > wanted.> > I will remove that test, together with the conditions (as nobody > opposed).> > Lukas> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071008/8ce1b10d/attachment.html From renggli at iam.unibe.ch Mon Oct 8 16:13:46 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 8 Oct 2007 16:13:46 +0200 Subject: Magritte object serialization #testReferenceStream In-Reply-To: References: <13095132.post@talk.nabble.com> Message-ID: <6800DB31-5C48-4F75-A2EE-3EE9BEF99F4D@iam.unibe.ch> I committed the changes. Tests still pass. Also the ones of Pier. Lukas On 8 Oct 2007, at 16:03, isaiah perumalla wrote: > Cool Thanks Lukas > > > From: renggli at iam.unibe.ch > > Subject: Re: Magritte object serialization #testReferenceStream > > Date: Mon, 8 Oct 2007 16:00:13 +0200 > > To: smallwiki at iam.unibe.ch > > > > > In Magritte what and where is object serialization used for ? so i > > > can get a better understanding on how to test this in GemStone/s > > > > Actually, this is not used anymore. Earlier versions of Pier had a > > simple Magritte based binary file-format, that never worked out as I > > wanted. > > > > I will remove that test, together with the conditions (as nobody > > opposed). > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > Find it at www.seek.com.au Your Future Starts Here. Dream it? Then > be it! > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Wed Oct 10 12:25:51 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Wed, 10 Oct 2007 10:25:51 +0000 Subject: [GS/SS Beta] SystemChangeNotifier & MADescriptionBuilder. In-Reply-To: <66666f210710092148wf504c43h36fd005c4762084@mail.gmail.com> References: <66666f210710092148wf504c43h36fd005c4762084@mail.gmail.com> Message-ID: Thanks Philippe yeh i undestand how the meta-descriptions for an object are built. it makes sense to use the solution you propose, however i dont want to get rid of the cache, i like the idea of keeping a cache of built descriptions for an object and each time new code is deployed the cache has to be manually flushed, by calling #flush on the default instance of MADescriptionBuilder. Dale is going implement SystemChangeNotifier soon for, so we can always allow MADescriptionBuilder to subcribe to systemEvents later. Does that sound reasonable ? PS: looking at the squeak implementation it seems that MADescriptionBuilder flushes its cache of description if any method is changed or modified or added in the entire System, not necessrily an object in the MADescriptionBuilder cache > Date: Wed, 10 Oct 2007 06:48:18 +0200> From: philippe.marschall at gmail.com> To: cappadonza at hotmail.com> Subject: Re: [GS/SS Beta] [betaG/S] SystemChangeNotifier> CC: beta at seaside.gemstone.com> > 2007/10/9, isaiah perumalla :> >> > in squeak there is a class ystemChangeNotifier, what is the equivalent of> > that in Gemstone/S> > I don't think you necessarily need one. Some background:> To build a metadescription of an object Magritte per default only> looks a the class side. It collects all the selectors the class of the> object contains that begin with 'description' and performs them. This> can take a moment on Squeak so a cache was added that maps classes to> metadescriptions. This cache will have to be invalidated if a class is> changed (a method added or removed).> > A solution for this would be to make a MADescriptionBuilder for use in> production, this one would not be invalidated automatically. You would> have to invalidate it whenever you deploy code. It might be that> building metadescriptions of GemStone in fast enough and you don't> need any cache.> > Cheers> Philippe> > > ________________________________> > Sell your car for just $30 at CarPoint.com.au. It's simple! _________________________________________________________________ It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071010/05cf1ce5/attachment.html From renggli at gmail.com Wed Oct 10 13:34:20 2007 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 10 Oct 2007 13:34:20 +0200 Subject: [GS/SS Beta] SystemChangeNotifier & MADescriptionBuilder In-Reply-To: References: <66666f210710092148wf504c43h36fd005c4762084@mail.gmail.com> Message-ID: <67628d690710100434h1348e3dfi442555f4c99d0b5c@mail.gmail.com> > To build a metadescription of an object Magritte per default only > looks a the class side. It collects all the selectors the class of the > object contains that begin with 'description' and performs them. This > can take a moment on Squeak so a cache was added that maps classes to > metadescriptions. This cache will have to be invalidated if a class is > changed (a method added or removed). The cache is only useful if you need to traverse a collection of thousands of objects that mostly share the same descriptions. Like this, descriptions don't need to be recreated all the time. This significantly speeds up the traversal. > PS: looking at the squeak implementation it seems that MADescriptionBuilder > flushes its cache of description if any method is changed or modified or > added in the entire System, not necessrily an object in the > MADescriptionBuilder cache This is the simplest thing that reliably works. It could be that you call other methods from the code that builds the descriptions (for example, if you extract default values to separate methods), that could affect the settings of the descriptions. In a productive system the cache fills up pretty fast. Since code changes in a productive system are rare this is not an issue. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Wed Oct 10 13:51:18 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Wed, 10 Oct 2007 11:51:18 +0000 Subject: [GS/SS Beta] SystemChangeNotifier & MADescriptionBuilder In-Reply-To: <67628d690710100434h1348e3dfi442555f4c99d0b5c@mail.gmail.com> References: <66666f210710092148wf504c43h36fd005c4762084@mail.gmail.com> <67628d690710100434h1348e3dfi442555f4c99d0b5c@mail.gmail.com> Message-ID: Thanks Lukas So for magritte GemStone port, I will let the MADescriptionBuilder build and cache the description for objects if it doesnt already exist in the cache and since code chages will be very rare in a production enviorment, i leave out MABuilderDescription subscription to SystemChangeNotifer for method chages in the System Cheers ISaiah> Date: Wed, 10 Oct 2007 13:34:20 +0200> From: renggli at gmail.com> To: smallwiki at iam.unibe.ch; beta at seaside.gemstone.com> Subject: Re: [GS/SS Beta] SystemChangeNotifier & MADescriptionBuilder> > > To build a metadescription of an object Magritte per default only> > looks a the class side. It collects all the selectors the class of the> > object contains that begin with 'description' and performs them. This> > can take a moment on Squeak so a cache was added that maps classes to> > metadescriptions. This cache will have to be invalidated if a class is> > changed (a method added or removed).> > The cache is only useful if you need to traverse a collection of> thousands of objects that mostly share the same descriptions. Like> this, descriptions don't need to be recreated all the time. This> significantly speeds up the traversal.> > > PS: looking at the squeak implementation it seems that MADescriptionBuilder> > flushes its cache of description if any method is changed or modified or> > added in the entire System, not necessrily an object in the> > MADescriptionBuilder cache> > This is the simplest thing that reliably works. It could be that you> call other methods from the code that builds the descriptions (for> example, if you extract default values to separate methods), that> could affect the settings of the descriptions. In a productive system> the cache fills up pretty fast. Since code changes in a productive> system are rare this is not an issue.> > Lukas> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071010/d5408e11/attachment-0001.html From cappadonza at hotmail.com Thu Oct 11 14:00:29 2007 From: cappadonza at hotmail.com (Isaiah Perumalla) Date: Thu, 11 Oct 2007 05:00:29 -0700 (PDT) Subject: Magritte MAUnlimited Message-ID: <13154302.post@talk.nabble.com> In magritte MAUnlimited is a subclass of Magnitude, since MAUnlimited is either a Unlimited Positive, or Unlimited negative and since it overrides #adaptToNumber: andSend:, is there a reason why it shouldnt be a subclass of Number rather than a subclass of Magnitude. it might make it easier for me if i made MAUnlimited subclass of number instead of Magnitude in the GemStone/s version. thanks Isaiah -- View this message in context: http://www.nabble.com/Magritte-MAUnlimited-tf4606754.html#a13154302 Sent from the SmallWiki mailing list archive at Nabble.com. From renggli at iam.unibe.ch Thu Oct 11 14:22:43 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Oct 2007 14:22:43 +0200 Subject: Magritte MAUnlimited In-Reply-To: <13154302.post@talk.nabble.com> References: <13154302.post@talk.nabble.com> Message-ID: > In magritte MAUnlimited is a subclass of Magnitude, since > MAUnlimited is > either a Unlimited Positive, or Unlimited negative and since it > overrides > #adaptToNumber: andSend:, is there a reason why it shouldnt be a > subclass of > Number rather than a subclass of Magnitude. it might make it easier > for me > if i made MAUnlimited subclass of number instead of Magnitude in the > GemStone/s version. Actually this class is not used. Also MAMultiplicity is not used. These two classes were part of an experiment that I didn't took any further for now. The classes are not part of the latest version of Magritte anymore. Lukas Name: Magritte-All-lr.247 Author: lr Time: 11 October 2007, 2:20:01 pm UUID: c15364eb-b250-4562-8716-67d0a1bd3984 Ancestors: Magritte-All-lr.246 - removed some unused code -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Thu Oct 11 14:24:57 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Thu, 11 Oct 2007 12:24:57 +0000 Subject: Magritte MAUnlimited In-Reply-To: References: <13154302.post@talk.nabble.com> Message-ID: ok cool thanks for your help lukas Isaiah> From: renggli at iam.unibe.ch> Subject: Re: Magritte MAUnlimited> Date: Thu, 11 Oct 2007 14:22:43 +0200> To: smallwiki at iam.unibe.ch> > > In magritte MAUnlimited is a subclass of Magnitude, since > > MAUnlimited is> > either a Unlimited Positive, or Unlimited negative and since it > > overrides> > #adaptToNumber: andSend:, is there a reason why it shouldnt be a > > subclass of> > Number rather than a subclass of Magnitude. it might make it easier > > for me> > if i made MAUnlimited subclass of number instead of Magnitude in the> > GemStone/s version.> > Actually this class is not used. Also MAMultiplicity is not used.> > These two classes were part of an experiment that I didn't took any > further for now. The classes are not part of the latest version of > Magritte anymore.> > Lukas> > > Name: Magritte-All-lr.247> Author: lr> Time: 11 October 2007, 2:20:01 pm> UUID: c15364eb-b250-4562-8716-67d0a1bd3984> Ancestors: Magritte-All-lr.246> > - removed some unused code> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071011/14632431/attachment.html From cappadonza at hotmail.com Thu Oct 11 17:00:34 2007 From: cappadonza at hotmail.com (Isaiah Perumalla) Date: Thu, 11 Oct 2007 08:00:34 -0700 (PDT) Subject: Magritte- MAProxyObject, MADynamic object Message-ID: <13157752.post@talk.nabble.com> what and how are MAProxyObject and MADynamicObject used in magritte ? i know it acts as a proxy for a 'real Object'. where are these proxies used ? -- View this message in context: http://www.nabble.com/Magritte--MAProxyObject%2C-MADynamic-object-tf4607813.html#a13157752 Sent from the SmallWiki mailing list archive at Nabble.com. From renggli at iam.unibe.ch Thu Oct 11 18:14:43 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Oct 2007 18:14:43 +0200 Subject: Magritte- MAProxyObject, MADynamic object In-Reply-To: <13157752.post@talk.nabble.com> References: <13157752.post@talk.nabble.com> Message-ID: > what and how are MAProxyObject and MADynamicObject used in magritte ? > i know it acts as a proxy for a 'real Object'. where are these > proxies used > ? It is rarely used, I try to avoid its use as much as possible. MAProxyObject is an abstract class. MADynamicObject is created when sending the message #asDynamicObject to a block. The idea is to have dynamic properties in descriptions (or other objects). For example in Pier the owner of a structure is described on the class side with something like: MASingleOptionDescription new beSorted; label: 'Owner'; selectorAccessor: #owner; reference: PUUser description; options: [ self allUsers ] asDynamicObject; yourself This means every time the options are queried the sender gets a proxy object that (most of the time) resolves to the list of all available users. Again, this is cool magic that works most of the time, but I strongly discourage to use it. In all cases it is possible to avoid its use all-together, for example by overriding #description on the instance side and adding the description manually instead of defining it on the class side. I am just too lazy to do that sometimes ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Thu Oct 11 18:39:15 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Thu, 11 Oct 2007 16:39:15 +0000 Subject: Magritte- MAProxyObject, MADynamic object In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: thanks lukas, make sense. For the port to GemStone/S i might leave MAProxyObject and MADynamicObject out. it can always be added later if people really want it. what do you think ? > From: renggli at iam.unibe.ch> Subject: Re: Magritte- MAProxyObject, MADynamic object> Date: Thu, 11 Oct 2007 18:14:43 +0200> To: smallwiki at iam.unibe.ch> > > what and how are MAProxyObject and MADynamicObject used in magritte ?> > i know it acts as a proxy for a 'real Object'. where are these > > proxies used> > ?> > It is rarely used, I try to avoid its use as much as possible. > MAProxyObject is an abstract class. MADynamicObject is created when > sending the message #asDynamicObject to a block.> > The idea is to have dynamic properties in descriptions (or other > objects). For example in Pier the owner of a structure is described > on the class side with something like:> > MASingleOptionDescription new> beSorted;> label: 'Owner';> selectorAccessor: #owner;> reference: PUUser description;> options: [ self allUsers ] asDynamicObject;> yourself> > This means every time the options are queried the sender gets a proxy > object that (most of the time) resolves to the list of all available > users.> > Again, this is cool magic that works most of the time, but I strongly > discourage to use it. In all cases it is possible to avoid its use > all-together, for example by overriding #description on the instance > side and adding the description manually instead of defining it on > the class side. I am just too lazy to do that sometimes ;-)> > Cheers,> Lukas> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Overpaid or Underpaid? Check our comprehensive Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071011/45ec8f16/attachment.html From renggli at iam.unibe.ch Thu Oct 11 20:14:42 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Oct 2007 20:14:42 +0200 Subject: Magritte- MAProxyObject, MADynamic object In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: > thanks lukas, make sense. For the port to GemStone/S i might leave > MAProxyObject and MADynamicObject out. it can always be added later > if people really want it. > what do you think ? Yes, I would do so. Pier has some users, but we could either refactor those or port MADynamicObject later on. I guess GemStone/S also supports #doesNotUnderstand:? Lukas > > > From: renggli at iam.unibe.ch > > Subject: Re: Magritte- MAProxyObject, MADynamic object > > Date: Thu, 11 Oct 2007 18:14:43 +0200 > > To: smallwiki at iam.unibe.ch > > > > > what and how are MAProxyObject and MADynamicObject used in > magritte ? > > > i know it acts as a proxy for a 'real Object'. where are these > > > proxies used > > > ? > > > > It is rarely used, I try to avoid its use as much as possible. > > MAProxyObject is an abstract class. MADynamicObject is created when > > sending the message #asDynamicObject to a block. > > > > The idea is to have dynamic properties in descriptions (or other > > objects). For example in Pier the owner of a structure is described > > on the class side with something like: > > > > MASingleOptionDescription new > > beSorted; > > label: 'Owner'; > > selectorAccessor: #owner; > > reference: PUUser description; > > options: [ self allUsers ] asDynamicObject; > > yourself > > > > This means every time the options are queried the sender gets a > proxy > > object that (most of the time) resolves to the list of all available > > users. > > > > Again, this is cool magic that works most of the time, but I > strongly > > discourage to use it. In all cases it is possible to avoid its use > > all-together, for example by overriding #description on the instance > > side and adding the description manually instead of defining it on > > the class side. I am just too lazy to do that sometimes ;-) > > > > Cheers, > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > Check our comprehensive Salary Centre Overpaid or Underpaid? > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Thu Oct 11 21:34:26 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Thu, 11 Oct 2007 19:34:26 +0000 Subject: Magritte- MAProxyObject, MADynamic In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: yeh i had a quick look and i saw pier using these proxy classes. yep GemStone/S Object supports #doesNotUnderstand:. so it shouldnt be too difficult to either refactor or add MADynamicObject later. however GemStone/S doesnt support protoObject. so i guess the MADynamicproxyObject will have to inherit from Object > From: renggli at iam.unibe.ch> Subject: Re: Magritte- MAProxyObject, MADynamic object> Date: Thu, 11 Oct 2007 20:14:42 +0200> To: smallwiki at iam.unibe.ch> > > thanks lukas, make sense. For the port to GemStone/S i might leave > > MAProxyObject and MADynamicObject out. it can always be added later > > if people really want it.> > what do you think ?> > Yes, I would do so.> > Pier has some users, but we could either refactor those or port > MADynamicObject later on. I guess GemStone/S also supports > #doesNotUnderstand:?> > Lukas> > > >> > > From: renggli at iam.unibe.ch> > > Subject: Re: Magritte- MAProxyObject, MADynamic object> > > Date: Thu, 11 Oct 2007 18:14:43 +0200> > > To: smallwiki at iam.unibe.ch> > >> > > > what and how are MAProxyObject and MADynamicObject used in > > magritte ?> > > > i know it acts as a proxy for a 'real Object'. where are these> > > > proxies used> > > > ?> > >> > > It is rarely used, I try to avoid its use as much as possible.> > > MAProxyObject is an abstract class. MADynamicObject is created when> > > sending the message #asDynamicObject to a block.> > >> > > The idea is to have dynamic properties in descriptions (or other> > > objects). For example in Pier the owner of a structure is described> > > on the class side with something like:> > >> > > MASingleOptionDescription new> > > beSorted;> > > label: 'Owner';> > > selectorAccessor: #owner;> > > reference: PUUser description;> > > options: [ self allUsers ] asDynamicObject;> > > yourself> > >> > > This means every time the options are queried the sender gets a > > proxy> > > object that (most of the time) resolves to the list of all available> > > users.> > >> > > Again, this is cool magic that works most of the time, but I > > strongly> > > discourage to use it. In all cases it is possible to avoid its use> > > all-together, for example by overriding #description on the instance> > > side and adding the description manually instead of defining it on> > > the class side. I am just too lazy to do that sometimes ;-)> > >> > > Cheers,> > > Lukas> > >> > > --> > > Lukas Renggli> > > http://www.lukas-renggli.ch> > >> > >> > > _______________________________________________> > > SmallWiki, Magritte, Pier and Related Tools ...> > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> >> >> > Check our comprehensive Salary Centre Overpaid or Underpaid?> >> > _______________________________________________> > SmallWiki, Magritte, Pier and Related Tools ...> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071011/273f176c/attachment.html From renggli at iam.unibe.ch Thu Oct 11 22:34:41 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 11 Oct 2007 22:34:41 +0200 Subject: Magritte- MAProxyObject, MADynamic In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: > yeh i had a quick look and i saw pier using these proxy classes. > yep GemStone/S Object supports #doesNotUnderstand:. so it shouldnt > be too difficult to either refactor or add MADynamicObject later. > however GemStone/S doesnt support protoObject. so i guess the > MADynamicproxyObject will have to inherit from Object What is the superclass of Object in GemStone/S? I guess MADynamicObject should have the same (probably this is nil). Lukas > > > > From: renggli at iam.unibe.ch > > Subject: Re: Magritte- MAProxyObject, MADynamic object > > Date: Thu, 11 Oct 2007 20:14:42 +0200 > > To: smallwiki at iam.unibe.ch > > > > > thanks lukas, make sense. For the port to GemStone/S i might leave > > > MAProxyObject and MADynamicObject out. it can always be added > later > > > if people really want it. > > > what do you think ? > > > > Yes, I would do so. > > > > Pier has some users, but we could either refactor those or port > > MADynamicObject later on. I guess GemStone/S also supports > > #doesNotUnderstand:? > > > > Lukas > > > > > > > > > > > From: renggli at iam.unibe.ch > > > > Subject: Re: Magritte- MAProxyObject, MADynamic object > > > > Date: Thu, 11 Oct 2007 18:14:43 +0200 > > > > To: smallwiki at iam.unibe.ch > > > > > > > > > what and how are MAProxyObject and MADynamicObject used in > > > magritte ? > > > > > i know it acts as a proxy for a 'real Object'. where are these > > > > > proxies used > > > > > ? > > > > > > > > It is rarely used, I try to avoid its use as much as possible. > > > > MAProxyObject is an abstract class. MADynamicObject is > created when > > > > sending the message #asDynamicObject to a block. > > > > > > > > The idea is to have dynamic properties in descriptions (or other > > > > objects). For example in Pier the owner of a structure is > described > > > > on the class side with something like: > > > > > > > > MASingleOptionDescription new > > > > beSorted; > > > > label: 'Owner'; > > > > selectorAccessor: #owner; > > > > reference: PUUser description; > > > > options: [ self allUsers ] asDynamicObject; > > > > yourself > > > > > > > > This means every time the options are queried the sender gets a > > > proxy > > > > object that (most of the time) resolves to the list of all > available > > > > users. > > > > > > > > Again, this is cool magic that works most of the time, but I > > > strongly > > > > discourage to use it. In all cases it is possible to avoid > its use > > > > all-together, for example by overriding #description on the > instance > > > > side and adding the description manually instead of defining > it on > > > > the class side. I am just too lazy to do that sometimes ;-) > > > > > > > > Cheers, > > > > Lukas > > > > > > > > -- > > > > Lukas Renggli > > > > http://www.lukas-renggli.ch > > > > > > > > > > > > _______________________________________________ > > > > SmallWiki, Magritte, Pier and Related Tools ... > > > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > > > > > > Check our comprehensive Salary Centre Overpaid or Underpaid? > > > > > > _______________________________________________ > > > SmallWiki, Magritte, Pier and Related Tools ... > > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > SmallWiki, Magritte, Pier and Related Tools ... > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > Find it at www.seek.com.au Your Future Starts Here. Dream it? Then > be it! > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Fri Oct 12 11:03:55 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Fri, 12 Oct 2007 09:03:55 +0000 Subject: Magritte- MAProxyObject, MADynamic In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: yep thats right superclass of Object in GemStone/S is nil, so yeh that makes sense to make MAProxyObject to inherit from nil. i will implement these objects and include it in Magritte GemStone/S version, since Pier is using it i dont want to leave it. thanks Isaiah> From: renggli at iam.unibe.ch> Subject: Re: Magritte- MAProxyObject, MADynamic > Date: Thu, 11 Oct 2007 22:34:41 +0200> To: smallwiki at iam.unibe.ch> > > yeh i had a quick look and i saw pier using these proxy classes. > > yep GemStone/S Object supports #doesNotUnderstand:. so it shouldnt > > be too difficult to either refactor or add MADynamicObject later. > > however GemStone/S doesnt support protoObject. so i guess the > > MADynamicproxyObject will have to inherit from Object> > What is the superclass of Object in GemStone/S?> > I guess MADynamicObject should have the same (probably this is nil).> > Lukas> > > >> >> > > From: renggli at iam.unibe.ch> > > Subject: Re: Magritte- MAProxyObject, MADynamic object> > > Date: Thu, 11 Oct 2007 20:14:42 +0200> > > To: smallwiki at iam.unibe.ch> > >> > > > thanks lukas, make sense. For the port to GemStone/S i might leave> > > > MAProxyObject and MADynamicObject out. it can always be added > > later> > > > if people really want it.> > > > what do you think ?> > >> > > Yes, I would do so.> > >> > > Pier has some users, but we could either refactor those or port> > > MADynamicObject later on. I guess GemStone/S also supports> > > #doesNotUnderstand:?> > >> > > Lukas> > >> > >> > > >> > > > > From: renggli at iam.unibe.ch> > > > > Subject: Re: Magritte- MAProxyObject, MADynamic object> > > > > Date: Thu, 11 Oct 2007 18:14:43 +0200> > > > > To: smallwiki at iam.unibe.ch> > > > >> > > > > > what and how are MAProxyObject and MADynamicObject used in> > > > magritte ?> > > > > > i know it acts as a proxy for a 'real Object'. where are these> > > > > > proxies used> > > > > > ?> > > > >> > > > > It is rarely used, I try to avoid its use as much as possible.> > > > > MAProxyObject is an abstract class. MADynamicObject is > > created when> > > > > sending the message #asDynamicObject to a block.> > > > >> > > > > The idea is to have dynamic properties in descriptions (or other> > > > > objects). For example in Pier the owner of a structure is > > described> > > > > on the class side with something like:> > > > >> > > > > MASingleOptionDescription new> > > > > beSorted;> > > > > label: 'Owner';> > > > > selectorAccessor: #owner;> > > > > reference: PUUser description;> > > > > options: [ self allUsers ] asDynamicObject;> > > > > yourself> > > > >> > > > > This means every time the options are queried the sender gets a> > > > proxy> > > > > object that (most of the time) resolves to the list of all > > available> > > > > users.> > > > >> > > > > Again, this is cool magic that works most of the time, but I> > > > strongly> > > > > discourage to use it. In all cases it is possible to avoid > > its use> > > > > all-together, for example by overriding #description on the > > instance> > > > > side and adding the description manually instead of defining > > it on> > > > > the class side. I am just too lazy to do that sometimes ;-)> > > > >> > > > > Cheers,> > > > > Lukas> > > > >> > > > > --> > > > > Lukas Renggli> > > > > http://www.lukas-renggli.ch> > > > >> > > > >> > > > > _______________________________________________> > > > > SmallWiki, Magritte, Pier and Related Tools ...> > > > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> > > >> > > >> > > > Check our comprehensive Salary Centre Overpaid or Underpaid?> > > >> > > > _______________________________________________> > > > SmallWiki, Magritte, Pier and Related Tools ...> > > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> > >> > > --> > > Lukas Renggli> > > http://www.lukas-renggli.ch> > >> > >> > > _______________________________________________> > > SmallWiki, Magritte, Pier and Related Tools ...> > > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> >> > Find it at www.seek.com.au Your Future Starts Here. Dream it? Then > > be it!> >> > _______________________________________________> > SmallWiki, Magritte, Pier and Related Tools ...> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071012/114a3cb9/attachment-0001.html From keith_hodges at yahoo.co.uk Sat Oct 13 18:13:05 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 13 Oct 2007 17:13:05 +0100 Subject: moveUp: moveDown: In-Reply-To: References: <13157752.post@talk.nabble.com> Message-ID: <4710EE91.8080305@yahoo.co.uk> Dear Lukas, I notice that when using the magritte list composition tool duplicates are allowed but it cant handle moving idividual items up and down reliably. On investigation it appears that the reason is due to moveUp: and moveDown: using indexOf: rather than identityIndexOf: I am not sure whether changing this behaviour would break other things. I am testing it out with this change. Keith From renggli at iam.unibe.ch Sat Oct 13 19:10:38 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sat, 13 Oct 2007 19:10:38 +0200 Subject: moveUp: moveDown: In-Reply-To: <4710EE91.8080305@yahoo.co.uk> References: <13157752.post@talk.nabble.com> <4710EE91.8080305@yahoo.co.uk> Message-ID: <6946B40A-CD2E-468E-AD35-B3CA9B33F8AF@iam.unibe.ch> > I notice that when using the magritte list composition tool > duplicates are allowed but it cant handle moving idividual items up > and down reliably. > > On investigation it appears that the reason is due to moveUp: and > moveDown: using indexOf: rather than identityIndexOf: > > I am not sure whether changing this behaviour would break other > things. I guess you are right, using #identityIndexOf: would be better. Please commit your change. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From girba at iam.unibe.ch Sat Oct 13 23:41:19 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Sat, 13 Oct 2007 23:41:19 +0200 Subject: Pier-All loading error Message-ID: <897DCA37-5918-432A-868D-6212D5FB75E8@iam.unibe.ch> Hi, I just tried to load Pier-All from http://source.lukas-renggli.ch/ pier/ in a fresh image, but I got the following loading error: ======================= This package depends on the following classes: WAUrl MAValidationError MATextInputComponent MAVisitor MACompatibility MAStringReader MADescription MAElementDescription MAComponent WAPresenter WARenderLoopMain WAFileLibrary WASystemConfiguration MAStringWriter WAAnchorTag You must resolve these dependencies before you will be able to load these definitions: MADescription>>beEditable MADescription>>beSearchable MADescription>>beSetting MADescription>>isEditable MADescription>>isSearchable MADescription>>isSetting MAStringReader>>visitStructureDescription: MAStringWriter>>visitStructureDescription: MAVisitor>>context MAVisitor>>context: MAVisitor>>visitStructureDescription: PBBlogHtmlView PBBlogHtmlView classSide>>isAbstract PBBlogHtmlView classSide>>isValidIn: PBBlogHtmlView>>batcher PBBlogHtmlView>>children PBBlogHtmlView>>findPosts PBBlogHtmlView>>posts PBBlogHtmlView>>renderBatcherOn: PBBlogHtmlView>>renderContentOn: PBBlogHtmlView>>tag PBBlogHtmlView>>tag: PBCommentsRssView PBCommentsRssView classSide>>isAbstract PBCommentsRssView classSide>>label PBCommentsRssView>>comments PBCommentsRssView>>findComments PBCommentsRssView>>renderComment:on: PBCommentsRssView>>renderRssOn: PBCommentsRssView>>title PBEntriesRssView PBEntriesRssView classSide>>isAbstract PBEntriesRssView classSide>>label PBEntriesRssView>>findPosts PBEntriesRssView>>posts PBEntriesRssView>>renderPost:on: PBEntriesRssView>>renderRssOn: PBHtmlView PBHtmlView classSide>>isAbstract PBHtmlView>>blog PBHtmlView>>renderAuthor:on: PBHtmlView>>renderComment:on: PBHtmlView>>renderLink:on: PBHtmlView>>renderMeta:on: PBHtmlView>>renderPost:on: PBHtmlView>>renderPosts:on: PBHtmlView>>renderPublication:on: PBHtmlView>>renderRssOn: PBHtmlView>>renderTags:on: PBHtmlView>>updateRoot: PBPostHtmlView PBPostHtmlView classSide>>isAbstract PBPostHtmlView classSide>>isValidIn: PBPostHtmlView>>buildCommand PBPostHtmlView>>buildComment PBPostHtmlView>>buildComponent PBPostHtmlView>>buildDescription PBPostHtmlView>>children PBPostHtmlView>>command PBPostHtmlView>>comment PBPostHtmlView>>comments PBPostHtmlView>>component PBPostHtmlView>>execute: PBPostHtmlView>>isCommentEnabled PBPostHtmlView>>post PBPostHtmlView>>renderComments:on: PBPostHtmlView>>renderContentOn: PBPostHtmlView>>renderLeaveCommentOn: PBPostTicker PBPostTicker classSide>>descriptionBlog PBPostTicker classSide>>descriptionNumberOfCharacters PBPostTicker classSide>>descriptionNumberOfPosts PBPostTicker classSide>>isAbstract PBPostTicker classSide>>label PBPostTicker>>blog PBPostTicker>>findPosts PBPostTicker>>numberOfCharacters PBPostTicker>>numberOfPosts PBPostTicker>>posts PBPostTicker>>renderContentOn: PBPostTicker>>renderPost:on: PBPostTicker>>summaryOf: PBRssView PBRssView classSide>>isAbstract PBRssView classSide>>isValidIn: PBRssView classSide>>label PBRssView classSide>>new PBRssView>>blog PBRssView>>link PBRssView>>renderDescription:on: PBRssView>>renderRssOn: PBRssView>>renderWithContext: PBRssView>>title PRAjaxSearchWidget PRAjaxSearchWidget classSide>>descriptionExampleText PRAjaxSearchWidget classSide>>label PRAjaxSearchWidget>>exampleText PRAjaxSearchWidget>>renderContentOn: PRAjaxSearchWidget>>renderItemsOn: PRAjaxSearchWidget>>selectionHandlerOn: PRBatcherWidget PRBatcherWidget classSide>>descriptionShowFirstLast PRBatcherWidget classSide>>descriptionShowNumbers PRBatcherWidget classSide>>descriptionShowPreviousNext PRBatcherWidget classSide>>isAbstract PRBatcherWidget classSide>>label PRBatcherWidget>>nextSibling PRBatcherWidget>>previousSibling PRBatcherWidget>>renderContentOn: PRBatcherWidget>>renderLabel:class:structure:on: PRBatcherWidget>>siblings PRChangesView PRChangesView classSide>>isAbstract PRChangesView classSide>>label PRChangesView>>buildList PRChangesView>>buildReport PRChildNotFoundError PRChildrenWidget PRChildrenWidget classSide>>defaultExpand PRChildrenWidget classSide>>defaultHighlight PRChildrenWidget classSide>>defaultLevel PRChildrenWidget classSide>>descriptionExpand PRChildrenWidget classSide>>descriptionLevel PRChildrenWidget classSide>>isAbstract PRChildrenWidget classSide>>label PRChildrenWidget>>expand PRChildrenWidget>>level PRChildrenWidget>>renderItem:on: PRChildrenWidget>>unfilteredItems PRCommandsWidget PRCommandsWidget classSide>>defaultCommandClasses PRCommandsWidget classSide>>descriptionCommandClasses PRCommandsWidget classSide>>isAbstract PRCommandsWidget classSide>>label PRCommandsWidget>>commandClasses PRCommandsWidget>>items PRCommandsWidget>>labelFor: PRCommandsWidget>>renderItem:on: PRCommandsWidget>>selected PRCompatibility PRCompatibility classSide>>hashPassword: PRConflictingNameError PRContentsWidget PRContentsWidget classSide>>defaultHeading PRContentsWidget classSide>>defaultTitle PRContentsWidget classSide>>descriptionHeading PRContentsWidget classSide>>descriptionTitle PRContentsWidget classSide>>isAbstract PRContentsWidget classSide>>label PRContentsWidget>>buildComponent: PRContentsWidget>>children PRContentsWidget>>component PRContentsWidget>>component: PRContentsWidget>>heading PRContentsWidget>>initialize PRContentsWidget>>onAnswerCommand: PRContentsWidget>>onChangeContext: PRContentsWidget>>renderContentOn: PRContentsWidget>>states PRContentsWidget>>title PRContentsWidget>>updateRoot: PRDecorationError PRDefaultView PRDefaultView classSide>>isAbstract PRDefaultView classSide>>label PRDefaultView>>name PRDefaultView>>render:on: PRDefaultView>>renderContentOn: PRDefaultView>>robots PRDownloadView PRDownloadView classSide>>isAbstract PRDownloadView classSide>>isValidIn: PRDownloadView classSide>>label PRDownloadView>>file PRDownloadView>>renderContentOn: PRHeaderWidget PRHeaderWidget classSide>>defaultCommandClasses PRHeaderWidget classSide>>defaultHeading PRHeaderWidget classSide>>descriptionHeading PRHeaderWidget classSide>>label PRHeaderWidget>>heading PRHeaderWidget>>renderContentOn: PRHeaderWidget>>renderItems:on: PRHeaderWidget>>renderLogoOn: PRHeaderWidget>>renderSpacerOn: PRHeaderWidget>>renderTabsOn: PRHeaderWidget>>renderTitleOn: PRHeaderWidget>>renderWidgetTitleOn: PRHistoryView PRHistoryView>>apply: PRHistoryView>>buildDescription PRHistoryView>>buildList PRHistoryView>>buildReport PRHistoryView>>children PRHistoryView>>open: PRHistoryView>>renderContentOn: PRHistoryView>>report PRHtmlWidget PRHtmlWidget classSide>>defaultText PRHtmlWidget classSide>>descriptionText PRHtmlWidget classSide>>isAbstract PRHtmlWidget classSide>>label PRHtmlWidget>>renderContentOn: PRHtmlWidget>>text PRInvalidKernelError PRInvalidNestingError PRInvalidNestingError classSide>>of:in: PRListWidget PRListWidget>>isActive: PRListWidget>>items PRListWidget>>labelFor: PRListWidget>>renderContentOn: PRListWidget>>renderItem:on: PRListWidget>>renderItems:on: PRListWidget>>selected PRLogView PRLogView classSide>>isAbstract PRLogView classSide>>label PRLogView>>buildList PRNavigationWidget PRNavigationWidget classSide>>isAbstract PRNavigationWidget classSide>>label PRNavigationWidget>>renderContentOn: PRNavigationWidget>>renderParents:on: PRPathWidget PRPathWidget classSide>>defaultAllButLast PRPathWidget classSide>>defaultHighlight PRPathWidget classSide>>descriptionAllButLast PRPathWidget classSide>>isAbstract PRPathWidget classSide>>label PRPathWidget>>allButLast PRPathWidget>>unfilteredItems PRPersistencyError PRPierConfiguration PRPierConfiguration>>ancestors PRPierConfiguration>>attributeKernel PRPierConfiguration>>attributes PRPierConfiguration>>mainClass PRPierConfiguration>>rootComponent PRPierConfiguration>>sessionExpirySeconds PRPierFrame PRPierFrame classSide>>applicationNamed: PRPierFrame classSide>>canBeRoot PRPierFrame classSide>>description PRPierFrame classSide>>exampleBasic PRPierFrame classSide>>exampleDocs PRPierFrame classSide>>initialize PRPierFrame classSide>>isAbstract PRPierFrame classSide>>on: PRPierFrame classSide>>pageForClass: PRPierFrame classSide>>registerAsApplication:kernel: PRPierFrame>>buildChildren PRPierFrame>>children PRPierFrame>>componentsOf: PRPierFrame>>context PRPierFrame>>context: PRPierFrame>>environment PRPierFrame>>forbiddenRequest: PRPierFrame>>processCallbackStream: PRPierFrame>>renderContentOn: PRPierFrame>>renderWithContext: PRPierFrame>>states PRPierFrame>>structure PRPierFrame>>update PRPierFrame>>updateRoot: PRPierFrame>>updateUrl: PRPierFrame>>withContextDo: PRPierLibrary PRPierLibrary>>basicCss PRPierLibrary>>boxBottomLeftPng PRPierLibrary>>boxBottomRightPng PRPierLibrary>>boxContentsPng PRPierLibrary>>boxCss PRPierLibrary>>boxTopLeftPng PRPierLibrary>>boxTopRightPng PRPierLibrary>>contentsCss PRPierLibrary>>headerLogoPng PRPierLibrary>>headerTabsPng PRPierLibrary>>headerTitleLeftPng PRPierLibrary>>headerTitlePng PRPierLibrary>>headerTitleRightPng PRPierLibrary>>layoutCss PRPierLibrary>>selectorsToInclude PRPierLibrary>>styleCss PRPierMain PRPierMain classSide>>classFromRequest:name:base: PRPierMain>>commandFrom: PRPierMain>>context PRPierMain>>context: PRPierMain>>createRoot PRPierMain>>dispatcher PRPierMain>>forbidden: PRPierMain>>invalidDispatcher: PRPierMain>>kernel PRPierMain>>notFound: PRPierMain>>return: PRPierMain>>start: PRPierMain>>structureFrom: PRPlainView PRPlainView classSide>>isAbstract PRPlainView classSide>>isValidIn: PRPlainView classSide>>label PRPlainView>>renderContentOn: PRRawView PRRawView>>renderWithContext: PRReferencesWidget PRReferencesWidget classSide>>defaultHighlight PRReferencesWidget classSide>>defaultMaxItems PRReferencesWidget classSide>>isAbstract PRReferencesWidget classSide>>label PRReferencesWidget>>unfilteredItems PRReportView PRReportView classSide>>isAbstract PRReportView classSide>>label PRReportView>>buildDescription PRReportView>>buildReport PRReportView>>buildStructures PRReportView>>children PRReportView>>description PRReportView>>renderContentOn: PRReportView>>report PRReportView>>structures PRSearchWidget PRSearchWidget classSide>>defaultHighlight PRSearchWidget classSide>>defaultMaxItems PRSearchWidget classSide>>descriptionDropdownList PRSearchWidget classSide>>isAbstract PRSearchWidget classSide>>label PRSearchWidget>>dropdownList PRSearchWidget>>findItems PRSearchWidget>>renderContentOn: PRSearchWidget>>searchText PRSearchWidget>>searchText: PRSearchWidget>>unfilteredItems PRStructureComponent PRStructureComponent>>choose PRStructureComponent>>renderEditorOn: PRStructureDescription PRStructureDescription classSide>>defaultComponentClasses PRStructureDescription classSide>>isAbstract PRStructureDescription classSide>>label PRStructureDescription>>acceptMagritte: PRStructureDescription>>kind PRStructureError PRStructureError classSide>>structure: PRStructureError>>setStructure: PRStructureError>>structure PRStructuresWidget PRStructuresWidget classSide>>defaultDropdownList PRStructuresWidget classSide>>defaultFilter PRStructuresWidget classSide>>defaultHighlight PRStructuresWidget classSide>>defaultHighlightPath PRStructuresWidget classSide>>defaultLabel PRStructuresWidget classSide>>defaultLabels PRStructuresWidget classSide>>defaultMaxItems PRStructuresWidget classSide>>descriptionDropdownList PRStructuresWidget classSide>>descriptionFilter PRStructuresWidget classSide>>descriptionHighlight PRStructuresWidget classSide>>descriptionHighlightPath PRStructuresWidget classSide>>descriptionLabel PRStructuresWidget classSide>>descriptionMaxItems PRStructuresWidget>>childrenOf: PRStructuresWidget>>dropdownList PRStructuresWidget>>filter PRStructuresWidget>>highlight PRStructuresWidget>>highlightPath PRStructuresWidget>>isActive: PRStructuresWidget>>isFiltered: PRStructuresWidget>>items PRStructuresWidget>>label PRStructuresWidget>>labelFor: PRStructuresWidget>>maxItems PRStructuresWidget>>renderContentOn: PRStructuresWidget>>renderItem:on: PRStructuresWidget>>renderSelect:on: PRStructuresWidget>>selected PRStructuresWidget>>unfilteredItems PRTocWidget PRTocWidget classSide>>isAbstract PRTocWidget classSide>>label PRTocWidget>>renderContentOn: PRTreeWidget PRTreeWidget classSide>>defaultAutoCollapse PRTreeWidget classSide>>defaultAutoExpand PRTreeWidget classSide>>descriptionAutoCollapse PRTreeWidget classSide>>descriptionAutoExpand PRTreeWidget classSide>>descriptionDropdownList PRTreeWidget classSide>>isAbstract PRTreeWidget classSide>>label PRTreeWidget>>autoCollapse PRTreeWidget>>autoExpand PRTreeWidget>>collapseStructure: PRTreeWidget>>dropdownList PRTreeWidget>>expandStructure: PRTreeWidget>>initialize PRTreeWidget>>isExpanded: PRTreeWidget>>onChangeContext: PRTreeWidget>>renderContentOn: PRTreeWidget>>renderStructure:on: PRTreeWidget>>renderStructureButton:on: PRTreeWidget>>renderStructureChildren:on: PRTreeWidget>>renderStructureLabel:on: PRTreeWidget>>states PRTreeWidget>>unfilteredItems PRViewComponent PRViewComponent classSide>>isValidIn: PRViewComponent classSide>>on: PRViewComponent>>context PRViewComponent>>cssClass PRViewComponent>>find: PRViewComponent>>name PRViewComponent>>renderContentOn: PRViewComponent>>robots PRViewComponent>>setContext: PRViewComponent>>updateRoot: PRViewsWidget PRViewsWidget classSide>>defaultViewClasses PRViewsWidget classSide>>descriptionViewClasses PRViewsWidget classSide>>isAbstract PRViewsWidget classSide>>label PRViewsWidget>>items PRViewsWidget>>labelFor: PRViewsWidget>>renderItem:on: PRViewsWidget>>selected PRViewsWidget>>viewClasses PRWidget PRWidget>>context PRWidget>>expand: PRWidget>>expand:in: PRWidget>>initialize PRWidget>>isSuperuser PRWidget>>onChangeContext: PRWidget>>properties PRWidget>>propertyAt: PRWidget>>propertyAt:ifAbsent: PRWidget>>propertyAt:ifAbsentPut: PRWidget>>propertyAt:put: PRWidget>>read: PRWidget>>readUsing: PRWidget>>renderContentOn: PRWidget>>write:using: PRWikiView PRWikiView classSide>>isAbstract PRWikiView classSide>>isValidIn: PRWikiView classSide>>label PRWikiView>>renderContentOn: PUBrowseComponent PUBrowseComponent classSide>>isAbstract PUBrowseComponent classSide>>label PUBrowseComponent>>defaultPermissions PUBrowseComponent>>execute:on: PUBrowseComponent>>initialize PUBrowseComponent>>permissions PUBrowseComponent>>renderContentOn: PUBrowseComponent>>renderPathOn: PUBrowseComponent>>renderPermissions:permissions:on: PUBrowseComponent>>renderTableHeadOn: PUBrowseComponent>>renderTableOn: PUBrowseComponent>>renderTableRow:named:on: PUBrowseComponent>>structure PUGroupsWidget PUGroupsWidget classSide>>isAbstract PUGroupsWidget classSide>>label PUGroupsWidget>>memberClass PUGroupsWidget>>members PUGroupsWidget>>remove: PUInvalidLogin PUMemberWidget PUMemberWidget>>add: PUMemberWidget>>buildReport PUMemberWidget>>children PUMemberWidget>>edit: PUMemberWidget>>edit:title: PUMemberWidget>>memberClass PUMemberWidget>>members PUMemberWidget>>onChangeContext: PUMemberWidget>>refresh PUMemberWidget>>remove: PUMemberWidget>>renderAddOn: PUMemberWidget>>renderContentOn: PUMemberWidget>>renderReportOn: PUMemberWidget>>report PUPierMain PUPierMain>>forbidden: PUSecurityWidget PUSecurityWidget classSide>>isAbstract PUSecurityWidget classSide>>label PUSecurityWidget>>editUser PUSecurityWidget>>renderContentOn: PUSecurityWidget>>renderEditUserOn: PUSecurityWidget>>renderGroupsOn: PUSecurityWidget>>renderUserOn: PUSystemWidget PUSystemWidget classSide>>isAbstract PUSystemWidget classSide>>label PUSystemWidget>>persistency PUSystemWidget>>renderActionsOn: PUSystemWidget>>renderContentOn: PUUsersWidget PUUsersWidget classSide>>isAbstract PUUsersWidget classSide>>label PUUsersWidget>>memberClass PUUsersWidget>>members PUUsersWidget>>remove: WAAnchorTag>>goto: WAPresenter>>context WAPresenter>>context: WAPresenter>>onChangeContext: WAUrl>>adaptToContext: WAUrl>>purgeSeasideFields Select Proceed to continue, or close this window to cancel the operation. ======================= -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Be rather willing to give than demanding to get." From tournesolo at gmail.com Sun Oct 14 01:15:51 2007 From: tournesolo at gmail.com (tournesolo@gmail.com) Date: Sun, 14 Oct 2007 01:15:51 +0200 Subject: conditionally showing a widget? Message-ID: <20071013231551.GD30517@e2011> hi - How does one make a widget appear only if a certain user is logged in? How would one for instance make the 'views' box appear only if the admin user is logged in? (Is there a place I could have found the answer? I read the docs I found and browsed the archives, but didn't find anything. I'm working my way to the relevant place in the code, but a nudge would be useful.) thanks, ts From girba at iam.unibe.ch Sun Oct 14 10:02:37 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Sun, 14 Oct 2007 10:02:37 +0200 Subject: conditionally showing a widget? In-Reply-To: <20071013231551.GD30517@e2011> References: <20071013231551.GD30517@e2011> Message-ID: <1E6C384C-C898-4687-8152-A6D3D194071A@iam.unibe.ch> Hi, First make sure you have an add-on to Pier that allows you to manage users. I use Pier Unix Security (you can load it from Squeak Map and it will load Pier as well). When it comes to rights, pages and components are similar. Here is one solution I used for a similar problem: - Load Pier Unix Security from Squeak Map. - Add System page as child of the root. I named it =System to make it appear first in the list of pages. - Add System Users component as child of the =System page. - Add System Groups component as child of the =System page. - Add a user that is in the admin group (or just use the default admin user). - Go to the root page, select Change Owner command, check the Recursively check box to affect all pages, and change the owner to be the admin user. - Go to the pages you do not want the others to see, and using the Change Other command remove the View ability. You can also play with groups, by making the page belong to a certain group and then place the wanted users in that group. Cheers, Doru On Oct 14, 2007, at 1:15 AM, tournesolo at gmail.com wrote: > > hi - > > How does one make a widget appear only if a certain user is logged in? > How would one for instance make the 'views' box appear only if the > admin user is logged in? > > (Is there a place I could have found the answer? I read the docs I > found and browsed the archives, but didn't find anything. I'm working > my way to the relevant place in the code, but a nudge would be > useful.) > > thanks, > ts > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Sometimes the best solution is not the best solution." From renggli at iam.unibe.ch Sun Oct 14 10:11:54 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 14 Oct 2007 10:11:54 +0200 Subject: Pier-All loading error In-Reply-To: <897DCA37-5918-432A-868D-6212D5FB75E8@iam.unibe.ch> References: <897DCA37-5918-432A-868D-6212D5FB75E8@iam.unibe.ch> Message-ID: <84EA546F-6113-4754-82F0-7633446C21A0@iam.unibe.ch> You need to load several prerequisites first: Kom http://www.squeaksource.com/KomWebServer Seaside, Scriptaculous http://www.squeaksource.com/Seaside Magritte http://source.lukas-renggli.ch/magritte You are not required to load Kom and Seaside to have a working Pier, but then you should only load Pier-Model, Magritte-Model. So all in all the dependencies are a bit more complicated. You should get a minimal working version when using the Package Universe, there all these dependencies are properly modelled. HTH, Lukas On 13 Oct 2007, at 23:41, Tudor Girba wrote: > Hi, > > I just tried to load Pier-All from http://source.lukas-renggli.ch/ > pier/ in a fresh image, but I got the following loading error: > > ======================= > > This package depends on the following classes: > WAUrl > MAValidationError > MATextInputComponent > MAVisitor > MACompatibility > MAStringReader > MADescription > MAElementDescription > MAComponent > WAPresenter > WARenderLoopMain > WAFileLibrary > WASystemConfiguration > MAStringWriter > WAAnchorTag > You must resolve these dependencies before you will be able to load > these definitions: > MADescription>>beEditable > MADescription>>beSearchable > MADescription>>beSetting > MADescription>>isEditable > MADescription>>isSearchable > MADescription>>isSetting > MAStringReader>>visitStructureDescription: > MAStringWriter>>visitStructureDescription: > MAVisitor>>context > MAVisitor>>context: > MAVisitor>>visitStructureDescription: > PBBlogHtmlView > PBBlogHtmlView classSide>>isAbstract > PBBlogHtmlView classSide>>isValidIn: > PBBlogHtmlView>>batcher > PBBlogHtmlView>>children > PBBlogHtmlView>>findPosts > PBBlogHtmlView>>posts > PBBlogHtmlView>>renderBatcherOn: > PBBlogHtmlView>>renderContentOn: > PBBlogHtmlView>>tag > PBBlogHtmlView>>tag: > PBCommentsRssView > PBCommentsRssView classSide>>isAbstract > PBCommentsRssView classSide>>label > PBCommentsRssView>>comments > PBCommentsRssView>>findComments > PBCommentsRssView>>renderComment:on: > PBCommentsRssView>>renderRssOn: > PBCommentsRssView>>title > PBEntriesRssView > PBEntriesRssView classSide>>isAbstract > PBEntriesRssView classSide>>label > PBEntriesRssView>>findPosts > PBEntriesRssView>>posts > PBEntriesRssView>>renderPost:on: > PBEntriesRssView>>renderRssOn: > PBHtmlView > PBHtmlView classSide>>isAbstract > PBHtmlView>>blog > PBHtmlView>>renderAuthor:on: > PBHtmlView>>renderComment:on: > PBHtmlView>>renderLink:on: > PBHtmlView>>renderMeta:on: > PBHtmlView>>renderPost:on: > PBHtmlView>>renderPosts:on: > PBHtmlView>>renderPublication:on: > PBHtmlView>>renderRssOn: > PBHtmlView>>renderTags:on: > PBHtmlView>>updateRoot: > PBPostHtmlView > PBPostHtmlView classSide>>isAbstract > PBPostHtmlView classSide>>isValidIn: > PBPostHtmlView>>buildCommand > PBPostHtmlView>>buildComment > PBPostHtmlView>>buildComponent > PBPostHtmlView>>buildDescription > PBPostHtmlView>>children > PBPostHtmlView>>command > PBPostHtmlView>>comment > PBPostHtmlView>>comments > PBPostHtmlView>>component > PBPostHtmlView>>execute: > PBPostHtmlView>>isCommentEnabled > PBPostHtmlView>>post > PBPostHtmlView>>renderComments:on: > PBPostHtmlView>>renderContentOn: > PBPostHtmlView>>renderLeaveCommentOn: > PBPostTicker > PBPostTicker classSide>>descriptionBlog > PBPostTicker classSide>>descriptionNumberOfCharacters > PBPostTicker classSide>>descriptionNumberOfPosts > PBPostTicker classSide>>isAbstract > PBPostTicker classSide>>label > PBPostTicker>>blog > PBPostTicker>>findPosts > PBPostTicker>>numberOfCharacters > PBPostTicker>>numberOfPosts > PBPostTicker>>posts > PBPostTicker>>renderContentOn: > PBPostTicker>>renderPost:on: > PBPostTicker>>summaryOf: > PBRssView > PBRssView classSide>>isAbstract > PBRssView classSide>>isValidIn: > PBRssView classSide>>label > PBRssView classSide>>new > PBRssView>>blog > PBRssView>>link > PBRssView>>renderDescription:on: > PBRssView>>renderRssOn: > PBRssView>>renderWithContext: > PBRssView>>title > PRAjaxSearchWidget > PRAjaxSearchWidget classSide>>descriptionExampleText > PRAjaxSearchWidget classSide>>label > PRAjaxSearchWidget>>exampleText > PRAjaxSearchWidget>>renderContentOn: > PRAjaxSearchWidget>>renderItemsOn: > PRAjaxSearchWidget>>selectionHandlerOn: > PRBatcherWidget > PRBatcherWidget classSide>>descriptionShowFirstLast > PRBatcherWidget classSide>>descriptionShowNumbers > PRBatcherWidget classSide>>descriptionShowPreviousNext > PRBatcherWidget classSide>>isAbstract > PRBatcherWidget classSide>>label > PRBatcherWidget>>nextSibling > PRBatcherWidget>>previousSibling > PRBatcherWidget>>renderContentOn: > PRBatcherWidget>>renderLabel:class:structure:on: > PRBatcherWidget>>siblings > PRChangesView > PRChangesView classSide>>isAbstract > PRChangesView classSide>>label > PRChangesView>>buildList > PRChangesView>>buildReport > PRChildNotFoundError > PRChildrenWidget > PRChildrenWidget classSide>>defaultExpand > PRChildrenWidget classSide>>defaultHighlight > PRChildrenWidget classSide>>defaultLevel > PRChildrenWidget classSide>>descriptionExpand > PRChildrenWidget classSide>>descriptionLevel > PRChildrenWidget classSide>>isAbstract > PRChildrenWidget classSide>>label > PRChildrenWidget>>expand > PRChildrenWidget>>level > PRChildrenWidget>>renderItem:on: > PRChildrenWidget>>unfilteredItems > PRCommandsWidget > PRCommandsWidget classSide>>defaultCommandClasses > PRCommandsWidget classSide>>descriptionCommandClasses > PRCommandsWidget classSide>>isAbstract > PRCommandsWidget classSide>>label > PRCommandsWidget>>commandClasses > PRCommandsWidget>>items > PRCommandsWidget>>labelFor: > PRCommandsWidget>>renderItem:on: > PRCommandsWidget>>selected > PRCompatibility > PRCompatibility classSide>>hashPassword: > PRConflictingNameError > PRContentsWidget > PRContentsWidget classSide>>defaultHeading > PRContentsWidget classSide>>defaultTitle > PRContentsWidget classSide>>descriptionHeading > PRContentsWidget classSide>>descriptionTitle > PRContentsWidget classSide>>isAbstract > PRContentsWidget classSide>>label > PRContentsWidget>>buildComponent: > PRContentsWidget>>children > PRContentsWidget>>component > PRContentsWidget>>component: > PRContentsWidget>>heading > PRContentsWidget>>initialize > PRContentsWidget>>onAnswerCommand: > PRContentsWidget>>onChangeContext: > PRContentsWidget>>renderContentOn: > PRContentsWidget>>states > PRContentsWidget>>title > PRContentsWidget>>updateRoot: > PRDecorationError > PRDefaultView > PRDefaultView classSide>>isAbstract > PRDefaultView classSide>>label > PRDefaultView>>name > PRDefaultView>>render:on: > PRDefaultView>>renderContentOn: > PRDefaultView>>robots > PRDownloadView > PRDownloadView classSide>>isAbstract > PRDownloadView classSide>>isValidIn: > PRDownloadView classSide>>label > PRDownloadView>>file > PRDownloadView>>renderContentOn: > PRHeaderWidget > PRHeaderWidget classSide>>defaultCommandClasses > PRHeaderWidget classSide>>defaultHeading > PRHeaderWidget classSide>>descriptionHeading > PRHeaderWidget classSide>>label > PRHeaderWidget>>heading > PRHeaderWidget>>renderContentOn: > PRHeaderWidget>>renderItems:on: > PRHeaderWidget>>renderLogoOn: > PRHeaderWidget>>renderSpacerOn: > PRHeaderWidget>>renderTabsOn: > PRHeaderWidget>>renderTitleOn: > PRHeaderWidget>>renderWidgetTitleOn: > PRHistoryView > PRHistoryView>>apply: > PRHistoryView>>buildDescription > PRHistoryView>>buildList > PRHistoryView>>buildReport > PRHistoryView>>children > PRHistoryView>>open: > PRHistoryView>>renderContentOn: > PRHistoryView>>report > PRHtmlWidget > PRHtmlWidget classSide>>defaultText > PRHtmlWidget classSide>>descriptionText > PRHtmlWidget classSide>>isAbstract > PRHtmlWidget classSide>>label > PRHtmlWidget>>renderContentOn: > PRHtmlWidget>>text > PRInvalidKernelError > PRInvalidNestingError > PRInvalidNestingError classSide>>of:in: > PRListWidget > PRListWidget>>isActive: > PRListWidget>>items > PRListWidget>>labelFor: > PRListWidget>>renderContentOn: > PRListWidget>>renderItem:on: > PRListWidget>>renderItems:on: > PRListWidget>>selected > PRLogView > PRLogView classSide>>isAbstract > PRLogView classSide>>label > PRLogView>>buildList > PRNavigationWidget > PRNavigationWidget classSide>>isAbstract > PRNavigationWidget classSide>>label > PRNavigationWidget>>renderContentOn: > PRNavigationWidget>>renderParents:on: > PRPathWidget > PRPathWidget classSide>>defaultAllButLast > PRPathWidget classSide>>defaultHighlight > PRPathWidget classSide>>descriptionAllButLast > PRPathWidget classSide>>isAbstract > PRPathWidget classSide>>label > PRPathWidget>>allButLast > PRPathWidget>>unfilteredItems > PRPersistencyError > PRPierConfiguration > PRPierConfiguration>>ancestors > PRPierConfiguration>>attributeKernel > PRPierConfiguration>>attributes > PRPierConfiguration>>mainClass > PRPierConfiguration>>rootComponent > PRPierConfiguration>>sessionExpirySeconds > PRPierFrame > PRPierFrame classSide>>applicationNamed: > PRPierFrame classSide>>canBeRoot > PRPierFrame classSide>>description > PRPierFrame classSide>>exampleBasic > PRPierFrame classSide>>exampleDocs > PRPierFrame classSide>>initialize > PRPierFrame classSide>>isAbstract > PRPierFrame classSide>>on: > PRPierFrame classSide>>pageForClass: > PRPierFrame classSide>>registerAsApplication:kernel: > PRPierFrame>>buildChildren > PRPierFrame>>children > PRPierFrame>>componentsOf: > PRPierFrame>>context > PRPierFrame>>context: > PRPierFrame>>environment > PRPierFrame>>forbiddenRequest: > PRPierFrame>>processCallbackStream: > PRPierFrame>>renderContentOn: > PRPierFrame>>renderWithContext: > PRPierFrame>>states > PRPierFrame>>structure > PRPierFrame>>update > PRPierFrame>>updateRoot: > PRPierFrame>>updateUrl: > PRPierFrame>>withContextDo: > PRPierLibrary > PRPierLibrary>>basicCss > PRPierLibrary>>boxBottomLeftPng > PRPierLibrary>>boxBottomRightPng > PRPierLibrary>>boxContentsPng > PRPierLibrary>>boxCss > PRPierLibrary>>boxTopLeftPng > PRPierLibrary>>boxTopRightPng > PRPierLibrary>>contentsCss > PRPierLibrary>>headerLogoPng > PRPierLibrary>>headerTabsPng > PRPierLibrary>>headerTitleLeftPng > PRPierLibrary>>headerTitlePng > PRPierLibrary>>headerTitleRightPng > PRPierLibrary>>layoutCss > PRPierLibrary>>selectorsToInclude > PRPierLibrary>>styleCss > PRPierMain > PRPierMain classSide>>classFromRequest:name:base: > PRPierMain>>commandFrom: > PRPierMain>>context > PRPierMain>>context: > PRPierMain>>createRoot > PRPierMain>>dispatcher > PRPierMain>>forbidden: > PRPierMain>>invalidDispatcher: > PRPierMain>>kernel > PRPierMain>>notFound: > PRPierMain>>return: > PRPierMain>>start: > PRPierMain>>structureFrom: > PRPlainView > PRPlainView classSide>>isAbstract > PRPlainView classSide>>isValidIn: > PRPlainView classSide>>label > PRPlainView>>renderContentOn: > PRRawView > PRRawView>>renderWithContext: > PRReferencesWidget > PRReferencesWidget classSide>>defaultHighlight > PRReferencesWidget classSide>>defaultMaxItems > PRReferencesWidget classSide>>isAbstract > PRReferencesWidget classSide>>label > PRReferencesWidget>>unfilteredItems > PRReportView > PRReportView classSide>>isAbstract > PRReportView classSide>>label > PRReportView>>buildDescription > PRReportView>>buildReport > PRReportView>>buildStructures > PRReportView>>children > PRReportView>>description > PRReportView>>renderContentOn: > PRReportView>>report > PRReportView>>structures > PRSearchWidget > PRSearchWidget classSide>>defaultHighlight > PRSearchWidget classSide>>defaultMaxItems > PRSearchWidget classSide>>descriptionDropdownList > PRSearchWidget classSide>>isAbstract > PRSearchWidget classSide>>label > PRSearchWidget>>dropdownList > PRSearchWidget>>findItems > PRSearchWidget>>renderContentOn: > PRSearchWidget>>searchText > PRSearchWidget>>searchText: > PRSearchWidget>>unfilteredItems > PRStructureComponent > PRStructureComponent>>choose > PRStructureComponent>>renderEditorOn: > PRStructureDescription > PRStructureDescription classSide>>defaultComponentClasses > PRStructureDescription classSide>>isAbstract > PRStructureDescription classSide>>label > PRStructureDescription>>acceptMagritte: > PRStructureDescription>>kind > PRStructureError > PRStructureError classSide>>structure: > PRStructureError>>setStructure: > PRStructureError>>structure > PRStructuresWidget > PRStructuresWidget classSide>>defaultDropdownList > PRStructuresWidget classSide>>defaultFilter > PRStructuresWidget classSide>>defaultHighlight > PRStructuresWidget classSide>>defaultHighlightPath > PRStructuresWidget classSide>>defaultLabel > PRStructuresWidget classSide>>defaultLabels > PRStructuresWidget classSide>>defaultMaxItems > PRStructuresWidget classSide>>descriptionDropdownList > PRStructuresWidget classSide>>descriptionFilter > PRStructuresWidget classSide>>descriptionHighlight > PRStructuresWidget classSide>>descriptionHighlightPath > PRStructuresWidget classSide>>descriptionLabel > PRStructuresWidget classSide>>descriptionMaxItems > PRStructuresWidget>>childrenOf: > PRStructuresWidget>>dropdownList > PRStructuresWidget>>filter > PRStructuresWidget>>highlight > PRStructuresWidget>>highlightPath > PRStructuresWidget>>isActive: > PRStructuresWidget>>isFiltered: > PRStructuresWidget>>items > PRStructuresWidget>>label > PRStructuresWidget>>labelFor: > PRStructuresWidget>>maxItems > PRStructuresWidget>>renderContentOn: > PRStructuresWidget>>renderItem:on: > PRStructuresWidget>>renderSelect:on: > PRStructuresWidget>>selected > PRStructuresWidget>>unfilteredItems > PRTocWidget > PRTocWidget classSide>>isAbstract > PRTocWidget classSide>>label > PRTocWidget>>renderContentOn: > PRTreeWidget > PRTreeWidget classSide>>defaultAutoCollapse > PRTreeWidget classSide>>defaultAutoExpand > PRTreeWidget classSide>>descriptionAutoCollapse > PRTreeWidget classSide>>descriptionAutoExpand > PRTreeWidget classSide>>descriptionDropdownList > PRTreeWidget classSide>>isAbstract > PRTreeWidget classSide>>label > PRTreeWidget>>autoCollapse > PRTreeWidget>>autoExpand > PRTreeWidget>>collapseStructure: > PRTreeWidget>>dropdownList > PRTreeWidget>>expandStructure: > PRTreeWidget>>initialize > PRTreeWidget>>isExpanded: > PRTreeWidget>>onChangeContext: > PRTreeWidget>>renderContentOn: > PRTreeWidget>>renderStructure:on: > PRTreeWidget>>renderStructureButton:on: > PRTreeWidget>>renderStructureChildren:on: > PRTreeWidget>>renderStructureLabel:on: > PRTreeWidget>>states > PRTreeWidget>>unfilteredItems > PRViewComponent > PRViewComponent classSide>>isValidIn: > PRViewComponent classSide>>on: > PRViewComponent>>context > PRViewComponent>>cssClass > PRViewComponent>>find: > PRViewComponent>>name > PRViewComponent>>renderContentOn: > PRViewComponent>>robots > PRViewComponent>>setContext: > PRViewComponent>>updateRoot: > PRViewsWidget > PRViewsWidget classSide>>defaultViewClasses > PRViewsWidget classSide>>descriptionViewClasses > PRViewsWidget classSide>>isAbstract > PRViewsWidget classSide>>label > PRViewsWidget>>items > PRViewsWidget>>labelFor: > PRViewsWidget>>renderItem:on: > PRViewsWidget>>selected > PRViewsWidget>>viewClasses > PRWidget > PRWidget>>context > PRWidget>>expand: > PRWidget>>expand:in: > PRWidget>>initialize > PRWidget>>isSuperuser > PRWidget>>onChangeContext: > PRWidget>>properties > PRWidget>>propertyAt: > PRWidget>>propertyAt:ifAbsent: > PRWidget>>propertyAt:ifAbsentPut: > PRWidget>>propertyAt:put: > PRWidget>>read: > PRWidget>>readUsing: > PRWidget>>renderContentOn: > PRWidget>>write:using: > PRWikiView > PRWikiView classSide>>isAbstract > PRWikiView classSide>>isValidIn: > PRWikiView classSide>>label > PRWikiView>>renderContentOn: > PUBrowseComponent > PUBrowseComponent classSide>>isAbstract > PUBrowseComponent classSide>>label > PUBrowseComponent>>defaultPermissions > PUBrowseComponent>>execute:on: > PUBrowseComponent>>initialize > PUBrowseComponent>>permissions > PUBrowseComponent>>renderContentOn: > PUBrowseComponent>>renderPathOn: > PUBrowseComponent>>renderPermissions:permissions:on: > PUBrowseComponent>>renderTableHeadOn: > PUBrowseComponent>>renderTableOn: > PUBrowseComponent>>renderTableRow:named:on: > PUBrowseComponent>>structure > PUGroupsWidget > PUGroupsWidget classSide>>isAbstract > PUGroupsWidget classSide>>label > PUGroupsWidget>>memberClass > PUGroupsWidget>>members > PUGroupsWidget>>remove: > PUInvalidLogin > PUMemberWidget > PUMemberWidget>>add: > PUMemberWidget>>buildReport > PUMemberWidget>>children > PUMemberWidget>>edit: > PUMemberWidget>>edit:title: > PUMemberWidget>>memberClass > PUMemberWidget>>members > PUMemberWidget>>onChangeContext: > PUMemberWidget>>refresh > PUMemberWidget>>remove: > PUMemberWidget>>renderAddOn: > PUMemberWidget>>renderContentOn: > PUMemberWidget>>renderReportOn: > PUMemberWidget>>report > PUPierMain > PUPierMain>>forbidden: > PUSecurityWidget > PUSecurityWidget classSide>>isAbstract > PUSecurityWidget classSide>>label > PUSecurityWidget>>editUser > PUSecurityWidget>>renderContentOn: > PUSecurityWidget>>renderEditUserOn: > PUSecurityWidget>>renderGroupsOn: > PUSecurityWidget>>renderUserOn: > PUSystemWidget > PUSystemWidget classSide>>isAbstract > PUSystemWidget classSide>>label > PUSystemWidget>>persistency > PUSystemWidget>>renderActionsOn: > PUSystemWidget>>renderContentOn: > PUUsersWidget > PUUsersWidget classSide>>isAbstract > PUUsersWidget classSide>>label > PUUsersWidget>>memberClass > PUUsersWidget>>members > PUUsersWidget>>remove: > WAAnchorTag>>goto: > WAPresenter>>context > WAPresenter>>context: > WAPresenter>>onChangeContext: > WAUrl>>adaptToContext: > WAUrl>>purgeSeasideFields > > Select Proceed to continue, or close this window to cancel the > operation. > > ======================= > > -- > www.iam.unibe.ch/~girba > www.iam.unibe.ch/~girba/blog/ > > "Be rather willing to give than demanding to get." > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From tournesolo at gmail.com Sun Oct 14 12:55:17 2007 From: tournesolo at gmail.com (tournesolo@gmail.com) Date: Sun, 14 Oct 2007 12:55:17 +0200 Subject: conditionally showing a widget? In-Reply-To: <1E6C384C-C898-4687-8152-A6D3D194071A@iam.unibe.ch> References: <20071013231551.GD30517@e2011> <1E6C384C-C898-4687-8152-A6D3D194071A@iam.unibe.ch> Message-ID: <20071014105517.GE30517@e2011> Thanks Tudor - but that doesn't work, or rather it doesn't do what I wanted. I already have the unix security installed and setup, but if you make the ('views') component visible only to admin, Pier still shows the box corresponding to the widget, with its title but no commands/views in it (try it!). What I want on the other hand is that the whole widget is absent (since it is empty of functionality now) unless the admin user is logged in. So the question stands: how do I conditionally show a widget such as the commands or views widget in the main environment? Michal From girba at iam.unibe.ch Sun Oct 14 14:43:47 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Sun, 14 Oct 2007 14:43:47 +0200 Subject: conditionally showing a widget? In-Reply-To: <20071014105517.GE30517@e2011> References: <20071013231551.GD30517@e2011> <1E6C384C-C898-4687-8152-A6D3D194071A@iam.unibe.ch> <20071014105517.GE30517@e2011> Message-ID: <1B33C461-E347-455E-B1DA-F6A40798C265@iam.unibe.ch> Hi, The reason for that is that you wrap the Views command with a div, and that div is not affected by the rights of the inner component/ page. For example, by default in Pier you get in the Environment page:

Views

+views+
If you want to control the visibility of the surrounding div as well, you can just create a page with only the above content, include the page in the Environment without any surrounding div and then give the page the wanted rights. Cheers, Doru On Oct 14, 2007, at 12:55 PM, tournesolo at gmail.com wrote: > Thanks Tudor - but that doesn't work, or rather it doesn't do what I > wanted. > > I already have the unix security installed and setup, but if you make > the ('views') component visible only to admin, Pier still shows the > box corresponding to the widget, with its title but no commands/views > in it (try it!). What I want on the other hand is that the whole > widget is absent (since it is empty of functionality now) unless the > admin user is logged in. > > So the question stands: how do I conditionally show a widget such as > the commands or views widget in the main environment? > > Michal > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Problem solving efficiency grows with the abstractness level of problem understanding." From keith_hodges at yahoo.co.uk Mon Oct 15 02:27:31 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 15 Oct 2007 01:27:31 +0100 Subject: MANullAccessor Message-ID: <4712B3F3.1050603@yahoo.co.uk> Does MANullAccessor have to be so so... erm unusable? If you happen to use it nothing seems to work with it. i.e. accessor selector doesnt work, one should argue that it shouldnt, but is it doing a good job of being a null? Most users of read: dont test canRead: first. I am thinking of implementing a subclass MADummyAccessor which does implement read: just so as it can play with the other accessors in mementos etc. I just wondered if there was a case for making MANullAccessor more friendly, i.e. swap its behaviour from pessimistic to optimistic, rather than expecting all users to test canRead: first, expect those users that really care to test cantRead: just an idea Keith From renggli at iam.unibe.ch Mon Oct 15 07:24:04 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 15 Oct 2007 07:24:04 +0200 Subject: MANullAccessor In-Reply-To: <4712B3F3.1050603@yahoo.co.uk> References: <4712B3F3.1050603@yahoo.co.uk> Message-ID: <59D86443-4B40-4C8E-9B07-D12CB24A6157@iam.unibe.ch> > Does MANullAccessor have to be so so... erm unusable? One important thing to notice is that the accessors are also used to establish identity between descriptions. In case of the NullAccessor this is done trough an UUID, in case of the SelectorAccessor this is naturally done trough its selector. > If you happen to use it nothing seems to work with it. > > i.e. accessor selector doesnt work, one should argue that it shouldnt, > but is it doing a good job of being a null? Since the NullAccessor is the default, it is supposed to warn the user of a missing access strategy. In case descriptions are created by end-users (where something like an access strategy would be out of scope), the NullAccessor establishes a perfect identity, that can then be used in #readUsing: and #write:using: to dispatch the access for example to a dictionary. > Most users of read: dont test canRead: first. I wonder if #canRead: and #canWrite: are still needed? Also most access strategies seem to be useless to me. I only use the NullAccessor (used internally), the ContainerAccessor (used internally), the SelectorAccessor, and rarely the AutoSelectorAccessor. Time for a clean-up? > I am thinking of implementing a subclass MADummyAccessor which does > implement read: just so as it can play with the other accessors in > mementos etc. That would make sense in your case, I guess. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From cappadonza at hotmail.com Mon Oct 15 10:25:12 2007 From: cappadonza at hotmail.com (isaiah perumalla) Date: Mon, 15 Oct 2007 08:25:12 +0000 Subject: MANullAccessor In-Reply-To: <59D86443-4B40-4C8E-9B07-D12CB24A6157@iam.unibe.ch> References: <4712B3F3.1050603@yahoo.co.uk> <59D86443-4B40-4C8E-9B07-D12CB24A6157@iam.unibe.ch> Message-ID: >Also most > access strategies seem to be useless to me. I only use the > NullAccessor (used internally), the ContainerAccessor (used > internally), the SelectorAccessor, and rarely the > AutoSelectorAccessor. Time for a clean-up?> I think the ChainAccessor strategy is also very useful> From: renggli at iam.unibe.ch> Subject: Re: MANullAccessor> Date: Mon, 15 Oct 2007 07:24:04 +0200> To: smallwiki at iam.unibe.ch> > > Does MANullAccessor have to be so so... erm unusable?> > One important thing to notice is that the accessors are also used to > establish identity between descriptions. In case of the NullAccessor > this is done trough an UUID, in case of the SelectorAccessor this is > naturally done trough its selector.> > > If you happen to use it nothing seems to work with it.> >> > i.e. accessor selector doesnt work, one should argue that it shouldnt,> > but is it doing a good job of being a null?> > Since the NullAccessor is the default, it is supposed to warn the > user of a missing access strategy. In case descriptions are created > by end-users (where something like an access strategy would be out of > scope), the NullAccessor establishes a perfect identity, that can > then be used in #readUsing: and #write:using: to dispatch the access > for example to a dictionary.> > > Most users of read: dont test canRead: first.> > I wonder if #canRead: and #canWrite: are still needed? Also most > access strategies seem to be useless to me. I only use the > NullAccessor (used internally), the ContainerAccessor (used > internally), the SelectorAccessor, and rarely the > AutoSelectorAccessor. Time for a clean-up?> > > I am thinking of implementing a subclass MADummyAccessor which does> > implement read: just so as it can play with the other accessors in> > mementos etc.> > That would make sense in your case, I guess.> > Cheers,> Lukas> > -- > Lukas Renggli> http://www.lukas-renggli.ch> > > _______________________________________________> SmallWiki, Magritte, Pier and Related Tools ...> https://www.iam.unibe.ch/mailman/listinfo/smallwiki _________________________________________________________________ It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071015/d60d2d3e/attachment.html From renggli at iam.unibe.ch Mon Oct 15 12:00:31 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 15 Oct 2007 12:00:31 +0200 Subject: MANullAccessor In-Reply-To: References: <4712B3F3.1050603@yahoo.co.uk> <59D86443-4B40-4C8E-9B07-D12CB24A6157@iam.unibe.ch> Message-ID: <3A5F0C50-AC1B-48E7-999F-9BAF875E00D8@iam.unibe.ch> > >Also most > > access strategies seem to be useless to me. I only use the > > NullAccessor (used internally), the ContainerAccessor (used > > internally), the SelectorAccessor, and rarely the > > AutoSelectorAccessor. Time for a clean-up? > I think the ChainAccessor strategy is also very useful Agree, but I found myself to prefer helper methods. For example instead of specifying #(group name) using a ChainAccessor, I just implemented User>>#groupName that delegates to the group and then use the SelectorAccessor. There are certainly cases where the ChainAccessor is simpler to use. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From tournesolo at gmail.com Mon Oct 15 14:14:38 2007 From: tournesolo at gmail.com (tournesolo@gmail.com) Date: Mon, 15 Oct 2007 14:14:38 +0200 Subject: conditionally showing a widget? In-Reply-To: <1B33C461-E347-455E-B1DA-F6A40798C265@iam.unibe.ch> References: <20071013231551.GD30517@e2011> <1E6C384C-C898-4687-8152-A6D3D194071A@iam.unibe.ch> <20071014105517.GE30517@e2011> <1B33C461-E347-455E-B1DA-F6A40798C265@iam.unibe.ch> Message-ID: <20071015121438.GA4650@e2011> Thanks Tudor - that's clever and elegant! > If you want to control the visibility of the surrounding div as well, > you can just create a page with only the above content, include the > page in the Environment without any surrounding div and then give the > page the wanted rights. From keith_hodges at yahoo.co.uk Mon Oct 15 14:35:16 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 15 Oct 2007 13:35:16 +0100 Subject: MANullAccessor In-Reply-To: <3A5F0C50-AC1B-48E7-999F-9BAF875E00D8@iam.unibe.ch> References: <4712B3F3.1050603@yahoo.co.uk> <59D86443-4B40-4C8E-9B07-D12CB24A6157@iam.unibe.ch> <3A5F0C50-AC1B-48E7-999F-9BAF875E00D8@iam.unibe.ch> Message-ID: <47135E84.8030400@yahoo.co.uk> Lukas Renggli wrote: >>> Also most >>> access strategies seem to be useless to me. I only use the >>> NullAccessor (used internally), the ContainerAccessor (used >>> internally), the SelectorAccessor, and rarely the >>> AutoSelectorAccessor. Time for a clean-up? >>> >> I think the ChainAccessor strategy is also very useful >> > > Agree, but I found myself to prefer helper methods. For example > instead of specifying #(group name) using a ChainAccessor, I just > implemented User>>#groupName that delegates to the group and then use > the SelectorAccessor. There are certainly cases where the > ChainAccessor is simpler to use. > > Lukas > I use MAChainAccessor as a fundamental piece in my RDB mapping. I walk the descriptions, including OneToOne relations and build a mapping from a flat db response into the described object model. As I build the query I collect the accessors for writing the query results into the model. While doing this I treat the Chain accessors like a stack that you can push and pop onto. I add MAAccessor-chainTo: for pushing and chainUnlinkLast for popping with #isChainAccessor for testing along the way. I have used MADictionaryAccessor for accessing settings but ended up defining a first class object for this. I use BlockAccessor for situations where the DB is not quite mapping directly into the to/from the model Now I have DummyAccessor, which works very well, since I only have to define #defaultAccessor - I have a table component where I select the content and order of fields for columns. However I also define buttons and spacers with descriptions even though they have no values, they can be selected and ordered together with real value accessing items. So I am not sure there is much left to tidy up.... Keith From tournesolo at gmail.com Mon Oct 15 21:51:48 2007 From: tournesolo at gmail.com (tournesolo@gmail.com) Date: Mon, 15 Oct 2007 21:51:48 +0200 Subject: embed pier blog? Message-ID: <20071015195148.GA5656@e2011> hi - I'm trying to embed a pier-blog in a vanilla pier page, using variations of +myblog+, but that only embeds the description of the blog -- not a view of the latest blog entries. Any simple trick? thanks, ts From girba at iam.unibe.ch Mon Oct 15 22:10:23 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Mon, 15 Oct 2007 22:10:23 +0200 Subject: embed pier blog? In-Reply-To: <20071015195148.GA5656@e2011> References: <20071015195148.GA5656@e2011> Message-ID: <00D3A808-3845-48D7-AA41-DD9CFAD523B0@iam.unibe.ch> Hi, If you want to include the latest blog entries, you should use a Post Ticker component. This component lets you specify the source blog and the number of blog entries and the number of characters for each entry. So, besides myblog, you should create a blogticker component and include that one in your page. Cheers, Doru On Oct 15, 2007, at 9:51 PM, tournesolo at gmail.com wrote: > > hi - > > I'm trying to embed a pier-blog in a vanilla pier page, using > variations of +myblog+, but that only embeds the description of the > blog -- not a view of the latest blog entries. Any simple trick? > > thanks, > ts > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Every successful trip needs a suitable vehicle." From jason.johnson.081 at gmail.com Mon Oct 15 22:14:20 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Mon, 15 Oct 2007 22:14:20 +0200 Subject: Magritte: descriptions for classes that use different constructors then new Message-ID: Hi all, I have a situation that brings up a couple of questions. I have 2 classes which have a class side variable which keeps track of the instances created (much like how Pier's PRKernel works). As a consequence, I need these objects to be instantiated, not with #new, but with a special message (e.g. #named:). The second part of the equation is that, while these two classes have their own Magritte definitions and can display themselves, there is a "main site" component that displays all the instances from these two classes, as options for the user. So this puts me in a situation where the main site class needs to have descriptions (MAToManyDescription I believe) that reference the other two objects (i.e. the main site class wont have any instVars for these). And for added fun, this class has a class side method named #description for the Seaside framework. Now, I think the issue with the main site is not so bad, I would just define my #description methods as normal, right? Since #description is taken already I guess I have to override it on the instance side and call MANamedBuilder for: myself? And the other question is, how do I enforce that when Magritte wants to make a new instance of these other two classes that it uses my custom constructor, not #new? Since the custom constructor is going to expect a portion of the data already, I'm guessing I need some kind of Memento? I suppose I could just let it create the object with new, and then have the accessor create the "real" object from this, but that seems very cheesy. Thanks for any help you can provide, Jason From renggli at iam.unibe.ch Tue Oct 16 10:07:40 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 16 Oct 2007 10:07:40 +0200 Subject: Magritte: descriptions for classes that use different constructors then new In-Reply-To: References: Message-ID: <1E7B0A99-D35E-4496-9BD4-12CA65ED1953@iam.unibe.ch> > Now, I think the issue with the main site is not so bad, I would just > define my #description methods as normal, right? Since #description > is taken already I guess I have to override it on the instance side > and call MANamedBuilder for: myself? Yes, that's the simplest possibility. > And the other question is, how do I enforce that when Magritte wants > to make a new instance of these other two classes that it uses my > custom constructor, not #new? Magritte does not have the possibility to specify a different constructor. > Since the custom constructor is going > to expect a portion of the data already, I'm guessing I need some kind > of Memento? I suppose I could just let it create the object with new, > and then have the accessor create the "real" object from this, but > that seems very cheesy. Yes, if you have descriptions for your constructor arguments you can use the MAAdaptiveModel to let the user enter the constructor data and then you feed these values into the constructor itself. I guess there is no easier way. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From tournesolo at gmail.com Tue Oct 16 11:59:33 2007 From: tournesolo at gmail.com (tournesolo@gmail.com) Date: Tue, 16 Oct 2007 11:59:33 +0200 Subject: embed pier blog? In-Reply-To: <00D3A808-3845-48D7-AA41-DD9CFAD523B0@iam.unibe.ch> References: <20071015195148.GA5656@e2011> <00D3A808-3845-48D7-AA41-DD9CFAD523B0@iam.unibe.ch> Message-ID: <20071016095933.GB7634@e2011> > you should use a Post Ticker component Excellent, thanks for the pointer. ts From jason.johnson.081 at gmail.com Tue Oct 16 17:59:20 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 16 Oct 2007 17:59:20 +0200 Subject: Magritte: descriptions for classes that use different constructors then new In-Reply-To: <1E7B0A99-D35E-4496-9BD4-12CA65ED1953@iam.unibe.ch> References: <1E7B0A99-D35E-4496-9BD4-12CA65ED1953@iam.unibe.ch> Message-ID: On 10/16/07, Lukas Renggli wrote: > > Yes, that's the simplest possibility. I saw some stuff on Ramon's blog that answered my question (I must say, I knew this blog was good, but I didn't realize how much great info was there). > Yes, if you have descriptions for your constructor arguments you can > use the MAAdaptiveModel to let the user enter the constructor data > and then you feed these values into the constructor itself. I guess > there is no easier way. Well, that's not bad. I'm just glad it's doable at all. From taking a quick look, it seems I can just make a CustomizedConstructorMemento to do this job. I can change the model to be the *class* instead of an instance of the class, and change the push method to first construct the class, then apply the remaining values. Hrm, actually I guess model will need to be the class on first use, and an instance of the class after data is committed to it once. But on an unrelated note, while exploring my options with accessors I think I may have uncovered a bug. I was using autoselector, which made instance variables in my class and accessors for them (handy when you need it!). I switched to selectorAccessor to stop this behavior and now I get the following: MessageNotUnderstood: Set>>copyFrom:to: Debug Proceed Full Stack Possible Causes * you sent a message this type of object doesn't understand Stack Trace 1. thisContext Set(Object)>>doesNotUnderstand: #copyFrom:to: self a Set() aMessage copyFrom: 1 to: 0 2. thisContext MAReport>>visible self a MAReport 3. thisContext MAReport>>renderTableBodyOn: self a MAReport html a WARenderCanvas row nil index nil col nil 4. thisContext [] in MAReport>>renderTableOn: {[self showBody ifTrue: [self renderTableBodyOn: html]]} self a MAReport html a WARenderCanvas 5. thisContext BlockContext>>renderOn: self [] in MAReport>>renderTableOn: {[self showBody ifTrue: [self renderTableBodyOn: html]]} aRenderer a WARenderCanvas I'm still investigating the cause of this, but I thought I would post it real fast in case someone knows off the top of their head. Thanks, Jason From renggli at iam.unibe.ch Tue Oct 16 18:15:58 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 16 Oct 2007 18:15:58 +0200 Subject: Magritte: descriptions for classes that use different constructors then new In-Reply-To: References: <1E7B0A99-D35E-4496-9BD4-12CA65ED1953@iam.unibe.ch> Message-ID: <1968BAAA-3DE0-4248-9B8E-740D83D0624A@iam.unibe.ch> > But on an unrelated note, while exploring my options with accessors I > think I may have uncovered a bug. I was using autoselector, which > made instance variables in my class and accessors for them (handy when > you need it!). I switched to selectorAccessor to stop this behavior > and now I get the following: The following change should fix this: Name: Magritte-Seaside-lr.245 Author: lr Time: 16 October 2007, 6:15:06 pm UUID: fc88afbe-e0b7-4a92-a3a5-859f94a3efc6 Ancestors: Magritte-Seaside-lr.244 - fixed a problem reported by Jason Johnson when suddenly a Set ended up in a report Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jason.johnson.081 at gmail.com Tue Oct 16 18:33:32 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 16 Oct 2007 18:33:32 +0200 Subject: Magritte: descriptions for classes that use different constructors then new In-Reply-To: <1968BAAA-3DE0-4248-9B8E-740D83D0624A@iam.unibe.ch> References: <1E7B0A99-D35E-4496-9BD4-12CA65ED1953@iam.unibe.ch> <1968BAAA-3DE0-4248-9B8E-740D83D0624A@iam.unibe.ch> Message-ID: Awesome, thanks. That was fast work! :) On 10/16/07, Lukas Renggli wrote: > > But on an unrelated note, while exploring my options with accessors I > > think I may have uncovered a bug. I was using autoselector, which > > made instance variables in my class and accessors for them (handy when > > you need it!). I switched to selectorAccessor to stop this behavior > > and now I get the following: > > The following change should fix this: > > Name: Magritte-Seaside-lr.245 > Author: lr > Time: 16 October 2007, 6:15:06 pm > UUID: fc88afbe-e0b7-4a92-a3a5-859f94a3efc6 > Ancestors: Magritte-Seaside-lr.244 > > - fixed a problem reported by Jason Johnson when suddenly a Set ended > up in a report > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From jason.johnson.081 at gmail.com Tue Oct 16 22:47:58 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 16 Oct 2007 22:47:58 +0200 Subject: Magritte: Accessors for classes with collection members Message-ID: Hello all, In Ramon's blog [1] he mentions: "When creating a description for that collection, I can specify my custom #accessor: rather than using the default #selectorAccessor: which then writes to my domain object with #addUser: and #removeUser:." Looking at the code, I don't see how this is done. Isn't the write accessor going to get a complete collection? Is the idea to just diff the received collection from the one the object had and make calls to #add and #remove as appropriate, or is there a way to only be told about the new objects in the collection? Thanks, Jason [1] http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/ From ramon.leon at allresnet.com Wed Oct 17 00:58:19 2007 From: ramon.leon at allresnet.com (Ramon Leon) Date: Tue, 16 Oct 2007 15:58:19 -0700 Subject: Magritte: Accessors for classes with collection members In-Reply-To: References: Message-ID: <058401c81048$0b79a3b0$f000a8c0@hq.allresnet.com> > In Ramon's blog [1] he mentions: > > "When creating a description for that collection, I can > specify my custom #accessor: rather than using the default > #selectorAccessor: > which then writes to my domain object with #addUser: and > #removeUser:." > > Looking at the code, I don't see how this is done. Isn't the > write accessor going to get a complete collection? Is the > idea to just diff the received collection from the one the > object had and make calls to #add and #remove as appropriate, > or is there a way to only be told about the new objects in > the collection? > > Thanks, > Jason That's exactly what I do. When I encapsulate a collection, I always provide the following #pluralCopyOfCollection #addX: #removeX: So... #people #addPerson: #removePerson: This doesn't work with Magritte expecting to be able to set the whole collection, so I use a custom accessor that removes items not contained in the new collection, and adds items not contained in the old collection. It requires a little reflection and a pluralize method to infer the collection name from the singular selector it's invoked with, i.e. #person for above sample. Ramon Leon http://onsmalltalk.com From keith_hodges at yahoo.co.uk Wed Oct 17 03:38:54 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 17 Oct 2007 02:38:54 +0100 Subject: Pier-tree in IE In-Reply-To: <058401c81048$0b79a3b0$f000a8c0@hq.allresnet.com> References: <058401c81048$0b79a3b0$f000a8c0@hq.allresnet.com> Message-ID: <471567AE.7000100@yahoo.co.uk> I have not had much success with the tree view in IE. It seems to cop out at depths > 2 or 3 Is this a known issue? Keith From jason.johnson.081 at gmail.com Wed Oct 17 08:08:30 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Wed, 17 Oct 2007 08:08:30 +0200 Subject: Magritte: Accessors for classes with collection members In-Reply-To: <058401c81048$0b79a3b0$f000a8c0@hq.allresnet.com> References: <058401c81048$0b79a3b0$f000a8c0@hq.allresnet.com> Message-ID: Ah, I see. How hard do you think it would it be to create a new MAToManyDescription (or Container or whatever) subclass that worked like this [1]? This seems like a common pattern so it might be a good extension to the framework, and I don't think it would be very hard. The component must already be calling add on a collection, so that add call just needs to be selected by the subclass. Another option might be to exchange the collection the memento uses now for a special collection that overrides the #add and #remove methods. I'll take a look at this today if I get a chance. Thanks for the clarification. I hope you find time/interest in doing more blog entries about doing things in Seaside/Magritte/Pier. :) [1] Just to be totally clear for all, by "like this" I mean; have a "read: whole collection", "modify: add to collection" and "modify: remove from collection", instead of just "read: whole collection"/"write: whole collection". On 10/17/07, Ramon Leon wrote: > > In Ramon's blog [1] he mentions: > > > > "When creating a description for that collection, I can > > specify my custom #accessor: rather than using the default > > #selectorAccessor: > > which then writes to my domain object with #addUser: and > > #removeUser:." > > > > Looking at the code, I don't see how this is done. Isn't the > > write accessor going to get a complete collection? Is the > > idea to just diff the received collection from the one the > > object had and make calls to #add and #remove as appropriate, > > or is there a way to only be told about the new objects in > > the collection? > > > > Thanks, > > Jason > > That's exactly what I do. When I encapsulate a collection, I always provide > the following > > #pluralCopyOfCollection > #addX: > #removeX: > > So... > > #people > #addPerson: > #removePerson: > > This doesn't work with Magritte expecting to be able to set the whole > collection, so I use a custom accessor that removes items not contained in > the new collection, and adds items not contained in the old collection. It > requires a little reflection and a pluralize method to infer the collection > name from the singular selector it's invoked with, i.e. #person for above > sample. > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From jborden23 at mac.com Fri Oct 19 05:51:39 2007 From: jborden23 at mac.com (John Borden) Date: Thu, 18 Oct 2007 22:51:39 -0500 Subject: Pier CSS to look like Smallwiki Message-ID: <4ACE241C-33F8-4AD1-AEDA-619FA45ACBE7@mac.com> All, Pier certainly has a lot of features that the previous version was lacking, however sometimes plain is more appealing. Has anyone setup pier to look like Smallwiki? Using the same style sheets didn't fill the bill, and I could probably figure out how to change PRPierLibrary>>styleCss to make it look similar; but if someone has already done this, I'll appreciate the help. Thanks, John From keith_hodges at yahoo.co.uk Sat Oct 20 22:30:44 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 20 Oct 2007 21:30:44 +0100 Subject: PRChildren broken Message-ID: <471A6574.9040608@yahoo.co.uk> Hello Lukas, It appears that embedding a PRChildren component is broken. This is a little tricky to explain. At the point of visiting the embedded component visitInternalLinkEmbed: anObject the context's structure is correct, namely the parent structure being displayed. ie. PRCurrentContext value structure. By the time it obtains the structure from which to collect the child-items, this structure may be something else entirely. So it appears that the PRChildren component being used is one that was cached, and this cached widget has itself cached the #context. I.e. the old context that it had when it was origianlly cached, not the current one in which it is being displayed. I have posted my solution for this... Name: Pier-Seaside-kph.213 Author: kph Time: 20 October 2007, 9:24:28 pm UUID: 75264720-7f4a-11dc-a343-000a95edb42a Ancestors: Pier-Seaside-lr.212 - fixed typo 'Highlight' labels - components obtained from a contexts componentDictionary cache have an obsolete context cached in their #context cheers Keith From keith_hodges at yahoo.co.uk Sat Oct 20 22:36:26 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 20 Oct 2007 21:36:26 +0100 Subject: Whats happening? In-Reply-To: <471A6574.9040608@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> Message-ID: <471A66CA.8000503@yahoo.co.uk> Could someone explain where we are going with this? thanks Keith ===== Name: Pier-Seaside-tg.206 Author: tg Time: 16 October 2007, 5:05:33 pm UUID: 7f2eb12c-28b3-4c8c-b74d-269681e5345a Ancestors: Pier-Seaside-lr.205 worked with lukas to get rid of the environment From keith_hodges at yahoo.co.uk Sat Oct 20 23:11:56 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 20 Oct 2007 22:11:56 +0100 Subject: Whats happening? x2 In-Reply-To: <471A6574.9040608@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> Message-ID: <471A6F1C.3060608@yahoo.co.uk> Could someone explain where we are going with this? Where are conditions going? I thought that automatic validation was half of the point of magritte? thanks Keith From renggli at iam.unibe.ch Sun Oct 21 09:05:36 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 21 Oct 2007 09:05:36 +0200 Subject: Whats happening? In-Reply-To: <471A66CA.8000503@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> Message-ID: <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> > Could someone explain where we are going with this? We are working on making Pier easier, for example that a structure has its own environment. A migration path will be provided. Don't load this (yet). Another goal is to let a structure have multiple documents, so that you can for example edit a side-bar, etc. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Sun Oct 21 09:10:25 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 21 Oct 2007 09:10:25 +0200 Subject: Whats happening? x2 In-Reply-To: <471A6F1C.3060608@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> <471A6F1C.3060608@yahoo.co.uk> Message-ID: <7810425B-3568-4847-AC05-68C0A26B02BE@iam.unibe.ch> > Where are conditions going? I asked a couple of weeks ago in the mailing-list and removed them because nobody opposed. The condition objects impose certain portability problems to VisualWorks and GemStone. They added quite a big deal of classes that I personally never used. > I thought that automatic validation was half of the point of magritte? Put a valuable object as condition, e.g. a block or your own implementation of an Object that responds to #value:. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Sun Oct 21 09:13:22 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 21 Oct 2007 09:13:22 +0200 Subject: PRChildren broken In-Reply-To: <471A6574.9040608@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> Message-ID: <3ED26618-9C27-4C58-B0E8-B2CF5D1FE555@iam.unibe.ch> > It appears that embedding a PRChildren component is broken. This is a > little tricky to explain. I guess that's not just the PRChildren component. Your fix makes sense, I will merge it into the latest code as soon as possible. Cheers, Lukas > > At the point of visiting the embedded component > visitInternalLinkEmbed: > anObject > the context's structure is correct, namely the parent structure being > displayed. ie. PRCurrentContext value structure. > > By the time it obtains the structure from which to collect the > child-items, this structure may be something else entirely. > > So it appears that the PRChildren component being used is one that was > cached, and this cached widget has itself cached the #context. I.e. > the > old context that it had when it was origianlly cached, not the current > one in which it is being displayed. > > I have posted my solution for this... > > Name: Pier-Seaside-kph.213 > Author: kph > Time: 20 October 2007, 9:24:28 pm > UUID: 75264720-7f4a-11dc-a343-000a95edb42a > Ancestors: Pier-Seaside-lr.212 > > - fixed typo 'Highlight' labels > - components obtained from a contexts componentDictionary cache > have an > obsolete context cached in their #context > > > cheers > > Keith > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Sun Oct 21 13:54:22 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sun, 21 Oct 2007 12:54:22 +0100 Subject: Whats happening? In-Reply-To: <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> Message-ID: <471B3DEE.9010605@yahoo.co.uk> Lukas Renggli wrote: >> Could someone explain where we are going with this? >> > > We are working on making Pier easier, for example that a structure > has its own environment. A migration path will be provided. Don't > load this (yet). > > Another goal is to let a structure have multiple documents, so that > you can for example edit a side-bar, etc. > > Lukas > > Ok... I am still stuggling to understand what this means. I thought that structures already have their own environments. Are you saying that a structure, having multiple documents, can have an environment as one of those. How will moving and copying work for these secondary-documents? How about a rule along the lines of "if I contain an 'environment' use it, otherwise use my parent's environment" ? I also think that you we need a different environment for editing environments. So can environments have environments? See below I am also attempting to make pier easier to use and harder to break. The scheme that I came up with looks like this. welcome admin user public site env sidebar header footer contents dev env boxes header contents Each of my top levels has different permissions. public and site are viewable by those that are not logged in. The user area requires the user to be logged in, and the admin and dev areas require you to be logged in as an admin-user. The dev hierarchy can only be edited by the superuser. User/public, use the site-env, and admin/dev/site use the dev-env. This allows the admin users to edit the site-env the environment of the overall site. While the admin and site areas themselves use the dev-env for display. This prevents admin users from breaking their working environment dev-env while changing the site-env. It works pretty well. I agree anything that help make things easy to use will be a good thing. I do not think that the current permissions model is flexible enough for any but the simpleset use cases. I think that if groups were to be able to have groups as members that might help. cheers Keith From renggli at iam.unibe.ch Sun Oct 21 15:45:40 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Sun, 21 Oct 2007 15:45:40 +0200 Subject: Whats happening? In-Reply-To: <471B3DEE.9010605@yahoo.co.uk> References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> <471B3DEE.9010605@yahoo.co.uk> Message-ID: > I thought that structures already have their own environments. Are you > saying that a structure, having multiple documents, can have an > environment as one of those. Yes, we would like to make the environment part of the page itself, not only a reference to a different structure as it was before. Of course you can still do that by embedding a different page. > How will moving and copying work for these secondary-documents? Copying and moving is possible on the level of structures only. So when you move a structure, its environment will be moved as well. That's exactly the same behavior as before. > How about a rule along the lines of "if I contain an 'environment' use > it, otherwise use my parent's environment" ? That will be the same. > I also think that you we need a different environment for editing > environments. So can environments have environments? See below You can stil do that. Exactly the same way you did before. > I am also attempting to make pier easier to use and harder to > break. The > scheme that I came up with looks like this. > > [...] > > This allows the admin users to edit the site-env the environment of > the > overall site. While the admin and site areas themselves use the dev- > env > for display. This prevents admin users from breaking their working > environment dev-env while changing the site-env. It works pretty well. Personally I find it a bit hard to understand ... ;-) Anyway, it is (and also should) remain flexible enough so that people can configure and setup their sites the way they like. Personally, I am using a very different model: (contents of the website) system (location of the management widgets) components (location of reusable components) parts (location of reusable layout parts) designs (location of full layout templates) I use this model for my web-site, the Seaside web-site and a couple of other Pier instances. > I do not think that the current permissions model is flexible > enough for > any but the simpleset use cases. I assume that you are using the Unix Security framework? What you have there is a (mostly) POSIX compliant security model. I am successfully this model in quite complicated setup right now. I am using it in an university course about software engineering: admins (myself), assistants (myself and some other assistants), and students. Furthermore, each student belongs to a group together with one of the assistants. Permissions are set so that only assistants can edit exercises. Each student can only edit his personal page and the pages of his team. Each team has private pages (that only the team can see) and public pages. Of course there is always a discussion between what is the best security model. There is also an ACL based security model available in Pier. People have always been discussion what is a better approach. Having tried both, I find the traditional POSIX permission model easier to understand an manage, but that's certainly a personal preference. > I think that if groups were to be able > to have groups as members that might help. Such a model would not be more powerful than the existing one. If that is requested, I guess, it could be easily feasible to implement (probably by removing a simple check). Lukas -- Lukas Renggli http://www.lukas-renggli.ch From girba at iam.unibe.ch Sun Oct 21 16:35:37 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Sun, 21 Oct 2007 16:35:37 +0200 Subject: Whats happening? In-Reply-To: References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> <471B3DEE.9010605@yahoo.co.uk> Message-ID: Hi, You can achieve groups in groups by adding users in several groups. For example, if you want all users from G1 to have access to what users in G2 do, then make all users from G1 also belong to G2. Cheers, Doru On Oct 21, 2007, at 3:45 PM, Lukas Renggli wrote: >> I think that if groups were to be able >> to have groups as members that might help. > > Such a model would not be more powerful than the existing one. If > that is requested, I guess, it could be easily feasible to implement > (probably by removing a simple check). -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "When people care, great things can happen." From jason.johnson.081 at gmail.com Sun Oct 21 16:56:18 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Sun, 21 Oct 2007 16:56:18 +0200 Subject: Whats happening? In-Reply-To: References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> <471B3DEE.9010605@yahoo.co.uk> Message-ID: On 10/21/07, Lukas Renggli wrote: > > Of course there is always a discussion between what is the best > security model. There is also an ACL based security model available > in Pier. People have always been discussion what is a better > approach. Having tried both, I find the traditional POSIX permission > model easier to understand an manage, but that's certainly a personal > preference. Well, on Unix at least, the problem with the POSIX model is not in how it deals with users and groups, but rather how these can be applied to resources (i.e. permissions for user, group and everyone else). I don't recall anything about how ACL works in Pier. For me, I would like a solution where I can put different groups on a given resource, and then put people in those groups. As much as it pains me to say, I think Windows has a better security model in this regard. From keith_hodges at yahoo.co.uk Sun Oct 21 17:02:31 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sun, 21 Oct 2007 16:02:31 +0100 Subject: Whats happening? In-Reply-To: References: <471A6574.9040608@yahoo.co.uk> <471A66CA.8000503@yahoo.co.uk> <44B5CD35-E63F-44A6-AAB0-7E132BF99AAD@iam.unibe.ch> <471B3DEE.9010605@yahoo.co.uk> Message-ID: <471B6A07.2090407@yahoo.co.uk> Lukas Renggli wrote: >> I thought that structures already have their own environments. Are you >> saying that a structure, having multiple documents, can have an >> environment as one of those. >> > > Yes, we would like to make the environment part of the page itself, > not only a reference to a different structure as it was before. Of > course you can still do that by embedding a different page. > > Personally I find it a bit hard to understand ... ;-) > > Anyway, it is (and also should) remain flexible enough so that people > can configure and setup their sites the way they like. > > Thanks for this case study, it is helpful. > Personally, I am using a very different model: > > (contents of the website) > system > (location of the management widgets) > components > (location of reusable components) > parts > (location of reusable layout parts) > designs > (location of full layout templates) > > I use this model for my web-site, the Seaside web-site and a couple > of other Pier instances. > The difference between our approaches is that you have to manage the permissions of each component individually. I found this quite difficult to keep track of. My approach gives permissions to each branch of the heirarchy, and so a component inherits the permissions of the branch in which it is placed. The advantage of this is visibility. I can know from the path of a component what permissions it has. >> I do not think that the current permissions model is flexible >> enough for >> any but the simpleset use cases. >> > > I assume that you are using the Unix Security framework? What you > have there is a (mostly) POSIX compliant security model. > > I am successfully this model in quite complicated setup right now. I > am using it in an university course about software engineering: > admins (myself), assistants (myself and some other assistants), and > students. Furthermore, each student belongs to a group together with > one of the assistants. Permissions are set so that only assistants > can edit exercises. Each student can only edit his personal page and > the pages of his team. Each team has private pages (that only the > team can see) and public pages. > As always I have difficulty understanding these things and I have a simple system very similar to yours... Yours: admins, assistants, students and public. Mine: superuser, admins, agents, and public (other). So they are not so very different. However your admin level, can be handled by granting superuser status, giving you only assistants and students to manage permissions for. For any component you can grant two different permissions, to the owner and group. If the students access is specified by the group permissions then surely only one assistant can be allowed to edit any one exercise, by granting that assistant ownership privileges. I have simply admins which can edit the site, and agents which can use the site. So if I assign a component as owned by user admin, and with use privileges by the group 'agents' this works. Ok, thats fine until I want to give more than one person admin rights (without giving them super-user status), since the item can only be owned by a single user rather than a group. My solution to this is that I use pier-users as "roles" and have an externally defined table of users which log in as a role. e.g. keith, bob and eric once authenticated all log in as pier user "role-admin". So a page owned by "role-admin" can be edited by keith, bob or eric. The usage is defined by the group 'agents', and 'role-agent' is a member of that group. Lets say... I want to introduce a layer in between. Say an agent-supervisors, who has slightly more privileges than an agent for accessing the same component. Since the ownership can only be one user, and that is "role-admin" and the group can only be one group which is "role-agent" I am stuck I think. Perhaps I was wrong perhaps what is needed is not for a group to contain other groups, but for the owner to be a group rather than an individual. If my owner could be a group, then... group "editors" could include users "role-admin" and "role-agent-supervisors". This would allow me to assign editing rights to 'editor' and using rights to group 'agents'. ... I think this boils down to the number of different uses for one component. If the uses are "admin", "use" , "view" then in some cases this maps into owner, (user) group, other (public). Private regions of a site would have to map "admin", "use" and "view" into just owner and group, since other is disallowed, and this is where I have got into trouble. Still I am very glad to see pier moving forward, Keith > Of course there is always a discussion between what is the best > security model. There is also an ACL based security model available > in Pier. People have always been discussion what is a better > approach. Having tried both, I find the traditional POSIX permission > model easier to understand an manage, but that's certainly a personal > preference. > > >> I think that if groups were to be able >> to have groups as members that might help. >> > > Such a model would not be more powerful than the existing one. If > that is requested, I guess, it could be easily feasible to implement > (probably by removing a simple check). > > Lukas > > From merlyn at stonehenge.com Mon Oct 22 03:59:12 2007 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Sun, 21 Oct 2007 18:59:12 -0700 Subject: magritte - multiple dynamic views for information gathered on multipage form Message-ID: <86lk9vgb9r.fsf@blue.stonehenge.com> I have a traditional "gather information over 10 pages" app in Perl that I'm rewriting using Seaside and Magritte. The current app stashes everything in a giant Perl hash (saving and loading from hidden vars) at each step. Sometimes, the presence or absence of (or even repetitions of) a field depends on previous questions answered on previous pages. When I started to model this with Magaritte, I quickly hit some roadblocks trying to implement the dynamic "descriptionFoo" since these are (a) cached and (b) have no access to "self" since they are class-side. So I've managed to come up with something that sorta works instance-side, but I'm not very happy with it, as I wonder for example how many times "myModel description" will be called during a render, and whether I should try to cache that. I also am ending up with a series of subclasses of a parent class that holds the entire collected values, but has only the items of interest. None of this seems very clean, and it seems like I'm reinventing some wheels. Does anyone have some examples of how to do things like a basic "gather info from a multipage query, some of which depends on earlier answers" task would work and look like? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! From keith_hodges at yahoo.co.uk Mon Oct 22 17:37:09 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 22 Oct 2007 16:37:09 +0100 Subject: Another command copying fix Message-ID: <471CC3A5.4090207@yahoo.co.uk> I found this fix in my code which is another intended to preserve the command-context integrity Keith --- PRCommand-context: aContext context: aContext (self isValidIn: aContext) ifFalse: [ self error: self name , ' is not useable in the given context.' ]. ^ (aContext command: self new) command From keith_hodges at yahoo.co.uk Mon Oct 22 19:28:05 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 22 Oct 2007 18:28:05 +0100 Subject: Command cant edit model In-Reply-To: <471CC3A5.4090207@yahoo.co.uk> References: <471CC3A5.4090207@yahoo.co.uk> Message-ID: <471CDDA5.7060208@yahoo.co.uk> I am trying, and failing, to create a command that acts upon a model. When a command calls asComponent it usually gives itself as a model. If I do: asComponent ^ (model description asComponentOn: model) addValidatedForm: (Array with: #save -> 'Confirm' with: #cancel); yourself Instead then everything works fine until the container component answers the model, and the answer handler is expecting aCommand not an instance of some other class Any ideas would be appreciated. Keith From keith_hodges at yahoo.co.uk Mon Oct 22 19:41:31 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 22 Oct 2007 18:41:31 +0100 Subject: Command cant edit model In-Reply-To: <471CDDA5.7060208@yahoo.co.uk> References: <471CC3A5.4090207@yahoo.co.uk> <471CDDA5.7060208@yahoo.co.uk> Message-ID: <471CE0CB.9040804@yahoo.co.uk> Ok solved it... I can implement read:Using: etc. on the command to delegate all accesses to the model. Keith > I am trying, and failing, to create a command that acts upon a model. > > When a command calls asComponent it usually gives itself as a model. > > If I do: > > asComponent > ^ (model description asComponentOn: model) > addValidatedForm: (Array with: #save -> 'Confirm' with: #cancel); > yourself > > Instead then everything works fine until the container component answers > the model, and the answer handler is expecting aCommand not an instance > of some other class > > Any ideas would be appreciated. > > Keith > From renggli at iam.unibe.ch Mon Oct 22 21:52:27 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 22 Oct 2007 21:52:27 +0200 Subject: magritte - multiple dynamic views for information gathered on multipage form In-Reply-To: <86lk9vgb9r.fsf@blue.stonehenge.com> References: <86lk9vgb9r.fsf@blue.stonehenge.com> Message-ID: > on previous questions answered on previous pages. When I started > to model > this with Magaritte, I quickly hit some roadblocks trying to > implement the > dynamic "descriptionFoo" since these are (a) cached and (b) have no > access to > "self" since they are class-side. So I've managed to come up with > something > that sorta works instance-side, but I'm not very happy with it, as > I wonder > for example how many times "myModel description" will be called > during a > render, and whether I should try to cache that. It is perfectly fine to override #description on the instance-side and return a dynamically composed object depending on the state of self (or the current context, whatever). While rendering the component keeps a reference onto the returned description, so #description should only be called once. However calling #description is usually not a bottleneck, only when traversing a huge graph of thousands of objects you will find a measurable speedup when using the cached descriptions. > Does anyone have some examples of how to do things like a basic > "gather info > from a multipage query, some of which depends on earlier answers" > task would > work and look like? Sounds like an interesting design problem. Do you need the model to be adaptive, so that end users can define questions and model the flow on the fly? Or are the questions and flow hard-coded? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From merlyn at stonehenge.com Mon Oct 22 22:39:53 2007 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Mon, 22 Oct 2007 13:39:53 -0700 Subject: magritte - multiple dynamic views for information gathered on multipage form In-Reply-To: (Lukas Renggli's message of "Mon, 22 Oct 2007 21:52:27 +0200") References: <86lk9vgb9r.fsf@blue.stonehenge.com> Message-ID: <86abqaevdy.fsf@blue.stonehenge.com> >>>>> "Lukas" == Lukas Renggli writes: Lukas> Do you need the model to be adaptive, so that end users can define Lukas> questions and model the flow on the fly? Or are the questions and Lukas> flow hard-coded? Questions and flow are hard-coded. Basically, I'm replacing the "booking engine" at geekcruises.com. Go to any cruise, pick "book now", check the check box, and submit. You'll be in the Perl code that I'm replacing after that. It's safe to paw through there, all the way to the end, because nothing gets recorded until the last "book it" hit. The cabin types depend on the cruise number from the initial request. The number of detailed passenger infos depends on the number of people given earlier. And so on. So, the views have to be somewhat dynamic based on previous questions, and I'm also hitting the database for a few of the things so I don't want to have to do that repeatedly for the same web hit for the same query. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! From renggli at iam.unibe.ch Mon Oct 22 23:35:49 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Mon, 22 Oct 2007 23:35:49 +0200 Subject: Another command copying fix In-Reply-To: <471CC3A5.4090207@yahoo.co.uk> References: <471CC3A5.4090207@yahoo.co.uk> Message-ID: Thank you for reporting this problem. I removed this accessor from the command all-together. It is used nowhere in the code and seems to be a legacy thing from earlier versions of Pier. Cheers, Lukas On 22 Oct 2007, at 17:37, Keith Hodges wrote: > I found this fix in my code which is another intended to preserve the > command-context integrity > > Keith > > --- > > > PRCommand-context: aContext > > context: aContext > > (self isValidIn: aContext) > ifFalse: [ self error: self name , ' is not useable in the > given > context.' ]. > > ^ (aContext command: self new) command > > > > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From jason.johnson.081 at gmail.com Tue Oct 23 07:33:46 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 23 Oct 2007 07:33:46 +0200 Subject: magritte - multiple dynamic views for information gathered on multipage form In-Reply-To: <86abqaevdy.fsf@blue.stonehenge.com> References: <86lk9vgb9r.fsf@blue.stonehenge.com> <86abqaevdy.fsf@blue.stonehenge.com> Message-ID: Isn't there some kind of component that breaks things into different pages? If not, then this page has some good information: http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/ I am making a series of sites right now that all view the same domain objects, so I can't use the defaults from Magritte because the "description" will depend on who is looking. In Magritte we can customize as high up as we want. My plan right now is simply not use #asComponent for display, but instead have a asAComponent for one site and asBComponent for another. Each one would select a different set of descriptions as described in the link above. Another option would be to make a custom component (or perhaps renderer is better, I haven't looked deeply at this part) that has a "page" member to show what page is displaying, calls the object side descriptions but caches the results (it may already work this way) and so on. I'm sure others know other tricks, I'm just starting with Magritte. On 10/22/07, Randal L. Schwartz wrote: > >>>>> "Lukas" == Lukas Renggli writes: > > Lukas> Do you need the model to be adaptive, so that end users can define > Lukas> questions and model the flow on the fly? Or are the questions and > Lukas> flow hard-coded? > > Questions and flow are hard-coded. > > Basically, I'm replacing the "booking engine" at geekcruises.com. Go to any > cruise, pick "book now", check the check box, and submit. > > You'll be in the Perl code that I'm replacing after that. It's safe to paw > through there, all the way to the end, because nothing gets recorded until the > last "book it" hit. > > The cabin types depend on the cruise number from the initial request. The > number of detailed passenger infos depends on the number of people given > earlier. And so on. So, the views have to be somewhat dynamic based on > previous questions, and I'm also hitting the database for a few of the things > so I don't want to have to do that repeatedly for the same web hit for the > same query. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > From merlyn at stonehenge.com Tue Oct 23 16:46:37 2007 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Tue, 23 Oct 2007 07:46:37 -0700 Subject: magritte - multiple dynamic views for information gathered on multipage form In-Reply-To: (Jason Johnson's message of "Tue, 23 Oct 2007 07:33:46 +0200") References: <86lk9vgb9r.fsf@blue.stonehenge.com> <86abqaevdy.fsf@blue.stonehenge.com> Message-ID: <864pghdh2q.fsf@blue.stonehenge.com> >>>>> "Jason" == Jason Johnson writes: Jason> Isn't there some kind of component that breaks things into different Jason> pages? If not, then this page has some good information: Jason> http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/ Oooh... I may have stumbled on that already, but I ended up recreating parts of it for what seems to be working now. The MAAccessor info looks like it'll help solve the next problem I have though. Yeay. Jason> In Magritte we can customize as high up as we want. My plan right now Jason> is simply not use #asComponent for display, but instead have a Jason> asAComponent for one site and asBComponent for another. Each one Jason> would select a different set of descriptions as described in the link Jason> above. Yeah, here's what I came up with in my WATask'ish thing: MyTask>>go self call: self page1Component. self call: self page2Component MyTask>>page1Component | result | result := model asPage1Component. "tweak description for this view" result description componentRenderer: MACssRenderer. result description attributes addClass: 'specialclass'. "tweak view" result addValidatedForm; addDecoration: (WAMessageDecoration new message: 'page 1'; yourself). ^result (page2 component is similar) MyModel>>asPage1Component ^MAContainer new add: self descriptionField1; asComponentOn: self MyModel>>asPage2Component ^MAContainer new add: self descriptionField2; addAll: self descriptionsField3; "might return 0..n items" add: self descriptionField4; asComponentOn: self I'm trying to keep the "view" tweaks in the Task, because I think the task should own how the container is rendered, although I think the subcontainers will probably define their own viewish flavors without help. I may rethink this later. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! From keith_hodges at yahoo.co.uk Wed Oct 24 17:42:22 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 24 Oct 2007 16:42:22 +0100 Subject: Components using subcomponents Message-ID: <471F67DE.1080205@yahoo.co.uk> Hi Lukas, I am struggling to see how components can register sub-components as children. One of my components has a header/footer fields which are rendered using wiki format. Unfortunately embedding components in this format does not work and I am trying to find a way to fix it. any thoughts? Keith From keith_hodges at yahoo.co.uk Thu Oct 25 19:55:40 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Thu, 25 Oct 2007 18:55:40 +0100 Subject: Components using subcomponents In-Reply-To: <471F67DE.1080205@yahoo.co.uk> References: <471F67DE.1080205@yahoo.co.uk> Message-ID: <4720D89C.3040807@yahoo.co.uk> I have managed to render wiki formatted text as a PRDocument in my component. When rendering I have to set the owner of the document to 'context structure'. However as soon as I embed the component in another page, links that are relative to the original component do not resolve. I seem unable to find any way of obtaining the parent PRComponent (i.e. the owner) of a PRWidget, am I missing something? Keith > Hi Lukas, > > I am struggling to see how components can register sub-components as > children. > > One of my components has a header/footer fields which are rendered using > wiki format. > Unfortunately embedding components in this format does not work and I am > trying to find a way to fix it. > > any thoughts? > > Keith > From renggli at iam.unibe.ch Thu Oct 25 20:50:01 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 25 Oct 2007 20:50:01 +0200 Subject: Components using subcomponents In-Reply-To: <4720D89C.3040807@yahoo.co.uk> References: <471F67DE.1080205@yahoo.co.uk> <4720D89C.3040807@yahoo.co.uk> Message-ID: > I have managed to render wiki formatted text as a PRDocument in my > component. When rendering I have to set the owner of the document to > 'context structure'. However as soon as I embed the component in > another > page, links that are relative to the original component do not > resolve. > > I seem unable to find any way of obtaining the parent PRComponent > (i.e. > the owner) of a PRWidget, am I missing something? #owner: should only be called after a document is parsed. It is used to resolve the links relative to the structure given as argument. Lukas > > Keith > >> Hi Lukas, >> >> I am struggling to see how components can register sub-components as >> children. >> >> One of my components has a header/footer fields which are rendered >> using >> wiki format. >> Unfortunately embedding components in this format does not work >> and I am >> trying to find a way to fix it. >> >> any thoughts? >> >> Keith >> > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Thu Oct 25 21:28:04 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Thu, 25 Oct 2007 20:28:04 +0100 Subject: Components using subcomponents In-Reply-To: References: <471F67DE.1080205@yahoo.co.uk> <4720D89C.3040807@yahoo.co.uk> Message-ID: <4720EE44.9040800@yahoo.co.uk> I have parsed some text in my widget, and from that I have a PRDocument, I want to call owner: upon it as you say, but since this is a widget it does not have access to the component in which it is being rendered. The two options I have come up with are to do 'context renderer lastVisited' and/or to have PRComponent-component call PRWidget structure: self. regards Keith >> I have managed to render wiki formatted text as a PRDocument in my >> component. When rendering I have to set the owner of the document to >> 'context structure'. However as soon as I embed the component in >> another >> page, links that are relative to the original component do not >> resolve. >> >> I seem unable to find any way of obtaining the parent PRComponent >> (i.e. >> the owner) of a PRWidget, am I missing something? >> > > #owner: should only be called after a document is parsed. It is used > to resolve the links relative to the structure given as argument. > > Lukas > > From keith_hodges at yahoo.co.uk Thu Oct 25 16:36:45 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Thu, 25 Oct 2007 15:36:45 +0100 Subject: Components using subcomponents In-Reply-To: <471F67DE.1080205@yahoo.co.uk> References: <471F67DE.1080205@yahoo.co.uk> Message-ID: <4720A9FD.9060805@yahoo.co.uk> No worries I have plan B. Keith > Hi Lukas, > > I am struggling to see how components can register sub-components as > children. > > One of my components has a header/footer fields which are rendered using > wiki format. > Unfortunately embedding components in this format does not work and I am > trying to find a way to fix it. > > any thoughts? > > Keith > > From renggli at iam.unibe.ch Thu Oct 25 23:11:53 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 25 Oct 2007 23:11:53 +0200 Subject: Components using subcomponents In-Reply-To: <4720A9FD.9060805@yahoo.co.uk> References: <471F67DE.1080205@yahoo.co.uk> <4720A9FD.9060805@yahoo.co.uk> Message-ID: Well, I am sorry, but what you request doesn't seem to be easily possible with the current model. Maybe we need to have sort of a registration mechanism? Lukas On 25 Oct 2007, at 16:36, Keith Hodges wrote: > No worries I have plan B. > > Keith > > >> Hi Lukas, >> >> I am struggling to see how components can register sub-components as >> children. >> >> One of my components has a header/footer fields which are rendered >> using >> wiki format. >> Unfortunately embedding components in this format does not work >> and I am >> trying to find a way to fix it. >> >> any thoughts? >> >> Keith >> >> > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Fri Oct 26 19:28:10 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 26 Oct 2007 18:28:10 +0100 Subject: [Ann] Pier-Commands-RemoveChildren Message-ID: <472223AA.4080506@yahoo.co.uk> Some folks may find this useful Keith -=-=- Name: Pier-Commands-RemoveChildren-kph.1 Author: kph Time: 26 October 2007, 6:26:35 pm UUID: 9a0279a6-83e8-11dc-a340-000a95edb42a Ancestors: Original Author: Damien Cassou Remove Children, presents a list of the current structures children for you to select those you wish to remove. This command is particularly useful for removing components whose display becomes broken during development. - update of what was Pier-UsefullComands for the latest Pier (circa Pier-Model-lr.175) From keith_hodges at yahoo.co.uk Sat Oct 27 05:21:29 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 27 Oct 2007 04:21:29 +0100 Subject: [ANN] demise of Pier-Shore Message-ID: <4722AEB9.3020208@yahoo.co.uk> Dear All, Pier (or any other seaside application) no longer needs a specialized root component in order to use ShoreComponents. The Seaside28Jetsam package now includes a ShoreHelperHelper which can be enabled in your pier app configuration. The "Helper" portion of Jetsam is entirely self contained, so could be distributed separately. The goal of the helpers concept is to avoid having to use specialized root classes for generic additions which results in combinatorial problems for multiple such additions. Helpers are Decorations which are automatically added to the root component of any application subject to configuration options. They work similarly to other Plugins in Seaside 2.8, as in, you can provide additional Helpers by subclassing WAHelper. So far, in addition to the "Shore Components Helper", Jetsam implements a "Keep Alive Helper" for keeping the session alive while the users browser is open. I find the later totally indispensable. Next I am looking to see how a similar mechanism can be used to avoid needing to subclass WASession. I aim to support Magma as a helper so that all of the different options for shared or pooled magma sessions can be orthogonal to the choice of seaside session class. If Comet could be added as a helper as well then that would also be great. best regards Keith From ssastre at seaswork.com Sat Oct 27 17:32:33 2007 From: ssastre at seaswork.com (Sebastian Sastre) Date: Sat, 27 Oct 2007 12:32:33 -0300 Subject: [ANN] demise of Pier-Shore In-Reply-To: <4722AEB9.3020208@yahoo.co.uk> Message-ID: Could be interesting. You can also think about announcements which usually neddes the anAnnouncer in the session and it's 4 or 5 methods cheers Sebastian Sastre > -----Mensaje original----- > De: smallwiki-bounces at iam.unibe.ch > [mailto:smallwiki-bounces at iam.unibe.ch] En nombre de Keith Hodges > Enviado el: S?bado, 27 de Octubre de 2007 00:21 > Para: SmallWiki, Magritte, Pier and Related Tools ... > Asunto: [ANN] demise of Pier-Shore > > Dear All, > > Pier (or any other seaside application) no longer needs a > specialized root component in order to use ShoreComponents. > The Seaside28Jetsam package now includes a ShoreHelperHelper > which can be enabled in your pier app configuration. > > The "Helper" portion of Jetsam is entirely self contained, so > could be distributed separately. > > The goal of the helpers concept is to avoid having to use > specialized root classes for generic additions which results > in combinatorial problems for multiple such additions. > > Helpers are Decorations which are automatically added to the > root component of any application subject to configuration > options. They work similarly to other Plugins in Seaside 2.8, > as in, you can provide additional Helpers by subclassing WAHelper. > > So far, in addition to the "Shore Components Helper", Jetsam > implements a "Keep Alive Helper" for keeping the session > alive while the users browser is open. I find the later > totally indispensable. > > Next I am looking to see how a similar mechanism can be used > to avoid needing to subclass WASession. I aim to support > Magma as a helper so that all of the different options for > shared or pooled magma sessions can be orthogonal to the > choice of seaside session class. If Comet could be added as a > helper as well then that would also be great. > > best regards > > Keith > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From keith_hodges at yahoo.co.uk Sat Oct 27 18:55:32 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Sat, 27 Oct 2007 17:55:32 +0100 Subject: [ANN] demise of Pier-Shore In-Reply-To: References: Message-ID: <47236D84.7090303@yahoo.co.uk> Sebastian Sastre wrote: > Could be interesting. You can also think about announcements which usually > neddes the anAnnouncer in the session and it's 4 or 5 methods > > cheers > > Sebastian Sastre > > Actually that is exactly what I was thinking about... all for one button on a web page! Keith From sebaspe at gmail.com Mon Oct 29 21:24:42 2007 From: sebaspe at gmail.com (=?ISO-8859-1?Q?Sebasti=E1n_Perez_Escribano?=) Date: Mon, 29 Oct 2007 17:24:42 -0300 Subject: Query about Pier Message-ID: <4726418A.2050409@gmail.com> Hi list, im working with Pier on VisualWorks and I have to add a user. So I do this: ((PRKernel instanceNamed:'Pier') propertyAt: #users) add: self user. But when a look a users report the new one doesn?t appear. And in the Pier Kernel its replicated. Its something Im doing wrong? Exist another way to add a user? Greetings in advance, Sebasti?n From keith_hodges at yahoo.co.uk Tue Oct 30 00:54:32 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Mon, 29 Oct 2007 23:54:32 +0000 Subject: Adding link types Message-ID: <472672B8.3080708@yahoo.co.uk> I was wondering if it might be worth dispatching the calls visitBrokenInternalLink: visitEmbeddedInternalLink: etc back to the Link instance... So that the types of link can render themselves appropriately. Keith From keith_hodges at yahoo.co.uk Tue Oct 30 01:18:01 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Tue, 30 Oct 2007 00:18:01 +0000 Subject: Adding link types In-Reply-To: <472672B8.3080708@yahoo.co.uk> References: <472672B8.3080708@yahoo.co.uk> Message-ID: <47267839.6060905@yahoo.co.uk> Keith Hodges wrote: > I was wondering if it might be worth dispatching the calls > visitBrokenInternalLink: visitEmbeddedInternalLink: etc back to the Link > instance... > > So that the types of link can render themselves appropriately. > > Keith > Example: PRRenderer-visitInternalLink: anObject anObject isBroken ifTrue: [ ^ anObject acceptLinkBroken: self ]. (anObject isEmbedded not or: [ self doesRemember: anObject target ]) ifTrue: [ ^ anObject acceptLinkGoto: self ]. self remember: anObject target while: [ anObject acceptLinkEmbed: anObject ] PRInternalLink-acceptLinkBroken: visitor ^ visitor visitInternalLinkBroken: self PRMyLink-acceptLinkBroken: visitor ^ visitor visitMyLinkBroken: self Keith From renggli at iam.unibe.ch Tue Oct 30 12:40:34 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 30 Oct 2007 12:40:34 +0100 Subject: Query about Pier In-Reply-To: <4726418A.2050409@gmail.com> References: <4726418A.2050409@gmail.com> Message-ID: <26D84B17-C8EB-4D58-A6DC-95A844F31B31@iam.unibe.ch> > ((PRKernel instanceNamed:'Pier') propertyAt: #users) add: self user. > > But when a look a users report the new one doesn?t appear. And in the > Pier Kernel its replicated. Its something Im doing wrong? Exist > another > way to add a user? Are you sure you are using the correct kernel? Why are you not using the accessor #users? Add the components PUGroupsWidget and PUUsersWidget to your Pier instance and add and edit the users/groups from the web. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From sebaspe at gmail.com Wed Oct 31 16:20:52 2007 From: sebaspe at gmail.com (=?ISO-8859-1?Q?Sebasti=E1n_Perez_Escribano?=) Date: Wed, 31 Oct 2007 12:20:52 -0300 Subject: Possible Bug? Message-ID: <47289D54.80902@gmail.com> Hi list, I?m working on Visual Works, and when a change the persistecy policy for PRImagePersistency and send #start, works. But when I add or remove a page the system crash. If I put PRNullPersistency again there is no problems. Here is the stack: BlockClosure [] in Object>>doesNotUnderstand: * optimized [] in Magritte.MAComponentRenderer>>hasError: self BlockClosure [] in Magritte.MAComponentRenderer>>hasError: *temps* each a MessageNotUnderstood self a Magritte.MATableRenderer *inst vars* method CompiledBlock [] in Magritte.MAComponentRenderer>>hasError: outerContext nil copiedValues a Magritte.MATableRenderer * OrderedCollection>>do: self OrderedCollection (a MessageNotUnderstood) *temps* aBlock BlockClosure [] in Magritte.MAComponentRenderer>>hasError: index 1 *inst vars* firstIndex 1 lastIndex 1 * Magritte.MATableRenderer(Magritte.MAComponentRenderer)>>hasError: self a Magritte.MATableRenderer *temps* aDescription a Magritte.MAPriorityContainer label: 'Add' comment: nil *inst vars* component a Magritte.MAContainerComponent html a Seaside.WARenderCanvas errors IdentitySet () * optimized [] in Magritte.MAComponentRenderer>>classFor: self BlockClosure [] in Magritte.MAComponentRenderer>>classFor: *temps* stream a WriteStream aDescription a Magritte.MAPriorityContainer label: 'Add' comment: nil self a Magritte.MATableRenderer *inst vars* method CompiledBlock [] in Magritte.MAComponentRenderer>>classFor: outerContext nil copiedValues #(a Magritte.MAPriorityContainer label: 'Add' comment: nil a Magritte.MATableRenderer) * String class(SequenceableCollection class)>>streamContents: self String *temps* blockWithArg BlockClosure [] in Magritte.MAComponentRenderer>>classFor: stream a WriteStream *inst vars* superclass CharacterArray methodDict MethodDictionary (#printOn: #hash #= #storeOn: #isLiteral #isSameXmlAs: #string #indexOfAnyOf:startingAt:ifAbsent: #withSqueakLineEndings #asDateAndTime #copyToHeap:encoding: #stringhash #asMIMEDocumentType: #compare: #asByteString #includesSubstring:caseSensitive: #asInteger #padded:to:with: #endsWith: #skipDelimiters:startingAt: #< #<= #>= #> #isString #includesSubString: #decodeAsLiteralArray #asTimeStamp #runLengthFor: #asParagraph #asText #lines #sunitMatch: #+ #caseInsensitiveLessOrEqual: #getEnclosedExpressionFrom: #asTwoByteString #asDuration #translated #copyToHeapUnicode #asDate #withoutQuoting #withSeparatorsCompacted #fullMetaName #inspectorClass #findTokens: #withBlanksTrimmed #gcCopyToHeapUnicode #sameAs: #gcCopyToHeapEncoding: #capitalized #copyToHeapEncoding: #asWordArray #changeFrom:to:with: #renderOn:indentLevel: #evaluateExpression:parameters: #concreteIndexFor: #copyToHeap: #indexOf:startingAt:ifAbsent: #convertToByteArray #encodeForHTTP #classNameOnly #refersToLiteral: #concreteString #asByteArrayEncoding: #asHexString #sunitSubStrings #prettyPrintHtmlOn:indentLevel: #asFourByteString #namesMetaClass #copyToHeap16Encoding: #trueCompare: #textRepresentation #asCapitalizedPhrase #stringEncoding #format: #isByteIndexed #asByteArray #printHtmlOn: #asClassNameOnly #asMIMEDocument #md5Hash #beginsWith: #asTime #hasChangeOfEmphasis #literalArrayEncoding #withHTMLEscapes #gcCopyToHeap16Encoding: #matches: #findDelimiters:startingAt: #renderOn: #isoToSqueak #indexOfSubCollection:startingAt: #sunitAsSymbol #adaptToString:andSend: #indexOfAnyOf:ifAbsent: #isAllSeparators )...etc... format 16384 subclasses #(ByteEncodedString TwoByteString Symbol GapString FourByteString) instanceVariables nil organization ('accessing' #changeFrom:to:with: #concreteIndexFor: #concreteString #indexOfSubCollection:startingAt: #runLengthFor: #string #stringEncoding) ('converting' #asByteArray #asByteArrayEncoding: #asByteString #asFourByteString #asParagraph #asText #asTwoByteString #asWordArray #convertToByteArray #decodeAsLiteralArray #literalArrayEncoding #withHTMLEscapes) ('comparing' #< #<= #= #> #>= #hash #sameAs:) ('te...etc... name #String classPool String asNameSpace environment Core Greetings in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071031/48bfe7bd/attachment.html From renggli at iam.unibe.ch Wed Oct 31 16:45:06 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Wed, 31 Oct 2007 16:45:06 +0100 Subject: Possible Bug? In-Reply-To: <47289D54.80902@gmail.com> References: <47289D54.80902@gmail.com> Message-ID: <6269A178-A69D-4144-B742-3848AC9DC78E@iam.unibe.ch> PRImagePersistency is very Squeak specific. I guess to make it work you would need to completely rewrite this class in VisualWorks anyway (maybe this has been done already, I don't know). I don't see how the stack you sent is related? It looks like Seaside tries to render a Magritte validation error. I recently fixed some bugs there. Cheers, Lukas On Oct 31, 2007, at 4:20 PM, Sebasti?n Perez Escribano wrote: > Hi list, > I?m working on Visual Works, and when a change the > persistecy policy for PRImagePersistency and send #start, works. But > when I add or remove a page the system crash. If I put > PRNullPersistency again there is no problems. > Here is the stack: > > BlockClosure [] in Object>>doesNotUnderstand: > ? optimized [] in Magritte.MAComponentRenderer>>hasError: > self > BlockClosure [] in Magritte.MAComponentRenderer>>hasError: > temps > each > a MessageNotUnderstood > self > a Magritte.MATableRenderer > inst vars > method > CompiledBlock [] in Magritte.MAComponentRenderer>>hasError: > outerContext > nil > copiedValues > a Magritte.MATableRenderer > ? OrderedCollection>>do: > self > OrderedCollection (a MessageNotUnderstood) > temps > aBlock > BlockClosure [] in Magritte.MAComponentRenderer>>hasError: > index > 1 > inst vars > firstIndex > 1 > lastIndex > 1 > ? Magritte.MATableRenderer(Magritte.MAComponentRenderer)>>hasError: > self > a Magritte.MATableRenderer > temps > aDescription > a Magritte.MAPriorityContainer label: 'Add' comment: nil > inst vars > component > a Magritte.MAContainerComponent > html > a Seaside.WARenderCanvas > errors > IdentitySet () > ? optimized [] in Magritte.MAComponentRenderer>>classFor: > self > BlockClosure [] in Magritte.MAComponentRenderer>>classFor: > temps > stream > a WriteStream > aDescription > a Magritte.MAPriorityContainer label: 'Add' comment: nil > self > a Magritte.MATableRenderer > inst vars > method > CompiledBlock [] in Magritte.MAComponentRenderer>>classFor: > outerContext > nil > copiedValues > #(a Magritte.MAPriorityContainer label: 'Add' comment: nil a > Magritte.MATableRenderer) > ? String class(SequenceableCollection class)>>streamContents: > self > String > temps > blockWithArg > BlockClosure [] in Magritte.MAComponentRenderer>>classFor: > stream > a WriteStream > inst vars > superclass > CharacterArray > methodDict > MethodDictionary (#printOn: #hash #= #storeOn: #isLiteral > #isSameXmlAs: #string #indexOfAnyOf:startingAt:ifAbsent: > #withSqueakLineEndings #asDateAndTime #copyToHeap:encoding: > #stringhash #asMIMEDocumentType: #compare: #asByteString > #includesSubstring:caseSensitive: #asInteger #padded:to:with: > #endsWith: #skipDelimiters:startingAt: #< #<= #>= #> #isString > #includesSubString: #decodeAsLiteralArray #asTimeStamp > #runLengthFor: #asParagraph #asText #lines #sunitMatch: #+ > #caseInsensitiveLessOrEqual: #getEnclosedExpressionFrom: > #asTwoByteString #asDuration #translated #copyToHeapUnicode #asDate > #withoutQuoting #withSeparatorsCompacted #fullMetaName > #inspectorClass #findTokens: #withBlanksTrimmed #gcCopyToHeapUnicode > #sameAs: #gcCopyToHeapEncoding: #capitalized #copyToHeapEncoding: > #asWordArray #changeFrom:to:with: #renderOn:indentLevel: > #evaluateExpression:parameters: #concreteIndexFor: #copyToHeap: > #indexOf:startingAt:ifAbsent: #convertToByteArray #encodeForHTTP > #classNameOnly #refersToLiteral: #concreteString > #asByteArrayEncoding: #asHexString #sunitSubStrings > #prettyPrintHtmlOn:indentLevel: #asFourByteString #namesMetaClass > #copyToHeap16Encoding: #trueCompare: #textRepresentation > #asCapitalizedPhrase #stringEncoding #format: #isByteIndexed > #asByteArray #printHtmlOn: #asClassNameOnly #asMIMEDocument #md5Hash > #beginsWith: #asTime #hasChangeOfEmphasis #literalArrayEncoding > #withHTMLEscapes #gcCopyToHeap16Encoding: #matches: > #findDelimiters:startingAt: #renderOn: #isoToSqueak > #indexOfSubCollection:startingAt: #sunitAsSymbol > #adaptToString:andSend: #indexOfAnyOf:ifAbsent: > #isAllSeparators )...etc... > format > 16384 > subclasses > #(ByteEncodedString TwoByteString Symbol GapString FourByteString) > instanceVariables > nil > organization > ('accessing' #changeFrom:to:with: #concreteIndexFor: #concreteString > #indexOfSubCollection:startingAt: #runLengthFor: #string > #stringEncoding) ('converting' #asByteArray #asByteArrayEncoding: > #asByteString #asFourByteString #asParagraph #asText > #asTwoByteString #asWordArray #convertToByteArray > #decodeAsLiteralArray #literalArrayEncoding #withHTMLEscapes) > ('comparing' #< #<= #= #> #>= #hash #sameAs:) ('te...etc... > name > #String > classPool > String asNameSpace > environment > Core > Greetings in advance! > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- Lukas Renggli http://www.lukas-renggli.ch