You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Gord Tanner <gt...@gmail.com> on 2012/02/23 00:49:44 UTC
pull request for cordova-js
didn't see an email get generated for this:
https://github.com/apache/incubator-cordova-js/pull/1
Adds in support for Contacts on BlackBerry and fixes the PlayBook exec
method.
Gord
Re: pull request for cordova-js
Posted by Jesse <pu...@gmail.com>.
I am starting a new thread to discuss "standard layer to exec"
Cheers,
Jesse
On Wed, Feb 22, 2012 at 7:05 PM, <gt...@gmail.com> wrote:
> I was playing with this today too, my vote is to not spend too much time
> with mixing in platform specific behavior per method as the end result we
> should be aiming at is not having any platform specific overrides.
>
> We should be pushing for a standard layer to exec and extending from
> there, exactly like Drew mentioned but a little more module driven rather
> than the classical method blackberry does at the moment.
>
>
> Sent on the TELUS Mobility network with BlackBerry
>
> -----Original Message-----
> From: Drew Walters <de...@gmail.com>
> Sender: purdrew@gmail.com
> Date: Wed, 22 Feb 2012 20:53:45
> To: <ca...@incubator.apache.org>
> Reply-To: callback-dev@incubator.apache.org
> Subject: Re: pull request for cordova-js
>
> I was actually looking at the contact related changes today as well.
> My changes are slightly different though. I followed the model set by
> the DirectoryEntry override in that the file only contains the API
> that need overridden (save, rename, find and helper methods). The
> platform file then overrides those methods similar to how
> DIrectoryEntry methods are overridden. Was still working on it when I
> left work today so haven't tested it. Advantage would be ensuring
> that the additional methods that are common (clone, create,
> constructor) are kept in the common file minimizing the risk of them
> getting out of sync.
>
> Honestly, I'm not crazy about the override in the platform file, seems
> to me a better model might be to handle platform uniqueness in the
> exec function like the playbook manager does. In my head that seems
> like a more straight forward way of fitting in to the framework but it
> would require some extra overhead of checking if an action has JS
> implementation or needs sent to native.
>
> FYI, I'm also looking at File API fixes. Requires some changes on
> native side to match behavior that other platforms have which
> cordova-js is expecting.
>
> On Wed, Feb 22, 2012 at 5:58 PM, Filip Maj <fi...@adobe.com> wrote:
> > Ill take a look!
> >
> > On 12-02-22 3:49 PM, "Gord Tanner" <gt...@gmail.com> wrote:
> >
> >>didn't see an email get generated for this:
> >>https://github.com/apache/incubator-cordova-js/pull/1
> >>
> >>
> >>Adds in support for Contacts on BlackBerry and fixes the PlayBook exec
> >>method.
> >>
> >>Gord
> >
>
Re: pull request for cordova-js
Posted by gt...@gmail.com.
I was playing with this today too, my vote is to not spend too much time with mixing in platform specific behavior per method as the end result we should be aiming at is not having any platform specific overrides.
We should be pushing for a standard layer to exec and extending from there, exactly like Drew mentioned but a little more module driven rather than the classical method blackberry does at the moment.
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
From: Drew Walters <de...@gmail.com>
Sender: purdrew@gmail.com
Date: Wed, 22 Feb 2012 20:53:45
To: <ca...@incubator.apache.org>
Reply-To: callback-dev@incubator.apache.org
Subject: Re: pull request for cordova-js
I was actually looking at the contact related changes today as well.
My changes are slightly different though. I followed the model set by
the DirectoryEntry override in that the file only contains the API
that need overridden (save, rename, find and helper methods). The
platform file then overrides those methods similar to how
DIrectoryEntry methods are overridden. Was still working on it when I
left work today so haven't tested it. Advantage would be ensuring
that the additional methods that are common (clone, create,
constructor) are kept in the common file minimizing the risk of them
getting out of sync.
Honestly, I'm not crazy about the override in the platform file, seems
to me a better model might be to handle platform uniqueness in the
exec function like the playbook manager does. In my head that seems
like a more straight forward way of fitting in to the framework but it
would require some extra overhead of checking if an action has JS
implementation or needs sent to native.
FYI, I'm also looking at File API fixes. Requires some changes on
native side to match behavior that other platforms have which
cordova-js is expecting.
On Wed, Feb 22, 2012 at 5:58 PM, Filip Maj <fi...@adobe.com> wrote:
> Ill take a look!
>
> On 12-02-22 3:49 PM, "Gord Tanner" <gt...@gmail.com> wrote:
>
>>didn't see an email get generated for this:
>>https://github.com/apache/incubator-cordova-js/pull/1
>>
>>
>>Adds in support for Contacts on BlackBerry and fixes the PlayBook exec
>>method.
>>
>>Gord
>
Re: pull request for cordova-js
Posted by Drew Walters <de...@gmail.com>.
I was actually looking at the contact related changes today as well.
My changes are slightly different though. I followed the model set by
the DirectoryEntry override in that the file only contains the API
that need overridden (save, rename, find and helper methods). The
platform file then overrides those methods similar to how
DIrectoryEntry methods are overridden. Was still working on it when I
left work today so haven't tested it. Advantage would be ensuring
that the additional methods that are common (clone, create,
constructor) are kept in the common file minimizing the risk of them
getting out of sync.
Honestly, I'm not crazy about the override in the platform file, seems
to me a better model might be to handle platform uniqueness in the
exec function like the playbook manager does. In my head that seems
like a more straight forward way of fitting in to the framework but it
would require some extra overhead of checking if an action has JS
implementation or needs sent to native.
FYI, I'm also looking at File API fixes. Requires some changes on
native side to match behavior that other platforms have which
cordova-js is expecting.
On Wed, Feb 22, 2012 at 5:58 PM, Filip Maj <fi...@adobe.com> wrote:
> Ill take a look!
>
> On 12-02-22 3:49 PM, "Gord Tanner" <gt...@gmail.com> wrote:
>
>>didn't see an email get generated for this:
>>https://github.com/apache/incubator-cordova-js/pull/1
>>
>>
>>Adds in support for Contacts on BlackBerry and fixes the PlayBook exec
>>method.
>>
>>Gord
>
Re: pull request for cordova-js
Posted by Filip Maj <fi...@adobe.com>.
Ill take a look!
On 12-02-22 3:49 PM, "Gord Tanner" <gt...@gmail.com> wrote:
>didn't see an email get generated for this:
>https://github.com/apache/incubator-cordova-js/pull/1
>
>
>Adds in support for Contacts on BlackBerry and fixes the PlayBook exec
>method.
>
>Gord