[Seaside-dev] Seaside2.8a1-lr.518 will be Seaside 2.8 final

Philippe Marschall philippe.marschall at gmail.com
Wed Oct 24 19:07:13 UTC 2007


2007/10/24, Dale Henrichs <dale.henrichs at gemstone.com>:
> Philippe,
>
> So I'm running the tests after merging Seaside2.8a1-lr.518 and I find
> that we're failing WAPlatformTest>>testAsString....Specifically '0.1'
> asString returns the 'wrong' value.

What does wrong in this case mean?

> BTW, '0.1' displayString returns the
> 'correct' value. Now I know there has been some brouhaha over
> asString/displayString, but my interpretation of the end result of the
> discussion was that asString would only be used in specific spots (like
> converting Symbols to Strings).
>
> SmallDouble>>asString (0.1 ends up being an instance of SmallDouble) is
> implemented as a primitive, so it will take a bit of monkey-business on
> my part to safely implement #asString for SmallDouble - which can be
> done ... BUT....
>
> I'm really just trying to double check whether #asString is ever
> expected to be sent to a Float in Seaside (having a test for it does
> indicate the expectation).... but it will be a whole lot easier to
> simply change the test in GemStone 2.8g1:)
>
> The only suspicious Seaside code is in
> WAUrl>>encodeParametersOn:usingHtmlEntities:, since that's the only WA*
> class that uses #asString with no qualifying comment,

Yepp, this look like the only possible sender.

> so perhaps this
> _is_ the place where a Float is expected.

These tests as well as the #displayString tests are more a precaution
measure to spot possible problems. Like this or nil. It's more to find
out what we can do and what we can't.

Cheers
Philippe

> Dale
>
> Philippe Marschall wrote:
>
> >Hi guys
> >
> >Seaside2.8a1-lr.518 will be the final version of Seaside 2.8. We
> >tested this together with Scriptaculous-lr.220, Comet-mb.23 and
> >RSRSS2-pmm.9. We won't annouce this in public before Friday 17:00 CET.
> >We included all the stuff from the VW guys except the #ifDefinded:do:.
> >We refactored one sender to use a platform specific subclass and the
> >other (SeasideAsync) does not justify an additional method in
> >SeasidePlatform support in our opinion.
> >
> >We'll open a new respository for 2.9 were all the new stuff can go in.
> >This is the resource session stuff from the VW guys, the custom
> >WAProcessMonitor and more (we didn't forget you Ramon). Eventually we
> >want to have a Universe for Seaside 2.9 in Squeak but this won't
> >happen this week.
> >
> >Cheers
> >Lukas and Philippe
> >_______________________________________________
> >seaside-dev mailing list
> >seaside-dev at lists.squeakfoundation.org
> >http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> >
> >
>
> _______________________________________________
> 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