Just as a side note: async loading of externally libraries shouldn't be a top target, especially as this is for example not allowed on iOS and I guess it isn't on other platforms as well.
PhoneGap/Callback/Cordova is mainly targeting embedded devices in a closed execution environment - this is not a webpage per se. I would just like to keep that in mind when doing design decisions. (that's just my opinion, please correct me if I'm wrong with that). Best, Wolfgang Am 24.11.2011 19:46, schrieb Filip Maj: > Bit late but better than never... > > PhoneGap doesn't *need* modules but it *should* have them. > > +1 for AMD from me. > > As Laurent said, we need to consider the end-user. Overhead would be. > Compilation step is nice for phonegap.js but you cannot expect all scripts > will be prepackaged. Consider the case where a PG app async loads > libraries externally. AMD should be supported. > > Another argument in this thread was readability (see Gord's prototype for > the readability; Brian you agree too that Gord's demo was pretty). Don't > buy that commonJS is "nicer" than AMD - agree with Andrew that that is a > question of style. Personally I think AMD is nicer. > > > On 11-11-20 7:19 PM, "Laurent Hasson" <[email protected]> wrote: > >> Not about advocacy? I still do innerHTML and table layouts! :) It's about >> how to structure the project moving forwards... and I always took this >> conversation to be about (1) how to we write the framework, and (2) how >> do developers use it. >> - Are we expecting third-party modules to be developed in the >> wild? >> - If I write an app and need (a), (b) and (c), but not (d), (e), >> and (f), how do I specify that? A build system is how it's done and >> having modules clearly defined and dependencies managed helps doing that. >> >> In WebWorks, and Tim can correct me, there are potentially hundreds of >> modules. To just say it's all one big file with everything in it is >> something I don't understand. The fact that it's all packaged and we >> don't incur bandwidth and requests to pull it all in doesn't mean it >> doesn't take time to load in the browser, parse and so on. Putting it all >> on the shoulders of a developer to bring it all in themselves is also >> problematic. >> >> Maybe I am missing something here, but the way I read your messages is: >> phonegap.js is fine as it is, and we don't use any modules, so why start >> now? If we believe that we can control it, then maybe that's a fine >> position. Otherwise, if it's going to grow, and if third-parties are able >> to extend it (i.e., add new modules), and developers are going to find >> themselves never needing the entire thing by far, then how do we manage >> it? >> >> And maybe this is not a 1.x thing, maybe we'll re-architect again in 2.0 >> if the need arises? Advocacy aside, I don't often come across projects >> that don't need to end there, or suffer because they did this sooner >> rather than later. Just my $.02. >> >> >> Thank you >> ------------------------------------------------ >> - LDH (Laurent Hasson) - >> - Technical Director, BlackBerry Web Platform - >> - Research In Motion - >> - Email: [email protected] - >> - Mobile: 646-460-7066 - >> ------------------------------------------------ >> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Brian LeRoux >> Sent: Sunday, November 20, 2011 9:22 PM >> To: [email protected] >> Subject: Re: Unified phonegap javascript layer incorperating modules / >> plugins >> >> With respect Laurent, lets keep the conversation around our project >> goals and away from library / pattern advocacy for just the moment. I >> don't think we are really debating this correctly (yet) since we >> aren't looking at the long view. Ultimately we don't even need a >> module system for the single file that is phonegap.js which is in use >> today and, indeed, we don't use one or have one. All this discussion >> has been framed, I think, around authoring apps with phonegap rather >> than how to author phonegap javascript itself. >> >> The key questions we need to answer to guide this effort: >> >> Are we looking to enforce a particular module semantics on 3rd party >> plugin authors? (Do we have to?) Are plugins all compiled into the >> phonegap.js file or are we going to see something like this: >> >> <script src="phonegap-exec.js"></script> >> <script src="phonegap-acceleromter.js"></script> >> >> ??? >> >> (And leave module loading as an exercise to the end developer...?) >> >> >> >> On Sun, Nov 20, 2011 at 5:38 PM, Laurent Hasson <[email protected]> wrote: >>> Things as ambitious as PhoneGap always grow in complexity faster and >>> bigger than people think. I have been in way too many projects in the >>> past where "anything goes" was the order of the day in terms of macro >>> structure, and then it became deeply regretted quickly. I for one don't >>> see a downside to using something like AMD. And if we do want to get >>> into a much more "micro-kernel" type approach for PhoneGap as a >>> platform, then we'll need something. >>> >>> So I would put the question differently: are people so offended by the >>> idea of something AMD-like? What's the downside? Verbosity? Overhead? >>> Really? :) It enables tooling, dependency management, code structuring, >>> plugins etc... I don't see the downside. >> >>> >>> >>> Thank you >>> ------------------------------------------------ >>> - LDH (Laurent Hasson) - >>> - Technical Director, BlackBerry Web Platform - >>> - Research In Motion - >>> - Email: [email protected] - >>> - Mobile: 646-460-7066 - >>> ------------------------------------------------ >>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin >>> >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of Brian LeRoux >>> Sent: Sunday, November 20, 2011 3:25 PM >>> To: [email protected] >>> Subject: Re: Unified phonegap javascript layer incorperating modules / >>> plugins >>> >>> Would like to draw attention back to the primary goal here: a single >>> file phonegap.js that works on all the target platforms: >>> >>> - ios >>> - android >>> - blackberry >>> - wp7 >>> - bada >>> - qt >>> - browser <--- never been an explicit goal, but seems consensus here >>> is that it should be given its a common practice during app dev >>> >>> Right now our module system is classic js: we have no module loader. >>> =P We just concat our JS, always have, and leave the loading of that >>> file as an exercise for the app developer using phonegap (and it >>> should stay that way). >>> >>> Our secondary goal w/ this effort was to determine how we could move >>> code out of the phonegap core and into atomic plugins. With that mind, >>> a module system is could make things whole lot nicer. >>> >>> Do have to use a module system when we 'pluginize'? No. >>> >>> Here's the big question: *should* authors of plugins be forced into a >>> module system? I'm thinking the answer here would be no too ---- but >>> I'd love to hear everyones thoughts on that. >>> >>> >>> On Sat, Nov 19, 2011 at 12:42 PM, Patrick Mueller <[email protected]> >>> wrote: >>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <[email protected]> wrote: >>>>> For PhoneGap.js, we're dealing with a finite number of modules - >>>>> around >>>>> twenty I'd guess, plus one for each plugin. Typically, each module >>>>> only >>>>> depends on phonegap/base - it's very unlikely that, say, the Camera >>>>> API >>>>> would depend on the Accelerometer, although there may be cases of >>>>> cross >>>>> dependencies. >>>> >>>> I take it you aren't including phonegap-plugins in that list (of 20). >>>> Shouldn't they be? >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential >>> information, privileged material (including material protected by the >>> solicitor-client or other applicable privileges), or constitute >>> non-public information. Any use of this information by anyone other than >>> the intended recipient is prohibited. If you have received this >>> transmission in error, please immediately reply to the sender and delete >>> this information from your system. Use, dissemination, distribution, or >>> reproduction of this transmission by unintended recipients is not >>> authorized and may be unlawful. >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute >> non-public information. Any use of this information by anyone other than >> the intended recipient is prohibited. If you have received this >> transmission in error, please immediately reply to the sender and delete >> this information from your system. Use, dissemination, distribution, or >> reproduction of this transmission by unintended recipients is not >> authorized and may be unlawful. > > -- GOFG - Get On Fat Guy http://www.gofg.at/ - powered by PhoneGap
