Scriptacolous trouble after update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Scriptacolous trouble after update

Thomas Fischer
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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

Victor-67
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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

Victor-67
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
Reply | Threaded
Open this post in threaded view
|

RE: VW questions

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

Michael Lucas-Smith-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Scriptacolous trouble after update

Michel Bany
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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

Michel Bany
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
Reply | Threaded
Open this post in threaded view
|

RE: VW questions

Boris Popov, DeepCove Labs (SNN)
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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

keith1y
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
Reply | Threaded
Open this post in threaded view
|

RE: VW questions

Ramon Leon-5
> 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
Reply | Threaded
Open this post in threaded view
|

Re: VW questions

keith1y
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
Reply | Threaded
Open this post in threaded view
|

RE: VW questions

Ron Teitelbaum
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
Reply | Threaded
Open this post in threaded view
|

RE: VW questions

Ramon Leon-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Scriptacolous trouble after update

Thomas Fischer
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
Reply | Threaded
Open this post in threaded view
|

RE: Scriptacolous trouble after update

Bany, Michel
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