[Seaside] JSObject printOn:

[Julian Fitzell]

The current code assumes that every "load script" responds to
#greaseString, which we have defined semantically (I think) as
returning an un-truncated text representation of the *data* of the
object. I don't immediately see why we couldn't implement
#greaseString on JSObject and change the result of #printOn: to be
more helpful in an inspector. Or am I missing a part of the picture?

Julian

On Tue, Dec 22, 2009 at 4:29 AM, Lukas Renggli <renggli at gmail.com> wrote:
>> Shouldn't JSObject>>printOn: be something else, so printOn: can show
>> information in the inspector? And
>
> The use of #printOn: has legacy reasons.
>
>> addLoadScript: anObject
>>        loadScripts := loadScripts copyWith: anObject.
>>        ^ anObject
>>
>> could more meaningfully reference aJSObject ?
>
> Also it makes it possible to use any objects (like strings themselves)
> can be added as load scripts. Furthermore it avoids a naughty
> dependency: #addLoadScript: is in Seaside-Core, while JSObject is in
> an optional extra package.
>
>> As we rely on examples instead of documentation, these little things can
>> really impede 'getting' what a class is doing, IMHO.
>
> You are not the first one to complain about the (mis)use of #printOn:.
> Personally, I don't think it is too bad: it clearly communicates what
> the object is representing, a proxy for the Javascript representation
> it prints to.
>
> I agree that it would probably be better to change it to something like
>
>    a JSObject(mock)
>
> where in brackets the Javascript representation is given.
> Unfortunately this is not easily possible given the wide application
> of this pattern in various internal and external Seaside Javascript
> libraries for over 4 years now.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>