foreach

[Va...@lntinfotech.com]

Hi,

     Is there a way to break out of foreach when a particular condition is
satisfied.

#foreach ( $name in $Customer.getName() )

 #if( $name == "XYZ" )
 -------------------------> is there a way to break out...
#end


Thanks & regards
Vanitha


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

Geir Magnusson Jr. wrote:
> On 5/3/02 11:38 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
> 
> 
>>Geir Magnusson Jr. wrote:
>>
>>>On 5/3/02 11:06 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>>>
>>>
>>>
>>>>Geir Magnusson Jr. wrote:
>>>>
>>>>
>>>>>Every bone in my body tells me this is the wrong thing to do, but I *just*
>>>>>can't resist.
>>>>
>>>>With all due respect, I think it is quite erroneous. You see, you're
>>>>making an invalid comparison. On the scale of software engineering
>>>>values, Velocity is closer to JSP than FreeMarker is, since Velocity
>>>>exposes all of the public methods in an object to the template author.
>>>>
>>>>Now, you can do also the full reflection approach in FreeMarker, but
>>>>that's not the default.
>>>>
>>>>So FreeMarker has a much greater tendency to enforce the MVC separation
>>>>than Velocity does.
>>>
>>>
>>>Ok.
>>>
>>>It was only a joke.
>>
>>Yes, you said that. Not a joke in the best of taste, though. I don't
>>think you would like to hear Velocity being likened to JSP.
> 
> 
> Er, I did liken Velocity to JSP.
> 
> 
>>It also wasn't too clear what the joke's punch line was.
> 
> 
> Sort of a visual/pattern thing.  Not everyone is going to get it, I suppose.

It blew right past me. I didn't get it. My interpretation of things was 
that you were just trying to blow some smoke and confuse matters. I 
mean, it's dead simple. There are legitimate reasons to want to break 
out of a loop. FreeMarker allows for that and Velocity does not. I guess 
you said: "Of course, I'm only joking." in order to leave yourself an 
escape hatch, right? :-)


> If I was a really funny guy, I would have done :
> 
> ----
> 
> Hi $originalPoster,
> 
> $target does not have this feature.
> 
> I thought you might be interested in knowing that $myAlternative (as of
> version $currVer) does have this feature. Your code above would look like:
> 
> #set($vallist =[ $refkey, $iterativeString, $stopVal] )
> #demosyntax( 'foreach' $vallist )
> 
> As you see above, $myAlternative's syntax is somewhat different from
> $target. However, $myAlternative $currVer also has a utility for
> automatically 
> converting $target templates to the $myAlternative syntax.
> 
> Best Regards,
> 
> $respondent

Well, I do appreciate the template. It may come in handy for some future 
messages. "FreeMarker has the feature. Velocity does not." :-) With the 
template you've provided, I'll just need to fill in the blanks each 
time. I hope you don't mind. After all, open source is based on the free 
circulation of information.

Cheers,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/3/02 11:38 AM, "Jonathan Revusky" <jr...@terra.es> wrote:

> Geir Magnusson Jr. wrote:
>> On 5/3/02 11:06 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>> 
>> 
>>> Geir Magnusson Jr. wrote:
>>> 
>>>> Every bone in my body tells me this is the wrong thing to do, but I *just*
>>>> can't resist.
>>> 
>>> With all due respect, I think it is quite erroneous. You see, you're
>>> making an invalid comparison. On the scale of software engineering
>>> values, Velocity is closer to JSP than FreeMarker is, since Velocity
>>> exposes all of the public methods in an object to the template author.
>>> 
>>> Now, you can do also the full reflection approach in FreeMarker, but
>>> that's not the default.
>>> 
>>> So FreeMarker has a much greater tendency to enforce the MVC separation
>>> than Velocity does.
>> 
>> 
>> Ok.
>> 
>> It was only a joke.
> 
> Yes, you said that. Not a joke in the best of taste, though. I don't
> think you would like to hear Velocity being likened to JSP.

Er, I did liken Velocity to JSP.

> 
> It also wasn't too clear what the joke's punch line was.

Sort of a visual/pattern thing.  Not everyone is going to get it, I suppose.

If I was a really funny guy, I would have done :

----

Hi $originalPoster,

$target does not have this feature.

I thought you might be interested in knowing that $myAlternative (as of
version $currVer) does have this feature. Your code above would look like:

#set($vallist =[ $refkey, $iterativeString, $stopVal] )
#demosyntax( 'foreach' $vallist )

As you see above, $myAlternative's syntax is somewhat different from
$target. However, $myAlternative $currVer also has a utility for
automatically 
converting $target templates to the $myAlternative syntax.

Best Regards,

$respondent

----

But it's clear I'm not very funny...


> In any case, I 
> gave a straight reply because there was some concern on my part that
> some people could take the implicit comparison between FM and JSP seriously.

Gosh, I hope not.  Other than the pointy brackets, can't see how they are
the same, not that you've relaxed the limitations on introspection.

> 
>> 
>> Welcome back to the Velocity lists.
> 
> 
> Thank you. Maybe there will be some nuggets of wisdom that can be
> shared. :-)

Maybe.
 
> Jonathan Revusky
> --
> Lead developer of FreeMarker http://freemarker.sourceforge.net/
> Build robust web appications with the
> Niggle Web Application Framework http://niggle.org/
> Available for Java/Internet Consulting
> 
> 
>> 
>> geir
>> 
>> 
>>> Best Regards,
>>> 
>>> Jonathan Revusky
>>> --
>>> Lead developer of FreeMarker http://freemarker.sourceforge.net/
>>> Build robust web appications with the
>>> Niggle Web Application Framework http://niggle.org/
>>> Available for Java/Internet Consulting
>>> 
>>> 
>>> 
>>>> On 5/3/02 10:40 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>>>> 
>>>> 
>>>> 
>>>>> Vanitha.S@lntinfotech.com wrote:
>>>>> 
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>    Is there a way to break out of foreach when a particular condition is
>>>>>> satisfied.
>>>>>> 
>>>>>> #foreach ( $name in $Customer.getName() )
>>>>>> 
>>>>>> #if( $name == "XYZ" )
>>>>>> -------------------------> is there a way to break out...
>>>>>> #end
>>>>> 
>>>>> Hi Vanitha,
>>>>> 
>>>>> Velocity does not have this feature.
>>>>> 
>>>>> I thought you might be interested in knowing that FreeMarker (as of
>>>>> version 2) does have this feature. Your code above would look like:
>>>>> 
>>>>> <foreach name in Customer.getName()>
>>>>> ...
>>>>> <if name == "XYZ">
>>>>>     <break>
>>>>> </if>
>>>>> ...
>>>>> </foreach>
>>>>> 
>>>>> As you see above, FreeMarker's syntax is somewhat different from
>>>>> Velocity. However, FreeMarker 2 also has a utility for automatically
>>>>> converting Velocity templates to the FreeMarker syntax.
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Jonathan Revusky
>>>> 
>>>> 
>>>> Hi Vanitha,
>>>> 
>>>> Velocity does not have this feature.
>>>> 
>>>> I thought you might be interested in knowing that JSP (as of version 1.0)
>>>> does have this feature.  Your code above would look like :
>>>> 
>>>> <%
>>>>    for( Iterator it=customer.iterator(); it.hasNext(); )
>>>>    {
>>>>      String name = (String) it.next();
>>>>      ....
>>>>      if (name.equals("XYZ"))
>>>>        break;
>>>>      ....
>>>>    }
>>>> %>
>>>> 
>>>> As you see above, JSP's syntax is somewhat different from Velocity.
>>>> However, JSP also has a taglib for automatically using Velocity templates
>>>> in
>>>> the JSP syntax.
>>>> 
>>>> Best Regards,
>>>> 
>>>> Geir Magnusson Jr.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Vanitha, I'm only joking, of course :)
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>> 
>> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

Geir Magnusson Jr. wrote:
> On 5/3/02 11:06 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
> 
> 
>>Geir Magnusson Jr. wrote:
>>
>>>Every bone in my body tells me this is the wrong thing to do, but I *just*
>>>can't resist.
>>
>>With all due respect, I think it is quite erroneous. You see, you're
>>making an invalid comparison. On the scale of software engineering
>>values, Velocity is closer to JSP than FreeMarker is, since Velocity
>>exposes all of the public methods in an object to the template author.
>>
>>Now, you can do also the full reflection approach in FreeMarker, but
>>that's not the default.
>>
>>So FreeMarker has a much greater tendency to enforce the MVC separation
>>than Velocity does.
> 
> 
> Ok.
> 
> It was only a joke.

Yes, you said that. Not a joke in the best of taste, though. I don't 
think you would like to hear Velocity being likened to JSP.

It also wasn't too clear what the joke's punch line was. In any case, I 
gave a straight reply because there was some concern on my part that 
some people could take the implicit comparison between FM and JSP seriously.

> 
> Welcome back to the Velocity lists.


Thank you. Maybe there will be some nuggets of wisdom that can be 
shared. :-)

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting


> 
> geir
> 
> 
>>Best Regards,
>>
>>Jonathan Revusky
>>--
>>Lead developer of FreeMarker http://freemarker.sourceforge.net/
>>Build robust web appications with the
>>Niggle Web Application Framework http://niggle.org/
>>Available for Java/Internet Consulting
>>
>>
>>
>>>On 5/3/02 10:40 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>>>
>>>
>>>
>>>>Vanitha.S@lntinfotech.com wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>    Is there a way to break out of foreach when a particular condition is
>>>>>satisfied.
>>>>>
>>>>>#foreach ( $name in $Customer.getName() )
>>>>>
>>>>>#if( $name == "XYZ" )
>>>>>-------------------------> is there a way to break out...
>>>>>#end
>>>>
>>>>Hi Vanitha,
>>>>
>>>>Velocity does not have this feature.
>>>>
>>>>I thought you might be interested in knowing that FreeMarker (as of
>>>>version 2) does have this feature. Your code above would look like:
>>>>
>>>><foreach name in Customer.getName()>
>>>>...
>>>> <if name == "XYZ">
>>>>     <break>
>>>> </if>
>>>>...
>>>></foreach>
>>>>
>>>>As you see above, FreeMarker's syntax is somewhat different from
>>>>Velocity. However, FreeMarker 2 also has a utility for automatically
>>>>converting Velocity templates to the FreeMarker syntax.
>>>>
>>>>Best Regards,
>>>>
>>>>Jonathan Revusky
>>>
>>>
>>>Hi Vanitha,
>>>
>>>Velocity does not have this feature.
>>>
>>>I thought you might be interested in knowing that JSP (as of version 1.0)
>>>does have this feature.  Your code above would look like :
>>>
>>> <%
>>>    for( Iterator it=customer.iterator(); it.hasNext(); )
>>>    {
>>>      String name = (String) it.next();
>>>      ....
>>>      if (name.equals("XYZ"))
>>>        break;
>>>      ....
>>>    }
>>> %>
>>>
>>>As you see above, JSP's syntax is somewhat different from Velocity.
>>>However, JSP also has a taglib for automatically using Velocity templates in
>>>the JSP syntax.
>>>
>>>Best Regards,
>>>
>>>Geir Magnusson Jr.
>>>
>>>
>>>
>>>
>>>Vanitha, I'm only joking, of course :)
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/3/02 11:06 AM, "Jonathan Revusky" <jr...@terra.es> wrote:

> Geir Magnusson Jr. wrote:
>> Every bone in my body tells me this is the wrong thing to do, but I *just*
>> can't resist.
> 
> With all due respect, I think it is quite erroneous. You see, you're
> making an invalid comparison. On the scale of software engineering
> values, Velocity is closer to JSP than FreeMarker is, since Velocity
> exposes all of the public methods in an object to the template author.
> 
> Now, you can do also the full reflection approach in FreeMarker, but
> that's not the default.
> 
> So FreeMarker has a much greater tendency to enforce the MVC separation
> than Velocity does.

Ok.

It was only a joke.

Welcome back to the Velocity lists.

geir

> 
> Best Regards,
> 
> Jonathan Revusky
> --
> Lead developer of FreeMarker http://freemarker.sourceforge.net/
> Build robust web appications with the
> Niggle Web Application Framework http://niggle.org/
> Available for Java/Internet Consulting
> 
> 
>> 
>> On 5/3/02 10:40 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
>> 
>> 
>>> Vanitha.S@lntinfotech.com wrote:
>>> 
>>>> Hi,
>>>> 
>>>>     Is there a way to break out of foreach when a particular condition is
>>>> satisfied.
>>>> 
>>>> #foreach ( $name in $Customer.getName() )
>>>> 
>>>> #if( $name == "XYZ" )
>>>> -------------------------> is there a way to break out...
>>>> #end
>>> 
>>> Hi Vanitha,
>>> 
>>> Velocity does not have this feature.
>>> 
>>> I thought you might be interested in knowing that FreeMarker (as of
>>> version 2) does have this feature. Your code above would look like:
>>> 
>>> <foreach name in Customer.getName()>
>>> ...
>>>  <if name == "XYZ">
>>>      <break>
>>>  </if>
>>> ...
>>> </foreach>
>>> 
>>> As you see above, FreeMarker's syntax is somewhat different from
>>> Velocity. However, FreeMarker 2 also has a utility for automatically
>>> converting Velocity templates to the FreeMarker syntax.
>>> 
>>> Best Regards,
>>> 
>>> Jonathan Revusky
>> 
>> 
>> Hi Vanitha,
>> 
>> Velocity does not have this feature.
>> 
>> I thought you might be interested in knowing that JSP (as of version 1.0)
>> does have this feature.  Your code above would look like :
>> 
>>  <%
>>     for( Iterator it=customer.iterator(); it.hasNext(); )
>>     {
>>       String name = (String) it.next();
>>       ....
>>       if (name.equals("XYZ"))
>>         break;
>>       ....
>>     }
>>  %>
>> 
>> As you see above, JSP's syntax is somewhat different from Velocity.
>> However, JSP also has a taglib for automatically using Velocity templates in
>> the JSP syntax.
>> 
>> Best Regards,
>> 
>> Geir Magnusson Jr.
>> 
>> 
>> 
>> 
>> Vanitha, I'm only joking, of course :)
>> 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

Geir Magnusson Jr. wrote:
> Every bone in my body tells me this is the wrong thing to do, but I *just*
> can't resist.

With all due respect, I think it is quite erroneous. You see, you're 
making an invalid comparison. On the scale of software engineering 
values, Velocity is closer to JSP than FreeMarker is, since Velocity 
exposes all of the public methods in an object to the template author.

Now, you can do also the full reflection approach in FreeMarker, but 
that's not the default.

So FreeMarker has a much greater tendency to enforce the MVC separation 
than Velocity does.

Best Regards,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting


> 
> On 5/3/02 10:40 AM, "Jonathan Revusky" <jr...@terra.es> wrote:
> 
> 
>>Vanitha.S@lntinfotech.com wrote:
>>
>>>Hi,
>>>
>>>     Is there a way to break out of foreach when a particular condition is
>>>satisfied.
>>>
>>>#foreach ( $name in $Customer.getName() )
>>>
>>> #if( $name == "XYZ" )
>>> -------------------------> is there a way to break out...
>>>#end
>>
>>Hi Vanitha,
>>
>>Velocity does not have this feature.
>>
>>I thought you might be interested in knowing that FreeMarker (as of
>>version 2) does have this feature. Your code above would look like:
>>
>><foreach name in Customer.getName()>
>>...
>>  <if name == "XYZ">
>>      <break>
>>  </if>
>>...
>></foreach>
>>
>>As you see above, FreeMarker's syntax is somewhat different from
>>Velocity. However, FreeMarker 2 also has a utility for automatically
>>converting Velocity templates to the FreeMarker syntax.
>>
>>Best Regards,
>>
>>Jonathan Revusky
> 
> 
> Hi Vanitha,
> 
> Velocity does not have this feature.
> 
> I thought you might be interested in knowing that JSP (as of version 1.0)
> does have this feature.  Your code above would look like :
> 
>  <%
>     for( Iterator it=customer.iterator(); it.hasNext(); )
>     {
>       String name = (String) it.next();
>       ....
>       if (name.equals("XYZ"))
>         break;
>       ....
>     }
>  %>
> 
> As you see above, JSP's syntax is somewhat different from Velocity.
> However, JSP also has a taglib for automatically using Velocity templates in
> the JSP syntax.
> 
> Best Regards,
> 
> Geir Magnusson Jr.
> 
> 
> 
> 
> Vanitha, I'm only joking, of course :)
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

Every bone in my body tells me this is the wrong thing to do, but I *just*
can't resist.


On 5/3/02 10:40 AM, "Jonathan Revusky" <jr...@terra.es> wrote:

> Vanitha.S@lntinfotech.com wrote:
>> Hi,
>> 
>>      Is there a way to break out of foreach when a particular condition is
>> satisfied.
>> 
>> #foreach ( $name in $Customer.getName() )
>> 
>>  #if( $name == "XYZ" )
>>  -------------------------> is there a way to break out...
>> #end
> 
> Hi Vanitha,
> 
> Velocity does not have this feature.
> 
> I thought you might be interested in knowing that FreeMarker (as of
> version 2) does have this feature. Your code above would look like:
> 
> <foreach name in Customer.getName()>
> ...
>   <if name == "XYZ">
>       <break>
>   </if>
> ...
> </foreach>
> 
> As you see above, FreeMarker's syntax is somewhat different from
> Velocity. However, FreeMarker 2 also has a utility for automatically
> converting Velocity templates to the FreeMarker syntax.
> 
> Best Regards,
> 
> Jonathan Revusky

Hi Vanitha,

Velocity does not have this feature.

I thought you might be interested in knowing that JSP (as of version 1.0)
does have this feature.  Your code above would look like :

 <%
    for( Iterator it=customer.iterator(); it.hasNext(); )
    {
      String name = (String) it.next();
      ....
      if (name.equals("XYZ"))
        break;
      ....
    }
 %>

As you see above, JSP's syntax is somewhat different from Velocity.
However, JSP also has a taglib for automatically using Velocity templates in
the JSP syntax.

Best Regards,

Geir Magnusson Jr.




Vanitha, I'm only joking, of course :)

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

Vanitha.S@lntinfotech.com wrote:
> Hi,
> 
>      Is there a way to break out of foreach when a particular condition is
> satisfied.
> 
> #foreach ( $name in $Customer.getName() )
> 
>  #if( $name == "XYZ" )
>  -------------------------> is there a way to break out...
> #end

Hi Vanitha,

Velocity does not have this feature.

I thought you might be interested in knowing that FreeMarker (as of 
version 2) does have this feature. Your code above would look like:

<foreach name in Customer.getName()>
...
    <if name == "XYZ">
        <break>
    </if>
...
</foreach>

As you see above, FreeMarker's syntax is somewhat different from 
Velocity. However, FreeMarker 2 also has a utility for automatically 
converting Velocity templates to the FreeMarker syntax.

Best Regards,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

Geir Magnusson Jr. wrote:
> On 5/4/02 1:15 PM, "Jonathan Revusky" <jr...@terra.es> wrote:
> 
> 
>>jonah benton wrote:
>>
>>>To the list- I'm responding to these points below, but any further
>>>debate will either be offline or dropped.
>>
>><sigh>
>>
>>The above is ridiculous, Jonah. If you did not want me to reply to this
>>message, you should not have posted it in the first place. I draw a very
>>negative conclusion from this kind of childish attempt to get in the
>>last word.
> 
> 
> Ok.  Now you'll have the last word.  Can we stop now?  Probably not...

First of all, I was obviously through with Jonah. The minute he said 
that it was so terrible that FM called macros "functions" but that the 
quality of actual code didn't matter, he was obviously blathering and I 
simply went in for the kill. In any case, Jonah specifically said that 
he was going to take the opportunity to "flame" FreeMarker. So AFAICS he 
got what he was looking for.

<shrug>

In any case, you've really got to learn to be a bit more honest, Geir. 
You are not writing in this thread in order to end it because it was 
already essentially over. I suppose you're trying to represent that I 
have mistreated poor Jonah. Look, you want to flame a fine product that 
somebody has put a lot of work into, and particularly if you're just 
talking out of your ass, what you just saw happen is what tends to 
happen -- plus or minus a bit of punctuation...

<shrug>


<snip>
>>>guerilla marketing should really be done by someone else. :)
>>
>>Well, you could be right, but the fact is that Velocity advocates are
>>not in any position to give this lecture to anybody. If you look at the
>>archives of the WebMacro list, you will see quite a bit of activity by
>>Velocity developers. AFAIK, Geir is still a regular on that list.
> 
> 
> 100% regular.
> 
> Count the number of posts to that list in the last 6 months that are from
> me.  Go ahead.  Give it a whirl.  (And don't count the flame-fest between
> us...)

Well, during the time I was subscribed to the WM list, you did post 
there regularly. I unsubscribed months ago.

> 
> Note first that I count Brian Goetz and Eric Ridge, two of the primary
> developers of WebMacro, as my friends, and I believe that they would
> describe me the same way.  I would suspect neither you or I would refer to
> our relationship that way.

Generally, I have not enjoyed my interaction with you. I find you 
annoying. For example, I find the pompous, self-righteousness, lecturing 
tone of this last message of yours very annoying, quite frankly. The 
fact remains. Jonah specifically and openly set out to flame my work. I 
note that he did try to do his homework but he did a rather botched job 
of it and got a lot of his facts wrong -- actually, most of them wrong. 
He then started lecturing me about where FreeMarker was heading, which 
admittedly was rather comical... :-)

> 
> Note second that I believe that overall, people view my participation on the
> WebMacro list positively.  You are free, of course, to validate that
> assertion if you want.

Well, what's your point then? If it is appropriate and even positive 
that the lead developer of Velocity is on the WebMacro list, then the 
same can be said for the lead developer of FreeMarker on the Velocity list.

<shrug>


>>So that is why I have no qualms about plugging FreeMarker on this list.
>>The Velocity people are in no moral position to cry foul.
> 
> 
> And you are free to do whatever you want on this list as long as you are
> polite and have a point that is related to Velocity.

I had a specific point to make that is pertinent to Velocity. Velocity 
does not allow you to break out of a loop. I could not resist pointing 
out that FreeMarker has this. That someone then takes the opportunity to 
"flame FreeMarker" and, to make matters worse, does not know what he's 
talking about leads to the result we observe here.

<shrug>

> 
> I think debate about this stuff is healthy, as long as we keep it on topic
> to Velocity (which is what this list is about) and you are not here simply
> trolling for users for Freemarker, as I would ask you respect the users time
> and inboxes.

Well, let me reiterate. Jonah specifically wrote a post saying that he 
was going to take the opportunity to "flame FreeMarker". That you 
seriously think that this is my fault is beyond me. Again, I made a 
point that was factual and pertinent, comparing Velocity with another 
product in the same application space.

<shrug>


> 
> 
>>I should also point out that the behavior of the Velocity people wrt
>>WebMacro is inherently more provocative and obnoxious, since, let's face
>>it, Velocity began life as a copy-cat WebMacro knock-off. And actually,
>>truth told, it still basically that. FreeMarker, OTOH, is not a copy of
>>anything.
> 
> 
> Indeed, one which you didn't invent.

I never claimed that I did. The history of the project is summarized on 
the FreeMarker web site.

<shrug>

> 
> :)
> 
> 
>>>
>>>>>We evaluated FreeMarker at various times over the past couple of years,
>>>>
>>>>I have been FreeMarker's lead developer for a little over 2 months.
>>>>FreeMarker 2 (codenamed Lazarus) is primarily my work.
>>>>
>>>>The evaluations you've performed in the past few years, are almost
>>>>certainly based on FreeMarker 1.x and you should realize that we're
>>>>talking about a moving target. Many of FreeMarker Classic's deficiencies
>>>>have been remedied in the Lazarus release. For one thing, Lazarus is
>>>>built around a formal grammar using JavaCC. The older hand-written
>>>>grammar went out the window. Also, the lack of arithmetic was addressed.
>>>>FreeMarker now supports integer and decimal variables and arithmetic.
>>>>
>>>
>>>
>>>They sound like good changes. Somewhat similar to the changes
>>>implemented in Velocity's "rewrite" of the WebMacro project.
>>
>>The move to javacc part, yes. The introduction of floating point
>>variables and arithmetic, no. Velocity still lacks floating point support.
> 
> 
> It does, and Freemarker lacks RMI and JMX management support.  The point is
> that we intentionally don't have floating point support, and you
> intentionally don't extend Remote...

Well, frankly I consider the above to be poppycock. AFAICT, Velocity 
supports integers and not floating point because the product you were 
copying supported integers and not floating point.

<shrug>

Like most imitators, you imitated both the strong points and the weak 
points of the product you were imitating.

Monkey see. Monkey do.

<shrug>

>>>>>I vaguely
>>>remember wondering about FreeMarker and arithmetic, but I don't remember
>>>what the concern was. I'm glad to hear there's more built-in support
>>>now.
>>
>>FM 1.x had no numerical variables, just some helper utility classes that
>>were a kind of workaround. FM 2 now supports integers and floating point
>>variables. In the core.
>>
>>
>>>
>>>>The issue at hand, the lack of the break construct, was a relatively
>>>>lower-order deficiency that was also addressed going from version 1.x to
>>>>2.x.
>>>>
>>>
>>>
>>>Agreed that it is very much a "lower-order" issue, not worth promoting
>>>as a critical benefit of the technology. :)
>>
>>This is a misrepresentation. I replied to a poster who wanted this
>>feature, saying that it was present in FreeMarker, but not in Velocity.
>>My answer was factual and, in my view, on-topic.
>>
> 
> 
> Please.  I'll happily spam your list with posts of tenuous topicality.

Somebody asked whether Velocity gave you a way of breaking out of a 
loop. I was happy to point out to the person in question that Velocity 
has no way of breaking out of a loop and I could not resist adding that 
FreeMarker does.

<shrug>

That somebody then takes the opportunity to "flame FreeMarker" is not 
something I have any control over. It is true that I did not *have to* 
answer. OTOH, Jonah's response contained many factual errors. It is also 
true (mea culpa) that I do not suffer fools gladly.


> 
> I'll make a template to do it.

Yeah, sure. It's a great time-saving device. :-)



> 
> 
>>As a matter of fact, I do not consider the break instruction to be such
>>a major thing, though it's still nice to have it. There are cases where
>>code can be written in a more readable way using it.
>>

<snip>

>>
>>The docs have not improved as much as the code base. We are turning our
>>attention to that.
>>
>>
>>>The HelloWorld sample is a much better sample, though perhaps it
>>>understates more than Velocity's Fundamental Pattern example the extent
>>>of integration someone should expect to perform when working with
>>>FreeMarker.
>>>
>>>Velocity's isn't perfect, of course- I have to do some funny things with
>>>Exception handling that were somewhat unexpected, but by and large the
>>>simplicity I've seen is what I've gotten.
>>
>>Let me reiterate that there is absolutely no need for you to justify to
>>me that you use Velocity.
>>
>>
>>>
>>>
>>>>In any case, FM 2 gives you the possibility of using the
>>>>reflection-based approach typical of Velocity and WebMacro -- even
>>>>though that approach may tend to expose more to the template layer than
>>>>is optimal. See:
>>>>
>>>>http://freemarker.sourceforge.net/docs/manual/beans.html
>>>>
>>>
>>>
>>>It's an excellent addition. To a first degree of approximation, that
>>>brings it a degree of parity with one of Velocity's best features. Some
>>>people may actually prefer having those helper classes in between their
>>>objects and their templates; others will not. I'm one of the latter, and
>>>appreciate Velocity's flexibility on that front.
>>
>>Actually, FreeMarker is more flexible since it provides the full
>>introspection approach, but also lets you define wrappers that expose
>>the minimal functionality to the template writer, rather than all the
>>public methods. You can use either approach depending on your needs.
> 
> 
> Er, can't you do the same thing with Velocity?

I don't think so. AFAIK, Velocity only provides the introspection-based 
approach. With FreeMarker, you can have an object implement one of three 
basic interfaces for scalar, list, and hash types and you can exactly 
control the functionality that is exposed to the template -- as opposed 
to exposing all of the object's public methods. However, FreeMarker also 
offers the introspection-based approach. So what is offered is basically 
a superset.

<snip>


>>You're quibbling again. There are terminological things that exist for
>>historical reasons and are probably not worth "fixing". The set of
>>people who care whether what is called a "function" in FM should really
>>be called a "macro" is very small. In fact, I suspect that you are not a
>>even a member of that set. You are simply making noise. The fact of the
>>matter is that, whether it's called a function or a macro, people just
>>use it.
>>
>><sigh>
>>


<snip>

>>
>>>The term has been adopted on the web as a metaphor for distributing work
>>>between people of different skills, since HTML was a language that
>>>non-programmers could constructively use to generate what in many areas
>>>used to be only producible by programmers. Data modelling and
>>>application logic unfortunately continue to be domains requiring various
>>>kinds of programmer talent to create appropriate solutions. This
>>>distribution of skills requires a deep level of coordination in any
>>>number of process models to have people work as efficiently as possible
>>>without stepping on one another's toes. To say that people who've been
>>>fit into an assembly line process with certain protocols for dialogue
>>>and production don't still have to be conscious of what their peers
>>>further up or downstream are doing to a certain extent- or to call those
>>>segregated roles not working closely together- is mistaken.
>>
>>I don't know what you're talking about. As a matter of fact, this was a
>>design goal of the assembly line. Henry Ford invented the assembly line
>>precisely in order to use the labor of extremely uneducated people --
>>poor rural people who were migrating to the cities. He designed a system
>>where these people only needed to know how to perform a very limited
>>task and that's it.
>>
>>(It does not bother me that you're wrong about this. What gets me is the
>>sense that you're arguing just for the sake of arguing.)
> 
> 
> Coming from you, I would think that would be a redeeming quality...

No, I don't like it when people speak and have nothing to say. 
Particularly when they say it pretentiously and adopt a lecturing tone, 
as in the text directly above.

> 
> 
>>>>>The
>>>>
>>>>>presence of a break command would be a nice convenience, but the fact is
>>>>>that a break is among the presentation-level state change mechanisms
>>>>>that must be available to template designers, and both sides often need
>>>>>to work together to determine what those are. Even in a pure MVC
>>>>>environment, the "business" logic involved in producing just
>>>>>presentation code may be complex, requiring solutions from both sides,
>>>>>design and programming.
>>>>
>>>>Yes, but again, the design goal is to minimize the need for them to work
>>>>together. Again, your argument is poorly constructed. It is baed on a
>>>>false syllogism.
>>>>
>>>
>>>
>>>No. If you put the programmers in one room and the designers in the
>>>other room and you set up one meeting at the beginning of the project
>>>for them to coordinate their work, and then you keep them off email and
>>>apart for 30 days, you're not going to have gotten anything usable.
>>>Once a team has worked together for a period of time, they develop
>>>enough trust and understanding to be able to solve problems with less
>>>interaction, but that also doesn't mean that they aren't working closely
>>>together. 
>>>
>>>MVC is a convenient management term to express the products of the work
>>>and the human roles involved, but the same issues apply in having people
>>>work together as having code work together. You have to develop the
>>>interfaces.
>>
>><LOL>
>>
>>You're one pretentious kid, Jonah!
> 
> 
> I called this one  a mile away.  I knew it was coming - you did the same
> thing to me.  Do you do this to everyone?

Well, yes, I guess I am. I speak sincerely with everybody. All of 
Jonah's text starting with "the term (MVC) has been adopted on the web 
as a metaphor for distributing work between...." stands out as being a 
bunch of empty, pretentious blather. I see no reason to pretend otherwise.

<shrug>

> 
> I don't know Jonah, but he's right on the money, and appears to be from
> direct experience.

Excuse me. What is it that he's right about? In all that pretentious 
stuff, it's not even clear what he's saying! To me, it sounds like a 
bunch of stuff he might have copied from a poorly written C.S. textbook....

<sigh>

> 
> Please stop comments like these.

Maybe you should tell participants on the list not to set out openly to 
flame other people's open source work. If that principle had been 
adhered to, this exchange would not have arisen, would it?

<shrug>


<snip>
>>
>>Well, your criticism is off-base. The built-in operator '?' was
>>introduced specifically so that certain things that template writers
>>frequently need, such as the size of a list or the upper case of a
>>string, would be available without having to expose the whole kitchen
>>sink of java public methods as occurs with tools like Velocity or WebMacro.
> 
> 
> This is such a strawman...

I don't think so. Could you explain why it's strawman, please?


> 
> 
>>>I don't see where FreeMarker wants to stop, whereas where Velocity wants
>>>to stop is very clear. In my eyes, perhaps FreeMarker ultimately wants
>>>to be something like Tea. More than an engine, less than an environment.
>>>Maybe it doesn't want to, but maybe it will end up there anyway.
>>
>>Maybe, maybe, maybe. Don't you think that it would be more appropriate
>>to ask *me* where FreeMarker is heading rather than lecture me about it? ;-)
>>
>>I really shouldn't say this, but... damn.... I'm going to say it...
>>
>><sigh>
>>
>>For some reason, Jakarta seems to be a magnet for a certain kind of
>>immature, obnoxious person.
> 
> 
> 
> I can't resist : welcome back!

Well, Geir, does it not strike you as rather odd that Jonah was 
lecturing *me* about where where FreeMarker is heading... Don't you 
think that I have maybe a bit of an advantage vis-a-vis Jonah or anybody 
else in terms of knowing where FM is heading?

<LOL>

I mean, the combined arrogance and stupidity that this conversation was 
reaching..... :-)


> 
> 
>>I mean, they're around all over the place,
>>but the density seems much higher on these mailing lists than other
>>comparable ones.
>>
>>Why is that?
> 
> 
> I dunno, but I am *sure* you are going to tell us...


Not me. I don't know why it's like that. It's just an observation I've made.


>>
>>Daniel Dekany made what I thought was a good point about this. The MVC
>>separation should not be used as a catch-all excuse for having an
>>underpowered template language. I agree with that.
> 
> 
> The question is where do you draw the line?  The notion of 'underpowered' is
> rather subjective.

I think most objective people would consider that the inability to do 
four-function calculator arithmetic is pretty suggestive of an 
underpowered template language.


<snip>
>>>>
>>>>So my knowledge of both the FreeMarker and Velocity code bases is
>>>>probably far superior to yours. My impression, having looked at the
>>>>Velocity code from the inside, is that the current FreeMarker 2 code
>>>>base is in a much more polished, mature state. These are both open
>>>>source products, so you are free to do a code review on the two code
>>>>bases and share your impressions.
>>>>
>>>
>>>
>>>That wasn't what I was saying, and for my purposes it doesn't really
>>>matter.
>>
>>That's naive. The code quality matters. In any case, I'm trying to make
>>sense of your overall message. To you, it's important that FM calls
>>something a "function" when it really should be called a "macro", yet
>>the actual quality of the code does not matter to you.
>>
>>Jonah, do you think that your overall position is sensible?
> 
> 
> Is this a rational question?

I think so. Jonah literally seems to be saying that code quality does 
not matter, yet the fact that we call a given thing a function instead 
of a macro does matter.

So I am asking him to reconsider his position. Seems rational to me. I 
have reconsidered my position at times and decided that I was wrong. It 
happens.

> 
> 
>><sigh>
>>
>>Well, look, I don't believe you really believe this. You're just in some
>>silly kid mode where you're saying anything at all, just to say
>>something.
> 
> 
> Strike two...

Well, the statement that code quality does not matter was strongly 
indicative to me that he was just saying anything.


> 
> 
>>The fact that you did not want me to reply to this message is
>>already indicative of that. In my experience, when somebody says "Nobody
>>can reply to what I'm about to say" it means that they're going to talk
>>a lot of nonsense and on some level, they themselves know that it's
>>nonsense.
> 
> 
> Or they have better things to do than argue with you. You have what appears
> to be an unlimited amount of time for such things.

Well, specifically in this spot, if they have better things to do, they 
wouldn't post the original message. I am specifically referring to a 
situation where people have the time to compose a message and send it 
and then tell people not to reply to it. That strikes me as utterly 
silly. Tell me, Geir. Does it make sense to you?

I'm not going to reply to anything else you've said below. I do have 
other things to do. :-)

Look, if people are saying specifically that they want to "flame 
FreeMarker" and then proceed to say a bunch of silly things, it is to be 
expected that I will respond to that. As for telling a silly pretentious 
kid that he's a silly pretentious kid, well, I'm doing him a favor. I 
mean, to lecture the lead developer of FreeMarker about where FreeMarker 
is heading is really getting close to the pinnacle of a certain kind 
of.... pretentious kid behavior... :-)

Have a nice day, :-)

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 1:15 PM, "Jonathan Revusky" <jr...@terra.es> wrote:

> jonah benton wrote:
>> To the list- I'm responding to these points below, but any further
>> debate will either be offline or dropped.
> 
> <sigh>
> 
> The above is ridiculous, Jonah. If you did not want me to reply to this
> message, you should not have posted it in the first place. I draw a very
> negative conclusion from this kind of childish attempt to get in the
> last word.

Ok.  Now you'll have the last word.  Can we stop now?  Probably not...

> 
>> 
> <snip for brevity>
> 
> 
>>>> This sudden entry onto the Velocity list by FreeMarker's lead developer
>>>> may be something of a joke, but as FreeMarker is publicly advertising
>>>> for users, I'm going to take this opportunity to flame it a little bit.
>>>> :)
>> 
>>> Well, I'll take the opportunity to inform you and possibly other people
>>> somewhat.
>> 
>> 
>> Frankly, I'm glad to hear FreeMarker is now seeing active attention.
>> There was a time when the only reachable source of information was
>> Google's cache of its old pages. The site itself was offline for quite a
>> while, as I recall.
> 
> Well, the situation you describe above may be the reason that FM 2 is
> codenamed Lazarus. :-) In any case, I was not actively involved in the
> project at that point. I was a reasonably contented end-user. Though not
> absolutely contented. I have addressed most of the things that bothered
> me about FM 1.x in version 2.
> 
>> 
>> I think a generic message announcing the new release to Velocity, JSP,
>> ColdFusion, ASP, perl-mod, etc lists, along with summary feature lists
>> and improvements, would be relevant and welcome. Lots of people would be
>> happy to hear of its revival, myself included. It's certainly a more
>> effective use of your marketing energy than making specific arguments on
>> minor syntactic issues on competing language mailing lists. That sort of
>> guerilla marketing should really be done by someone else. :)
> 
> Well, you could be right, but the fact is that Velocity advocates are
> not in any position to give this lecture to anybody. If you look at the
> archives of the WebMacro list, you will see quite a bit of activity by
> Velocity developers. AFAIK, Geir is still a regular on that list.

100% regular.

Count the number of posts to that list in the last 6 months that are from
me.  Go ahead.  Give it a whirl.  (And don't count the flame-fest between
us...)

Note first that I count Brian Goetz and Eric Ridge, two of the primary
developers of WebMacro, as my friends, and I believe that they would
describe me the same way.  I would suspect neither you or I would refer to
our relationship that way.

Note second that I believe that overall, people view my participation on the
WebMacro list positively.  You are free, of course, to validate that
assertion if you want.


> 
> So that is why I have no qualms about plugging FreeMarker on this list.
> The Velocity people are in no moral position to cry foul.

And you are free to do whatever you want on this list as long as you are
polite and have a point that is related to Velocity.

I think debate about this stuff is healthy, as long as we keep it on topic
to Velocity (which is what this list is about) and you are not here simply
trolling for users for Freemarker, as I would ask you respect the users time
and inboxes.

> 
> I should also point out that the behavior of the Velocity people wrt
> WebMacro is inherently more provocative and obnoxious, since, let's face
> it, Velocity began life as a copy-cat WebMacro knock-off. And actually,
> truth told, it still basically that. FreeMarker, OTOH, is not a copy of
> anything.

Indeed, one which you didn't invent.

:)

> 
>> 
>> 
>>> 
>>>> We evaluated FreeMarker at various times over the past couple of years,
>>> 
>>> I have been FreeMarker's lead developer for a little over 2 months.
>>> FreeMarker 2 (codenamed Lazarus) is primarily my work.
>>> 
>>> The evaluations you've performed in the past few years, are almost
>>> certainly based on FreeMarker 1.x and you should realize that we're
>>> talking about a moving target. Many of FreeMarker Classic's deficiencies
>>> have been remedied in the Lazarus release. For one thing, Lazarus is
>>> built around a formal grammar using JavaCC. The older hand-written
>>> grammar went out the window. Also, the lack of arithmetic was addressed.
>>> FreeMarker now supports integer and decimal variables and arithmetic.
>>> 
>> 
>> 
>> They sound like good changes. Somewhat similar to the changes
>> implemented in Velocity's "rewrite" of the WebMacro project.
> 
> The move to javacc part, yes. The introduction of floating point
> variables and arithmetic, no. Velocity still lacks floating point support.

It does, and Freemarker lacks RMI and JMX management support.  The point is
that we intentionally don't have floating point support, and you
intentionally don't extend Remote...


> 
> 
>> I vaguely
>> remember wondering about FreeMarker and arithmetic, but I don't remember
>> what the concern was. I'm glad to hear there's more built-in support
>> now.
> 
> FM 1.x had no numerical variables, just some helper utility classes that
> were a kind of workaround. FM 2 now supports integers and floating point
> variables. In the core.
> 
>> 
>> 
>>> The issue at hand, the lack of the break construct, was a relatively
>>> lower-order deficiency that was also addressed going from version 1.x to
>>> 2.x.
>>> 
>> 
>> 
>> Agreed that it is very much a "lower-order" issue, not worth promoting
>> as a critical benefit of the technology. :)
> 
> This is a misrepresentation. I replied to a poster who wanted this
> feature, saying that it was present in FreeMarker, but not in Velocity.
> My answer was factual and, in my view, on-topic.
> 

Please.  I'll happily spam your list with posts of tenuous topicality.

I'll make a template to do it.

> As a matter of fact, I do not consider the break instruction to be such
> a major thing, though it's still nice to have it. There are cases where
> code can be written in a more readable way using it.
> 
>> 
>> 
>>>> prior to selecting Velocity last year. Very early on I thought that
>>>> FreeMarker looked like a reasonable templating option for Java-hosted
>>>> applications, and was especially keen on the tag syntax for a while. But
>>>> I shuddered when I looked at the hoops I'd have to go through to make
>>>> various kinds of data available to templates (see:
>>>> http://freemarker.sourceforge.net/docs/manual/guestbook.html )
>>> 
>>> 
>>> Well, that example is poorly chosen. Basically, it's an artificial
>>> example used to show somebody implementing the core interfaces
>>> themselves. In practice, people would just use the built-in
>>> implementations such as SimpleSequence and SimpleHash. IOW, nobody would
>>> ever write that code -- particularly for such a simple example.
>>> 
>> 
>> 
>> I would hope that no one would ever need to write that code, but I chose
>> it because it was the first sample code I had found at FreeMarker's
>> site, so I had to assume it was representative. So while I understand
>> that it may poorly represent the new capabilities or requirements of
>> your new release, perhaps constructing a better, more prominently
>> featured example is called for.
> 
> The docs have not improved as much as the code base. We are turning our
> attention to that.
> 
>> 
>> The HelloWorld sample is a much better sample, though perhaps it
>> understates more than Velocity's Fundamental Pattern example the extent
>> of integration someone should expect to perform when working with
>> FreeMarker.
>> 
>> Velocity's isn't perfect, of course- I have to do some funny things with
>> Exception handling that were somewhat unexpected, but by and large the
>> simplicity I've seen is what I've gotten.
> 
> Let me reiterate that there is absolutely no need for you to justify to
> me that you use Velocity.
> 
>> 
>> 
>> 
>>> In any case, FM 2 gives you the possibility of using the
>>> reflection-based approach typical of Velocity and WebMacro -- even
>>> though that approach may tend to expose more to the template layer than
>>> is optimal. See:
>>> 
>>> http://freemarker.sourceforge.net/docs/manual/beans.html
>>> 
>> 
>> 
>> It's an excellent addition. To a first degree of approximation, that
>> brings it a degree of parity with one of Velocity's best features. Some
>> people may actually prefer having those helper classes in between their
>> objects and their templates; others will not. I'm one of the latter, and
>> appreciate Velocity's flexibility on that front.
> 
> Actually, FreeMarker is more flexible since it provides the full
> introspection approach, but also lets you define wrappers that expose
> the minimal functionality to the template writer, rather than all the
> public methods. You can use either approach depending on your needs.

Er, can't you do the same thing with Velocity?
 
> 
>> 
>> 
>>>> Having also had the displeasure of managing ColdFusion projects in the
>>>> past, and seeing what designers were cooking up in JavaScript, I was
>>>> unexcited about a mindset that encouraged yet another way for
>>>> non-programmers to define arbitrarily complex "functions" in templates.
>>>> (To be clear, Velocity permits defining "macros", but as the saying
>>>> goes, I've met macros, macros are not functions, and Velocity is better
>>>> for it.) 
>>> 
>>> You're misinformed, Jonah. FreeMarker "functions" are pretty much
>>> exactly equivalent to Velocity "macros". Truth told, they should be
>>> called macros (or possibly procedures.) Naming them "functions" was
>>> incorrect but that didn't happen on my clock. :-)
>>> 
>> 
>> 
>> Yes, the term function is incorrect. Those abstractions may not even be
>> procedures. Perhaps I wasn't clear enough in my objection to the term-
>> its use invites designers to solve problems in ways that JavaScript is
>> often used to solve problems.
>> 
>> The designers I've worked with know about "functions" from JavaScript. I
>> appreciate that you or others may not see this as a negative, but I've
>> seen a lot of bad JavaScript. When you call something a function, the
>> designers I know will go ahead and assume they can do with functions
>> what they normally do with functions in, e.g. JavaScript. For instance,
>> if they can't return a value because the syntax prevents it, they'll
>> just set a variable and use it later, a la TCL and its "upvar"
>> capability. 
>> 
>> It really doesn't matter on who's watch the mistake originally occurred.
>> It's your project now. If the term is incorrect, then change it- surely
>> if you've done the work to write a code conversion utility from Velocity
>> to FreeMarker, with the expectation that Velocity users will beat a path
>> to your better mousetrap- then offering your own users a simple,
>> automatic code migration path to correct the mistakes of the past should
>> be feasible, yes? :)
> 
> You're quibbling again. There are terminological things that exist for
> historical reasons and are probably not worth "fixing". The set of
> people who care whether what is called a "function" in FM should really
> be called a "macro" is very small. In fact, I suspect that you are not a
> even a member of that set. You are simply making noise. The fact of the
> matter is that, whether it's called a function or a macro, people just
> use it.
> 
> <sigh>
> 
> 
>> 
>>>> To speak to your comment directly, Jonathan- on the one hand, to speak
>>>> of the absence of a break command as a deficiency in the language,
>>>> requiring an unnecessary or unfortunate degree of Java programmer
>>>> involvement- it's not a serious comment.
>>> 
>>> No, I was quite serious. I implemented the feature because users wanted
>>> it. Quite clearly, various users have expressed just today on this list
>>> that it would be a very nice thing to have. So, the view that this is a
>>> deficiency in the template language is quite serious and seems to be
>>> borne out by the reactions I observe. In fact, I do not know what your
>>> grounds are for saying that it is not a deficiency. You seem to be
>>> basing this on a false syllogism.
>>> 
>>> Anyway, you can disagree with my point, but it was a completely serious
>>> comment made in the utmost sincerity.
>>> 
>> 
>> 
>> By "serious" I mean serious enough to warrant the implication in your
>> earliest message, that the absence of a break command is a good reason
>> to switch templating languages.
> 
> Jonah, for a guy who is so nitpicking about language -- who takes issue
> with the fact that what we're calling "functions" should really be
> called "macros" -- you are very sloppy in your own discourse.
> 
> I *never* stated that the absence of the break command was a good reason
> to switch templating languages. I simply pointed out that FM has the
> feature and Velocity does not.
> 
> As regards reasons to switch, I consider it more likely that people will
> switch because they want full numerical support.
> 
>> 
>> 
>>>> Of course, the presence of a
>>>> break or additional flow control could be a nice convenience, but there
>>>> are no shortage of issues in web application development requiring Java
>>>> programmer involvement, starting with the data model, workflow,
>>>> scalability issues, and the like. Java programmers for many reasons
>>>> often need to be aware of what template designers are going to be up to
>>>> when they build particular pages, and they have to work together.
>>> 
>>> I'm sorry. Your argument above contains a false syllogism. You are
>>> arguing that because it is necessary for Java programmers and designers
>>> to work together on occasion, therefore the need to address this issue
>>> on the java level is not a deficiency. Well, it is, because the *goal*
>>> of MVC is in fact to *minimize* the necessity of the two teams
>>> (graphical and coding) to work closely together.
>>> 
>> 
>> 
>> No no. The *original* motivation behind the articulation of the MVC
>> pattern was to solve code structuring problems that people were first
>> discovering with object oriented languages like Smalltalk and its
>> predecessors in building traditional GUIs. The model suggests how to
>> build the intimate integration needed between conceptually distinct
>> functional units in order to wind up with maintainable code that
>> produces a responsive UI.
> 
> Thanks for the history lesson, but I think we were talking about the web
> space. Tools like FreeMarker and Velocity exist to facilitate a
> situation where the two teams can work as independently as possible.
> 
>> 
>> The term has been adopted on the web as a metaphor for distributing work
>> between people of different skills, since HTML was a language that
>> non-programmers could constructively use to generate what in many areas
>> used to be only producible by programmers. Data modelling and
>> application logic unfortunately continue to be domains requiring various
>> kinds of programmer talent to create appropriate solutions. This
>> distribution of skills requires a deep level of coordination in any
>> number of process models to have people work as efficiently as possible
>> without stepping on one another's toes. To say that people who've been
>> fit into an assembly line process with certain protocols for dialogue
>> and production don't still have to be conscious of what their peers
>> further up or downstream are doing to a certain extent- or to call those
>> segregated roles not working closely together- is mistaken.
> 
> I don't know what you're talking about. As a matter of fact, this was a
> design goal of the assembly line. Henry Ford invented the assembly line
> precisely in order to use the labor of extremely uneducated people --
> poor rural people who were migrating to the cities. He designed a system
> where these people only needed to know how to perform a very limited
> task and that's it.
> 
> (It does not bother me that you're wrong about this. What gets me is the
> sense that you're arguing just for the sake of arguing.)

Coming from you, I would think that would be a redeeming quality...

> 
>> 
>>>> The
>>> 
>>>> presence of a break command would be a nice convenience, but the fact is
>>>> that a break is among the presentation-level state change mechanisms
>>>> that must be available to template designers, and both sides often need
>>>> to work together to determine what those are. Even in a pure MVC
>>>> environment, the "business" logic involved in producing just
>>>> presentation code may be complex, requiring solutions from both sides,
>>>> design and programming.
>>> 
>>> Yes, but again, the design goal is to minimize the need for them to work
>>> together. Again, your argument is poorly constructed. It is baed on a
>>> false syllogism.
>>> 
>> 
>> 
>> No. If you put the programmers in one room and the designers in the
>> other room and you set up one meeting at the beginning of the project
>> for them to coordinate their work, and then you keep them off email and
>> apart for 30 days, you're not going to have gotten anything usable.
>> Once a team has worked together for a period of time, they develop
>> enough trust and understanding to be able to solve problems with less
>> interaction, but that also doesn't mean that they aren't working closely
>> together. 
>> 
>> MVC is a convenient management term to express the products of the work
>> and the human roles involved, but the same issues apply in having people
>> work together as having code work together. You have to develop the
>> interfaces.
> 
> <LOL>
> 
> You're one pretentious kid, Jonah!

I called this one  a mile away.  I knew it was coming - you did the same
thing to me.  Do you do this to everyone?

I don't know Jonah, but he's right on the money, and appears to be from
direct experience.

Please stop comments like these.

> 
>> 
>> 
>> 
>>>> More generally, at this point in web development, I am much more
>>>> comfortable with a simpler template language that requires some
>>>> solutions in Java to "work around [its] deficiencies", than a more
>>>> sophisticated template language that encourages designers to grow their
>>>> creative instincts into unmaintainable code without programmer
>>>> involvement. FreeMarker is much more restrained than PhP, ColdFusion,
>>>> and others in that ilk, but the mindset encouraging non-programmers to
>>>> find programmatic solutions is certainly present in its design.
>>> 
>>> From your comments, I doubt that you are familiar with FreeMarker. The
>>> FreeMarker template language is approximately at the level of complexity
>>> of Velocity. It is not at all comparable to PHP etcetera.
>>> 
>> 
>> 
>> Certainly FreeMarker and PHP are not in the same ballpark, but
>> FreeMarker has markedly more of a programming system feel to it than
>> Velocity, and its trend, to my eyes, is towards a richer environment,
>> while Velocity's trend is not. There is more to FM than the language;
>> the various Models that date to FM Classic are case in point. Even at
>> the language level, FM's new ? "operator" is a good example of syntactic
>> sugar that Velocity remains largely free of. As syntactic sugar accretes
>> in response to user requests, and the feedback cycle continues, the
>> product morphs into something new.
> 
> Well, your criticism is off-base. The built-in operator '?' was
> introduced specifically so that certain things that template writers
> frequently need, such as the size of a list or the upper case of a
> string, would be available without having to expose the whole kitchen
> sink of java public methods as occurs with tools like Velocity or WebMacro.

This is such a strawman...

> 
>> 
>> I don't see where FreeMarker wants to stop, whereas where Velocity wants
>> to stop is very clear. In my eyes, perhaps FreeMarker ultimately wants
>> to be something like Tea. More than an engine, less than an environment.
>> Maybe it doesn't want to, but maybe it will end up there anyway.
> 
> Maybe, maybe, maybe. Don't you think that it would be more appropriate
> to ask *me* where FreeMarker is heading rather than lecture me about it? ;-)
> 
> I really shouldn't say this, but... damn.... I'm going to say it...
> 
> <sigh>
> 
> For some reason, Jakarta seems to be a magnet for a certain kind of
> immature, obnoxious person.


I can't resist : welcome back!


> I mean, they're around all over the place,
> but the density seems much higher on these mailing lists than other
> comparable ones.
> 
> Why is that?

I dunno, but I am *sure* you are going to tell us...
 
> 
>> Velocity wants to be like the great class libraries of the pre-StdC++
>> days. So while the products are similar now, I would expect in two
>> year's time they would look quite different.
> 
> That's probably quite true. FreeMarker is moving forward quite quickly.
> 
>> 
>> 
>>> As I have said earlier today, FM in fact tends to enforce more of a
>>> model-view separation than Velocity does because it does not, by
>>> default, expose all the public methods of an object.
>> 
>> 
>> If I define them as public, it means I want other people to have access
>> to them. 
> 
> Apples and oranges again. You want other java programmers to have access
> to your public methods in a class. You don't necessarily want a template
> writer to be using them.
> 
>> Frankly I'm glad that it looks like it's less work now (e.g.
>> almost none) in FM to expose all the public methods of an object that I
>> make. Good move. :)
> 
> Truth told, Attila Szegedi's reflection-based classes were available
> earlier under the contrib directory. They were promoted to being a full
> part of the distro in FM 2.
> 
>> 
>> 
>>>> I've found Velocity's aggressive segregation of church and state
>>>> (designers and programmers) to be useful, its trivial integration with
>>>> virtually any Java application environment a great help, and the model
>>>> for making data available to templates as simple as it ought to be.
>>> 
>>> Well, the inability to break out of a loop and suggesting that this is
>>> something that must be resolved on the java level is something of a flaw
>>> in terms of that separation.
>> 
>> 
>> Maybe. Better safe than sorry. I've had quite a few problems crop up
>> where non-programmers invented solutions to problems because they had
>> the syntax available to do so, but their solutions weren't appropriate,
>> and what they had discovered was a flaw in the model. More reason to
>> have close communication between designers and programmers, to get
>> perspective on things like that.
> 
> Daniel Dekany made what I thought was a good point about this. The MVC
> separation should not be used as a catch-all excuse for having an
> underpowered template language. I agree with that.

The question is where do you draw the line?  The notion of 'underpowered' is
rather subjective.

> 
> 
>> 
>> 
>>>> A
>>> 
>>>> surprising benefit was that once I started using Velocity in contexts
>>>> other than HTML page generation, I was glad I wasn't using a tag syntax,
>>>> which just doesn't work as well in other contexts.
>>> 
>>> This is a red herring, frankly. The syntax is more or less irrelevant.
>> 
>> 
>> The issue is not irrelevant to the purpose of my post, which was to
>> point out, in contrast to your advertisement, my experiences evaluating
>> FreeMarker, and to point out the reasons we selected Velocity. And
>> something I was surprised to realize is that it would be confusing to
>> have a tag language embedded in something like pure XML. The closer HTML
>> gets to XML, the better it is that my embedded language isn't tag-based.
> 
> A matter of personal taste, I think. Many people like FreeMarker syntax
> specifically because, in terms of explaining it to designers, you just
> sort of introduce it as a few extra tags.
> 
> In practice, within the first few days, people get used to whatever
> syntax there is, so I don't think it's worth making a lot of hay about it.
> 
> 
>> 
>>>> Also, at the time of my evaluation, FreeMarker 2.0 was still under
>>>> development. Looks like 2.0 final was just released in April-
>>>> congratulations. Velocity is still in the version 1.x stage, but it's
>>>> essentially WebMacro 2.0, and has a reasonable degree of maturity. That
>>>> it's under the apache project umbrella helps as well.
>>> 
>>> I recently was in the Velocity code in order to write a Velocity->FM
>>> converter. In fact, the Vel->FM converter is a hacked version of
>>> velocity itself. It uses the velocity code to build the abstract syntax
>>> tree and then traverses the tree and outputs it in FM syntax.
>>> 
>>> So my knowledge of both the FreeMarker and Velocity code bases is
>>> probably far superior to yours. My impression, having looked at the
>>> Velocity code from the inside, is that the current FreeMarker 2 code
>>> base is in a much more polished, mature state. These are both open
>>> source products, so you are free to do a code review on the two code
>>> bases and share your impressions.
>>> 
>> 
>> 
>> That wasn't what I was saying, and for my purposes it doesn't really
>> matter.
> 
> That's naive. The code quality matters. In any case, I'm trying to make
> sense of your overall message. To you, it's important that FM calls
> something a "function" when it really should be called a "macro", yet
> the actual quality of the code does not matter to you.
> 
> Jonah, do you think that your overall position is sensible?

Is this a rational question?

> 
> <sigh>
> 
> Well, look, I don't believe you really believe this. You're just in some
> silly kid mode where you're saying anything at all, just to say
> something.

Strike two...

> The fact that you did not want me to reply to this message is
> already indicative of that. In my experience, when somebody says "Nobody
> can reply to what I'm about to say" it means that they're going to talk
> a lot of nonsense and on some level, they themselves know that it's
> nonsense.

Or they have better things to do than argue with you. You have what appears
to be an unlimited amount of time for such things.

 
>> To take an apocryphal example, Microsoft Word may be horribly
>> coded, but it's a much more polished product than AbiWord.
> 
> Word is not an open source product. FreeMarker and Velocity are. You can
> compare the code quality. And yes, code quality does matter.
> 
>> The fact that
>> Velocity is many more months into its rewrite than FreeMarker,
> 
> The fact that it is many more months into its rewrite and the code is so
> much messier indicates that the project is in much more of a mess.
> That's the conclusion *I* draw.
> 
>> with what
>> I've seen of the dedicated energy of its author, *does* matter to me.
>> And I don't need to review the code because I have seen at this point
>> that if something's broken, it's going to get fixed- almost before
>> anyone realized it was broken. I don't know how Geir does that, some
>> kind of mind-meld, perhaps. :)
>> 
>> 
>>>> That said, there are some features in FreeMarker that I would probably
>>>> use were they available in Velocity, but the careful, conservative
>>>> approach with the engine, the ways Velocity makes it easy for me,
>>>> working in Java, to use it everywhere I want to, and the mindset that
>>>> supports managing designers rather than permitting their creative are
>>>> much more important than specific features. And Velocity is flexible
>>>> enough that if I need those features, I can add them myself.
>>> 
>>> If Velocity is satisfactory for your needs, you are no under obligation
>>> to justify your choice to me. However, this conversation shows me that
>>> you do have certain misconceptions. Certainly, your idea that a
>>> FreeMarker "function" is somehow something completely different from a
>>> Velocity "macro" is a complete misconception.
>>> 
>> 
>> 
>> Perhaps- I apologize if my comment could be construed as implying
>> anything other than: it actually didn't matter to me what FreeMarker's
>> "functions" actually did for the purposes of my evaluation- whether or
>> not they really are functions is irrelevant. The fact that they are
>> called functions is either careless if they aren't, or undesirable if
>> they are. That capability is not something I'm looking to support in a
>> templating language, and that carelessness is not something I'm
>> interested in using.
> 
> Well again, you're trying to make a big deal about whether something is
> called a "function" or a "macro" after expressing that the actual
> quality of the code does not matter.
> 
> <big sigh>
> 
> Do you have any more idiotic things to say or are you through now?
> 
> 
>> 
>> To rectify the situation- if you're serious about the statement that
>> they're misnamed, then you should correct it, not justify by saying it
>> occurred before you took over. Deprecate their use, provide a code
>> conversion utility, and move on.
> 
> I considered that, but it's not worth the bother. *Nobody* cares whether
> they write:
> 
> <function foo>
> ...
> </function>
> 
> or
> 
> <macro foo>
> ....
> </macro>
> 
> There are a lot of legacy templates and it's just not worth the bother.
> Nobody cares. I'm 99% sure that even you don't actually care. You're
> just trying to make some sort of noise.
> 
>> 
>> 
>> 
>>> So, if you imagine yourself in my position, you surely would understand
>>> that I would feel obliged to correct you.
>>> 
>> 
>> 
>> I appreciate that you want to grow your user base, present the strongest
>> face possible for your product, and correct any misconceptions you
>> perceive others to have. Honestly I think there are better ways to
>> present your case than the day of posts you've presented here- but I'm
>> not you and FreeMarker isn't my product. :)
> 
> Well, that's fair enough, but then you should realize that Velocity
> developers have done exactly this in the past. That is why I have no
> compunctions about it.
> 

Sort of a subjective morality?  Or are you judge, jury and executioner,
meting out rightful vengeance?

>> 
>>>> 
>>>> Of course there is also the unbelievable energy Geir commits to the
>>>> list. I guess it's good for Velocity that the FreeMarker project is not
>>>> so busy that its principal developer also has the time to troll here to
>>>> help support Velocity users. ;-)
>>> 
>>> Well, this is again based on faulty reasoning. FreeMarker 2.0 went final
>>> on April 18. After over a thousand downloads, there have been no bug
>>> reports. Zero, zilch, nada.
>>> 
>> 
>> 
>> My friend, I appreciate the degree of quality that can be achieved with
>> diligence, but if you are truly capable of writing 100% bug free
>> software, there are clearly more important things for you to be doing
>> than template engines. :)
> 
> What I said was true. After 2 weeks and well over a thousand downloads
> there are no open bugs against FreeMarker 2.x.
> 
>> 
>> 
>> 
>>> So actually, that I have the free time for this puts FreeMarker in a
>>> good light.
>>> 
>> 
>> 
>> Maybe. Have you gotten a lot of announcements of "sites powered by
>> FreeMarker"?
> 
> We've gotten some. There are doubtless plenty of sites powered by
> FreeMarker, though most of them would still be using FM 1.x. Version 2
> is still quite new.
> 
>> 
>> 
>>> (FM 2.0rc1 and 2.0rc2 did have various issues and I was busy correcting
>>> them. 2.0rc3 onwards had no reported bugs.)
>>> 
>>> Well, I hope this message was helpful.
> 
> Anyway, Jonah, you most certainly *can* reply to this message if you
> want. But you might be well advised to think twice about it. :-)
> 

For the good of us all.


Jonathan, you will reply to this I am sure.  I don't mind discussing any
valid points, but lets keep things concise and non-personal.  I know the
reaction will be that *I* got personal, but I really didn't.  Don't try to
cast intelligent, sincere people as 'kids'.  I can't speak for the entire
community, but I know personally I won't tolerate it.

> Ciao,
> 
> 
> Jonathan Revusky
> --
> Lead developer of FreeMarker http://freemarker.sourceforge.net/
> Build robust web appications with the
> Niggle Web Application Framework http://niggle.org/
> Available for Java/Internet Consulting
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

jonah benton wrote:
> To the list- I'm responding to these points below, but any further
> debate will either be offline or dropped.

<sigh>

The above is ridiculous, Jonah. If you did not want me to reply to this 
message, you should not have posted it in the first place. I draw a very 
negative conclusion from this kind of childish attempt to get in the 
last word.

> 
<snip for brevity>


>>>This sudden entry onto the Velocity list by FreeMarker's lead developer
>>>may be something of a joke, but as FreeMarker is publicly advertising
>>>for users, I'm going to take this opportunity to flame it a little bit. 
>>>:)
>
>>Well, I'll take the opportunity to inform you and possibly other people 
>>somewhat.
> 
> 
> Frankly, I'm glad to hear FreeMarker is now seeing active attention.
> There was a time when the only reachable source of information was
> Google's cache of its old pages. The site itself was offline for quite a
> while, as I recall. 

Well, the situation you describe above may be the reason that FM 2 is 
codenamed Lazarus. :-) In any case, I was not actively involved in the 
project at that point. I was a reasonably contented end-user. Though not 
absolutely contented. I have addressed most of the things that bothered 
me about FM 1.x in version 2.

> 
> I think a generic message announcing the new release to Velocity, JSP,
> ColdFusion, ASP, perl-mod, etc lists, along with summary feature lists
> and improvements, would be relevant and welcome. Lots of people would be
> happy to hear of its revival, myself included. It's certainly a more
> effective use of your marketing energy than making specific arguments on
> minor syntactic issues on competing language mailing lists. That sort of
> guerilla marketing should really be done by someone else. :)

Well, you could be right, but the fact is that Velocity advocates are 
not in any position to give this lecture to anybody. If you look at the 
archives of the WebMacro list, you will see quite a bit of activity by 
Velocity developers. AFAIK, Geir is still a regular on that list.

So that is why I have no qualms about plugging FreeMarker on this list. 
The Velocity people are in no moral position to cry foul.

I should also point out that the behavior of the Velocity people wrt 
WebMacro is inherently more provocative and obnoxious, since, let's face 
it, Velocity began life as a copy-cat WebMacro knock-off. And actually, 
truth told, it still basically that. FreeMarker, OTOH, is not a copy of 
anything.

> 
> 
>>
>>>We evaluated FreeMarker at various times over the past couple of years,
>>
>>I have been FreeMarker's lead developer for a little over 2 months. 
>>FreeMarker 2 (codenamed Lazarus) is primarily my work.
>>
>>The evaluations you've performed in the past few years, are almost 
>>certainly based on FreeMarker 1.x and you should realize that we're 
>>talking about a moving target. Many of FreeMarker Classic's deficiencies 
>>have been remedied in the Lazarus release. For one thing, Lazarus is 
>>built around a formal grammar using JavaCC. The older hand-written 
>>grammar went out the window. Also, the lack of arithmetic was addressed. 
>>FreeMarker now supports integer and decimal variables and arithmetic.
>>
> 
> 
> They sound like good changes. Somewhat similar to the changes
> implemented in Velocity's "rewrite" of the WebMacro project. 

The move to javacc part, yes. The introduction of floating point 
variables and arithmetic, no. Velocity still lacks floating point support.


> I vaguely
> remember wondering about FreeMarker and arithmetic, but I don't remember
> what the concern was. I'm glad to hear there's more built-in support
> now.

FM 1.x had no numerical variables, just some helper utility classes that 
were a kind of workaround. FM 2 now supports integers and floating point 
variables. In the core.

> 
> 
>>The issue at hand, the lack of the break construct, was a relatively 
>>lower-order deficiency that was also addressed going from version 1.x to 
>>2.x.
>>
> 
> 
> Agreed that it is very much a "lower-order" issue, not worth promoting
> as a critical benefit of the technology. :)

This is a misrepresentation. I replied to a poster who wanted this 
feature, saying that it was present in FreeMarker, but not in Velocity. 
My answer was factual and, in my view, on-topic.

As a matter of fact, I do not consider the break instruction to be such 
a major thing, though it's still nice to have it. There are cases where 
code can be written in a more readable way using it.

> 
> 
>>>prior to selecting Velocity last year. Very early on I thought that
>>>FreeMarker looked like a reasonable templating option for Java-hosted
>>>applications, and was especially keen on the tag syntax for a while. But
>>>I shuddered when I looked at the hoops I'd have to go through to make
>>>various kinds of data available to templates (see:
>>>http://freemarker.sourceforge.net/docs/manual/guestbook.html )
>>
>>
>>Well, that example is poorly chosen. Basically, it's an artificial 
>>example used to show somebody implementing the core interfaces 
>>themselves. In practice, people would just use the built-in 
>>implementations such as SimpleSequence and SimpleHash. IOW, nobody would 
>>ever write that code -- particularly for such a simple example.
>>
> 
> 
> I would hope that no one would ever need to write that code, but I chose
> it because it was the first sample code I had found at FreeMarker's
> site, so I had to assume it was representative. So while I understand
> that it may poorly represent the new capabilities or requirements of
> your new release, perhaps constructing a better, more prominently
> featured example is called for.

The docs have not improved as much as the code base. We are turning our 
attention to that.

> 
> The HelloWorld sample is a much better sample, though perhaps it
> understates more than Velocity's Fundamental Pattern example the extent
> of integration someone should expect to perform when working with
> FreeMarker.
> 
> Velocity's isn't perfect, of course- I have to do some funny things with
> Exception handling that were somewhat unexpected, but by and large the
> simplicity I've seen is what I've gotten.

Let me reiterate that there is absolutely no need for you to justify to 
me that you use Velocity.

> 
> 
> 
>>In any case, FM 2 gives you the possibility of using the 
>>reflection-based approach typical of Velocity and WebMacro -- even 
>>though that approach may tend to expose more to the template layer than 
>>is optimal. See:
>>
>>http://freemarker.sourceforge.net/docs/manual/beans.html
>>
> 
> 
> It's an excellent addition. To a first degree of approximation, that
> brings it a degree of parity with one of Velocity's best features. Some
> people may actually prefer having those helper classes in between their
> objects and their templates; others will not. I'm one of the latter, and
> appreciate Velocity's flexibility on that front.

Actually, FreeMarker is more flexible since it provides the full 
introspection approach, but also lets you define wrappers that expose 
the minimal functionality to the template writer, rather than all the 
public methods. You can use either approach depending on your needs.


> 
> 
>>>Having also had the displeasure of managing ColdFusion projects in the
>>>past, and seeing what designers were cooking up in JavaScript, I was
>>>unexcited about a mindset that encouraged yet another way for
>>>non-programmers to define arbitrarily complex "functions" in templates.
>>>(To be clear, Velocity permits defining "macros", but as the saying
>>>goes, I've met macros, macros are not functions, and Velocity is better
>>>for it.) 
>>
>>You're misinformed, Jonah. FreeMarker "functions" are pretty much 
>>exactly equivalent to Velocity "macros". Truth told, they should be 
>>called macros (or possibly procedures.) Naming them "functions" was 
>>incorrect but that didn't happen on my clock. :-)
>>
> 
> 
> Yes, the term function is incorrect. Those abstractions may not even be
> procedures. Perhaps I wasn't clear enough in my objection to the term-
> its use invites designers to solve problems in ways that JavaScript is
> often used to solve problems. 
> 
> The designers I've worked with know about "functions" from JavaScript. I
> appreciate that you or others may not see this as a negative, but I've
> seen a lot of bad JavaScript. When you call something a function, the
> designers I know will go ahead and assume they can do with functions
> what they normally do with functions in, e.g. JavaScript. For instance,
> if they can't return a value because the syntax prevents it, they'll
> just set a variable and use it later, a la TCL and its "upvar"
> capability. 
> 
> It really doesn't matter on who's watch the mistake originally occurred.
> It's your project now. If the term is incorrect, then change it- surely
> if you've done the work to write a code conversion utility from Velocity
> to FreeMarker, with the expectation that Velocity users will beat a path
> to your better mousetrap- then offering your own users a simple,
> automatic code migration path to correct the mistakes of the past should
> be feasible, yes? :) 

You're quibbling again. There are terminological things that exist for 
historical reasons and are probably not worth "fixing". The set of 
people who care whether what is called a "function" in FM should really 
be called a "macro" is very small. In fact, I suspect that you are not a 
even a member of that set. You are simply making noise. The fact of the 
matter is that, whether it's called a function or a macro, people just 
use it.

<sigh>


> 
>>>To speak to your comment directly, Jonathan- on the one hand, to speak
>>>of the absence of a break command as a deficiency in the language,
>>>requiring an unnecessary or unfortunate degree of Java programmer
>>>involvement- it's not a serious comment. 
>>
>>No, I was quite serious. I implemented the feature because users wanted 
>>it. Quite clearly, various users have expressed just today on this list 
>>that it would be a very nice thing to have. So, the view that this is a 
>>deficiency in the template language is quite serious and seems to be 
>>borne out by the reactions I observe. In fact, I do not know what your 
>>grounds are for saying that it is not a deficiency. You seem to be 
>>basing this on a false syllogism.
>>
>>Anyway, you can disagree with my point, but it was a completely serious 
>>comment made in the utmost sincerity.
>>
> 
> 
> By "serious" I mean serious enough to warrant the implication in your
> earliest message, that the absence of a break command is a good reason
> to switch templating languages. 

Jonah, for a guy who is so nitpicking about language -- who takes issue 
with the fact that what we're calling "functions" should really be 
called "macros" -- you are very sloppy in your own discourse.

I *never* stated that the absence of the break command was a good reason 
to switch templating languages. I simply pointed out that FM has the 
feature and Velocity does not.

As regards reasons to switch, I consider it more likely that people will 
switch because they want full numerical support.

> 
> 
>>>Of course, the presence of a
>>>break or additional flow control could be a nice convenience, but there
>>>are no shortage of issues in web application development requiring Java
>>>programmer involvement, starting with the data model, workflow,
>>>scalability issues, and the like. Java programmers for many reasons
>>>often need to be aware of what template designers are going to be up to
>>>when they build particular pages, and they have to work together. 
>>
>>I'm sorry. Your argument above contains a false syllogism. You are 
>>arguing that because it is necessary for Java programmers and designers 
>>to work together on occasion, therefore the need to address this issue 
>>on the java level is not a deficiency. Well, it is, because the *goal* 
>>of MVC is in fact to *minimize* the necessity of the two teams 
>>(graphical and coding) to work closely together.
>>
> 
> 
> No no. The *original* motivation behind the articulation of the MVC
> pattern was to solve code structuring problems that people were first
> discovering with object oriented languages like Smalltalk and its
> predecessors in building traditional GUIs. The model suggests how to
> build the intimate integration needed between conceptually distinct
> functional units in order to wind up with maintainable code that
> produces a responsive UI. 

Thanks for the history lesson, but I think we were talking about the web 
space. Tools like FreeMarker and Velocity exist to facilitate a 
situation where the two teams can work as independently as possible.

> 
> The term has been adopted on the web as a metaphor for distributing work
> between people of different skills, since HTML was a language that
> non-programmers could constructively use to generate what in many areas
> used to be only producible by programmers. Data modelling and
> application logic unfortunately continue to be domains requiring various
> kinds of programmer talent to create appropriate solutions. This
> distribution of skills requires a deep level of coordination in any
> number of process models to have people work as efficiently as possible
> without stepping on one another's toes. To say that people who've been
> fit into an assembly line process with certain protocols for dialogue
> and production don't still have to be conscious of what their peers
> further up or downstream are doing to a certain extent- or to call those
> segregated roles not working closely together- is mistaken. 

I don't know what you're talking about. As a matter of fact, this was a 
design goal of the assembly line. Henry Ford invented the assembly line 
precisely in order to use the labor of extremely uneducated people -- 
poor rural people who were migrating to the cities. He designed a system 
where these people only needed to know how to perform a very limited 
task and that's it.

(It does not bother me that you're wrong about this. What gets me is the 
sense that you're arguing just for the sake of arguing.)

> 
>> > The
>>
>>>presence of a break command would be a nice convenience, but the fact is
>>>that a break is among the presentation-level state change mechanisms
>>>that must be available to template designers, and both sides often need
>>>to work together to determine what those are. Even in a pure MVC
>>>environment, the "business" logic involved in producing just
>>>presentation code may be complex, requiring solutions from both sides,
>>>design and programming.
>>
>>Yes, but again, the design goal is to minimize the need for them to work 
>>together. Again, your argument is poorly constructed. It is baed on a 
>>false syllogism.
>>
> 
> 
> No. If you put the programmers in one room and the designers in the
> other room and you set up one meeting at the beginning of the project
> for them to coordinate their work, and then you keep them off email and
> apart for 30 days, you're not going to have gotten anything usable. 
> Once a team has worked together for a period of time, they develop
> enough trust and understanding to be able to solve problems with less
> interaction, but that also doesn't mean that they aren't working closely
> together. 
> 
> MVC is a convenient management term to express the products of the work
> and the human roles involved, but the same issues apply in having people
> work together as having code work together. You have to develop the
> interfaces.

<LOL>

You're one pretentious kid, Jonah!

> 
> 
> 
>>>More generally, at this point in web development, I am much more
>>>comfortable with a simpler template language that requires some
>>>solutions in Java to "work around [its] deficiencies", than a more
>>>sophisticated template language that encourages designers to grow their
>>>creative instincts into unmaintainable code without programmer
>>>involvement. FreeMarker is much more restrained than PhP, ColdFusion,
>>>and others in that ilk, but the mindset encouraging non-programmers to
>>>find programmatic solutions is certainly present in its design. 
>>
>> From your comments, I doubt that you are familiar with FreeMarker. The 
>>FreeMarker template language is approximately at the level of complexity 
>>of Velocity. It is not at all comparable to PHP etcetera.
>>
> 
> 
> Certainly FreeMarker and PHP are not in the same ballpark, but
> FreeMarker has markedly more of a programming system feel to it than
> Velocity, and its trend, to my eyes, is towards a richer environment,
> while Velocity's trend is not. There is more to FM than the language;
> the various Models that date to FM Classic are case in point. Even at
> the language level, FM's new ? "operator" is a good example of syntactic
> sugar that Velocity remains largely free of. As syntactic sugar accretes
> in response to user requests, and the feedback cycle continues, the
> product morphs into something new. 

Well, your criticism is off-base. The built-in operator '?' was 
introduced specifically so that certain things that template writers 
frequently need, such as the size of a list or the upper case of a 
string, would be available without having to expose the whole kitchen 
sink of java public methods as occurs with tools like Velocity or WebMacro.

> 
> I don't see where FreeMarker wants to stop, whereas where Velocity wants
> to stop is very clear. In my eyes, perhaps FreeMarker ultimately wants
> to be something like Tea. More than an engine, less than an environment.
> Maybe it doesn't want to, but maybe it will end up there anyway.

Maybe, maybe, maybe. Don't you think that it would be more appropriate 
to ask *me* where FreeMarker is heading rather than lecture me about it? ;-)

I really shouldn't say this, but... damn.... I'm going to say it...

<sigh>

For some reason, Jakarta seems to be a magnet for a certain kind of 
immature, obnoxious person. I mean, they're around all over the place, 
but the density seems much higher on these mailing lists than other 
comparable ones.

Why is that?


> Velocity wants to be like the great class libraries of the pre-StdC++
> days. So while the products are similar now, I would expect in two
> year's time they would look quite different. 

That's probably quite true. FreeMarker is moving forward quite quickly.

> 
> 
>>As I have said earlier today, FM in fact tends to enforce more of a 
>>model-view separation than Velocity does because it does not, by 
>>default, expose all the public methods of an object.
> 
> 
> If I define them as public, it means I want other people to have access
> to them. 

Apples and oranges again. You want other java programmers to have access 
to your public methods in a class. You don't necessarily want a template 
writer to be using them.

> Frankly I'm glad that it looks like it's less work now (e.g.
> almost none) in FM to expose all the public methods of an object that I
> make. Good move. :)

Truth told, Attila Szegedi's reflection-based classes were available 
earlier under the contrib directory. They were promoted to being a full 
part of the distro in FM 2.

> 
> 
>>>I've found Velocity's aggressive segregation of church and state
>>>(designers and programmers) to be useful, its trivial integration with
>>>virtually any Java application environment a great help, and the model
>>>for making data available to templates as simple as it ought to be.
>>
>>Well, the inability to break out of a loop and suggesting that this is 
>>something that must be resolved on the java level is something of a flaw 
>>in terms of that separation.
> 
> 
> Maybe. Better safe than sorry. I've had quite a few problems crop up
> where non-programmers invented solutions to problems because they had
> the syntax available to do so, but their solutions weren't appropriate,
> and what they had discovered was a flaw in the model. More reason to
> have close communication between designers and programmers, to get
> perspective on things like that.

Daniel Dekany made what I thought was a good point about this. The MVC 
separation should not be used as a catch-all excuse for having an 
underpowered template language. I agree with that.


> 
> 
>> > A
>>
>>>surprising benefit was that once I started using Velocity in contexts
>>>other than HTML page generation, I was glad I wasn't using a tag syntax,
>>>which just doesn't work as well in other contexts. 
>>
>>This is a red herring, frankly. The syntax is more or less irrelevant.
> 
> 
> The issue is not irrelevant to the purpose of my post, which was to
> point out, in contrast to your advertisement, my experiences evaluating
> FreeMarker, and to point out the reasons we selected Velocity. And
> something I was surprised to realize is that it would be confusing to
> have a tag language embedded in something like pure XML. The closer HTML
> gets to XML, the better it is that my embedded language isn't tag-based.

A matter of personal taste, I think. Many people like FreeMarker syntax 
specifically because, in terms of explaining it to designers, you just 
sort of introduce it as a few extra tags.

In practice, within the first few days, people get used to whatever 
syntax there is, so I don't think it's worth making a lot of hay about it.


> 
>>>Also, at the time of my evaluation, FreeMarker 2.0 was still under
>>>development. Looks like 2.0 final was just released in April-
>>>congratulations. Velocity is still in the version 1.x stage, but it's
>>>essentially WebMacro 2.0, and has a reasonable degree of maturity. That
>>>it's under the apache project umbrella helps as well.
>>
>>I recently was in the Velocity code in order to write a Velocity->FM 
>>converter. In fact, the Vel->FM converter is a hacked version of 
>>velocity itself. It uses the velocity code to build the abstract syntax 
>>tree and then traverses the tree and outputs it in FM syntax.
>>
>>So my knowledge of both the FreeMarker and Velocity code bases is 
>>probably far superior to yours. My impression, having looked at the 
>>Velocity code from the inside, is that the current FreeMarker 2 code 
>>base is in a much more polished, mature state. These are both open 
>>source products, so you are free to do a code review on the two code 
>>bases and share your impressions.
>>
> 
> 
> That wasn't what I was saying, and for my purposes it doesn't really
> matter.

That's naive. The code quality matters. In any case, I'm trying to make 
sense of your overall message. To you, it's important that FM calls 
something a "function" when it really should be called a "macro", yet 
the actual quality of the code does not matter to you.

Jonah, do you think that your overall position is sensible?

<sigh>

Well, look, I don't believe you really believe this. You're just in some 
silly kid mode where you're saying anything at all, just to say 
something. The fact that you did not want me to reply to this message is 
already indicative of that. In my experience, when somebody says "Nobody 
can reply to what I'm about to say" it means that they're going to talk 
a lot of nonsense and on some level, they themselves know that it's 
nonsense.

> To take an apocryphal example, Microsoft Word may be horribly
> coded, but it's a much more polished product than AbiWord. 

Word is not an open source product. FreeMarker and Velocity are. You can 
compare the code quality. And yes, code quality does matter.

> The fact that
> Velocity is many more months into its rewrite than FreeMarker, 

The fact that it is many more months into its rewrite and the code is so 
much messier indicates that the project is in much more of a mess. 
That's the conclusion *I* draw.

> with what
> I've seen of the dedicated energy of its author, *does* matter to me.
> And I don't need to review the code because I have seen at this point
> that if something's broken, it's going to get fixed- almost before
> anyone realized it was broken. I don't know how Geir does that, some
> kind of mind-meld, perhaps. :)
> 
> 
>>>That said, there are some features in FreeMarker that I would probably
>>>use were they available in Velocity, but the careful, conservative
>>>approach with the engine, the ways Velocity makes it easy for me,
>>>working in Java, to use it everywhere I want to, and the mindset that
>>>supports managing designers rather than permitting their creative are
>>>much more important than specific features. And Velocity is flexible
>>>enough that if I need those features, I can add them myself.
>>
>>If Velocity is satisfactory for your needs, you are no under obligation 
>>to justify your choice to me. However, this conversation shows me that 
>>you do have certain misconceptions. Certainly, your idea that a 
>>FreeMarker "function" is somehow something completely different from a 
>>Velocity "macro" is a complete misconception.
>>
> 
> 
> Perhaps- I apologize if my comment could be construed as implying
> anything other than: it actually didn't matter to me what FreeMarker's
> "functions" actually did for the purposes of my evaluation- whether or
> not they really are functions is irrelevant. The fact that they are
> called functions is either careless if they aren't, or undesirable if
> they are. That capability is not something I'm looking to support in a
> templating language, and that carelessness is not something I'm
> interested in using. 

Well again, you're trying to make a big deal about whether something is 
called a "function" or a "macro" after expressing that the actual 
quality of the code does not matter.

<big sigh>

Do you have any more idiotic things to say or are you through now?


> 
> To rectify the situation- if you're serious about the statement that
> they're misnamed, then you should correct it, not justify by saying it
> occurred before you took over. Deprecate their use, provide a code
> conversion utility, and move on. 

I considered that, but it's not worth the bother. *Nobody* cares whether 
they write:

<function foo>
...
</function>

or

<macro foo>
....
</macro>

There are a lot of legacy templates and it's just not worth the bother. 
Nobody cares. I'm 99% sure that even you don't actually care. You're 
just trying to make some sort of noise.

> 
> 
> 
>>So, if you imagine yourself in my position, you surely would understand 
>>that I would feel obliged to correct you.
>>
> 
> 
> I appreciate that you want to grow your user base, present the strongest
> face possible for your product, and correct any misconceptions you
> perceive others to have. Honestly I think there are better ways to
> present your case than the day of posts you've presented here- but I'm
> not you and FreeMarker isn't my product. :)

Well, that's fair enough, but then you should realize that Velocity 
developers have done exactly this in the past. That is why I have no 
compunctions about it.

> 
>>> 
>>>Of course there is also the unbelievable energy Geir commits to the
>>>list. I guess it's good for Velocity that the FreeMarker project is not
>>>so busy that its principal developer also has the time to troll here to
>>>help support Velocity users. ;-)
>>
>>Well, this is again based on faulty reasoning. FreeMarker 2.0 went final 
>>on April 18. After over a thousand downloads, there have been no bug 
>>reports. Zero, zilch, nada.
>>
> 
> 
> My friend, I appreciate the degree of quality that can be achieved with
> diligence, but if you are truly capable of writing 100% bug free
> software, there are clearly more important things for you to be doing
> than template engines. :)

What I said was true. After 2 weeks and well over a thousand downloads 
there are no open bugs against FreeMarker 2.x.

> 
> 
> 
>>So actually, that I have the free time for this puts FreeMarker in a 
>>good light.
>>
> 
> 
> Maybe. Have you gotten a lot of announcements of "sites powered by
> FreeMarker"?

We've gotten some. There are doubtless plenty of sites powered by 
FreeMarker, though most of them would still be using FM 1.x. Version 2 
is still quite new.

> 
> 
>>(FM 2.0rc1 and 2.0rc2 did have various issues and I was busy correcting 
>>them. 2.0rc3 onwards had no reported bugs.)
>>
>>Well, I hope this message was helpful.

Anyway, Jonah, you most certainly *can* reply to this message if you 
want. But you might be well advised to think twice about it. :-)

Ciao,


Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[jonah benton <jo...@jonah.com>]

To the list- I'm responding to these points below, but any further
debate will either be offline or dropped.


On Fri, 2002-05-03 at 14:47, Jonathan Revusky wrote:
> jonah benton wrote:
> > On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
> > 
> >>jonah benton wrote:
> >>
> >>>We've had occasional need for it, but we're generally iterating over a
> >>>list maintained by an object we have in the context, so when we reach a 
> >>>state change where we want to stop iterating, we tell the object, and
> >>>the object arranges for the next call to hasNext() to return false.
> >>
> >>Yes, but that's apples and oranges. Essentially, what you're doing is 
> >>using your control of the java code layer to work around a deficiency in 
> >>the template language.
> >>
> > 
> > 
> > Better that than the other way around. :)
> 
> Maybe, but you're quibbling. My original point stands.

I'll respond in more detail below.

> 
> > 
> > 
> >>In the idealized MVC situation, the people working at the template layer 
> >>are completely separate people from those working at the java code layer.
> >>
> > 
> > 
> > Of course. Yet they must work together on issues more important than
> > this. 
> > 
> > More comments below.
> > 
> > 
> > This sudden entry onto the Velocity list by FreeMarker's lead developer
> > may be something of a joke, but as FreeMarker is publicly advertising
> > for users, I'm going to take this opportunity to flame it a little bit. 
> > :)
> 
> Well, I'll take the opportunity to inform you and possibly other people 
> somewhat.

Frankly, I'm glad to hear FreeMarker is now seeing active attention.
There was a time when the only reachable source of information was
Google's cache of its old pages. The site itself was offline for quite a
while, as I recall. 

I think a generic message announcing the new release to Velocity, JSP,
ColdFusion, ASP, perl-mod, etc lists, along with summary feature lists
and improvements, would be relevant and welcome. Lots of people would be
happy to hear of its revival, myself included. It's certainly a more
effective use of your marketing energy than making specific arguments on
minor syntactic issues on competing language mailing lists. That sort of
guerilla marketing should really be done by someone else. :)

> 
> 
> > 
> > We evaluated FreeMarker at various times over the past couple of years,
> 
> I have been FreeMarker's lead developer for a little over 2 months. 
> FreeMarker 2 (codenamed Lazarus) is primarily my work.
> 
> The evaluations you've performed in the past few years, are almost 
> certainly based on FreeMarker 1.x and you should realize that we're 
> talking about a moving target. Many of FreeMarker Classic's deficiencies 
> have been remedied in the Lazarus release. For one thing, Lazarus is 
> built around a formal grammar using JavaCC. The older hand-written 
> grammar went out the window. Also, the lack of arithmetic was addressed. 
> FreeMarker now supports integer and decimal variables and arithmetic.
> 

They sound like good changes. Somewhat similar to the changes
implemented in Velocity's "rewrite" of the WebMacro project. I vaguely
remember wondering about FreeMarker and arithmetic, but I don't remember
what the concern was. I'm glad to hear there's more built-in support
now.

> The issue at hand, the lack of the break construct, was a relatively 
> lower-order deficiency that was also addressed going from version 1.x to 
> 2.x.
> 

Agreed that it is very much a "lower-order" issue, not worth promoting
as a critical benefit of the technology. :)

> 
> > prior to selecting Velocity last year. Very early on I thought that
> > FreeMarker looked like a reasonable templating option for Java-hosted
> > applications, and was especially keen on the tag syntax for a while. But
> > I shuddered when I looked at the hoops I'd have to go through to make
> > various kinds of data available to templates (see:
> > http://freemarker.sourceforge.net/docs/manual/guestbook.html )
> 
> 
> Well, that example is poorly chosen. Basically, it's an artificial 
> example used to show somebody implementing the core interfaces 
> themselves. In practice, people would just use the built-in 
> implementations such as SimpleSequence and SimpleHash. IOW, nobody would 
> ever write that code -- particularly for such a simple example.
> 

I would hope that no one would ever need to write that code, but I chose
it because it was the first sample code I had found at FreeMarker's
site, so I had to assume it was representative. So while I understand
that it may poorly represent the new capabilities or requirements of
your new release, perhaps constructing a better, more prominently
featured example is called for.

The HelloWorld sample is a much better sample, though perhaps it
understates more than Velocity's Fundamental Pattern example the extent
of integration someone should expect to perform when working with
FreeMarker.

Velocity's isn't perfect, of course- I have to do some funny things with
Exception handling that were somewhat unexpected, but by and large the
simplicity I've seen is what I've gotten.


> In any case, FM 2 gives you the possibility of using the 
> reflection-based approach typical of Velocity and WebMacro -- even 
> though that approach may tend to expose more to the template layer than 
> is optimal. See:
> 
> http://freemarker.sourceforge.net/docs/manual/beans.html
> 

It's an excellent addition. To a first degree of approximation, that
brings it a degree of parity with one of Velocity's best features. Some
people may actually prefer having those helper classes in between their
objects and their templates; others will not. I'm one of the latter, and
appreciate Velocity's flexibility on that front.


> 
> > 
> > Having also had the displeasure of managing ColdFusion projects in the
> > past, and seeing what designers were cooking up in JavaScript, I was
> > unexcited about a mindset that encouraged yet another way for
> > non-programmers to define arbitrarily complex "functions" in templates.
> > (To be clear, Velocity permits defining "macros", but as the saying
> > goes, I've met macros, macros are not functions, and Velocity is better
> > for it.) 
> 
> You're misinformed, Jonah. FreeMarker "functions" are pretty much 
> exactly equivalent to Velocity "macros". Truth told, they should be 
> called macros (or possibly procedures.) Naming them "functions" was 
> incorrect but that didn't happen on my clock. :-)
> 

Yes, the term function is incorrect. Those abstractions may not even be
procedures. Perhaps I wasn't clear enough in my objection to the term-
its use invites designers to solve problems in ways that JavaScript is
often used to solve problems. 

The designers I've worked with know about "functions" from JavaScript. I
appreciate that you or others may not see this as a negative, but I've
seen a lot of bad JavaScript. When you call something a function, the
designers I know will go ahead and assume they can do with functions
what they normally do with functions in, e.g. JavaScript. For instance,
if they can't return a value because the syntax prevents it, they'll
just set a variable and use it later, a la TCL and its "upvar"
capability. 

It really doesn't matter on who's watch the mistake originally occurred.
It's your project now. If the term is incorrect, then change it- surely
if you've done the work to write a code conversion utility from Velocity
to FreeMarker, with the expectation that Velocity users will beat a path
to your better mousetrap- then offering your own users a simple,
automatic code migration path to correct the mistakes of the past should
be feasible, yes? :) 


> > 
> > To speak to your comment directly, Jonathan- on the one hand, to speak
> > of the absence of a break command as a deficiency in the language,
> > requiring an unnecessary or unfortunate degree of Java programmer
> > involvement- it's not a serious comment. 
> 
> No, I was quite serious. I implemented the feature because users wanted 
> it. Quite clearly, various users have expressed just today on this list 
> that it would be a very nice thing to have. So, the view that this is a 
> deficiency in the template language is quite serious and seems to be 
> borne out by the reactions I observe. In fact, I do not know what your 
> grounds are for saying that it is not a deficiency. You seem to be 
> basing this on a false syllogism.
> 
> Anyway, you can disagree with my point, but it was a completely serious 
> comment made in the utmost sincerity.
> 

By "serious" I mean serious enough to warrant the implication in your
earliest message, that the absence of a break command is a good reason
to switch templating languages. 

> 
> > Of course, the presence of a
> > break or additional flow control could be a nice convenience, but there
> > are no shortage of issues in web application development requiring Java
> > programmer involvement, starting with the data model, workflow,
> > scalability issues, and the like. Java programmers for many reasons
> > often need to be aware of what template designers are going to be up to
> > when they build particular pages, and they have to work together. 
> 
> I'm sorry. Your argument above contains a false syllogism. You are 
> arguing that because it is necessary for Java programmers and designers 
> to work together on occasion, therefore the need to address this issue 
> on the java level is not a deficiency. Well, it is, because the *goal* 
> of MVC is in fact to *minimize* the necessity of the two teams 
> (graphical and coding) to work closely together.
> 

No no. The *original* motivation behind the articulation of the MVC
pattern was to solve code structuring problems that people were first
discovering with object oriented languages like Smalltalk and its
predecessors in building traditional GUIs. The model suggests how to
build the intimate integration needed between conceptually distinct
functional units in order to wind up with maintainable code that
produces a responsive UI. 

The term has been adopted on the web as a metaphor for distributing work
between people of different skills, since HTML was a language that
non-programmers could constructively use to generate what in many areas
used to be only producible by programmers. Data modelling and
application logic unfortunately continue to be domains requiring various
kinds of programmer talent to create appropriate solutions. This
distribution of skills requires a deep level of coordination in any
number of process models to have people work as efficiently as possible
without stepping on one another's toes. To say that people who've been
fit into an assembly line process with certain protocols for dialogue
and production don't still have to be conscious of what their peers
further up or downstream are doing to a certain extent- or to call those
segregated roles not working closely together- is mistaken. 


>  > The
> > presence of a break command would be a nice convenience, but the fact is
> > that a break is among the presentation-level state change mechanisms
> > that must be available to template designers, and both sides often need
> > to work together to determine what those are. Even in a pure MVC
> > environment, the "business" logic involved in producing just
> > presentation code may be complex, requiring solutions from both sides,
> > design and programming.
> 
> Yes, but again, the design goal is to minimize the need for them to work 
> together. Again, your argument is poorly constructed. It is baed on a 
> false syllogism.
> 

No. If you put the programmers in one room and the designers in the
other room and you set up one meeting at the beginning of the project
for them to coordinate their work, and then you keep them off email and
apart for 30 days, you're not going to have gotten anything usable. 
Once a team has worked together for a period of time, they develop
enough trust and understanding to be able to solve problems with less
interaction, but that also doesn't mean that they aren't working closely
together. 

MVC is a convenient management term to express the products of the work
and the human roles involved, but the same issues apply in having people
work together as having code work together. You have to develop the
interfaces.


> > 
> > More generally, at this point in web development, I am much more
> > comfortable with a simpler template language that requires some
> > solutions in Java to "work around [its] deficiencies", than a more
> > sophisticated template language that encourages designers to grow their
> > creative instincts into unmaintainable code without programmer
> > involvement. FreeMarker is much more restrained than PhP, ColdFusion,
> > and others in that ilk, but the mindset encouraging non-programmers to
> > find programmatic solutions is certainly present in its design. 
> 
>  From your comments, I doubt that you are familiar with FreeMarker. The 
> FreeMarker template language is approximately at the level of complexity 
> of Velocity. It is not at all comparable to PHP etcetera.
> 

Certainly FreeMarker and PHP are not in the same ballpark, but
FreeMarker has markedly more of a programming system feel to it than
Velocity, and its trend, to my eyes, is towards a richer environment,
while Velocity's trend is not. There is more to FM than the language;
the various Models that date to FM Classic are case in point. Even at
the language level, FM's new ? "operator" is a good example of syntactic
sugar that Velocity remains largely free of. As syntactic sugar accretes
in response to user requests, and the feedback cycle continues, the
product morphs into something new. 

I don't see where FreeMarker wants to stop, whereas where Velocity wants
to stop is very clear. In my eyes, perhaps FreeMarker ultimately wants
to be something like Tea. More than an engine, less than an environment.
Maybe it doesn't want to, but maybe it will end up there anyway.
Velocity wants to be like the great class libraries of the pre-StdC++
days. So while the products are similar now, I would expect in two
year's time they would look quite different. 


> As I have said earlier today, FM in fact tends to enforce more of a 
> model-view separation than Velocity does because it does not, by 
> default, expose all the public methods of an object.

If I define them as public, it means I want other people to have access
to them. Frankly I'm glad that it looks like it's less work now (e.g.
almost none) in FM to expose all the public methods of an object that I
make. Good move. :)


> 
> > 
> > I've found Velocity's aggressive segregation of church and state
> > (designers and programmers) to be useful, its trivial integration with
> > virtually any Java application environment a great help, and the model
> > for making data available to templates as simple as it ought to be.
> 
> Well, the inability to break out of a loop and suggesting that this is 
> something that must be resolved on the java level is something of a flaw 
> in terms of that separation.

Maybe. Better safe than sorry. I've had quite a few problems crop up
where non-programmers invented solutions to problems because they had
the syntax available to do so, but their solutions weren't appropriate,
and what they had discovered was a flaw in the model. More reason to
have close communication between designers and programmers, to get
perspective on things like that.

> 
>  > A
> > surprising benefit was that once I started using Velocity in contexts
> > other than HTML page generation, I was glad I wasn't using a tag syntax,
> > which just doesn't work as well in other contexts. 
> 
> This is a red herring, frankly. The syntax is more or less irrelevant.


The issue is not irrelevant to the purpose of my post, which was to
point out, in contrast to your advertisement, my experiences evaluating
FreeMarker, and to point out the reasons we selected Velocity. And
something I was surprised to realize is that it would be confusing to
have a tag language embedded in something like pure XML. The closer HTML
gets to XML, the better it is that my embedded language isn't tag-based.

> 
> > 
> > Also, at the time of my evaluation, FreeMarker 2.0 was still under
> > development. Looks like 2.0 final was just released in April-
> > congratulations. Velocity is still in the version 1.x stage, but it's
> > essentially WebMacro 2.0, and has a reasonable degree of maturity. That
> > it's under the apache project umbrella helps as well.
> 
> I recently was in the Velocity code in order to write a Velocity->FM 
> converter. In fact, the Vel->FM converter is a hacked version of 
> velocity itself. It uses the velocity code to build the abstract syntax 
> tree and then traverses the tree and outputs it in FM syntax.
> 
> So my knowledge of both the FreeMarker and Velocity code bases is 
> probably far superior to yours. My impression, having looked at the 
> Velocity code from the inside, is that the current FreeMarker 2 code 
> base is in a much more polished, mature state. These are both open 
> source products, so you are free to do a code review on the two code 
> bases and share your impressions.
> 

That wasn't what I was saying, and for my purposes it doesn't really
matter. To take an apocryphal example, Microsoft Word may be horribly
coded, but it's a much more polished product than AbiWord. The fact that
Velocity is many more months into its rewrite than FreeMarker, with what
I've seen of the dedicated energy of its author, *does* matter to me.
And I don't need to review the code because I have seen at this point
that if something's broken, it's going to get fixed- almost before
anyone realized it was broken. I don't know how Geir does that, some
kind of mind-meld, perhaps. :)


> > 
> > That said, there are some features in FreeMarker that I would probably
> > use were they available in Velocity, but the careful, conservative
> > approach with the engine, the ways Velocity makes it easy for me,
> > working in Java, to use it everywhere I want to, and the mindset that
> > supports managing designers rather than permitting their creative are
> > much more important than specific features. And Velocity is flexible
> > enough that if I need those features, I can add them myself.
> 
> If Velocity is satisfactory for your needs, you are no under obligation 
> to justify your choice to me. However, this conversation shows me that 
> you do have certain misconceptions. Certainly, your idea that a 
> FreeMarker "function" is somehow something completely different from a 
> Velocity "macro" is a complete misconception.
> 

Perhaps- I apologize if my comment could be construed as implying
anything other than: it actually didn't matter to me what FreeMarker's
"functions" actually did for the purposes of my evaluation- whether or
not they really are functions is irrelevant. The fact that they are
called functions is either careless if they aren't, or undesirable if
they are. That capability is not something I'm looking to support in a
templating language, and that carelessness is not something I'm
interested in using. 

To rectify the situation- if you're serious about the statement that
they're misnamed, then you should correct it, not justify by saying it
occurred before you took over. Deprecate their use, provide a code
conversion utility, and move on. 


> So, if you imagine yourself in my position, you surely would understand 
> that I would feel obliged to correct you.
> 

I appreciate that you want to grow your user base, present the strongest
face possible for your product, and correct any misconceptions you
perceive others to have. Honestly I think there are better ways to
present your case than the day of posts you've presented here- but I'm
not you and FreeMarker isn't my product. :)


> 
> >  
> > Of course there is also the unbelievable energy Geir commits to the
> > list. I guess it's good for Velocity that the FreeMarker project is not
> > so busy that its principal developer also has the time to troll here to
> > help support Velocity users. ;-)
> 
> Well, this is again based on faulty reasoning. FreeMarker 2.0 went final 
> on April 18. After over a thousand downloads, there have been no bug 
> reports. Zero, zilch, nada.
> 

My friend, I appreciate the degree of quality that can be achieved with
diligence, but if you are truly capable of writing 100% bug free
software, there are clearly more important things for you to be doing
than template engines. :)


> So actually, that I have the free time for this puts FreeMarker in a 
> good light.
> 

Maybe. Have you gotten a lot of announcements of "sites powered by
FreeMarker"?

> (FM 2.0rc1 and 2.0rc2 did have various issues and I was busy correcting 
> them. 2.0rc3 onwards had no reported bugs.)
> 
> Well, I hope this message was helpful.
> 
> Regards,
> 
> Jonathan Revusky
> --
> Lead developer of FreeMarker http://freemarker.sourceforge.net/
> Build robust web appications with the
> Niggle Web Application Framework http://niggle.org/
> Available for Java/Internet Consulting
> 
> 

Cheers, 

Jonah

> 
> > 
> > Cheers,
> > 
> > Jonah
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

jonah benton wrote:
> On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
> 
>>jonah benton wrote:
>>
>>>We've had occasional need for it, but we're generally iterating over a
>>>list maintained by an object we have in the context, so when we reach a 
>>>state change where we want to stop iterating, we tell the object, and
>>>the object arranges for the next call to hasNext() to return false.
>>
>>Yes, but that's apples and oranges. Essentially, what you're doing is 
>>using your control of the java code layer to work around a deficiency in 
>>the template language.
>>
> 
> 
> Better that than the other way around. :)

Maybe, but you're quibbling. My original point stands.

> 
> 
>>In the idealized MVC situation, the people working at the template layer 
>>are completely separate people from those working at the java code layer.
>>
> 
> 
> Of course. Yet they must work together on issues more important than
> this. 
> 
> More comments below.
> 
> 
> This sudden entry onto the Velocity list by FreeMarker's lead developer
> may be something of a joke, but as FreeMarker is publicly advertising
> for users, I'm going to take this opportunity to flame it a little bit. 
> :)

Well, I'll take the opportunity to inform you and possibly other people 
somewhat.


> 
> We evaluated FreeMarker at various times over the past couple of years,

I have been FreeMarker's lead developer for a little over 2 months. 
FreeMarker 2 (codenamed Lazarus) is primarily my work.

The evaluations you've performed in the past few years, are almost 
certainly based on FreeMarker 1.x and you should realize that we're 
talking about a moving target. Many of FreeMarker Classic's deficiencies 
have been remedied in the Lazarus release. For one thing, Lazarus is 
built around a formal grammar using JavaCC. The older hand-written 
grammar went out the window. Also, the lack of arithmetic was addressed. 
FreeMarker now supports integer and decimal variables and arithmetic.

The issue at hand, the lack of the break construct, was a relatively 
lower-order deficiency that was also addressed going from version 1.x to 
2.x.


> prior to selecting Velocity last year. Very early on I thought that
> FreeMarker looked like a reasonable templating option for Java-hosted
> applications, and was especially keen on the tag syntax for a while. But
> I shuddered when I looked at the hoops I'd have to go through to make
> various kinds of data available to templates (see:
> http://freemarker.sourceforge.net/docs/manual/guestbook.html )


Well, that example is poorly chosen. Basically, it's an artificial 
example used to show somebody implementing the core interfaces 
themselves. In practice, people would just use the built-in 
implementations such as SimpleSequence and SimpleHash. IOW, nobody would 
ever write that code -- particularly for such a simple example.

In any case, FM 2 gives you the possibility of using the 
reflection-based approach typical of Velocity and WebMacro -- even 
though that approach may tend to expose more to the template layer than 
is optimal. See:

http://freemarker.sourceforge.net/docs/manual/beans.html


> 
> Having also had the displeasure of managing ColdFusion projects in the
> past, and seeing what designers were cooking up in JavaScript, I was
> unexcited about a mindset that encouraged yet another way for
> non-programmers to define arbitrarily complex "functions" in templates.
> (To be clear, Velocity permits defining "macros", but as the saying
> goes, I've met macros, macros are not functions, and Velocity is better
> for it.) 

You're misinformed, Jonah. FreeMarker "functions" are pretty much 
exactly equivalent to Velocity "macros". Truth told, they should be 
called macros (or possibly procedures.) Naming them "functions" was 
incorrect but that didn't happen on my clock. :-)

> 
> To speak to your comment directly, Jonathan- on the one hand, to speak
> of the absence of a break command as a deficiency in the language,
> requiring an unnecessary or unfortunate degree of Java programmer
> involvement- it's not a serious comment. 

No, I was quite serious. I implemented the feature because users wanted 
it. Quite clearly, various users have expressed just today on this list 
that it would be a very nice thing to have. So, the view that this is a 
deficiency in the template language is quite serious and seems to be 
borne out by the reactions I observe. In fact, I do not know what your 
grounds are for saying that it is not a deficiency. You seem to be 
basing this on a false syllogism.

Anyway, you can disagree with my point, but it was a completely serious 
comment made in the utmost sincerity.


> Of course, the presence of a
> break or additional flow control could be a nice convenience, but there
> are no shortage of issues in web application development requiring Java
> programmer involvement, starting with the data model, workflow,
> scalability issues, and the like. Java programmers for many reasons
> often need to be aware of what template designers are going to be up to
> when they build particular pages, and they have to work together. 

I'm sorry. Your argument above contains a false syllogism. You are 
arguing that because it is necessary for Java programmers and designers 
to work together on occasion, therefore the need to address this issue 
on the java level is not a deficiency. Well, it is, because the *goal* 
of MVC is in fact to *minimize* the necessity of the two teams 
(graphical and coding) to work closely together.

 > The
> presence of a break command would be a nice convenience, but the fact is
> that a break is among the presentation-level state change mechanisms
> that must be available to template designers, and both sides often need
> to work together to determine what those are. Even in a pure MVC
> environment, the "business" logic involved in producing just
> presentation code may be complex, requiring solutions from both sides,
> design and programming.

Yes, but again, the design goal is to minimize the need for them to work 
together. Again, your argument is poorly constructed. It is baed on a 
false syllogism.

> 
> More generally, at this point in web development, I am much more
> comfortable with a simpler template language that requires some
> solutions in Java to "work around [its] deficiencies", than a more
> sophisticated template language that encourages designers to grow their
> creative instincts into unmaintainable code without programmer
> involvement. FreeMarker is much more restrained than PhP, ColdFusion,
> and others in that ilk, but the mindset encouraging non-programmers to
> find programmatic solutions is certainly present in its design. 

 From your comments, I doubt that you are familiar with FreeMarker. The 
FreeMarker template language is approximately at the level of complexity 
of Velocity. It is not at all comparable to PHP etcetera.

As I have said earlier today, FM in fact tends to enforce more of a 
model-view separation than Velocity does because it does not, by 
default, expose all the public methods of an object.

> 
> I've found Velocity's aggressive segregation of church and state
> (designers and programmers) to be useful, its trivial integration with
> virtually any Java application environment a great help, and the model
> for making data available to templates as simple as it ought to be.

Well, the inability to break out of a loop and suggesting that this is 
something that must be resolved on the java level is something of a flaw 
in terms of that separation.

 > A
> surprising benefit was that once I started using Velocity in contexts
> other than HTML page generation, I was glad I wasn't using a tag syntax,
> which just doesn't work as well in other contexts. 

This is a red herring, frankly. The syntax is more or less irrelevant.

> 
> Also, at the time of my evaluation, FreeMarker 2.0 was still under
> development. Looks like 2.0 final was just released in April-
> congratulations. Velocity is still in the version 1.x stage, but it's
> essentially WebMacro 2.0, and has a reasonable degree of maturity. That
> it's under the apache project umbrella helps as well.

I recently was in the Velocity code in order to write a Velocity->FM 
converter. In fact, the Vel->FM converter is a hacked version of 
velocity itself. It uses the velocity code to build the abstract syntax 
tree and then traverses the tree and outputs it in FM syntax.

So my knowledge of both the FreeMarker and Velocity code bases is 
probably far superior to yours. My impression, having looked at the 
Velocity code from the inside, is that the current FreeMarker 2 code 
base is in a much more polished, mature state. These are both open 
source products, so you are free to do a code review on the two code 
bases and share your impressions.

> 
> That said, there are some features in FreeMarker that I would probably
> use were they available in Velocity, but the careful, conservative
> approach with the engine, the ways Velocity makes it easy for me,
> working in Java, to use it everywhere I want to, and the mindset that
> supports managing designers rather than permitting their creative are
> much more important than specific features. And Velocity is flexible
> enough that if I need those features, I can add them myself.

If Velocity is satisfactory for your needs, you are no under obligation 
to justify your choice to me. However, this conversation shows me that 
you do have certain misconceptions. Certainly, your idea that a 
FreeMarker "function" is somehow something completely different from a 
Velocity "macro" is a complete misconception.

So, if you imagine yourself in my position, you surely would understand 
that I would feel obliged to correct you.


>  
> Of course there is also the unbelievable energy Geir commits to the
> list. I guess it's good for Velocity that the FreeMarker project is not
> so busy that its principal developer also has the time to troll here to
> help support Velocity users. ;-)

Well, this is again based on faulty reasoning. FreeMarker 2.0 went final 
on April 18. After over a thousand downloads, there have been no bug 
reports. Zero, zilch, nada.

So actually, that I have the free time for this puts FreeMarker in a 
good light.

(FM 2.0rc1 and 2.0rc2 did have various issues and I was busy correcting 
them. 2.0rc3 onwards had no reported bugs.)

Well, I hope this message was helpful.

Regards,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting



> 
> Cheers,
> 
> Jonah
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Daniel Dekany <dd...@freemail.hu>]

Saturday, May 4, 2002, 4:46:54 AM, Mike Williams wrote:

>   >>> On Sat, 4 May 2002 02:42:49 +0200,
>   >>> "Daniel" == Daniel Dekany <dd...@freemail.hu> wrote:
>
>   Daniel> 1.: V layer tends to be simple (compared to C and M) but it is
>   Daniel> not always simple.
>
> How do you mean?  Can you describe what a "complex" view layer would do?

a) Flow control
E.g. you want to break the foreach loop... not that big complexity :)
but you still need some workaround to do it now. Also I'm sure
everybody can imagine a view with some labelled nested loops and/or
continue-s, etc.

b) Reusable components or how should I call them...
Then there are those JSP-tag or macro like things. Many of them are
for presentation so they are part of the view layer. You may have to
use them for, print menus, fill HTML form, print error messages of the
perviously badly filled form fields... etc. So they are not necessary
trivial. Before you say that Velocity has no deficiency here as it
has vm-s and tools: see below.

>   Daniel> I think many users would be more happy if Velocity offers a
>   Daniel> facility similar to JSP tag-libs.  [...] Programmers can write
>   Daniel> velocity tags, and non-programmer designers can use them.
>
> Well, Velocity provides the facility to use context-tools, which to me,
> answers this need admirably.  I've worked on systems that use custom JSP
> tags, and they were a maintenance nightmare.

Context-tools would be good but there are problems with them:
- By-position parameter passing (vs. by-name) can be awful in many
situations. Think about if many of you parameters are optional. BTW
this is a purely syntactical problem: E.g. <$foo a=1 b=2/> could be
written now as $foo(["a",1, "b",2]) but it is so ugly...
- Context-tools calls has no "body" (I mean the thing between
the start and end tag: <$foo>This is the body</foo>). This can be
solved if I use a $foo_begin and $foo_end, but it is awkward.
- They can't do flow control. I mean that you can't skip/loop the
"body".

(Just think aloud: Tools can't print to the output stream or do an
#include or a #parse in such an easy way as a vm can. So if someone
ever wants to implement "Velociy-tags" then perhaps it should nearer
to vm-s than to context-tools...)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Mike Williams <md...@bigfoot.com>]

  >>> On Sat, 4 May 2002 02:42:49 +0200,
  >>> "Daniel" == Daniel Dekany <dd...@freemail.hu> wrote:

  Daniel> 1.: V layer tends to be simple (compared to C and M) but it is
  Daniel> not always simple.

How do you mean?  Can you describe what a "complex" view layer would do?

  Daniel> I think many users would be more happy if Velocity offers a
  Daniel> facility similar to JSP tag-libs.  [...] Programmers can write
  Daniel> velocity tags, and non-programmer designers can use them.

Well, Velocity provides the facility to use context-tools, which to me,
answers this need admirably.  I've worked on systems that use custom JSP
tags, and they were a maintenance nightmare.

-- 
cheers,
Mike

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Overhead creating a Vector of objects to send to VTL ? ( Re: foreach)

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 4:12 PM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
> I work solely in the Web world. Probably the most common place where
> one would use #foreach is looping over a list of results from a query.
> For example, viewing a catalog, or viewing the results from a search
> engine. I have never found Velocity lacking, mainly because I've
> usually handled all the logic in the SQL before I return the list of
> results to Velocity.
> Consider sending the results of a SQL query to a velocity template.
> Each result represents an object (eg. an item in your catalog) for
> which you have a corresponding Javabean. At the moment I loop over
> the JDBC ResultSet within the Java code and create a Vector of
> catalogItem objects, which is sent to the Velocity Template.
> This contrasts greatly with the JSP way of handling the JDBC ResultSet
> directly. However, is my mechanism using too much Object creation
> (the Vector of Javabeans) which I understand is "expensive" overhead
> in Java ?I'm trying to optimize performance and scalability so is this a
> real concern ? 

If you are not accessing everything in the result set, this may be wasteful
(although java is getting efficient).

One solution is to access the data 'just in time'.  To do this, make a
little class that you put the result set into, and then that class into the
context. It might be a little  bit of a pain as you will need to let
Velocity iterator over something.  If you only will iterate over it once,
then you can just make it look like an Iterator.  I have no idea if the
following works, let alone compiles.  I am just making this up :)

 public class Foo implements java.util.Iterator {

    ResultSet myResultSet;
    MyMapper mapper;

    public Foo(ResultSet rs)
    {
        myResultSet = rs;
        mapper = new Mapper(myResultSet);
    }

     public boolean hasNext() {
       
        return rs.next();
     }

     public Object next() {
          return mapper;
     }
}

 public class MyMapper implements Map{
   ResultSet rs;

  public MyMapper(ResultSet rs)
  {
      this.rs = rs;
   }
  
   public Object get(String key)
   {
     return rs.getString(key);
   }

   ... Rest of Map methods
}


So the idea is that you wrap the result set in something that looks like a
java.util.Iterator, so Vel will iterate over it and put that into the
context.  No new objects yet.

Then, each item in the set will be a mapper that also wraps the result set
(so no new objects created).

Then, when you use it

  #foreach($item in $resultset)

      $item.foo

  #end

Will only access the result set creating a string for the column 'foo'.


> 
> I have never bought into the "most people working in the MVC View
> are not programmers" argument, which is the basis of Struts and a
> multitude of frameworks which seem to have been born in ivory towers.
> Sure, it's true there are more non-programmers in the View area, but I
> wouldn't expect any designer to be able to use VTL. No disrespect to
> any of them, but the hundreds of designers I've worked with just wouldn't
> want to know and prefer not to have the responsibility. Therefore,
> it's a non-issue for me.  Velocity Rocks.
> 
> Thank you for any feedback on the initial question.
> Stephen Riek.
> 
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> Get personalised at My Yahoo!.
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Problem loading templates into Javabeans.

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/5/02 2:36 AM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
>>>   "Geir Magnusson Jr." <ge...@adeptra.com> wrote:
>>> Thank you for the explanation Geir. Using your method
>>> the Javabean can load the template OK when used in a
>>> standalone Java app but it still isn't loaded when
>>> used in a webapp.
>>> 1. The template is placed in
>>> /WEB-INF/classes/com/fubar/template.vm
>> 
>> Keep the template in the jar, and throw the whole jar into
>> 
>> WEB-INF/lib
>> 
>> Is that going to be a problem? I don't know how you are
>> deploying, but I would figure this would be the most
>> convenient thing - one jar, one config, two uses....
> Yes, that will be most convenient for deployment but during
> the development process it's necessary to keep changing or
> tweaking the template.vm and the actual Javabean code.
> I love Velocity for the rapid prototyping. Change the template.vm
> and see the results instantly. Continually repacking a jar
> and waiting for Tomcat to reload introduces the same sort of
> delays that I dislike with JSP.
> Still, if there's no other way, I'll do all development of
> the Javabean in standalone mode and then when I'm happy with
> the code, pack a jar and stick it in the WEB-INF/lib.
> Would be nicer to prototype within the webapp though.

Hm.  I wonder if you could rig it such that you have both file and
classloader going at the same time.  The only problem would be to set the
file path.  Hm.  You could do '/' but that's yecchy and dangerous, as if you
deploy that way, you aren't in control of what will happen.

Good problem.

> Thanks for the help Geir. Does this man ever sleep ?

Actually headed there right now :)

Thanks

> Stephen Riek
> 
>> 2. The Javabean that uses the template is
>> /WEB-INF/classes/com/fubar/VBean.java
>> 3. VBean.java has the display() method below which gets a template file
>> (template.vm) 
>> and returns a string. It will obviously also put variables in the context
>> later.
>> public String display() {
>> try {
>> Template template=null;
>> Velocity.setProperty("resource.loader", "class");
>> 
>> 
Velocity.setProperty("class.resource.loader.class","org.apache.velocity.runti>>
m
>> e.resource.loader.ClasspathResourceLoader" );
>> Velocity.init();
>> System.out.println("debug = velocity.init() ok");
>> Template t = Velocity.getTemplate("com/fubar/template.vm");
>> System.out.println("debug = got the template ok");
>> VelocityContext context = new VelocityContext();
>> System.out.println("debug = created context");
>> StringWriter sw = new StringWriter();
>> template.merge( context, sw );
>> System.out.println("debug = merged ok");
>> return sw.toString();
>> }
>> catch( ResourceNotFoundException rnfe ) {
>> System.out.println("debug = template not found");
>> }
>> catch( ParseErrorException pee ) { }
>> catch( MethodInvocationException mie ) { }
>> catch( Exception e ){
>> System.out.println("Unexpected Error " + e.getMessage());
>> }
>> return "";
>> }
>> 
>> When the Javabean is used in a standalone Java application, template.vm is
>> loaded OK*. 
>> However, when the Javabean is created from a JSP and the display() method
>> called,
>> the "template not found" debug message is shown in the Tomcat shell.
>> 
>> * Even when the template is loaded correctly in the standalone app, it fails
>> to 
>> merge and generates "Unexpected Error null" but that's a different problem.
>> 
>> I like this method of template loading and can't help but feel I'm almost
>> there
>> but having gone round in circles for a hours testing different settings can't
>> seem to get it. 
>> 
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> Get personalised at My Yahoo!.
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Problem loading templates into Javabeans.

[Stephen Riek <st...@yahoo.co.uk>]

> >   "Geir Magnusson Jr." <ge...@adeptra.com> wrote: 
> > Thank you for the explanation Geir. Using your method 
> > the Javabean can load the template OK when used in a 
> > standalone Java app but it still isn't loaded when
> > used in a webapp. 
> > 1. The template is placed in
> > /WEB-INF/classes/com/fubar/template.vm
> 
> Keep the template in the jar, and throw the whole jar into
> 
> WEB-INF/lib
> 
> Is that going to be a problem? I don't know how you are 
> deploying, but I would figure this would be the most 
> convenient thing - one jar, one config, two uses....
Yes, that will be most convenient for deployment but during
the development process it's necessary to keep changing or
tweaking the template.vm and the actual Javabean code. 
I love Velocity for the rapid prototyping. Change the template.vm
and see the results instantly. Continually repacking a jar
and waiting for Tomcat to reload introduces the same sort of
delays that I dislike with JSP.
Still, if there's no other way, I'll do all development of
the Javabean in standalone mode and then when I'm happy with
the code, pack a jar and stick it in the WEB-INF/lib.
Would be nicer to prototype within the webapp though.
Thanks for the help Geir. Does this man ever sleep ?
Stephen Riek

> 2. The Javabean that uses the template is
> /WEB-INF/classes/com/fubar/VBean.java
> 3. VBean.java has the display() method below which gets a template file
> (template.vm) 
> and returns a string. It will obviously also put variables in the context
> later.
> public String display() {
> try {
> Template template=null;
> Velocity.setProperty("resource.loader", "class");
> 
> Velocity.setProperty("class.resource.loader.class","org.apache.velocity.runtim
> e.resource.loader.ClasspathResourceLoader" );
> Velocity.init();
> System.out.println("debug = velocity.init() ok");
> Template t = Velocity.getTemplate("com/fubar/template.vm");
> System.out.println("debug = got the template ok");
> VelocityContext context = new VelocityContext();
> System.out.println("debug = created context");
> StringWriter sw = new StringWriter();
> template.merge( context, sw );
> System.out.println("debug = merged ok");
> return sw.toString();
> }
> catch( ResourceNotFoundException rnfe ) {
> System.out.println("debug = template not found");
> }
> catch( ParseErrorException pee ) { }
> catch( MethodInvocationException mie ) { }
> catch( Exception e ){
> System.out.println("Unexpected Error " + e.getMessage());
> }
> return "";
> }
> 
> When the Javabean is used in a standalone Java application, template.vm is
> loaded OK*. 
> However, when the Javabean is created from a JSP and the display() method
> called,
> the "template not found" debug message is shown in the Tomcat shell.
> 
> * Even when the template is loaded correctly in the standalone app, it fails
> to 
> merge and generates "Unexpected Error null" but that's a different problem.
> 
> I like this method of template loading and can't help but feel I'm almost
> there
> but having gone round in circles for a hours testing different settings can't
> seem to get it. 
> 



---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Re: Problem loading templates into Javabeans.

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/5/02 1:00 AM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
> Thank you for the explanation Geir.  Using your method the Javabean can load
> the
> template OK when used in a standalone Java app but it still isn't loaded when
> used
> in a webapp. 
> 1. The template is placed in
> <webapp>/WEB-INF/classes/com/fubar/template.vm

Keep the template in the jar, and throw the whole jar into

  WEB-INF/lib

Is that going to be a problem?  I don't know how you are deploying, but I
would figure this would be the most convenient thing - one jar, one config,
two uses....


> 
> 2. The Javabean that uses the template is
> <webapp>/WEB-INF/classes/com/fubar/VBean.java
> 3. VBean.java has the display() method below which gets a template file
> (template.vm) 
> and returns a string. It will obviously also put variables in the context
> later.
> public String display() {
> try {
>  Template template=null;
>  Velocity.setProperty("resource.loader", "class");
>  
> Velocity.setProperty("class.resource.loader.class","org.apache.velocity.runtim
> e.resource.loader.ClasspathResourceLoader" );
>  Velocity.init();
>  System.out.println("debug = velocity.init() ok");
>  Template t = Velocity.getTemplate("com/fubar/template.vm");
>  System.out.println("debug = got the template ok");
>  VelocityContext context = new VelocityContext();
>  System.out.println("debug = created context");
>  StringWriter sw = new StringWriter();
>  template.merge( context, sw );
>  System.out.println("debug = merged ok");
>  return  sw.toString();
> }
> catch( ResourceNotFoundException rnfe ) {
>     System.out.println("debug = template not found");
>  }
> catch( ParseErrorException pee ) { }
> catch( MethodInvocationException mie ) { }
> catch( Exception e ){
>  System.out.println("Unexpected Error " + e.getMessage());
> }
> return "";
> }
> 
> When the Javabean is used in a standalone Java application, template.vm is
> loaded OK*. 
> However, when the Javabean is created from a JSP and the display() method
> called,
> the "template not found" debug message is shown in the Tomcat shell.
> 
> * Even when the template is loaded correctly in the standalone app, it fails
> to 
> merge and generates "Unexpected Error null" but that's a different problem.
> 
> I like this method of template loading and can't help but feel I'm almost
> there
> but having gone round in circles for a hours testing different settings can't
> seem to get it. 
> 
> Stephen Riek.
> 
> 
> 
> 
> ---------------------------------
> Do You Yahoo!?
> Get personalised at My Yahoo!.
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Problem loading templates into Javabeans.

[Stephen Riek <st...@yahoo.co.uk>]

 Thank you for the explanation Geir.  Using your method the Javabean can load the
template OK when used in a standalone Java app but it still isn't loaded when used
in a webapp. 
1. The template is placed in 
<webapp>/WEB-INF/classes/com/fubar/template.vm

2. The Javabean that uses the template is 
<webapp>/WEB-INF/classes/com/fubar/VBean.java
3. VBean.java has the display() method below which gets a template file (template.vm) 
and returns a string. It will obviously also put variables in the context later.
public String display() {
  try {
   Template template=null;
   Velocity.setProperty("resource.loader", "class");
   Velocity.setProperty("class.resource.loader.class","org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader" );
   Velocity.init();
   System.out.println("debug = velocity.init() ok");
   Template t = Velocity.getTemplate("com/fubar/template.vm");
   System.out.println("debug = got the template ok");
   VelocityContext context = new VelocityContext();
   System.out.println("debug = created context");
   StringWriter sw = new StringWriter();
   template.merge( context, sw );
   System.out.println("debug = merged ok");
   return  sw.toString();
  }
  catch( ResourceNotFoundException rnfe ) {   
      System.out.println("debug = template not found");
   }
  catch( ParseErrorException pee ) { }
  catch( MethodInvocationException mie ) { }
  catch( Exception e ){
   System.out.println("Unexpected Error " + e.getMessage());
  }
  return "";
 }

When the Javabean is used in a standalone Java application, template.vm is loaded OK*. 
However, when the Javabean is created from a JSP and the display() method called,
the "template not found" debug message is shown in the Tomcat shell.

* Even when the template is loaded correctly in the standalone app, it fails to 
merge and generates "Unexpected Error null" but that's a different problem. 

I like this method of template loading and can't help but feel I'm almost there
but having gone round in circles for a hours testing different settings can't 
seem to get it. 

Stephen Riek.




---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Re: Problem loading templates into Javabeans.

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 6:01 PM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
> At the risk of appearing an idiot or lazy, which I'd like to think I'm not,
> an example would be very helpful. I've had a lot of problems configuring
> Tomcat to date. I had even tried to set a parameter in web.xml that would
> specify the filepath of the template.vm but couldn't get that to work even.
> The Tomcat group could do with a helping hand from whoever wrote the
> Velocity documentation :-)
> 

:)

Ok - the following should work :

1) put the template in your jar.  'Top level' is fine, but you might want to
be safe via something deeper.

  foo/bar/woogie/yourtemplate.vm

2) Configure velocity.  Can be via properties or directly.  Direct example :


  Velocity.setProperty("resource.loader", "class");
  Velocity.setProperty("class.resource.loader.class",
    "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader" );

  ... Set any other properties ...

  Velocity.init();

And you probably should use Velocity.RESOURCE_LOADER instead of the strings
:)

That *should* do it - you will have to then

  Template t = Velocity.getTemplate("foo/bar/woogie/yourtemplate.vm");

So be forewarned.

Should work just fine.

Geir


> Stephen Riek.
> 
> 
> 
> "Geir Magnusson Jr." <ge...@adeptra.com> wrote:
> On 5/4/02 5:26 PM, "Stephen Riek" wrote:
> 
>> 
>>> "Geir Magnusson Jr." wrote:
>>> I don't understand the question.
>> 
>> Sorry :(
>> 
>>> Do you want to make a javabean that embeds Velocity?
>> 
>> That is correct.
>> 
>> public class VBean {
>> // snipped Constructor and
>> // setXxx() and getXxx() methods.
>> 
>> public render() {
>> // load template.vm from file system.
>> // put all properties in a Velocity context.
>> // return result.
>> } 
>> } 
>> 
>> I created a bean that loads the template.vm from the
>> current directory
>> The problem is specifying the location of template.vm
>> if the Javabean is to be used in Tomcat webapps by
>> servlets and JSPs.
> 
> Oh - easy.
> 
> Use the classpath loader, and put the template in the jar you ship the bean
> in.
> 
> If that's not clear, I can give an example.
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Problem loading templates into Javabeans.

[Stephen Riek <st...@yahoo.co.uk>]

 At the risk of appearing an idiot or lazy, which I'd like to think I'm not, 
an example would be very helpful. I've had a lot of problems configuring
Tomcat to date. I had even tried to set a parameter in web.xml that would
specify the filepath of the template.vm but couldn't get that to work even.
The Tomcat group could do with a helping hand from whoever wrote the 
Velocity documentation :-)

Stephen Riek.

 

  "Geir Magnusson Jr." <ge...@adeptra.com> wrote: 
On 5/4/02 5:26 PM, "Stephen Riek" wrote:

> 
>> "Geir Magnusson Jr." wrote:
>> I don't understand the question.
> 
> Sorry :(
> 
>> Do you want to make a javabean that embeds Velocity?
> 
> That is correct. 
> 
> public class VBean {
> // snipped Constructor and
> // setXxx() and getXxx() methods.
> 
> public render() {
> // load template.vm from file system.
> // put all properties in a Velocity context.
> // return result.
> } 
> } 
> 
> I created a bean that loads the template.vm from the
> current directory
> The problem is specifying the location of template.vm
> if the Javabean is to be used in Tomcat webapps by
> servlets and JSPs.

Oh - easy.

Use the classpath loader, and put the template in the jar you ship the bean
in.

If that's not clear, I can give an example.


-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Re: Problem loading templates into Javabeans.

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 5:26 PM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
>> "Geir Magnusson Jr." <ge...@adeptra.com> wrote:
>> I don't understand the question.
> 
> Sorry :(
> 
>> Do you want to make a javabean that embeds Velocity?
> 
> That is correct. 
> 
> public class VBean {
>   // snipped Constructor and
>   // setXxx() and getXxx() methods.
> 
>   public render() {
>      // load template.vm from file system.
>      // put all properties in a Velocity context.
>      // return result.
>   } 
> } 
> 
> I created a bean that loads the template.vm from the
> current directory
> The problem is specifying the location of template.vm
> if the Javabean is to be used in Tomcat webapps by
> servlets and JSPs.

Oh - easy.

Use the classpath loader, and put the template in the jar you ship the bean
in.

If that's not clear, I can give an example.


-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Problem loading templates into Javabeans.

[Stephen Riek <st...@yahoo.co.uk>]

> "Geir Magnusson Jr." <ge...@adeptra.com> wrote: 
> I don't understand the question.

Sorry :(

> Do you want to make a javabean that embeds Velocity?

That is correct. 

public class VBean { 
    // snipped Constructor and 
    // setXxx() and getXxx() methods.

    public render() { 
       // load template.vm from file system.
       // put all properties in a Velocity context.
       // return result.
    } 
} 

I created a bean that loads the template.vm from the 
current directory 
The problem is specifying the location of template.vm
if the Javabean is to be used in Tomcat webapps by 
servlets and JSPs. 

Stephen Riek.

>> I have encountered a problem defining a File Resource Loader for a
>> Javabean which will be used in a webapp as well as a standalone
>> application. Since it is a Javabean that may be used outside of the
>> Tomcat JVM, I can not rely on the servlet context. I had it working
>> with a Javabean in standalone code using a velocity.properties file
>> and template.vm in the working directory or hardcoded into the
>> Javabean but both caused a resource not found error when the
>> Javabean was called from a JSP.
>> Veltags is not really what I'm looking for because I'm again using
>> the Javabean outside of the webapp.
>> 
>> Is this possible at all ? Really, I'd like to ship just a Javabean plus
>> one template.vm and maybe a velocity.properties file, that can be
>> used within webapp as well as standalone apps. Too much to ask ?





---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Re: Problem loading templates into Javabeans.

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/4/02 4:22 PM, "Stephen Riek" <st...@yahoo.co.uk> wrote:

> 
> I have encountered a problem defining a File Resource Loader for a
> Javabean which will be used in a webapp as well as a standalone
> application. Since it is a Javabean that may be used outside of the
> Tomcat JVM, I can not rely on the servlet context. I had it working
> with a Javabean in standalone code using a velocity.properties file
> and template.vm in the working directory or hardcoded into the
> Javabean but both caused a resource not found error when the
> Javabean was called from a JSP.
> Veltags is not really what I'm looking for because I'm again using
> the Javabean outside of the webapp.
> 
> Is this possible at all ? Really, I'd like to ship just a Javabean plus
> one template.vm and maybe a velocity.properties file, that can be
> used within webapp as well as standalone apps. Too much to ask ?
> 

I don't understand the question.

Do you want to make a javabean that embeds Velocity?

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Problem loading templates into Javabeans.

[Stephen Riek <st...@yahoo.co.uk>]

I have encountered a problem defining a File Resource Loader for a 
Javabean which will be used in a webapp as well as a standalone 
application. Since it is a Javabean that may be used outside of the
Tomcat JVM, I can not rely on the servlet context. I had it working
with a Javabean in standalone code using a velocity.properties file
and template.vm in the working directory or hardcoded into the 
Javabean but both caused a resource not found error when the 
Javabean was called from a JSP. 
Veltags is not really what I'm looking for because I'm again using
the Javabean outside of the webapp. 

Is this possible at all ? Really, I'd like to ship just a Javabean plus
one template.vm and maybe a velocity.properties file, that can be
used within webapp as well as standalone apps. Too much to ask ?

Stephen Riek.



---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Overhead creating a Vector of objects to send to VTL ? ( Re: foreach)

[Stephen Riek <st...@yahoo.co.uk>]

I work solely in the Web world. Probably the most common place where 
one would use #foreach is looping over a list of results from a query.
For example, viewing a catalog, or viewing the results from a search
engine. I have never found Velocity lacking, mainly because I've 
usually handled all the logic in the SQL before I return the list of
results to Velocity.  
Consider sending the results of a SQL query to a velocity template. 
Each result represents an object (eg. an item in your catalog) for
which you have a corresponding Javabean. At the moment I loop over
the JDBC ResultSet within the Java code and create a Vector of 
catalogItem objects, which is sent to the Velocity Template. 
This contrasts greatly with the JSP way of handling the JDBC ResultSet
directly. However, is my mechanism using too much Object creation
(the Vector of Javabeans) which I understand is "expensive" overhead
in Java ?I'm trying to optimize performance and scalability so is this a 
real concern ? 

I have never bought into the "most people working in the MVC View 
are not programmers" argument, which is the basis of Struts and a 
multitude of frameworks which seem to have been born in ivory towers.  
Sure, it's true there are more non-programmers in the View area, but I 
wouldn't expect any designer to be able to use VTL. No disrespect to 
any of them, but the hundreds of designers I've worked with just wouldn't 
want to know and prefer not to have the responsibility. Therefore, 
it's a non-issue for me.  Velocity Rocks.

Thank you for any feedback on the initial question.
Stephen Riek.
 



---------------------------------
Do You Yahoo!?
Get personalised at My Yahoo!.

Re: foreach

[jonah benton <jo...@jonah.com>]

On Fri, 2002-05-03 at 17:42, Daniel Dekany wrote:
> Friday, May 3, 2002, 11:03:21 PM, jonah benton wrote:
> 
> > On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
> >> jonah benton wrote:
> >> > We've had occasional need for it, but we're generally iterating over a
> >> > list maintained by an object we have in the context, so when we reach a 
> >> > state change where we want to stop iterating, we tell the object, and
> >> > the object arranges for the next call to hasNext() to return false.
> >> 
> >> Yes, but that's apples and oranges. Essentially, what you're doing is 
> >> using your control of the java code layer to work around a deficiency in 
> >> the template language.
> >
> > Better that than the other way around. :)
> >
> >> In the idealized MVC situation, the people working at the template layer 
> >> are completely separate people from those working at the java code layer.
> [snip]
> > More generally, at this point in web development, I am much more
> > comfortable with a simpler template language that requires some
> > solutions in Java to "work around [its] deficiencies", than a more
> > sophisticated template language that encourages designers to grow their
> > creative instincts into unmaintainable code without programmer
> > involvement. FreeMarker is much more restrained than PhP, ColdFusion,
> > and others in that ilk, but the mindset encouraging non-programmers to
> > find programmatic solutions is certainly present in its design. 
> 
> A more sophisticated template language is not necessary a drawback:
> 
> 1.: V layer tends to be simple (compared to C and M) but it is not
> always simple. Moving complexities of V into C/M just because the
> templating language is too stupid is a nonsense. Blend V into C/M is a
> clean violation of the MVC model idea.
> 

Of course- the key point is that in the web world, unlike the worlds
where MVC originated, most people working in the V are not programmers.
This has a substantial impact on code quality, especially procedural/oo
code quality. In my experience, non-programmers and programmers write
equally good code in declarative languages (html), but non-programmers
write unmaintainable or incorrect code in more expressive procedural/oo
languages. So the reason to put what could be V abstractions into Java
and make them available through method calls is to ensure that those
abstractions are developed and maintained by the best programmers. 

Velocity has procedural constructs, but happily limited abstraction
mechanisms, and this really helps to improve code quality in templates.


> 2.: Not everything in the V is made by the non-programmer designers.
> Even right now you may write tools that perform cleanly V tasks (HTML
> encoder for example). And I think many users would be more happy if
> Velocity offers a facility similar to JSP tag-libs. This does not mean
> that designers will write Velocity-tags. They will not as they will
> not learn how to do it and they will not be allowed to write tags
> anyway. Programmers can write velocity tags, and non-programmer
> designers can use them. This was just an example, not a proposal...

Yes- I've worked extensively with taglibs and have good and bad things
to say about them. Where the problem domain permits a declarative
solution with an appropriately structured set of taglibs, they're really
great. But many problems don't fit into this category, including view
problems.

I briefly explored the possibility of extending Velocity with custom
directives to capture some of the tag semantics we had been working with
in the past- because to follow on to a good point that Jonathan made,
sometimes exposing a more restricted semantics than objects usually
expose is a good idea- again, for code quality reasons. Tags let you do
this, sometimes more clearly than objects. I'd like to explore it
further at some point.


> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Daniel Dekany <dd...@freemail.hu>]

Friday, May 3, 2002, 11:03:21 PM, jonah benton wrote:

> On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
>> jonah benton wrote:
>> > We've had occasional need for it, but we're generally iterating over a
>> > list maintained by an object we have in the context, so when we reach a 
>> > state change where we want to stop iterating, we tell the object, and
>> > the object arranges for the next call to hasNext() to return false.
>> 
>> Yes, but that's apples and oranges. Essentially, what you're doing is 
>> using your control of the java code layer to work around a deficiency in 
>> the template language.
>
> Better that than the other way around. :)
>
>> In the idealized MVC situation, the people working at the template layer 
>> are completely separate people from those working at the java code layer.
[snip]
> More generally, at this point in web development, I am much more
> comfortable with a simpler template language that requires some
> solutions in Java to "work around [its] deficiencies", than a more
> sophisticated template language that encourages designers to grow their
> creative instincts into unmaintainable code without programmer
> involvement. FreeMarker is much more restrained than PhP, ColdFusion,
> and others in that ilk, but the mindset encouraging non-programmers to
> find programmatic solutions is certainly present in its design. 

A more sophisticated template language is not necessary a drawback:

1.: V layer tends to be simple (compared to C and M) but it is not
always simple. Moving complexities of V into C/M just because the
templating language is too stupid is a nonsense. Blend V into C/M is a
clean violation of the MVC model idea.

2.: Not everything in the V is made by the non-programmer designers.
Even right now you may write tools that perform cleanly V tasks (HTML
encoder for example). And I think many users would be more happy if
Velocity offers a facility similar to JSP tag-libs. This does not mean
that designers will write Velocity-tags. They will not as they will
not learn how to do it and they will not be allowed to write tags
anyway. Programmers can write velocity tags, and non-programmer
designers can use them. This was just an example, not a proposal...


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[jonah benton <jo...@jonah.com>]

On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
> jonah benton wrote:
> > We've had occasional need for it, but we're generally iterating over a
> > list maintained by an object we have in the context, so when we reach a 
> > state change where we want to stop iterating, we tell the object, and
> > the object arranges for the next call to hasNext() to return false.
> 
> Yes, but that's apples and oranges. Essentially, what you're doing is 
> using your control of the java code layer to work around a deficiency in 
> the template language.
> 

Better that than the other way around. :)

> In the idealized MVC situation, the people working at the template layer 
> are completely separate people from those working at the java code layer.
> 

Of course. Yet they must work together on issues more important than
this. 

More comments below.

> Regards,
> 
> Jonathan Revusky
> --
> Lead developer of FreeMarker http://freemarker.sourceforge.net/
> Build robust web appications with the
> Niggle Web Application Framework http://niggle.org/
> Available for Java/Internet Consulting
> 

This sudden entry onto the Velocity list by FreeMarker's lead developer
may be something of a joke, but as FreeMarker is publicly advertising
for users, I'm going to take this opportunity to flame it a little bit. 
:)

We evaluated FreeMarker at various times over the past couple of years,
prior to selecting Velocity last year. Very early on I thought that
FreeMarker looked like a reasonable templating option for Java-hosted
applications, and was especially keen on the tag syntax for a while. But
I shuddered when I looked at the hoops I'd have to go through to make
various kinds of data available to templates (see:
http://freemarker.sourceforge.net/docs/manual/guestbook.html )

Having also had the displeasure of managing ColdFusion projects in the
past, and seeing what designers were cooking up in JavaScript, I was
unexcited about a mindset that encouraged yet another way for
non-programmers to define arbitrarily complex "functions" in templates.
(To be clear, Velocity permits defining "macros", but as the saying
goes, I've met macros, macros are not functions, and Velocity is better
for it.) 

To speak to your comment directly, Jonathan- on the one hand, to speak
of the absence of a break command as a deficiency in the language,
requiring an unnecessary or unfortunate degree of Java programmer
involvement- it's not a serious comment. Of course, the presence of a
break or additional flow control could be a nice convenience, but there
are no shortage of issues in web application development requiring Java
programmer involvement, starting with the data model, workflow,
scalability issues, and the like. Java programmers for many reasons
often need to be aware of what template designers are going to be up to
when they build particular pages, and they have to work together. The
presence of a break command would be a nice convenience, but the fact is
that a break is among the presentation-level state change mechanisms
that must be available to template designers, and both sides often need
to work together to determine what those are. Even in a pure MVC
environment, the "business" logic involved in producing just
presentation code may be complex, requiring solutions from both sides,
design and programming.

More generally, at this point in web development, I am much more
comfortable with a simpler template language that requires some
solutions in Java to "work around [its] deficiencies", than a more
sophisticated template language that encourages designers to grow their
creative instincts into unmaintainable code without programmer
involvement. FreeMarker is much more restrained than PhP, ColdFusion,
and others in that ilk, but the mindset encouraging non-programmers to
find programmatic solutions is certainly present in its design. 

I've found Velocity's aggressive segregation of church and state
(designers and programmers) to be useful, its trivial integration with
virtually any Java application environment a great help, and the model
for making data available to templates as simple as it ought to be. A
surprising benefit was that once I started using Velocity in contexts
other than HTML page generation, I was glad I wasn't using a tag syntax,
which just doesn't work as well in other contexts. 

Also, at the time of my evaluation, FreeMarker 2.0 was still under
development. Looks like 2.0 final was just released in April-
congratulations. Velocity is still in the version 1.x stage, but it's
essentially WebMacro 2.0, and has a reasonable degree of maturity. That
it's under the apache project umbrella helps as well.

That said, there are some features in FreeMarker that I would probably
use were they available in Velocity, but the careful, conservative
approach with the engine, the ways Velocity makes it easy for me,
working in Java, to use it everywhere I want to, and the mindset that
supports managing designers rather than permitting their creative are
much more important than specific features. And Velocity is flexible
enough that if I need those features, I can add them myself.
 
Of course there is also the unbelievable energy Geir commits to the
list. I guess it's good for Velocity that the FreeMarker project is not
so busy that its principal developer also has the time to troll here to
help support Velocity users. ;-)

Cheers,

Jonah



> > 
> > 
> > 
> > On Fri, 2002-05-03 at 08:48, McLaughlin, Jim wrote:
> > 
> >>>Don't use stop.  It's really ill-defined at best.
> >>>
> >>>We could consider a #break directive, but my instinct would be to try
> >>>and avoid that if possible.  Do other people really have a strong need?
> >>>
> >>>
> >>
> >>No strong need but I can see #break and #continue <label> (for deeply nested
> >>loops) being extremely handy.  I remember doing this in school and we had to
> >>grind the ast through another transformation.  I haven't looked into the
> >>source so I don't know what kind of performance hit it will put on velocity.
> >>
> >>
> >>--
> >>Jim McLaughlin
> >>Software Engineer
> >>Stonewater Software
> >>email: jim@stonewatersoftware.com
> >>Phone: 847.864.1060 x107
> >>Fax  : 847.864.1238
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Jonathan Revusky <jr...@terra.es>]

jonah benton wrote:
> We've had occasional need for it, but we're generally iterating over a
> list maintained by an object we have in the context, so when we reach a 
> state change where we want to stop iterating, we tell the object, and
> the object arranges for the next call to hasNext() to return false.

Yes, but that's apples and oranges. Essentially, what you're doing is 
using your control of the java code layer to work around a deficiency in 
the template language.

In the idealized MVC situation, the people working at the template layer 
are completely separate people from those working at the java code layer.

Regards,

Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web appications with the
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting

> 
> 
> 
> On Fri, 2002-05-03 at 08:48, McLaughlin, Jim wrote:
> 
>>>Don't use stop.  It's really ill-defined at best.
>>>
>>>We could consider a #break directive, but my instinct would be to try
>>>and avoid that if possible.  Do other people really have a strong need?
>>>
>>>
>>
>>No strong need but I can see #break and #continue <label> (for deeply nested
>>loops) being extremely handy.  I remember doing this in school and we had to
>>grind the ast through another transformation.  I haven't looked into the
>>source so I don't know what kind of performance hit it will put on velocity.
>>
>>
>>--
>>Jim McLaughlin
>>Software Engineer
>>Stonewater Software
>>email: jim@stonewatersoftware.com
>>Phone: 847.864.1060 x107
>>Fax  : 847.864.1238
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet problem.... (solved)

[Jeff Duska <Je...@noaa.gov>]

Tim

Thanks for the help. I had my template in the wrong directory. I 
co-worker pointed out my mistake. It works fine now.

Regards,

Jeff


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet problem....

[Jeff Duska <Je...@noaa.gov>]

> What's your directory tree look like? Where's test.vm live?
> 
> 
> Tim
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 

I figured it was pretty standard except that it lives in the Eclipse 
workspace instead of Tomcat's webapp directory.

Here it is

workspace (dir)
	UserServer (dir)
		WEB-INF
			classes (dir)
			lib (dir)
			src (dir)
			work (Eclipse working directory)
			build.xml
			test.vm
			toolbox.xml
			web.xml
		work (Eclipse working directory)
		.classpath	(Eclipse files)
		.project
		.tomcatplugin

It is pretty standard stuff.



Jeffrey Duska
IMC
Applications Programmer
jeff.duska@noaa.gov

NCDC
151 Patton Avenue
Suite 468
Asheville, NC 28801
(828)271-4485 Office
(828)273-7441 Cell



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: VelocityViewServlet problem....

[Tim Colson <tc...@cisco.com>]

> When I change the path to this I get the following exception, 
> which says  it can't find the test.vm. 
Ok - different problem. At least now the webapp is running. :-)

> VelocityServlet : Error processing the template
> org.apache.velocity.exception.ResourceNotFoundException: 
> Unable to find resource '/test.vm'

What's your directory tree look like? Where's test.vm live?


Tim


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityViewServlet problem....

[Jeff Duska <Je...@noaa.gov>]

Tim Colson wrote:
> Jeff -
> 
> 
>>I check my log file I says the my web.xml is not found.
> 
> 
> I'd guess it's telling the truth. ;-)
> 
> 
>>I checked my server.xml file the context looks correct
>><Context path="/UserServlet" 
>>docBase="c:\workspace\UserServlet\WEB-INF" 
>>workDir="c:\workspace\UserServlet\WEB-INF\work\org\apache\jsp" />


When I change the path to this I get the following exception, which says 
it can't find the test.vm. I figured that it wasn't setup right. This is 
why I moved the docBase to WEB-INF directory.

VelocityServlet : Error processing the template

org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource '/test.vm'
org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
resource '/test.vm'
	at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:502)
	at 
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:386)
	at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:812)
	at 
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:794)
	at 
org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleton.java:337)
	at 
org.apache.velocity.servlet.VelocityServlet.getTemplate(VelocityServlet.java:524)
	at 
org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest(VelocityViewServlet.java:282)
	at 
org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServlet.java:356)
	at 
org.apache.velocity.servlet.VelocityServlet.doGet(VelocityServlet.java:317)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
	at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
	at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
	at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
	at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
	at 
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
	at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at 
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
	at 
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
	at java.lang.Thread.run(Thread.java:479)



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: VelocityViewServlet problem....

[Tim Colson <tc...@cisco.com>]

Jeff -

> I check my log file I says the my web.xml is not found.

I'd guess it's telling the truth. ;-)

> I checked my server.xml file the context looks correct
> <Context path="/UserServlet" 
> docBase="c:\workspace\UserServlet\WEB-INF" 
> workDir="c:\workspace\UserServlet\WEB-INF\work\org\apache\jsp" />

I think that's your problem - try changing that docBase to be one level
'up'.

Ergo:
<Context path="/UserServlet"  docBase="c:\workspace\UserServlet\" 

Cheers,
Tim


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

VelocityViewServlet problem....

[Jeff Duska <Je...@noaa.gov>]

Howdy folks...

I'm not sure what I've done wrong, but I'm my velocity files are not 
getting rendered with VelocityViewServlet. Please forgive me if this is 
something simple. I'm new to Velocity.

Here is what I did I have a Tomcat project in Eclipse.

I copied the lib directory, web.xml, toolbox.xml from the 
velocity-tools\view\examples\simple\WEB-INF. I removed the following 
section out of the web.xml file, since I'm not using tooltoy.class.

  <init-param>
       <param-name>toolbox</param-name>
       <param-value>/WEB-INF/toolbox.xml</param-value>
    </init-param>

    <load-on-startup>10</load-on-startup>

I figured I try my beans after I showed that simple foreach loop worked. 
   I renamed the index.vm to test.vm. I removed the toytool.getMessage 
code from the test.vm.

When I go to my site in Tomcat, I see the velocity code

#foreach($i in [1..5])i$ #end

not the

Lets count 1 2 3 4 5

I check my log file I says the my web.xml is not found. I don't 
understand, since it is sitting right in the WEB-INF directory. I 
checked my server.xml file the context looks correct

<Context path="/UserServlet" docBase="c:\workspace\UserServlet\WEB-INF" 
workDir="c:\workspace\UserServlet\WEB-INF\work\org\apache\jsp" />

c:\workspace\UserServlet\WEB-INF is where my web.xml file is. I would 
expect a different error, if I had corrupted the web.xml file when I 
edited it.

Help. Can you give me pointers on how to track this down? I like 
Eclipse, but I'm wondering if I might better off using Ant build. This 
way I could create a war file automaticly as part of the process. I wish 
that Exlipse just used Ant instead of its stupid .project file, but that 
is a subject for another group.

Regards,


Jeffrey Duska
IMC
Applications Programmer
jeff.duska@noaa.gov

NCDC
151 Patton Avenue
Suite 468
Asheville, NC 28801
(828)271-4485 Office
(828)273-7441 Cell



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[jonah benton <jo...@jonah.com>]

We've had occasional need for it, but we're generally iterating over a
list maintained by an object we have in the context, so when we reach a 
state change where we want to stop iterating, we tell the object, and
the object arranges for the next call to hasNext() to return false.



On Fri, 2002-05-03 at 08:48, McLaughlin, Jim wrote:
> >
> > Don't use stop.  It's really ill-defined at best.
> >
> > We could consider a #break directive, but my instinct would be to try
> > and avoid that if possible.  Do other people really have a strong need?
> >
> >
> 
> No strong need but I can see #break and #continue <label> (for deeply nested
> loops) being extremely handy.  I remember doing this in school and we had to
> grind the ast through another transformation.  I haven't looked into the
> source so I don't know what kind of performance hit it will put on velocity.
> 
> 
> --
> Jim McLaughlin
> Software Engineer
> Stonewater Software
> email: jim@stonewatersoftware.com
> Phone: 847.864.1060 x107
> Fax  : 847.864.1238
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["McLaughlin, Jim" <ji...@stonewatersoftware.com>]

>
> Don't use stop.  It's really ill-defined at best.
>
> We could consider a #break directive, but my instinct would be to try
> and avoid that if possible.  Do other people really have a strong need?
>
>

No strong need but I can see #break and #continue <label> (for deeply nested
loops) being extremely handy.  I remember doing this in school and we had to
grind the ast through another transformation.  I haven't looked into the
source so I don't know what kind of performance hit it will put on velocity.


--
Jim McLaughlin
Software Engineer
Stonewater Software
email: jim@stonewatersoftware.com
Phone: 847.864.1060 x107
Fax  : 847.864.1238



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Daniel Dekany <dd...@freemail.hu>]

Friday, May 3, 2002, 4:37:27 PM, Geir Magnusson Jr. wrote:

> On 5/3/02 9:10 AM, "Claude Brisson" <cl...@savoirweb.com> wrote:
>
>> Another mean to do it would be to put the #foreach loop itself alone in a
>> template, and so to use #stop as a break command, but one
>> may not like this templates fragmentation...
>
> Don't use stop.  It's really ill-defined at best.
>
> We could consider a #break directive, but my instinct would be to try and
> avoid that if possible.  Do other people really have a strong need?

Lack of such basic flow control constructs as loops with labels and
continue and break is socking for me, but perhaps it is acceptable if
we want to *force* programmers to remove complexity from the View.
However I personally don't like if a tool forces me to do something.
This is because life always finds the case where the nice model will
not work. And when it happens you will want, say, a break only in
that one damn case. Now you perhaps say that I want to make Velocty
complex again. But I think that a tool is simple and easy to learn if
it has a clear and simple "mental model" and a good documentation and
it does not really mater if it has 5 built-in directives or 10
(although too many built-in directive is a possible symptom of bad
mental model).

About the original question: If you want to put a break inside the
foreach loop then your Iterator/Enumerator is maybe wrong. That is, if
you want to stop the loop at "Fred" then why don't your
Iterator/Enumerator interpret "Fred" as the terminal element? So when
it reaches "Fred" then hasNext()/hasMoreElements() should return
false. I know it is complicated sometimes but this is how Velocty
moves complexity from the View into the Controller. But I know that
there are situations where this will be a very problematic and idiot
solution so I'm +1 about more flow control directives in general.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/3/02 9:10 AM, "Claude Brisson" <cl...@savoirweb.com> wrote:

> Another mean to do it would be to put the #foreach loop itself alone in a
> template, and so to use #stop as a break command, but one
> may not like this templates fragmentation...

Don't use stop.  It's really ill-defined at best.

We could consider a #break directive, but my instinct would be to try and
avoid that if possible.  Do other people really have a strong need?



> 
> CloD
> 
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
> To: <ve...@jakarta.apache.org>
> Sent: vendredi 3 mai 2002 15:04
> Subject: Re: foreach
> 
> 
>> On 5/3/02 7:58 AM, "Vanitha.S@lntinfotech.com" <Va...@lntinfotech.com>
>> wrote:
>> 
>>> Hi,
>>> 
>>>    Is there a way to break out of foreach when a particular condition is
>>> satisfied.
>> 
>> No
>> 
>>> 
>>> #foreach ( $name in $Customer.getName() )
>>> 
>>> #if( $name == "XYZ" )
>>> -------------------------> is there a way to break out...
>>> #end
>>> 
>> 
>> It's can be a pain, but the solution is typically something like
>> 
>> #set($doit = true)
>> 
>> #foreach($name in $stuff)
>> 
>>   #if($doit == true)
>>     ....
>>   #end
>> #end
>> 
>> Grossly inefficient, of course if $stuff is huge...
>> 
>> --
>> Geir Magnusson Jr.
>> Research & Development, Adeptra Inc.
>> geirm@adeptra.com
>> +1-203-247-1713
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>> 
>> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

[Claude Brisson <cl...@savoirweb.com>]

Another mean to do it would be to put the #foreach loop itself alone in a template, and so to use #stop as a break command, but one
may not like this templates fragmentation...

CloD

----- Original Message -----
From: "Geir Magnusson Jr." <ge...@adeptra.com>
To: <ve...@jakarta.apache.org>
Sent: vendredi 3 mai 2002 15:04
Subject: Re: foreach


> On 5/3/02 7:58 AM, "Vanitha.S@lntinfotech.com" <Va...@lntinfotech.com>
> wrote:
>
> > Hi,
> >
> >    Is there a way to break out of foreach when a particular condition is
> > satisfied.
>
> No
>
> >
> > #foreach ( $name in $Customer.getName() )
> >
> > #if( $name == "XYZ" )
> > -------------------------> is there a way to break out...
> > #end
> >
>
> It's can be a pain, but the solution is typically something like
>
> #set($doit = true)
>
> #foreach($name in $stuff)
>
>   #if($doit == true)
>     ....
>   #end
> #end
>
> Grossly inefficient, of course if $stuff is huge...
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: foreach

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 5/3/02 7:58 AM, "Vanitha.S@lntinfotech.com" <Va...@lntinfotech.com>
wrote:

> Hi,
> 
>    Is there a way to break out of foreach when a particular condition is
> satisfied.

No

> 
> #foreach ( $name in $Customer.getName() )
> 
> #if( $name == "XYZ" )
> -------------------------> is there a way to break out...
> #end
> 

It's can be a pain, but the solution is typically something like

#set($doit = true)

#foreach($name in $stuff)

  #if($doit == true)
    ....
  #end
#end

Grossly inefficient, of course if $stuff is huge...

-- 
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>