Tapestry
  1. Tapestry
  2. TAPESTRY-1276

If component should include an optional negate parameter

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 5.0.3
    • Component/s: tapestry-core
    • Labels:
      None
    • Environment:
      MacOS X 10.4.8, Eclipse 3.2.1

      Description

      It would be useful for the If component to take an optional negate parameter, much like the WOCondition component in WebObjects. This would allow the component content to be rendered if the associated condition is FALSE instead of TRUE, therefore eliminating the need to write an additional Java method to perform this negate operation.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        Does the else parameter (a block) suffice, as in:

        <t:comp type="If" test="order.lineItems">
        . . . <!-- Display the line items, etc. -->
        <t:parameter name="else">
        There are no llne items in this order.
        </t:parameter>
        </t:comp>

        Show
        Howard M. Lewis Ship added a comment - Does the else parameter (a block) suffice, as in: <t:comp type="If" test="order.lineItems"> . . . <!-- Display the line items, etc. --> <t:parameter name="else"> There are no llne items in this order. </t:parameter> </t:comp>
        Hide
        Randy Leonard added a comment -

        I suppose it does, just a little more verbose than what I am used to.

        Show
        Randy Leonard added a comment - I suppose it does, just a little more verbose than what I am used to.
        Hide
        Howard M. Lewis Ship added a comment -

        It's more verbose for some things, but I quite often find I need two ifs: for the normal case, and one for the else case. This merges both cases together with a minimum of fuss.

        I'm not saying the negate parameter is bad (T4 has an equivalent "invert" parameter), but there may be other options that are better, such as extending the property expression syntax to support an inversion operator, i.e.

        <t:comp type="if" test="! order.lineItems">
        . . .
        </t:comp>

        Another option would be to create an Unless component:

        <t:comp type="unless" test="order.lineItems">
        . . .
        </t:comp>

        I find both of these preferable to a negate or invert parameter.

        Show
        Howard M. Lewis Ship added a comment - It's more verbose for some things, but I quite often find I need two ifs: for the normal case, and one for the else case. This merges both cases together with a minimum of fuss. I'm not saying the negate parameter is bad (T4 has an equivalent "invert" parameter), but there may be other options that are better, such as extending the property expression syntax to support an inversion operator, i.e. <t:comp type="if" test="! order.lineItems"> . . . </t:comp> Another option would be to create an Unless component: <t:comp type="unless" test="order.lineItems"> . . . </t:comp> I find both of these preferable to a negate or invert parameter.
        Hide
        Jesse Kuhnert added a comment -

        "cough". .. You know, there is a certain property expression library floating around that can do these kinds of things and has recently been upgraded to include compilation support via javassist for the "entire" expression.

        I'm not sure how much the paths diverge wrt needs / environment / etc, but "the world is yours" as they say....Drew has officially handed it off to me so we "own it" as far as I'm concerned morality wise if we get pissed off with hosting at opensymphony.com. Of course there'd be no issues with making you a committer / any little changes that might need to be made. In some perverse way I'm enjoying the lower level side of my brain that it exercises so I'm ok with fielding requests....

        URL is http://svn.opensymphony.com/svn/ognl/trunk/ . I've deployed it and have to imagine some people are using it in 4.1.2 tapestry now as I've made it a required dependency.

        It's probably more trouble than it's worth for both of us but thought I'd throw this out there as I can imagine you'll be spending the rest of your days adding more and more property expression logic otherwise.

        Show
        Jesse Kuhnert added a comment - "cough". .. You know, there is a certain property expression library floating around that can do these kinds of things and has recently been upgraded to include compilation support via javassist for the "entire" expression. I'm not sure how much the paths diverge wrt needs / environment / etc, but "the world is yours" as they say....Drew has officially handed it off to me so we "own it" as far as I'm concerned morality wise if we get pissed off with hosting at opensymphony.com. Of course there'd be no issues with making you a committer / any little changes that might need to be made. In some perverse way I'm enjoying the lower level side of my brain that it exercises so I'm ok with fielding requests.... URL is http://svn.opensymphony.com/svn/ognl/trunk/ . I've deployed it and have to imagine some people are using it in 4.1.2 tapestry now as I've made it a required dependency. It's probably more trouble than it's worth for both of us but thought I'd throw this out there as I can imagine you'll be spending the rest of your days adding more and more property expression logic otherwise.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Randy Leonard
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development