Scriptacolous trouble after update
Locked
Scriptacolous trouble after update
 
|
Hi,
I have updated to Seaside 2.7b1-mb.23 Scriptacolous-lr.220 and (now?) I have trouble with SUInsertion, SUUpdater and SUDocument . When I try to insert / update / send a small HTML fragment seaside insert the DOCTYPE, HEAD and BODY tag before it streams my HTML fragment " test" :-(a code example html button onClick: ( html evaluator callback: [ : script | script insertion top; id: mapId; with: [ :canvas | canvas heading with: 'TEST' ] ] ); with: 'test'. Any Ideas? salute Thomas |
|
|
Is this a list exclusively dedicated to Squeak or also VW questions are
welcome? I see only Squeak issues here. Is there another list dedicated to VW? How different is Seaside for Squeak from Seaside for VW? Thanks, Victor _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Thomas Fischer
Is this a list exclusively dedicated to Squeak or also VW questions are
welcome? I see only Squeak issues here. Is there another list dedicated to VW? How different is Seaside for Squeak from Seaside for VW? Thanks, Victor _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: VW questions
|
|
In reply to this post by Victor-67
It's exactly the same, Squeak versions regularly get ported "as-is". As
a matter of fact I'm a VisualWorks user myself. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Victor > Sent: Monday, October 29, 2007 12:48 PM > To: Seaside - general discussion > Subject: Re: [Seaside] VW questions > > Is this a list exclusively dedicated to Squeak or also VW questions are > welcome? I see only Squeak issues here. Is there another list > dedicated to VW? > > How different is Seaside for Squeak from Seaside for VW? > > Thanks, > Victor > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Many Cincom Smalltalk engineers watch this list.
Michael Boris Popov wrote: > It's exactly the same, Squeak versions regularly get ported "as-is". As > a matter of fact I'm a VisualWorks user myself. > > Cheers! > > -Boris > > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Scriptacolous trouble after update
|
|
In reply to this post by Thomas Fischer
On 29 Oct 2007, at 19:26 , Thomas Fischer wrote: > I have updated to > Seaside 2.7b1-mb.23 > Scriptacolous-lr.220 > Hi Thomas, Scriptaculous-lr.220 is only for Seaside 2.8. If you want to stay with Seaside 2.7 then you should pick Scriptaculous2.7-mb.220 HTH Michel. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Victor-67
On 29 Oct 2007, at 20:50 , Victor wrote: > > How different is Seaside for Squeak from Seaside for VW? They are identical. Cheers, Michel. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: VW questions
|
|
Like identical twins delivered days apart :)
-Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Michel Bany > Sent: Monday, October 29, 2007 2:52 PM > To: [hidden email]; Seaside - general discussion > Subject: Re: [Seaside] VW questions > > > On 29 Oct 2007, at 20:50 , Victor wrote: > > > > > How different is Seaside for Squeak from Seaside for VW? > > They are identical. > Cheers, > Michel. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi,
can someone explain to me my components do not know who their parents are (quickly before I put this is in!) I am struggling to see why this would be a bad idea, since without it I can see no way of enabling message routing from components. Announcements seems limited to me since if using a global announcer. I cannot see how two similar components on one page, each trying to announce something to their parents/containers would be able to. I used to use a SemanticMessage which would crawl up the hierarchy looking for its target! If a subscription was found on route then it would trigger. any thoughts would be appreciated. Keith _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Hi,
> > can someone explain to me my components do not know who their > parents are (quickly before I put this is in!) > > I am struggling to see why this would be a bad idea, since > without it I can see no way of enabling message routing from > components. It's a bad idea because it makes components that aren't reusable, they become very tightly bound to their parents. > Announcements seems limited to me since if using a global > announcer. I cannot see how two similar components on one > page, each trying to announce something to their > parents/containers would be able to. You don't have to use a global announcer, every component can have it's own announcer and you can have parents subscribe to events their children throw that they're interested in, this keeps the children loosely coupled and reusable. You could also just have a sender on the announcement to let the parent decide if the sender was a child, if you prefer a single global announcer. > any thoughts would be appreciated. > > Keith Every time I've gone down the parent path, I've regretted it. I'll stick with announcements, much better approach. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Ramon,
> It's a bad idea because it makes components that aren't reusable, > theybecome very tightly bound to their parents. > I saw that on a blog somewhere, but I am not sure I buy it. Surely they only become bound to their parents if you use the relationship over rigidly. Consider the situation anthropomorphically... If I am presently in a car, I can see and know that I am in a car. If I choose to shout then all of the car can hear me. If I am in a bus, I can see I am in a bus, and again if I shout in the bus the bus driver can hear me. However I am not chained to the bus and can take the train if I want to. When modelling physical telecomunications equipment I always implemented parent-child relationships, and certainly never regretted it. Basically I used the #parent for routing semantic messages. When a card was removed from the rack it would instanciate a SemanticMessage-cardRemoved: aCard (based upon the ideas of SemanticMessages in SmalltalkAgents) This message would move up the heirarchy looking for an object to either a) directly handle the message #cardRemoved: aCard or if the item had any subscriptions registered such that on: selector send: message to: subscriber. When the Alarm card was inserted in the rack it would register for cardRemoved: events and raise the appropriate events. theRack on: #cardRemoved: send: #cardRemovedAlarm: to: self. Subscriptions could also add arguments to a message as it passed through. I am begining to think that I might reimplement self routing SemanticMessages with a slightly more announcement like flavour for Seaside. >> Announcements seems limited to me since if using a global >> announcer. I cannot see how two similar components on one >> page, each trying to announce something to their >> parents/containers would be able to. >> > > You don't have to use a global announcer, every component can have it's own > announcer and you can have parents subscribe to events their children throw > that they're interested in, this keeps the children loosely coupled and > reusable. > How do the children find the parents announcer, if they do not know whom their parent is? I think that I am struggling to understand announcements and I cant find the original articles any longer. > You could also just have a sender on the announcement to let the parent > decide if the sender was a child, if you prefer a single global announcer. > > >> any thoughts would be appreciated. >> >> Keith >> > > Every time I've gone down the parent path, I've regretted it. I'll stick > with announcements, much better approach. > > Ramon Leon > http://onsmalltalk.com > Thanks very much for your prompt reply Keith _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Keith,
It sure sounds like the same functionality as the announcement framework. Check out: http://decenturl.com/cincomsmalltalk/vassiliannouncementsframework http://decenturl.com/lukas-renggli/decouplingseasidecomponents Happy Coding! Ron > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Keith Hodges > Sent: Monday, October 29, 2007 9:05 PM > To: Seaside - general discussion > Subject: Re: [Seaside] VW questions > > Hi Ramon, > > > It's a bad idea because it makes components that aren't reusable, > > theybecome very tightly bound to their parents. > > > I saw that on a blog somewhere, but I am not sure I buy it. Surely they > only become bound to their parents if you use the relationship over > rigidly. > > Consider the situation anthropomorphically... If I am presently in a > car, I can see and know that I am in a car. If I choose to shout then > all of the car can hear me. If I am in a bus, I can see I am in a bus, > and again if I shout in the bus the bus driver can hear me. However I am > not chained to the bus and can take the train if I want to. > > When modelling physical telecomunications equipment I always implemented > parent-child relationships, and certainly never regretted it. Basically > I used the #parent for routing semantic messages. > > When a card was removed from the rack it would instanciate a > SemanticMessage-cardRemoved: aCard (based upon the ideas of > SemanticMessages in SmalltalkAgents) This message would move up the > heirarchy looking for an object to either a) directly handle the message > #cardRemoved: aCard or if the item had any subscriptions registered such > that on: selector send: message to: subscriber. > > When the Alarm card was inserted in the rack it would register for > cardRemoved: events and raise the appropriate events. > > theRack on: #cardRemoved: send: #cardRemovedAlarm: to: self. > > Subscriptions could also add arguments to a message as it passed through. > > I am begining to think that I might reimplement self routing > SemanticMessages with a slightly more announcement like flavour for > Seaside. > >> Announcements seems limited to me since if using a global > >> announcer. I cannot see how two similar components on one > >> page, each trying to announce something to their > >> parents/containers would be able to. > >> > > > > You don't have to use a global announcer, every component can have it's > own > > announcer and you can have parents subscribe to events their children > throw > > that they're interested in, this keeps the children loosely coupled and > > reusable. > > > And this was what led me to wondering how on earth this works at all. > > How do the children find the parents announcer, if they do not know whom > their parent is? > > I think that I am struggling to understand announcements and I cant find > the original articles any longer. > > You could also just have a sender on the announcement to let the parent > > decide if the sender was a child, if you prefer a single global > announcer. > > > > > >> any thoughts would be appreciated. > >> > >> Keith > >> > > > > Every time I've gone down the parent path, I've regretted it. I'll > stick > > with announcements, much better approach. > > > > Ramon Leon > > http://onsmalltalk.com > > > > Thanks very much for your prompt reply > > Keith > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by keith1y
> I saw that on a blog somewhere, but I am not sure I buy it.
> Surely they only become bound to their parents if you use the > relationship over rigidly. Sending direct message to parents is what causes the problem. If you're just crawling the hierarchy looking for a handler, I can see how that is less rigid. > Consider the situation anthropomorphically... If I am > presently in a car, I can see and know that I am in a car. If > I choose to shout then all of the car can hear me. If I am in > a bus, I can see I am in a bus, and again if I shout in the > bus the bus driver can hear me. However I am not chained to > the bus and can take the train if I want to. If a component can see and know it's parent (which I've done myself), the temptation t send message to that parent are overwhelming and soon, you can't use any other parent. The component becomes glued to its context. > When modelling physical telecomunications equipment I always > implemented parent-child relationships, and certainly never > regretted it. Basically I used the #parent for routing > semantic messages. > When a card was removed from the rack it would instanciate a > SemanticMessage-cardRemoved: aCard (based upon the ideas of > SemanticMessages in SmalltalkAgents) This message would move > up the heirarchy looking for an object to either a) directly > handle the message > #cardRemoved: aCard or if the item had any subscriptions > registered such that on: selector send: message to: subscriber. This requires too much discipline for me, I'd rather shout "I'm removed" and let the context handle it appropriately, which may mean not at all. If interested people have already subscribed... I don't need to climb anything, I just shout "I'm removed". > > You don't have to use a global announcer, every component can have > > it's own announcer and you can have parents subscribe to > events their > > children throw that they're interested in, this keeps the children > > loosely coupled and reusable. > > > And this was what led me to wondering how on earth this works at all. > > How do the children find the parents announcer, if they do > not know whom their parent is? You've got it backwards, children just announce using their own announcer. The parent *knows* it's children and registered as a listener for any announcements they make when it created them. The child has no need to know the parent. A wheel doesn't know what car it's on, it works on any car. > Thanks very much for your prompt reply > > Keith No problem, I've struggled with the parent thing myself, even added parents to my own components for a while, but I just find it too inflexible when I want to use the component somewhere else. Parents registering to child events is just so much more loosely coupled and easy to assemble than children knowing their parents in my experience. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Scriptacolous trouble after update
|
|
In reply to this post by Michel Bany
Hi,
now I use Seaside2.7b1-mb.23 and Scriptacolous2.7-mb.220 but I have the same Problem: html button onClick: ( html evaluator callback: [ : script | script insertion top; id: mapId; with: [ :canvas | canvas heading with: 'TEST' ] ] ); with: 'test'. response should: =========== new Insertion.Top('id3167003223',' TEST')response is: ======== new Insertion.Top('id3167003223','<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\r"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title>Seaside</title><meta content="text/html; charset=utf-8" http-equiv="Content-Type" /></head><body> TEST')salute Thomas |
RE: Scriptacolous trouble after update
|
|
Hi Thomas,
This bug is fixed in Scriptaculous2.7-mb.221. Sorry I didn't spot it myself. And thanks for the report, Michel. > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf > Of Thomas Fischer > Sent: mardi, 30. octobre 2007 11:34 > To: [hidden email] > Subject: Re: [Seaside] Scriptacolous trouble after update > > > Hi, > > now I use Seaside2.7b1-mb.23 and Scriptacolous2.7-mb.220 but > I have the same > Problem: > > html button > onClick: ( html evaluator > callback: [ : script | > script insertion top; id: mapId; > with: [ :canvas | canvas heading with: 'TEST' ] > ] > ); with: 'test'. > > response should: > =========== > new Insertion.Top('id3167003223','<h1>TEST</h1>') > > response is: > ======== > new Insertion.Top('id3167003223','<!DOCTYPE html PUBLIC > "-//W3C//DTD XHTML 1.0 > Transitional//EN"\r"http://www.w3.org/TR/xhtml1/DTD/xhtml1-tra > nsitional.dtd"><html > lang="en" xml:lang="en" > xmlns="http://www.w3.org/1999/xhtml"><head><title>Seaside</title><meta > content="text/html; charset=utf-8" http-equiv="Content-Type" > /></head><body><h1>TEST</h1>') > > salute > Thomas > -- > View this message in context: > http://www.nabble.com/Scriptacolous-trouble-after-update-tf471 > 3610.html#a13485855 > Sent from the Squeak - Seaside mailing list archive at Nabble.com. > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |