3 Replies Latest reply: Jan 28, 2013 12:30 PM by Cmore-Oracle RSS

    What is better common droplets or http://java.sun.com/jsp/jstl/core tags??

    Obed Murillo
      Hi Gurus,

      I work with Jsps and I found easier to use jstl tags for loops and conditions than actual droplets, What is the better practice on this matter?

      What is better use for loops as for each?

      This /atg/dynamo/droplet/ForEach or this c:forEach

      and for conditional?

      This /atg/dynamo/droplet/Switch or this c:choose

      Note: I know that for each has status param, and that you can sort, the question above is about the simple usage just sending the array param.

      Regards,
      Obed

      Edited by: obedmhg on Jan 23, 2013 3:29 PM

      Edited by: obedmhg on Jan 23, 2013 3:31 PM
        • 1. Re: What is better common droplets or http://java.sun.com/jsp/jstl/core tags??
          RMishra
          What is better use for loops as for each?
          This /atg/dynamo/droplet/ForEach or this c:forEach>
          Droplets / DSP tag library
          Droplets are ATG servlet beans that are used to dynamically generate HTML. ATG provides numerous droplets to perform lots of common tasks (e.g. display all the error messages for a form), but it’s possible to write your own custom ones also. The DSP (dynamo server pages) tag library is somewhat equivalent to JSTL but with the added ability that they naturally interact with Nucleus components.
          Droplets tend to be a bit verbose. For example, compare the following piece of hypothetical code to display the contents of a shopping cart written using ATG droplets with what it might look like if written in a bespoke JEE application.
          <h1>ATG shopping cart example</h1>
          <dsp:droplet name="/atg/dynamo/droplet/ForEach">  <dsp:param name="array"
              bean="/atg/commerce/ShoppingCart.current.commerceItems" />
            <dsp:param name="elementName" value="commerceItem" />
            <dsp:oparam name="output">
              <dsp:getvalueof var="commerceItemId" param="commerceItem.id" />
              <dsp:droplet name="SkuLookupDroplet">
                <dsp:param name="id" param="commerceItem.catalogRefId" />
                <dsp:param name="elementName" value="sku" />
                <dsp:oparam name="output">
                  <dsp:getvalueof param="sku.displayName" var="skuDisplayName" />
                </dsp:oparam>
              </dsp:droplet>
              <td><dsp:valueof param="skuDisplayName" />  <dsp:valueof
                param="commerceItem.priceInfo.amount" converter="currency"
                locale="${someCustomlocale}">0.00</dsp:valueof></td>
              <td><dsp:a href="deliveryOptions.page"
                bean="DeliveryOptionsFormHandler.value.itemId"
                value="${commerceItemId}">Delivery Options</dsp:a></td>
            </dsp:oparam>
          </dsp:droplet>
          <h1>Bespoke shopping cart example</h1>
          <c:forEach var="commerceItem"
            items="${shoppingCart.current.commerceItems}">
            <td><customtag:getSkuDisplayName id="${commerceItem.catalogRefId}" />
            <fmt:formatNumber type="currency" minFractionDigits="2"
              value="${commerceItem.priceInfo.amount}" /></td>
            <td><a href="deliveryOptions?itemId=${commerceItem.id}">Delivery Options</a></td>
          </c:forEach>
          Of course, there is no reason why you can't mix and match tag libraries and only use the ATG tags and droplets where necessary.

          -RMishra
          • 2. Re: What is better common droplets or http://java.sun.com/jsp/jstl/core tags??
            Nooruddin Shaik
            If you can avoid droplets and can use JSTL tag libs then better to use jstl.
            Performance wise droplets are slightly heavier when compared to JSTL.

            Droplets are more powerful the JSTL in ATG as they work with nucleus components.

            Peace
            Shaik
            • 3. Re: What is better common droplets or http://java.sun.com/jsp/jstl/core tags??
              Cmore-Oracle
              I'd generally agree with Shaik. Droplets are very easy to write, are configurable and overridable... but are a little heavier weight than many JSTL tags. Using JSTL tags for core logic tends to be a little more terse and efficient.

              However, there are some newer features that made droplets less painful to use with JSTL tags and EL expressions.

              h3. The Droplet Tag

              The droplet tag supports dynamic attributes, so you don't necessary need separate dsp:param tags. This is particularly convenient for static values being passed in (as in "elementName" above). You can also use JSTL in those dynamic attributes (which is especially handy when using the DynamicELResolver).

              The droplet tag also supports a "var" attribute, which binds the current frame of the param stack. So, in the ForEach example upthread, one could add var="forEach" to your tag, and then refer to output params of the droplet via syntax like ${forEach.count}. This is one way to reduce shuttling values between ATG params and regular JSTL-friendly attributes.

              h3. DynamoELResolver

              The DynamoELResolver can be added to a web-app by registering atg.taglib.dspjsp.RegisterELResolverServletContextListener as a listener class. The DynamoELResolver adds 3 behaviors:

              1. It provides top-level "nucleus" variable, which allows nucleus components to be referenced by el. This allows using an EL expression like ${nucleus["/atg/userprofiling/Profile"].firstname} . Note that generally it's more efficient to use dsp:importbean with a var attribute if you are going to reference the same component more than once on a page (although the "nucleus" implicit object also supports the short name when importbean is used).

              2. It provides the ability to reference the properties of dynamic beans (as in the profile example above). This is particularly handy with RepositoryItems, including profiles, products, skus, etc.

              3. Invokes beforeGet when getting values from FormHandlers.

              (It would be convenient if the DynamoELResolver provided easy access to the whole param stick via an "objectParam" (or some such) implicit attribute, but it doesn't currently.)