Greetings,
Thank you David and the others that gave me suggestions here. Using a combination of Repaintable, and the other advice enabled me to get this working. (I also was missing some of the libraries I needed. Thanks Nick.) Sorry that it took so long to get back to this, but working on this internal app is secondary to my primary Support duties at Cincom. :-) Again, thanks for the help folks. James T. Savidge, [[hidden email]], Friday, August 19, 2011 -- Dont worry Bob. Heres what to do. ... Raise the Exception, walkback, and nobody gets hurt. David explains his framework for repainting Seaside components in an earlier post: 2010/9/3 C. David Shaffer <[hidden email]>: (...) > Here's the problem: During an AJAX callback (request, update or script) > sometimes a component unrelated to the one making the callback needs to > be repainted. Normally this happens as the result of an announcement. > While announcements serve to decouple the components they also prevent > the source of the announcement from knowing to cause this other > component to paint. > > Basically this motivates using Comet but I don't like Comet and find > that I don't need Comet's level of "server push" for any of my > applications. What I need is simply the way tack a little extra > javascript on the end of AJAX calls... > > My solution: Repaintable in the Cincom Public Store Repository. (This > package uses JQuery.) It is a very simple framework so easily abandoned > if it is the wrong thing to do Here's how it works: Components > subclass RPRepaintable (or you merge RPRepaintable's methods into your > component hierarchy if that isn't possible). You must also use > RPSession or a subclass as your session class for your application. > When a component wants to append javascript onto the end of the current > response to an AJAX request it: other alternatives that I can use. Wouldn't it make sense to support this "out-of-the-box" in Seaside? Kind regards Runar On 05/10/2011 09:24 PM, [hidden email] wrote: > On Tuesday, 10 May 2011, <[hidden email]> wrote: >> > Greetings, >> > >> > Despite trying to follow the suggestions I have seen in the discussions and in >> > the documentation, I cant seem to get onClick notifications to work on >> > checkbox(s) or multiSelect. >> > >> > My goal is to present the user with a list of selections, and when they click >> > on one of the items in the list, I want to refresh a secondary list with data >> > that is related to selection they made in the first list. Something similar to what I wrote below is what has worked for me in the past using Pharo/Gemstone & Seaside 3. When using checkboxes you probably want onClick rather than onChange because IE does not register the change until the checkbox loses focus. I haven't tried a multiselect. And there is likely a better/cleaner way to do this. renderUpdatingCheckbox:html |id | html checkbox id: (id := html nextId); value: cbox; onClick: ((html jQuery ajax) serializeThisWithHidden; script: [ :s | s << (s jQuery id: 'target-div') load: [ :h | self renderTarget: h ] ]); callback: [ :value | cbox:=value ]. html label for: id; with: 'checkbox test'. html div id:'target-div'; with:[self renderTarget: html]. renderTarget: html cbox ifTrue:[html render:'Box is checked'] ifFalse:[html render:'Box is not checked'] If you want to test the above you'd need an ivar in your component named #cbox. Also I'm not sure about this but I thought that if you use labels rather than the trailing #with: your user can click the entire label to trigger the change in the check box. Paul _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |