[Seaside-dev] Re: Seaside2.8a1-mb.487
Michel Bany
michel.bany at gmail.com
Mon Oct 1 09:15:05 UTC 2007
>> If I see correctly the fix to #asFilename: means we send #asString to
>> a Symbol instead of #displayString. May I ask why? This is against
>> our
>> convention that all conversion to strings must be done with
>> #displayString. We went through a lot of pain because #displayString
>> is supposed to be working on VW contrary to #asString.
Looks as if you already sent this but I didn't get it, for some reason.
In VW, sending #displayString to #foo answers #foo, not 'foo'. This
causes
#testAsFileName to fail in VW. With my change to #asFilename:
the test pass.
Another possibility would have been to reimplement #displayString in VW
for the Symbol class to answer a string rather than a symbol as the
method
name suggests. However this could have negative side-effects on some
existing code. Maybe the other readers of this list will have an
opinion.
I do not see #displayString as a conversion method but rather as a
method
that produces string representations of objects for the user interface,
somehow similar to #printString. Also, using #displayString is a
little more
than a convention. VW does not and cannot have #asString implemented
in Object, therefore using something else than #asString for getting
string representations of objects was an obligation in order to make
Seaside
portable, rather than a convention. See below the (nearly) complete
story as
to why Seaside uses #displayString.
Cheers,
Michel
> -----Original Message-----
> From: Bany, Michel
> Sent: Thursday, April 07, 2005 12:27 PM
> To: Michael, Sherry
> Subject: RE: UndefinedObject>>asString
>
>
> > Can you please explain this a bit more, especially the
> > reasons why this was needed.
>
> Seaside is able to render any Smalltalk object into HTML based
> upon polymorphism. Rather than using #printString that is understood
> by all Smalltalk objects in VW, Avi Bryant used #asString that is
> understood by all objects in Squeak. Therefore I ended up borrowing
> this Squeak method :
>
> Object >> asString
> ^ self printString
>
> Doing this has a negative effect on GenericException >> description
> where we would like to get defaultMessageText when messageText is
nil.
> Therefore I will have to include this in the Seaside parcel.
>
> description
> "Answer the exception text."
>
> | text |
> ^ (messageText notNil and: [messageText
> respondsTo: #asString])
> ifTrue:
> [messageText asString]
> ifFalse:
> [(text := messageText value) == nil
> ifTrue: [self
> defaultMessageText]
> ifFalse: [text asString]]
>
> I can also ask Avi Bryant if he could replace all sends of #asString
> to #printString in Seaside. May be it is not too much work.
> On the other hand using #respondsTo: is usually considered as bad
> practice, so there is room for interesting discussions with
> Steve Dahl.
> -----Original Message-----
> From: Michael, Sherry
> Sent: mardi, 12. avril 2005 17:09
> To: Dahl, Steve; 'knight at acm.org'
> Cc: Bany, Michel
> Subject: FW: UndefinedObject>>asString
>
> Hi Steve and Alan,
>
> Here's an interesting issue that comes up as Michel and I are
> preparing to put StoreForSupra into the preview directory for
> VW7.4. Seaside is a conveniently large and complex bundle
> useful for testing Store implementations.
>
> For reasons listed below the Seaside-VW port needs to
> implement UndefinedObject>>asString, which has some
> unpleasant side effects.
>
> Especially as we have now included Seaside in our default set
> of things to install, I would like to have this discussion
> and come to some kind of consensus on the desired implementation.
>
> Thanks,
> Sherry
> -----Original Message-----
> From: Steve Dahl [mailto:sdahl at goshawk.com]
> Sent: mardi, 12. avril 2005 17:55
> To: Michael, Sherry
> Cc: knight at acm.org; Bany, Michel
> Subject: Re: FW: UndefinedObject>>asString
> What follows is random thoughts and uncertainty, more than a
> solution, although there's a suggestion in there if it looks
> helpful. I'll take any suggestions anyone wants to offer.
>
> I would rather that extension packages did not push #value
> and #asString up to Object. It's not safe, because it tends
> to break other code.
>
> It would be better IMO if Seaside defined in Object something
> like #squeakAsString, or #seasideAsString, which is
> implemented something like:
>
> ^(self respondsTo: #asString)
> ifTrue: [self asString]
> ifFalse: [self printString]
>
> Or this could be implemented using an MNU handler.
>
> I'm not sure this is a practical idea--we can't successfully
> prevent extensions from adding unsafe messages to Object. It
> keeps coming up, although *maybe* if we provided
> #squeakAsString and / or #squeakValue, we might be able to
> get folks to start using it. Right now, I'm just proposing it
> for consideration.
>
> The problem is that GenericException's description might be
> nil, or something that responds to #asString, or something
> that responds to #value. When one extension package moves
> #value up to Object, and another package moves #asString up
> to Object, code like
> GenericException>>description become very hard to implement.
>
> I am tempted to try to implement GenericException>>description as:
>
> text := [messageText value]
> on: MessageNotUnderstood
> do: [:x | x return: messageText].
> ^text == nil
> ifTrue: [self defaultMessageText]
> ifFalse: [text asString].
>
> Unfortunately, code that wants to be compatible with
> ObjectStudio wants
> String>>value to compile and evaluate the String. Compatibility with
> Squeak is a good thing, but compatibility with ObjectStudio
> is also one of our goals right now, and we haven't sorted out
> what it all means yet.
>
> The problem with moving #asString and #value up to Object
> (rather than defining application-specific versions of those
> methods) is that, for example, ObjectStudio and Squeak may
> not be in agreement about the semantics of those methods, and
> we may not be able to be simultaneously compatible with both
dialects.
> -----Original Message-----
> From: Bany, Michel
> Sent: mercredi, 13. avril 2005 16:59
> To: 'Steve Dahl'; Michael, Sherry
> Cc: knight at acm.org
> Subject: RE: FW: UndefinedObject>>asString
> There are hundreds of #asString sends in Seaside.
>
> Porting Seaside to VW implies filing-in a large .st file
> exported from Squeak.
> There may be some possibility to automatically replace
> #asString with #seasideAsString during file-in.
> Do you know a good place where code can be wisely
> modified right before the compile during a file-in ?
> That may work.
>
> Michel.
> -----Original Message-----
> From: Steve Dahl [mailto:sdahl at goshawk.com]
> Sent: mercredi, 13. avril 2005 18:05
> To: Bany, Michel
> Cc: Michael, Sherry; knight at acm.org
> Subject: Re: FW: UndefinedObject>>asString
>
> One way to handle this might be to convince the developers of
> Seaside to change the original application to use a more
> "vendor-neutral" selector, so that it doesn't need to be
> refactored every time it's moved to VisualWorks. The Squeak
> version would then implement
> Object>>seasideAsString as "^self asString", and VisualWorks would
> implement it as I described.
>
> Another way is to run a rewrite rule on Seaside after you file it in.
> The following file-in applies the transformation to the 'Tools-Misc'
> package. You would apply it to the various Seaside packages after the
> code has been loaded. Or if you prefer some other test for
> membership in
> Seaside, let me know and we can work something out.
>
> I'm sorry the code is so complex, but I couldn't readily find any
> documentation on how to invoke the code rewriter
> programmatically, so I
> had to work it out. It would be easier to do this rewrite in the
> browser, but if it's something you'd be doing regularly, it might be
> better to have a script that can be run without user intervention.
>
> Make sure you don't modify Object>>seasideAsString, or you'll get an
> infinite recursion.
>
>
> ------------------------------------
> | rule pkg classes |
> pkg := Registry packageNamed: 'Tools-Misc'.
> rule := ParseTreeRewriter new.
> rule replaceTree: (RBLiteralNode value: #asString)
> withTree: (RBLiteralNode value: #seasideAsString).
> rule replace: '``@object asString'
> with: '``@object seasideAsString'.
>
> classes := OrderedCollection new.
> SystemUtils allBehaviorsDo: [:beh | classes add: beh].
>
> classes do:
> [:beh |
> (pkg definedSelectorsFor: beh)
> do: [:selector || parseTree aMethod |
> aMethod := beh compiledMethodAt: selector.
> parseTree := RBParser
> parseMethod: aMethod getSource
> onError: [:str :pos |
> self halt].
> parseTree isNil
> ifTrue: [self halt].
> (rule executeTree: parseTree)
> ifTrue: [aMethod mclass
> compile: rule tree printString
> classified: aMethod
> definition protocol]]].
From: Bany, Michel
Sent: mercredi, 13. avril 2005 18:55
To: Avi Bryant (avi at beta4.com)
Subject: #asString
Hello Avi,
I am having a (small) problem porting Seaside to VisualWorks.
It all comes from #asString being implemented by Object in Squeak
and Seaside relying heavily on it.
It makes it difficult for Seaside to coexist with some other software
and
for instance has forced me to patch GenericException, a core VW class.
There are many possible solutions to this problem. Apparently the
best solution
would be to change Seaside so that it does no longer use #asString so
much
and instead would use #printString or #seasideString. There are other
solutions as you can see in the attachments. Let me know if you
cannot read
the attachments.
Could you please have a look to the attachments and let me know your
opinion.
Are you back to Canada or are you sill around in Europe ?
Thanks in advance,
Michel.
> -----Original Message-----
> From: Avi Bryant [mailto:avi.bryant at gmail.com]
> Sent: jeudi, 14. avril 2005 00:11
> To: Bany, Michel
> Subject: Re: #asString
>
> On 4/13/05, Bany, Michel <mbany at cincom.com> wrote:
>
> > There are many possible solutions to this problem.
> Apparently the best
> > solution would be to change Seaside so that it does no longer use
> > #asString so much and instead would use #printString or
> > #seasideString.
>
> This sounds reasonable. Certainly, if you prepare a patch
> for this I'll integrate it, or I'll make the changes myself
> when I get a chance.
>
> I think #seasideString (or maybe #displayString ?) would be
> better than #printString, since #printString has semantics (in
Squeak,
> anyway) that we don't usually want.
>
> > Are you back to Canada or are you sill around in Europe ?
>
> I'm in Europe at least until ESUG.
>
> Avi
> -----Original Message-----
> From: Bany, Michel
> Sent: jeudi, 14. avril 2005 18:42
> To: 'Steve Dahl'
> Cc: Michael, Sherry; knight at acm.org
> Subject: RE: FW: UndefinedObject>>asString
>
> > One way to handle this might be to convince the developers
> of Seaside
> > to change the original application to use a more "vendor-neutral"
> > selector, so that it doesn't need to be refactored every time it's
> > moved to VisualWorks. The Squeak version would then implement
> > Object>>seasideAsString as "^self asString", and VisualWorks would
> > implement it as I described.
>
> Avi Bryant is convinced and is suggesting #displayString as
> the method of choice. I do not know if this was intentional,
> since Squeak does not have this method, but it looks like a nice fit.
> The #displayString's intention in VisualWorks seems to be the
> same as Seaside's intention with #asString.
>
> This sounds promising and I will explore this path.
>
> I can keep you informed if you wish.
>
> Thanks for your advices,
> Michel.
>
> -----Original Message-----
> From: Bany, Michel
> Sent: vendredi, 15. avril 2005 11:15
> To: 'avi at beta4.com'
> Subject: RE: #asString
>
> > This sounds reasonable. Certainly, if you prepare a patch for this
> > I'll integrate it, or I'll make the changes myself when I get a
> > chance.
> >
> > I think #seasideString (or maybe #displayString ?) would be better
> > than #printString, since #printString has semantics (in Squeak,
> > anyway) that we don't usually want.
>
> Hello Avi,
>
> Unlike Squeak, VisualWorks has #displayString (you may know
> that already) and I think it is very nice fit. It seems to me
> that the intention of #displayString in VW is really close to
> the Seaside's expectation regarding #asString.
>
> Therefore I decided to give it a try. I applied the attached
> Squeak change set to Seaside 2.5b7-10. Then I made a port to
> VW from there. With a couple of small changes, I was able to
> run everything on VW without regression.
>
> I also looked at the Seaside add-ons (the "bonus pack"),
> mainly Adrian's Mewa and David's testing stuff. Ideally,
> these add-ons would require some changes, however this is not
> strictly needed because (1) #asString being still available
> in Squeak, there should not be any regresssion when running
> these add-ons in Squeak and (2) I can add some overrides
> during their port to VW.
>
> Hope you can integrate this.
>
> Another topic : when we met last time in Bern you said you
> would love to see an FTP server that would be used by the web
> designers to upload/download style sheets, javascripts etc,
> into Seaside. I am in the process of providing This
> functionality using HTTP rather than FTP. This is based on Seaside.
> Uploaded style sheets and javascripts are perceived as files
> in directories but are stored as methods in subclasses of
> WAStringLibrary. Pictures can be uploaded as well as methods
> of WAPictureLibrary subclasses.
> Does this make sense to web designers if this is not FTP ?
>
> Thanks,
> Michel.
>
> -----Original Message-----
> From: Avi Bryant [mailto:avi.bryant at gmail.com]
> Sent: vendredi, 15. avril 2005 12:08
> To: Bany, Michel
> Subject: Re: #asString
>
> On 4/15/05, Bany, Michel <mbany at cincom.com> wrote:
>
> > Therefore I decided to give it a try. I applied the attached Squeak
> > change set to Seaside 2.5b7-10. Then I made a port to VW
> from there.
> > With a couple of small changes, I was able to run everything on VW
> > without regression.
>
> Excellent. I'll integrate this soon (just have to decide
> which branch to do it in...).
>
> > Does this make sense to web designers if this is not FTP ?
>
> To some degree, but it's not ideal - the advantage of FTP is
> that text editors like BBEdit support opening and saving
> files directly over FTP. In general, FTP (and SFTP) is the
> usual way for designers to interact with remote servers, and
> all of their tools are based around it.
>
> Avi
> -----Original Message-----
> From: Avi Bryant [mailto:avi.bryant at gmail.com]
> Sent: mardi, 10. mai 2005 15:15
> To: Bany, Michel
> Subject: Re: #asString
>
> On 4/15/05, Bany, Michel <mbany at cincom.com> wrote:
>
> > Therefore I decided to give it a try. I applied the attached Squeak
> > change set to Seaside 2.5b7-10. Then I made a port to VW
> from there.
> > With a couple of small changes, I was able to run everything on VW
> > without regression.
>
> I've now integrated this into the 2.6a branch. Sorry for the
> long delay...
>
> Cheers,
> Avi
>
> -----Original Message-----
> From: Bany, Michel
> Sent: mardi, 10. mai 2005 15:40
> To: 'Steve Dahl'
> Subject: RE: FW: UndefinedObject>>asString
>
> Hi Steve,
>
> Avi Bryant just informed me that he integrated the changes we
> suggested to the Squeak version of Seaside.
>
> Seaside now uses #displayString rather than #asString.
>
> This will show up in the VisualWorks version in the near future.
>
> Michel.
More information about the seaside-dev
mailing list