[jira] [Assigned] (WEEX-18) bubble up event of click in android

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-18:
-

Assignee: Adam Feng

> bubble up event of click in android
> ---
>
> Key: WEEX-18
> URL: https://issues.apache.org/jira/browse/WEEX-18
> Project: Weex
>  Issue Type: Improvement
> Environment: weex_sdk 0.11 / 0.10
>Reporter: xingjiu
>Assignee: Adam Feng
>  Labels: android, event
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Binding a click event on child element, when the parent element binding a 
> long press event. Then just long press at the child element.
> Two mistakes occurs:
> 1. the parent long press event not be fired.
> 2. the child click event fired.
> Demo is at http://dotwe.org/weex/a20e3898b3875e04d28ef394509d2088
> I know this is a hard work to resolve it, while we can find out a solution 
> firstly. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-54) [proposal] Support to detect the feature compatibility of weex

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-54:
-

Assignee: Hanks Zhang  (was: sospartan)

> [proposal] Support to detect the feature compatibility of weex
> --
>
> Key: WEEX-54
> URL: https://issues.apache.org/jira/browse/WEEX-54
> Project: Weex
>  Issue Type: New Feature
>  Components: JSFM
>Affects Versions: 0.15
>Reporter: Hanks Zhang
>Assignee: Hanks Zhang
>Priority: Minor
>  Labels: features
>
> h2. Background
> Because Weex support to extend components and modules, so the host 
> environment will be very different. Weex needs a mechanism to detect whether 
> a feature is supported in the current environment.
> h2. API Design
> {code:javascript}
> weex.supports(condition : String) : Boolean | Null
> {code}
> * param: a formatted string. @TYPE/NAME
> * return value: supported -> true | unsupported -> false | unclear -> null
> h2. Usage
> {code:javascript}
> // Detects whether the embed component is supported
> weex.supports('@component/embed')
> // Detects whether the picker module is supported
> weex.supports('@module/picker')
> // Detects whether the dom.getComponentRect method is supported
> weex.supports('@module/dom.getComponentRect')
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-17) Abstract a common `weex` variable for each JS framework

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-17:
-

Assignee: Hanks Zhang

> Abstract a common `weex` variable for each JS framework
> ---
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
>  Issue Type: Improvement
>Reporter: Jinjiang Zhao
>Assignee: Hanks Zhang
>Priority: Minor
>  Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can 
> abstract and prepare something which every JS framework will do the same and 
> put them into a common `weex` variable. Then this variable could be used 
> directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId 
> in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex 
> page. Because it certainly need processes functions, so it depends on the 
> CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document 
> instance.
> 4. Config object of the Weex page. It should contains env info, framework 
> info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And 
> NativeModuleGetter instance, Document instance, config object and CSS units 
> calculator could be exposed on `weex` variable as `{ requireModule(name), 
> document, config, unit }`. So the new API design of 
> `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-35) A component open URL got different action on iOS and Android

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-35:
-

Assignee: xingZhang

> A component open URL got different action on iOS and Android
> 
>
> Key: WEEX-35
> URL: https://issues.apache.org/jira/browse/WEEX-35
> Project: Weex
>  Issue Type: Bug
> Environment: iOS, Android
>Reporter: Isken Huang
>Assignee: xingZhang
>
> iOS: 
> https://github.com/apache/incubator-weex/blob/master/ios/sdk/WeexSDK/Sources/Component/WXAComponent.m#L63
> Android: 
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/ui/component/WXA.java#L53
> iOS SDK's is when href exist and string length more then 0 to do something. 
> Android SDK's is when href is not null to do something. This logic should be 
> the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-33) Config Ability in weex

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-33:
-

Assignee: xingZhang

> Config Ability in weex
> --
>
> Key: WEEX-33
> URL: https://issues.apache.org/jira/browse/WEEX-33
> Project: Weex
>  Issue Type: New Feature
>Reporter: xingjiu
>Assignee: xingZhang
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Background：
> As we know, weex now has NO config module. Every mobile of weex are using the 
> same config (the config in source code).
> More and more module or component requires the ability to sperate one from 
> each other.
> Such as Prefetch, Prerender module. There should be a way to config the how 
> the module works, like how many items it cound do the prefetch. This config 
> will be different in different apps.
> Solution:
> Add a module named of WXConfigModule in weex_sdk, a simple key-value storage 
> is enough.
> API is
> void setConfig(String name, Object value)
> Object getConfig(String name)
> void sync(String name) // get the lastest config from server
> void syncAll()
> void invalid(String name) // option.  invalid a config for once, using in 
> debug of bugfix scenario
> The default implement is calling the config interface. 
> App like TAOBAO will using orange to sync configs from server.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-45) clearTimeout and clearInterval doesn't work when funId is greater than 127

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-45:
-

Assignee: YorkShen

> clearTimeout and clearInterval doesn't work when funId is greater than 127
> --
>
> Key: WEEX-45
> URL: https://issues.apache.org/jira/browse/WEEX-45
> Project: Weex
>  Issue Type: Bug
>Reporter: YorkShen
>Assignee: YorkShen
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-49) add osName to weex.config.env

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-49:
-

Assignee: Danz He  (was: sospartan)

> add osName to weex.config.env
> -
>
> Key: WEEX-49
> URL: https://issues.apache.org/jira/browse/WEEX-49
> Project: Weex
>  Issue Type: Improvement
>  Components: Project 
>Affects Versions: 0.15
>Reporter: Danz He
>Assignee: Danz He
>
> Since the *weex.config.env.platform* on web has tell user that the 
> environment is 'Web', there should be another property to tell which system 
> ('android' or 'iOS') it is on. So a *weex.config.env.osName* is needed. On 
> Android and iOS platform, the platform name and the osName is the same, 
> however  on Web platform (webview or mobile browsers), they are different.
> For example, a weex page runing in a chrome browser on a Android device with 
> weex-vue-render. access the two properties will be:
> * weex.config.env.platform: 'Web'
> * weex.config.env.osName: 'android'
> * weex.config.env.osName: 'iOS'
> doc: http://weex.apache.org/references/weex-variable.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-63) Android refactor lines

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-63:
-

Assignee: YorkShen  (was: sospartan)

> Android refactor lines
> --
>
> Key: WEEX-63
> URL: https://issues.apache.org/jira/browse/WEEX-63
> Project: Weex
>  Issue Type: New Feature
>Reporter: YorkShen
>Assignee: YorkShen
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-51) The console APIs doesn't work on Android

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-51:
-

Assignee: YorkShen  (was: sospartan)

> The console APIs doesn't work on Android
> 
>
> Key: WEEX-51
> URL: https://issues.apache.org/jira/browse/WEEX-51
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Affects Versions: 0.15
>Reporter: Hanks Zhang
>Assignee: YorkShen
>
> As Weex switched its js engine to JSC on Android, the console APIs doesn't 
> work anymore.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-66) Support FlatGUI

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-66:
-

Assignee: YorkShen  (was: sospartan)

> Support FlatGUI
> ---
>
> Key: WEEX-66
> URL: https://issues.apache.org/jira/browse/WEEX-66
> Project: Weex
>  Issue Type: New Feature
>Reporter: YorkShen
>Assignee: YorkShen
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-70) weex pull request rules discuss

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-70:
-

Assignee: Adam Feng  (was: sospartan)

> weex pull request rules discuss
> ---
>
> Key: WEEX-70
> URL: https://issues.apache.org/jira/browse/WEEX-70
> Project: Weex
>  Issue Type: Improvement
>  Components: Project 
>Affects Versions: 0.17
>Reporter: Zechang Xie
>Assignee: Adam Feng
>
> weex pull request rules discuss for better run weex in apache.
> give me your suggest.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (WEEX-27) Prerender

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng resolved WEEX-27.
---
Resolution: Fixed

> Prerender
> -
>
> Key: WEEX-27
> URL: https://issues.apache.org/jira/browse/WEEX-27
> Project: Weex
>  Issue Type: New Feature
> Environment: Android, iOS, (not Html5)
>Reporter: xingjiu
>Assignee: Adam Feng
> Attachments: TB12RlEQFccXFXX.jpg
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> In order to impove the page open speed, we have intro many ways, such as 
> js-bundle prefetch.
> Now we have a new idea of render the next page in background. When click the 
> button to jump to the next page, just show it, no other js file execute cost 
> needed.
> We call it prerender.
> First. Limition
> Prerender will benifit user experience of waiting time of new page load.
> It is like a tradition way, use extre space(memory) to reduce time cost.
> We need to protected our app`s memory cost, so just one page can be 
> prerendered. This limit maybe removed later.
> Second. How we do?
> One way is to store the callNative commander in memory.
> We know weex use javascript engine to explain how the page will be render, 
> then js will use callNative() to make native views created.
> Once we just store the callNative commander, not to execute it. When the page 
> is truely show, do the commander executed.
> The attach image is the order of weex render steps currently.
> Finally. 
> Our goal is to make weex page show quickly.
> We assure that using prerender, the page open in one second will reach 99.9+ 
> precent. And the global festive main page will works prefect in prerender 
> mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-43) Add release job to travis CI

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-43:
-

Assignee: Zechang Xie  (was: Adam Feng)

> Add release job to travis CI
> 
>
> Key: WEEX-43
> URL: https://issues.apache.org/jira/browse/WEEX-43
> Project: Weex
>  Issue Type: Task
>  Components: Project 
>Reporter: sospartan
>Assignee: Zechang Xie
>
> Some changes will make to project's travis config:   
> * Put commands to `.travis` config use `if` statement, avoid using script 
> file will make more easier to determine problems.
> * Add our release test
>   * Create a release source tarball
>   * test build script for source release
>   * upload daily build artfacts (This will wait until we add snapshot upload 
> script)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-44) Add script to upload snapshot artifact to maven/pods repo

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-44:
-

Assignee: xingZhang  (was: Adam Feng)

> Add script to upload snapshot artifact to maven/pods repo
> -
>
> Key: WEEX-44
> URL: https://issues.apache.org/jira/browse/WEEX-44
> Project: Weex
>  Issue Type: Sub-task
>  Components: Project 
>Reporter: sospartan
>Assignee: xingZhang
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-78) The ES7 methods should be removed to improve compatibility

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-78:
-

Assignee: Hanks Zhang  (was: sospartan)

> The ES7 methods should be removed to improve compatibility
> --
>
> Key: WEEX-78
> URL: https://issues.apache.org/jira/browse/WEEX-78
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Reporter: Hanks Zhang
>Assignee: Hanks Zhang
>  Labels: patch
>
> The implementation of event bubbling in JSF is using 
> `Array.prototype.includes` API [1] which is defined in ECMAScript 2016 (ES7). 
> This method is not compatible with low version js engines and should be 
> replaced.
> [1] 
> https://github.com/apache/incubator-weex/blob/4bc653653c1460dcad0642ef654e593c89ebaaf1/html5/runtime/vdom/Element.js#L412



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (WEEX-79) Modify document website style of weex.

[Adam Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Feng reassigned WEEX-79:
-

Assignee: Hanks Zhang  (was: sospartan)

> Modify document website style of weex.
> --
>
> Key: WEEX-79
> URL: https://issues.apache.org/jira/browse/WEEX-79
> Project: Weex
>  Issue Type: Improvement
>Reporter: erha19
>Assignee: Hanks Zhang
>
> Problem:
> Document page space is less and poor reading effect
> Solution:
> - Change background-color of body.
> - Add a separate scroll bar for the document page



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-17) Abstract a common `weex` variable for each JS framework

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200064#comment-16200064
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user weex-bot commented on the issue:

https://github.com/apache/incubator-weex/pull/785
  





  

  
  Warnings

  
  
  :warning:
  No Changelog changes!

  

  :warning:
  These new JS files do not have Flow enabled: 
html5/runtime/api/WeexInstance.js, html5/runtime/api/component.js, 
html5/runtime/api/module.js

  

  :warning:
  This PR should update related documents as well. 

  




  

  
  Messages

  
  
  :book:
  danger test finished.

  




  Generated by :no_entry_sign: http://github.com/danger/danger-js/;>dangerJS




> Abstract a common `weex` variable for each JS framework
> ---
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
>  Issue Type: Improvement
>Reporter: Jinjiang Zhao
>Priority: Minor
>  Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can 
> abstract and prepare something which every JS framework will do the same and 
> put them into a common `weex` variable. Then this variable could be used 
> directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId 
> in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex 
> page. Because it certainly need processes functions, so it depends on the 
> CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document 
> instance.
> 4. Config object of the Weex page. It should contains env info, framework 
> info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And 
> NativeModuleGetter instance, Document instance, config object and CSS units 
> calculator could be exposed on `weex` variable as `{ requireModule(name), 
> document, config, unit }`. So the new API design of 
> `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-17) Abstract a common `weex` variable for each JS framework

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200055#comment-16200055
 ] 

ASF GitHub Bot commented on WEEX-17:


GitHub user Hanks10100 opened a pull request:

https://github.com/apache/incubator-weex/pull/785

[WEEX-17] Abstract "weex" variable for each js framework

Fix [WEEX-17](https://issues.apache.org/jira/browse/WEEX-17).

Pass the `weex` variable to each front-end framework in the last argument 
of `createInstance`. Its API is defined 
[here](http://weex.apache.org/references/weex-variable.html).

Both Vue and Rax can use the `weex` variable with the same implementation. 
Currently, Vue passed `weex` variable to the js bundle, but Rax doesn't pass it 
yet.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Hanks10100/incubator-weex jsfm-feature-weex

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-weex/pull/785.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #785


commit 48ccea1c4edc02b7af80e81f5639243776bef077
Author: Hanks 
Date:   2017-10-11T09:19:48Z

+ [jsfm] add weex variable api in runtime




> Abstract a common `weex` variable for each JS framework
> ---
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
>  Issue Type: Improvement
>Reporter: Jinjiang Zhao
>Priority: Minor
>  Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can 
> abstract and prepare something which every JS framework will do the same and 
> put them into a common `weex` variable. Then this variable could be used 
> directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId 
> in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex 
> page. Because it certainly need processes functions, so it depends on the 
> CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document 
> instance.
> 4. Config object of the Weex page. It should contains env info, framework 
> info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And 
> NativeModuleGetter instance, Document instance, config object and CSS units 
> calculator could be exposed on `weex` variable as `{ requireModule(name), 
> document, config, unit }`. So the new API design of 
> `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)