Tag Interface Component Library (TICL) 1.0b Available

Discussions

News: Tag Interface Component Library (TICL) 1.0b Available

  1. Kobrix has announced the immediate availability of TICL (Tag Interface Component Library) 1.0 Beta. TICL is library of server-side user interface components accessible through JSP tags. Like a conventional desktop toolkit, the components maintain state and manage interaction logic with the end-user with little or no assistance from the programmer.

    Read more about TICL at http://www.kobrix.com/ticl/ticlmain.jsp.

    More info
    ---------------------
    One of the major goals of TICL is to bring RAD-like development to the WEB platform. Programmers can concentrate on logical functionality and build JSP
    pages by placing TICL components through tags and responding to user events. Every component is self-contained and manages interaction with the end-user. Visual appearance of components is abstracted into a high-level styles framework.

    The library is tailored more towards WEB application development, rather than content only oriented sites. It is designed to quickly build clean, robust, well-structured and therefore highly maintainable code. It integrates seemlessly into existing JSP applications and it will work on any standard compliant JSP 1.1 container (e.g. Tomcat, Resin) and with fairly recent versions of the popular browsers.

    Core features are:

    - A powerful and extensible server-side event model. Component-end user interaction is encapsulated into a well defined set of server-side events. You can of course define event listeners, develop custom events, event filters etc.

    - Predefined components like panels, tabbed panels, tree views, DHTML menus, table views. Most can perform their interaction with the end-user at the browser through DHTML or by making a trip back to server on every user action (like expanding a tree node or minimizing a panel).

    - Smart browser handling. A complete framework for dealing with browser (user agent) capabilities, including detection of dynamic properties like connection speed, screen resolution, available plugins etc.; supporting JSP tags; on the fly selection of component rendering based on the current user agent.

    - A high-level styles framework for complete customization of the look&feel of components. Styles can be organized into themes. An inheritence mechanism of style objects provides for a powerful high-level structuring. The framework allows for a clean separation between look&feel and functional
    behaviour of GUI elements. No more copy&paste, no more code cluttering with tedious, browser-specific HTML details - consistency of look&feel can be easily achieved by maintaining a single TICL style sheet, a simple XML file, that is applied to all pages in your WEB application.

    - Full encapsulation of HTML forms, including a file upload component, augmented with things such as server-side command handlers, labels and DHTML tooltips. Form fields are typed, true server-side components. Not limited to the standard HTML form fields, they operate on a high level and custom ones can be developed and plugged into the framework.

    - A very powerful and easy to use declarative form validation mechanism (both client and server-side). You define validation rules and handlers for invalid forms in a clean, declarative way. The same rules you define can be applied at the client (through automatic generation of the necessary JavaScript) or at the server. Special purpose syntax allows you to easily handle interdependencies between field values.

    - A Data Objects framework integrated with TICL forms. Allows you to manipulate complex aggregate structures and associate them with forms for automatic mapping to/from form field values and data object fields (e.g. Java beans). A type mapping framework allows you to map any form field type to any Java type.

    - An integration module for the popular Struts framework is provided also. For example, it is now possible to use the powerful TICL form tags with Struts' ActionForms.

    TICL is FREE for non-commercial and non-govermental use. It comes with an extensive, over 200 pages, Reference Manual. To download it, please goto http://www.kobrix.com and select Downloads from the TICL pulldown menu. If you are not already a TICL user, you may need to register first.

    We sincerely hope you will enjoy TICL and are looking forward to your feedback!

    The Kobrix Team.

    Threaded Messages (18)

  2. We (in Altoprofilo spa, Italy) have used a pre-beta version of TICL for internal evaluation, developing a sample catalog management interface, and I must say I was impressed by what I've seen.

    Although the model suggested by the framework is different by the one that is prevalent today (mvc), the architecture TICL is based on is very clean and well thought: even if we have not used its more advanced tasks TICL has given us a lot helping us building a user interface in a very short period of time, while having a system graphically very flexible and well-decoupled (html from javascript from java code from tag libraries from configuration...).

    I'm afraid the pricing model will limit the diffusion of this system, I would have liked to see something like it in the open source, but I really do think that TICL can give a very big value to a project: of course the shared source model is preferable than a closed source one. Anyway, the documentation is good, and the support very responsive (see the forums: every problem I've had has been fixed in hours).

    Moreover it seems kobrix has build a part of their site which encourages the sharing of style sheets and other artifacts, which is good: the only thing I miss are clear guidelines about how to create TICL extensions (but I haven't dig very deeply into this part of the docs).

    Well, I've loved this system, and I think it's one more valid answer to .net fans questions such as "do you have... in jsp?": we do have TICL, we will have java server faces implementations, we do have Struts, Webwork, JSOS and coldtags, opensymphony, ...

    Definitely, we do have a great community.
  3. Hi Davide,

    Thanks for the kind comments! We're currently working on the "shared source" license agreement and I think it will be quite permissible in terms of what you can do with the source (not like MS's one ;).

    We will be posting tutorials and howtos in the new DevShare section of the site, in particular examples of creating new components. That's one of the reasons we created it - it's a good and relatively easy way to get information out.
  4. I just tried the examples at the TICL site. The Tabbed Pane example works, but causes all kinds of refresh activity, with lots of intermittent refresh artifacts. The Tree example didn't work at all.

    HTML simply is not adequate for serious user interfaces, regardless of how interesting the concepts behind this product might be.

    A better approach would be to have a generic interface applet, and have the JSPs send it interface descriptors (preferably in XML) that it can interpret and display. Then it can POST user entries back to the server.

    I've done that; it is not a commercial product. See the Java applet and application interfaces at:
    http://uncled.ais.unc.edu/DVMPortfolio/Portfolio.html
  5. David,

    We will appreciate it a lot if you could report the problems we are having with the treeview example on the online forums at http://www.kobrix.com. This has been tested with pretty old browsers like NS4 and IE4, and with Opera as well.

    Switching to a different tab item in a TabbedPane will trigger a server-side event and refresh the page when manageOn="server". If manageOn="client", items are switched through DHTML and there's no refresh.
  6. Uhm... what browser did you test the page against? I just tried both with MSIE 6 and Mozilla 1.0 RC2 and it works pretty smoothly. I believe there is a list of browsers officially supported, somewhere on their site: TICL offers a dynamic component for browser recognition, but you may have tried the pages with an unsupported one.

    As for "html simply is not adequate": it is just adequate enough for a lot of applications, and pretty often, in my experience, it is mandated by the customer. The "generic interface applet" may be well-suited for a lot of situations, such as the ones where the customer is interested both in a functional user interface and in a strong web-centric user experience.

    We often have to work with customers that choose two different companies for the production of the interface and production of the back end, and this separation often causes workflow problems: I have experienced a better interaction with the html developers I've worked with, thanks to TICL. Of course, mine is a very limited "direct" experience with TICL, but I think I'll push the choice over TICL for future projects, when TICL will become stable and mature because I believe it is promising.

    Regarding wingS: I gave a look at it some time ago, and seemed a great product, too. Nevertheless it seemed to me it was more suited for the production of "a" web interface for an application, rather than dynamicizing "the" web interface that someone else (html team, web design external company, intermediate artifacts in photoshop, ...) has produced. Am I wrong? In this case I'll fly on the site downloading wingS ( :) ). Anyway, TICL seems to me just perfect for this last kind of things.
  7. Hello David Moffat, I didn't know what is the application in your portfolio page. What is the application, please?
    I would want try this application.

    Tks

    PS: Excuse-me, I don´t speak english very well. I´m brazilian.
  8. Uhm... what browser did you test the page against? I just tried both with MSIE 6 and Mozilla 1.0 RC2 and it works pretty smoothly. I believe there is a list of browsers officially supported, somewhere on their site: TICL offers a dynamic component for browser recognition, but you may have tried the pages with an unsupported one.

    As for "html simply is not adequate": it is just adequate enough for a lot of applications, and pretty often, in my experience, it is mandated by the customer. The "generic interface applet" may be well-suited for a lot of situations, such as the ones where the customer is interested both in a functional user interface and in a strong web-centric user experience.

    We often have to work with customers that choose two different companies for the production of the interface and production of the back end, and this separation often causes workflow problems: I have experienced a better interaction with the html developers I've worked with, thanks to TICL. Of course, mine is a very limited "direct" experience with TICL, but I think I'll push the choice over TICL for future projects, when TICL will become stable and mature because I believe it is promising.

    Regarding wingS: I gave a look at it some time ago, and seemed a great product, too. Nevertheless it seemed to me it was more suited for the production of "a" web interface for an application, rather than dynamicizing "the" web interface that someone else (html team, web design external company, intermediate artifacts in photoshop, ...) has produced. Am I wrong? In this case I'll fly on the site downloading wingS ( :) ). Anyway, TICL seems to me just perfect for this last kind of things.
  9. If you need an LGPL-ed alternative, have a look at:

       wingS

    wingS features in short:

    o Swing like component model
    o highlevel components like STree, STable, STabbedPane, SMenu, SDesktop, SInternalFrame
    o uses Swing models and Swing events
    o pluggable look and feel (even WML is possible)
    o template layout manager, that incorporates wingS components in plain html files (no proprietary elements)
    o reload management framesets (only dirty frames are fetched from the server)
    o mature and stable

    Holger Engels
  10. wingS: Great stuff!
  11. your kidding right... PMGO for you
  12. These are really cool ideas! Unfortunately, browsers are meant for browsing, and HTML is a display notation.

    If I create an "application" with Wings or TICL, how do I specifically integrate and control the browser's own interface? What does pressing the Back button mean? Can I open 10 pages to the same application? What is the meaning of a bookmark into the middle of the application? How does the application handle resizing? Can I open the same page in 5 different windows? And enter data into all of them? Why make your user wait for page refreshes?

    You and your clients could have all the benefits of web delivery, network interaction, and automatic updates if you use Java Web Start. You should present that requirement to your clients up front. If your applications are desirable, people will make the (small) extra effort. In fact, JWS only adds to the value of your application. People buy new computers, or upgrade, just to accommodate software they want. They don't get a computer to see what kind of lowest common denominator software will flock to it.

    HTML-based "applications" are lowest common denominator applications. Why work today to deliver yesterday's applications tomorrow?
  13. Why work today to deliver yesterday's applications tomorrow?
    ----

    Yes! Now all we have to do is convince everybody who thinks otherwise... [sigh].

    God bless,
    -Toby Reyelts
  14. These are really cool ideas! Unfortunately, browsers are >meant for browsing, and HTML is a display notation.

    Interesting idea. Html is a display notation, of course, but HTTP is a protocol often used for transporting RPC, javascript is a scripting language that can be used to build complex user interfaces, validation rules, dynamic interactions; web-based interfaces often prove to be more usable than traditional ones...

    >If I create an "application" with Wings or TICL, how do I >specifically integrate and control the browser's own >interface? What does pressing the Back button mean? Can I >open 10 pages to the same application? What is the meaning >of a bookmark into the middle of the application? How does >the application handle resizing? Can I open the same page >in 5 different windows? And enter data into all of them?
    Mmmmh, you must come out of a university where they taught you what are the *bad sins* of the web interfaces: I respect your worries, but it happens that most of the times, the issues you are presenting are simply uninteresting and do not pose problems at all. "What does pressing the back button mean"? Who cares: if you are really interested in building a usable interface in html you can do it: in the meanwhile we often have to build web interfaces in a very short period of time, and find tools such as TICL very useful. I leave you with your interesting considerations regarding java web start: you may maybe contact companies such as macromedia or bea, asking them why the interfaces of the management tools for their application servers are served through web applications.

    Someone should probably be fired, at bea, in version 5.1 of
    weblogic they had a lot of wonderful awt standalone apps to build the applications, deploy them, monitor the app.server, do hot deploy: how comes they have proven to be so stupid building that lame weblogic 6 web console? I hope you will be able to sleep with this incredible thought: in the meanwhile I use the weblogic interface, being very happy of the changes since version 5...

    > Why make your user wait for page refreshes?
    Why? Maybe because web interfaces have proven to be usable even with refreshes, and in many situations they are simply well suited for the needs of the project?

    >HTML-based "applications" are lowest common denominator >applications. Why work today to deliver yesterday's >applications tomorrow?
    There are a lot of reasons to do that: you don't have to always build innovation, you sometimes are asked to build a web interface to a DB because the customer has a few ideas that he is absolutely unwilling to abandon, and not enough money to experiment with technologies he/she doesn't know or understand.

    For the future, we will probably be able to leverage more ways of building web interfaces: flash, curl, technologies like that ones (much more than insisting with applets or surrogate technologies). Today, a lot of peoples are still building web applications with html interfaces, and being "revolutionary" at all costs is simply off-topic, with respect to the issues of building html interfaces for web applications.
  15. <quote>
    Someone should probably be fired, at bea, in version 5.1 of weblogic they had a lot of wonderful awt standalone apps to build the applications, deploy them, monitor the app.server, do hot deploy
    </quote>

    You might want to check out WebLogic Builder, which is part of WebLogic Server 7.

    --
    Cedric

  16. TICL[ Go to top ]

    Just downloaded and tried the product. The features are nice and well thought out. One criticism is that the library dominates your Presentation Layer design. I mean, a tag library should be complimentary to your UI design, not the focus of it. Although Struts has tag libraries, they are convenience things. The design of Struts is MVC, not tags.

    They also have to work on the pricing model. It's hard to justify spending thousands on this tag library. Especially with Jakarta's libraries and JSTL coming right around the corner. It's really just a cost/benefit thing.


  17. TICL[ Go to top ]

    Hi Stan,

    I am glad you liked TICL's features, and I would like to respond to your criticism. One of the main goals in TICL's architecture (probably the main one) was to simplify UI development, without enforcing any particular UI design. That is why we have gone at length to allow the customization of component rendering at several levels. I don't quite understand what you mean by "dominates" the presentation layer. TICL IS a UI library, and it deals with _user interface_ development almost exclusively. It is therefore only natural that you use it in the so called presentation layer. TICL's tags are no more the focus of UI design than the openGL library is the focus of a, say, 3D modeling program. In other words, UI is the focus of TICL not the other way around. Also, bear in mind that TICL is a library of Java server-side UI components and a web development framework, not strictly a "tag library". The tags are really a programming interface to the components. You can use all those components directly from a servlet, it's just more work and less elegant.

    Regarding jakarta, JSTL i similar taglibs - their scope is quite different than TICL's. They are more of a collection of utilities helping avoid Java code in JSPs. JSTL can be a true time saver, especially due to the expression language, but again the scopes do not even overlap.

    Regarding Struts - it is essentially a controller architecture where MVC is applied at the application level. TICL is MVC too, but the pattern is applied to individual components, more like Swing, with components managing interaction state and functionality, models managing the data associated with a component and renderers handling HTML output. In fact, TICL can be used with Struts (including TICL's form tags, an integration achieved without even modifying TICL) so they can be quite complementary. And, by the way, try using Struts ActionForms without the "convenience" form tags...

    A side, "philosophical" note: The point of TICL is that it lets you write much shorter and cleaner code, by providing true UI component, self-contained functionality. Virtually all toolkits aiming to simplify web development start from questions such as who is doing what, how is labor divided, how are the artifacts produced by various people put together etc. The architecture of TICL is based somewhat on the premise that there are essentially three development roles: the business logic programmer, the UI programmer and the graphic/UI designer. Note that this is different than the mainstream twofold division of front-end/back-end developers. The front-end is seldom merely "presentation". When writing a truly interactive web application, it involves quite a bit of programming. And that programming, whether we like it or not, traditionally ends up in JSP pages, written by guys who were supposed to draw nice pictures and choose fonts and colors only. To make the long story short, in TICL's view, the JSP writer is a programmer, maybe not a proficient one, but a UI programmer dealing with the functional aspect of the user interface (the UI logic) while web designers work mostly on CSSs and the high-level TICL styles. True, TICL won't help you create fancy web designs, but it will save you a lot of time creating an interactive web-based UI.

    Lastly, the pricing of TICL was more or less determined by what we would have paid before we ended up developing it (because something like it was nowhere to be found). We believe that if it saves even a single developer at least two days of work on a project, the price is already justified. Note that the price is "per server", it will cost in the thousands only for a quite large web farm. Not to mention time savings resulting from the much shorter, cleaner and maintainable code. It has already saved us huge amounts of development time. Maybe because we know it well, but still.

    Well, sorry for the long post. I only hope it clarified things a bit.

    Cheers,
    Boris
  18. TICL[ Go to top ]

    Hi, Boris

    You guys are doing a great job, because it's a dream of many
    programmers to releive themselfs from writing this unmaintable two-browser HTML/JS mix. I completely agree that standalone Java applications delivered via Java Web Start despite of all their greateness are overkill and luxury we can't afford in many projects (like need to deliver 10-screen wizard in two days). But on the other hand, every attempt to provide anything beyond dumb go-to the-server-and-completely-repaint-on-any-user-action in my experience always ends up with JS errors or even browser crashes. And unfortunately (realy :-() you web site is no exception. Excited enought I was about to download trial version. Kobrix web site looks veri nice and I assume it's built on TICL. But silly me - I swithed to Netscape 4.79 from IE and... User settings form was comletely screwed: field are positioned over the labels, tooltips are hidden beyond text boxes and radio buttons did not appear at all. Thats a grim reality. We are all still victims of that (past?) browser war. And 300 bucks is reasonable price (at least for me) if thing would only work. Until then I will continue to use my dumb "least common denominator" toolset
    and listen to customer's complains about poore UI.
    Again, you are doing a good, much needed job!

  19. TICL[ Go to top ]

    Andrei,

    Thanks for the nice comments! It is the HTML/JS/Java mess that prompted the development of TICL in the first place. Define components functionally, and get the HTML/JS, browser-specific stuff out of the way...

    Yes the site was build with TICL, of course ;). We are aware of the NS4 problem and the site will be updated in the next couple of days. This is purely a rendering issue, overlooked because of the rush to get beta out - TICL's forms renderer is broken with NS4, the problem is currently being worked on. And I must note, still in the promotional tone ;), the fix is in a single place due to the styling/rendering framework in TICL.

    Boris