Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WATree is broken #195

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 6 comments
Closed

WATree is broken #195

GoogleCodeExporter opened this issue Mar 25, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

1. go to /seaside/tests/alltests
2. go to WATreeFunctionalTest
3. click '+' nothing happends
4. click 'Collection' an exception happends

The problem seems to be that although the message send contains the right
arguments the actual message that is sent does not.

I tried this with both Pharo and Squeak 3.10.2, same behavior.

What makes me nervous about this is that we use a lot MessageSends in other
places as well.

Original issue reported on code.google.com by philippe...@gmail.com on 4 Oct 2008 at 1:30

@GoogleCodeExporter
Copy link
Author

Works without using MessageSend.

MessageSend without argument(s) are working fine!

Original comment by obi...@gmail.com on 5 Oct 2008 at 6:18

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

- Something like this in WATRee
MessageSend receiver: self selector: #select: argument: aNode
does not work because
WAActionCallback evaluateWithArgument: anObject
 sends valueWithPossibleArgument: anObject  (anObject = '' in that case)
valueWithPossibleArgument: anArg 
    self numArgs = 0 ifTrue: [^self value].
    self numArgs = 1 ifTrue: [^self value: anArg].
..

In that case sending numArgs to the MessageSend instance gives you 1,
So it is using value: '' instead of value.
Thats the reason why the argument "aNode" is lost!

- Removed the MessageSend refs in WATRee

Original comment by obi...@gmail.com on 5 Oct 2008 at 6:47

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Alternatively, we could change our implementation of 
#valueWithPossibleArgument: to
only use the parameter if there are not enough arguments in the MessageSend to 
fill
the selector. In other words, check "self numArgs - arguments size".

We can even call #valueWithEnoughArguments:, though I bet that's a Squeak 
extension,
so we probably can't. :)

What does anyone think? This behaviour seems more logical to me at first glance 
and
means we don't have to worry about making arbitrary restrictions like "but you 
can't
use a MessageSend".

Original comment by jfitz...@gmail.com on 7 Oct 2008 at 8:15

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I'd rather wanna know why it suddenly broke than invent a way to hack around it.

Original comment by philippe...@gmail.com on 8 Oct 2008 at 4:50

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

It's not a quick way around it.

The change to WAActionCallback>>evaluateWithArgument: (it used to call #value)
happened in Seaside-Core-jf-164 and Seaside-Core-jf-165. We want to provide the 
value
of the GET or POST parameter to the action callback block if they want it, but 
most
of the time when you are writing an action callback you don't care.

I just think our implementation of MessageSend>>valueWithPossibleArgument: is 
buggy.
If the message send has already been parameterized, then by definition, there 
are no
possible arguments slots. What I don't know is if there are other parts of the 
code
that would be broken by this behaviour (I suspect not, because it's kind of 
illogical
to want to override the arguments specified in the MessageSend).

Name: Seaside-Core-jf.164
Author: jf
Time: 14 July 2008, 2:13:46 am
UUID: a43e950f-083b-e145-a771-90a30169a632
Ancestors: Seaside-Core-jf.163

Allow action callbacks access to the value given in the URL if they pass in a
one-argument block (needed to allow SUCallback to be side-effect free)

Name: Seaside-Core-jf.165
Author: jf
Time: 14 July 2008, 2:24:03 am
UUID: 31a42a97-3f83-f649-9284-09092072fb1f
Ancestors: Seaside-Core-jf.164

Oops... #valueWithPossibleArgument *is* made available on ported platforms so 
we can
use it. It's only the variant that takes multiple arguments that is unavailable.

Original comment by jfitz...@gmail.com on 8 Oct 2008 at 7:58

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Name: Seaside-Squeak-Platform-jf.16
Author: jf
Time: 18 October 2008, 12:29:36 pm
UUID: 6875a521-d29f-f14b-8b9a-24b64435f09e
Ancestors: Seaside-Squeak-Platform-lr.15

Name: Seaside-Tests-Platform-jf.6
Author: jf
Time: 18 October 2008, 12:29:53 pm
UUID: ba44255c-3fda-6345-8adf-7349ca3e37e5
Ancestors: Seaside-Tests-Platform-jf.5

Fix for http://code.google.com/p/seaside/issues/detail?id=195

MessageSend>>valueWithPossibleArgument: was moved from the Core package to the
Squeak-Platform package and its behaviour was changed so that it first uses any
arguments stored within the MessageSend and, only if there are still empty 
argument
slots in the selector, uses the passed argument.

WAPlatformTest>>testMessageSendValueWithPossibleArgument was updated to test 
more
thoroughly to catch this behaviour




Name: Seaside-Core-jf.284
Author: jf
Time: 18 October 2008, 12:26:42 pm
UUID: 6df6287f-6bce-124d-847e-06d22ae31bba
Ancestors: Seaside-Core-jf.283

Move MessageSend>>valueWithPossibleArgument: from Core package to 
Squeak-Platform package

Original comment by jfitz...@gmail.com on 18 Oct 2008 at 10:31

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant