On 2010-08-06, at 07:39, Lou Iorio wrote: > I don't know how to begin to fix this. > > Can someone provide more info, and a simple code example (if appropriate)? > > It looks like it should go in the Constraints chapter of the dguide.
It should probably be in 2 places: in Constraints, because it reveals a subtle detail of constraints (see footnote below) and also where we talk about interacting with the browser/runtime, because it tells you how to map "query args" into application attributes. What this is saying is that when you invoke an application using a URL, you can pass arguments to to the application in the URL like so: http://...my-app.lzx?foo=42 If you want an attribute in your application to be constrained to that argument, you _must_ use a $once constraint (you could use an always constraint, but you know these parameters are never going to change, and oh, by the way, you will get a runtime error if you try to make it an always constraint, because lz.Browser is not an object that supports always contstraints -- it is not a subclass of lz.Eventable, as all <view>s are, hence it cannot send update events, hence you cannot listen for update events, hence you can't make an always constraint on it [*]). <attribute name="foo" value="$once{lz.Browser.getInitArg('foo')}" /> To me it's kind of too bad we call this a 'browser init arg', since the term 'init arg' is used elsewhere in LZX for a totally different purpose, and the internet standard calls the part of an HTTP url after the ? a 'query string' (http://en.wikipedia.org/wiki/URI_scheme), hence these arguments are referred to everywhere else as 'query args'. It's also too bad that we confound these parameters with the browser, because OL apps can be delivered into non-browser runtimes (e.g., Air) and can still have parameters. But neither of these are your issue, other than trying to make a good story as to why things are the way they are. I love how documenting a feature makes you realize what a crappy implementation you have. Maybe we should require developers to write documentation first. If they can't construct an English description of what they are trying to implement, they are surely doing it wrong. :P --- [*] Gory details: We used to let you create constraints on arbitrary things and in swf8 days if you tried to constrain against something that you couldn't really, because it was not an object that implemented our constraint protocol, you would just silently lose. We have stricter rules now: Objects that know how to send events when their attributes change are all subclasses of lz.Eventable. If you want to listen for `onfoo` events, which is how an always constraint is implemented, the object holding the foo attribute needs to be an Eventable object (I know, not a very good name). lz.Browser is a thin wrapper around the browser API in the runtime, and not an Eventable object.
