[moving to laszlo-dev] Here's a proposed model for doing browser capability detection:
- We have one function, call it lzHostCapabilities, that returns a list of tokens describing the specific capabilities supported by the host. These tokens are the same tokens used inside LFC for requires/ provides. In particular, there is one token, "hostSupportsOpenLaszloBasic", whose presence guarantees the host can run basic OpenLaszlo applications. - This function is available in two places: as a kernel API, and as a standalone function that can be called from host wrapper code. - The kernels and the LFC use lzHostCapabilities (or requires/ provides) to customize behavior and to provide a "hard stop" for hosts that just can't run OpenLaszlo - host wrapper code *can* use lzHostCapabilities to provide any sort of preflighting or configuration necessary before, during, or after, load of the OpenLaszlo app. Assuming we all agree on this, the remaining question is how to package the function in the host-wrapper case. The most straightforward thing would be to add a js file in lps/includes, call it lzhtmlutils.js, that contains the lzHostCapabilities function. (Note that I have a changeset out with a new file, lps/includes/ utils.js, containing a parseQueryArgs function. If we accept this, I would still check in that changeset, but in a subsequent changeset convert to the scheme described above.) Reactions? Thoughts? jim On Sep 26, 2006, at 8:12 AM, P T Withington wrote: > Ah, I was just talking about for the current Legal's, where we want > to caveat the not-fully-qualified browsers. I was expecting the > final version not to have such a caveat. Is this wrong? > > And yes, I expect this to run before the app loads (or at least in > parallel), so I expected it to be stand-alone code, not part of (or > dependent on) the LFC loading. > > It seems to me that sharing code with the LFC or the pre-flighting > that David is talking about is a different issue. > > On 2006-09-26, at 01:29 EDT, Jim Grandy wrote: > >> Well, that's a good question: does the browser detect need to run >> before the app loads? If the load time is long enough, certainly >> yes it does. And the developer may want to load an alternative >> version of the app if the browser detect fails, again arguing for >> pre-flighting. >> >> jim >> >> On Sep 25, 2006, at 9:41 PM, Max Carlson wrote: >> >>> Yes. Please note there's complete browser detection logic >>> already in place in LzSprite - I'd encourage you to use that. >>> See LzSprite.prototype.quirks.__BrowserDetect >>> >>> Perhaps we should move this somewhere more public, like LzBrowser... >>> >>> -Max >>> >>> P T Withington wrote: >>>> Jim and I propose simplifying out browser-detect feature for >>>> DHTML so that we can apply it more generally to our standard >>>> templates. (The current LZPIX implementation is very slick, but >>>> requires an extra 'interstitial' page that would be a pain to >>>> make for every demo.) Our proposal is that for the 'not fully >>>> supported browsers' we will simply pop up an alert saying that >>>> the browser is not fully supported (and load the app anyways). >>>> Is this acceptable to everyone? >> > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
