Ok, so a setter --- think that was the key missing piece of info. b/c this is behavioral we'd probably be better off making it a function call:
CB.supportOrientation(0, 180) ... But smells like configuration and less like something that should dynamically set/reset --- and probalby has some sensible defaults that could exist/be overwrit by config.xml ... how about: CB.config.supportOrientation(0, 180) ??? On Mon, Oct 24, 2011 at 3:28 PM, Jesse <[email protected]> wrote: > pseudo xui code ... a simple case > > // image view should be freely oriented > function showImageView() { > x$("#listView").css({display:'none'}); > CB.supportedOrientations = [0,90,-90,180]; > x$("#imageView").css({display:'block'}); > x$("#imageView .closeBtn").click(showListView); > } > > // list view always wants to display in portrait or portrait upsidedown > function showListView() { > x$("#imageView").css({display:'none'}); > CB.supportedOrientations = [0,180]; > x$("#listView").css({display:'block'}); > > x$("#listView li").click(function(e){ > // assume some DOM modification based on selected item. > showImageView(); > }); > } > > On Mon, Oct 24, 2011 at 3:11 PM, Brian LeRoux <[email protected]>wrote: > >> k, so imp semantics aside for a second. can you futz up a quick >> example of how you would call the code? (rather than how you'd impl >> it) >> >> want to understand use cases here.. >> >> >> >> On Mon, Oct 24, 2011 at 3:00 PM, Jesse <[email protected]> wrote: >> > Storing values in an object IMHO adds little or no value. >> > The Array has the additional benefit of providing a preferential order as >> > well, for the case where the requested 'supportedOrientations' does not >> > contain the physical current orientation. >> > >> > I do see a benefit to have defined type values, but deviating from the >> > numeric values only makes things more difficult to understand. The >> numeric >> > values were chosen because these ARE the values passed to listeners of >> the >> > 'orientationchange' event >> > On most platforms, window.orientation already contains an integer value >> > which is one of : 0,90,-90,180 >> > >> > north|south| .. imply that we are talking about the compass direction >> that >> > the device is facing, which absolutely not the case. >> > >> > We could make it absolutely understandable to all by providing a static >> > human-readable version of the values. Like this: >> > >> > // This definitely SHOULD be namespaced >> > OrientationType = { >> > PORTRAIT:0, >> > LANDSCAPE:90, >> > LANDSCAPE_LEFT:90, >> > LANDSCAPE_RIGHT:-90, >> > PORTRAIT_RIGHTSIDEUP:0, >> > PORTRAIT_UPSIDEDOWN:180 >> > }; >> > >> > // RE: I can see more orientation >> > // settings emerging in the future. For example, future devices may have >> a >> > // fluid orientation .... >> > >> > This should not be confused with the devicemotion or accelerometer apis >> > which provide much more granular control when needed. Orientation values >> are >> > intended to be discrete values and not a continuous series. The only >> other >> > orientations I foresee are possible additions of FACEUP and FACEDOWN, >> > although they are primarily just modifiers in another dimension to the >> > existing values. >> > >> > >> > >> > >> > >> > >> > On Mon, Oct 24, 2011 at 2:17 PM, Brian LeRoux <[email protected]> wrote: >> > >> >> Good suggestions mr. brooks. Also, we might as we get used to this, it >> >> will be spaced under CB. Also, I think we could be more colloquial: >> >> >> >> CB.orientation.supports = { >> >> north:true, >> >> south:false, >> >> east:false, >> >> west:true >> >> } >> >> >> >> if (CB.orientation.supports.north) { >> >> // ...etc >> >> } >> >> >> >> Is there API utility in the absolute #'s in an array that we're >> >> missing here Jesse? How are ppl using orientation? >> >> >> > >> >
