New Article "XMLC vs JSP" Posted on TheServerSide

Discussions

News: New Article "XMLC vs JSP" Posted on TheServerSide

Bookmark and Share Get thread feed

  1. New Article "XMLC vs JSP" Posted on TheServerSide (46 messages)

    • Posted by: Nate Borg
    • Posted on: May 01 2002 09:03 EDT
    This article does a comparative study of JavaServer Pages and Enhydra XMLC. After reviewing JSP, JSP Tag Libraries and XMLC, this article looks at a real world scenario on the use of push versus pull, then speculates on an assessment of how well these two strategies address Web application development today.

    Read Article Here
    Reply to this

    Threaded Messages (46)

  2. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    i think it's better to educate designers to the level where they can deal with tags, and simple objects. seems to me, that XMLC builds too much knowledge about the design into the actual java code...

    eg. using XMLC, how would you build a table where BGCOLORs are different for every other line, without putting some knowledge about this into the java code? (btw, i never used XMLC :)
    Reply to this Reply to original

  3. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    As someone who started doing Java web application in XMLC, it led to to great presentation lock in. It is a lot of work to create very dynamic pages. Also, at least when I used it, there was a very wierd, non-intuitive, way of creating tables when the the row count is dynamic. Hard code a template row, duplicate in when executing, modify the duplicated row, repeat until all rows are there, then delete the template row.

    It all just seemed way to complicated, and I go into convultions each time I have to maintain that code. I can see where it may work fine for certain types of sites, but it didn't really fit the type of project I used for it. I am glad JSP has come along a lot since then.

    -Pete
    Reply to this Reply to original

  4. Obnoxious Plug: Tapestry[ Go to top ]

    Tapestry is built around a workflow that starts with a graphic designer using Photoshop, continues with an HTML producer (potentially the same person) who produces HTML, stylesheets an images, and ends with a Java developer who "instruments" the HTML to produce the final result.

    Part of Tapestry's desirability is that the HTML template (the instrumented final result) can be updated by the HTML producer without break it, and it still previews properly inside a WYSIWYG editor. In fact, I borrowed ideas from Barracuda to accomplish this!

    Unlike JSPs, Tapestry instrumentation takes the form of additional <span> tags and the addition of a jwcid attribute ("jwc" = "Java Web Component"). That's all that changes in the HTML template, the rest of the dynamic behavior is defined in a seperate component specification.

    http://sf.net/projects/tapestry

    Reply to this Reply to original

  5. Obnoxious Plug: Tapestry[ Go to top ]

    With a typical amount of hand waving, this is what the HTML template would look like in Tapestry:

    <html>
    <body bgcolor="white">
    <table border=2 cellspacing=3 cellpadding=3>
    <tr jwcid="loop">
    <td><aa jwcid="link"><span jwcid="insertName">Department Name</span></aa>
    </td>
    </tr>
    </table>
    </body>
    </html>

    (In real life, the "aa" element would be a "a", but TheServerSide's message board prevents posting "invalid links").


    Tapestry goes to great lengths to minimize impact on the HTML template. The presence of a "jwcid" attribute marks an element as a placeholder for a component ... the component is responsible for rendering the opening and closing tags as well as any content. As you can see, Tapestry components nest in the same way as HTML or JSP tags (unlike JSP tags, a component may have its own HTML template).

    Tapestry is flexible in other ways ... the <span> tag will be completely replaced by the department name at runtime; the <span> tag, as well as the sample text (useful when previewing the page in a WYSIWYG editor) are all replaced by the name of the department.

    A bit more would go inside a Tapestry component specififcation (an XML file that defines the type of component, as well as the type and configuration of embedded components) and there would be a small amount of Java code (a listener method that would be executed when the link was clicked).
    Reply to this Reply to original

  6. Obnoxious Plug: Tapestry[ Go to top ]

    Howard,

      Thankyou for the lucid examples, if only the rest will follow.


    regards,
    nn



    Reply to this Reply to original

  7. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Exactly. The "push" approaches, such as XMLC, simplify Web page coding (HTML, XHTML, etc.), but increase the amount of Java coding, specially for pages with lots of data entry fields and/or dynamic data sources.
    This leads to a high degree of coupling between web pages and the corresponding Java classes.
    Personally, I much prefer a "pull" approach, where you keep all presentation-related code in the web page, in the form of markup (HTML/XTHML/WML for UI elements, and JSP tags for control and data binding - with no scriplets!), and data- and business-related code in Java beans and/or XML documents. This can be achieved with JSP 1.2, but unfortunatelly, no Web app framework to date (that I know of) seems to satisfy these requirements.
    Reply to this Reply to original

  8. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Tapestry is built, from the ground up, to satisfy these sorts of requirements. It's based on my long term experiences developing web applications -- including the need to seperate the work of the "pixel grinders" (graphic designers) and "code jockeys" (Java coders).

    Tapestry uses a pull architecture built around properties (or property paths). In some cases (such as looping operations, and form related components) components will push data back into domain objects.

    Tapestry is all about minimizing the amount of Java code. All Java code is written in an IDE, like XMLC, there is no option to "emed" (i.e, "corrupt") HTML templates with Java code.

    Most of the code you write in Tapestry takes the form of short "listener methods"; methods invoked when a link is clicked or a form submitted.

    "Less code == good"

    http://sf.net/projects/tapestry


    Reply to this Reply to original

  9. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hey Howard - I'm pretty sure this is a thread for JSP vs. XMLC . Can you move your Tapestry posts to a new thread, rather than taking over every new presentation related post.

    Thanks.
    Reply to this Reply to original

  10. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Howdy,

    "Less code == good" (From above)

    I don't necessarily agree. Less code is really nice, but performance (for us) is most important. I'd rather do a bit more coding / configuration / whatever and get a really fast framework.

    There's another suggestion above to
    "so you use Barracuda framework that provides Swing style MVC component model that maps to XMLC generated DOM tree.
    Then you simply use handy things like BTable and BList."

    Seems like very high overhead, low performance if you have to serve a lot of big, frequently changing pages to many users. I'd be interested in end-user performance comparisons for a benchmark site using XMLC, Tapestry, Barracuda, etc...

    Yoav Shapira
    Reply to this Reply to original

  11. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hello Yoav,

    XMLC achieves JSP-level performance through its "lazyDOM" feature. LazyDOM is Mark Diekhan's approach to the problem of the Xerces DOM always being entirely instantiated, even those areas that are not necessarily targeted for dynamic content. As a subclass of the Xerces class, LazyDOM creates a "read only" DOM tree. Only those elements that are tagged with an id attribute are instantiated and all changes made to those portions of the tree are tracked in parallel to the read only tree. When writeDOM is called to transform the tree back to markup, the changed portions of the tree are inserted into the stream.

    Having said all of that, we've found that for highly
    dynamic pages, you might as well stick with the xerces
    DOM.

    David
    Reply to this Reply to original

  12. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    I don't think any solution that attempts to automate HTML output (ie - methods for TR, TD, H1, etc.) really takes into account the (oft-occurring) real world requirements of pixel-perfect look-and-feel and the real world limitations imposed by a fragmented output environment (browsers). I'd much rather have to sneak a little Java into my JSP than have HTML buried in jar files. I don't know of any serious web-designer who can't work without a WYSIWIG editor. On the flip-side, IMO any seasoned Java/web devloper should be able to handle changes other than major aesthetics at the HTML/JavaScript level. In a messy, uncontrolled output environment like the web, I give the nod to experienced developers over automated tools--at least for now.
    Reply to this Reply to original

  13. New Article 'XMLC vs JSP' Posted on TheServerSide[ Go to top ]

    I think what we really lack in JSP today is a well designed tag language, which avoids the typical problems cited against JSP, while allowing complex web apps with a minimal amount of code (including HTML, JavaScript, Java, and XML). And with a JSP 1.2 web container, such tag library could also prevent the use of scriplets in the JSP pages (JSTL 1.0 RI already defines a JSP 1.2 validator for that).

    For example, consider the following alternative to the example in the article, including the JSP page (view) and a backing Java bean (model):

    - organization.jsp -----------------------------------
    <%@ taglib uri="parsec" prefix="pc" %>
    <pc:page class="Organization">
    <html>
    <body bgcolor="white">
    <table border=2 cellspacing=3 cellpadding=3>
    <pc:iteration values="${departmentNames}">
    <tr>
    <td><pc:link value="${current}">
      <pc:param name="deptName" value="${current}"/>
      <aa href="list.jsp">Engineering</aa>
    </pc:link></td>
    </tr>
    </pc:iteration>
    </table>
    </body>
    </html>
    </pc:page>

    (Note: aa=a; the TSS won't accept an invalid link.)

    - Organization.java ------------------------------
    public class Organization extends PageBean {
      public String[] getDepartmentNames() { ... }
    }
    --------------------------------------------------

    That would be it. No extra Java code, no extra XML configuration. Of course, the page writer would have to learn about the JSP tags. But note that the JSP page above can still be previewed in a browser, or in an HTML tool, such as HomeSite.
    Reply to this Reply to original

  14. New Article 'XMLC vs JSP' Posted on TheServerSide[ Go to top ]

    Hey Rogerio,

    Your example looks very like ASP.NET

    coincidence? :)
    Reply to this Reply to original

  15. Remember JSTL (was: New Article 'XMLC vs JSP' )[ Go to top ]

    Much of the criticisms of JSP is based on the use of scriptlets and the lack of standard JSP tag libraries.

    We now have a standard tag library, the JSTL (the JSP Standard Tag Library)

    http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html

    Currently JSTL supports XML, XSLT and XPath as well as i18n, SQL and common looping, branching, working with URLs and so forth.

    JSTL comes with an Expression Language for working easily with java beans, properties, collections, maps, arrays in a powerful and simple yet safe way without using scriptlets.

    So using JSP with JSTL we now have a simple, standard tag library approach to making JSP pages that avoids all of the past problems. There's no need for scriptlets any more and JSTL rocks!

    Reply to this Reply to original

  16. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    In most cases when you use this push model, XMLC compiled DOM representation is very low interface to work with,
    so you use Barracuda framework that provides Swing style MVC component model that maps to XMLC generated DOM tree.
    Then you simply use handy things like BTable and BList.
    I personally prefer Barracuda and XMLC because of clear separation of presentation markup and content: Designers need only to write HTML skeletons and don't need to know anything else.
    In my practise most designers are bad programmers and vise versa. Person that works with JSP is considered to be a designer and a programmer at the same time. Maintenance of hundreds of JSPs is somewhat more cumbersome that maintenance of a set of HTML skeletons and separate Java code.
    However JSP is more document centric while XMLC is more application centric and Barracuda is more GUI centric.
    Being programmer and not page author I prefer to use Barracuda component model instead of JSP in most cases.
    But, as always, there is no silver bullet..

    Though a little biased these are worth to read:
    Barracuda vs Struts
    and
    Surveying the Landscape



    Reply to this Reply to original

  17. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    The following code excerpt is from an example in the Barracuda web site:

    http://barracuda.enhydra.org/cvs_source/Barracuda/docs/comp/tutorial_hello_world2.html

    <ul>
      <li class="Dir::Iterate_Start.Groceries Dir::Iterate_Next.Groceries">
        <span class="Dir::Get_Data.Groceries.Qty">3 cans</span>&nbsp;
        <span class="Dir::Get_Data.Groceries.Item">Corn</span>
      </li>
    </ul>

    (I removed the extra mockup data, to make it simpler.)

    Technically, this is pure HTML, but in reality there is a sub-language embedded in "class" attributes. IMO, using an appropriate JSP language (tag library) here would be cleaner and more readable, as well as more consistent with the spirit of XML. For example, it could be written like this:

    <ul>
    <xx:iteration values="${groceries}">
      <li>
        <xx:expr value="${qty}">3 cans</xx:expr>&nbsp;
        <xx:expr value="${item}">Corn</xx:expr>
      </li>
    </xx:iteration>
    </ul>

    I think this shows that the real problem with JSP is not that it's inherently bad, but that it has not been used properly. The real issue is one of language design, not of approach (pull X push), or implementation.
    Reply to this Reply to original

  18. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    We are using a custom combination of Struts and Barracuda with great success. Struts handles the model and controller and we use Barracuda's component/templating model to handle the presentation. Barracuda is build on top of XMLC so we never have to program to the low level XMLC APIs.

    The HTML designers love it because they can have total control over the HTML. Our developers love it because they rarely have to touch the HTML. The only time the developers have touch the HTML is to put the Barracuda directive in the class attribute of the markup that needs dynamic data. For example:

    <span class="Dir::Get_Data.User.FirstName">Steve</a>

    Steve
    Reply to this Reply to original

  19. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    A great article about XMLC! I also prefer to use XMLC instead of JSP because of these XMLC's capabilities:

    1. With XMLC it is possible to show the storyboard to your customers without any functionalities -> Prototyping.

    2. In my open source project OpenUSS (http://openuss.sourceforge.net) - thanks to XMLC - it is possible to make a totally new look&feel of OpenUSS without using any Java developers (http://openuss.sourceforge.net/openuss/referenceimpl.html)
    The idea of just putting standard HTML tags in all the html files is really great.

    3. Working with XML within the java files is also really easy. Using Barracuda makes the stuff much more easier. I'll upgrade OpenUSS with Barracuda as soon as possible ;-) I already looked at other template languages like Velocity or WebMarker, etc. But none of them can handle the whole stuffs as elegant as XMLC.

    Once you try XMLC, you will never want to go back to JSP ;-)

    Regards,
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
    Reply to this Reply to original

  20. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    True, that it is even with JSP tags very hard to really avoid completely the intermingling of the business logic with the presentation generation. Therefore I can highly recommend an article published on O'Reilly Network:
    Accelerating JSP Tag Development with Jakarta Velocity, which describes who to use Velocity templates from withing custom JSP tags to overcome this problem.

    Greetings,
    Niko
    Reply to this Reply to original

  21. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Well, ..... no.
    XMLC forces Java developers to take control of the presentation layer by deciding mechanisms on how many
    rows needs to be displayed in the Servlet code itself.

    With a simple JSP tag, the HTML designers take instead
    control of it - as it should be - and there is no need
    for the java developer to worry about it.

    Frameworks exist that implement these tags already and
    it is a breeze to make them available into the standard
    tool used by the web developers - say Allaire.
    We did just that in one of my last projects , complete
    with testing environment to run the tags [using tomcat].

    JSP is much more mature than XMLC currently:
    1. It is a standard
    2. Loads of effort is going in defining it
    3. There are frameworks supporting various features including navigation, validation, templating and
    personalization - features that XMLC is at best
    in trouble supporting them

    Also, a bit of confusion in your terminolgy, both JSP and XMLC are really pull as both need
    a request from a client to a servlet controller to
    work!!!!! [and the servlet controller pushes content
    to the client in both models]


    So, in a gist JSP is so much better than XMLC for proper
    design at this point in time.

    All tha best,
    Max
    Reply to this Reply to original

  22. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Some comments:

    > With a simple JSP tag, the HTML designers take instead
    > control of it - as it should be - and there is no need
    > for the java developer to worry about it.
    I just wonder, how many HTML designers can understand Java code... At least not what I've seen until now ;-) And this is a big advantage of XMLC.

    > JSP is much more mature than XMLC currently:
    > 1. It is a standard
    Maybe the people from XMLC should propose XMLC for a JSR. At least XMLC uses different kind of technique than JSP (push instead of pull). For me: Open Source == Standard.

    > 2. Loads of effort is going in defining it
    I think, this is a pitty, because people just don't want to try something different. But don't forget there is also a huge community for XMLC and Barracuda.
     
    > 3. There are frameworks supporting various features
    > including navigation, validation, templating and
    > personalization - features that XMLC is at best
    > in trouble supporting them
    Just look at Barracuda for this, you will be surprised ;-)

    > Also, a bit of confusion in your terminolgy, both
    > JSP and XMLC are really pull as both need
    > a request from a client to a servlet controller to
    > work!!!!! [and the servlet controller pushes content
    > to the client in both models]
    The terminology pull and push should be understood like
    this:
    - JSP file with TagLibs (View) "pulls" the "data to show"
      from the servlet (Model). So the JSP file (View) actually
      determines which data to show.
    - The servlet (Model) "pushes" the "data to show" to
      the compiled HTML file (View) - Java DOM file - with XMLC.
      So the servlet (Model) determines which data to show.
    The iteration example above shows this difference clearly.
    (https://theserverside.com/home/thread.jsp?thread_id=13272#47324)

    > So using JSP with JSTL we now have a simple, standard tag
    > library approach to making JSP pages that avoids all of the
    > past problems. There's no need for scriptlets any more and
    > JSTL rocks!
    The problem with JSP files is that you cannot use those files as a storyboard, thanks to TagLibs, which are not standard HTML tags. Or maybe this has changed already? Is there any web browsers able to show JSP files like HTML files, as if all the TagLibs were not there, so I can just use them as a storyboard (prototyping)?
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
    Reply to this Reply to original

  23. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hello Lofi,

    re: JSRs and XMLC... Barracuda is already represented
    on the java faces JSR-127. Given its basis in XMLC,
    XMLC is indirectly represented in the JCP process,
    though I'd like to see it elevated in some way.

    Also, Sun have updated the SunOne document in Chapter
    8 "Presentations" to acknowledge the two strategies
    that I write about, namely push versus pull. Rather
    than use this terminology, they talk in terms of
    JSP Templates versus DOM-based approach, acknowleding
    that there at least these two recognized strategies.

    David Young
    Reply to this Reply to original

  24. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hello David,

    > on the java faces JSR-127. Given its basis in XMLC,
    > XMLC is indirectly represented in the JCP process,
    > though I'd like to see it elevated in some way.
    > JSP Templates versus DOM-based approach, acknowleding
    > that there at least these two recognized strategies.
    Great to hear this. I think you should promote XMLC
    more, so it can become a really JSR ;-)

    Regards,
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
    Reply to this Reply to original

  25. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    I always thought ATG Dynamo was ahead of the game with its extensive tag libraries and pre-J2EE tiered strategy. Cold Fusion tags were great too. It used to be ONLY servlets and then JSP came along to compete against ASP. Wow, compiled pages, cool. I wished someone would come up with an open standard. Mostly so a client didn't have to pay a quarter million dollars for an e-commerce package This was before Tomcat and the other Jakarta projects.

    Lately, I have been using Struts, the Struts tag libraries, and the Commons tag libraries. I like the separation of business logic and presentation. It really forces you to separate. Any java code in the JSP is there to drive presentation only.

    I see the beauty of XMLC yet there also seems to be a trend to visualize tag libraries in tools like Dreamweaver. VisualAge and other IDEs visualized drag and drop JavaBeans. It is a question of closing the gap between static comps that we use now and proofable dynamic pages. We use greeking to show copy, why not for tag libraries.

    Where do you stand on HTML developers using Javscript or even DHTML?
    Reply to this Reply to original

  26. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    It is not an either-or world anymore, thanks to Japple!

    Folks, Japple delivers both the elegance and power of push-style data binding (DOM) and the speed and ease-of-use of JSP.

    Japple handles the HTML compilation at runtime using a combination of JTidy and JDOM. It then loads the DOM into the JSP request object for data binding. HTML stays plain and pure. JSP files are simply _all_ Java code. They can get/set data, call services as they would normally, and then just bind the data into the DOM using convenience methods provided by Japple. Very easy and very straight forward.

    Need to update the HTML? No problem, edit the HTML file on disk and hit reload in the browser.

    Need to update the JSP? Again, simply edit the JSP file on disk and hit reload in the browser.

    Japple is the best of both worlds! Push-stype (DOM) data binding combined with JSP.

    Download the WAR's and find out for yourself!
    There is a Japple Tutorial setup that takes about 30 minutes to complete.
    http://www.japple.org/tutorial/
    http://www.japple.org


    Cheers,
    Bill

    ps. Japple is LGPL
    Reply to this Reply to original

  27. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Thanks to the information about Japple. I saw the idea about the templates in Japple (http://www.japple.org/tutorial/templates.html).

    This idea is indeed quite interesting. Could you please explain to me, why do you use JSP for programming the DOM? What difference does this make than just using a plain servlet?

    Thanks,
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------
    Reply to this Reply to original

  28. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Thanks to the information about Japple. I saw the idea

    > about the templates in Japple
    > (http://www.japple.org/tutorial/templates.html).
    >
    > This idea is indeed quite interesting. Could you please
    > explain to me, why do you use JSP for programming the DOM?
    > What difference does this make than just using a plain
    > servlet?

    Simply for ease-of-use and speed-of-development. Application developers who already know JSP, can use the power of push-style (DOM) data binding without having to worry about a pre-complation step, classpath, DOM APIs, etc.

    Also it provides the familar, iterative development process of changing HTML or JSP and hitting reload in the brower to see the changes.

    The problems I have with most of the "frameworks" out there is that you need to be an expert Java programmer to get anything done. I believe we need tools that allow developers to assemble applications faster and easier. Using JSP for programming the DOM is just one of the ways Japple addresses this issue.

    Cheers,
    Bill
    --
    http://www.japple.org/

    Reply to this Reply to original

  29. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    The problem with JSP files is that you cannot use those

    >files as a storyboard, thanks to TagLibs, which are not
    >standard HTML tags. Or maybe this has changed already? Is
    >there any web browsers able to show JSP files like HTML
    >files, as if all the TagLibs were not there, so I can just
    >use them as a storyboard (prototyping)?

    Actually, you CAN view JSP files in any browser, provided you a) rename the file to .html; or b) configure your OS so that .jsp files have a MIME type of text/html, and a browser assigned to them.
    What you will see, of course, depends on what's in the file.
    The examples I have shown in previous posts will display correctly, as if they were not there (web browsers generally ignore unrecognized tags and attributes).
    BTW, this is the main reason why I don't like Struts and other similar frameworks: they replace the standard HTML tags for UI controls with their own JSP tags. As I said before, it is an issue of language design.
    Reply to this Reply to original

  30. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hey, everybody is trying to move away from code and replace it with templates, especially for the UI, where the presentation takes far more effort to achieve than the dynamic code. If you architect your app well, you will have minimum Java or any code in the presentation. The necessary retrievals will be done upfront.

    You can do a mock-up with JSP if you provide "mock-up" data in whatever Java classes you will use to retrieve the real data.

    A nice alternative is XML and XSLT -- here is your data, mock-up or real, easy to see and validate. XSLT can be used in push or pull mode, depending on how you code it. Too bad it will never have the performance of compiled JSPs. On the other hand, if it happens on the *client*, we have a completely different set of opportunities... This is feasible only for Intranet applications where you can control the browser and OS.
    Reply to this Reply to original

  31. Shameless Plug: Internet document report server!!!![ Go to top ]

    Check out the IDRS (http://idrs.sourceforge.net/), it uses a powerful tepmlate engine thats very easy to add new tags to and a plugable scripting engine ! here is an example of using the IDRS to create a report on some data:

    <rml>
    <ishtml>true</ishtml>
    <scriptclass>net.sourceforge.idrs.script.embedable.IDRSPython</scriptclass>
    <head>
    <!-- HTML Header code here -->
    <db id="data>
      <dbname>MainDB</dbname>
      <sql>
        <src>
          SELECT name, cost from table where id=?
        </src>
      </sql>
    </db>
    </head>
    <body>
      <table border="0">
        <tr><td>name</td><td>cost</td></tr>
        <repeat id="data" color1="grey" color2="white">
          <tr bgcolor="<field><Background></field>">
            <td>
              <font color="<field><ForeColor></field>">
                <field>data.name</field>
              </font>
            </td>
            <td>
              <font color="<field><ForeColor></field>">
                <field format="number,money" >data.cost</field>
              </font>
            </td>
           </tr>
         </repeat>
       </table>
      </body>
    </rml>

    There are tags for form handling, using java objects and advanced presentation logic as well as the abillity to use any scripting language you want (currently beanshell and jython).

    Marc Boorshtein
    Reply to this Reply to original

  32. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Interesting article.

    However, I see one point missing in this article. The XMLC process requires page-compilation before someone can bind data to the page. This is somewhat skewed, because changes in pages could easily break data binding code. In the JSP model, if the JSP tries to pull wrong data, the JSP fails, but not the data binding code. This could get counter-productive in some cases.

    The author also fails to mention the fact that in the pre-J2EE days, NAS used to have a similar approach, where the Java developer fills up some generic data structure (so there is no interface for binding) that the page pulls at render time.

    Subbu
    Reply to this Reply to original

  33. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    However, I see one point missing in this article.

    > The XMLC process requires page-compilation before
    > someone can bind data to the page. This is somewhat
    > skewed, because changes in pages could easily break
    > data binding code.
    This is not true. As long as the "id"s are not changed... The probability that those HTML designers make changes by mistake within JSP files is bigger ;-)

    > The author also fails to mention the fact that in
    > the pre-J2EE days, NAS used to have a similar approach,
    > where the Java developer fills up some generic data
    > structure (so there is no interface for binding)
    > that the page pulls at render time.
    The most important difference -> XMLC uses XML! And this is also the great advantage of XMLC to compare with other template languages like Velocity, WebMacro or Freemarker...

    Just another story for all of you ;-) ...
    For all the beginners in the presentation technologies:
    At my university I had a project with my students building a J2EE web application with the current Open Source Technologies. I took 2 students to take care the whole presentation layer. Both of them haven't worked with JSP, XMLC or Velocity yet. They only had a basic knowledge in Servlet, so they were beginners. I let both of them examine and try JSP, XMLC and Velocity. After two weeks, they had to make a presentation about those presentation technologies. As a result, both of them found that XMLC is very easy to handle and to understand to compare with JSP and Velocity (I don't talk about Struts, Barracuda or Turbine here...)

    One nice side effect of using XMLC, I didn't have to explain them how XML works, because they also learn this directly within XMLC ;-)

    I found JSP with JSP TagLibs is also a very nice designed approach. But if you don't have any JSP experts in your team and you want to have a well designed, easy to extend web application, XMLC is surely the way to go.

    Like David said before that Sun already acknowledges both strategies and surely: there is no one solution for all problems!

    Greets,

    LoDe.
    http://openuss.sourceforge.net
    Reply to this Reply to original

  34. New Article "XMLC vs JSP" Posted on TheServerSide[ Go to top ]

    Hi LoDe, we have programmers who have worked on JSP technology for quite some time but there was a debate since we were wondering if there could be a better solution than over loading the JSP pages with lots of java code, the use os JSP tab libs could help but that requires a great level of expertise which we havent acquired still.We even had a look at Velocity as a solution but could not find it as a very convincing approach.

    As per your message XMLC looks to be good solution, though I would like a better insight on the pros and cons of using XMLC.

    Thanks in advance.

    Kalpana Sharma
    Reply to this Reply to original

  35. New Article "XMLC - BEWARE THE LICENSING![ Go to top ]

    A quick word of caution...
    XMLC (and the Barracuda framework) claims to be open source and looked great to me from the outset. However, no one on the mailing lists would respond to my repeated requests for basic interpretation of their unique license(Enhydra Public License - EPL). Further, any other inquiries by others SEEMED to be skirted over or answered in nebulous terms - at best.

    Soooo ... if you have an attorney at your disposal to help you interpret the license, then check it out. Otherwise BE CAREFUL!
    Reply to this Reply to original

  36. New Article "XMLC - BEWARE THE LICENSING![ Go to top ]

    So if HTML designers need to understand a lit bit of java and currently don't - is that bad in itself?? Don't you think of that as a gain they get out of the project??

    Is this to get burger flippers to code page designs :) and save some $$$ ??

    Try it and Burger flippers will inevitably ( much to your discomfort)learn some java ho ho ho :) !!

    Just let them also have some career path eh!!

    Keep inventing frameworks - you (framework strategists) will lose !! You are becoming like your MBA crackpots!!

    In all these years of evolution of software development , No strategy to avoid or centralize the use of upper cortex has ever succeeded. The demand for more sharper upper cortices has only increased!!

    Yah all of these page frameworks make the page code look simple, but takes a genious to understand the simplicity :) :)

    get a life!! Struts it is and no more!!
    Reply to this Reply to original

  37. New Article "XMLC - BEWARE THE LICENSING![ Go to top ]

    So if HTML designers need to understand a lit bit of java and currently don't - is that bad in itself?? Don't you think of that as a gain they get out of the project??

    > Is this to get burger flippers to code page designs :) and save some $$$ ??
    > Try it and Burger flippers will inevitably ( much to your discomfort)learn some java ho ho ho :) !!
    > Just let them also have some career path eh!!
    > Keep inventing frameworks - you (framework strategists) will lose !! You are becoming like your MBA crackpots!!
    > In all these years of evolution of software development , No strategy to avoid or centralize the use of upper cortex has ever succeeded. The demand for more sharper upper cortices has only increased!!
    > Yah all of these page frameworks make the page code look simple, but takes a genious to understand the simplicity :) :)
    > get a life!! Struts it is and no more!!

    Couldn't help but reply to this useless troll of a comment.

    And I'll do it without mentioning a certain framework I favor.

    It's about proper division of labor and creating an environment in which everyone can be effective, at *all* stages of the product lifecycle, without going into a panic. It's about addressing situations that real developers and contractors find when involved on *real* projects.

    In real projects, you have a mix of people with different capabilities. You may be walled off from the graphic designers and HTML producers (leading to the dreaded friday night HTML merge).

    In the real world, where even requirements are subject to change late in a project, you need to create agile software. I don't doubt that the HTML producers (the ones you disparagingly refer to as "burger flippers" you arrogant, useless shithead) are capable of picking up some Java, in much the way they pick up JavaScript, but they are not the ones with the depth of experience necessary to create flexible, agile solutions. Nor are the often in a position to see the big picture, to identify areas of reuse ... they are often on a pretty fixed schedule and checklist ... convert *this* photoshop mockup into *that* HTML page.

    And by the way, HTML producers and graphic designers do not see "Java developer" as the next step in their career path.

    None of the frameworks are designed to bypass anyone's cereberal cortex. Each, in its own way, and following its developers' preferences, philosophies and experiences, is about creating a common approach to solving the continuous stream of tiny problems that makes up an application. Creating uniformity, not by fiat, but by making it easier and more attractive, is a huge win. It makes it easier to deal with all the problems in real world development: Developers with differing skill sets, geographic locations, experience levels and communication skills.

    There's a lot of software in the world that works great as demoware ... and falls on its face as soon as you try to do anything interesting with it. These frameworks are about getting real work done in a real environment.
    Reply to this Reply to original

  38. New Article "XMLC - BEWARE THE LICENSING![ Go to top ]

    I guess I went too far to make my point. I apologize for anything derogatory explicit or implied in my posting. Don't want to muddy this dicussion further.
    Reply to this Reply to original

  39. New Article "XMLC - BEWARE THE LICENSING![ Go to top ]

    To your original statement re: licensing...
    IMHO, there's nothing to worry about (beyond the
    general condition of open source licenses in
    general...)

    EPL - Enhydra Public License - is derived with
    very few changes from the Mozilla Public Licence
    developed by Netscape for open sourcing their
    browser engine.

    If you want to see the differences, check out:
    http://enhydra.enhydra.org/software/license/index.html
    http://enhydra.enhydra.org/software/license/MozillaStepByStep.html

    David
    Reply to this Reply to original

  40. xml/xslt[ Go to top ]

    Has anyone tried xml/xslt approach to address this presentation layer problem? It seems to have the benefit of both jsp and xmlc.
    Reply to this Reply to original

  41. xml/xslt[ Go to top ]

    I loved the burger flipper and the equally appropriate response.

    I actually think there is a very valid point here. Every project can select any number of technologies. Lets say we have a unix back end and a browser based user community. We have a team of 3 developers - and they will have to be a versatile bunch...and I believe most developers can actually manage html.

    OK, Oracle, Tomcat, JSP's.
    Maybe.. Oracle, Tomcat, Servlets

    Frameworks? Why.

    Now lets say a team of 8.
    Oracle, JBoss, Struts. Say. So I've selected struts, its pretty widely used, no ones CV will suffer.

    Now a team of 20, say 3 PM, 5 java, 2 dba, 3 web gui, 3 test and docn, and 4 interns learning to use the coffee machine. Now things are a bit more of a nightmare. You really do have experts and specialists. The dbas want to know very little of the middle tier, they are worried about data feeds. The java boys have to worry about scaleability and robustness, and the gui chaps are fending off marketing who want it in a slightly lighter shade of blue because they are fools.

    So, now we arrive at this argument on theserverside. I'd go with dreamweaver templates and a handover to java boys to integrate into the struts dev process. BUT, I can see how someone from a less java background would want the java boys to kinda fit in with the html rather than visa versa. Have a strict template approach...

    So, small teams... do whatever you like. Big teams, argue for months on end and then get your key star employees to make it work really quickly. Probably.

    Or more simple, for big teams this is a real issue, for small teams then there should be no issue.

    Jonathan
    ps I still say struts over templates!
    Reply to this Reply to original

  42. xml/xslt[ Go to top ]

    Yes. I did the xml/xslt thing for a client who had 25 different 'looks' for a site (included 5 digital tv platforms and wml). The target was to support 1m page impressions/day, so performance was very important to us, but with so many platforms, xsl seemed an obvious way to go.

    The pitfalls are:
    - Fetching back complex information for simple views and then transforming it down (you might do this in order to reuse code originally written for a richer presentation environment).
    - Complex xsl, and not reusing transformations destroys performance.
    - xsl is extremely poor at string processing. In order to avoid processor-specific xsl you will continually be migrating little pieces of functionality (like url encoding) back into the xml generation phase. You'll find that this is really putting a little of your presentation logic in the wrong place :(

    That being said, it does work.
    Reply to this Reply to original

  43. xml/xslt[ Go to top ]

    If you like the XML/XSLT approach, check this out:

    http://www.orbeon.com/oxf/

    A mix of Struts, Cocoon and more...
    Reply to this Reply to original

  44. Getting the best of both JSP and XMLC[ Go to top ]

    Those who value complete separation of HTML from server-side code, but prefer to use languages like JSP, may wish to consider Dynamator. Dynamator adds the benefits of XMLC to traditional page-generation languages like JSP.

    Dynamator transforms pure HTML into standard server pages in languages like JSP, Java, and XSL. HTML authors maintain pure HTML; developers code separate files that specify how to transform the HTML into a server page.

    Dynamator provides the same benefits as XMLC: complete separation of HTML from server-side code, support for a static demo site, and easy internationalization, customization, and multi-channel presentation. Unlike XMLC, Dynamator has no execution-environment components and is compatible with any runtime architecture (JSP Model I or II, Java out.println, XSL, PHP, ASP.NET, etc.).

    The Dynamator language is small and simple. Mostly, developers use the languages they already know (like JSP with tag libraries). And pages generated by Dynamator are as efficient as those coded by hand.

    Dynamator is free, open source software.

    http://dynamator.sourceforge.net
    Reply to this Reply to original

  45. Getting the best of both JSP and XMLC[ Go to top ]

    Nice! I've done something similar in my current project - generating multiple jsps from single html files, with links and form tags converted to use struts taglibs 'on the fly'. The idea is to be able to track the static mockup sites the web designers produce for the marketing department.

    The differences:
    - I wrote the parser myself rather than use JTidy. Mine guarantees equivalence of the generated jsp and the input html, which meant the html designer wasnt constrained by xml-correctness. This was a major factor for us that led to me not using xmlc in the first place.
    - I was interested in coarse-grained replacement of static content with dynamic, so id-attributed chunks generate separate files, stitched back together with struts templates. Config files used in the build can switch in custom jsps globally or on a per-page basis. I'd like to be able to support fine-grained changes better but it hasn't become a big issue yet.

    I'm looking at changing my (hardcoded) code generator to generate an intermediate xml format now - not simply correcting the html as per jtidy, but again leaving the html alone - in order to make the jsp generation more flexible, use xsl for the final code generation phase, yadda yadda yadda.

    The amount of jsp code we actually have to maintain is very small as a consequence, so I doubt a switch to your tool would be useful for us now. But it might have saved me a lot of time if I'd found your tool last year!
    Reply to this Reply to original

  46. Getting the best of both JSP and XMLC[ Go to top ]

    I refered the Dynamator tool as adviced by you, but i dont understand the need to write a separate .dyn file and then run the HTML file for generating the JSP page.I could as well code the entire JSP page itself,whats the added advantage?
    In our project we have all the front end files in HTML, these need to be converted to JSP by adding additonal pieces of code withing the HTML files,in what way would Dynamator help?
    Reply to this Reply to original

  47. The advantages of separation[ Go to top ]

    To me the most important advantage of placing server-side logic in a separate file from the HTML is that the HTML and JSP code can then be maintained independently. So HTML authors can continue to enhance and tweak the HTML without bothering programmers, and programmers can write and maintain JSP code without getting into the HTML.

    If the same people who write the HTML also code the JSP, this is not as big a deal.

    There are lots of other advantages, some of which may be more important to you. See the Dynamator.
    Reply to this Reply to original