JBYTE Java-based Template Engine 1.0 Released

Discussions

News: JBYTE Java-based Template Engine 1.0 Released

  1. JavaBY Template Engine (JBYTE) is a template engine enforces separation of application logic from presentation logic. JBYTE is used mostly for generating HTML from servlets but it can also be used for generating XML, RTF, WML, e-mail text, source code and configuration files.

    Check out the JavaBY Template Engine (JBYTE).

    Threaded Messages (27)

  2. Related projects:

    http://jakarta.apache.org/velocity/

    http://www.webmacro.org/

    http://opensource.go.com/Tea/

    http://freemarker.sourceforge.net/

    http://tapestry.sourceforge.net/
  3. JBYTE is genuine template engine, which not contain a macro language definitions.
    However, Velosity, WebMacro, Freemarker is not template engines. It's macro languages embedded in HTML.
    So, if you want to use genuine template engine, your choice JBYTE.
    When you use JBYTE, you not need to know another macro language or programming language.
    You use Java for Model and Controller layer of MVC architecture and use pure HTML for View.
    That its all!

    I'm waiting for your comments and suggestions.
  4. Very minimalistic. Basically it is just regular expressions and simple looping. Not very genuine if you ask me. Best templating engine I have seen is CheetahTemplate (written in Python). Unfortunately it doesn't yet feel comfortable choice for Java templating. I think I'll stick with Velocity and SiteMesh.
  5. Only I can tell only one concerning to JBYTE. It is difficult to estimate his power and simplicity, not having tried to program on it.
  6. As far as I could tell (correct me if I'm wrong), there's no conditional processing, no arithmetic, no hierarchial data, only highly limited looping (dictated by the lack of an expression language), no number formatting, no string manipulation, not sorting, no grouping, ... Not to mention streamlined processing, modular scripts, support for functions, etc.
    Another problem that I can think of is the manual data feeding to the script. It's not very elegant or convinient to set the particular variables manually with Java code. Some sort of expression language for JavaBeans could be very usefull... of course, JSP standard taglibs allready offer that, and the issue does not exist when using XSLT assuming you use some automatic process to convert objects to XML (many such tools exist and are free).

    How can this solution measure up to XSLT+XML, JSP, or more mature scripting languages? Do you have any real-world examples?

    Gal
  7. Do you want to programm on Java without programming on it?
    Gm. :-)
  8. Heh... first of all, yes I would. I would like keep my code base relatively small so that is remains maintainable. Implementing the data feeding in a generic fashion seems like a good place where you can cut down on "manual labor" with hardly any implications on runtime performance.
    Second of all, I'd like my view developers to be able to write most of the view without knowing Java, so they don't have to bug me all the time. View developers are usually HTML design experts, not programmers. Using JSP taglibs and the JavaBeans expression language, view developers can access all the data they want, directly from the objects, using simple expressions. If they had to touch the Java code whenever they decide they need another piece of data in their script, they would bug me and call me up all the time...

    Besides, why do you only reply to this one point, when I made about a dosen others?

    Gal
  9. I think the point is that since JByte doesnt contain any conditional inclusion support, only very limited support for looping, and no support for i18n, the added benefit of using JByte compared to a homegrown servlet solution is minimal. Lets face it, you cant really claim to be the next logical step in web-development based on a product containing the staggering amount of 220 lines of java code.

    Br - Johan
  10. Support for i18n provided by pure Java API.
    My engine do only one task. It separate application logic from presentation logic.
  11. Yes, but I am wondering if the support for presentation logic is enough. How would your f ex create a page where a specific table, or table row, or table cell, should only be rendered if there is a certain set of data present in the database?

    Br - Johan
  12. Just try out Jbyte. Then you find answer on your question and more future questions.
  13. I guess that means that there is no way to do what I asked, short of bringing the presentation logic into the application logic.

    Br - Johan
  14. The thing I always liked about template engines such as these is they had the potential to be truely cross-platform in the scripting language sense. I've found template engines for PHP (Fast Templates, PHPLib's one, etc) and ASP (ASPTemplate) and I'm sure there are others. They all use the same (or similar) template files. You could write a web app in Java and fairly easily port it to PHP and ASP. That said, it seems XSL/XML (cocoon, stxx) is proving itself ready and more capable for this task.

    Don
  15. XML/XSL is a macro language.
    JBYTE is not a macro language.
    JBYTE is pure template engine.
    JBYTE and Java is enougth for building small and large MVC applications.

    That its all!
  16. How is XSLT a macro language? XSLT does not embed any type of "code" in it's templates. It has no procedural flow of control, and is driven by an expression language. XSLT is centered around the concept of a template, as even it syntax would indicate (<xsl:template> is the major top-level element).

    Whether or not JBTYE is enogth to build a specific application depends on the specific application's requirements. Can you please post a reply describing how can the operations mentioned by myself and others be implemented in JBYTE? If they can't, say they can't, and let the user choose whether or not JBYTE is enogth for his specific application.

    Gal
  17. Has XSLT no procedural flow of control?
    What is it?
    <xsl:for-each select="tutorial/enimals/dogs/dog" order-by="dogName">
    <xsl:if test="position() mod 2 = 0">
    "if", "for-each", "select", "order-by" and so on.
    All flow of control must do Java, but not template.

    The operations mentioned by yourself and others must be implemented by pure Java.
    Template must have only markup.
    My template engine has it.
  18. XSLT does not have a procedural control flow. You can't say when each part of the template will be processed - only that it will be processed, and the results will be placed in the correct order. That's why you can't do things like read/write variables.
    Of course, XSLT does have some sort of control structures to allow conditionals, looping, etc. This is a necessary part of the template engine. I obviously didn't mean to imply that XSLT does not support these things (if it didn't, it probably wouldn't be used at all).

    Does it seem right to you that the logic related to generating the view (such as deciding whether or not a certain table cell should appear, calculating the size of some element, etc) will have to be performed in Java code? Would you like your HTML designers to be forced to learn Java, or worse, come to you for every little piece of logic they need?

    Gal
  19. You do not understood.
    HTML designers don't need to learn Java. They only markup HTML by enclosed template tags and variables.
    Java developer use this markup for generating dynamic HTML. He retrieve data from Model and put its in View using Controller(for example Servlet).
    Controller have responsibilities to manage Model and View.
  20. First of all, what you are describing in not MVC architecture. In MVC-based architecture, the view renders the model for display. The controller is not involved in this. This is required in order to get reusable views and reusable controllers. Your suggestion ties the view and controller together by creating dependencies. If I wanted to use the same model components in a different application, I could not reuse my view, because it depends on the controller to manage it.

    As for this specific case, you did not address the issue I raised. Web designers do more than just code HTML. They decide how the page should look in different situations. For example, if the user has insufficient funds, a red warning will apear on top of the page. If the user has not logged-in yet, a log-in link will be displayed. These two *extremely simple* examples require conditional processing. In JBYTE, this processing will have to be done in Java, meaning that your average web designer won't be able to do it. So who does it? You, the developer. That's all I'm saying. Developers should be aware, before choosing JBYTE, that they will have to deal with every little piece of logic that the web-designer deems necessary. I for one would prefer to have some simple expression language that the designer can do most of his work with, and call me up only for the most sophisticated requirements.

    Gal
  21. I understand you.

    You want to work how you wish and are used to.

    And you not understand many things in my template engine because you did not use it in real work.
  22. Hi all!

    Alexey, don't worry, most of people develop his/her own template engines. So it's no problem. Please provide the
    something like "real-life" solution but not slogans. You now, developers are very conservative people.

    Best wishes,
    Eugene
  23. And you not understand many things in

    > my template engine because you did not
    > use it in real work.

    Come on, Alexey! You template engine isn't bad. I like simple things. However, if I compare it with Freemarker (a simple template engine), it lacks some important & useful features.

    This is not enough:

    <{abc
      ${def}
    abc}>

    That's an equivalent to Freemarker's <list> construct, fine to generate <table...> stuff.

    Check out Freemarker and extend JBYTE.

    Cheers,
    Andreas
  24. I check out Freemarker and will not extend JBYTE.
    List is a control flow structure.
    My engine not have control flow in HTML.
    All control flow must be implemented in Java class or Java servlet.
  25. And other one.
    See JBYTE tutorial
  26. As far as I see you have variable substitution plus some equivalent of a
    Freemarker List.
  27. According to the java-doc this is no "engine". It simply replaces one string (key) with another(value). but now the java.lang.String.replace() methods (jdk1.4) are available, and i think, the function of JBYTE one can be rebuild on half an hour by any java programmer.

    corban
  28. We have looked at the same problem as you are addressing and have build a solution using XML Components. In our view, the task of building and maintaining web content is very similar to the task of building and maintaining executable software - such as Java programs. We have taken some of the solutions developed for software engineering - such as class inheritance, and applied the idea to XML content. Our solution - XML Components is described in this white paper. I'd welcome any comments on this. Docland XML Engine .

    The Docland XML Engine assembles web pages from reusable components at run time. This enables servlet developers to concentrate on the delivering the dynamic content of web pages, and off-load to orhers the task of generating the finaliszed presentation. An additional advantage of this process is that the work of generating finalized presentations can be delegated to separate caching front-end processors, or even to the client machines.