WAInspector>>#evaluate nonportable

[GoogleCodeExporter]

Should probably use a method in SeasidePlatformSupport

Original issue reported on code.google.com by renggli on 2 Mar 2008 at 8:10

[GoogleCodeExporter]

It's probably a better solution to simply move WAInspector to Seaside-Squeak-
Development and WAInspectorPlugin to Seaside-Squeak-Development-Core-Plugins.  
This 
aligns it with the other platform-dependent tools.

While the port of WAInspector/WAInspectorPlugin to VA Smalltalk did not require 
any 
changes to WAInspectorPlugin, it did require changes to WAInspector that could 
not 
be contained by simply invoking a SeasidePlatformSupport method.

Original comment by [email protected] on 17 Jun 2008 at 7:11

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

[GoogleCodeExporter]

I wouldn't complain if WAInspector was platform specific ... I've ended up
customizing the inspector for GemStone/S anyway...

Original comment by [email protected] on 17 Jun 2008 at 7:52

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

[GoogleCodeExporter]

Niall, John and Dale discussed this a bit.  John agreed that WAInspectorPlugin 
could 
stay where it is (in Development-Core).  WAInspector though does need to move 
to a 
platform-specific package.  The design decision this is whether to provide a 
WAAbstractInspector as a super class which would hold the methods assumed to be 
common to all implementations.

John will do a first cut of an implementation and share it with Dale for 
comment/modification.  

Original comment by [email protected] on 29 Aug 2008 at 1:42

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

[GoogleCodeExporter]

Original comment by [email protected] on 30 Aug 2008 at 3:45

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

[GoogleCodeExporter]

The pattern seems to be that if a tool is platform-specific, then the tool and 
the 
plugin for the tool reside in the platform-specific package.  This is 
presumably so 
the tool can be completely optional for a particular platform.  However, I 
think 
that an inspector is (or should be) a requirement.  Therefore, I will move only 
WAInspector to the platform-specific package and reference it from 
WAInspectorPlugin 
through 'SeasidePlatformSupport inspectorClass'.

Original comment by [email protected] on 8 Sep 2008 at 5:39

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

[GoogleCodeExporter]

BAD IDEA.  #inspectorClass is implemented on Object with a completely different 
(although related) meaning.  So, I guess I will switch to 
SeasidePlatformSupport >> 
#seasideInspectorClass.

Original comment by [email protected] on 8 Sep 2008 at 6:04

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

[GoogleCodeExporter]

Original comment by [email protected] on 8 Sep 2008 at 6:26

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

[GoogleCodeExporter]

Sorry I took this issue from you, but you set to started 20 days ago and there 
is no 
fix. So I took the liberty. I moved WAIspector to Seaside-Squeak-Development 
and 
added the #seasideInspectorClass to SeasidePlatformSupport. I also moved the 
#inspector fields method to Seaside-Squeak-Development.

Name: Seaside-Development-Core-pmm.63
Author: pmm
Time: 28 September 2008, 12:33:06 pm
UUID: 333bf31a-ff9b-4b9f-94ff-f103a3c8f3a0
Ancestors: Seaside-Development-Core-lr.62

- http://code.google.com/p/seaside/issues/detail?id=1
- moved WAInspector to Seaside-Squeak-Development

Name: Seaside-Squeak-Development-pmm.22
Author: pmm
Time: 28 September 2008, 12:34:05 pm
UUID: 2f7870bb-a9ba-4261-a448-4cc471d18185
Ancestors: Seaside-Squeak-Development-jf.21

- http://code.google.com/p/seaside/issues/detail?id=1
- moved WAInspector to Seaside-Squeak-Development
- moved Object >> #inspectorFields to Seaside-Squeak-Development
Name: Seaside-Core-pmm.255
Author: pmm
Time: 28 September 2008, 12:34:44 pm
UUID: 956e8a6e-7510-482f-afd1-102664998849
Ancestors: Seaside-Core-jf.254

- http://code.google.com/p/seaside/issues/detail?id=1
- moved Object >> #inspectorFields to Seaside-Squeak-Development

Name: Seaside-Component-pmm.9
Author: pmm
Time: 28 September 2008, 12:35:39 pm
UUID: a35cce07-ed62-4672-b085-9eafc640d146
Ancestors: Seaside-Component-jf.8

- http://code.google.com/p/seaside/issues/detail?id=1
- moved Object >> #inspectorFields to Seaside-Squeak-Development so WATree 
example 
had to be fixed


Name: Seaside-Tests-Development-pmm.3
Author: pmm
Time: 28 September 2008, 12:36:38 pm
UUID: 13cef22e-f20a-4a7d-b424-fc44bb3bbc81
Ancestors: Seaside-Tests-Development-jf.2

- http://code.google.com/p/seaside/issues/detail?id=1
- added test for SeasidePlatformSupport class >> #seasideInspectorClass

Name: Seaside-Tests-All-pmm.14
Author: pmm
Time: 28 September 2008, 12:37:21 pm
UUID: 48a96ee2-7ff3-4a4c-b1f4-7b14aca0c59a
Ancestors: Seaside-Tests-All-jf.13

- http://code.google.com/p/seaside/issues/detail?id=1
- moved Object >> #inspectorFields to Seaside-Squeak-Development so test had to 
go 
as well


Name: Seaside-Tests-Squeak-All-pmm.5
Author: pmm
Time: 28 September 2008, 12:39:02 pm
UUID: d924df9f-5ac8-4cc3-92e6-6252bc3791f5
Ancestors: Seaside-Tests-Squeak-All-jf.4

- http://code.google.com/p/seaside/issues/detail?id=1
- moved Object >> #inspectorFields to Seaside-Squeak-Development so test had to 
move 
here

Original comment by [email protected] on 28 Sep 2008 at 10:44

• Changed state: Fixed
• Added labels: Type-Portability, Version-Seaside2.9
• Removed labels: Type-Defect

[GoogleCodeExporter]

I wonder if we really want to force porters to implement a 
#seasideInspectorClass. I suggest to do it like with 
WABrowser, move everything to Seaside-Squeak-Development. This reduces the 
number of dependencies and 
makes porting easier.

Original comment by renggli on 28 Sep 2008 at 11:20

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

[GoogleCodeExporter]

I apologize for the time I had this in Started status -- I was away from the 
office 
on an extended business trip followed by a vacation week, all without internet 
access, and only returned yesterday.

I had actually decided to move WAInspector and WAWalkback to Seaside-Squeak-
Development-Core; WAInspectorPlugin to Seaside-Squeak-Development-Core-Plugins; 
and 
add walkbackClass (or seasideWalkbackClass) to WASqueakPlatform.

Doing this would correct all the porting issues I have with these 3 classes 
(there 
used to be more, but some of the WA...Walkback classes have gone away) and 
seems to 
mirror the structure of the other tool plugins with platform dependencies.  
Comments?

Original comment by [email protected] on 6 Oct 2008 at 7:33

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

[GoogleCodeExporter]

Marking this issue Started again since there seems to still be discussion 
ongoing.

(no need to have #seasideWalkbackClass, I think, since it's only implemented on 
a
seaside object... I realize we needed #seasideInspectorClass to avoid 
conflicting
with an existing method)

Original comment by [email protected] on 6 Oct 2008 at 8:11

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

[GoogleCodeExporter]

Original comment by [email protected] on 6 Oct 2008 at 8:54

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

[GoogleCodeExporter]

OK, finally done.

Name: Seaside-Development-jok.14
Author: jok
Time: 10 October 2008, 2:33:23 pm
UUID: 03211995-5b64-8f43-90dc-cb7e01747af1
Ancestors: Seaside-Development-jok.13

-http://code.google.com/p/seaside/issues/detail?id=1

WAInspectorPlugin and WAWalkback moved to Seaside-Squeak-Development

Name: Seaside-Squeak-Development-jok.27
Author: jok
Time: 10 October 2008, 2:59:01 pm
UUID: 324933ea-0f58-ed45-87ab-0c887f2ef29d
Ancestors: Seaside-Squeak-Development-obi.26

- http://code.google.com/p/seaside/issues/detail?id=1

- Move WAInspectorPlugin and WAWalkback from Seaside-Development to 
Seaside-Squeak-
Development.
- Add walkbackClass to resolve reference from WAWalkbackErrorHandler to 
WAWalkback

Name: Seaside-Tests-Squeak-Development-jok.3
Author: jok
Time: 10 October 2008, 3:35:06 pm
UUID: 3afd489c-0f50-e64c-b102-40e8bd166e26
Ancestors: Seaside-Tests-Squeak-Development-jf.2

- http://code.google.com/p/seaside/issues/detail?id=1

- swap out testSeasideInspectorClass for testWalkbackClass 

Original comment by [email protected] on 10 Oct 2008 at 7:42

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

[GoogleCodeExporter]

Re: comment 9 from Lukas ...  There still is a new factory class on 
SeasidePlatformSupport -- I guess I could have kept going with moving classes, 
but 
this seemed like a logical stopping place since it resolved the porting issue

Original comment by [email protected] on 10 Oct 2008 at 7:45

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

[GoogleCodeExporter]

Since we are moving more and more of the unportable tools to the platforms and 
let
them reimplement them would it make sense to move WAWalkbackErrorHandler (which 
is
almost empty) there instead of having #walkbackClass in SeasidePlatformSupport?

Original comment by [email protected] on 11 Oct 2008 at 4:08

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

[GoogleCodeExporter]

I guess that depends pretty much on whether we are "demanding" that porters 
implement
a walkback error handler. If not, then it certainly might as well move.

If we expect all ports to have that handler, it's a bit funny to have them all
reimplement it...

The other option would be to have WAInspector in the non-platform-specific 
package
that defines the protocol and have a class-var that a platform-specific package 
can
register itself in.

But I don't feel strongly about any of the solutions.

Original comment by [email protected] on 11 Oct 2008 at 4:25

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

[GoogleCodeExporter]

I like the idea of at least a skeleton of the implementation sitting in the 
core (or
dev) packages ... Like the inspector, there are only a handful of things that 
need to
be ported and the rest of the implementation is fine ... so unless the class is
completely empty, I'd be inclined to leave it there...

I also like the idea of registering platform-specific implementations...makes it
possible to have multiple inspectors or debuggers (production vs development) 
even in
the platform-specific case.

Original comment by [email protected] on 11 Oct 2008 at 4:44

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

[GoogleCodeExporter]

Reopened since there still seems to be discussion on how best to address the 
problem.

Original comment by [email protected] on 13 Oct 2008 at 1:37

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

[GoogleCodeExporter]

OK, I have thought about this some more and I have decided that the initial 
problem 
(portability) is fixed.  I'm not sure I want to tackle the registration of 
platform-
specific tool implementations, so I will leave it to someone else to open a new 
issue if they still feel strongly about this.

Original comment by [email protected] on 27 Oct 2008 at 2:18

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

[GoogleCodeExporter]

I created Issue 221 so we don't lose track of the rest of the stuff that came 
up here.

Original comment by [email protected] on 27 Oct 2008 at 2:53

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