HyperQbs 2.1 released, with full Java Server Faces support

Discussions

News: HyperQbs 2.1 released, with full Java Server Faces support

  1. HyperQbs framework is the first fully compliant and ready to market implementation of the new standard for visual component assembly, which is being defined in the JavaServer Faces specification (JSR 127) under the Java Community Process.

    Press Release
    -----------------------
    San Jose, California - July 18th, 2001 - Qbizm Technologies, Inc., a leading visual component framework provider, is proud to announce a new alpha version of its HyperQbs[tm] framework 2.1.

    HyperQbs framework is the first fully compliant and ready to market implementation of the new standard for visual component assembly, which is being defined in the JavaServer[tm] Faces specification lead by Sun Microsystems under the Java Community Process[sm].

    When constructing a web site that provides a complex GUI, developers often create special purpose infrastructure that simplifies re-using form parts and facilitates the process of applying sweeping changes to style and behavior to all of a site's GUI elements. Over time, the specialized infrastructure created to support all of these tasks tends to take on a life of its own. Unfortunately the idiosyncratic qualities of a particular site's GUI software make it difficult to take advantage of generic purpose programming tools and environments, leaving developers with inefficient, tedious and hard-to-maintain code. Qbizm Technologies addresses these issues with its award-winning component framework HyperQbs[tm] and dynamic face[tm] technology.

    "The new version fulfills requests of many HyperQbs users calling for simplification, support of Sun’s Java Server Pages[tm] (JSP) and WAR archive for easy adoption. Especially the support for JSP lets HyperQbs users to leverage on their current investments in the Java 2 Enterprise Edition[tm] platform and at the same time gain the benefits of future-proof component architecture and re-use." - said Rene Michalek, CTO Qbizm Technologies, Inc.

    Alpha testers are welcome to freely download the whole distribution from the HyperQbs developer portal at http://www.hyperqbs.org. The most valuable feedback will be awarded with a Qbistic present.

    Qbizm Technologies, Inc. (http://www.qbizm.com) is an infrastructure company enabling developers to develop and non-programmers to visually assemble enterprise scale front-end applications from reusable GUI components. Its world class dynamic face component framework, HyperQbs[tm], extends Java[tm] 2 Platform, Enterprise Edition-compliant application servers while providing them a single platform standardized approach to rapid front-end development, assembly and maintenance. The unique and future-proof dynamic face technology automatically adjusts application’s visual content representation and behaviour based on users’ browsing devices and personalization profiles (HTML browser, PDA, WAP, SMS, voice, Flash etc.) reducing development costs significantly even for yet non-existent devices and protocols. Qbizm is a privately held company headquartered in the heart of California’s Silicon Valley with R&D labs located in Central Europe.

    # # #
    Sun, Sun Microsystems, the Sun logo, Java, JavaServer and Forte are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

    HyperQbs is a registered trademark of Qbizm Technologies, Inc. All other names are trademarks or registered trademarks of their respective owners.

    For more information refer to:

    Qbizm Technologies, Inc.
    2033 Gateway Place
    Suite 500
    San Jose, California 95110<br>
    USA
    press at qbizm dot com
    http://www.qbizm.com
    http://www.hyperqbs.org

  2. Forgive me if I sound skeptical, but:
    - How is it possible to be "fully compliant" to a specification that's "being defined" ?
    - How is it possible to be "market ready" with an "alpha" version ?

    Has the JavaServer Faces spec even reached public review stage yet? I think the JSR was approved in May, but with a number of objections re conflict/overlap with Apache "Struts". I can't see it in any of the lists for subsequent JCP stages.

    Anyone know what stage the specification has really reached?
  3. http://jcp.org/jsr/detail/127.jsp

    It's not even public yet!
  4. You are right - JSR 127 remains under development and I should have rather stated that our solution fully meets the design goals of JSR127 and we'll make sure that our framework stays compliant as the JSR 127 keeps moving forward.

    In any case, there is indeed a strong need for a component framework for presentation logic especially in large projects and the JavaServer Faces initiative is proof of it. Generally the rule goes, the larger project, the bigger need.

    There is also already a number of other frameworks out of which only few can say that they meet the JSR 127 design goals. I&#8217;m not saying that HyperQbs is the best (although I believe it is :), but I say that it&#8217;s here and you can evaluate and see for yourself.

    HyperQbs is in production version 2.0 (the &#8220;market ready&#8221; :) and has been already used in a number of enterprise-scale projects either by us or by our partners. The version in alpha is the version 2.1 with enhanced functionality and added support for WAR and the JSP parser (actually it&#8217;s parser neutral - you can use whatever parser you want now).

    I'd appreciate your feedback

    -peter
  5. Good grief man, that is incredibly deceptive on your part!

    To say that your product is "Fully JSR-127 compliant" is TOTALLY different from saying that it "Meets the design goals of JSR-127".

    I may write a little framework in Java which lets you encapsulate data table access with transactions and security. I could say that my framework "meets the design goals of EJB", but tar and feather me if I try to tell you it's "EJB compliant".

    Go away.

    Bryan
  6. Brian,

    > Good grief man, that is incredibly deceptive on your part!
    > To say that your product is "Fully JSR-127 compliant" is
    > TOTALLY different from saying that it "Meets the design
    > goals of JSR-127".

    I don't think so, but I agree that a proper selection of wording would be better, since this is a really sensitive topic as I've found out. I'll be more careful next time.

    At the same time I insist that HyperQbs is fully compliant with the current stage of JSR-127 .... which is the definition of design goals and that we'll make sure that HyperQbs complies with the JSR-127 specs as they evolve. What's deceptive about it? Can you show me another presentation framework that complies with the JSR-127 design goals today?

    > I may write a little framework in Java which lets you
    > encapsulate data table access with transactions and
    > security. I could say that my framework "meets the design
    > goals of EJB", but tar and feather me if I try to tell you
    > it's "EJB compliant".

    Well, we have been focused on the development of HyperQbs for over the past two years - it's much more than your example. It's even further than Struts, Turbine, Enhydra's framework etc. just have a look at http://www.hyperqbs.org and let us know - it's free :)

    -peter
  7. Good grief man, that is incredibly deceptive on your part!

    >> To say that your product is "Fully JSR-127 compliant" is
    >> TOTALLY different from saying that it "Meets the design
    >> goals of JSR-127".

    > I don't think so, but I agree that a proper selection of
    > wording would be better, since this is a really sensitive
    > topic as I've found out. I'll be more careful next time.

    > At the same time I insist that HyperQbs is fully
    > compliant with the current stage of JSR-127 .... which is
    > the definition of design goals and that we'll make sure
    > that HyperQbs complies with the JSR-127 specs as they
    > evolve. What's deceptive about it? Can you show me
    > another presentation framework that complies with the JSR-
    > 127 design goals today?

    I have to agree with the original poster here -- meeting design goals is far different from being compliant (which nobody can be since it is unreleased). If you are saying it is compliant then you should be able to say that the CURRENT version is compliant (e.g.: code that is written today meets the spec as is) once the unreleased standard is finalized, something which I don't think you can do (unless your implementation is being taken as is to be the standard, which I doubt).
  8. JSR-127 _TODAY_ is, as far as I can see (from the public's perspective), a set of about 10 bullet points briefly describing concepts and strategies it is destined to cover some day. To say that your product "pretty much covers those same design goals" may or may not be accurate, but I maintain that to claim "JSR-127 compliance" at this stage is intentionally misleading and deceptive, since there is nothing to be compliant with. It reads like a cheap marketing trick to hook and reel in IT managers who only vaguely understand the web app UI framework landscape.

    And to answer your question -- no, I cannot point to another web application framework which is JSR-127 compliant -- something which I don't believe anyone can legitimately claim at this absurdly early stage of the JSR-127 JCP process.
  9. just have a look at http://www.hyperqbs.org

    >and let us know - it's free :)

    Well I tried that, but the English language portion of the link sent me to http://www.flashline.com/components/view.jsp?prodid=3779&affiliateid=116013
    where it's listed as "Starting at: $3,145.00 USD"
  10. What is this about???

    Man I can't understand this anymore

    There are so many so called "frameworks" being
    advertised to me.

    More and more frameworks!!!!!

    It doesn't matter i'm stick to simple JSP:)

    Mohammed Firdaus
  11. In response to Mohammed and his skepticism toward frameworks &#8230; well, as I mentioned earlier - the bigger project, the bigger pain, the bigger need for a framework. The JSR 127 has a well-written advocation of this. A visual GUI component framework can save you from a number of repetitive and tedious programming tasks, which you can exchange with reusable GUI components. It let's you to do incremental development, teamwork, reusability, prototyping of server-side applications etc. Also maintenance of a fully component-based solution is much easier than digging in spaghetti code.

    The reason for so many frameworks being advertised to you is simple - those companies needed such framework for themselves and than they decided to share the fruits of their work with others. So the need in this type of projects was the driving force and this is, I think, unquestionable.

    I understand that the motivation behind JSR 127 was/is to standardize the so many different and partial approaches of different framework vendors and the design-goals are well thought-out and as a matter of fact HyperQbs meets them today. There are also other frameworks and its in their best interest to follow what the JSR127 does.

    JSP is a strong technology and I think that the visual GUI components just extend the whole J2EE infrastructure - so, you can carry on with your JSP programming and eventually add a GUI component etc.

    I believe that such a component framework could be very useful e.g. in web services.

    What do you think?

    -peter
  12. Peter, thanks for the replies. Good to know there's more to this than just another press release.

    I agree entirely that we badly need such a framework, and need a standard for it. I'd add that without a framework one still needs to implement much the same functionality, it just ends up spread throughout all the "normal" code.

    So I keenly await results from JSR 127. But given the current state of play I'm using my own tag library and supporting components in the meantime. Did look at some other products but they seemed too inappropriate/immature to bother learning and depending on. My view is that if we have to have a proprietary short-term solution, it might as well be under my own control and focused on our own needs. Didn't spot HyperQbs before and would be interested to try it, but as ever it's on a long list of "look at"s.

    Basically I see this as make do as best one can until JSR 127 gives us a proper standard.

    I'd be interested in how you think a JSR 127 "reference implementation" will affect products like HyperQbs.
  13. Mike,

    > I'd be interested in how you think a JSR 127 "reference
    > implementation" will affect products like HyperQbs.

    Well, good question - I'm not sure if my English language skills allow me to express exactly my thoughts, but I'll give it a try :) - my recent experience with the HyperQbs 2.1 announcement showed that a presentation framework is a very sensitive topic among developers. No surprise, a lot of people invested their energy and money into development of their own and very unique framework solution at the time when it was inappropriate to speak about a component base GUI framework for server-side applications. They just needed it to solve their own headaches. Surprisingly 1-2 years ago, people didn't understand this concept at all and we could find statements like "it&#8217;s impossible to reuse server-side GUI" and "uhhh? Presentation logic? It's bullshit! We have JSP" etc.

    This "underground" movement evolved into a number of different and partial framework solutions with everybody protecting his/her own baby. However, this current situation doesn't allow leveraging with off-the-shelf assembly tools, new reusable components and all the benefits that each individual framework could provide alone, but not all together if each one is different (simply not feasible to achieve).

    If component based business logic is standardized and you can move application among different application servers, what good does it make to you, if the presentation layer is made with an obscure framework? Do you have the right third-party tool and third party components? .. well, not today in the current "my baby" approach.

    Sun came in with JSR-127 at the right time (if not late) in order to clean this messy situation and thus eliminate the tension among developers. I expect all the different frameworks to start implementing the JSR's design goals and specs as soon as they become available (at least this is what we do with HyperQbs) or to give up. However, not many frameworks today can meet these design goals (e.g. Struts doesn't).

    I believe that "presentation logic" is a key piece of technology in order to make a step further and people should start getting themselves ready by carefully looking at the options now. E.g. a presentation logic framework is absolutely necessary for the new buzzword of Web Services - thus the next year will be in token of the "JSR-127" buzzword.

    I'd be very interested in the opinion of vendors of the other presentation logic frameworks.

    -peter
  14. No matter what you call or claim, saying you full support a spec is flat out false advertising. When the JSR is finalized, you could argue that I could use this initial statement to prove you did not full support the JSR, since it's most likely going to differ when released.

    Also, where in the world the English version of your site. I keep getting redirected to .cz

    Come on guys...
  15. No matter what you call or claim, saying you full support a spec is flat out false advertising. When the JSR is finalized, you could argue that I could use this initial statement to prove you did not full support the JSR, since it's most likely going to differ when released.

    Also, where in the world the English version of your site. I keep getting redirected to .cz

    Come on guys...