JSObject printOn:
Locked
 
|
Hi, throughout the system, printOn: appears to be used to provide meaningful information about an object for developers. In particular, it's what you see in an inspector.
Am I right in thinking that in JSObject and JSJoin it is more of a rendering method? For example, you if try to use JSRenderingTest>>#testScript as an example, you get the detail attached. you have anObject, and the details shown are mock. mockdetail.png Shouldn't JSObject>>printOn: be something else, so printOn: can show information in the inspector? And addLoadScript: anObject loadScripts := loadScripts copyWith: anObject. ^ anObject could more meaningfully reference aJSObject ? As we rely on examples instead of documentation, these little things can really impede 'getting' what a class is doing, IMHO. Cheers, ...Stan |
|
|
> 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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks for the explanation. I think we'll have to agree to disagree on I suspect it clearly represents something when you have been using it for 4 years. ;) So would the following be a valid comment for #addLoadScript:? addLoadScript: anObject "anObject is any object which replies to #printOn: with valid javascript. usually it will be a JSObject or a string. example: html document addLoadScript: 'message()'. will render: <script type="text/javascript">/*<![CDATA[*/function onLoad(){message()}/*]]>*/</script>" loadScripts := loadScripts copyWith: anObject. ^ anObject Cheers, ...Stan |
|
|
In reply to this post by Lukas Renggli
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 <[hidden email]> 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Stan Shepherd
Along the same lines, WAScriptTag>>with: aString self attributes at: 'type' ifAbsentPut: [ 'text/javascript' ]. super with: [ aString isNil ifFalse: [ self document nextPutAll: aString greaseString ] ] is called by WAHtmlCanvas>>script: aBlock self script with: aBlock so the parameter changes from Block to String in the passing. Am I right in thinking aBlock should be aString? ...Stan |
|
|
I renamed #printOn: and #printContentOn: to #javascriptOn: and
#javascriptContentOn: in subclasses of JSObject with the latest commit series. All functional tests and examples continue to work. People that subclassed JSObject in external projects need to perform that renaming too, otherwise their code will break. Lukas 2009/12/24 Stan Shepherd <[hidden email]>: > > > Stan Shepherd wrote: >> >> >> Lukas Renggli wrote: >>> >>> Also it makes it possible to use any objects (like strings themselves) >>> can be added as load scripts. >>> >> So would the following be a valid comment for #addLoadScript:? >> >> addLoadScript: anObject >> "anObject is any object which replies to #printOn: with valid javascript. >> usually it will be a JSObject or a string. >> example: >> html document >> addLoadScript: 'message()'. >> will render: >> <script type="text/javascript">/*<![CDATA[*/function >> onLoad(){message()}/*]]>*/</script>" >> >> loadScripts := loadScripts copyWith: anObject. >> ^ anObject >> >> Cheers, ...Stan >> >> > > > Along the same lines, > WAScriptTag>>with: aString > self attributes > at: 'type' > ifAbsentPut: [ 'text/javascript' ]. > super with: > [ aString isNil ifFalse: [ self document nextPutAll: aString greaseString > ] ] > > is called by > WAHtmlCanvas>>script: aBlock > self script with: aBlock > > so the parameter changes from Block to String in the passing. Am I right in > thinking aBlock should be aString? > ...Stan > > > -- > View this message in context: http://n4.nabble.com/JSObject-printOn-tp976924p978210.html > Sent from the Squeak - Seaside mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks, that looks much clearer. ...Stan |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |