as in the blog view? but I suspect this design intentional, for the RSS feed? ? PS. NetNewsWire gets Doru's feed but not the one from my local image. Vienna seems to accept both, but an online validator wasn't too happy with the feed? -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org From keith_hodges at yahoo.co.uk Tue Nov 20 01:14:53 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Tue, 20 Nov 2007 00:14:53 +0000 Subject: [ANN] MAAutoCompletingTextInputComponent Message-ID: <474226FD.30505@yahoo.co.uk> enjoy Keith ---------------- Name: Magritte-Scriptaculous-kph.4 Author: kph Time: 20 November 2007, 12:13:56 am UUID: 7bfbcf14-96fd-11dc-9bf8-000a95edb42a Ancestors: Magritte-Scriptaculous-kph.3 MAAutoCompletingTextInputComponent From jason.johnson.081 at gmail.com Tue Nov 20 07:41:27 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 20 Nov 2007 07:41:27 +0100 Subject: Dynamic descriptions In-Reply-To: References:

Message-ID: Ah, nice. I should have thought of that. :) Thanks for your help. On Nov 19, 2007 10:24 PM, Lukas Renggli wrote: > > Now of course what happens is, if I click edit first then the fields > > are always read only and vice versa if I click new first, due to > > caching. That is, it works perfectly.... the first use, and from then > > on #description is called. Before I fought with this anymore I > > thought I would check if there is a simpler way to do what I'm trying > > to do. > > No, that's the usual way to do. > > Since the description are cached, you have to make a copy before > changing it: > > e copy beReadonly; yourself > > Cheers, > 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 Nov 20 07:48:32 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 20 Nov 2007 07:48:32 +0100 Subject: Strange behavior with MAToManyRelationDescription Message-ID: Hello all, I am building a form that consists of two components, e.g. House and Person. For each of these, when a new one is created I register it. I have a manager class that displays these using: MAToManyRelationDescription new classes: (Array with: House); label: 'Houses'; accessor: (MASelectorAccessor new readSelector: #houses; writeSelector: nil; yourself); default: Array new; priority: 20; yourself People is similar. The Manager class is a form, but with no buttons as it is only needed to let the add buttons work on these relation descriptions. The accessor shown here, houses just calls "House instances" to get currently registered houses. I subclass MACheckedMemento and create a custom memento that simply overrides the #push: method to see if the object is new (no members will be set) and if so, registers the object after called "super push:". Everything is fine except for Houses, after I create a new hause the main display always shows 2. If I leave the page and visit new I see only one. I have looked around but I dont see how this is happening. Any ideas? From renggli at iam.unibe.ch Tue Nov 20 21:36:46 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Tue, 20 Nov 2007 21:36:46 +0100 Subject: Strange behavior with MAToManyRelationDescription In-Reply-To: References: Message-ID: Hi, > I am building a form that consists of two components, e.g. House and > Person. For each of these, when a new one is created I register it. what do you register? And -- when you create new ones -- you have more than two components? I don't quite get it ... > I have a manager class that displays these using: That's the form? > MAToManyRelationDescription new > classes: (Array with: House); > label: 'Houses'; > accessor: (MASelectorAccessor new > readSelector: #houses; > writeSelector: nil; > yourself); > default: Array new; > priority: 20; > yourself > > People is similar. The Manager class is a form, but with no buttons > as it is only needed to let the add buttons work on these relation > descriptions. The accessor shown here, houses just calls "House > instances" to get currently registered houses. I subclass > MACheckedMemento and create a custom memento that simply overrides the > #push: method to see if the object is new (no members will be set) and > if so, registers the object after called "super push:". Why don't you write your manager class manually and display the editors for houses and persons as children? You can use the #onAnswer: handler of the Magritte components to get notified when the user hits add (save). I don't quite understand why you need MAToManyRelationDescription and a custom MACheckedMemento. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From jason.johnson.081 at gmail.com Tue Nov 20 22:14:25 2007 From: jason.johnson.081 at gmail.com (Jason Johnson) Date: Tue, 20 Nov 2007 22:14:25 +0100 Subject: Strange behavior with MAToManyRelationDescription In-Reply-To: References:

Message-ID: Sorry, I was in a hurry because I had to get off the train. :) Ok, I have a Person class and a House class. Each of these has a class side method called #register: that stores the instance in an ordered collection of the class side. Person and House both have full descriptions and are capable of displaying themselves, so the "manager" class just allows one to make many of these. So the use case is, you see the first page, it has a list of Persons and a list of Houses, these are queried from the instances registered with the class (i.e. in the class side collection variable). The user clicks "add" on, say, Person. Now they get the Person page, as described by the Person class, they type in there information and click "Save". This is where I need the custom memento (and tell me if I'm doing this wrong): If you click save that winds up calling "commit" on the memento and actually writing the data to the object, but this new object wont be registered in the class side collection (and therefor will simply cease to exist when this session expires). So my custom memento simply lets everything work as normal and then calls "Person register: self model" to get the new object registered. The problem happens when "save" returns on Person and you go back to the manager page. You see your nice new Person in the report table as expected, but right below is the same Person again! And if you edit either one the changes reflect in both. And the really hairy thing is, even though House is almost exactly the same in every way (I can find no relevant difference) it doesn't have this behavior. (couple of comments below as well) On Nov 20, 2007 9:36 PM, Lukas Renggli wrote: > > That's the form? Below was the description that the manager uses to show the list of Houses. > > MAToManyRelationDescription new > > classes: (Array with: House); > > label: 'Houses'; > > accessor: (MASelectorAccessor new > > readSelector: #houses; > > writeSelector: nil; > > yourself); > > default: Array new; > > priority: 20; > > yourself > > > Why don't you write your manager class manually and display the > editors for houses and persons as children? You can use the #onAnswer: > handler of the Magritte components to get notified when the user hits > add (save). Hrm, I thought that's what I was doing. The above description is saved in the manager as a component under houseComponent and is returned from the children method of the manager. But I will go look up uses of onAnswer to try and figure out what you mean. From keith_hodges at yahoo.co.uk Wed Nov 21 01:20:11 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Wed, 21 Nov 2007 00:20:11 +0000 Subject: [Ann] Dependencies between form elements in the GUI Message-ID: <474379BB.3090704@yahoo.co.uk> Hello, At present magritte is a little limited when you have two form fields which are related in some way. I have come up with a scheme which works, suggestions are of course very welcome. Here is an example from the top.... description0020ServiceType ^ MASingleOptionDescription new accessor: ((#serviceType asAccessor) update: #serviceTypeChangedTo:); reference: MAClassDescription new; options: [ DTIServiceTypes allSubclasses ] asDynamicObject; default: DTIDeliveryWholesale; componentClass: MASelectListComponentSU ; beRequired; bePersisted; yourself Service type is select list which changes the values in other fields in the form, when the users switches it. 1. The first innovation is the setting of the priority in the method selector name. I have used this for 3 days and it works really well. (Enhancement available in Magritte-CustomBuilder package) 2. The second innovation is ((#serviceType asAccessor) update: #serviceTypeChangedTo:) This is shorthand for... (MASelectorAccessor read: #serviceType write: #serviceType:) propertyAt: #update put: (MASelectorAccessor write: #serviceTypeChangedFix:) So we have normal access to the datamodel via the reading and writing accessors, this is the sort of accessing that persisting (and mementos) would use, but GUI elements can use additional optional update accessor. #serviceTypeChangedTo: will modify other fields in the model. (Well actually the model's memento but we will come to that). Where GUI elements used to write to objects using the standard Object-#write:using: there is now an #Object-#update:using: which uses the update accessor if present. 3. RealMementos The problem with the way that the Gui does mementos now is that it operates on a dictionary of the models data. The mementos have no awareness of the model itself. Enter MARealMemento... This uses a dictionary checks as before BUT importantly read/writes from the GUI are performed upon a real copy of the model, which is returned upon commit/save. It also has methods (not yet used) #snapshot, and #hasChangedSinceSnapshot, which the gui can us in order to only up date items which have changed since the previous update. This means that the update methods can modify the values in other fields and the GUI will see these changes if it is re-rendered using Scriptaculous. Two caveats are that items being edited by an InternalEditor will will need to a) have an MAStraitMemento so that they operate directly on the same model (since they are in the same UI) and (b) the internally edited objects must be modified not replaced (since the InternalEditor currently has and is likely to keep a reference to the object itself) 4. MASelectListComponentSU The scriptaculous addition to the standard select list component, calls the #update: accessor when the users changes the selection, and it renders updateContentOn: of the containing MAContainerComponent. So the display of all fields is refreshed. I have one other refinement... (not yet implemented in this form) 5. Modifying readonly isVisible accessor: ((#check asAccessor) readonly: #isCheckDisabled); accessor: ((#check asAccessor) visible: #isCheckVisible); The code so far is available in Magritte-RealMemento , Magritte-Scriptaculous, Magritte-CustomBuilder I think that this potentially moves magritte up a level in user-interactivity enjoy Keith From girba at iam.unibe.ch Thu Nov 22 13:53:59 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 22 Nov 2007 13:53:59 +0100 Subject: css and firefox Message-ID: Hi, I have the following problem with CSS and Firefox On http://moose.unibe.ch I have a CSS file that is pointed to as stylesheet from the root page. On Safari 3.0 and on Internet Explorer it looks Ok, but on Firefox it looks as if the CSS cannot be found. What could the problem be? Cheers, Doru -- www.tudorgirba.com www.tudorgirba.com/blog "Next time you see your life passing by, say 'hi' and get to know her." From girba at iam.unibe.ch Thu Nov 22 13:55:36 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 22 Nov 2007 13:55:36 +0100 Subject: blog rss Message-ID: Hi again, I have a blog moose.unibe.ch/news, but the RSS link points to localhost. What could be the problem? I should say that there is an Apache rewrite rule that forwards moose.unibe.ch to localhost. Cheers, Doru -- www.tudorgirba.com www.tudorgirba.com/blog "One cannot do more than one can do." From damien.pollet at gmail.com Thu Nov 22 14:21:53 2007 From: damien.pollet at gmail.com (Damien Pollet) Date: Thu, 22 Nov 2007 14:21:53 +0100 Subject: css and firefox In-Reply-To: References: Message-ID: <34b4844b0711220521l2c995518rcc4b776e7a7111e0@mail.gmail.com> Nice design :) Using the Web Inspector from Safari, it seems all the CSS files are served with MIME type text/html, that might be the problem? On 22/11/2007, Tudor Girba wrote: > Hi, > > I have the following problem with CSS and Firefox > > On http://moose.unibe.ch I have a CSS file that is pointed to as > stylesheet from the root page. On Safari 3.0 and on Internet Explorer > it looks Ok, but on Firefox it looks as if the CSS cannot be found. > What could the problem be? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org From cbeler at enit.fr Thu Nov 22 14:45:13 2007 From: cbeler at enit.fr (cbeler@enit.fr) Date: Thu, 22 Nov 2007 14:45:13 +0100 (CET) Subject: css and firefox In-Reply-To: <34b4844b0711220521l2c995518rcc4b776e7a7111e0@mail.gmail.com> References: <34b4844b0711220521l2c995518rcc4b776e7a7111e0@mail.gmail.com> Message-ID: <55654.193.51.2.185.1195739113.squirrel@www.enit.fr> >> Hi, >> >> I have the following problem with CSS and Firefox true.. no css in my page... with firebug I see in the head where the css is linked an arror: 1

Error: "/seaside/moose/seaside/files/WAStandardFiles/halo.css" not found.

probably because in the address /seaside/moose/seaside/files/ there shouldn't be /seaside/moose/ I don't know if it's due to the apache conf or anything else... hth C?drick >> >> On http://moose.unibe.ch I have a CSS file that is pointed to as >> stylesheet from the root page. On Safari 3.0 and on Internet Explorer >> it looks Ok, but on Firefox it looks as if the CSS cannot be found. >> What could the problem be? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> _______________________________________________ >> SmallWiki, Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > -- > Damien Pollet > type less, do more [ | ] http://typo.cdlm.fasmz.org > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki From cbeler at enit.fr Thu Nov 22 14:47:03 2007 From: cbeler at enit.fr (cbeler@enit.fr) Date: Thu, 22 Nov 2007 14:47:03 +0100 (CET) Subject: css and firefox In-Reply-To: <55654.193.51.2.185.1195739113.squirrel@www.enit.fr> References: <34b4844b0711220521l2c995518rcc4b776e7a7111e0@mail.gmail.com> <55654.193.51.2.185.1195739113.squirrel@www.enit.fr> Message-ID: <55692.193.51.2.185.1195739223.squirrel@www.enit.fr> oh it works now.... it seems you fixed it ;) From girba at iam.unibe.ch Thu Nov 22 14:55:40 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 22 Nov 2007 14:55:40 +0100 Subject: css and firefox In-Reply-To: <55692.193.51.2.185.1195739223.squirrel@www.enit.fr> References: <34b4844b0711220521l2c995518rcc4b776e7a7111e0@mail.gmail.com> <55654.193.51.2.185.1195739113.squirrel@www.enit.fr> <55692.193.51.2.185.1195739223.squirrel@www.enit.fr> Message-ID: <7EF8CAE0-AA68-420E-98CE-2296992565B7@iam.unibe.ch> Indeed, it was due to an Apache setting: the /seaside/files were not passed on. Thanks for looking into it :). Doru On Nov 22, 2007, at 2:47 PM, cbeler at enit.fr wrote: > oh it works now.... it seems you fixed it ;) > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com www.tudorgirba.com/blog "One cannot do more than one can do." From girba at iam.unibe.ch Fri Nov 23 22:29:55 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 23 Nov 2007 22:29:55 +0100 Subject: image persistency Message-ID: Hi, I am trying to make ImagePersistency with seasidehosting, but it does not work, because the code seems to try to access '/' instead of the directory of the image. I know that at least seaside.st is on seasidehosting, and I was wondering how did you solve this issue. I attached here the debug log I got. -------------- next part -------------- A non-text attachment was scrubbed... Name: SqueakDebug.log Type: application/octet-stream Size: 1875 bytes Desc: not available Url : http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20071123/3fe7a250/SqueakDebug-0001.obj -------------- next part -------------- Doru -- www.tudorgirba.com www.tudorgirba.com/blog "From an abstract enough point of view, any two things are similar." From damien.pollet at gmail.com Wed Nov 28 23:42:55 2007 From: damien.pollet at gmail.com (Damien Pollet) Date: Wed, 28 Nov 2007 23:42:55 +0100 Subject: Notifying structures of editions Message-ID: <34b4844b0711281442i783348d7t7fc3b1e657df9289@mail.gmail.com> Hi, When editing a structure, accessors are called via Magritte but there is no way for the structure to reinitialize itself before any accessor is called, or to re-establish its invariant after all accessors have been called. I thought I'd wrap PRCommand>>doExecute with something like self structure willEdit and self structure didEdit, would that make sense? I also saw PRStructure>>validateCommand which shouldn't modify the structure, but in my case (Citezen) validating means parsing that takes time and I'd prefer not to repeat that work when committing the edition to the structure. I think writing this helped me see a solution: - validation does the heavy parsing and stores result in (an adhoc subclass of) the edit command - executing the command stores parsed data in the structure and resets the final data - a lazy accessor for the final data builds it and ditches the parsed data hopefully that was clear? if you have suggestions? -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org From renggli at iam.unibe.ch Thu Nov 29 07:54:07 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 07:54:07 +0100 Subject: small changes to pier-blog, pier-math In-Reply-To: <34b4844b0711191545h3125be81pa2037eed63acfae0@mail.gmail.com> References: <34b4844b0711191545h3125be81pa2037eed63acfae0@mail.gmail.com> Message-ID: > Two detail changes? > - I made pier-math generate transparent PNGs (imperfectly but that's > dvipng not doing what its man page says) That's cool. Thanks for the contribution. > - individual blog posts are now wrapped in the same

> as in the blog view? but I suspect this design intentional, for the > RSS feed? ? I don't see any change here, but it looks ok to me. > PS. NetNewsWire gets Doru's feed but not the one from my local image. > Vienna seems to accept both, but an online validator wasn't too happy > with the feed? Why is the validator unhappy? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Thu Nov 29 08:16:29 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 08:16:29 +0100 Subject: Notifying structures of editions In-Reply-To: <34b4844b0711281442i783348d7t7fc3b1e657df9289@mail.gmail.com> References: <34b4844b0711281442i783348d7t7fc3b1e657df9289@mail.gmail.com> Message-ID: > When editing a structure, accessors are called via Magritte but there > is no way for the structure to reinitialize itself before any accessor > is called, or to re-establish its invariant after all accessors have > been called. It is possible to create a subclass of PREditCommand and override #doExecute to trigger some postprocessing. > I thought I'd wrap PRCommand>>doExecute with something like self > structure willEdit and self structure didEdit, would that make sense? Exactly. > I think writing this helped me see a solution: > - validation does the heavy parsing and stores result in (an adhoc > subclass of) the edit command > - executing the command stores parsed data in the structure and resets > the final data > - a lazy accessor for the final data builds it and ditches the > parsed data > > hopefully that was clear? if you have suggestions? Generally getting notified about events is a bit of a problem in Pier. Several things (such as creating new structures, persistency, etc) are quite, because this triggers events in rather clumsy ways. I once rewrote part of this mess using announcements, which provides a significant improvement over the current status but also breaks/ changes certain things. Unfortunately I lost the image, but if I have time I probably redo it. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Thu Nov 29 08:00:01 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 08:00:01 +0100 Subject: Strange behavior with MAToManyRelationDescription In-Reply-To: References:

Message-ID: <3FC3F4A7-B28E-4D7D-8E74-7E2252928729@iam.unibe.ch> > Ok, I have a Person class and a House class. Each of these has a > class side method called #register: that stores the instance in an > ordered collection of the class side. Person and House both have full > descriptions and are capable of displaying themselves, so the > "manager" class just allows one to make many of these. Ok, got it. > This is where I need the custom memento (and tell me if I'm doing this > wrong): If you click save that winds up calling "commit" on the > memento and actually writing the data to the object, but this new > object wont be registered in the class side collection (and therefor > will simply cease to exist when this session expires). So my custom > memento simply lets everything work as normal and then calls "Person > register: self model" to get the new object registered. Sure that's a possibility, but why not use the return value if you are using #call: or set an #onAnswer: handler if you are using composition? So in your manager you have something along: house := self call: House new asComponent. house ifNotNil: [ House register: house ]. or (in case of composition): editor := House new asComponent onAnswer: [ :house | house ifNotNil: [ House register: house ]. editor := nil ] > The problem happens when "save" returns on Person and you go back to > the manager page. You see your nice new Person in the report table as > expected, but right below is the same Person again! And if you edit > either one the changes reflect in both. And the really hairy thing > is, even though House is almost exactly the same in every way (I can > find no relevant difference) it doesn't have this behavior. Looks like your memento method gets called twice? Why not check if the object is already present? Why not use a Set then? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Thu Nov 29 08:08:36 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 08:08:36 +0100 Subject: [Ann] Dependencies between form elements in the GUI In-Reply-To: <474379BB.3090704@yahoo.co.uk> References: <474379BB.3090704@yahoo.co.uk> Message-ID: <5131F470-1965-458E-918C-EC242B3584D4@iam.unibe.ch> > The problem with the way that the Gui does mementos now is that it > operates on a dictionary of the models data. The mementos have no > awareness of the model itself. Enter MARealMemento... This uses a > dictionary checks as before BUT importantly read/writes from the GUI > are > performed upon a real copy of the model, which is returned upon > commit/save. How do you edit existing objects then? How do you copy objects? How do you handle other parts of the model that reference these objects? > I think that this potentially moves magritte up a level in > user-interactivity It is certainly an interesting approach to a valid problem. I tried to add similar things a couple of years ago, but eventually gave up as it was introducing more problems than it solved. I found that it was much easier to achieve the same using multiple steps or manually composed Magritte components. Of course, especially with todays acceptance of AJAX, this becomes interesting again. I am very interested in your progress and interested to include it in the core, if it works well in a general setup. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From renggli at iam.unibe.ch Thu Nov 29 08:11:46 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 08:11:46 +0100 Subject: image persistency In-Reply-To: References: Message-ID: Hi Doru, > I am trying to make ImagePersistency with seasidehosting, but it > does not work, because the code seems to try to access '/' instead > of the directory of the image. I know that at least seaside.st is on > seasidehosting, and I was wondering how did you solve this issue. I think this has come up before. Also in the context of using the Magma object database. The problem is that saving the image tries to iterate over the directory tree, what is restricted on seasidehosting.st. I thought this issue was resolved? Or is there a patch that needs to be loaded? I don't remember. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From damien.pollet at gmail.com Thu Nov 29 09:46:41 2007 From: damien.pollet at gmail.com (Damien Pollet) Date: Thu, 29 Nov 2007 09:46:41 +0100 Subject: small changes to pier-blog, pier-math In-Reply-To: References: <34b4844b0711191545h3125be81pa2037eed63acfae0@mail.gmail.com> Message-ID: <34b4844b0711290046h361bc2bfo9b511289ed82a562@mail.gmail.com> > > - individual blog posts are now wrapped in the same

> > as in the blog view? but I suspect this design intentional, for the > > RSS feed? ? > > I don't see any change here, but it looks ok to me. you mean no code in the commit or no visible result ? that should render the exact same bolg view, add the

in the post view, and I think the method that rendered the inside of this div was also used for the RSS, so now unless it is ignered by RSRSS, there would be the div in the RSS too. > > PS. NetNewsWire gets Doru's feed but not the one from my local image. > > Vienna seems to accept both, but an online validator wasn't too happy > > with the feed? > > Why is the validator unhappy? I don't remember, I used http://feedvalidator.org/ -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org From girba at iam.unibe.ch Thu Nov 29 10:00:53 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Thu, 29 Nov 2007 10:00:53 +0100 Subject: image persistency In-Reply-To: References:

Message-ID: <21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> Hi Lukas, >> I am trying to make ImagePersistency with seasidehosting, but it >> does not work, because the code seems to try to access '/' instead >> of the directory of the image. I know that at least seaside.st is on >> seasidehosting, and I was wondering how did you solve this issue. > > I think this has come up before. Also in the context of using the > Magma object database. The problem is that saving the image tries to > iterate over the directory tree, what is restricted on > seasidehosting.st. I thought this issue was resolved? Or is there a > patch that needs to be loaded? I don't remember. Do you have any idea of who should we ask? :) Doru -- www.tudorgirba.com www.tudorgirba.com/blog "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From renggli at iam.unibe.ch Thu Nov 29 19:53:07 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Thu, 29 Nov 2007 19:53:07 +0100 Subject: image persistency In-Reply-To: <21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> References:

<21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> Message-ID: <573F9E31-825A-4A15-8971-C2706A524048@iam.unibe.ch> >>> I am trying to make ImagePersistency with seasidehosting, but it >>> does not work, because the code seems to try to access '/' instead >>> of the directory of the image. I know that at least seaside.st is on >>> seasidehosting, and I was wondering how did you solve this issue. >> >> I think this has come up before. Also in the context of using the >> Magma object database. The problem is that saving the image tries to >> iterate over the directory tree, what is restricted on >> seasidehosting.st. I thought this issue was resolved? Or is there a >> patch that needs to be loaded? I don't remember. > > Do you have any idea of who should we ask? :) I was wrong, this wasn't discussed on the Magritte mailing-list, but on the internal one of seasidehosting.st. Maybe Keith Hodges knows more, how he solved the problem in the end. He wrote at that time: > Creating a repository worked for me once, but now it fails again. > > Still stuck on: aFileDirectory assureExistence Otherwise Adrian Lienhard might certainly be able to help. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Thu Nov 29 17:44:35 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Thu, 29 Nov 2007 16:44:35 +0000 Subject: image persistency In-Reply-To: <21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> References:

<21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> Message-ID: <474EEC73.3030703@yahoo.co.uk> Tudor Girba wrote: > Hi Lukas, > > >>> I am trying to make ImagePersistency with seasidehosting, but it >>> does not work, because the code seems to try to access '/' instead >>> of the directory of the image. I know that at least seaside.st is on >>> seasidehosting, and I was wondering how did you solve this issue. >>> >> I think this has come up before. Also in the context of using the >> Magma object database. The problem is that saving the image tries to >> iterate over the directory tree, what is restricted on >> seasidehosting.st. I thought this issue was resolved? Or is there a >> patch that needs to be loaded? I don't remember. >> Magma should be happy being given a relative path. The problem reported seems to be when using Image Persistency Keith From keith_hodges at yahoo.co.uk Fri Nov 30 06:19:28 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 30 Nov 2007 05:19:28 +0000 Subject: Strugging with Commands Message-ID: <474F9D60.6010606@yahoo.co.uk> I am struggling to write a command which edits a model, rather than the command instance itself. I am trying to do it this way since the model class and description may change whereas the command class does not. PREditUser-asComponent | component | component := self model asComponent. ^ component addValidatedForm: (Array with: self saveButton with: self cancelButton); onAnswer: [ :value | [ self execute ] on: Error do: [:err | ^ component errors add: err. ]. value storeOnDB. self context: self answer "<< References: <474F9D60.6010606@yahoo.co.uk> Message-ID: > I am struggling to write a command which edits a model, rather than > the > command instance itself. I am trying to do it this way since the model > class and description may change whereas the command class does not. Why do you use a command then? As described in the GOF book, this design pattern is used to encapsulate an action and its parameters. > [code] > > The problem that I am having is that the standard onAnswer: for > commands > is implemented by the containing Contents Widget somewhere else and I > cant see any way of overriding it. I neither understand your code nor the sentence above ;-) Is the problem that Seaside doesn't allow to have multiple onAnswer: handlers? I guess this is something that should be fixed ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From girba at iam.unibe.ch Fri Nov 30 13:03:49 2007 From: girba at iam.unibe.ch (Tudor Girba) Date: Fri, 30 Nov 2007 13:03:49 +0100 Subject: image persistency In-Reply-To: <474EEC73.3030703@yahoo.co.uk> References:

<21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> <474EEC73.3030703@yahoo.co.uk> Message-ID: <37B342BC-BC79-48FA-8F57-27823CD662A5@iam.unibe.ch> Hi, The problem is indeed when using ImagePersistency. As I understood, this is also the solution behind seaside.st which also stays on seasidehosting.st. So, I was just wondering how is it actually solved. Maybe seaside.st has a special treatment on seasidehosting? Cheers, Doru On Nov 29, 2007, at 5:44 PM, Keith Hodges wrote: > Tudor Girba wrote: >> Hi Lukas, >> >> >>>> I am trying to make ImagePersistency with seasidehosting, but it >>>> does not work, because the code seems to try to access '/' instead >>>> of the directory of the image. I know that at least seaside.st is >>>> on >>>> seasidehosting, and I was wondering how did you solve this issue. >>>> >>> I think this has come up before. Also in the context of using the >>> Magma object database. The problem is that saving the image tries to >>> iterate over the directory tree, what is restricted on >>> seasidehosting.st. I thought this issue was resolved? Or is there a >>> patch that needs to be loaded? I don't remember. >>> > Magma should be happy being given a relative path. > > The problem reported seems to be when using Image Persistency > > Keith > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -- www.tudorgirba.com www.tudorgirba.com/blog "Obvious things are difficult to teach." From renggli at iam.unibe.ch Fri Nov 30 13:40:56 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Fri, 30 Nov 2007 13:40:56 +0100 Subject: image persistency In-Reply-To: <37B342BC-BC79-48FA-8F57-27823CD662A5@iam.unibe.ch> References:

<21961A4A-912F-4F43-B056-DBAA01F4BA58@iam.unibe.ch> <474EEC73.3030703@yahoo.co.uk> <37B342BC-BC79-48FA-8F57-27823CD662A5@iam.unibe.ch> Message-ID: <585AB25D-67FA-4FBB-8E32-98B47B1517C1@iam.unibe.ch> > So, I was just wondering how is it actually solved. Maybe seaside.st > has a special treatment on seasidehosting? Indeed, www.seaside.st does not run on the restricted VM. Actually it uses the same setup as the management application www.seasidehosting.st. Lukas -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Fri Nov 30 19:29:08 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 30 Nov 2007 18:29:08 +0000 Subject: Strugging with Commands In-Reply-To: References: <474F9D60.6010606@yahoo.co.uk> Message-ID: <47505674.2070407@yahoo.co.uk> Lukas Renggli wrote: >> I am struggling to write a command which edits a model, rather than >> the >> command instance itself. I am trying to do it this way since the model >> class and description may change whereas the command class does not. >> > > Why do you use a command then? As described in the GOF book, this > design pattern is used to encapsulate an action and its parameters. > > It does encapsulate an action. The problem being that commands as they are can only act upon themselves. Keith From renggli at iam.unibe.ch Fri Nov 30 19:35:45 2007 From: renggli at iam.unibe.ch (Lukas Renggli) Date: Fri, 30 Nov 2007 19:35:45 +0100 Subject: Strugging with Commands In-Reply-To: <47505674.2070407@yahoo.co.uk> References: <474F9D60.6010606@yahoo.co.uk> <47505674.2070407@yahoo.co.uk> Message-ID: <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> >>> I am struggling to write a command which edits a model, rather than >>> the >>> command instance itself. I am trying to do it this way since the >>> model >>> class and description may change whereas the command class does not. >>> >> >> Why do you use a command then? As described in the GOF book, this >> design pattern is used to encapsulate an action and its parameters. > > It does encapsulate an action. The problem being that commands as they > are can only act upon themselves. Why do you think that? All commands I know act on other objects, mostly on structures in Pier. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch From keith_hodges at yahoo.co.uk Fri Nov 30 20:08:58 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 30 Nov 2007 19:08:58 +0000 Subject: Strugging with Commands In-Reply-To: <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> References: <474F9D60.6010606@yahoo.co.uk> <47505674.2070407@yahoo.co.uk> <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> Message-ID: <47505FCA.8080002@yahoo.co.uk> A simpler solution: PRContentsWidget-buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | self onAnswerCommand: (aContext command onReturn: value) ]; yourself PRCommand-onReturn: value ^ value This gives commands an opportunity to handle the form's reply, returning a command for the PRContents widget to #execute. I think this is a better solution. Keith From keith_hodges at yahoo.co.uk Fri Nov 30 19:45:57 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 30 Nov 2007 18:45:57 +0000 Subject: Strugging with Commands In-Reply-To: <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> References: <474F9D60.6010606@yahoo.co.uk> <47505674.2070407@yahoo.co.uk> <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> Message-ID: <47505A65.4000307@yahoo.co.uk> Lukas Renggli wrote: >>>> I am struggling to write a command which edits a model, rather than >>>> the >>>> command instance itself. I am trying to do it this way since the >>>> model >>>> class and description may change whereas the command class does not. >>>> >>>> >>> Why do you use a command then? As described in the GOF book, this >>> design pattern is used to encapsulate an action and its parameters. >>> >> It does encapsulate an action. The problem being that commands as they >> are can only act upon themselves. >> > > Why do you think that? All commands I know act on other objects, > mostly on structures in Pier. > > Cheers, > Lukas > I must choose my words more carefully: they can only display themselves, since the value returned from the component must be a command or nil. Here is my solution.... PRContentsWidget-i-buildComponent: aContext ^ aContext command asComponent onAnswer: [ :value | aContext command onAnswerValue: value to: self ]; yourself PRCommand-i-onAnswerValue: componentReturnValue to: widget "componentReturnValue is typically but not necessarily a command" componentReturnValue isNil ifTrue: [ ^ widget context: (widget context structure: widget context structure) ]. [ componentReturnValue execute ] on: Error do: [ :err | Preferences debugPierFormErrors ifTrue: [ err pass ]. ^ widget component errors add: err. ]. widget context: componentReturnValue answer ========= what do you think? Keith From keith_hodges at yahoo.co.uk Fri Nov 30 23:34:15 2007 From: keith_hodges at yahoo.co.uk (Keith Hodges) Date: Fri, 30 Nov 2007 22:34:15 +0000 Subject: Pier-Jetsam and PRViewToEditCommand In-Reply-To: <47505FCA.8080002@yahoo.co.uk> References: <474F9D60.6010606@yahoo.co.uk> <47505674.2070407@yahoo.co.uk> <6D8C6F39-5B6F-42F0-BAE9-6585C44EE3C6@iam.unibe.ch> <47505FCA.8080002@yahoo.co.uk> Message-ID: <47508FE7.70508@yahoo.co.uk> Hello, PRViewToEditCommand displays a read only display of the supplied model, with Edit/Cancel buttons. Clicking Edit, goes to an editable version of the same form, with a Save/Cancel button. PRViewToEditCommand is a subclass of PRAction, a subclass of PRCommand, which expects to display an editor for a supplied model. This addition has been made available in a new "Pier-Jetsam" package for some pier/magritte base add ons, where some of the base pier extensions (i.e. from my previous email) can await potential inclusion in the main release. I have also moved Pier-Debugging over into Pier-Jetsam. Pier-Jetsam includes some logging of pier events, so it depends upon Logging which in turn depends upon Kernel-Extensions Installer ss project: '311'; install:'Kernel-Extensions'. Installer ss project: 'Logging'; install:'Logging'. best regards Keith