September 2014 - Pharo-dev - lists.pharo.org

WhatsUp from: 2014-09-01 until: 2014-09-14

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-09-14 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Sept. 1, 2014

Re: [Pharo-dev] NeoJSON Mapping name-changing field

by Sean P. DeNigris

Sean P. DeNigris wrote > I ended up with FlickApiResponse class>>neoJsonMapping: mapper... It turns out the Flickr API returns slightly weird JSON responses - the status is on the same level as possible multiple data attributes, so I ended up with (even uglier): neoJsonMapping: mapper mapper for: self customDo: [ :mapping | mapping decoder: [ :dict | | dataDict | dataDict := Dictionary new. (dict keys reject: [ :k | k = 'stat']) do: [ :k | dataDict at: k put: (dict at: k) ]. self new status: (dict at: 'stat'); data: dataDict; yourself ] ] ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545p4775552… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

Re: [Pharo-dev] NeoJSON Mapping name-changing field

by Sean P. DeNigris

Sean P. DeNigris wrote > How do I handle mapping this second field with NeoJSONReader? Thanks I ended up with FlickApiResponse class>>neoJsonMapping: mapper mapper for: self customDo: [ :mapping | mapping decoder: [ :dict | self new status: (dict at: 'stat'); data: (dict at: dict keys first); yourself ] ] but maybe there's a more elegant way? ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545p4775547… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

NeoJSON Mapping name-changing field

by Sean P. DeNigris

The Flickr API returns a JSON object with two fields: 'status' and otherField, where the name of otherField depends on the API method. How do I handle mapping this second field with NeoJSONReader? Thanks ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

Re: [Pharo-dev] Latch for Pharo (Opinion needed)

by garduino

Thanks for your opinion Sean. I agree that this sort of solution is a must in our days. My idea is develop the SDK in a way that be the more agnostic as possible, but I not think in Amber yet. Thanks for the suggestion. Cheers. -- View this message in context: http://forum.world.st/Latch-for-Pharo-Opinion-needed-tp4775525p4775540.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

Re: [Pharo-dev] Latch for Pharo (Opinion needed)

by Sean P. DeNigris

garduino wrote > a product/service to add a degree of security to web applications I don't know anything about Latch specifically, but I've been at a loss when writing Smalltalk web apps for a pre-packaged solution to this common problem, and would really appreciate a standard, well-tested option! One tiny request - it would be great if you could make it framework-agnostic. Now that we have e.g. Amber and Seaside, it's frustrating that many great web libraries are coupled to Seaside and can not be used in Amber. I've been dreaming about extracting a common HTML tag library... Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Latch-for-Pharo-Opinion-needed-tp4775525p4775539.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

When all you have is Spec, everything looks like a nail?

by Sean P. DeNigris

I've been mulling this over for a while, and since we've been having conversations about Spec's place in our future... DISCLAIMER: this is a visceral experience I've been having over a long period of time, so it may not be factually "true" or current, but I present it as a contribution, if only by someone saying "you're full of crap because..." and we all learn something. The purpose of Spec as I understand it is to both come up with a nice streamlined UI API, and to make multiple targets (e.g. Morphic, html) possible with the same codebase. These are both important goals. And it seems we've made some progress at least in the first case. I definitely enjoy working with Spec's API far more that e.g. PolyMorph. Spec could be a very valuable application-level tool. If I want to write a business application, I can write once via a nice API and deploy "anywhere". Life is good. My discomfort is with making *all* our core tools Spec-based. While it is great from an "eating our own dog food perspective", one of the great principles of Morphic is exploration and discoverability. Many times before Spec I was able to poke around a tool, figure out how it worked, and apply that lesson to my own UI. However, with Spec I find it extremely difficult to figure out WTH is going on. Parsing of arrays of symbols seems to have replaced Smalltalk code, and each field/model piece of a Spec UI seems to be buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now that we have e.g. specialized inspectors, we might be able to alleviate this. My 2c. ----- Cheers, Sean -- View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nai… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014