webapp开发平台 - CSDN
精华内容
参与话题
  • 1.5 版本更新说明 BUI 1.5版本以后变化很大,统一新的风格,新的规范750,新增基于Dom的数据驱动,完善了单页路由页面的生命周期等等,在...后续我们还会整理一些实战类的教程,欢迎关注BUI Webapp专栏。 一...

    原文地址: https://segmentfault.com/a/1190000012994082

     

    1.5 版本更新说明

    BUI 1.5版本以后变化很大,统一新的风格,新的规范750,新增基于Dom的数据驱动,完善了单页路由页面的生命周期等等,在好用的路上越走越远,如果你也觉得好用,帮我们推荐给您身边的朋友,谢谢。后续我们还会整理一些实战类的教程,欢迎关注BUI Webapp专栏

    一、案例代表

    点击预览QQ交互效果GIF

    这是你看下去的动力, 我用BUI仿照QQ的手机截图做出来的一个demo, 包含QQ的常见交互, 侧滑边栏,TAB切换,侧滑列表,下拉刷新,下拉菜单,弹窗搜索等交互操作, 这几种操作很多UI框架都有, 但几种操作结合在一块, 不同方向之间的交互冲突, 不是那么简单的事情. 使用BUI耗时1天.

    通过这个看似简单的例子, 使用BUI快速开发出来的应用是可以上得了台面的.在没有设计稿的情况下, 我们可以仿照任何一款APP开发,并且按照APP的相同比例完美还原. 另外一个是在各种复杂的手势操作交互里面, BUI游刃有余.

    请使用手机扫码操作看看.

    QQ演示地址

    建议扫码在手机预览, PC预览不支持手势操作.

    点击PC预览Demo

    BUI控件demo

    二、前言

    今天的主角就是BUI交互框架, 又不仅仅只是框架, 这是一整套快速开发Webapp的解决方案. 请查看BUI官网, 里面有DEMO演示, 给你最直观的感受.

    如果你也跟我一样在寻找一款快速开发的Webapp框架, 相信我,你来对地方了. 欢迎加入BUI 移动开发交流群: 691560280满 
    BUI 移动开发交流群2: 4170980

    我自己从2011年开始接触移动混合app开发至今, 开发的应用也有几十个了, 这些经验可能对别人也会有所帮助. 于是我把它整理出来, 围绕着快速开发,BUI做了很多事情, 看完你就会明白, BUI的快是有意义的.

    面向的开发者

    • 混合App开发者
    • 后端开发者
    • 前端
    • 美工

    我对框架的要求

    我找过很多框架, 对框架有一些要求:

    1. 简单学习上手快;
    2. 能够轻松定制UI;
    3. 开发一次,跨平台全适配,什么安卓,IOS,微信,淘宝,支付宝,钉钉,浏览器等等;
    4. 控件要多,至少满足平常所需;
    5. 能结合第三方打包平台,打包成独立应用;
    6. 有案例或者模板可以参考;
    7. 支持物理按键后退;
    8. 支持后退刷新;
    9. 支持后退到指定页面带动画;
    10. 模块化开发;
    11. 反应速度快;

    ...

    这样的要求不过分吧? 
    但发现每个UI框架都有自己的定位, 跟我要的还不太一样, 于是我们只能自己造轮子.
    既然自己造轮子,那就要先做最适合自己的,然后才是适合别人. 这里有必要交待一下背景.

    三、背景

    早在2011年, 品高公司就开始接触移动互联网, 并有了第一个基于Cordova的混合app开发框架及打包平台--Bingotouch (那个时候除了Appcan,没有像Dcloud,APICloud等比较成熟的平台) ,为了配合Bingotouch开发框架, 我们需要有一个UI, 于是我们有了一个简单的UI, 那时只有一些简单的基础控件, 简单的适配(可以在打包自适应,但无法在浏览器预览), 页面切换传参使用原生的切换, 其它复杂点的就用第三方的插件, 下拉刷新就用iscroll, 投入到项目开发中就没去管UI了, 一晃就4年过去了, 简直就是奇迹.

    但随着混合应用的技术推广及系统的升级,手机屏幕越来越大,我们的UI存在的一些不足,我们意识到,我们的UI必须升级了. 经过4年的移动开发项目经验沉淀, 于是2015年底我们就开始着手UI的改造.

    四、移动开发的难点

    这里顺便交待一下我们的旧UI存在的问题吧.

    1.viewport问题

    旧UI采用viewport固定宽度的方式适应, 把设计稿更改成320大小, 然后我们按这个大小量取间隙,还原设计稿, 这样会导致在浏览器整个页面变大, 之前不考虑浏览器,所以问题还不大, 但随着viewport在不同手机设备的表现, 这种方式瓶颈越来越大, if else 越来越多.

    2.UI组件少

    早期的时候,基于zepto的控件还要适应移动端, 是少之又少, 所以我们经常需要上网找或者自己写控件, 这样就造成每个控件的使用方式不一, 兼容不一, 较难上手.

    3.不同平台需要多次开发

    由于页面切换是使用原生切换,这样体验较好, 但是也带来一个问题,跟框架结合过于紧密, 有些项目需求, 开发以后,客户要求在微信上线, 这样就得开发2次, 如果还要在其它平台呢? 不敢想象.

    ...

    正是因为有了这些问题, 才让我们的新BUI适应性越来越强.

    五、设计思路

    很多看完文档不太理解BUI的更多是Native模块, 这里是我们区别于其它webapp开发框架的地方, BUI的一个控件或者一个方法不止做一件事情. 我们这里主要分析一下Native模块的设计.

    前面谈到我们的页面切换传参是用的原生切换, 在安卓2.多的系统,如果使用location.href跳转会泛白,单页在不同安卓下的表现也不尽完美, 所以我们这里采用的原生, 而原生在web浏览器是不能运行的. 于是我们想采用一种兼容的方式, 像混合应用一样, 中间做一层转换, 这样就可以各取所需, 需要web时, 整体切换成web.

    Method <- web <- BUI -> Bingotouch -> Native

    1. 思路1

    BUI设计思路1

    思路解析: bui 通过 bui.isWebapp (旧版是bui.debug) 来选择是web,或者native, 所有native模块需要在 bui.ready 里面去初始化, 就这样,我们把Bingotouch 里面常用的交互, 页面跳转, 传参, 刷新, 回退, 请求, 上传, 下载 等常用的功能模块做了封装统一API, 每个native模块的方法都对应两个不同的方法, 这样在使用过程,用户不需要关注是原生还是web, 只需要知道,我在浏览器运行, 就设置 bui.isWebapp 为true, 需要打包, 就用 bui.isWebapp 为false;

    BUI设计思路2

    以上就是我们的BUI 为我们公司的Bingotouch而实现的一套UI思路, 细心的你可能会发现, Bingotouch 跟互联网上的第三方平台很像, 没错的, 但是我们出来比较早. 这点我觉得很引以为豪. 所以看下那个设计思路, 我们也是为了扩展到第三方平台预留了接口. 于是我们有了不同版本的 bui.js .

    2. 思路2

    BUI设计思路3

    场景1: 客户指定要使用第三方平台打包;

    我们的Bingotouch就派不上用场,即使我们很优秀, 但是客户不放心, 用第三方平台后面可以不依赖于某一家公司, 可以很容易找到其他开发者, 客户的担心也不无道理.

    第三方平台的出现方便了开发者,但也带来了新的难题, 一个第三方平台,会有自己的开发生态, 工具, API, UI, 开发者要学习的东西太多.

    于是我们BUI又可以派上用场了, 我们还是用我们熟悉的方式开发, 只是特殊部分原生接口,使用第三方的就可以了, 这样你只需要学习一次BUI,就能开发其它平台,使用其它平台的部分原生接口,想想是很美好的事情. 后面发现每个平台的上传,下载,文件处理等的方式都不同, 处理起来很耗费时间, 针对第三方平台我们精简了部分Native方法, 只保留了 页面加载,传参,后退,请求,刷新这些.

    这样, 客户不管指定哪个平台,都可以使用我们的UI来做开发交互, 开发人员都不用再学习新的UI, 能减少一点是一点啊.

    六、框架特点

    围绕这个想法去设计, 再分析了互联网上的一些UI的特点, 我们的框架应该是这样子的:
    介于webapp跟混合app开发之间, 大部分应用有80%以上的功能都是由UI实现的, 这样通过学习一次BUI, 你就可以游刃于不同平台之间.

    BUI成本优势

    1. 简单学习,快速上手

    在软件公司里面, 开发者占多数以及人员的流动等因素, 如果开发者愿意去学习使用, 可以解决招不到合适的前端问题. 所以学习要快,简单.

    技术选型

    我们在技术上没有依赖于vue,react等先进理念, 我们就是要简单, Dom是最基础也是最容易理解的, 所以我们基于zepto或者jquery.

    工具

    开发者习惯用什么工具,就用什么工具.习惯用什么 webpack,gulp,sass,less 完全由自己做主. 但是如果使用我们推荐的sublimetext工具, 我们有针对这个工具的一个插件, 可以快速书写,事半功倍.

    丰富的文档及入门视频

    BUI的入门文档只需要5分钟 
    BUI的控件API文档 
    BUI的规范文档
    BUI的FAQ

    2. 多终端多平台适配

    我们采用独有的规范,使用REM适配,开发出来的页面,能够在各种安卓IOS系统,webkit浏览器(淘宝,微信,QQ,钉钉),第三方打包平台(Dcloud,APICloud,APPCan等) 不同分辨率,保持一致的缩放效果. 跟web保持一致的切图习惯,只是在做单位转换的时候, 是基于540px设计稿,1rem=100px
    这是很多UI欠缺的, 给你一个设计稿,没有什么指引告诉你图要怎么切, 大部分是采用响应式自适应出来的效果, 看上去一样,实际效果是跟效果图有出入的.

    如图, 其它UI的适配的高度是固定的, 随着屏幕增高, 底部的空白会越来越多, 而BUI是整体等比缩放, 像一张大图缩放到合适的屏幕一样. 真正是一次开发,多平台适配.

    其它UI的适配:

    其它UI的适配

    BUI的适配:

    BUI的适配

    3. 丰富的交互组件

    BUI控件演示Demo

    前面我们也说过,旧UI我们需要经常找插件,找来的插件也不一定能用, 调用系统原生的交互,在安卓跟ios会有不同的表现, 为了避免这种情况, 我们把互联网上常见的插件都统一开发出来, 一致的交互, 一致的使用方式, 一致的API.

    BUI的组件还有些不太一样的地方, 我们关注控件的交互,主张相同交互由同一个控件实现. 我们的组件是内容跟结构交互分离, 一个组件可以做多件事情, 例如:

    bui.slide 是一个焦点图组件, 它除了自身支持, 横向,纵向,全屏,自动播放等功能以外, 我们稍微改变了参数, 它就变成了 tab 组件.

    **(这里不能直接上传gif交互图,我把重要的交互展示一下,想看更多交互请直接点击预览交互效果)**

    bui.slide 焦点图控件

    预览交互效果

    js:
    var uiSlide = bui.slide({
        id:"#uiSlide",
        height:200
    })
    html:
    <div id="uiSlide" class="bui-slide">
        <div class="bui-slide-main">
            <ul>
                <li>
                    <!--第1屏-->
                    <img src="" alt="">
                    <div class="bui-slide-title">图片标题</div>
                </li>
            </ul>
        </div>
        <!-- 分屏菜单 -->
        <div class="bui-slide-head">
            <ul >
                <li>1</li>
            </ul>
        </div>
    </div>

    TAB 选项卡

    TAB初始化

    js: 
    var uiSlideTab = bui.slide({
        id:"#uiSlideTab",
        menu:".bui-nav",
        children:".bui-tab-main ul",
        scroll: true
    })
    html:
    <div id="uiSlide" class="bui-tab">
        <div class="bui-tab-head">
            <ul class="bui-nav">
                <!-- 分屏菜单 active 是激活的TAB样式 -->
                <li class="bui-btn active">Tab1</li>
            </ul>
        </div>
        <div class="bui-tab-main">
            <ul>
                <li>
                    第1屏
                </li>
            </ul>
        </div>
    </div>

    仔细观察下这两个的结构及交互,变的只是父层的样式, 其它结构及操作都是一样的. 我们把TAB的结构再拆分一下, 就变成了 TAB在顶部以及在底部的效果.

    TAB在顶部
    TAB在顶部

    TAB在底部
    TAB在底部

    TAB在侧边
    TAB在侧边

    这样是方便了,但是要记住的参数很多,怎么破? 这就要谈到我们的BUI Fast插件了, 一个快速书写的 Sublimetext插件, 这个后面篇幅再介绍. 我们把比较重要的组件给大家介绍一下.

    还有什么是bui.slide能做的? 例如: 微信里面的推广,经常是整屏往上滑动, 我还用过 bui.slide 去拓展了一个简单的有动画效果的路由. 发挥你的想象前, 先仔细了解控件的特性. 后面我们有自己更简单的单页路由.

    bui.list 下拉刷新及上拉加载控件

    bui.list是基于 bui.scroll 扩展的一个加载分页及刷新的一个控件, 默认把分页都处理好了,你只需要配置一个数据请求的地址, 能返回一个数组就行了, 如果返回的字段不一样, 也是提供了字段映射的配置, 开发一个加载及下拉刷新功能的列表, 只要5分钟. 如果这个满足不了你的需求, 你可以再看 bui.scroll 及 bui.pullrefresh 这两个控件.

    bui.list

    bui.dialog 弹出层组件

    bui.dialog 弹出层插件同样是一个扩展性特别强的插件, 支持从不同方向进入, 支持关闭打开, 支持全屏等, 支持动态创建以及静态渲染,
    这两者的区别 例如,

    动态渲染
    bui.confirm, bui.alert, bui.prompt 都是基于dialog动态创建的控件, 这种方式简单,只需要传入content参数;
    静态渲染
    还有bui.select,bui.actionsheet, bui.pickerdate 等控件. select及actionsheet 的底层都是一个静态渲染的对话框, 这样有个好处就是, 对话框的内容都自由定义.

    预览交互效果GIF

    bui.select 选择控件

    选择控件,支持单选,多选, 支持弹窗或者不弹窗, 支持静态或者动态渲染.

    图片描述

    bui.actionsheet 上拉菜单控件

    上拉菜单控件, 常用于分享

    图片描述

    bui.swipe 滑动组件

    bui.swipe 也是很强大的一个控件, 解决同一个页面的各种手势操作冲突. 像 bui.sidebar ,bui.listview 都是基于bui.swipe扩展的插件.

    图片描述

    bui.sidebar 侧边栏组件

    支持左边跟右边,支持同时, 但还是建议同一个页面不要出现太多这类交互.

     

    bui.listview 侧滑列表组件

    侧滑列表控件,支持菜单在左边或者右边

    图片描述

    bui.hint 自动消失提醒组件

    消息提醒自动消失, 支持上中下等方向, 并且支持自动关闭或者手动关闭, 可以指定在某个容器内.

    图片描述

    bui.accordion 折叠组件

    折叠菜单, 显示隐藏, 支持全部显示,或者一次只能显示一个.

    图片描述

    bui.dropdown 下拉菜单组件

    下拉菜单, 常用于搜索旁边的选择, 选项不宜过多.

    图片描述
    这些都是基本的组件, BUI官网其实还有很多, 就不一一列举了.

    4. 轻松定制UI

    BUI是有规范可循的,这个在输出设计稿的时候,尤其有用. 而且BUI更多的是关注UI交互这块, 只要遵循BUI的结构规范, 里面的内容是可以自由定制的, UI也是随你怎么修改,只要ID不变, 交互就不变.

    5. 快速开发

    重头戏来了, 前面这些都只是铺垫, 只有简单的文档, 丰富的组件, 这些每个框架都有, 不能算快. 
    我们围绕着开发人员快速开发, 做了很多事情, 让你如虎添翼.

    5.1 BUIFast插件

    BUIFast 是Sublimetext的一个插件, 前面我们也说了,我们并不要求用户使用某个工具, 但如果用户使用我们推荐的工具, 那就是如虎添翼. Sublimetext是一个优秀的编辑器. 安装好BUIFast插件以后, 你可以使用BUI的快速书写.

    规则如下: 
    ui- 生成结构, bui- 生成脚本

    ui-html 生成BUI的标准引用
    ui-page 生成BUI标准结构页面

    ui-控件名 生成 控件的结构;
    bui-控件名 生成 控件的初始化; 
    两个前呼后应.

    后面我们新增了 bu-控件名-demo 直接生成示例代码. 所以前面说的, 你根本不需要去记住结构,你只需要记住有什么控件名. 比方 bui-slide-tab

    点击预览效果22

    5.2 buijs Node命令行工具

    全局安装buijs以后,每次创建如果有新版本都会从github获取, 可以在任意地方创建, 并且可以指定模板及打包平台.

    安装

    sudo npm install -g buijs

    简单创建工程包(默认webapp平台)

    buijs create demo

    指定模板 
    同一个工程可以重复新增模板, main- 开头会覆盖main 模块, page-开头是新增模块. 点击查看更多模板预览 部分模板我们还增加了常用的交互处理, 比如登录输入框的删除, 注册发送验证码的倒计时, 如果不需要可以自行删除.

    buijs create demo -t main-tab

    指定dcloud平台
    指定平台以后,创建的工程可以直接覆盖到平台新创建的应用目录, 默认bui绑定了物理后退按键的处理.

    buijs create demo -p dcloud

    点击预览效果23

    5.3 模板库

    模板库有2个,一个是配合buijs工具创建的, 但由于每次创建都会获取最新,如果太多模板,这里创建工程就会偏慢, 所以我们只把常用的模板放github上面, 我们还有一个新模板库, 那里下载下来每个都是 CSS,js,html 一起的.

    模板库

    5.4 插件库

    bui的官方组件只是一些基本的组件, 后续还会扩展.

    5.5 案例库

    除了插件,模板,官网还提供了一个案例库, 这个案例是一些通用的例子, 下载下来就能拿去开发. 
    这里比较有代表性的一个案例是仿照QQ的一个交互, 交互复杂,但开发起来我们只耗时1天.

    BUI代表案例QQ

    点击预览
    建议扫码在手机预览, PC预览不支持手势操作.

    七、设计思路改进

    1. 去平台化

    从BUI出来诞生到现在, 在品高内部已经两年了, 服务了近百个项目, 其中也暴露出来了一些问题.

    1.第三方打包平台如雨后春笋般增长, 我们的兼容何时才休?

    用户在做开发的时候,一开始选择了平台其实也不会再转换其它平台了, 虽然我们提供了这种可能, 对于用户来说, 在webapp及打包平台间切换用场会比 APICloud 平台转换到 Dcloud平台之类的场景要多得多, 所以我们目前只兼容 Bingotouch, APICloud, Dcloud 有对应的 bui.js , 其它平台暂时不考虑.

    2.由于我们基于DOM开发,入门门槛低,带来的问题是开发过程中的代码质量无法保证;
    3.每个人喜欢用的模块化不一样, 有人喜欢用requirejs, 有人喜欢用seajs, 同样的模块不能在项目之间共享;

    2. 单页路由

    在用第三方平台的原生跳转里面, 也有一定的局限性, 比方, 后退刷新, 后退多层到指定页面 等, 这些每个平台的处理都不一样, 而且有的都不允许这么处理. 我们需要更灵活的路由, 支持效果自定义, 支持后退刷新, 支持后退到指定页面, 支持物理后退 等, 这一切创建对应工程包的时候, 你就已经拥有.

    路由效果

    这里我们默认采用的是微信的切换效果, 你还可以选择其它交互, 例如 dcloud 的 cover, QQ 的slide 切换效果, 这些效果都是为了让你的应用更好的嵌入对应的平台. 这种特别在原生跟轻应用之间切换较为常用.

    预览交互效果26

    3. 模块化

    我们使用我们自己的模块化,跟路由一起配合使用, 开发的模块在项目之间的共享成为了可能, 我们还按照requirejs,seajs 的接口设置, 可以兼容之前的模块.

    4. 路由及模块化的原理

    当你打开index.html的时候,就会自动加载main模块, 模块的命名, 除了main, 其它匿名模块默认都是.html前面的路径名, 比方: main 模块有个按钮, 按钮有个链接(注意不能使用a标签)

    main模块, 路径: pages/main/main.html

    <div class="bui-btn" href="pages/sidebar/sidebar.html">跳转到sidebar</div>

    点击会自动跳转到 pages/sidebar/sidebar.html , 这时会自动加载 pages/sidebar/sidebar.js

    sidebar.js 路径: pages/sidebar/sidebar.js

    loader.define(function(require,exports,module){
        
        module.exports = {};
    })

    这样, 如果其它页面要调用sidebar的模块

    loader.require("pages/sidebar/sidebar",function(sidebar){
       //  
    })

    这是路由最简单的用法, 当然他还有很多其它定义, 具体需要自己查看API了.

    路由

    八、总结

    与其说bui是一个交互框架,我觉得我们更像是一个移动快速开发解决方案, 围绕开发过程中的效率,一点一点的进步优化, 我们也针对了常用的平台的快速创建工程包, 创建完覆盖到对应的平台应用包里面就能使用了, 是不是开发最快的webapp框架? 我希望是, 但我更希望整理的这些内容对别人有所帮助.

    BUI的目的不是要成为一个很优秀的框架, 而是可以帮助大家解决80%问题的框架.

    一个人快, 节省的只是一个项目的时间, 如果每个人都能开发更快, 节省的是N个项目的时间. 后面我们会在 segmentfault的 BUI的专栏 里,把一些常用的技巧,及使用上的FAQ整理一下, 欢迎一起理性探讨.

    展开全文
  • WebApp开发入门

    2019-07-21 07:01:43
    web app 的技术平台很多,如adobe phonegap、sencha touch、appcan(国产)、dcloud(国产)平台。我选择了dcloud平台,原因:简单,容易上手。 web app项目开发的技术架构:mui+php+mysql 前端: mui(view层/...

    web app 的技术平台很多,如adobe phonegap、sencha touch、appcan(国产)、dcloud(国产)平台。我选择了dcloud平台,原因:简单,容易上手。

     

    web app项目开发的技术架构:mui+php+mysql

    前端: mui(view层/control层)

    后端: php(model层/control层)+mysql(后端忽略)

     

    搭建环境使用Hbuilder IDE(配套使用mui,里面可以mui创建模板,支持mui语法提示)

    PS:也可以使用不同的移动框架,如:SUI、Frozen UI、Ionic。

     

    Hbuilder IDE新建一个web app项目。

    接着创建app项目

    看看项目目录结构。

     

    unpakage----这里存放的是打包后生成的apk或者app,还有一个生成不同尺寸icon图标文件夹。

    此图是由下面的manifest.json图标配置生成的。

    manifest.json---类似于android的manifest,但是比android的manifest更具有优越性,可以跨平台配置android、ios参数(主要是配置android,ios的没有过多的设置),方便接入第三方sdk。

    更多详细的配置,请在manifest.json代码视图配置。

     

    现在来实现一下把web打包成本地app。

     

    接着选择生成什么平台的app。

    这里我使用DCloud平台里面的证书(云打包)

     

    如果需要本地打包的话,就要生成证书别名、私钥密码、证书文件之后,填写进去才可以打包。

    证书别名、私钥密码、证书文件-----这个些是从原生的开发工具生成的,如:使用android studio 或者是 eclipse for android 生成一个keystore。(因为下载IDE太费劲,所以建议使用jdk里面的命令工具生成keystroe)

     

    打包完成后,看项目目录。

    发现apk已经生成了。                     

                     

    PS:web app调试与原生app调试是一样的,建议在真机运行,如果需要在电脑模拟运行的话,比较麻烦,需要下载对应的IDE,如:android stuido/Xcode 。

          我用的是魅族手机,所以Hbuilder就是检测不到我连接的设备。只能把应用打包成apk之后在手机运行。

        

     

    转载于:https://www.cnblogs.com/Sroot/p/5810470.html

    展开全文
  • Web发展简史((webapp+Java原生)移动端开发 )+web网站)

    千次阅读 多人点赞 2019-04-01 20:04:25
    ((webapp+Java原生)移动端开发(微信小程序,公众号,头条app))+web网站) Web发展简史 1:在那时,Web开发还比较简单,开发者经常会去操作web服务器(主要还是他自己的机器),并且他会写一些HTML页面放到服务器...

     

    Web发展简史--------->((webapp+Java原生)移动端开发(微信小程序,公众号,头条app))+web网站)

    Web发展简史

    1:在那时,Web开发还比较简单,开发者经常会去操作web服务器(主要还是他自己的机器),并且他会写一些HTML页面放到服务器指定的文件夹(/www)下。这些HTML页面,就在浏览器请求页面时使用。(当时只能获取HTML,静态页面)

    2:问题就出现了,你只能获取到静态内容。倘若你想让访问者看到有多少其他访问者访问了这个网站呢(还记得那些统计流量的旋转图片吗?!),或者倘若你想让访问者去填写这样一个表单,包含有姓名和邮件地址呢?于此就转向了CGI和Perl脚本,在web服务器端运行一段短小的代码,并能与文件系统或者数据库进行交互(可以交互啦!提交个表单,查看个信息)

    3:当时组织CGI/Perl这样的脚本代码太混乱了。CGI伸缩性不是太好(经常是为每个请求分配一个新的进程),也不太安全(直接使用文件系统或者环境变量),同时也没提供一种结构化的方式去构造动态应用程序。几年来一直很困惑,直到大约2005年左右,出现了Java Server Pages(JSP),微软的ASP,以及PHP!我喜欢把当时的参考架构比作成IIS和ASP.NET,你可以用Visual Studio快速构建一个可伸缩并且安全的应用程序。(因为cgi交互不怎么好,所以在服务器上开始写(jsp,asp,php动态语言代码了进行帮助查找数据,查找图片,动态语言效率更高))

     

    4:直到当时,web服务器多半会返回整个页面或者文档,但AJAX(2005)的出现,让事情变得很有意思。AJAX允许客户端的JavaScript脚本为局部页面提供请求服务,然后可以在无需回到服务器情况下动态刷新部分页面,也就是更新浏览器中的document对象,通常称作DOM,或者文档对象模型。(javascript的出现让用户更加快速的更改,修改页面内容,而不用再去访问WEB服务器去请求,返回HTML修改页面啦!javascript访问更快)

    虽然从服务器端返回的仍然是HTML,但浏览器上的代码能把这HTML片段内嵌到当前页面中。也就是说web应用的响应可以更快,这时我们真正用web应用取代了web页面。谷歌的GMail和谷歌地图都是当时AJAX的杀手级产品。随后用AJAX局部刷新就如雨后春笋般出现。

    5:在随后的几年时间里,AJAX成为了焦点,但在服务器端仍然使用着旧有的技术。大概在2007年,37signals公司公开其成员–Ruby on Rails。那个基于Ruby on Rails 5分钟构建博客的演示完全征服了全世界的开发者。一夜之间,所以谈论的焦点都是关于Rails!Rails的不同之处在于使用规定的方式去设计你的web应用程序,运用一种已经广泛在桌面应用开发,但未被搬到web应用上的开发模式。这种模式就叫做模式(数据)-视图(模板)-控制器(业务逻辑)。Rails强调,“这事就该这么做”,并且通过许多插件让构建web应用再一次更加健全。(这时候后台框架打开了新的大门,后端框架先被提出来的,现在的前端趋势也开始要有MVC的前端框架啦!WEB前端全栈开发,node.js直接访问数据库,mongo数据库,)

     

    6:在2007到2010年期间,涌现了3种开发潮流:

    第一个是智能手机和移动应用潮流。通常情况下,许多应用程序同时有web和移动应用两种版本。尽管如此,服务端仍然返回的是HTML页面,而不是其它移动应用可以识别。因此,你需要返回的是结构化数据来取代HTML。

    第二个开发潮流是jQuery。这是一个非常流行的JavaScript库,能够很容易构建动态、美妙的web应用,甚至是AJAX!

    第三个潮流是Node.js的发布。这是第一次能让你用JavaScript开发高性能的服务端程序,进而可能结束“客户端开发者”要知道HTML/JavaScript,“服务端开发者”要知道.NET/C#/Ruby这样的噩梦。(json是服务器向浏览器返回的一种数据结构,浏览器解析json提取里面的key-value键值对,服务器端(jsp,php)可以把数据库里面的数据封装到json中,发给浏览器)

    7:尽管这是一个不错的架构,但我们可以重用一些在客户端的收获去简化那些曾经发生在像客户端意大利面似的jQuery代码。和Rails精神类似,我们需要用一种规定的方式从服务端获取到数据,再对客户端的HTML页面进行包装。因此,在接下来的2年时间里,业界出现了许多用于简化客户端开发的框架,诸如Backbone,Ember,Derby和Meteor,当然也包括我的最爱,AngularJS,vlue.js。(这些东西访问数据库,把数据从服务器取出到浏览器,浏览器MVC再去解析数据)

    8:因此,这就是我们看到的今天,而我后面要讲到的参考架构是这样的,mongodb作为数据库服务器,node/express作为web应用服务器,客户端使用AngularJS,同时也使用Bootstrap样式风格。我发现这种架构允许我能够快速构建web服务以及基于AngularJS的客户端接口,甚至和其它的服务,如PhoneGap或者其它原生移动开发工具一样,进行移动应用的开发。(这种开发模式越来越可以快速开发啦!应用到webapp开发,这些前端一般用于业务型强,主要用于给用户展现内容和数据,业务型比较强的。移动端开发还有Java原生开发的,主要用于逻辑性强的。Java安卓原生开发(处理密码处理,过滤什么的)逻辑性比较强的应用。现在APP可以使用混合式开发(webapp(html+css+javascript(mui移动端js框架)+node.js+mongo)+原生Java开发),现在网站开发用的还是html+css+javascript(包括js框架)前端+后端(ssh+ssm+springboot框架))。这就是现在主流的开发模式。

    https://blog.csdn.net/zzzkk2009/article/details/9849431   经典的安卓移动端开发(web+Java原生开发)web系统发展历史

    https://blog.csdn.net/z742182637/article/details/52055970   也是web系统开发历史(不怎么清晰,不是太好)

    https://blog.csdn.net/youngyouth/article/details/84755278#web_5   web服务器架构的发展历史
     

     

     

     

    1. 静态页面时代

    大学时候,上机还得换卡穿拖鞋,Novell的网络是很神奇的,然而更神奇的是通讯原理老师半神秘的讲他上 Internet,“Cernet(教育网)有条64K的出口,半年前还很快,现在已经比较卡了”。就这样,我们用Netscape指向Yahoo。那是一个HTML加图片的世界,充斥着各种花哨闪耀的字体和鞠躬的小人,蓝色连接点击后会奇幻的变色。

    我们开始用不熟练的HTML和简陋的设计来设计网页,并且知道这边有个浏览器,那边有个叫WebServer的东西,但管理Sun工作站的机房老师总是盯的很紧,不会让你动系统半分。听说有个叫Linux的神奇东西,好吧我想尝试,可是我只有一台攒的电脑,以及若干张5寸3寸的软盘。我至今感谢一位师兄,他帮我下载并切分了一个版本的Mandrake,就这样室友看到非常奇怪的一幕,我奔波在机房宿舍之间,仔细计算容量来拷贝,就这样在假期里我第一次搭建了Apache。

     

    2. CGI时代

    很快页面上流行一个叫做计数器的东西,免费的收费的建站网站都把它当作卖点,“立体超炫变色时尚计数器”,很快我们看到几乎每个页面都有了一个点击量在88888的酷装置,只是无论怎么点都不会变化。而校园里张贴着令人眼红的广告,“征人写CGI程序,一支500元!“。

    慢慢的,知道了CGI是利用进程间输入输出通信,和WebServer进行通信,从而可以写程序来控制页面输出的内容。但在当时会给硬盘分区就在中关村被看成电脑高手的年代,实在是会者寥寥。即便到了今天,我依然对Perl敬而远之。一些前辈用C写出更高级的CGI应用,比如WebMail,挖到第一桶金,成为今天互联网的先驱。

     

    3. PHP露出锋芒

    说实话,我认为PHP是最受益于互联网浪潮的语言,在合适的时间和好伙伴Mysql一起出现。利用Apache的模块mod-php,将php作为web服务器的一部分运行,效率和维护性都达到很好的提升。脚本语言成为互联网前端开发主力一直到今天。PHP和大哥Perl,以及兄弟Python,Ruby一起盘据在编程语言排行榜5-10名位置。

    同样的Mysql也是时代的娇子,它快速灵活易用成为网站数据库的首选,但很长时间里,Mysql被其他数据库诟病,别说Oracle等高富帅,即便是同为开源的Postgres社区里,也会有这样的声音,“不支持事务也叫数据库?”。没关系,开源社区很快为其加入各种引擎,如今Mysql绝对是装机总量第一的数据库。

     

    4. J2EE

    Java时代来临,一杯咖啡,一个可跳动的小精灵牵动了所有的大型软件公司。没错是所有,包括微软,Sun公司一时星光无限,所有的开发人员都在谈Java。人们对其桌面表现失望进而质疑时,J2EE及时出现了,Servlet+JSP快速成为Web开发的好用技术。能够跨平台,独立解包使用的Web服务器,挂接任意数据库的JDBC接口,一时世界变得很美好。

    微软的ASP也出现了,一开始也是脚本解释,和PHP等技术类似。很快微软的C#和dotNET战略出台,ASP也升级为ASP.Net,从此dotNET和J2EE是竞争者,更是一对站在相同站壕的朋友,互相学习和抄袭对方的技术和设计,直到今天。

     

    5. Web层框架百花齐放

    Servlet是一个优异的Web技术规范,但面对丛多的开发需求,还是不能很好的覆盖。Struts框架很快成为主流,今天我们依然看到很多.do后缀的页面。Struts主要做了三件事,一是对请求Url进行很好的梳理,通过Command模式把请求指配到Action对象上,并可以用同期出现的Ioc框架进行注入。二是梳理出若干有用好用的Intecepter,并可以自由组合构成自己的Stack。三是对页面流转流程通过xml的方式可以灵活定义。

    同期,数以百计的各种框架出现了,多数都是针对Servlet的空白点,在几个方面进行代码或者配置的约定,可谓百花齐放,百家争鸣,我想Java社区能到今天依然繁荣,这种海纳百川,开放的态度是根本原因。如今很多框架已经走过生命期,但还有很多活跃的,其中Webwork即Struts2,和SpringMVC是模板技术类别最出色的。GWT,Wicket等在页面组件类表现不错,还有脱离Servlet束缚Play等框架。

     

    6. WithoutEJB

    J2EE里,除了Servlet外另一个重量级的规范就是EJB。EJB设计的来源是Corba技术,分布式对象技术在EJB规范中有完整的体现。Rod在著作中对EJB规范粗重庞大难用提出各种质疑,尤其是针对其强制分布的要求。我的观念是分布式支持没有错,现在EJB规范中对于Local和Remote的划分定义是正确的。开发人员应该一开始就需要了解接口粒度的划分,本地和远程接口是不同的。对于一般的小型应用,Servlet和EJB容器都在一个虚拟机中,本地接口是合理的,但对于大型企业应用和互联网级别应用,势必需要服务的远程划分和调用。所以早期的EJB,可以说一方面设计不完备,另一方面又过度设计。但EJB自从3以后完全脱胎换骨,成为设计良好的规范。

    Spring作为开发框架,把Ioc和AOP能力发挥的淋漓尽致,在各个层次很好融合其他技术和项目库,一直是Java Web开发的主流。不过面对CDI等JavaEE规范,在注入,生命期管理,对象解耦等优势不在。我预计今后Spring, JavaEE和Osgi会在主流Java开发框架方向竞争,也会相互借鉴和融合。

     

    7. Ajax

    Javascript是浏览器正统的脚本语言,但在那个机器性能不佳的年代,一段Js代码造成鼠标没有响应的情况比比皆是。Js的给人影响就是页面上飘来飘去“点击我”对话框,页面上走马灯效果的变色通告,或者是几十层模态对话框的恶意页面,很多网吧的机器默认Js是禁用的。在很长的一段时间里,Java web开发一个潜规则就是少手写Js文件,这样可以很好的支持多种浏览器和提高效率。

    谷歌火了,Ajax也成为火爆的前端技术,我们在使用gmail,google map等产品时,有了另一种体验,点击链接或按钮后,即便网络不算流畅,页面不再全白重新刷新,而是内容渐渐的出现。其原理就是利用Js脚本到后台服务器获取数据,在浏览器前端对数据进行解析和渲染,在这个过程中,大多数页面并不需要进行改变,只是更新页面中一部分即可。谷歌公司大力支持Firefox使其重生,并和苹果一起发展webkit项目,各自发展了chrome和safari浏览器,伴随者页面渲染能力大力提升同时,Js脚本的解析能力也突飞猛进。我个人认为Ajax这个技术看似简单,但却是新一代Web,所谓Web2.0的基石性质技术,为互联网泡沫后互联网的复兴和今日腾飞起到了重要作用。

     

    8. Ruby and Rails

    快速成长的互联网需要快速的web开发能力,Rails框架出现了,同时火爆的还有Ruby语言,它的出现满足了当时开发者的需要,快速开发,玩cool的东西,有完备的后端模型支持。让我们仔细分析一下Rails中MVC就能发现,Model中对实体对象的关系定义,和JavaEE的JPA很多概念一致,但利用Ruby语言的元能力,可以直接对实体对象进行功能扩展,而其时Java社区还在为贫血,充血对象争论不休。Control,View等层次也能和Java的一些框架概念一致,不过有些设计构思更巧妙,而且Rails的基因就是满足互联网开发需要,和JavaEE企业级应用有所不同。

    很快的,各种语言纷纷出现模仿Rails的项目,Java的Grails, SpringROO,JBossForge,Python的Django,PHP的Symfony等等。毫无例外的,能有影响力的都是开源的,有良好社区能力建设的项目。

     

    9. JSF和CDI

    让我们回到企业应用开发,大家有没有想过所谓企业应用和互联网应用之间最大的差别是什么?我认为是用户数量级别的差异,导致前端设计方式,软件体系,后台数据库,缓存技术应用,有不同的设计理念和方式。用更技术化来说,就是会话和事务。企业应用是有强会话和事务需求的,而这两个技术词语也会一并关联存在。很简单,在一个事务中会经过多次会话过程,直到这个事务全部做完。和我们日常办事是一样的,填单子,和办事人员沟通,修改单据,盖章,各种口舌,最终感慨,办事真难。

    从软件层面考虑,一个企业应用软件可能用户数并不太多,就企业中百十号人,但前后台的交互是长时间,多次会话交互的。JSF技术其实是借鉴了微软ASP.net,它们继承了传统IDE快速开发的思路,希望通过拖拽连接可以快速开发一个应用。页面上的组件,对应后台服务器的业务组件,在得到服务器请求之后,组件需要做一系列动作来完成解析,校验,模型重建,业务方法调用,页面渲染等步骤,这些必然有个较长的过程。复杂性,效率,和其他技术的融合,JSF技术从诞生起就被质疑不断,而且面对每个明星技术,都有些格格不入,比如Ajax出现了,而JSF要求的Post方式还需要重刷页面。但JSF一直在改进,越来越科学完善。如今,配合CDI,JSF是企业应用开发的首选技术之一,大家可以研究一下Oracle的应用产品和ADF开发框架。

    CDI是Seam框架的技术精华形成的JavaEE规范,在JavaEE7里面已经成为最重要的规范之一。和Hibernate最终形成JPA一样,CDI也是GavinKing构思,开发推动的。仔细分析就会发现,CDI几乎弥补了JavaEE在现代开发需求中,对象方面定义的绝大多数不足,比如和DI规范定义了注入,生命期管理和会话范围定义,完善了EJB对于普通POJO对于事务,异步通知机制的定义,还有注解的堆叠定义,装饰模式等等。有时候我就在想,假如JavaEE是GK从头打造,我们开发人员会少走很多弯路,因为他对企业应用的理解和用Java构建框架和定义规范,都是贴近一线开发人员需求。唯一遗憾的就是CDI还没有推动完成,他转移兴趣玩起语言了。关于JSF和CDI,我建议做相关产品的朋友,即便不用这样的组合,最好也对其技术基本内容有所了解,我想对思路扩展是非常有好处的。

     

    10. Netty,NodeJs,Vertx和异步化趋势

    Netty的领导者和Mina的主力开发者TrustLee,是一个说话慢条斯里的韩国人。面试时问我一个关于volatile问题,双方都觉得非母语很别扭,所以就都简单表达一下就算。可我没想到这个同龄的开发人员,日后对Java在互联网公司的地位提升,起到这么大的作用,这个项目就是Netty。我们都知道Java异步集合库的作者DougLea的功劳,Nio1代,对于Socket的异步化还不是很完善,即便是Nio2,工作重心还是文件系统的异步化处理,网络层的异步化设计逐步加强改进。因为Java的设计理念,正交化,接口堆叠,底层功能平台统一化等给异步分布式网络框架留出足够的空间去发挥,Netty,Mina,Grizzly等项目纷纷出现。Twitter宣布从Ruby转向Scala,并使用Netty让其大红大紫。

    所谓异步网络框架,就是对网络层调用,进行异步化,并进行接口封装,使得容易理解和使用。异步能力还是通过Java虚拟机现有功能实现的,通过对数据流的处理和状态感知来进行处理,而不是传统的阻塞式的收发消息。这个符合我们生活中的感受,当你订票时,你会打电话告诉你需要什么,说订好票给我电话,然后你就去做别的事情,直到订票员通知你订好了来支付取票再进行下一步操作,如果订票是同步的,那你就要一直等待订票完成,遇到春运可能会搭上整天的时间。

    为什么异步网络框架也受到重视,答案也是互联网,数以亿计的请求点击涌来时,传统的webserver顶不住了,采用一个线程服务一个请求模型的webserver,无法承受这么大的数据访问,特别对于Java这样的吃内存语言,一个请求占用了一个线程,同时也占用了相对应的若干资源。用企业应用的设计的整个架构面对互联网级别的应用时,有点崩溃的感觉。解决高并发大量请求的途径是高吞吐量加上可扩展的软件架构。异步化可以提升吞吐量,就和银行的排队机一样,顾客来了得到排队服务,当有可用的柜台服务时会主动通知顾客,我们可以设想,即使有再多的顾客,也可以通过增加业务柜台,少许增加排队机和少量人工协调处理来解决。

    NodeJs是一个异步化的基于Javascript的开发框架,是当前的明星技术,符合了一些当前开发需求,如异步化,前端Js技术广泛应用,Js引擎能力极大提升,NoSQL的火爆,组件构建模式变化等。利用Js语言函数式编程能力,Js开发人员可以很轻松的利用已有的组件开发后端应用,前端可以直接用浏览器处理Js,别忘了Js是浏览器唯一能统一识别的脚本语言,或者用JQuery,AngularJS等流行框架,世界很清净,都是Js。

    但我们需要了解在常驻内存服务型程序方面,Java等语言占有极大优势,Java社区很快出现了和NodeJs有相同设计思路的项目,Vertx就是其中的优秀代表。它充分借鉴了NodeJs和Erlang/OTP Actor模型的优秀设计,利用分布式消息机制进行对象间通信,利用Netty进行网络异步操作,方法调用倡导异步调用,有自己的模块化机制。这样,Java社区出现了和NodeJs竞争的技术框架,良好使用,可以解决大规模互联网应用的需求。

    Java领域的异步化趋势可以说刚刚开始,我们看到Servlet和EJB都加入异步支持,Spring的Reactor,JBoss的undertow,随着Java8对函数语言能力的增强,可以预见又会有丛多的项目产生。我关注着异步化趋势和JavaEE开发方式的融合之路,相信那是Web开发的明天。

     

     

     

     

     

     

     

     

    展开全文
  • 主流的Web应用程序平台

    千次阅读 2017-09-06 20:15:57
    主流的Web应用程序平台 动态网站应用程序平台的搭建需要使用Web服务器发布网页,而Web服务器软件又需要安装在操作系统上,并且动态网站都需要使用脚本语言对服务器端进行编程,所以也要在同一个服务器中为Web服务器...

    主流的Web应用程序平台

    动态网站应用程序平台的搭建需要使用Web服务器发布网页,而Web服务器软件又需要安装在操作系统上,并且动态网站都需要使用脚本语言对服务器端进行编程,所以也要在同一个服务器中为Web服务器捆绑安装一个应用程序服务器,用于解析服务器端的脚本程序。另外,现在开发的动态网站都是基于数据库的,需要将网站内容存储在数据库中,使用也要为网站选择一款合适的数据库管理软件。这样,一个动态网站服务器平台的最少组合包括:操作系统+Web服务器+应用服务器+数据库。网站开发平台中的每个组件都有多种可以选择的软件,例如,操作系统可以使用UNIX、Linux、Windows等,根据不同的像ASP、JSP和PHP等脚本语言选择对应的应用服务器,数据库和Web服务器更是很多。使用搭建一个优秀的网站服务器平台往往要根据企业的需要而定,有时甚至由个人爱好需要决定,当然更要考虑部署费用、安全机制、性能及管理维护等因素。

     

    Web应用程序开发平台对比分析

    目前,网站服务器平台比较常见的有ASP.NET、JavaEE和LAMP三种:ASP.NET的服务器端操作系统时使用微软的Windows,并且需要按照微软的IIS网站服务器,数据库管理系统通常是使用微软的SQL Server,而服务器端编程语言也是使用微软的产品ASP技术,就是ASP.NET动态网站软件开发平台;JavaEE的服务器端操作系统使用UNIX,并在UNIX操作系统上按照Tomcat或Webblogic网站服务器,数据库管理系统使用Oracle数据库,服务器端编程语言使用Sun公司的JSP技术,就是JavaEE动态网站软件开发平台;LAMP的服务器端操作系统使用开源的系统Linux,在Linux操作系统上安装自由软件Apache网站服务器,数据库管理系统也是采用开源的MySQL软件,服务器端脚本编程语言又是使用开源软件PHP技术,就是LAMP动态网站软件开发平台。

     

    1.ASP.NET

    ASP.NET是Windows Server+IIS+SQL Server+ASP组合,所有组成部分都是基于微软的产品。它的优点是兼容性比较好,安装和使用比较方便,不需要太多的配置。而且简单易学,拥有很大的用户群,也有大量的学习文档。还有就是开发工具强大而多样,易用、简单、人性化。ASP.NET也有很多不足,由于Windows操作系统本身存在着问题,ASP.NET的安全性、稳定性、跨平台都会因为与Windows NT的捆绑而显现出来。使用ASP.NET平台开发的网站软件,外部攻击时可以取得很高的权限而导致网站瘫痪或者数据丢失。并且无法实现跨操作系统的应用,也不能完全实现企业级应用的功能,不适合开发大型系统,而且Windows和SQL Server软件的价格也不低,平台建设成本比较高。

     

    2.JavaEE开发平台

    JavaEE是一个开放的、基于标准的开发和部署的平台,基于Web的、以服务端计算为核心的、模块化的企业应用。由Sun公司领导着JavaEE规范和标准的制定,但同时很多公司如IBM、BEA也为该标准的制定贡献了很多力量。JavaEE开发架构是UNIX+Tomcat+Oracle+JSP的组合,是一个非常强大的组合,环境搭建比较复杂,同时价格也不菲。Java的框架利于大型的协同编程开发,系统易维护、可复用性比较好。它特别适合企业级应用系统开发,功能强大,但要难学得多,另外开发速度比较慢,成本也比较高,不适合快速开发和对成本要求比较低的中小型应用系统。

     

    3.LAMP开发平台

    LAMP是Linux+Apache+MySQL+PHP的标准缩写。Linux操作系统,网站服务器Apache、数据库MySQL和PHP程序模块的连接,形成了一个非常优秀的网站数据库的开发平台,是开源免费的自由软件,与JavaEE架构和ASP.NET架构形成了三足鼎立的竞争态势,是较受欢迎的开源软件网站开发平台。LAMP组合具有简便性、低成本、高安全性、开发速度快和执行灵活等特点,使得其在全球发展速度较快,应用较广,越来越多的企业将平台架构在LAMP之上。不管是否是专业人士,皆可以利用LAMP平台工具来设计和架设网站及开发应用程序,目前主流的网站都在使用LAMP作为自己的系统运行平台。

    展开全文
  • 开发webapp工具和语言

    千次阅读 2018-06-06 16:06:03
    首先外壳可以用cordova,也可以用HBuilder结合css+html5+knockout(数据绑定)+framework7+require.js
  • webApp开发经验总(一)

    2020-05-09 15:31:05
    你选择webapp 都是为了在规定时间里快速完成,总结就是webapp 适合简单型、大数据分析及报表展示类的应用,这样就能体现出跨平台的有点,开发快捷方便。具体情况还是得根据实际情况分析进行技术选型。相比几个跨平台...
  • webapp开发框架

    万次阅读 2017-11-16 14:38:08
    介绍几个移动web app开发框架     jQuery Mobile  jQuery Mobile框架能够帮助你快速开发出支持多种移动设备的Mobile应用用户界面。jQuery Mobile最新版本是1.4.0,默认主题采用扁平化设计风格。jQuery ...
  • VUE实战项目之喵喵电影

    千人学习 2019-05-13 17:27:50
    2019全新打造Web前端教程,Vue实战项目之喵喵电影,详细讲解项目演示与开发流程。
  • H5+CSS3移动商城实战课程

    千人学习 2019-05-20 10:11:59
    本课程是实战课程,需要了解html和html5的基础知识,掌握css和css3的知识;主要讲解移动商城的首页、商城的分类、商城的购物车、商城的会员等...
  • 前言由于自己平时做项目(自己做或者帮朋友做的移动APP,webAPP,机器学习算法类)比较多,做的东西大多没有整理成文档,现在就把之前做的项目整理成文档分享给大家,好大家以后做相关项目有个参考! 在做HTML5开发时一直在...
  • 本课程是实战课程,需要了解html和html5的基础知识,掌握css和css3的知识;主要讲解移动商城首页、商城分类、商城购物车、产品分类、产品列表、评论、地址管理、下单、会员注册、会员登录、密码修改、订单列表、收藏...
  • H5移动商城15天从零实战课程

    千人学习 2019-07-16 16:39:38
    主要讲解移动商城首页、商城分类、商城购物车、产品分类、产品列表、评论、地址管理、下单、会员注册、会员登录、密码修改、订单列表、收藏、信息列表和详情等...
  • 使用Intellij IDEA 和maven创建web项目webapp全过程。注意中间可能会卡住,所以中间有说要加个参数这样就会很快。
  • 捆绑30+测试

    1970-01-01 08:00:00
    捆绑30+测试
  • app应用选型——原生还是web

    千次阅读 2018-08-30 18:44:52
    原生app是基于平台开发的一个应用程序,webapp则是一个web应用(和pc端的web应用没有本质区别,唯一的区别是一个在pc端的浏览器中访问,一个在移动端的浏览器中访问)。 再举一个例子:原生app类似于安装在电脑上的...
  • 微信小程序和WebApp有什么区别?

    千次阅读 2017-01-15 13:13:11
    微信小程序和WebApp有什么区别?-威震天 1.开发方式: 开发语言和开发感觉方面类似,微信小程序自己的js-sdk也是类似vue和ng的mvvm思想来写。webapp如ionic是基于ng的所有有很多ng插件,但是微信小程序是自己渲染...
  • 关于tomcat的webapp目录

    万次阅读 2018-06-26 17:35:13
    工作这种事情,越做越觉得自己会的不多,要好好努力。今天就记下关于tomcat的webapps目录认知。webapps目录用来存放应用程序,当... 下面关于对于项目中webapp的认知。所以关于在项目中访问本地的图片问题。如图啊...
  • 论手持设备应用的WebApp化!

    万次阅读 热门讨论 2010-07-25 21:51:00
    而当前流行的手机平台有Iphone,Android,Symbian,BlackBerry,Windows Mobile等,同一个应用来说,我们要开发出满足各个平台的各种版本应用。那么我们有没有可能只开发一种应用就能满足各个手机平台呢? 答案是有的,...
  • H5 CSS3公司移动站界面.三天从零实战

    千人学习 2019-06-03 16:11:47
    学会企业站移动站的设计,从0实战开始制作一个公司的移动站点,包含公司的首页、产品页面、资讯列表、关于我们、留言等 界面的演示可以看第一节视频的课程演示
  • ArcGIS WebApp Builder 使用指南

    千次阅读 2015-01-23 10:07:42
    ArcGIS WebApp Builder 是Esri在2014年4月份推出的,相信做WebGIS开发的GISer们对ArcGIS的FlexViewer都不陌生,这次推出的就相当于JS版的Viewer。 1、ArcGIS WebApp Builder安装、部署   ArcGIS WebApp Builder的...
1 2 3 4 5 ... 20
收藏数 70,578
精华内容 28,231
热门标签
关键字:

webapp开发平台