[Seaside] JSObject printOn:
jfitzell at gmail.com
Tue Dec 22 16:08:26 UTC 2009
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?
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
> it prints to.
> I agree that it would probably be better to change it to something like
> a JSObject(mock)
> Unfortunately this is not easily possible given the wide application
> libraries for over 4 years now.
> Lukas Renggli
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside