Recently I was trying to puzzle out how to provide some descriptions on
some objects that changed based on other descriptions. A concrete example of this is: a Flickr photo, with two descriptions: - photo ID - which JPG size to use The second description depends on the first -- one can't retrieve the available sizes to choose from without first getting the photo ID. So I did a bit of Googling around, and came across an On Smalltalk [1] article, where it mentioned something about this: > Generally speaking you'll keep these descriptions on the class side of > your domain object. On occasion, you'll want some property of the > description to be dynamic and depend on the actual value of an instance > side value, so you'll move the description to the instance side. > Strictly speaking, it doesn't matter where you put them, sometimes > you'll use them to build forms when you don't even have a domain object, > but this isn't the normal case. Then I did some further looking, and found some tutorial [2] that actually gives some information on doing this (without Pier). It seems like in general (based on this tutorial) you implement #descriptionEdit, and then grab that when handling the editing function in whatever UI you choose. That said, I've been struggling to figure out how I can do this with a PRWidget in Pier. There seems to be some way of doing it with a PRStructure, as PRFile provides editing capabilities on a text-based file by overriding #editDescription. But I'm not sure how it would work with a PRWidget, or if it is even possible. Basically, I would envision it as follows in the UI, continuing with the Flickr photo example: - Create a new photo widget - Edit the photo widget -- the size property either does not show or is not populated - Input a photo ID - Either submit the form, or have something realize it has what it needs to populate the next field and transmit the data without a page refresh - Select the photo size, and submit Is there any way of accomplishing this with the existing support for Magritte in Pier? Or is this something that could be (or should be) hacked into PRWidget? Or am I going about this in a completely wrong way? Any advice would be much appreciated. Thanks, Joel [1] http://onsmalltalk.com/using-magritte-with-seaside [2] http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?chapter=10#part4 _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
I am not sure if you have seen the Magritte FAQ? The website is
currently offline, but you can see the page in the web archive: http://web.archive.org/web/20080615132619/http://www.lukas-renggli.ch/smalltalk/magritte/faq Does that help? Lukas On 31 December 2010 09:57, Joel Kitching <[hidden email]> wrote: > Recently I was trying to puzzle out how to provide some descriptions on some > objects that changed based on other descriptions. > > A concrete example of this is: a Flickr photo, with two descriptions: > - photo ID > - which JPG size to use > > The second description depends on the first -- one can't retrieve the > available sizes to choose from without first getting the photo ID. > > So I did a bit of Googling around, and came across an On Smalltalk [1] > article, where it mentioned something about this: > >> Generally speaking you'll keep these descriptions on the class side of >> your domain object. On occasion, you'll want some property of the >> description to be dynamic and depend on the actual value of an instance >> side value, so you'll move the description to the instance side. >> Strictly speaking, it doesn't matter where you put them, sometimes >> you'll use them to build forms when you don't even have a domain object, >> but this isn't the normal case. > > Then I did some further looking, and found some tutorial [2] that actually > gives some information on doing this (without Pier). It seems like in > general (based on this tutorial) you implement #descriptionEdit, and then > grab that when handling the editing function in whatever UI you choose. > > That said, I've been struggling to figure out how I can do this with a > PRWidget in Pier. There seems to be some way of doing it with a > PRStructure, as PRFile provides editing capabilities on a text-based file by > overriding #editDescription. But I'm not sure how it would work with a > PRWidget, or if it is even possible. > > Basically, I would envision it as follows in the UI, continuing with the > Flickr photo example: > - Create a new photo widget > - Edit the photo widget -- the size property either does not show or is not > populated > - Input a photo ID > - Either submit the form, or have something realize it has what it needs to > populate the next field and transmit the data without a page refresh > - Select the photo size, and submit > > Is there any way of accomplishing this with the existing support for > Magritte in Pier? Or is this something that could be (or should be) hacked > into PRWidget? Or am I going about this in a completely wrong way? > > Any advice would be much appreciated. > > Thanks, > Joel > > [1] http://onsmalltalk.com/using-magritte-with-seaside > [2] > http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?chapter=10#part4 > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Free forum by Nabble | Edit this page |