Re: [ANNOUNCEMENT] Weex.io will be offliine in the end of this month

[Hanks Zhang]

I support using xxx.dotwe.org instead of editor.weex.io if it really has
the branding issue. The candidate domain name could be editor.dotwe.org or
v2.dotwe.org.

Technological speaking, redirect editor.weex.io to the new domain in DNS is
feasible. However, the dotwe.org is not under my control, but maybe I can
find the one who is able to configure it.

Best Regards,
Hanks

申远  于2019年11月27日周三 上午11:42写道：

> From the information I have, the server of editor.weex.io will be offline
> by the end of Dec, 2019 if we don't migrate to the new data center. While
> the domain name could be alive until Nov, 2020 if we don't pay for it.
>
> I will not judge the domain name decsion made by ASF brand management, but
> I think it would satisfy ASF brand management, Apache Weex user, Apache
> Weex Committer, domain owner and server maintainer like you until Nov, 2020
> if we pay for the server and binding the server to a new domain name, like
> .dotwe.org.
>
> IMO, this is the best solution we have now, though I don't know what we
> shall do if domain is controlled and misused by third-party after Nov, 2020.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年11月26日周二 下午7:10写道：
>
>> I think the concerns from ASF is mainly on domain part, as the domain
>> weex.io does lead some confusion. Is domain of http://dotwe.org/vue on
>> under your control? Could we create redirect editor.weex.io to
>> .dotwe.org through http 301 redirect or DNS CNAME ?
>>
>> IMNAL, but I think backend-server is not againts any rules of ASF, we
>> just need to pay for the bill every year, just like the domain name. @Hanks
>> Zhang  I know you're planning to migrate the
>> server to another data-center due to some technical reason, but this is OK
>> with ASF's rules according to my undersing.
>>
>> Best Regards,
>> YorkShen
>>
>> 申远
>>
>>
>> Hanks Zhang  于2019年11月26日周二 下午4:29写道：
>>
>>> In my opinion, both close weex.io or migrate the server to ASF's VM is
>>> not a good idea, the cost is too expensive.
>>>
>>> For the branding issue of the domain, I think we can register a new
>>> domain name to replace the editor.weex.io, and redirect the legacy
>>> domain to the new one. Currently, the weex.io domain is under my
>>> GoDaddy account and will be expired at 2020/11/20.
>>>
>>> For the server that provides service of editor.weex.io, If we CAN NOT
>>> continue using it, we could apply for a new server that has no branding
>>> issue with ASF to migrate it.
>>>
>>>
>>> Best Regards,
>>> Hanks Zhang
>>>
>>>
>>> 申远  于2019年11月26日周二 上午11:55写道：
>>>
>>>> Well, it seems like the brand management,VP doesn't like the idea [1]
>>>> that we hold the domain name of http://editor.weex.io/, we have to
>>>> take down the domain name for better or worse. As some of you may not see
>>>> discussion in private mailing list, I will move it back to this mailing
>>>> list. Here is the options we have.
>>>>
>>>>- Take down weex.io, which saves us the money and satisfies the
>>>>rule of apache brand management. Of course, this will have bad 
>>>> influence on
>>>>Weex users.
>>>>- Transfer weex.io to ASF, and use it as always. This approach
>>>>doese seems better, but ASF refused to pay for the domain, which means 
>>>> the
>>>>    domain maintainer has to pay for it even it's not in his/her control. I
>>>>don't know wheter the domain maintainer would agree with this. @Dan
>>>> @Hanks Zhang  Any
>>>>words you want to say on this proposal ? I remembered the domain is 
>>>> under
>>>>one of you control.
>>>>- Request a VM from INFRA ASF and host the dynamic content of
>>>>editor.weex.io to the new VM. I don't know whether this is possible
>>>>in the aspect of engineering, still need replies from @Dan
>>>> @Hanks Zhang 
>>>>
>>>> If there are other opinions, please let me know. I am trying to do my
>>>> best to solve the problem, but none of the above solutions make me happy.
>>>>
>>>> [1]
>>>> https://lists.apache.org/thread.html/78122338690c154ce1637bb0509edb948724fe98b61c7632e91cfc53@%3Cprivate.weex.apache.org%3E
>>>>
>>>> Best Regards,
>>>> YorkShen
>>>>
>>>> 申远
>>>>
>>>>
>>>> 申远  于2019年11月6日周三 下午8:45写道：
>>>>
>>>>>

Re: [ANNOUNCEMENT] Weex.io will be offliine in the end of this month

[Hanks Zhang]

In my opinion, both close weex.io or migrate the server to ASF's VM is not
a good idea, the cost is too expensive.

For the branding issue of the domain, I think we can register a new domain
name to replace the editor.weex.io, and redirect the legacy domain to the
new one. Currently, the weex.io domain is under my GoDaddy account and will
be expired at 2020/11/20.

For the server that provides service of editor.weex.io, If we CAN NOT
continue using it, we could apply for a new server that has no branding
issue with ASF to migrate it.


Best Regards,
Hanks Zhang


申远  于2019年11月26日周二 上午11:55写道：

> Well, it seems like the brand management,VP doesn't like the idea [1] that
> we hold the domain name of http://editor.weex.io/, we have to take down
> the domain name for better or worse. As some of you may not see discussion
> in private mailing list, I will move it back to this mailing list. Here is
> the options we have.
>
>- Take down weex.io, which saves us the money and satisfies the rule
>of apache brand management. Of course, this will have bad influence on Weex
>users.
>- Transfer weex.io to ASF, and use it as always. This approach doese
>seems better, but ASF refused to pay for the domain, which means the domain
>maintainer has to pay for it even it's not in his/her control. I don't know
>wheter the domain maintainer would agree with this. @Dan
> @Hanks Zhang  Any words
>you want to say on this proposal ? I remembered the domain is under one of
>you control.
>- Request a VM from INFRA ASF and host the dynamic content of
>editor.weex.io to the new VM. I don't know whether this is possible in
>the aspect of engineering, still need replies from @Dan
> @Hanks Zhang 
>
> If there are other opinions, please let me know. I am trying to do my best
> to solve the problem, but none of the above solutions make me happy.
>
> [1]
> https://lists.apache.org/thread.html/78122338690c154ce1637bb0509edb948724fe98b61c7632e91cfc53@%3Cprivate.weex.apache.org%3E
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年11月6日周三 下午8:45写道：
>
>> After some digging, I found that domain maintainer must request an
>> explicit permit [1] from VP, Brand management if they use Apache Trademark
>> in their domain. There is more work we need to do here.
>>
>> [1] http://www.apache.org/foundation/marks/domains.html#permission
>>
>> Best Regards,
>> YorkShen
>>
>> 申远
>>
>>
>> 申远  于2019年11月6日周三 上午11:14写道：
>>
>>> First of all, thanks all for participating.
>>>
>>> it would be great if someone could find a way to pay for it and keep the
>>>> redirects alive so no external links break.
>>>>
>>>
>>> I will see what I can do, maybe my company could pay the bill, as the
>>> company relies on Weex deeply.
>>>
>>> I found a new domain name[2] in the page[1]. And the content in the two
>>>> domain names is highly similar. Is it possible to merge the contents of
>>>> domain [3] into domain [2] ?
>>>>
>>>
>>> Based on my communnication with the website maintainer,
>>> http://dotwe.org/vue is the V1 version, and http://editor.weex.io/ is
>>> the V2 version, it's very unlikely to merge them into one, especially some
>>> features in V1 version doesn't get support in V2 version.
>>>
>>> Besides, both of the sites you mentioned may violate the brand of Apache
>>> Weex, they have to change their content or donate to ASF. Considering ASF
>>> website only has static content, mirgating those websites containing
>>> dynamic content to ASF server will be a great deal of work, or impractical,
>>> even if they're willing to donate to ASF.
>>>
>>> I am in favour of remaining the current situation, e.g. two websites
>>> separated from Apache Weex,  if they could fix the brand issue.
>>>
>>> Best Regards,
>>> YorkShen
>>>
>>> 申远
>>>
>>>
>>> Jan Piotrowski  于2019年11月6日周三 上午5:20写道：
>>>
>>>> I second the comments made before, as weex.io seems to be in use for
>>>> some
>>>> things and probably also linked all over the internet with earlier
>>>> mentions
>>>> of Weex, it would be great if someone could find a way to pay for it and
>>>> keep the redirects alive so no external links break.
>>>>
>>>> (I'd be happy to sponsor the first year or three - just contact me
>>>> directly
>>>> so I can send the money to the person taking care of this.)
>>>>
>>>

Re: [DISCUSS] Graduate Weex from Apache Incubator

[Hanks Zhang]

As a committer of Weex, I am really happy to hear that Weex has so
remarkable progress. I also think Weex is ready for graduate.

Since Weex began incubating in Nov 2016, it has already published 5
releases and widely used in real-world production with many different apps
and companies. I wish Weex could keep on improving itself and become a real
community-based project.

Looking forward to the next progress.

Best Regards,
Hanks Zhang


Jan Piotrowski  于2019年9月28日周六 上午1:56写道：

> Nice progress.
>
> Let me know when website and all public communication and content is
> on par for what you think should be fine for graduation, and I will
> spend the time to go through all of it and see if I can find any
> confusing parts.
>
> -J
>
> Am Fr., 27. Sept. 2019 um 13:40 Uhr schrieb shihan zheng
> :
> >
> > Very beautiful progress, thanks to York Shen’s efforts ！
> >
> > During this time, we spent a lot of time learning "the Apache Way" to
> > improve the Apache Weex(Incubating)  community.
> >
> > There may still be some problems at present, hope everyone can help find
> > problems together and provide valuable advice.
> >
> > Looking forward to Apache Weex(Incubating)  graduation！
> >
> > Best Regards,
> >
> > shihan zheng
> >
> >
> > 饮源
> >
> > York Shen  于2019年9月27日周五 下午3:32写道：
> >
> > > Hi, community.
> > >
> > > First of all, I sent this email to make consensus, not call an official
> > > vote. As always, everyone is welcomed to expressed their opinions.
> > >
> > > Apache Weex(Incubating) joined the Incubator since Nov, 2016 and the
> > > community has grown diverse, moved to ASF infrastructure, learnt
> Apache way
> > > and its value behind. Some of achievements of Apache Weex is listed
> below:
> > > Published 5 release by 5 release manager
> > > Inviting 16 new committers
> > > Migrated code repos to https://github.com/apache/incubator-weex/ <
> > > https://github.com/apache/incubator-weex/>
> > > Migrated website to https://weex.apache.org/ <https://weex.apache.org/
> >
> > > Migrated conversation/decision to d...@weex.apache.org  > > d...@weex.apache.org>
> > >
> > > And there are some problems needed to be solved before graduation.
> Luckily
> > > for us, we have solutions for each one of the problems:
> > > Third party IP: We will make those third part IP donated to ASF,  and
> > > we’re currently in IP clearance process.
> > > LGPL runtime dependency: We got these problems solved by switching to
> > > BSD-Licensed jsc-android [1] in this PR [2].
> > > Rename android package name to org.apache.weex: Resolved by this PR [3]
> > > Some web pages [4] on our website relies on third-part server API: We
> will
> > > delete this page soon.
> > >
> > > I shall call a vote for Apache release after problem 2 solved, and will
> > > call a formal vote for graduation in this mailing list when all of the
> > > problems above solved. According to my estimation, two or three weeks
> is
> > > needed for solving all the issues above. At last, I hope we could
> graduate
> > > from Apache Incubator before next Podlling report.
> > >
> > > [1] https://www.npmjs.com/package/jsc-android <
> > > https://www.npmjs.com/package/jsc-android>
> > > [2] https://github.com/apache/incubator-weex/pull/2940 <
> > > https://github.com/apache/incubator-weex/pull/2940>
> > > [3] https://github.com/apache/incubator-weex/pull/2925 <
> > > https://github.com/apache/incubator-weex/pull/2925>
> > > [4] https://weex.apache.org/community/solutions.html <
> > > https://weex.apache.org/community/solutions.html>
> > >
> > > Best Regards,
> > > York Shen
> > >
> > > 申远
> >
> >
> >
> > --
> >
> > Best Regards!
> > -
> > Shihan Zheng (Weex project team member )
>

[Proposal] Enhance and standardize Weex's style ability with CSSOM

[Hanks Zhang]

## Background

To improve the development experience should be the priority of Weex and
Weex's style ability often be criticized by developers, it's not competent
enough and hasn't been improved for a long time.

I think we should take more efforts to improve our css features.

## What CSSOM can do?

CSSOM (CSS Object Module) is a specification in W3C which defines a group
of APIs for managing CSS, such as StyleSheet, CSSRule, Selectors, etc.

In particular, CSSOM can bring more css selector support for Weex, the
performance will be improved as well. Moreover, CSSOM is a standard way to
implement css features, just as browsers do.

For example, the following css will be supported with CSSOM:

```css
/* @media rule */
@media screen and (min-width: 900px) {

  /* complex css selector */
  #root div text.title {
padding: 1vw 3vh;  /* css shorthand */
border: 2px dotted rgba(0, 24, 133, .2); /* compound values */
  }
}
```

## Implementation

I have already written a standalone C++ library to implement a lite version
of CSSOM, which only supports a subset of specs. It can be integrated into
Weex directly.

The following parts should be modified to achieve the goal:

* DSL Frameworks: Adjust the style management API and update the compilers.
* JS Framework: Sending the original class list to native, stop merging
them into inline styles.
* Weex Core: Integrate the cssom library, use it to store and query styles.

I'll share more technical details about it later. Looking forward to your
opinions.

Best Regards,
Hanks

Re: [NEW MENTOR REQUIRED] Apache Weex (incubating)

[Hanks Zhang]

+1.

I also think Weex needs more guidance from more mentors, they can give
advice from different perspectives. On the other hand, most PPMC and
committers of Weex are Chinese, we wish Weex can absorb ideas form
more world-wide developers from different cultures. Looking forward to your
opinions.

Best Regards,
Hanks Zhang

Jonathan Dong  于2018年11月12日周一 下午7:32写道：

> Hi Folks,
>
> I’m writing to seek for new motivated mentors for the Apache Weex
> (incubating) project, to drive and mentor the community and project to
> graduate.
>
> Weex is a project aims to build high-performance mobile applications by
> leveraging mobile web development experience. It was accepted into the
> Apache Incubator since Nov. 30, 2016, there are 2 Apache releases during
> the incubation period, and 11 PPMC and 3 committers by now. We have been
> struggling with the active mentorship which could lead us through the
> podling process and push the project to the graduation, for now we only
> have one active mentor Willem Jiang (who helps a lot to grow the community
> as well as the processes, thanks), and we believe it’s the right time to
> invite one more mentor or two to offload some mentoring duty from Willem
> and push us through the graduation.
>
> If you are interested, please let use know at
> dev@weex.incubator.apache.org. Looking forward to your guidance.
>
> Cheers,
>
> Jonathan Dong
>

Re: [DISCUSS] The Content of Weex Podling Report

[Hanks Zhang]

Sorry for missing this question, I will answer it once I have the
permission to update the wiki file.

Regards,
Hanks

Justin Mclean  于2018年11月5日周一 下午2:45写道：

> Hi,
>
> Thanks for filling in the report. Is there any reason that this question
> was removed and not answered?
>
> "Have your mentors been helpful and responsive or are things falling
> through the cracks? In the latter case, please list any open issues
> that need to be addressed."
>
> Thanks,
> Justin
>

[Proposal] Improve the workflow, website and tools of Weex

[Hanks Zhang]

Weex has been incubating at ASF since 2016-06-30, but the community is
still lacking activity, documents and tools are still not user-friendly or
easy-to-use. We have to say that, Weex isn't doing well in the community,
so I conceived a plan to improve them.

I summarized two main problems of Weex community:

  (1) The quality of documents and tools.
  (2) Information asymmetry.

For the (1) problem, Weex's documents are outdated and not accurate enough.
There is no other way, we have to review or even rewrite them. We can
arrange 1or 2 months time to do that together. It should be a one-off task
if we really write them well. Moreover, I suggest allowing readers to rate
each document and rewrite most low-rate document every (one or two) week.

As for the tools, we have three of them: the online editor (dotwe.org), the
playground app, and the command line toolkit. But they are too simple and
not stable enough. We should improve them as an integrated product, make it
easy-to-use and stable.

For the (2) problem, the main reason is Weex contributors don't like to
share their ideas and what they are actually doing. The community can't see
any clear development progress except those unreadable commit logs. And
worse, we haven't given timely feedback to the issues and feature requests,
we just ignored them actually, which will disappoint the community.

To solve it, I think we should migrate the workflow to the mailing list.
Assign specific contributors to be responsible for managing community
affairs in turn, until every core members know how it works and can handle
those affairs on their own initiative.

In summary, the key points are as follows:

1. Share ideas and development progress in the mailing list regularly.
2. Manage community affairs (issues, podling report, etc) in turn.
3. Update the structure of the website and review/rewrite all documents.
4. Rewrite most low-rate document every week.
5. Refactor the online editor, playground app, toolkit to offer consistent
and stable service.
6. Allow community developers to explore and publish tutorials or examples
efficiently.

I encourage all contributors to take part in it. Let's make Weex much
better and build a healthy community.

Best Regards,
Hanks Zhang

Re: [DISCUSS] The Content of Weex Podling Report

[Hanks Zhang]

Update: the IPMC report page is
https://wiki.apache.org/incubator/November2018

>

Re: [DISCUSS] The Content of Weex Podling Report

[Hanks Zhang]

Here is the draft of the podling report, please share your opinions if you
found something improper.


Weex

Weex is a framework for building high-performance mobile apps with modern
web development experience.

Weex has been incubating since 2016-11-30.

Three most important issues to address in the move towards graduation:

  1. Propose more open discussions in the mailing list, improve the
activity.
  2. Establish a regular release schedule and a clear roadmap.
  3. Develop more committers and PPMCs, stay focused on the community.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

  Apologize for missing the last podling report.

  The main reason for it is the PPMC and committers does not pay enough
attention in the mailing list. We have realized this mistake and decide to
take more efforts on building the community.

  Here are some actions:
  1. Hold meetings regularly among core contributors of Weex and publish
the summary to the mailing list.
  2. Take turns on duty for each release and podling reports.

How has the community developed since the last report?

  * Released a new version (v0.19.0) of Weex.
https://lists.apache.org/thread.html/3e7bfe9e3f79a8d4b46dbe668bfb559e4e539bd7c5f4143107e6af00@%3Cgeneral.incubator.apache.org%3E
  * Hold a meetup in Shanghai at 2018-09-15, discussed technologies about
the new render pipeline and interactive experience of Weex.
  * Migrate the source code from (git-wip-us.apache.org) to (
gitbox.apache.org) and enabled the issue panel on the GitHub.

How has the project developed since the last report?

  * In average, more than 10 PRs or commits were merged to the main branch
each week. The Github repository now has 162 contributors (8 new since the
last
report) and 1451 forks (130 new).
  * Weex has developed a new render pipeline and used it in production, but
it still needs more improvement.
  * A more CSS-friendly Weex Renderer is under discussing, it can fix many
cross-platform inconsistency problems.

How would you assess the podling's maturity? Please feel free to add your
own commentary.

  [ ] Initial setup
  [ ] Working towards the first release
  [x] Community building
  [x] Nearing graduation
  [ ] Other:

Date of the last release:

  2018-10-08 (v0.19.0)

When were the last committers or PPMC members elected?

  New PPMC member: jondong (Jonathan Dong)

Signed-off-by:

IPMC/Shepherd notes:

--

By the way, I am not the PPMC member yet and not authorized to edit this
page: https://wiki.apache.org/incubator/September2018
I wish someone could help me to update this content to the report page.

Best Regards,
Hanks Zhang

[DISCUSS] The Content of Weex Podling Report

[Hanks Zhang]

Hi, Weex Community

The board meeting of Apache is near, we should finish the IPMC report this
week.

Here is the report outline, there are many questions we should answer. I
will prepare the most of them, please feel free to add your comments.



Weex

Weex is a framework for building high-performance mobile apps with modern
web development experience.

Weex has been incubating since 2016-11-30.

Three most important issues to address in the move towards graduation:

1.
2.
3.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware
of?

How has the community developed since the last report?

How has the project developed since the last report?

How would you assess the podling's maturity? Please feel free to add your
own commentary.

  [ ] Initial setup
  [ ] Working towards the first release
  [x] Community building
  [ ] Nearing graduation
  [ ] Other:

Date of the last release:

2018-10-08 (v0.19.0)

When were the last committers or PPMC members elected?

Have your mentors been helpful and responsive or are things falling
through the cracks? In the latter case, please list any open issues
that need to be addressed.

Signed-off-by:

IPMC/Shepherd notes:

-

Best Regards,
Hanks

Re: Podling Report Reminder - November 2018

[Hanks Zhang]

Sorry for not sending the IPMC report, I will start a discussion and
prepare the report this week.

Best Regards,
Hanks Zhang

Willem Jiang  于2018年10月29日周一 下午4:56写道：

> As we missed the last month IPMC report. Please prepare your IPMC
> report this week.
> We can start the discussion on the mailing list first.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Oct 25, 2018 at 5:34 AM  wrote:
> >
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 21 November 2018, 10:30 am PDT.
> > The report for your podling will form a part of the Incubator PMC
> > report. The Incubator PMC requires your report to be submitted 2 weeks
> > before the board meeting, to allow sufficient time for review and
> > submission (Wed, November 07).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Candidate names should not be made public before people are actually
> > elected, so please do not include the names of potential committers or
> > PPMC members in your report.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> > *   How does the podling rate their own maturity.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > https://wiki.apache.org/incubator/November2018
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
>

Re: Moving the github related notification mail to other mailing list

[Hanks Zhang]

Agree.

Actually, I already create a custom filter to separate GitHub notifications
from normal discussions in my own inbox.

Regards,
Hanks

Jonathan Dong  于2018年10月7日周日 上午11:22写道：

> Agree, commits channel should be a better place for GitHub auto generated
> mails.
>
> Cheers,
> Jonathan Dong
> 
> From: Adam Feng 
> Sent: Sunday, October 7, 2018 11:08:29 AM
> To: dev; dev@weex.incubator.apache.org
> Subject: Re: Moving the github related notification mail to other mailing
> list
>
> Agree,  I suggest move all the Github notifications to
> comm...@weex.apache.org
>
> The email volume from GitHub might lead to dev@ list being ignored.
>
> Thanks.
> Adam Feng
> 在 2018年10月7日 +0800 AM9:42，Willem Jiang ，写道：
> > Hi，
> >
> > As there are lot of traffic from the github in the dev, it's hard for
> > us to checkout the other mail in the dev@weex.
> > Can we move the git related notification to another mailing list?
> >
> > Any thoughts?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
>

[RESULT][VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC4]

[Hanks Zhang]

Dear Weex Community,

I am pleased to announce that the Weex community has approved the release
of 0.19.0 RC4.

The vote has opened for 72+ hours and passed with:
3 binding "+1" votes and 1 non-binding vote
no "0" votes
no "-1" votes

The vote thread:
https://lists.apache.org/thread.html/cdfd9cc5b9ade0bd86fc35a8e56fb76d45b1a785b1025de67f5b@%3Cdev.weex.apache.org%3E

+1, Adam Feng (binding)
+1, Shihan Zheng (binding)
+1, York Shen (binding)
+1, Zhi Qian (non-binding)

Best Regards,
Hanks Zhang

[VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC4]

[Hanks Zhang]

Hi Weex Community,

I'm calling this vote to release Apache Weex (Incubating) version 0.19.0.

The tag to be voted upon:

https://github.com/apache/incubator-weex/commits/0.19.0-rc4
(88caa7fb95a4f8bae6bf3fa53fbd07aa9f496e80)

The source code artifacts can be found at:

https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC4/apache-weex-incubating-0.19.0-RC4-src.tar.gz

The SHA-512 checksum for apache-weex-incubating-0.19.0-RC4-src.tar.gz:

E41BB93D 26BCAB55 F39BF11B 91649221 92A56671 9D076C1A 60182569 E3F29D05
026F73CC
 D09B4F31 2E3012AD A3B00599 B647CD36 E7E0DD8A 19A9D0B3 362C9FFD

The artifacts have been signed with Key: 4FD8BC09C7E9DB81, which can be
found in the keys file:

https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS

Release note about this version:

https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464

This vote will remain open for at least 72 hours.

Please vote on releasing this RC.

[ ] +1 approve

[ ] +0 no opinion

[ ] -1 disapprove (and the reason why)

[jira] [Resolved] (WEEX-547) Remove module proxy cache in each instance

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-547.
--
Resolution: Fixed

> Remove module proxy cache in each instance
> --
>
> Key: WEEX-547
> URL: https://issues.apache.org/jira/browse/WEEX-547
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>    Reporter: Hanks Zhang
>    Assignee: Hanks Zhang
>Priority: Major
>
> JS Framework has a cache strategy for module proxies which is good for 
> performance. But it also a potential reason for the memory leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-445) export requireModule to global

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-445.
--
Resolution: Resolved

> export requireModule to global
> --
>
> Key: WEEX-445
> URL: https://issues.apache.org/jira/browse/WEEX-445
> Project: Weex
>  Issue Type: New Feature
>  Components: JSFM
>Reporter: Zhenfei You
>    Assignee: Hanks Zhang
>Priority: Major
>
> Export requireModule to global, so we can use
> {code:javascript}
> var navigator = requireModule('navigator')
> {code}
> it is equal to 
> {code:javascript}
> var navigator = weex.requireModule('navigator')
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WEEX-547) Remove module proxy cache in each instance

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-547:


 Summary: Remove module proxy cache in each instance
 Key: WEEX-547
 URL: https://issues.apache.org/jira/browse/WEEX-547
 Project: Weex
  Issue Type: Bug
  Components: JSFM
Reporter: Hanks Zhang
Assignee: Hanks Zhang


JS Framework has a cache strategy for module proxies which is good for 
performance. But it also a potential reason for the memory leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Move Incubator-weex-site Repo to Gitbox

[Hanks Zhang]

+1

Totally agree, it can simplify the workflow of updating documents. Really
looking forward to this.

[jira] [Commented] (WEEX-383) scroller scroll-direction:horizontal with div flex:1 not work

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-383:
--

I add an example for you, it works fine on Android. 
[http://dotwe.org/vue/8d4d2721baaf9704556803d92efe15cd]

 

Maybe it's something wrong with the web render and ios.

> scroller scroll-direction:horizontal with div flex:1 not work
> -
>
> Key: WEEX-383
> URL: https://issues.apache.org/jira/browse/WEEX-383
> Project: Weex
>  Issue Type: Bug
> Environment: iOS 10
>Reporter: fh
>    Assignee: Hanks Zhang
>Priority: Major
>
> when i use    
> scroller
> ```
> scroll-direction:horizontal
> flex-direction:row
> ```
>  
> div
> ```
> flex:1
> ```
>  
> the flex:1 will not work
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-236) 标签在Android上设置锚点会刷新

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-236:
--

Duplicated with https://issues.apache.org/jira/browse/WEEX-236

> 标签在Android上设置锚点会刷新
> ---
>
> Key: WEEX-236
> URL: https://issues.apache.org/jira/browse/WEEX-236
> Project: Weex
>  Issue Type: Improvement
>  Components: Android
>Affects Versions: 0.12
>Reporter: 胡广宇
>Assignee: codefurture
>Priority: Minor
> Fix For: 0.13
>
>
> 您好, 我在使用标签时,我通过在src中定义锚点来达到向所展示的html进行传值,和监听. 
> 但是发现设置锚点之后在Android上会刷新页面,而iOS上并不会刷新.
> 因此觉得这是一个issue~  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (WEEX-418) method can not be override

[Hanks Zhang (JIRA)]

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

Hanks Zhang closed WEEX-418.

Resolution: Fixed

> method can not be override
> --
>
> Key: WEEX-418
> URL: https://issues.apache.org/jira/browse/WEEX-418
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.20
>Reporter: chuyi
>Assignee: codefurture
>Priority: Minor
>
> the following method is final: 
> * removeEvent
> * removeAllEvents



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-324) How to load different CSS for landscape and portrait Screen?

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-324:
--

Be compatible with pad or tablet is a known feature request of Weex. We are 
planning to support media query in the CSS, then you can use this code to 
specify styles in different orientations.

 

```css

{{@media screen and (orientation: landscape) {}}

{{  body { flex-direction: row; }}}

{{}}}

{{@media screen and (orientation: portrait) {}}

{{  body { flex-direction: column; }}}

{{}}}

{{```}}

 

This feature is not supported yet, but under considering now.

 

> How to load different CSS for landscape and portrait Screen?
> 
>
> Key: WEEX-324
> URL: https://issues.apache.org/jira/browse/WEEX-324
> Project: Weex
>  Issue Type: Bug
>Reporter: mjsornp
>Assignee: Adam Feng
>Priority: Major
>
> We want run our Application both in phone and pad.
> We can get the orientation of screen，But We don't how to load different CSS 
> for landscape and portrait?
> Do you have any suggestion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-470) module lost after switch from on Activity to previous Activity

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-470.
--
Resolution: Resolved
  Assignee: Hanks Zhang  (was: codefurture)

> module lost after switch from on Activity to previous Activity
> --
>
> Key: WEEX-470
> URL: https://issues.apache.org/jira/browse/WEEX-470
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.19
>Reporter: 华逢义
>Assignee: Hanks Zhang
>Priority: Blocker
>
> Activity A started Activity B.
> B finished and back to A
> After this operation.weex.requireModule(xxx) does not work in Activity A
> the error is as follow:
> {color:#FF}D/jsLog: [JS Framework] Failed to requireModule("stream"), 
> instance (4) doesn't exist anymore.__ERROR{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (WEEX-544) 使用ref的时，当data里的属性与function重名，会提示XXX is not a function

[Hanks Zhang (JIRA)]

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

Hanks Zhang closed WEEX-544.

Resolution: Won't Fix
  Assignee: Hanks Zhang  (was: Adam Feng)

> 使用ref的时，当data里的属性与function重名，会提示XXX is not a function
> -
>
> Key: WEEX-544
> URL: https://issues.apache.org/jira/browse/WEEX-544
> Project: Weex
>  Issue Type: Bug
>Reporter: Jiajie Tan
>    Assignee: Hanks Zhang
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-544) 使用ref的时，当data里的属性与function重名，会提示XXX is not a function

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-544:
--

If using the same name in the "data" and "function", one of them will be 
overridden. That's fairly normal. If you found a bug, please offer a demo to 
reproduce it.

> 使用ref的时，当data里的属性与function重名，会提示XXX is not a function
> -
>
> Key: WEEX-544
> URL: https://issues.apache.org/jira/browse/WEEX-544
> Project: Weex
>  Issue Type: Bug
>Reporter: Jiajie Tan
>Assignee: Adam Feng
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[RESULT][VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC3]

[Hanks Zhang]

Dear Weex Community,

I am pleased to announce that the Weex community has approved the release
of 0.19.0 RC3.

The vote has opened for 72+ hours and passed with:
3 binding "+1" votes
no "0" votes
no "-1" votes

The vote thread:
https://lists.apache.org/thread.html/40d49fa7338680253be47382c26150a1730992611a26267648f2@%3Cdev.weex.apache.org%3E

+1, Adam Feng (binding)
+1, York Shen (binding)
+1, Shihan Zheng (binding)

We'll continue to start the IPMC vote now.

Best Regards,
Hanks Zhang

[VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC3]

[Hanks Zhang]

Hi Weex Community,

I'm calling this vote to release Apache Weex (Incubating) version 0.19.0.

The tag to be voted upon:

[
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=shortlog;h=refs/tags/0.19.0-rc3](https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=shortlog;h=refs/tags/0.19.0-rc3)

Hash for the release tag:

ab1a91db5aa585d5e7721311260ad5dd3a0e4b16

The source tarball can be found at:

[
https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC3/](https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC3/)

The artifacts have been signed with Key: 4FD8BC09C7E9DB81, which can be
found in the keys file:

[
https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS](https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS)

Release note about this version:

[
https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464](https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464)

This vote will remain open for at least 72 hours.

Please vote on releasing this RC.

[ ] +1 approve

[ ] +0 no opinion

[ ] -1 disapprove (and the reason why)

[jira] [Resolved] (WEEX-225) Module build failed: TypeError: staticClass.trim is not a function

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-225.
--
Resolution: Won't Fix

> Module build failed: TypeError: staticClass.trim is not a function
> --
>
> Key: WEEX-225
> URL: https://issues.apache.org/jira/browse/WEEX-225
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.18
> Environment: weex-loader:v0.7.2
> weex SDK 0.18
> Android 7.0
>Reporter: wuyanhui
>Assignee: zhengshihan
>Priority: Major
>
>  
>  E/jsengine: ReportException : Exception: Error: Module build failed: 
> TypeError: staticClass.trim is not a function
>  at parseStaticClass 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3699:33)
>  at Array.transformNode 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3661:13)
>  at processElement 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1376:28)
>  at Object.start 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1215:9)
>  at handleStartTag 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:484:15)
>  at parseHTML 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:344:11)
>  at parse 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1160:3)
>  at baseCompile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/b
>  
> reportJSException >>>> instanceId:5, exception function:createInstance, 
> exception:Exception: Error: Module build failed: TypeError: staticClass.trim 
> is not a function
>  at parseStaticClass 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3699:33)
>  at Array.transformNode 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3661:13)
>  at processElement 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1376:28)
>  at Object.start 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1215:9)
>  at handleStartTag 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:484:15)
>  at parseHTML 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:344:11)
>  at parse 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1160:3)
>  at baseCompile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3644:13)
>  at Object.compile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3619:22)
>  at Object.compile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:4277:25)
>  at Object.module.exports 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-vue-loader/lib/template-compiler.js:71:27)
>  (global function):18458:16
>  __webpack_require__@(global function):25:34
>  (global function):18194:43
>  __webpack_require__@(global function):25:34
>  (global function):4827:33
>  __webpack_require__@(global function):25:34
>  (global function):17223:35
>  __webpack_require__@(global function):25:34
>  (global function):33471:34
>  __webpack_require__@(global function):25:34
>  (global function):33375:38
>  __webpack_require__@(global function):25:34
>  (global function):68:37
>  (global function):69:12
>  anonymous@(global function):33679:7
>  (weex framework):1:40926
>  createInstance@(weex framework):1:40937
>  (weex framework):1:255299
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-225) Module build failed: TypeError: staticClass.trim is not a function

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-225:
--

As mentioned in the document, bind class list with a variable is not supported 
yet. 
[http://weex-project.io/cn/references/components/recycle-list.html#yang-shi-gong-neng-de-xian-zhi]

 

But you can bind inline styles as well.

> Module build failed: TypeError: staticClass.trim is not a function
> --
>
> Key: WEEX-225
> URL: https://issues.apache.org/jira/browse/WEEX-225
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.18
> Environment: weex-loader:v0.7.2
> weex SDK 0.18
> Android 7.0
>Reporter: wuyanhui
>Assignee: zhengshihan
>Priority: Major
>
>  
>  E/jsengine: ReportException : Exception: Error: Module build failed: 
> TypeError: staticClass.trim is not a function
>  at parseStaticClass 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3699:33)
>  at Array.transformNode 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3661:13)
>  at processElement 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1376:28)
>  at Object.start 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1215:9)
>  at handleStartTag 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:484:15)
>  at parseHTML 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:344:11)
>  at parse 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1160:3)
>  at baseCompile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/b
>  
> reportJSException >>>> instanceId:5, exception function:createInstance, 
> exception:Exception: Error: Module build failed: TypeError: staticClass.trim 
> is not a function
>  at parseStaticClass 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3699:33)
>  at Array.transformNode 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3661:13)
>  at processElement 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1376:28)
>  at Object.start 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1215:9)
>  at handleStartTag 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:484:15)
>  at parseHTML 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:344:11)
>  at parse 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:1160:3)
>  at baseCompile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3644:13)
>  at Object.compile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:3619:22)
>  at Object.compile 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-template-compiler/build.js:4277:25)
>  at Object.module.exports 
> (/Users/wuyanhui/Documents/weex/sellerWeex/node_modules/weex-vue-loader/lib/template-compiler.js:71:27)
>  (global function):18458:16
>  __webpack_require__@(global function):25:34
>  (global function):18194:43
>  __webpack_require__@(global function):25:34
>  (global function):4827:33
>  __webpack_require__@(global function):25:34
>  (global function):17223:35
>  __webpack_require__@(global function):25:34
>  (global function):33471:34
>  __webpack_require__@(global function):25:34
>  (global function):33375:38
>  __webpack_require__@(global function):25:34
>  (global function):68:37
>  (global function):69:12
>  anonymous@(global function):33679:7
>  (weex framework):1:40926
>  createInstance@(weex framework):1:40937
>  (weex framework):1:255299
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-448) Iconfont character may randomly display as '?'

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-448.
--
Resolution: Resolved

> Iconfont character may randomly display as '?'
> --
>
> Key: WEEX-448
> URL: https://issues.apache.org/jira/browse/WEEX-448
> Project: Weex
>  Issue Type: Bug
>Reporter: Wang Qianyuan
>Assignee: Adam Feng
>Priority: Major
> Attachments: 图片.png
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-449) Iconfont character may randomly display as '?'

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-449.
--
Resolution: Resolved

> Iconfont character may randomly display as '?'
> --
>
> Key: WEEX-449
> URL: https://issues.apache.org/jira/browse/WEEX-449
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 0.12
>Reporter: Wang Qianyuan
>Assignee: xingZhang
>Priority: Major
> Attachments: 图片.png
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-453) transform/transformOrigin conflict when updateStyles

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-453.
--
Resolution: Resolved

> transform/transformOrigin conflict when updateStyles
> 
>
> Key: WEEX-453
> URL: https://issues.apache.org/jira/browse/WEEX-453
> Project: Weex
>  Issue Type: Bug
>Reporter: Hao Junhua
>Assignee: Adam Feng
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-473) Update HOW-TO-BUILD.md for weexcore

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-473.
--
Resolution: Resolved

> Update HOW-TO-BUILD.md for weexcore
> ---
>
> Key: WEEX-473
> URL: https://issues.apache.org/jira/browse/WEEX-473
> Project: Weex
>  Issue Type: Task
>Reporter: xumin
>Assignee: Adam Feng
>Priority: Major
>
> Update HOW-TO-BUILD.md for weexcore



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (WEEX-499) the element in slider don't trigger it's appear event when slider changed

[Hanks Zhang (JIRA)]

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

Hanks Zhang reassigned WEEX-499:


Assignee: XuYouyang  (was: xingZhang)

> the element in slider don't trigger it's appear event when slider changed
> -
>
> Key: WEEX-499
> URL: https://issues.apache.org/jira/browse/WEEX-499
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Reporter: fh
>Assignee: XuYouyang
>Priority: Major
>
>  
> {code:java}
> 
>  ref="sliderBox"
> :style="{height:normalHeight}"
> auto-play="true"
> interval="3000">
>  :key="index">
>  :style="{width:item.width, height:item.height}"
> :src="defaultImg"
> :placeholder="defaultImg"
> v-demo="item.imgUrl">
> 
> 
> 
> 
> {code}
>  
> the v-demo listen the image's appear event, however in the slider ,which 
> structure looks like the code above， don't rigger it's appear event when 
> slider changed. Until i scroll the the  the appear event is triggered. 
>  
>  
> 我使用 v-demo 这个自定义指令来监听slider内部 image 元素的 appear 事件，在 appear 
> 事件内做一些处理。但是，像上面这样的结构，slider自动轮播时，内部 image 元素的 appear 事件没有被触发。当我滑动外层的 list 
> 时，这儿的 image 元素的 appear 事件才触发。
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (WEEX-504) textarea 设置 :active伪类，placeholder不消失

[Hanks Zhang (JIRA)]

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

Hanks Zhang reassigned WEEX-504:


Assignee: XuYouyang  (was: xingZhang)

> textarea 设置 :active伪类，placeholder不消失
> 
>
> Key: WEEX-504
> URL: https://issues.apache.org/jira/browse/WEEX-504
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 0.12, 0.19
>Reporter: jiangbin
>Assignee: XuYouyang
>Priority: Major
>
> textarea 设置 :active伪类，placeholder不消失，与当前文字叠加显示
> demo参考[http://dotwe.org/vue/c45ae83c092e7ca988ffc6952077d10a]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-495) WXSwizzleInstanceMethod实现重大bug

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-495:
--

Feel free to send a pull request. Our iOS developers will review the 
modification.

 



欢迎直接提 RP, 在 PR 里结合代码讨论问题。

> WXSwizzleInstanceMethod实现重大bug
> --
>
> Key: WEEX-495
> URL: https://issues.apache.org/jira/browse/WEEX-495
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Reporter: liuan
>Assignee: xingZhang
>Priority: Critical
> Attachments: image-2018-07-06-17-06-47-091.png
>
>
> WXSwizzleInstanceMethod方法实现低级失误造成的重大bug，如果不修改，当hook的方法在主类中没实现而在父类有实现时，会导致无线循环，解决方案如下图所示
> !image-2018-07-06-17-06-47-091.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-154) Weex render and other thin but critical issues should be classify to render container by call render of exception callback

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-154.
--
Resolution: Resolved

> Weex render and other thin but critical issues should be classify to render 
> container by call render of exception callback
> --
>
> Key: WEEX-154
> URL: https://issues.apache.org/jira/browse/WEEX-154
> Project: Weex
>  Issue Type: New Feature
>  Components: Android, iOS, JSFM
>Reporter: atomtong
>Assignee: zhengshihan
>Priority: Minor
>  Labels: features
>
> hi guys,
> Rendering or other thin but critical issues in Weex SDK should be classified 
> to render container by call render of exception callback.
> In order to classify Weex SDK those problems,  we are clearing up error code 
> and degrade code for render container。
> in detail, error code classified by js framework initializing, js bundle 
> download, js bundle rendering and another process.
> WXErrorCode and WXRenderErrorCode is the specific class to define those 
> errors.and we can call WXExceptionUtils's commit method to track those errors 
> immediately to some RT userlog analyzing platform. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (WEEX-290) how to use list method resetLoadmore

[Hanks Zhang (JIRA)]

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

Hanks Zhang closed WEEX-290.

Resolution: Won't Fix

> how to use list method resetLoadmore
> 
>
> Key: WEEX-290
> URL: https://issues.apache.org/jira/browse/WEEX-290
> Project: Weex
>  Issue Type: Bug
>  Components: Android, JSFM
>Affects Versions: 0.18
>Reporter: mjsornp
>Assignee: Hanks Zhang
>Priority: Major
>
> How to use method resetLoadmore in list component
> document descript as below, but I still don't known how to use this function:
> [https://weex.apache.org/cn/references/components/list.html#resetloadmore-0-9]
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-397) Support to build js framework files in build_from_source.sh

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-397.
--
Resolution: Resolved

> Support to build js framework files in build_from_source.sh
> ---
>
> Key: WEEX-397
> URL: https://issues.apache.org/jira/browse/WEEX-397
> Project: Weex
>  Issue Type: Improvement
>  Components: JSFM
>    Reporter: Hanks Zhang
>    Assignee: Hanks Zhang
>Priority: Minor
>
> Now, run the "scripts/build_from_source.sh" script will not generate js 
> frameworks correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-438) vue-rx error: exception:Exception: TypeError: undefined is not an object (evaluating 'root.clearTimeout.bind')

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-438.
--
Resolution: Not A Problem

> vue-rx error:  exception:Exception: TypeError: undefined is not an object 
> (evaluating 'root.clearTimeout.bind')
> ---
>
> Key: WEEX-438
> URL: https://issues.apache.org/jira/browse/WEEX-438
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Reporter: itfront
>Assignee: Hanks Zhang
>Priority: Major
>  Labels: clearTimeout.bind, rxjs
>
> 
>  
>  Age：\{{ age$ }}
>  
> 
> 
>  import Vue from 'vue'
>  import VueRx from 'vue-rx'
>  import Rx from 'rxjs/Rx'
> Vue.use(VueRx, Rx)
> module.exports = {
>  subscriptions () {
>  return {
>  age$: Rx.Observable.of(23)
>  .map(data => data),
>  }
>  }
>  }
> 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-327) 在ios的safari上bfcache失效（MessageChannel引起

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-327.
--
Resolution: Delivered

> 在ios的safari上bfcache失效（MessageChannel引起
> --
>
> Key: WEEX-327
> URL: https://issues.apache.org/jira/browse/WEEX-327
> Project: Weex
>  Issue Type: Bug
>  Components: Web Renderer
>Affects Versions: 0.18
> Environment: ios 11.3
> 浏览器：ios上所有浏览器
>Reporter: wj
>Assignee: Danz He
>Priority: Major
>  Labels: weex, weex-vue-render
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> 问题复现：
> 1.打开下面dotWe链接：
> [http://dotwe.org/vue/b9a2bf2c5b5d39d61026f09b28905239]
> 2.点击手机模型下方的“Open it in a new page”得到独立页面的地址
> 3.用ios的safari的打开得到的地址
> 4.在列表页滚动一段距离，然后点击随便一个item跳转到下一页。
> 5.在下一页返回
> 期望表现：
> 应该从bfcache中恢复页面，返回后列表停在原来位置。
> 实际表现：
> 列表回到了顶部，页面js重新执行了。如果监听页面的pageshow事件，会发现event.persisted始终是false。
> 这个bug最早是在vue2.5.16上发现的[点这里|https://github.com/vuejs/vue/issues/8109]
> 因为vue2.4.4以后用到了MessageChannel导致了这个bug，所以在一个标准的vue工程里把vue版本降回2.4.3就没有问题了。
> 但是！在weex的工程里，就算我把vue版本降回2.4.3，还是不行，最终发现是下面这一行的问题
> [weex-vue-render/src/weex/index.js|https://github.com/weexteam/weex-vue-render/blob/5a8218089deebed99b6e1808e5a7a058a18b2373/src/weex/index.js#L28]
> Line 28 in 
> [5a82180|https://github.com/weexteam/weex-vue-render/commit/5a8218089deebed99b6e1808e5a7a058a18b2373]
> | |import 'core-js/modules/es6.promise'|
> core-js这个库也用到了MessageChannel
> （飞猪的线上产品也是有这个问题的：[https://m.fliggy.com/?_projVer=0.1.128）|https://m.fliggy.com/?_projVer=0.1.128%EF%BC%89]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (WEEX-104) How to handle component Route in weex?

[Hanks Zhang (JIRA)]

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

Hanks Zhang closed WEEX-104.

Resolution: Not A Problem

> How to handle component Route in weex?
> --
>
> Key: WEEX-104
> URL: https://issues.apache.org/jira/browse/WEEX-104
> Project: Weex
>  Issue Type: Bug
>  Components: Web Renderer
>Reporter: Edward Zhang
>Assignee: Danz He
>Priority: Major
> Attachments: 1.png, 2.png
>
>
> *When I build weex app. I found every vue file will be generated a js file. 
> And when I serve project. All of js files added to my html file. Why it is 
> load all the files in it? How could I route my weex app? every js file 
> content is below:*
> var App = require('..\src\xxx.vue')   // different vue file.
> App.el = '#root'
> new Vue(App)
> *I think it is not good way to route entire app. Does anyone could support me 
> snippet code?*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-104) How to handle component Route in weex?

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-104:
--

Using vue-router to write SPA (single-page-application), or using navigator 
module to achieve MPA (multiple-page-application).

 

http://weex-project.io/guide/advanced/use-vuex-and-vue-router.html

> How to handle component Route in weex?
> --
>
> Key: WEEX-104
> URL: https://issues.apache.org/jira/browse/WEEX-104
> Project: Weex
>  Issue Type: Bug
>  Components: Web Renderer
>Reporter: Edward Zhang
>Assignee: Danz He
>Priority: Major
> Attachments: 1.png, 2.png
>
>
> *When I build weex app. I found every vue file will be generated a js file. 
> And when I serve project. All of js files added to my html file. Why it is 
> load all the files in it? How could I route my weex app? every js file 
> content is below:*
> var App = require('..\src\xxx.vue')   // different vue file.
> App.el = '#root'
> new Vue(App)
> *I think it is not good way to route entire app. Does anyone could support me 
> snippet code?*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-330) component not updating title on web renderer

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-330.
--
Resolution: Won't Fix

>  component not updating title on web renderer
> --
>
> Key: WEEX-330
> URL: https://issues.apache.org/jira/browse/WEEX-330
> Project: Weex
>  Issue Type: Bug
>  Components: Web Renderer
>Affects Versions: 0.12
> Environment: Firefox 59, Ubuntu 17.10 x64, Both dotwe.org and the 
> weex command line tool v1.3.4 (latest release in npm). It seems to carry out 
> through several versions.
>Reporter: Gonzalo Ruiz
>Assignee: Danz He
>Priority: Major
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Cannot read a "web" component's  on the web renderer. It works on 
> Android but the value is simply "" on the web renderer.
> I'm using the title tag to pass an auth token from a webview to the app's JS 
> code to execute a login, but my code only works on a real device, making 
> development troublesome.
>  
> Link to reproduce the issue:
> [http://dotwe.org/vue/0e21b48adcc302ca8c90449e083acf62]
>  
> This is a resource to aid with fixing the issue: a jsFiddle demo that 
> successfully retrieves the title from an iframe object:
> [https://jsfiddle.net/wLvdexkq/]
> The only code that needs to be executed is the following:
> document.getElementById("main-content-iframe").contentDocument.title
> But mind that this needs to be executed when the iframe loads.
>  
> Thanks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Contributing to English docs

[Hanks Zhang]

That's really great!

I think there are still many developers is stumbling upon Weex like you
guys did. Most of Weex developers are Chinese people, it would be great to
have native speakers reviewing the English documents. I have noticed the
pull request about the tutorial, a good beginning! Looking forward to
furthering cooperation.

Feel free to ask any question confused you in the mailing list (or
personally).

Best Regards,
Hanks

Paul Adams  于2018年7月5日周四 上午3:47写道：

> My pleasure! I am currently working on the Getting Started page, and will
> work top-down through:
> https://gist.github.com/Hanks10100/8afb66772d00f5d1446b27320af1c8ff
>
> On Wed, Jul 4, 2018 at 2:40 PM, Tiago Alves  wrote:
>
> > Hi Paul!
> >
> > Nice to have a native speaker working on the much needed docs. I
> > contributed a bit in the creating plugins section, and will update that
> > soon since some stuff changed.
> >
> > Thanks!
> > Tiago
> > On 4 Jul 2018 20:34 +0100, Paul Adams , wrote:
> > > Hi everyone!
> > >
> > > My name is Paul Adams and I am a software developer based in the United
> > > States. I work with Vue.js as part of my job, but I use it extensively
> in
> > > side projects outside of my work role. I have stumbled upon Weex and
> > > reached out to Hanks regarding contributing to the English docs repo. I
> > > just wanted to introduce myself to everyone and say hi.
> > >
> > > Regards,
> > >
> > > Paul Adams
> >
>

Re: Podling Report Reminder - July 2018

[Hanks Zhang]

Hi Willem and Weex PMCCs,

I summarised the podling report about Weex as follow, but I don't know how
to edit that report (maybe don't have the permission). I wish someone can
help me to post this report.



Weex

Weex is a framework for building high-performance mobile applications with
modern web development experience.

Weex has been incubating since 2016-11-30.

Three most important issues to address in the move towards graduation:

  1. Develop more non-Chinese contributors and committers, to bring
diversity to
the community.
  2. Improve the developer's activity in the mailing list.
  3. Create regularly release schedule.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

  None.

How has the community developed since the last report?

  * Forward to the second release, it's under RC2 now.
  * Set up a regular monthly meeting between Alibaba, Tencent, and PayTM
developers.
  * 493(213 new issues since the last report) issues have been reported on
JIRA,
and 321(79 since the last report) of them are resolved or closed.
  * Our Github repo has growth in contributors 154(9 new since the last
report), forks 1321(153 new), watchers 497(46 new) and stars 9985(1255
new)

How has the project developed since the last report?

  * Excluding merges, 20 authors have pushed 77 commits to master and 93
commits to all branches. (June 4, 2018 – July 4, 2018)
  * Refactor the thread model of JavascriptCore and integrate WeexCore call
to iOS.

How would you assess the podling's maturity?
Please feel free to add your own commentary.

  [ ] Initial setup
  [ ] Working towards first release
  [x] Community building
  [ ] Nearing graduation
  [ ] Other:

Date of last release:

  2017-06-08

When were the last committers or PPMC members elected?

  None.

--

Best Regards,
Hanks


Willem Jiang  于2018年7月4日周三 下午8:18写道：

> Hi,
>
> The Podling report is due by end of today.
> Please send your report ASAP.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jun 28, 2018 at 5:41 AM,  wrote:
>
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 18 July 2018, 10:30 am PDT.
> > The report for your podling will form a part of the Incubator PMC
> > report. The Incubator PMC requires your report to be submitted 2 weeks
> > before the board meeting, to allow sufficient time for review and
> > submission (Wed, July 04).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Candidate names should not be made public before people are actually
> > elected, so please do not include the names of potential committers or
> > PPMC members in your report.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> > *   How does the podling rate their own maturity.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > https://wiki.apache.org/incubator/July2018
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >
>

Re: 为什么使用wx单位H5显示不正常

[Hanks Zhang]

wx 单位并不标准，可能存在兼容性问题，浏览器并不支持，需要提前编译。weex-vue-precompiler  (
https://github.com/weexteam/weex-vue-precompiler) 会执行部分编译功能。

如果发现 bug，希望能提供详细信息和能复现的例子。参考
http://weex-project.io/cn/bug-report-guidelines.html


ZhaoYiding  于2018年7月4日周三 下午12:56写道：

> 为什么使用wx单位H5显示不正常

Re: Suggestion on moving Weex Code Repo to Gitbox

[Hanks Zhang]

Sounds good if PMCs have the permission to manage issues and PRs on GitHub
directly, but I wonder if there are any side effects of the migration.
What's the process and what will be happened about the "git-wip-us" repo?

Adam Feng  于2018年6月28日周四 下午7:49写道：

> +1
>
> It will be convenient for us if we can use Github issues and pull requests.
>
>
> Thanks.
> Adam Feng
> 在 2018年6月28日 +0800 PM6:14，申远 ，写道：
> > Hi, Folks
> >
> > Apache Infa now provided us read/write access directly to weex repos on
> > Github through a utility called Gitbox( https://gitbox.apache.org/).
> PMCs
> > have the option to embrace the Gitbox and using Github UI to review code,
> > merge PRs.
> >
> > For now, there are plenty of Apache projects hosted by GItbox(
> > https://gitbox.apache.org/repos/asf). Personally, I am fascinated by the
> > idea of directly access to Github, which will make committers life far
> more
> > easy.
> >
> > I'd like to suggest that we host Apache Weex (
> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git) on Gitbox
> to
> > enable read/write access of Repos on Github.
> > --
> >
> >
> > Best regards,
> >
> > York Shen
>

[jira] [Commented] (WEEX-470) module lost after switch from on Activity to previous Activity

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-470:
--

The "weex" variables are different in each page. [1] If you register a "$xx" 
method using the "weex" variable in page B, when you back to page A, the B's 
"weex" is destroyed. It's reasonable to get an error when you calling "$xx" 
method in page A which relies on page B's weex variable.

It's important to isolate running context of each page in Weex. Do NOT use 
global variables or global methods. You can use global mixins [2] or js service 
[3].

 

[1] [http://weex-project.io/cn/references/weex-variable.html]

[2] 
[https://cn.vuejs.org/v2/guide/mixins.html#%E5%85%A8%E5%B1%80%E6%B7%B7%E5%85%A5]

[3] http://weex-project.io/cn/references/js-service.html

 

每个页面里的 "weex" 变量是不一样的而且彼此独立，如果你在 B 页面注册(覆盖)全局变量 $xx，内部实现依赖的是 B 页面里的 "weex" 
变量，退出回到 A 之后，B 的 "weex" 就废了，这时候调用 $xx 报错是正常的，因为它依赖了 B 页面的变量。

在 Weex 里比较强调环境隔离，不要注册全局变量。可以给每个页面都注册个全局的 mixin，或者用 js service。

 

 

> module lost after switch from on Activity to previous Activity
> --
>
> Key: WEEX-470
> URL: https://issues.apache.org/jira/browse/WEEX-470
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.19
>Reporter: 华逢义
>Assignee: codefurture
>Priority: Blocker
>
> Activity A started Activity B.
> B finished and back to A
> After this operation.weex.requireModule(xxx) does not work in Activity A
> the error is as follow:
> {color:#FF}D/jsLog: [JS Framework] Failed to requireModule("stream"), 
> instance (4) doesn't exist anymore.__ERROR{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE]: Release Apache Weex (Incubating) 0.19.0 [RC2]

[Hanks Zhang]

+1. This release looks good for me. Thanks for all your works.

Dan  于2018年6月26日周二 下午9:33写道：

> +1, the shells command work fine! cheers~
>
> Adam Feng  于2018年6月26日周二 下午9:15写道：
>
> > Hi Weex Community,
> > I'm calling this vote to release Apache Weex (Incubating) version 0.19.0.
> > The tag to be voted upon:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=shortlog;h=refs/tags/0.19.0-rc2
> > Hash for the release tag:
> > 85784303472a5187863abf3476d2db38cce67fa4
> > The source tarball can be found at:
> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC2/
> > The artifacts have been signed with Key : 4FD8BC09C7E9DB81, which can be
> > found in the keys file:
> > https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
> > Release note about this version:
> > https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464
> > This vote will remain open for at least 72 hours.
> > Please vote on releasing this RC.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Thanks.Adam Feng
> >
>

[jira] [Commented] (WEEX-438) vue-rx error: exception:Exception: TypeError: undefined is not an object (evaluating 'root.clearTimeout.bind')

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-438:
--

"TypeError: undefined is not an object" is really a common error in javascript. 
It's mainly caused by trying to read a property from undefined variable.

 

In this case, the "root" or "root.clearTimeout" may be undefined, add a type 
check before using them can avoid is error.

> vue-rx error:  exception:Exception: TypeError: undefined is not an object 
> (evaluating 'root.clearTimeout.bind')
> ---
>
> Key: WEEX-438
> URL: https://issues.apache.org/jira/browse/WEEX-438
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Reporter: itfront
>Assignee: Hanks Zhang
>Priority: Major
>  Labels: clearTimeout.bind, rxjs
>
> 
>  
>  Age：\{{ age$ }}
>  
> 
> 
>  import Vue from 'vue'
>  import VueRx from 'vue-rx'
>  import Rx from 'rxjs/Rx'
> Vue.use(VueRx, Rx)
> module.exports = {
>  subscriptions () {
>  return {
>  age$: Rx.Observable.of(23)
>  .map(data => data),
>  }
>  }
>  }
> 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-470) module lost after switch from on Activity to previous Activity

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-470:
--

In our playground app ([http://weex-project.io/cn/tools/playground.html)] , 
there are so many cases as you described. When you opened B, the activity A 
should not be destroyed.

 

Maybe you could offer a demo to reproduce it.

> module lost after switch from on Activity to previous Activity
> --
>
> Key: WEEX-470
> URL: https://issues.apache.org/jira/browse/WEEX-470
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.19
>Reporter: 华逢义
>Assignee: codefurture
>Priority: Blocker
>
> Activity A started Activity B.
> B finished and back to A
> After this operation.weex.requireModule(xxx) does not work in Activity A
> the error is as follow:
> {color:#FF}D/jsLog: [JS Framework] Failed to requireModule("stream"), 
> instance (4) doesn't exist anymore.__ERROR{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE]: Release Apache Weex (Incubating) 0.19.0 [RC0]

[Hanks Zhang]

-1. The dependent version of Node.js in the HOW-TO-BUILD.md [1] is not
correct.

To build js framework correctly, the version of Node.js should be higher
than v7.6.0, the HOW-TO-BUILD.md should be updated before release.

I have already opened a pull request to do it:
https://github.com/apache/incubator-weex/pull/1279

[1]
https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=blob;f=HOW-TO-BUILD.md;h=416c2bcdd40756a7eef16644f4904013a358ced5;hb=refs/tags/0.19.0-rc0#l15

shihan zheng  于2018年6月20日周三 下午4:18写道：

> build failed,  require  high version node
>
> Adam Feng  于2018年6月20日周三 上午10:26写道：
>
>> Hi Weex Community,
>> I'm calling this vote to release Apache Weex (Incubating) version 0.19.0.
>> The tag to be voted upon:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=shortlog;h=refs/tags/0.19.0-rc0
>>
>> Hash for the release tag:
>> 9ea6ac79ecf7cd855e1afe114a1897fe06621e81
>>
>> The source tarball can be found at:
>> https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC0/
>>
>> The artifacts have been signed with Key : 4FD8BC09C7E9DB81, which can be
>> found in the keys file:
>> https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS
>> Release note about this version:
>> https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464
>> This vote will remain open for at least 72 hours.
>> Please vote on releasing this RC.
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Thanks.
>> Adam Feng
>>
>
>
> --
>
> Best Regards!
> -
> Shihan Zheng (Weex project team member )
>
>

[jira] [Resolved] (WEEX-455) Migrate the example website to incubator-weex-site

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-455.
--
   Resolution: Resolved
Fix Version/s: 0.19

> Migrate the example website to incubator-weex-site
> --
>
> Key: WEEX-455
> URL: https://issues.apache.org/jira/browse/WEEX-455
> Project: Weex
>  Issue Type: Task
>  Components: Project 
>    Reporter: Hanks Zhang
>    Assignee: Hanks Zhang
>Priority: Minor
> Fix For: 0.19
>
>
> The current examples repo is in  
> [https://hanks10100.github.io/weex-vue-examples/] , not an official website 
> of Weex. It needs to be refactored and migrated to the incubator-weex-site 
> repo and publish to weex.apache.org.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WEEX-461) Stop tracking dsl types in js framework

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-461:


 Summary: Stop tracking dsl types in js framework
 Key: WEEX-461
 URL: https://issues.apache.org/jira/browse/WEEX-461
 Project: Weex
  Issue Type: Bug
  Components: JSFM
Reporter: Hanks Zhang
Assignee: Hanks Zhang


Stop tracking the DSL type in the debugger of js framework.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WEEX-455) Migrate the example website to incubator-weex-site

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-455:


 Summary: Migrate the example website to incubator-weex-site
 Key: WEEX-455
 URL: https://issues.apache.org/jira/browse/WEEX-455
 Project: Weex
  Issue Type: Task
  Components: Project 
Reporter: Hanks Zhang
Assignee: Hanks Zhang


The current examples repo is in  
[https://hanks10100.github.io/weex-vue-examples/] , not an official website of 
Weex. It needs to be refactored and migrated to the incubator-weex-site repo 
and publish to weex.apache.org.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Weex Monthly Meeting between Paytm and Alibaba

[Hanks Zhang]

Here are some actions after the monthly meeting.

## The Second Apache Release of Weex

The license and notice files are fine, Adam will start a new vote on
releasing the v0.19 of Weex SDK.

## Documents

The document list of Weex:
https://gist.github.com/Hanks10100/8afb66772d00f5d1446b27320af1c8ff

For the first step, we should focus on the following articles.

+ Getting Started: http://weex-project.io/guide/index.html
+ Front-End Frameworks:
http://weex-project.io/guide/front-end-frameworks.html
+ Use Vue.js on Weex: http://weex-project.io/guide/use-vue.html
+ Weex Variable: http://weex-project.io/references/weex-variable.html
+ Use Vuex and vue-router:
http://weex-project.io/guide/advanced/use-vuex-and-vue-router.html
+ Integrate to Your App:
http://weex-project.io/guide/integrate-to-your-app.html
+ Setup Develop Environment: http://weex-project.io/guide/set-up-env.html

## Examples

The current examples repo need to be refactored and migrated to
incubator-weex and incubator-weex-site repo separately. Hanks will do it
before the next monthly meeting.



2018-06-08 18:17 GMT+08:00 Hanks Zhang :

> We plan to hold a monthly meeting between Paytm and Alibaba developers at
> 11th, June New Delhi time 2:00 pm (Beijing time 4:30 pm).
>
> Here are the topics:
>
> + How to Participate in Weex
> + Apache Release Progress
> + Document Review List
> + Weex Examples List
> + Encountered Problems in Practice
>

Weex Monthly Meeting between Paytm and Alibaba

[Hanks Zhang]

We plan to hold a monthly meeting between Paytm and Alibaba developers at
11th, June New Delhi time 2:00 pm (Beijing time 4:30 pm).

Here are the topics:

+ How to Participate in Weex
+ Apache Release Progress
+ Document Review List
+ Weex Examples List
+ Encountered Problems in Practice

[jira] [Commented] (WEEX-401) about param jsonInitData

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-401:
--

As far as I can see, that "jsonInitData" will be passed to the corresponding 
pages. In Vue.js syntax, you can get that data in the root component, it will 
be extended to the "this" of the root component.

 

For example, if you passed a data like this:

{

  name: 'string',

  object: { array:  [1, 2, 3] }

}

 

You can access those data in the root component:

 

export default {

  mounted () {

    console.log(this.name) // string

    this.object.array.push(4)

  }

}

 

 

> about param jsonInitData
> 
>
> Key: WEEX-401
> URL: https://issues.apache.org/jira/browse/WEEX-401
> Project: Weex
>  Issue Type: Improvement
>Reporter: shanyong
>Assignee: Adam Feng
>Priority: Major
>
> when native renderpage we have put a param named  "jsoninitdata"
> mInstance.renderByUrl(
>  getPageName(),
>  url,
>  options,
>  jsonInitData,
>  WXRenderStrategy.APPEND_ASYNC);
>  
> how to get this param in weex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (WEEX-337) weex.supports return null when component name contains character '-'

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-337.
--
Resolution: Fixed

> weex.supports return null when component name contains character '-'
> 
>
> Key: WEEX-337
> URL: https://issues.apache.org/jira/browse/WEEX-337
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Affects Versions: 0.18
>Reporter: seewhy
>Assignee: Hanks Zhang
>Priority: Major
>
> weex.supports return null when component name contains character '-'
> for example:
> {code:java}
> weex.supports('@component/recycle-list')
> {code}
> should return true, but it returns null now.
> test case: 
> http://dotwe.org/vue/26b73776ae3e34c4335491ce40e89e57



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WEEX-397) Support to build js framework files in build_from_source.sh

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-397:


 Summary: Support to build js framework files in 
build_from_source.sh
 Key: WEEX-397
 URL: https://issues.apache.org/jira/browse/WEEX-397
 Project: Weex
  Issue Type: Improvement
  Components: JSFM
Reporter: Hanks Zhang
Assignee: Hanks Zhang


Now, run the "scripts/build_from_source.sh" script will not generate js 
frameworks correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-116) It seems vue doesn't support instance property in weex.

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-116:
--

Extend Vue prototype in the lifecycle may not be a good idea, the modification 
may take effect delay.

Even it's not a good practice, this feature works for me.

Moreover, I think it's better to use "Vue.extend()" to extend APIs on Vue 
prototype, write a plugin to do that could be better.

> It seems vue doesn't support instance property in weex.
> ---
>
> Key: WEEX-116
> URL: https://issues.apache.org/jira/browse/WEEX-116
> Project: Weex
>  Issue Type: Bug
>Reporter: Edward Zhang
>Assignee: Hanks Zhang
>Priority: Critical
> Attachments: error.png
>
>
> I want to transplant Onsen UI to weex environment. official site is below:
> https://onsen.io/
> BUT, I met some errors while i running code. It is ok to webpack my app. BUT 
> when I serve it in browser, i suppose vue do not support instance property. 
> some snippets below:
> in main.js
> {code:javascript}
> new Vue({
>   el: '#root',
>   render: h => h(AppNavigator),
>   store: new Vuex.Store(storeLike),
>   beforeCreate: function() {
> // Shortcut for Material Design
> Vue.prototype.$md = this.$ons.platform.isAndroid();  //look this line:  
> Vue.prototype.$md can not assign value to it.
>   }
> });
> {code}
> in AppSplitter.vue
> {code:html}
> 
>   
> 
>width="260px"
> :swipe-target-width="$md && 25"  
> //$md is undefined here.
> :animation="$md ? 'overlay' : 'reveal'"   
> //$md is undefined here.
> :open.sync="isOpen"
>   >
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> Error information is right below in the attachment. Does anyone tell me why? 
> And anyone who would like to help me. You can clone my github project: 
> https://github.com/Edward-Roshan/Weex-Onsen
> Does Anyone just help me to launch it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-17.
-
Resolution: Done

> 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
(v7.6.3#76005)

[jira] [Closed] (WEEX-310) recycle-list无法访问外层属性

[Hanks Zhang (JIRA)]

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

Hanks Zhang closed WEEX-310.

Resolution: Not A Problem

> recycle-list无法访问外层属性
> 
>
> Key: WEEX-310
> URL: https://issues.apache.org/jira/browse/WEEX-310
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.18
>Reporter: mhl
>Assignee: Hanks Zhang
>Priority: Blocker
>  Labels: recycle-list
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
>  
> {code:java}
> 
>loadmoreoffset="10">
> 
>
>  {{curIndex}}
>  
>  
>  
>  {{img.title}}
>  
>  
>   
>
>   
> 
> 
> export default {
>name: 'find',
>data() {
>   return {
> curIndex: 0,
> imageList: [
>   {title: 'item A', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item B', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item C', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'}
>],
>list: [1,2,3]
> }
>}
> }
> {code}
> 在recycle-list里面无法访问外层属性，比如无法访问：curIndex / imageList 。  recycle-list只能访问list。 
> 这应该是bug , 换成list组件是可以正常访问的。
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-310) recycle-list无法访问外层属性

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-310:
--

因为 recycle-list 
比较强调数据驱动的方式，列表数据由同一个入口（变量）传递进来也比较符合最佳实践。要实现“外层”传值的话，会比较损伤性能，也不太符合最初的设计理念，目前不考虑实现这个功能，后续会再认真评估一下。

> recycle-list无法访问外层属性
> 
>
> Key: WEEX-310
> URL: https://issues.apache.org/jira/browse/WEEX-310
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.18
>Reporter: mhl
>Assignee: Hanks Zhang
>Priority: Blocker
>  Labels: recycle-list
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
>  
> {code:java}
> 
>loadmoreoffset="10">
> 
>
>  {{curIndex}}
>  
>  
>  
>  {{img.title}}
>  
>  
>   
>
>   
> 
> 
> export default {
>name: 'find',
>data() {
>   return {
> curIndex: 0,
> imageList: [
>   {title: 'item A', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item B', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item C', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'}
>],
>list: [1,2,3]
> }
>}
> }
> {code}
> 在recycle-list里面无法访问外层属性，比如无法访问：curIndex / imageList 。  recycle-list只能访问list。 
> 这应该是bug , 换成list组件是可以正常访问的。
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-310) recycle-list无法访问外层属性

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-310:
--

You can't use the "outer" data which are not defined in the list data. That 
means you can only use the data of the `list` property within the  
for your case. It's a limitation of recycle-list, I'll add a notice in the 
document. The best solution for this case is putting all data is the `list`, 
it's also a good practice.

 

recycle-list 只能用写在 for 里的数据，“外层”属性不能用，这算是个底层功能的限制。建议把数据都放 list 里。

> recycle-list无法访问外层属性
> 
>
> Key: WEEX-310
> URL: https://issues.apache.org/jira/browse/WEEX-310
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 0.18
>Reporter: mhl
>Assignee: Adam Feng
>Priority: Blocker
>  Labels: recycle-list
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
>  
> {code:java}
> 
>loadmoreoffset="10">
> 
>
>  {{curIndex}}
>  
>  
>  
>  {{img.title}}
>  
>  
>   
>
>   
> 
> 
> export default {
>name: 'find',
>data() {
>   return {
> curIndex: 0,
> imageList: [
>   {title: 'item A', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item B', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'},
>   {title: 'item C', src: 
> '<a  rel="nofollow" href="http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg">http://img1.gtimg.com/ent/pics/hv1/122/43/2273/147812912.jpg</a>'}
>],
>list: [1,2,3]
> }
>}
> }
> {code}
> 在recycle-list里面无法访问外层属性，比如无法访问：curIndex / imageList 。  recycle-list只能访问list。 
> 这应该是bug , 换成list组件是可以正常访问的。
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: How to set z-index in App ?

[Hanks Zhang]

+1. I also think this feature should be considered seriously, the feature
request has been proposed for a long time.

It needs the new layout engine to support it.

Best Regards,
Hanks

2018-03-06 0:00 GMT+08:00 莫克陶 :

> z-index is important when making cool effect .
>
> This feature needs to be supported.
>
> https://segmentfault.com/q/101013513793?_ea=3401065
>
> http://dotwe.org/vue/e2ea54e6141a5b669efa5c5a75e9ab92
>

Re: Regarding plans to take weex global

[Hanks Zhang]

Awesome! Looking forward to your sharing! I also realized that Weex did not
do well in the community, especially in the English world. It would be very
helpful for worldwide developers to getting started with weex.

I am also planning to write some articles to introduce Weex to the
beginners. We really should share the development progress of Weex more
frequently.

Best Regards,
Hanks

2018-02-28 15:51 GMT+08:00 Varun Sobti :

> Hello Everyone,
>
> I'm Varun Sobti, working as frontend lead with Paytm India.
>
> I’ve been exploring a lot about presence of weex and native script as these
> are the only 2 options available for vuejs. I figured out some problems
> that other engineers face, which stops them for using weex for production
> apps.
>
> I want to help expand it's reach globally and below points can be
> considered as the plan of action:
>
> 1. Fix documentation. Make it more acceptable.
> 2. Ease of initiating a new app.
> 3. Creating a strong community where some of us are readily available to
> help and unblock others in case of any issue.
> 4. Creating videos for basic training and How-n-Why.
>
> Please feel free to suggest any changes.
>
> There may be a lot of thing that are already in progress. Please do share
> details so that we all can be on the same page.
>
> I look forward to connecting with you all. Let’s go big with weex and make
> sure it reaches and appeals as many engineers as possible.
>
>
> Thanks,
> Varun
>

[jira] [Assigned] (WEEX-229) weex web weex-vue-render1.0.x text components value attribute not effective

[Hanks Zhang (JIRA)]

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

Hanks Zhang reassigned WEEX-229:


Assignee: Danz He  (was: Adam Feng)

> weex web weex-vue-render1.0.x text components value attribute not effective 
> 
>
> Key: WEEX-229
> URL: https://issues.apache.org/jira/browse/WEEX-229
> Project: Weex
>  Issue Type: Bug
>Reporter: fengwuxp
>Assignee: Danz He
>Priority: Major
>
> example
>  code :
>  ``
>  result:
> ` `
> use cdn js
>  
>  src="//h5.m.taobao.com/js/trip/weex-ui/weex-vue-render-next.min.js">
> devDependencies list:
> {{"vue": "^2.5.3", }}
> {{"vue-loader": "^12.2.2",}}
> {{ "vue-router": "^3.0.1", }}
> {{"vue-template-compiler": "^2.5.3", }}
> {{"webpack": "^3.8.1", }}
> {{"webpack-cli": "^2.0.9", }}
> {{"webpack-dev-server": "^3.0.0",}}
> {{ "weex-loader": "~0.5.3", }}
> {{"weex-ui": "^0.4.0", }}
> {{"weex-vue-framework": "^2.5.13-weex.5",}}
> {{ "weex-vue-loader": "~0.4.2",}}
> {{ "weex-vue-precompiler": "^0.1.17", }}
> {{"weex-vue-render": "^1.0.17",}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WEEX-208) 两个结构类似的数据合并前，产生数据污染

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-208:
--

你好，建议用英语提 issue。

这可能是 console.log 计算 var1 值时的延迟，因为里边的属性都是 getter，console 输出后你把它展开了才计算里边的值，打印的都是 
var1 的引用，内容也是一样的。试试用 console.log(JSON.stringify(var1)) 打印出来的结果对不对。

 

Maybe it's a delay when console.log calculating the value of `var1`. You can 
try `console.log(JSON.stringify(var1))` to print the value.

> 两个结构类似的数据合并前，产生数据污染
> ---
>
> Key: WEEX-208
> URL: https://issues.apache.org/jira/browse/WEEX-208
> Project: Weex
>  Issue Type: Bug
>  Components: Web Renderer
>Affects Versions: 0.12
>Reporter: 华逢义
>Assignee: Danz He
>Priority: Major
> Attachments: Catch(02-07-15-24-02).jpg, Catch367C(02-07-15-24-02).jpg
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> 代码：
>  
>   !Catch(02-07-15-24-02).jpg!
> LOG:
> !Catch367C(02-07-15-24-02).jpg!
>  
>  
>  数据污染了，合并前并没有任何操作，但是没定义var1["2"]的visibility，仍然被初始化为visibility=2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Write an article to introduce Weex to the community

[Hanks Zhang]

For a long time, Weex is low-key in the community, developers don't know
the latest progress about Weex and have many misunderstandings.

I am planning to write an article to introduce Weex and publish it on the
Medium these days. The outline is:

# What is Weex?
# Support Multiple Front-end Frameworks
# Quick Start
# Usage Examples
# Who is using Weex?
# Real World Performance
# Community

If you have any advice or information, please let me know! (just reply the
email)

Best Regards, Hanks

Re: Moving Playground & Examples out of Weex repo

[Hanks Zhang]

The screenshot in the mail may not always visible. Here is the image
address:

https://img.alicdn.com/tfs/TB13Es5m2DH8KJjy1XcXXcpdXXa-1059-1953.png

2018-01-16 15:33 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:

> I developed a new Weex playground app, the landing page looks like this:
>
>
>
> It supports to read documents about Weex and Vue online, preview real
> examples on the phone and view the source code of it. Users can also get
> the basic information of Weex project and be informed with the latest news.
>
> I think it's time to upgrade our playground app now. We should release a
> new version.
>
> 2017-12-06 12:10 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:
>
>>
>> I have created a personal website to put those demos [1]. It doesn't
>> finish yet and could be linked form Weex's official website when it's done.
>>
>> It's a static website at present, developers can add examples through PR.
>> I think we could let developers modify or add examples online if it has a
>> backend.
>>
>> [1] https://hanks10100.github.io/weex-vue-examples/
>>
>>
>> 2017-12-06 10:33 GMT+08:00 方曦(千之) <fangxi...@alibaba-inc.com>:
>>
>>> Also very agree with Hanks.
>>> +1
>>>
>>> > 在 2017年12月6日，10:31，Jonathan Dong <jondong.commun...@outlook.com> 写道：
>>> >
>>> > I love the idea about the online playground demos, things are kept
>>> online should be easy to publish, modify and revoke. And for the demo
>>> application itself, should be kept as simple as it can be, with minimum
>>> features like navigation, debug, QR scan, and maybe a easy access point to
>>> the online playground demo.
>>> >
>>> > I think I can follow this implementation on app side.
>>> >
>>> >> On 6 Dec 2017, at 10:21 AM, 谷宝剑(剑白) <jianbai@alibaba-inc.com>
>>> wrote:
>>> >>
>>> >>
>>> >>   have an online playground demo like hao123 website, collect as
>>> many example as possible. so that developer can get lastest feature and
>>> example
>>> >>
>>> >> --From:Hanks
>>> Zhang <zhanghan...@gmail.com>Time:2017 Dec 5 (Tue) 21:41To:dev <
>>> dev@weex.incubator.apache.org>Subject:Re: Moving Playground & Examples
>>> out of Weex repo
>>> >> Moreover, I think our playground app should be redesigned.
>>> >>
>>> >> Most examples are based on the ".we" framework, which will be removed
>>> soon.
>>> >> Even those examples written in Vue are not the best practice and have
>>> no
>>> >> reference value. The UI of it is also rough and has not been updated
>>> for a
>>> >> long time. We should provide more practical examples and make it easy
>>> to
>>> >> use.
>>> >>
>>> >> Besides the examples, I think this app is also a link between Weex
>>> team and
>>> >> developers. It can be used to expose information and thoughts to
>>> >> developers, and can also be used to collect the feedback. We should
>>> make
>>> >> good use of it.
>>> >>
>>> >> Best Regards, Hanks
>>> >>
>>> >>
>>> >> 2017-10-31 17:49 GMT+08:00 Adam Feng <cxfe...@gmail.com>:
>>> >>
>>> >>> +1
>>> >>>
>>> >>> The playground in Weex repo should be a simple “Weex browser”,  a
>>> Weex
>>> >>> examples viewer that lets you navigate to Weex experiences just like
>>> >>> websites.
>>> >>>
>>> >>> Thanks.
>>> >>> Adam Feng
>>> >>>
>>> >>> On 30 Oct 2017, 10:13 PM +0800, xing zhang <
>>> zhangxing610...@gmail.com>,
>>> >>> wrote:
>>> >>>> We should update the Playground App in App Store both on Android
>>> and iOS
>>> >>>> frequently, so the developers can use it to preview their page
>>> using the
>>> >>>> new feature, and we can fix the emergency bug at the same time.
>>> >>>>
>>> >>>> 2017-10-30 21:59 GMT+08:00 Jonathan Dong <
>>> jondong.commun...@outlook.com
>>> >>>> :
>>> >>>>
>>> >>>>> Hi Weex folks,
>>> >>>>>
>>> >

Support import javascript files dynamically

[Hanks Zhang]

Since Weex support using multi-contexts [1], js code is no longer executed
by js framework, it also breaks the "one js file for one page" limit. In
the other word, it's possible to run multiple js files (synchronously or
asynchronously) in one page.

I think the N-to-N relationship between Weex page and js code is more
flexible than one-to-one, and more complicate too. If Weex supports it,
features like code split, caching, lazy execution could be supported too.
But it also easy to be abused.

Before start thinking out the implementation details, I would like to
discuss whether should Weex support it at first.

[1] https://lists.apache.org/thread.html/87bf83253ed7ee318a8cf98d693bc5
34b3e08b4d28655a1290f2e0c7@%3Cdev.weex.apache.org%3E

Best Regard, Hanks

Manage scoped style sheets in native render engines

[Hanks Zhang]

Currently, style sheets are managed in js framework. The class list and
style sheets will be calculated to "classStyle" and merge to the "style" on
the element. It's tricky and inefficient. Even using the same class name,
the style object will be duplicated for each element.

Moreover, this feature won't work on , because the value of
"classList" couldn't be got in front-end frameworks.

I think it's more reasonable to manage style sheets in native render
engines. To achieve it, the scoped style sheets should be sent to native
before render. And the front-end frameworks no longer need to calculate the
CSS rules referenced in the class list.

Looking forward to furthering discussions.

Best Regards, Hanks

Split js framework into different types for different usage

[Hanks Zhang]

Currently, both vue, rax and the legacy ".we" framework are all packaged
into the js framework, but for one Weex page could only be written in one
specific framework, it doesn't need both of them at once.

I think it's a good idea to split js framework into different pieces.
Distinguish vue and rax, whether compile ES6, and whether use polyfills.
It's more practical for native to manage dependencies and isolate contexts.

Another advantage is it's possible to use smaller js framework packages in
some scenario. Take the v0.22.5 for example, the size of js frameworks
could be:


​

To achieve this, the file structure and build scripts of js framework
should be adjusted.



Best Regards, Hanks

Re: Use multi context for Weex page

[Hanks Zhang]

The implementation in js framework is finished, and I sent a PR [1] to
merge it into the master branch.

The Vue.js framework and native render engines have already achieved it and
all unit tests are passed (poison: [2] validator: [3]). I think it's time
to test it in some real cases, such as the TaoBao app.

[1] https://github.com/apache/incubator-weex/pull/960
[2] http://dotwe.org/vue/665a40b9ccc937025fceda627937f659
[3] http://dotwe.org/vue/5a182754bf404b314d70a4ced455c3e8

2017-12-19 16:47 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:

> For the Vue.js framework, I sent a PR [1] to achieve it. I think Rax
> should do the same thing.
>
> In the PR, I removed legacy framework APIs and use "createInstanceContext"
> instead of "createInstance" to create the Vue module instance for each page.
>
> Native render engines should also call "createInstanceContext" instead of
> "createInstance", and the source code is no longer needed. Another change
> is, the bundle type of the code (Vue or Rax) should be parsed in native and
> send it to js framework.
>
> [1] https://github.com/vuejs/vue/pull/7272
>
> 2017-12-04 16:22 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:
>
>> +1. Currently, multiple js bundles are executed in the same js context,
>> and the isolation is implemented by js, which is not robust.
>>
>> In my opinion, the most reasonable solution is to distinguish the "Global
>> Context" and the "Instance Context", move the logic of instance management
>> and code execution from js to native.
>>
>> On this basis, I think there are some sub-problems that need to be solved:
>>
>> (1). How to expose APIs from Global Context to Instance Context?
>> (2). How to isolate those exposed APIs?
>> (3). Adjustments of Vue and Rax.
>> (4). Impact on performance.
>> (5). What about the platform APIs and the polyfills? Such as console,
>> Object.assign, and timer.
>> (6). Redesign the js service.
>>
>> Feel free to discuss any of these topics, or add one.
>>
>> Best regards, Hanks
>>
>
>

[jira] [Resolved] (WEEX-183) append="tree" doesn't work on the root element

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-183.
--
Resolution: Resolved

> append="tree" doesn't work on the root element
> --
>
> Key: WEEX-183
> URL: https://issues.apache.org/jira/browse/WEEX-183
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>Reporter: Hanks Zhang
>Assignee: Hanks Zhang
>
> For this example: http://dotwe.org/vue/c479b4f8b2e7243efe1cfed2f442e35a
> Even there is an append="tree" on the root element, js framework will send 
> two render directives to native. JS Framework does it on purpose to ensure 
> the performance of sending the first render directive (createBody). I think 
> it should be fixed.



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

[jira] [Resolved] (WEEX-182) JS framework send empty attributes and styles to native

[Hanks Zhang (JIRA)]

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

Hanks Zhang resolved WEEX-182.
--
Resolution: Resolved

> JS framework send empty attributes and styles to native
> ---
>
> Key: WEEX-182
> URL: https://issues.apache.org/jira/browse/WEEX-182
> Project: Weex
>  Issue Type: Bug
>  Components: JSFM
>    Reporter: Hanks Zhang
>    Assignee: Hanks Zhang
>
> After JS Framework support batched update of attributes and styles. 
> (https://github.com/apache/incubator-weex/pull/819) Sometimes it will send 
> empty or the whole attributes and styles to native because there is no diff 
> in it.



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

Re: Separate the weex-vue-render from the incubator-weex repo

[Hanks Zhang]

+1. I also think it's a good idea to remove render and framework folders.
But I will do it step by step.

(1). I have sent a PR (https://github.com/apache/incubator-weex/pull/955)
to remove all legacy .we examples.
(2). The next will be the legacy web-render and vue-render.
(3). And then, all source code of frameworks and its build scripts should
be removed.
(4). At last, adjust the file structure of js frameworks. "html5" is not a
reasonable name, use "runtime" is fine.

Now (1) is working in progress, I think you can start to do (2) now, and
don't forget to remove the useless build scripts.

Best Regards, Hanks


2017-12-22 15:25 GMT+08:00 He Sai <tekk...@gmail.com>:

> Yes.. About that, I think we should have more discussion on not just
> renders but all the js codes in 'html5' folder, because there may be other
> legacy codes we might want to remove or archive.
>
> Firstly, the codes in html5/render/ include three different web renderer.
> They should be removed, but the render/native is just a entry file for
> frameworks. Maybe the native render should be moved to the html5/frameworks
> as well.
>
> Secondly, should we remove it once for all, or should we just archive it
> into the path of html5/render/legacy ? Since the way we dealing with the
> old js-framework is like this.
>
> At last, what we do here is to clear out the DSL layer code, making weex
> more concentrative and foucs on the core SDK and js-runtime, so that our
> main project structure could be much clearer and more lightweight.
>
> I tend to remove all the codes in html5 including frameworks and renders,
> move runtime codes into a 'runtime' path, and import whichever js-framework
> into that runtime codes from npm packages.
>
> The structure might be like this:
>
> ```
> - android
> - ios
> - html5
> - runtime (new) / all the js runtime code here...
> - ...
> ```
>
>
>
>
> 2017-12-22 14:17 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:
>
> > I noticed that the weex-vue-render have already been moved to
> > https://github.com/weexteam/weex-vue-render
> >
> > So, I think the source code of it should be removed from the
> > [apache/incubator-weex] repo. I created an issue to track it:
> > https://issues.apache.org/jira/browse/WEEX-181
> >
> >
> >
> > 2017-12-19 23:42 GMT+08:00 He Sai <tekk...@gmail.com>:
> >
> > > @Jonathan Dong, Great, Thanks ! I'll transfer it into weexteam group
> > soon.
> > >
> > > 2017-12-19 19:04 GMT+08:00 Jonathan Dong <
> jondong.commun...@outlook.com
> > >:
> > >
> > > > That is nice. I can help to create a repo in
> > https://github.com/weexteam
> > > > to host the codes here instead of using a personal github account.
> > > >
> > > > On 19 Dec 2017, 5:52 PM +0800, He Sai <tekk...@gmail.com>, wrote:
> > > > I think it's better to separate it from this repo. It's more like a
> DSL
> > > > layer stuff, a
> > > > javascript framework to run the dot vue file on web platform, not a
> > > feature
> > > > of
> > > > weex SDK it self. Since the rax DSL framework is not included in this
> > > repo,
> > > > it's
> > > > more or less the same.
> > > >
> > > > I have already created a new repo for these codes, with building
> > scripts
> > > > and
> > > > test cases:
> > > >
> > > > https://github.com/MrRaindrop/weex-vue-render
> > > >
> > > > The main project in this repo should be more focusing and cleaner,
> > > > and the render codes in html5 folder could all be removed later.
> > > >
> > > > 2017-12-19 17:31 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:
> > > >
> > > > The "weex-vue-render" is a component and module library for Vue.js.
> It
> > > > enables pages written in Weex + Vue to run on the Web platform. It
> can
> > be
> > > > used to downgrade the weex native pages to web pages.
> > > >
> > > > However, I think this package should separate from the incubator-weex
> > > repo.
> > > >
> > > > Because it doesn't rely on any code of WeexSDK, and WeexSDK doesn't
> > rely
> > > on
> > > > any code of weex-vue-render neither. Even the vue framework itself is
> > > > separated from the incubator-weex repo, weex require it as a
> > dependency,
> > > > not to mention that weex-vue-render is not a part of WeexSDK.
> > > >
> > > > Moreover, weex-vue-render also required many web dependencies which
> > could
> > > > not be used in WeexSDK. I think it's a better to keep the source code
> > of
> > > > incubator-weex more simple and move the weex-vue-render and its
> > > > dependencies to a separate repo.
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 
> > > > Best Wishes！
> > > > _danz
> > > >
> > >
> > >
> > >
> > > --
> > > 
> > > Best Wishes！
> > > _danz
> > >
> >
>
>
>
> --
> 
> Best Wishes！
> _danz
>

[jira] [Created] (WEEX-183) append="tree" doesn't work on the root element

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-183:


 Summary: append="tree" doesn't work on the root element
 Key: WEEX-183
 URL: https://issues.apache.org/jira/browse/WEEX-183
 Project: Weex
  Issue Type: Bug
  Components: JSFM
Reporter: Hanks Zhang
Assignee: Hanks Zhang


For this example: http://dotwe.org/vue/c479b4f8b2e7243efe1cfed2f442e35a

Even there is an append="tree" on the root element, js framework will send two 
render directives to native. JS Framework does it on purpose to ensure the 
performance of sending the first render directive (createBody). I think it 
should be fixed.



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

[jira] [Created] (WEEX-182) JS framework send empty attributes and styles to native

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-182:


 Summary: JS framework send empty attributes and styles to native
 Key: WEEX-182
 URL: https://issues.apache.org/jira/browse/WEEX-182
 Project: Weex
  Issue Type: Bug
  Components: JSFM
Reporter: Hanks Zhang
Assignee: Hanks Zhang


After JS Framework support batched update of attributes and styles. 
(https://github.com/apache/incubator-weex/pull/819) Sometimes it will send 
empty or the whole attributes and styles to native because there is no diff in 
it.



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

Re: Separate the weex-vue-render from the incubator-weex repo

[Hanks Zhang]

I noticed that the weex-vue-render have already been moved to
https://github.com/weexteam/weex-vue-render

So, I think the source code of it should be removed from the
[apache/incubator-weex] repo. I created an issue to track it:
https://issues.apache.org/jira/browse/WEEX-181



2017-12-19 23:42 GMT+08:00 He Sai <tekk...@gmail.com>:

> @Jonathan Dong, Great, Thanks ! I'll transfer it into weexteam group soon.
>
> 2017-12-19 19:04 GMT+08:00 Jonathan Dong <jondong.commun...@outlook.com>:
>
> > That is nice. I can help to create a repo in https://github.com/weexteam
> > to host the codes here instead of using a personal github account.
> >
> > On 19 Dec 2017, 5:52 PM +0800, He Sai <tekk...@gmail.com>, wrote:
> > I think it's better to separate it from this repo. It's more like a DSL
> > layer stuff, a
> > javascript framework to run the dot vue file on web platform, not a
> feature
> > of
> > weex SDK it self. Since the rax DSL framework is not included in this
> repo,
> > it's
> > more or less the same.
> >
> > I have already created a new repo for these codes, with building scripts
> > and
> > test cases:
> >
> > https://github.com/MrRaindrop/weex-vue-render
> >
> > The main project in this repo should be more focusing and cleaner,
> > and the render codes in html5 folder could all be removed later.
> >
> > 2017-12-19 17:31 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:
> >
> > The "weex-vue-render" is a component and module library for Vue.js. It
> > enables pages written in Weex + Vue to run on the Web platform. It can be
> > used to downgrade the weex native pages to web pages.
> >
> > However, I think this package should separate from the incubator-weex
> repo.
> >
> > Because it doesn't rely on any code of WeexSDK, and WeexSDK doesn't rely
> on
> > any code of weex-vue-render neither. Even the vue framework itself is
> > separated from the incubator-weex repo, weex require it as a dependency,
> > not to mention that weex-vue-render is not a part of WeexSDK.
> >
> > Moreover, weex-vue-render also required many web dependencies which could
> > not be used in WeexSDK. I think it's a better to keep the source code of
> > incubator-weex more simple and move the weex-vue-render and its
> > dependencies to a separate repo.
> >
> >
> >
> >
> > --
> > 
> > Best Wishes！
> > _danz
> >
>
>
>
> --
> 
> Best Wishes！
> _danz
>

[jira] [Created] (WEEX-181) Move weex-vue-render out to weexteam

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-181:


 Summary: Move weex-vue-render out to weexteam
 Key: WEEX-181
 URL: https://issues.apache.org/jira/browse/WEEX-181
 Project: Weex
  Issue Type: Improvement
Reporter: Hanks Zhang
Assignee: Danz He


As discussed in 
https://lists.apache.org/thread.html/2c009f1b741a7f1baec07e5a26a9d2c2e8d846abedd85fbb7de32559@%3Cdev.weex.apache.org%3E
 , the weex-vue-render should be separated from the current repo.

The new repo is located in https://github.com/weexteam/weex-vue-render , I 
think the source code of it should be removed from the apache/incubator-weex 
repo.



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

Separate the weex-vue-render from the incubator-weex repo

[Hanks Zhang]

The "weex-vue-render" is a component and module library for Vue.js. It
enables pages written in Weex + Vue to run on the Web platform. It can be
used to downgrade the weex native pages to web pages.

However, I think this package should separate from the incubator-weex repo.

Because it doesn't rely on any code of WeexSDK, and WeexSDK doesn't rely on
any code of weex-vue-render neither. Even the vue framework itself is
separated from the incubator-weex repo, weex require it as a dependency,
not to mention that weex-vue-render is not a part of WeexSDK.

Moreover, weex-vue-render also required many web dependencies which could
not be used in WeexSDK. I think it's a better to keep the source code of
incubator-weex more simple and move the weex-vue-render and its
dependencies to a separate repo.

Re: Use multi context for Weex page

[Hanks Zhang]

For the Vue.js framework, I sent a PR [1] to achieve it. I think Rax should
do the same thing.

In the PR, I removed legacy framework APIs and use "createInstanceContext"
instead of "createInstance" to create the Vue module instance for each page.

Native render engines should also call "createInstanceContext" instead of
"createInstance", and the source code is no longer needed. Another change
is, the bundle type of the code (Vue or Rax) should be parsed in native and
send it to js framework.

[1] https://github.com/vuejs/vue/pull/7272

2017-12-04 16:22 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:

> +1. Currently, multiple js bundles are executed in the same js context,
> and the isolation is implemented by js, which is not robust.
>
> In my opinion, the most reasonable solution is to distinguish the "Global
> Context" and the "Instance Context", move the logic of instance management
> and code execution from js to native.
>
> On this basis, I think there are some sub-problems that need to be solved:
>
> (1). How to expose APIs from Global Context to Instance Context?
> (2). How to isolate those exposed APIs?
> (3). Adjustments of Vue and Rax.
> (4). Impact on performance.
> (5). What about the platform APIs and the polyfills? Such as console,
> Object.assign, and timer.
> (6). Redesign the js service.
>
> Feel free to discuss any of these topics, or add one.
>
> Best regards, Hanks
>

Re: [DISCUSS] The first conference/meetup of Apache Weex, Hangzhou 2018

[Hanks Zhang]

Sorry, the email does not finish yet. Here are the following words:

1. New document and website.
2. Update playground app and online playground.
3. Introduce what's Weex accomplished for the last year.
4. Introduce the strategies and roadmaps.

Best Regards, Hanks

2017-12-13 22:56 GMT+08:00 Hanks Zhang <zhanghan...@gmail.com>:

> Great !
>
> There are many misunderstandings about Weex in the community and this is a
> good opportunity to RE-introduce Weex.
>
> Compared to the discussions on that day, I was more concerned with what
> should we prepare before the conference.
>
> 1. Documents and website.
>
> 2017-12-13 11:02 GMT+08:00 方曦(千之) <fangxi...@alibaba-inc.com>:
>
>> I'm very happy to hear from WeexConf again.
>>
>> At the same time I am also very eager to hear the voice from the industry
>> team, Will WeexConf have invited some non-Alibaba team to do the sharing
>> plan?
>>
>> As a personal developer, I also very much hope to come to feel the
>> atmosphere of communication.
>>
>> Wish all the best.
>>
>>
>> > 在 2017年12月11日，22:16，Adam Feng <cxfe...@gmail.com > cxfe...@gmail.com>> 写道：
>> >
>> > Hi, all:
>> > We are going to organise the third Weex Conf (first of Apache Weex) in
>> Hangzhou in mid-January, 2018.
>> > Potential Content:
>> >
>> > • 1 day conference
>> > • 7-9 x 40 minute presentations
>> > • Talks on: Apache way, contributions, performance, applications, best
>> practices, roadmap, etc.
>> >
>> > Please share your ideas on anything…schedules, venues, speakers,
>> attendees, topics, or any talks you would like to give. We want to hear
>> what kind of conference contributors want. This conference should be one
>> that does its best to gather developers who are specifically interested in
>> Weex and cater to the wants and needs of the attendees.
>> >
>> >
>> > Thanks.
>> > Adam Feng
>>
>>
>

Re: [DISCUSS] The first conference/meetup of Apache Weex, Hangzhou 2018

[Hanks Zhang]

Great !

There are many misunderstandings about Weex in the community and this is a
good opportunity to RE-introduce Weex.

Compared to the discussions on that day, I was more concerned with what
should we prepare before the conference.

1. Documents and website.

2017-12-13 11:02 GMT+08:00 方曦(千之) :

> I'm very happy to hear from WeexConf again.
>
> At the same time I am also very eager to hear the voice from the industry
> team, Will WeexConf have invited some non-Alibaba team to do the sharing
> plan?
>
> As a personal developer, I also very much hope to come to feel the
> atmosphere of communication.
>
> Wish all the best.
>
>
> > 在 2017年12月11日，22:16，Adam Feng > 写道：
> >
> > Hi, all:
> > We are going to organise the third Weex Conf (first of Apache Weex) in
> Hangzhou in mid-January, 2018.
> > Potential Content:
> >
> > • 1 day conference
> > • 7-9 x 40 minute presentations
> > • Talks on: Apache way, contributions, performance, applications, best
> practices, roadmap, etc.
> >
> > Please share your ideas on anything…schedules, venues, speakers,
> attendees, topics, or any talks you would like to give. We want to hear
> what kind of conference contributors want. This conference should be one
> that does its best to gather developers who are specifically interested in
> Weex and cater to the wants and needs of the attendees.
> >
> >
> > Thanks.
> > Adam Feng
>
>

Re: About the framework type annotation

[Hanks Zhang]

I think we could take three steps to get the framework type of a js bundle.

1. Parse the URL params, use a special key to specify the framework type.
This will skip the string parsing and save time.
2. Parse the "use weex:vue" or "use weex:rax" in the code string.
3. Parse the // { "Framework": “Vue/Rax” }, just to be compatible with the
previous syntax.

If there still failed to parse a reasonable framework type after these
steps, then throw an error or use "Vue" as default.

2017-12-11 16:28 GMT+08:00 Adam Feng <cxfe...@gmail.com>:

> Is there any way to avoid string parsing, for example, get framework type
> from returning value while executing the bundle?
>
> Thanks.
> Adam Feng
>
> On 11 Dec 2017, 4:12 PM +0800, Hanks Zhang <zhanghan...@gmail.com>, wrote:
> > The "framework type annotation" is a special syntax written in js bundle
> to
> > indicate which framework it is using, such as Vue and Rax. Refer to its
> > document [1] the annotation looks like:
> >
> > // { "framework": "Vue" }
> >
> > or
> >
> > // { "framework": "Rax" }
> >
> > It's comment with special format actually, however, it is often been
> > removed by the many build tools while minify or uglify. It is fragile and
> > not standard.
> >
> > I think we should use "Directive Prologues" [2] to indicate the framework
> > type of js bundle. This feature is used to declare the *strict model*. It
> > looks like:
> >
> > "use weex:vue";
> >
> > or
> >
> > "use weex:rax";
> >
> > Both ' (single quote) and " (double quotes) are fine. With or without
> > ; (semicolon) is fine.
> >
> > What do you think fellows?
> >
> >
> > [1]
> > http://weex-project.io/references/advanced/extend-
> jsfm.html#JS-Bundle-format-requirements
> > [2] http://ecma-international.org/ecma-262/5.1/#sec-14.1
>

About the framework type annotation

[Hanks Zhang]

The "framework type annotation" is a special syntax written in js bundle to
indicate which framework it is using, such as Vue and Rax. Refer to its
document [1] the annotation looks like:

// { "framework": "Vue" }

or

// { "framework": "Rax" }

It's  comment with special format actually, however, it is often been
removed by the many build tools while minify or uglify. It is fragile and
not standard.

I think we should use "Directive Prologues" [2] to indicate the framework
type of js bundle. This feature is used to declare the *strict model*. It
looks like:

"use weex:vue";

or

"use weex:rax";

Both ' (single quote) and " (double quotes) are fine. With or without
; (semicolon) is fine.

What do you think fellows?


[1]
http://weex-project.io/references/advanced/extend-jsfm.html#JS-Bundle-format-requirements
[2] http://ecma-international.org/ecma-262/5.1/#sec-14.1

Re: Moving Playground & Examples out of Weex repo

[Hanks Zhang]

I have created a personal website to put those demos [1]. It doesn't finish
yet and could be linked form Weex's official website when it's done.

It's a static website at present, developers can add examples through PR. I
think we could let developers modify or add examples online if it has a
backend.

[1] https://hanks10100.github.io/weex-vue-examples/


2017-12-06 10:33 GMT+08:00 方曦(千之) :

> Also very agree with Hanks.
> +1
>
> > 在 2017年12月6日，10:31，Jonathan Dong  写道：
> >
> > I love the idea about the online playground demos, things are kept
> online should be easy to publish, modify and revoke. And for the demo
> application itself, should be kept as simple as it can be, with minimum
> features like navigation, debug, QR scan, and maybe a easy access point to
> the online playground demo.
> >
> > I think I can follow this implementation on app side.
> >
> >> On 6 Dec 2017, at 10:21 AM, 谷宝剑(剑白) 
> wrote:
> >>
> >>
> >>   have an online playground demo like hao123 website, collect as
> many example as possible. so that developer can get lastest feature and
> example
> >>
> >> --From:Hanks
> Zhang Time:2017 Dec 5 (Tue) 21:41To:dev <
> dev@weex.incubator.apache.org>Subject:Re: Moving Playground & Examples
> out of Weex repo
> >> Moreover, I think our playground app should be redesigned.
> >>
> >> Most examples are based on the ".we" framework, which will be removed
> soon.
> >> Even those examples written in Vue are not the best practice and have no
> >> reference value. The UI of it is also rough and has not been updated
> for a
> >> long time. We should provide more practical examples and make it easy to
> >> use.
> >>
> >> Besides the examples, I think this app is also a link between Weex team
> and
> >> developers. It can be used to expose information and thoughts to
> >> developers, and can also be used to collect the feedback. We should make
> >> good use of it.
> >>
> >> Best Regards, Hanks
> >>
> >>
> >> 2017-10-31 17:49 GMT+08:00 Adam Feng :
> >>
> >>> +1
> >>>
> >>> The playground in Weex repo should be a simple “Weex browser”,  a Weex
> >>> examples viewer that lets you navigate to Weex experiences just like
> >>> websites.
> >>>
> >>> Thanks.
> >>> Adam Feng
> >>>
> >>> On 30 Oct 2017, 10:13 PM +0800, xing zhang  >,
> >>> wrote:
>  We should update the Playground App in App Store both on Android and
> iOS
>  frequently, so the developers can use it to preview their page using
> the
>  new feature, and we can fix the emergency bug at the same time.
> 
>  2017-10-30 21:59 GMT+08:00 Jonathan Dong <
> jondong.commun...@outlook.com
>  :
> 
> > Hi Weex folks,
> >
> > I’m thinking of moving Playground and Examples out of Weex repo to
> > simplify our code base, I hope we can fully discuss if it is
> necessary
> >>> to
> > make this move.
> >
> > Playground is a good entry to fiddle with the features of basic
> >>> components
> > and debug your pages, but it is kind of heavy if we take it as a demo
> >>> in
> > the Weex repo. As many of the Weex developers tend to create their
> own
> > applications based on the Playground project, I suppose it is
> >>> necessary to
> > create a simpler one, say AppShell, which only contains QR Scan and
> >>> page
> > load functions, it would be sufficient for users to test their Weex
> >>> pages,
> > and much easier for them to take it as an application template to
> >>> create
> > their own project. Playground should be maintained in a separate repo
> >>> in
> > WeexTeam, which can be maintained and distributed separately.
> >
> > Same things should also happens to examples directory, I suppose what
> >>> we
> > really need is one or few simplified example to demonstrate the usage
> >>> of
> > the main components and the way of implementing app using Weex in the
> > simplest way, not to keep those detailed example for each components
> in
> > Weex repo. Instead I think it is a good practice to move them into
> >>> WeexTeam
> > and maintains as a separate repo, and replace the .we implementation
> >>> with
> > .vue as well.
> >
> > Any thought? I hope we can fully discuss it and bring out a proposal
> to
> > make it happen asap.
> >
> > Cheers,
> > Jonathan Dong
> >
> >
> >>>
> >>
> >
>
>

Re: Moving Playground & Examples out of Weex repo

[Hanks Zhang]

Moreover, I think our playground app should be redesigned.

Most examples are based on the ".we" framework, which will be removed soon.
Even those examples written in Vue are not the best practice and have no
reference value. The UI of it is also rough and has not been updated for a
long time. We should provide more practical examples and make it easy to
use.

Besides the examples, I think this app is also a link between Weex team and
developers. It can be used to expose information and thoughts to
developers, and can also be used to collect the feedback. We should make
good use of it.

Best Regards, Hanks


2017-10-31 17:49 GMT+08:00 Adam Feng :

> +1
>
> The playground in Weex repo should be a simple “Weex browser”,  a Weex
> examples viewer that lets you navigate to Weex experiences just like
> websites.
>
> Thanks.
> Adam Feng
>
> On 30 Oct 2017, 10:13 PM +0800, xing zhang ,
> wrote:
> > We should update the Playground App in App Store both on Android and iOS
> > frequently, so the developers can use it to preview their page using the
> > new feature, and we can fix the emergency bug at the same time.
> >
> > 2017-10-30 21:59 GMT+08:00 Jonathan Dong  >:
> >
> > > Hi Weex folks,
> > >
> > > I’m thinking of moving Playground and Examples out of Weex repo to
> > > simplify our code base, I hope we can fully discuss if it is necessary
> to
> > > make this move.
> > >
> > > Playground is a good entry to fiddle with the features of basic
> components
> > > and debug your pages, but it is kind of heavy if we take it as a demo
> in
> > > the Weex repo. As many of the Weex developers tend to create their own
> > > applications based on the Playground project, I suppose it is
> necessary to
> > > create a simpler one, say AppShell, which only contains QR Scan and
> page
> > > load functions, it would be sufficient for users to test their Weex
> pages,
> > > and much easier for them to take it as an application template to
> create
> > > their own project. Playground should be maintained in a separate repo
> in
> > > WeexTeam, which can be maintained and distributed separately.
> > >
> > > Same things should also happens to examples directory, I suppose what
> we
> > > really need is one or few simplified example to demonstrate the usage
> of
> > > the main components and the way of implementing app using Weex in the
> > > simplest way, not to keep those detailed example for each components in
> > > Weex repo. Instead I think it is a good practice to move them into
> WeexTeam
> > > and maintains as a separate repo, and replace the .we implementation
> with
> > > .vue as well.
> > >
> > > Any thought? I hope we can fully discuss it and bring out a proposal to
> > > make it happen asap.
> > >
> > > Cheers,
> > > Jonathan Dong
> > >
> > >
>

Re: Use multi context for Weex page

[Hanks Zhang]

+1. Currently, multiple js bundles are executed in the same js context, and
the isolation is implemented by js, which is not robust.

In my opinion, the most reasonable solution is to distinguish the "Global
Context" and the "Instance Context", move the logic of instance management
and code execution from js to native.

On this basis, I think there are some sub-problems that need to be solved:

(1). How to expose APIs from Global Context to Instance Context?
(2). How to isolate those exposed APIs?
(3). Adjustments of Vue and Rax.
(4). Impact on performance.
(5). What about the platform APIs and the polyfills? Such as console,
Object.assign, and timer.
(6). Redesign the js service.

Feel free to discuss any of these topics, or add one.

Best regards, Hanks

Use ES6 js framework on Android

[Hanks Zhang]

Weex is using custom js engine (JavascriptCore) on Android. Its version is
new and supports almost all ES6 features, except modules.

I think this is a good opportunity to use ES6 in js framework and remove
useless polyfills. It can improve the js runtime efficiency on Android.

However, we can't upgrade the js engine on iOS. For compatibility reasons,
we have to use the js framework in ES5 on iOS. The packaging process may
need to change too, and how to maintain version consistency is also a
problem.

What do you think fellows?

Best regards, Hanks

[jira] [Assigned] (WEEX-95) border-radius is overlap on Android

[Hanks Zhang (JIRA)]

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

Hanks Zhang reassigned WEEX-95:
---

Assignee: YorkShen  (was: Adam Feng)

> border-radius is overlap on Android
> ---
>
> Key: WEEX-95
> URL: https://issues.apache.org/jira/browse/WEEX-95
> Project: Weex
>  Issue Type: Bug
>        Reporter: Hanks Zhang
>Assignee: YorkShen
>
> Look the example below, it should be a ring with pure blue color. But it 
> rendered many little circles within the border on Android.
> http://dotwe.org/vue/d182d36928fe79b8555324d79ed2feb5



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

[jira] [Commented] (WEEX-114) Android GetComponentRect on some platform not right

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-114:
--

I can offer an example: http://dotwe.org/vue/e9c4b14afdbbd14bf6abe544c7fee65a

> Android GetComponentRect on some platform not right
> ---
>
> Key: WEEX-114
> URL: https://issues.apache.org/jira/browse/WEEX-114
> Project: Weex
>  Issue Type: Bug
>  Components: Android
>Reporter: codefurture
>Assignee: zhengshihan
>
> Android GetComponentRect on some platform not right



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

[jira] [Created] (WEEX-97) font-weight and linear-gradient can't be reset on iOS and web

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-97:
---

 Summary: font-weight and linear-gradient can't be reset on iOS and 
web
 Key: WEEX-97
 URL: https://issues.apache.org/jira/browse/WEEX-97
 Project: Weex
  Issue Type: Bug
  Components: iOS, Web Renderer
Reporter: Hanks Zhang
Assignee: xingZhang


See the example below, click the tex will toggle its styles. But the 
font-weight couldn't be reset on iOS, the linear-gradient couldn't be reset on 
web. Android is fine.

http://dotwe.org/vue/ecf6a20bde4c42ae4e7b6314ebce4438



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

Re: The Legacy Weex DSL 1.0 (.we) Front-End Framework Should be Removed

[Hanks Zhang]

Supported since 29 Aug. https://github.com/vuejs/vue/pull/6223

2017-10-30 11:03 GMT+08:00 申远 <shenyua...@gmail.com>:

> Do we support richtext in .vue context now?
>
> > 在 2017年10月28日，08:52，Jianfeng Li <ismis...@gmail.com> 写道：
> >
> > +1. We should focus on the standard DSL like Vue. This is a good start to
> > let us put burden down and traveling light :)
> >
> > Hanks Zhang <zhanghan...@gmail.com>于2017年10月27日 周五13:25写道：
> >
> >> OK, that's a good idea.
> >>
> >> The issue is created. [WEEX-90]
> >> https://issues.apache.org/jira/browse/WEEX-90
> >>
> >> Regards, Hanks
> >>
> >> 2017-10-27 13:08 GMT+08:00 Jonathan Dong <jondong.commun...@outlook.com
> >:
> >>
> >>> +1. Totally agree. And I think we can also file a JIRA issue to track
> the
> >>> progress.
> >>>
> >>> Cheers,
> >>>
> >>> Jonathan Dong
> >>>
> >>> On 26 Oct 2017, 3:05 PM +0800, Adam Feng <cxfe...@gmail.com>, wrote:
> >>> +1， I suggest removing all the other documents about ".we" except the 2
> >>> documents you mentioned,  let’s speed up the migration.
> >>>
> >>> Thanks.
> >>> Adam Feng
> >>>
> >>> On 26 Oct 2017, 2:04 PM +0800, Hanks Zhang <zhanghan...@gmail.com>,
> >> wrote:
> >>> Weex DSL 1.0 (.we) front-end framework is inspired by Vue.js 1.0. Since
> >>> Weex supports the official Vue.js 2.0 in v0.10.0 [1] at 2017-02-17, the
> >>> ".we" framework is deprecated. In order to optimize the performance,
> >>> stability, and package size, this legacy framework should be removed
> from
> >>> the WeexSDK.
> >>>
> >>> I suggest removing the ".we" framework in the 2018 January release of
> >>> WeexSDK.
> >>>
> >>> For the projects who are still using the ".we" framework, you can read
> >> the
> >>> "Migration From .we Framework" [2] and "The Syntax Difference Between
> .we
> >>> and .vue" [3] documents to help you migrate your ".we" project to
> Vue.js
> >>> 2.0 project. But those documents only have Chinese version.
> >>>
> >>> [1] https://github.com/alibaba/weex/releases/tag/v0.10.0
> >>> [2] http://weex-project.io/cn/references/migration/
> >>> migration-from-weex.html
> >>> [3] http://weex-project.io/cn/references/migration/difference.html
> >>>
> >>> Best Regards, Hanks
> >>>
> >>
>
>

[jira] [Commented] (WEEX-90) Remove The Legacy Weex DSL 1.0 (.we) Front-End Framework

[Hanks Zhang (JIRA)]

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

Hanks Zhang commented on WEEX-90:
-

+1. The .we framework related documents have already removed in the 
"incubator-weex-site", except for the migration documents. After we removed the 
code of .we framework in 2018, we can also remove the migration documents then.

> Remove The Legacy Weex DSL 1.0 (.we) Front-End Framework
> 
>
> Key: WEEX-90
> URL: https://issues.apache.org/jira/browse/WEEX-90
> Project: Weex
>  Issue Type: Bug
>Reporter: Hanks Zhang
>Assignee: Adam Feng
>
> Weex DSL 1.0 (.we) front-end framework is inspired by Vue.js 1.0. Since Weex 
> supports the official Vue.js 2.0 in v0.10.0 [1] at 2017-02-17, the ".we" 
> framework is deprecated. In order to optimize the performance, stability, and 
> package size, this legacy framework should be removed from the WeexSDK.
> I suggest removing the ".we" framework in the 2018 January release of WeexSDK.
> For the projects who are still using the ".we" framework, you can read the 
> "Migration From .we Framework" [2] and "The Syntax Difference Between .we and 
> .vue" [3] documents to help you migrate your ".we" project to Vue.js 2.0 
> project. But those documents only have Chinese version.
> [1] https://github.com/alibaba/weex/releases/tag/v0.10.0
> [2] http://weex-project.io/cn/references/migration/migration-from-weex.html
> [3] http://weex-project.io/cn/references/migration/difference.html



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

Re: The Legacy Weex DSL 1.0 (.we) Front-End Framework Should be Removed

[Hanks Zhang]

OK, that's a good idea.

The issue is created. [WEEX-90]
https://issues.apache.org/jira/browse/WEEX-90

Regards, Hanks

2017-10-27 13:08 GMT+08:00 Jonathan Dong <jondong.commun...@outlook.com>:

> +1. Totally agree. And I think we can also file a JIRA issue to track the
> progress.
>
> Cheers,
>
> Jonathan Dong
>
> On 26 Oct 2017, 3:05 PM +0800, Adam Feng <cxfe...@gmail.com>, wrote:
> +1， I suggest removing all the other documents about ".we" except the 2
> documents you mentioned,  let’s speed up the migration.
>
> Thanks.
> Adam Feng
>
> On 26 Oct 2017, 2:04 PM +0800, Hanks Zhang <zhanghan...@gmail.com>, wrote:
> Weex DSL 1.0 (.we) front-end framework is inspired by Vue.js 1.0. Since
> Weex supports the official Vue.js 2.0 in v0.10.0 [1] at 2017-02-17, the
> ".we" framework is deprecated. In order to optimize the performance,
> stability, and package size, this legacy framework should be removed from
> the WeexSDK.
>
> I suggest removing the ".we" framework in the 2018 January release of
> WeexSDK.
>
> For the projects who are still using the ".we" framework, you can read the
> "Migration From .we Framework" [2] and "The Syntax Difference Between .we
> and .vue" [3] documents to help you migrate your ".we" project to Vue.js
> 2.0 project. But those documents only have Chinese version.
>
> [1] https://github.com/alibaba/weex/releases/tag/v0.10.0
> [2] http://weex-project.io/cn/references/migration/
> migration-from-weex.html
> [3] http://weex-project.io/cn/references/migration/difference.html
>
> Best Regards, Hanks
>

[jira] [Created] (WEEX-90) Remove The Legacy Weex DSL 1.0 (.we) Front-End Framework

[Hanks Zhang (JIRA)]

Hanks Zhang created WEEX-90:
---

 Summary: Remove The Legacy Weex DSL 1.0 (.we) Front-End Framework
 Key: WEEX-90
 URL: https://issues.apache.org/jira/browse/WEEX-90
 Project: Weex
  Issue Type: Bug
Reporter: Hanks Zhang
Assignee: Adam Feng


Weex DSL 1.0 (.we) front-end framework is inspired by Vue.js 1.0. Since Weex 
supports the official Vue.js 2.0 in v0.10.0 [1] at 2017-02-17, the ".we" 
framework is deprecated. In order to optimize the performance, stability, and 
package size, this legacy framework should be removed from the WeexSDK.

I suggest removing the ".we" framework in the 2018 January release of WeexSDK.

For the projects who are still using the ".we" framework, you can read the 
"Migration From .we Framework" [2] and "The Syntax Difference Between .we and 
.vue" [3] documents to help you migrate your ".we" project to Vue.js 2.0 
project. But those documents only have Chinese version.

[1] https://github.com/alibaba/weex/releases/tag/v0.10.0
[2] http://weex-project.io/cn/references/migration/migration-from-weex.html
[3] http://weex-project.io/cn/references/migration/difference.html



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