For data requests, the DataProvider API currently does not currently have any method to set the proxy server URL explicitly, but I would like to add such a feature.
The current default system data provider is an instance of LzHTTPDataProvider, which uses instances of LzHTTPDataRequest to encapsulate requests. Currently the way it works is when a data request is made, LzDataset builds a HTTPDataRequest object and passes it to the default data provider via the doRequest() methods. So if we add a new "proxyhost" property to nodes (or if that is too broad, to LzView and to LzDataset), then if there is a proxyhost property set on the dataset, it will get stuck into the HTTPDataRequest, and then LzHTTPDataProvider can use that value. If it is not set, then the proxy host will default to the current behavior of using the application's own URL as the proxy server address. On Thu, May 29, 2008 at 3:22 PM, Henry Minsky <[EMAIL PROTECTED]> wrote: > I think the intention is that this applies to not just data but to media > loading as well, which is outside the scope of the > DataProvider API. > > > On Thu, May 29, 2008 at 3:07 PM, David Temkin <[EMAIL PROTECTED]> > wrote: > >> Max, Henry, >> >> Can this be solved using the existing mechanism of a custom dataprovider, >> which could implement a proxy policy? That was one intention of the >> dataprovider API. >> >> Better to do this in one place, as opposed to adding a new API for this. >> >> - D. >> >> >> >> On May 28, 2008, at 4:43 PM, Max Carlson wrote: >> >> Sounds good to me! By the way, I filed a bug to track the proxy policy >>> API change: http://jira.openlaszlo.org/jira/browse/LPP-6058 >>> >>> Can you file one for doing the same with the proxyhost attribute? >>> Thanks! >>> >>> Henry Minsky wrote: >>> >>>> A related issue, it would be nice to be able to specify the URL of the >>>> proxy host, instead of it being >>>> hardcoded to be the app url. How about a proxyhost attribute that you >>>> can set in a similar manner? >>>> On Wed, May 28, 2008 at 3:00 PM, Max Carlson <[EMAIL PROTECTED]<mailto: >>>> [EMAIL PROTECTED]>> wrote: >>>> Hi Folks, >>>> I was thinking of deprecating the LzView.add/removeProxyPolicy() >>>> APIs in favor of a new, simpler system. The current API looks like >>>> this: >>>> LzView.addProxyPolicy ( f ) >>>> Adds a function which can decide how the media at a given URL should >>>> be loaded >>>> @param Function f: A function that takes a URL as a string and >>>> returns one of true, false, or null meaning respectively that the >>>> request should be proxied by the LPS server; made directly to the >>>> URL; or should be passed to the next policy function in the list. >>>> The default policy function returns the value of canvas.proxied >>>> LzView.removeProxyPolicy ( f ) >>>> Removes a proxy policy function that has been added using >>>> LzView.addProxyPolicy >>>> @param Function f: The function to remove from the policy list >>>> @return Boolean: Returns true if the function was found and removed, >>>> false >>>> if not >>>> Instead, each view would be able to set its own proxy policy. If a >>>> view does not have an explicit proxy policy set, it looks up the >>>> parent chain until it finds one. The canvas always has a default >>>> proxy policy set. Views can change their proxy policy like this: >>>> anyview.setProxyPolicy ( f ) >>>> Sets a proxy policy function on a per-view basis. >>>> @param Function f: The function to use for this view's proxy policy >>>> Let me know what you think! >>>> -- Regards, >>>> Max Carlson >>>> OpenLaszlo.org >>>> -- >>>> Henry Minsky >>>> Software Architect >>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>> >>> >>> -- >>> Regards, >>> Max Carlson >>> OpenLaszlo.org >>> >> >> > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
