#urlForDocument: w/o canvas?
Locked
 
|
All,
I'm a bit confused about #urlForDocument: in a non-render method. Background: I'm having a component (SwfObject) which wraps the SWFObject .js library. This component gets initialized in my Application: initialize super initialize. swf := (SwfObject new) alternativeContent: [:html | html text: 'Flash is being loaded']; extent: 640 @ 480; url: OFCFileLibrary / #openflashchartSwf; yourself In the render code of my app I render this component. However the flash needs a reference to some content using #urlForDocument: . So I need to set this in the render method: renderContentOn: html swf variables: ((Dictionary new) at: 'data-file' put: (html context urlForDocument: self data); yourself) jsonString. html render: swf This works w/o problem. However the data does not change from render to render. So what I would like to do is to set the #variables: in #initielize as well - however this is not possible because I need #urlForDocument: which is only available through the canvas? My bad gut feeling comes from the point that I do not want to change components during render - only as a result of an action. At this point I have no choice but to do it? So I'm asking myself whether it is possible to get an URL for a document outside of the render run - maybe a URL to a (delayed) MIMEDocument which gets it's content via a pluggable block? I would love to do something like this in #initialize. swf variables: ((Dictionary new) at: 'data-file' put: (self urlForDelayedDocument: [self data]); yourself) jsonString. Any pointers? Thanks, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: #urlForDocument: w/o canvas?
|
|
Hi Udo,
For elegance you can make that dictionary to be in an inst var of your wrapper component and in the render method json that instvar (presumably with a proper dictionary). That way could potentially be changed in any calback and then render properly according to that. Make some convenience accessors and you're done, Cheers, Sebastian Sastre PD: that, of course, if I understood you right ;) > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Udo Schneider > Enviado el: Miércoles, 15 de Octubre de 2008 08:00 > Para: [hidden email] > Asunto: [Seaside] #urlForDocument: w/o canvas? > > All, > > I'm a bit confused about #urlForDocument: in a non-render method. > > Background: I'm having a component (SwfObject) which wraps > the SWFObject > .js library. This component gets initialized in my Application: > > initialize > super initialize. > swf := (SwfObject new) > alternativeContent: [:html | html text: 'Flash is being loaded']; > extent: 640 @ 480; > url: OFCFileLibrary / #openflashchartSwf; > yourself > > In the render code of my app I render this component. However > the flash > needs a reference to some content using #urlForDocument: . So > I need to > set this in the render method: > > renderContentOn: html > swf > variables: ((Dictionary new) > at: 'data-file' put: (html context urlForDocument: self data); > yourself) jsonString. > html render: swf > > This works w/o problem. However the data does not change from > render to > render. So what I would like to do is to set the #variables: in > #initielize as well - however this is not possible because I need > #urlForDocument: which is only available through the canvas? > > My bad gut feeling comes from the point that I do not want to change > components during render - only as a result of an action. At > this point > I have no choice but to do it? > > So I'm asking myself whether it is possible to get an URL for > a document > outside of the render run - maybe a URL to a (delayed) MIMEDocument > which gets it's content via a pluggable block? > > I would love to do something like this in #initialize. > > swf variables: ((Dictionary new) > at: 'data-file' put: (self urlForDelayedDocument: [self data]); > yourself) jsonString. > > Any pointers? > > Thanks, > > Udo > > _______________________________________________ > 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 |
Re: #urlForDocument: w/o canvas?
|
|
Hi Sebastian,
> For elegance you can make that dictionary to be in an inst var of your wrapper > component and in the render method json that instvar (presumably with a proper > dictionary). As far as I can see it I can move some of the code to a separate method. E.g.: initialize super initialize. swf := SwfObject new. swf alternativeContent: [:html | html text: 'Flash is being loaded']; extent: 640 @ 480; url: OFCFileLibrary / #openflashchartSwf ofcVariables: html ^(Dictionary new) at: 'data-file' put: (html context urlForDocument: self data); yourself However I still see a problem: To obtain a URL for the data-file in #ofcVariables: I still have to call #urlForDocument. And this is only possible to do it by calling the current renderers context and ask it for the document URL. I think what I would need is a way to get a URL for some content which is not dependent on the canvas (i.e. initialized /once/ in the #initialize method of the parent component). IMHO something between using #urlDocument: /which depends/varies on the per render-run canvas) and using a static file (using WAFileLibrary and friends. > That way could potentially be changed in any calback and then render properly > according to that. Callback rings a bell for me - is there a way to define a callback (and getting it's URL) and to define what kind of content to return? > PD: that, of course, if I understood you right ;) You did - I just may have been a bit unclear. It's not that it doesn't work right know - it's just that changing a sub-components state during a render-run seems wrong to me. CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: #urlForDocument: w/o canvas?
|
|
> ofcVariables: html > ^(Dictionary new) > at: 'data-file' put: (html context urlForDocument: self data); > yourself > > However I still see a problem: To obtain a URL for the data-file in > #ofcVariables: I still have to call #urlForDocument. And this is only > possible to do it by calling the current renderers context and ask it > for the document URL. > > > That way could potentially be changed in any calback and > then render properly > > according to that. > Callback rings a bell for me - is there a way to define a > callback (and > getting it's URL) and to define what kind of content to return? > I think there is, I don't remember right now, but are you sure not thinking too much resource oriented here? What problem do you see with callbacks? > > PD: that, of course, if I understood you right ;) > You did - I just may have been a bit unclear. It's not that > it doesn't > work right know - it's just that changing a sub-components > state during > a render-run seems wrong to me. > Sure, note callbacks are defined in blocks that are executed in a different phase than the rendering phase. So the state affected in a callback is not being made during render. Only defined as eventually executable actions. I don't see where you are changing components during render. Just a little refactor to clean up your component. Cheers, Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
In reply to this post by Sebastian Sastre-2
Sorry, wrong methods:
Hi Sebastian, > For elegance you can make that dictionary to be in an inst var of your wrapper > component and in the render method json that instvar (presumably with a proper > dictionary). As far as I can see it I can move some of the code to a separate method. E.g.: renderContentOn: html swf variables: (self ofcVariables: html) jsonString. html render: swf ofcVariables: html ^(Dictionary new) at: 'data-file' put: (html context urlForDocument: self data); yourself However I still see a problem: To obtain a URL for the data-file in #ofcVariables: I still have to call #urlForDocument. And this is only possible to do it by calling the current renderers context and ask it for the document URL. I think what I would need is a way to get a URL for some content which is not dependent on the canvas (i.e. initialized /once/ in the #initialize method of the parent component). IMHO something between using #urlDocument: /which depends/varies on the per render-run canvas) and using a static file (using WAFileLibrary and friends. > That way could potentially be changed in any calback and then render properly > according to that. Callback rings a bell for me - is there a way to define a callback (and getting it's URL) and to define what kind of content to return? > PD: that, of course, if I understood you right ;) You did - I just may have been a bit unclear. It's not that it doesn't work right know - it's just that changing a sub-components state during a render-run seems wrong to me. CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
In reply to this post by Sebastian Sastre-2
Sebastian,
> I think there is, I don't remember right now, but are you sure not thinking too > much resource oriented here? Resources is one thing - the other is that in the back of my mind I remember something like "never change components during render" thingie ... > What problem do you see with callbacks? None - I'm just not sure how to use them (esp. in this context) > Sure, note callbacks are defined in blocks that are executed in a different > phase than the rendering phase. So the state affected in a callback is not being > made during render. Only defined as eventually executable actions. > I don't see where you are changing components during render. Just a little > refactor to clean up your component. The "swf variables: (self ofcVariables: html) jsonString." in #renderContentOn: changes the components state to reflect the "new"(?) #urlForDocument: value before rendering it. renderContentOn: html swf variables: (self ofcVariables: html) jsonString. html render: swf Thanks for your help, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: #urlForDocument: w/o canvas?
|
|
> > I don't see where you are changing components during
> render. Just a little > > refactor to clean up your component. > The "swf variables: (self ofcVariables: html) jsonString." in > #renderContentOn: changes the components state to reflect the > "new"(?) > #urlForDocument: value before rendering it. > I don't use the swf object you mention. In the render phase is ok to create objects on the fly that will help you render a component. Scriptaculous way of adding javascript in Seaside applications use and abuse from that. You can use the wrapper as a dispensable thing that is initialized with fresh state (of that dispensable thing). Note that this will be different from changing state of the component itself. Think of a scriptaculous effect. It is created, configured passed as paramenter and it only will last for that render. If your wrapper is usable like that, then it would be perfectly fine to use one on the fly. Check if is really justified to make that wrapper to be placed in an inst var of your component. If not, remove it and use as if it where an effect or whatever. If it really justified that every instance should be part of the component. It will be considered (sub)state. In such a case I can understand your worry about thinking better where to set the state. > renderContentOn: html > swf variables: (self ofcVariables: html) jsonString. > html render: swf > > Thanks for your help, > > Udo > Cheers, Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
Sebastian,
> I don't use the swf object you mention. In the render phase is ok to create You can't - I'm currently working on it :-) > objects on the fly that will help you render a component. Scriptaculous way of > adding javascript in Seaside applications use and abuse from that. You can use > the wrapper as a dispensable thing that is initialized with fresh state (of that > dispensable thing). Note that this will be different from changing state of the > component itself. Think of a scriptaculous effect. It is created, configured > passed as paramenter and it only will last for that render. Thanks for the background. I'll try to implement it as a brush instead. Creating temp brushes is IMHO more natural (to me) than creating temp components. Thanks for your help - it gave me quite some insight into how it all works behind the scenes. CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: #urlForDocument: w/o canvas?
|
|
> > I don't use the swf object you mention. In the render phase
> is ok to create > You can't - I'm currently working on it :-) > Oh you do. Just using the canvas and you are creating WAxxxTag objects that will last for that render alone. What you should not do is to create Seaside components in that phase. > > objects on the fly that will help you render a component. > Scriptaculous way of > > adding javascript in Seaside applications use and abuse > from that. You can use > > the wrapper as a dispensable thing that is initialized with > fresh state (of that > > dispensable thing). Note that this will be different from > changing state of the > > component itself. Think of a scriptaculous effect. It is > created, configured > > passed as paramenter and it only will last for that render. > Thanks for the background. I'll try to implement it as a > brush instead. > Creating temp brushes is IMHO more natural (to me) than creating temp > components. > didn't mention to create temp components. Now you say that I get the idea of maybe your wrapper is a component and there is not really justified for it to be a componenet (which mostly depends on it using call:/show:/answer: methods). > Thanks for your help - it gave me quite some insight into how it all > works behind the scenes. > > > CU, > > Udo > Sure, cheers, Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: #urlForDocument: w/o canvas?
|
|
In reply to this post by Udo Schneider
On Thu, Oct 16, 2008 at 9:18 AM, Udo Schneider
<[hidden email]> wrote: > Thanks for the background. I'll try to implement it as a brush instead. > Creating temp brushes is IMHO more natural (to me) than creating temp > components. > > Thanks for your help - it gave me quite some insight into how it all works > behind the scenes. I haven't really been following this discussion but note that instead of a brush you can also just create a class (not a component) that responds to #renderOn:. Then in your #renderContentOn: in your component, you can create an instance of that class and pass it to "html render:". Maybe a brush is more natural for your case, I don't know, but I wanted to make sure you were aware that brush/component are not the only two options. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
Hi Julian,
> I haven't really been following this discussion but note that instead > of a brush you can also just create a class (not a component) that > responds to #renderOn:. Then in your #renderContentOn: in your > component, you can create an instance of that class and pass it to > "html render:". I wasn't aware of this. I think I can combine both approaches by providing a brush (for render methods where the content changes on a per-render run basis) and by using your solution for more static stuff (which uses the brush internally of course). > Maybe a brush is more natural for your case, I don't know, but I > wanted to make sure you were aware that brush/component are not the > only two options. Thanks. It's always good to add a trick to ones bag. CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
In reply to this post by Sebastian Sastre-2
Sebastian,
>>> I don't use the swf object you mention. In the render phase >> is ok to create >> You can't - I'm currently working on it :-) >> > Oh you do. Just using the canvas and you are creating WAxxxTag objects that will > last for that render alone. What you should not do is to create Seaside > components in that phase. Now I'm getting confused :-) What I meant is that I currently work on SWFObject - so there was no chance you could have known it. Regarding WAXXXTag - I'm currently going this way - although my stuff is subclassed from WABrush as there is no simpla Tag Mapping. > Please don't confuse creating temp objects with creating temp components. I > didn't mention to create temp components. Now you say that I get the idea of > maybe your wrapper is a component and there is not really justified for it to be > a componenet (which mostly depends on it using call:/show:/answer: methods). You're right - this was part of my bad gut feeling. I'm currently redoing the stuff as brush and it simply feels natural. CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Re: #urlForDocument: w/o canvas?
|
|
> Now I'm getting confused :-) What I meant is that I currently work on
> SWFObject - so there was no chance you could have known it. > what a mess... hehe in a previous mail I've omited a bit of text to desambiguate and inducted your confusion. Let me clarify, I get it is a goodie you are working on. What I meant is just the idea of you can, and are using all the time temp objects which helps in the render process. > Regarding WAXXXTag - I'm currently going this way - although > my stuff is > subclassed from WABrush as there is no simpla Tag Mapping. > > > Please don't confuse creating temp objects with creating > temp components. I > > didn't mention to create temp components. Now you say that > I get the idea of > > maybe your wrapper is a component and there is not really > justified for it to be > > a componenet (which mostly depends on it using > call:/show:/answer: methods). > You're right - this was part of my bad gut feeling. I'm currently > redoing the stuff as brush and it simply feels natural. > > CU, > > Udo > Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: #urlForDocument: w/o canvas?
|
|
Sebastian,
> what a mess... hehe in a previous mail I've omited a bit of text to > desambiguate and inducted your confusion. Let me clarify, I get it is a goodie > you are working on. What I meant is just the idea of you can, and are using all > the time temp objects which helps in the render process. Now I got you. As I wrote - I'm already (re-)doing this with a brush approach and temp objects. Thanks for claryfing it all - I think we are on one page now :-) CU, Udo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |