[Seaside-dev] Re: Seaside2.8a1-mb.487
Philippe Marschall
philippe.marschall at gmail.com
Mon Oct 1 11:33:45 UTC 2007
2007/10/1, Michel Bany <michel.bany at gmail.com>:
> >> 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.
That was probably my mistake. I assumed you were subscribed to this
list when I sent this mail some time ago.
> 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.
Yeah, unless you have classboxes like Gemstone/S this semantical
change is likely to break stuff.
> 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.
So basically neither #displayString nor #asString will ever work.
Which just means we will have to introduce our own method for string
conversion that is used by no other Smalltalk (or wait for ANSI,
*jk*). This doesn't really take me by surprise to so I have a concrete
proposal: #toString. Yes, it's Java-esque but this is good thing since
it means that we have no conflicts with existing dialects.
Cheers
Philippe
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
More information about the seaside-dev
mailing list