<%@ page extend="ClassName" %>

解决方案 »

  1.   

    怎么不行呢? 提示 extend 是无效的属性阿
      

  2.   

    vssivl(克斯)说得正确,我试过是可以的。
    <%@ page extends="类名" %>
      

  3.   

    其实大家一看我的需求 应该都明白了。 我以前不是搞java的 但是软件的思路都是相通的。所以学习或者用一门新的语言作系统。我都希望这个系统能够被我以后所复用。那么我都希望把我的基础架构搭建好,那么以后开发系统就非常的快。
       就如:在的dephi中 单纯编码 普通的一个系统(如:汽车美容管理系统)  我们公司一个程序员一个礼拜就能够搞定了。这也是归公于我们的基础架构已经非常的完善。常用的解决方案都已经在基础机构里面完成了。其他的人就感觉是在做二次开发一样。
      

  4.   

    呵呵 想法是不错的,桌面程序中的form得确是可以extends,不过jsp这个东东跟form是有区别的,有很多是html的控制,你想想你要在jsp1和jsp2之间继承什么?如果为了代码重用,你可以用jsp:include等机制,极少使用extends的。
      

  5.   

    用include本来也是非常好的机制。但是肯定没有extends好。因为作为每一个企业自己的一个框架架构用include来实现就不那么明智了。比如:自己实现jsp的页面持续状态。
      

  6.   

    jsp的复用最好通过include实现BTW:
    如果你的jsp代码中还有超过1%的java代码,那么你的jsp水平还不够.
      

  7.   

    jap的复用一是通过include如果一定要搞一个基础框架以便于二次开发的话
    肯定也不会写一个jsp的父类去继承,因为实际项目中这样意义并不大
    而应该用xsl设计一种jsp模板,使html很容易转化为jsp如果你一定按照delphi的思想去写jsp的父类说明你还不明白mvc的理念,jsp只是做表示层,应按照表示层来开发,尽量不要含java代码
      

  8.   

    有开源是用inster机制比include强大多了
      

  9.   

    是啊,做View层也要使用父类来重用??
    恐怕从效率上来说反而降低了吧?这个用到控制层比较多吧?所以Servlet才会经常用到Base类
      

  10.   

    呵呵呵呵 也看过mvc,也了解mvc的思路。就是因为mvc 所以才要写父类 而不是用include. 要知道现在的java无论哪种架构开发效率其实还是非常的低下的,Structs等,要做到所需要的代码分离技术而产生的配置十分的繁琐,自己也写了常用的自定义的标签,但要实现页面状态的持续非常的麻烦,jsp继承父类并不是说我们的业务逻辑要放在父类,肯定不是,而是对jsp本身页面的一个基础功能扩充,比如我这两天封装的listpage  editPage类里面做了大部分的页面grid方面的显示分页等工作,我封装的editPage  jsp类对数据编辑页面的日常应用作了一个补充。不知道大伙明白我这个页面状态的持续所表达的意思没有,这方面我感觉java里面,相对作weblogic的应用要轻松得多。可是客户不接受阿!
      

  11.   

    看看我们的这个如何:www.htok.net
      

  12.   

    觉得 自定义的标签 麻烦
    可以使用 velocity这样的模板机制
    关于扩充 jsp本身 没尝试过不过 感觉jsp本身逻辑功能已经过于强大在去扩充和去自定义标签 差不多吧。
      

  13.   

    复用用继承好像不如实现接口,少用继承.刚刚CSDN看到的
      

  14.   

    JSP页面从一个父类中继承的问题,在JSP规范中确实提供了这么一种机制。不过实际工作中用处并不是很大。现在我们都是以一种MVC的模式进行开发的。需要在页面上进行的逻辑处理时很少的。实际的业务逻辑代码应该放在JavaBean中。
      

  15.   

    jsp继承父类并不是说我们的业务逻辑要放在父类,肯定不是,
      

  16.   

    我是从CS开发转向到BS开发的。刚刚用JSP时很不习惯,也想楼主所想,要是能继承就好了。用了一段时间才明白,这好像不现实啊。现实的做法是你写主要的后台类,让别人去给你作前台的View。还有一招就是将通用的东西设计成标签,也很爽的。还不行就只能自己一边做一边抱怨BS的前台设计吧,
      

  17.   

    mvc 无论是在jsp,asp.net 或者其他的b/s应用中,肯定都适用。但是 事实上我们在b/s结构中日常作业务逻辑相对来说调试和工作量都比较单一。而b/s的view相对工作量还比较繁琐一些。怎么把view的工作量解放出来?对于其他的开发b/s 比如:pb 可以用datawindow.  asp.net 可以用webform. 所以很多人在做开发的时候还是使用jsp+bean或者标签(structs也是标签)。而这一切最终的目的是尽量的实现view中html页面和代码的分离。
      在delphi中一样 我想很少有人把复杂的业务逻辑放在一个form里面。肯定是封装类.所以 面向对象 软件的思路肯定都8 9不离十,不管你是b/s结构 还是桌面应用。在delphi中可以对view(也就是delphi的form)写一个基类。如:显示列表的listform,用来编辑的editform. 对于里面的元素可以通过写vcl控件(相当于java的自定义标签或者bean,asp.net的控件或者标签,pb的用户object,vb的activex)。
      

  18.   

    说这么多的目的就是如何建立一个团队或者企业的快速的开发平台。这个是非常的重要,不然作了很久的软件 也许就仅仅是量的积累。
      ps: 期待jdo. 对jdbc这种基本上没有经过多大封装的玩意的确不感冒,从资源占用上的确有优势,但开发速度的确不是十分的理想,要知道我们用来99%都是做数据库的相关开发阿。而or影射的灵活性又太差.
      以上仅仅是我个人这半个月来对java的理解,正之处请指正。
      

  19.   

    对jdbc这种基本上没有经过多大封装的玩意的确不感冒:
    ---------------------------我不知道这句话是什么意思,你要对jdbc封装什么,首先可以用数据源加连接池,避免一些基本代码另外,对诸多的sql语句,用单独的外部sql文件,用key来检索,然后执行。。最后再次强调,DBbean由于有很多相似之处,最好用xsl模板生成,当然里面的Connection,stmt,rs等等你可以写父类封装,这样应该可以完成你所谓的jdbc封装。同样,你要求的jsp作父类的想法,同样可以用它来实现,请参看前面的回复(题外话:封装太多,程序员会蜕化的^_^)
      

  20.   

    如果你用JSP来复用的话,说明你的JAVA框架不敢恭维JSP是表现逻辑,只需要用极少的JAVA代码,否则就应该考虑你的设计问题了
      

  21.   

    如果为了代码重用,jsp:include等机制用的比较多。引楼上的:封装太多,程序员会蜕化的^_^)顶~~~ 而且封装的东西大多是有太多的冗余,除非你封装的够细致,如果太细致又失去了它的通用性,矛盾啊。
      

  22.   

    经过这几天的努力。我已经封装好了DataBaseDeal类。这是一个数据库操作类。基于JDBC.其实也没有什么特别之处。只是对常用的操作进行了全方位的封装。有15个静态函数,平均每个函数都有三个多态。基本上能够满足程序员的数据库操作的需要。而作为日常的数据库系统: 列表页面(查询,排序,编辑,删除,增加 等功能的列表页面), 编辑页面(增加,编辑,审核页面) 的这类数据库的页面操作的基类也已经封装完成 进入测试期。
       下一步就是进行页面状态持续的问题的封装(这点思路来源于前几天开asp.net 和jsp[Servlet])的比较,整体思路出来了 应该没有什么问题。
       这样以后我们公司的程序员基本上培训几天。只要懂数据库操作的都可以通过java来开发了。   现在的架构还是采用的是mvc模式。只是对view进行了一些封装。真个架构思路没有变。但是一旦页面状态持续的基类写好了 那么在简单的页面会放弃mvc,也就是去掉控制这个环节,直接通过view页面接收。复杂的页面还是采用mvc.
      

  23.   

    这半个多月来也看了一些javade资料,但是 java提供给我们的不是一成不变的东西。重要的是自己的理解。由自定义标签+mvc的思路也就成就了structs,由数据库的OR影射成就了hibrate。
        封装的目的一个是开发效率,二是规范性容易把握,三是升级变更只要升级基类就ok.这就是为什么以前我在用其他的语言面向对象的语言或者平台作开发的时候。常用的我宁愿继承一个什么都没有改变的类来让其他的程序员来继承他的原因。
        还有我想说的一句:面向对象因该和任何架构都不矛盾的吧!
      

  24.   

    view是给最终客户看的,他看到和能理解的仅仅是页面上的一块一块,也就是include,他不可能也不应该知道这个页面和那个页面有父子或者兄弟关系(extends)。如果设计成这样了,那么毫无疑问是失败的。从另一个角度来说,你也不要指望一个做页面的美工mm知道oo.封装的一个重要目的,也可能是当初最重要的目的:权限和安全楼主没有考虑到,现在有种说法是拒绝继承,用aggregation的做法来做调用的proxy.但是也是见仁见智的做法。
      

  25.   

    在基类里面权限肯定是有的 这点是肯定考虑到了的。
       
        view是给客户看的,这句话说得有点太过了。对于客户来说 肯定的 作为b/s架构 最终他所关心的是客户端的html代码  你是怎么实现的他肯定不是非常的关心,而且也关心不到。
        
        要知道美工MM作的html页面 我不相信你直接使用 你的程序员只是更改一个名字都放上去???
    的确高。
       
        商业化的项目 都是要以效率和质量为保证的,其他的一切说了都是空。
        要明白世界上没有一成不变的道理 :)
      

  26.   

    也许有一天"chenyingchun(油条)"会了解JAVA的真正广博和j2ee的深奥,而不是仅仅局限在讨论b/s和jsp上面.但是对于现在的你我无话可说.......因为这些只是你在短时间内对Java的认识.附带一句:真正的高高高高手很少或几乎不来这里(我经常来,所以我不是高手).要看真正的高手去
    http://www.theserverside.com/
      

  27.   

    >>也许有一天"chenyingchun(油条)"会了解JAVA的真正广博和j2ee的深奥,而不是仅仅局限在讨论b/s和jsp上面.
        呵呵呵呵. 好一句博大精深!哪门语言,那个平台不是博大精深?jsp不能讨论吗?
    我前面都已经讲过了为什么要加高高高手这几个字。如果不是帖上高高手三个字,有那么多的"高人"近来吗?呵呵呵呵。
        
       那位高人说说你们公司现在自己的java的开发的一些基础架构或者基础类。属于自己的东西,这里是讨论交流, 不是在那里发一些毫无用处的语言的。
      

  28.   

    随着技术的发展,实现权限控制比较好的办法是AOP,比较早的设计有filter实现,我记得还有一个响应链的设计模式就是专门处理这类场景的。把权限做一个功能本身是比较影响业务的。如果楼主面对过足够啰嗦的用户和足够频繁的改动,就不会去尝试着怎么设计公用的基类了,用户一个不经意的改动就会让你的“基类设计”前功尽弃。我不是web开发人员,但是可以肯定的是理想的开发需要程序员用近html习惯的表达式语言的标签做替换以后,和美工做的静态页面一个外观,或者不变动任何代码最好。应用性的项目以迅速满足用户的业务需求为第一要务。
      

  29.   

    回复人: temony(temony) ( ) 信誉:100  2005-05-12 12:54:00  得分: 0  
     
     
       也许有一天"chenyingchun(油条)"会了解JAVA的真正广博和j2ee的深奥,而不是仅仅局限在讨论b/s和jsp上面.但是对于现在的你我无话可说.......因为这些只是你在短时间内对Java的认识.附带一句:真正的高高高高手很少或几乎不来这里(我经常来,所以我不是高手).要看真正的高手去
    http://www.theserverside.com/
      =======================
    没有自己的交流平台,怎么折腾都是在听别人说,不发展提高自己的技术水平,永远也就是跟风性质的。
    csdn虽破,闲了还是常逛逛的好,毕竟是我们自己的交流平台。