This is for hysterical reasons. We started out with just resource, then later added source to clearly distinguish http resources, because it seemed like they would be different. Also, in lzx source="..." is much more like HTML...
Later, someone expected resource="http:..." to work, so we added a clause in setResource() to delegate to setSource. There's no real reason to expose this complexity to lz.view, we might as well decide on one or the other (I vote for resource since it already works with http:) and deprecate source. This will be easy, because the sprite APIs can be updated later. Filed as http://jira.openlaszlo.org/jira/browse/LPP-9387 On Sep 13, 2010, at 10:08 AM, P T Withington wrote: > I hope the OpenLaszlo Architect can answer your question, because from > reading the documentation, I can't figure out what the difference between > > <view>/source >> >> The URL from which to load the resource for this view. If this attribute is >> set, the media for the view is loaded at runtime. > > and <view>/resource >> A resource that is presented in the background of this view. The value can >> be either the name of a resource defined with the resource tag, a URL, or a >> pathname. If the value is a URL, the resource is requested when the view is >> displayed. If it's a pathname, the file named by the pathname is compiled >> into the application, and attached to this view. > > is. They seem to have a lot of overlap. I would think we could simplify > this to be less mysterious. My guess is that they _used_ to be two separate > interfaces, one which meant load my resource at runtime and the other which > meant load my resource from a compiled-in resource, but people got so > confused, we made the latter accept any of resource name, path, or general > URL and heuristicate what the user could have meant. I guess we didn't apply > the same generality to the former. > > It might be simpler if we required the argument to _always_ be an URL and > used either standard scheme (like source="CID:logo", http://bit.ly/aojqC8) > or created our own non-standard one (e.g., source="resource:logo") to specify > the case where we mean a local compiled-in, named resource, and standard > schemes (source="file:resources/logo.jpg", source="http:resources/logo.jpg") > for the cases of creating an anonymous resource and loading the resource at > runtime over http. If we say the default scheme is the one for resource > names (either cid: or resource:) we would be backwards compatible. > > Maybe you want to file a bug/improvement request? > > --- > > As to the <resource> tag, that does seem a _little_ clearer: > >> This tag imports the object into the application, and binds it to a string >> which can be used within a view > > from which I intuit the point of a <resource> is to compile the source _into_ > the application, rather than loading it at runtime. And while <resource>/src > does say its type is URL, it refines that by saying: > >> The path of a file that contains the source for this object. > > so, it seems reasonably clear that a resource is expected to be a local file > available at compile time, and it's purpose is to make that file into > "immediate" data that is available/compiled-into the app (and hence the app > does not need an internet connection to load it's resources). This seems > like a useful distinction to keep. > > On 2010-09-13, at 07:03, Raju Bitter wrote: > >> I did some more testing, and have some questions on the logic of the >> code in setResource. According to the docs >> (http://www.openlaszlo.org/lps4.8/docs/reference/) the src attribute >> of a resource tag is an URL. The value of the src tag will be used to >> call setResource on a view, when I assign a resource to a view, as in >> this example: >> >> <canvas height="70"> >> <resource name="logo" src="../images/logo.png"/> >> <view resource="logo"/> >> </canvas> >> >> At runtime, you can set a views resource by using >> someView.setAttribute("source", resourceURL), or using >> someView.setAttribute("resource", resourceURL). In that case, >> LzSprite#setResource method is called. Actually this is a bit >> confusing, since you can't use a URL within a resource tag's @src: >> >> <resource name="mountainRsc" src="http:resources/images/wetterstein.jpg" /> >> >> This will trigger a compiler error with the error message "unknown >> protocol: http". If setAttribute("resource", http/https/app URL) works >> at runtime, why even provide a setSource method? >> >> I attached a testcase for you with comments to the JIRA issue as well. >> >> >> On Fri, Sep 10, 2010 at 1:14 AM, Raju Bitter >> <[email protected]> wrote: >>> Yes, based on my testing. Tested with image files and MP3 files for >>> audio playback. >>> >>> On Thu, Sep 9, 2010 at 11:44 PM, Henry Minsky <[email protected]> >>> wrote: >>>> Raju, I'm going to file a JIRA request to track this change, is this the >>>> only change you need to the LFC >>>> to support AIR resources? >>>> >>>> >>>> --- WEB-INF/lps/lfc/kernel/swf9/LzSprite.as (revision 17458) >>>> +++ WEB-INF/lps/lfc/kernel/swf9/LzSprite.as (working copy) >>>> @@ -363,7 +363,8 @@ >>>> */ >>>> public function setResource (r:String):void { >>>> if (this.resource == r) return; >>>> - if (r.indexOf('http:') == 0 || r.indexOf('https:') == 0) { >>>> + if (r.indexOf('http:') == 0 || r.indexOf('https:') == 0 || >>>> r.indexOf('app:') == 0) { >>>> + // if (r.indexOf('http:') == 0 || r.indexOf('https:') >>>> == >>>> 0) { >>>> this.setSource( r ); >>>> return; >>>> } >>>> >>>> >>>> -- >>>> Henry Minsky >>>> Software Architect >>>> [email protected] >>>> >>>> >>>> >>> >> >
