You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@velocity.apache.org by Christoph Reck <Ch...@dlr.de> on 2000/11/23 11:32:05 UTC

Pittfalls in migration from WM to VL

Here I'll list problems that I encountered in migrating the
templates (I hope such a alpha test result list is welcome):

* convert.WebMacro is not up to date and makes to many
  assumptions. 
  + I will send a patch.
  - a #begin is not removed if it is in the same "#if" line
  - converting to "#foreach ($foo in $bar).getKeys()"
  - #parse still converted to #include (w/o parenthesis)
  - javascript "}"s being converted to #end (this is maybe out
    of scope of the simple convert.WebMacro)

* Variables starting with a "_" underscore are not converted
  - should be allowed and added to the VL grammar.

* Template error messages are emitted without stating the filename 
  and wrong line numbers when using #parse.
  + In general template error messages are not very helpfull. I will 
    try to provide patches when I get to it.

* A #set with a following comment causes a NPE, e.g:
  #set $color = "0x8080FF" ## light blue

* A file ending in a ## without an EOL emits a TokenMgrError.

* A #set without an "=" emits a NPE instead of an apropiate 
  error message.

* The negation in #if ( !$foo ) does not work (throws a NPE if
  $foo does not exist). 
  + workaround use: #if ( $foo )#else ...
  - The test/template/logical.wm has a #if (!($foo == true)), but
    just shows that the negation works with logical values.

* A method invocation (which is not a getXXX) without parameters
  requires an empty braket set, else it throws a ClassCastException,
  e.g. add following line to the example.vm: length=$list.size

* A null assignment (e.g. returned from a method call) leaves the
  variable unchanged, e.g:
  #set $foo = "bar"
  \$foo is now $foo
  #set $foo = $provider.Hashtable.get("anything not in there")
  #if ( $foo )
    \$foo should have contained null!
  #else
    $foo is now correctly null.
  #end

* Hastables are known to a foreach, but not to set. The WM syntax
  #set $provider.Hashtable.NEW_KEY = "a string"
  does not do anyting. How does one set a value into a Hastable without
  emitting the previous content? does one need to do:
  #set $dummy = $provider.Hashtable.put("NEW_KEY", "a string")

* Whitespaces around standalone #if, #else, #end are preserved,
  it should be possible to handle them like a #set
  - Note that this would also make the VSL templates much more
    readable!
  ---
  #set $bar = true
  #if ($foo)
      \$foo=>$foo
  #else    $foo undefined
    #if ($bar)
      \$bar=>$bar
    #else
      $bar undefined
    #end
  #end
  ---
  should emit
  ---
      $foo undefined
      $bar=>true
  ---
  where the first else is not standalone, therefore whitespaces 
  are untouched, all other directives (even the indented ones)
  emit nothing (not even a EOL).
  
* Pluggable directives should contain a flag on the interface that
  states if whitespaces should be removed when these are standalone.
  A #parse should not touch whitespaches, whereas a #include should 
  in my opinion work, e.g.:
     #set $data.Response.setHeader("content-type", "image/gif")
     #set $dummy = $data.getOut()
     #include ("/images/logo.gif")

* The current snapshot contains new xalan/xerces which is not
  compatible with the included JTest.

* The example/test.sh in the current snapshot is referencing
  velocity-0.4.jar instead of the generated 0.5

* The build-velocity.sh just does a prepare as the default target,
  I would expect it to do at least a compile and jar (as the 
  install.html states).


Please let me know if I should dig into the code to help out with 
these problems. Maybe it would then be time to obtain CVS write
permission.


:) Christoph

Re: Error in latest CVS: TexenTask.java

Posted by Jason van Zyl <jv...@periapt.com>.

On Fri, 24 Nov 2000, Jason van Zyl wrote:

> On Fri, 24 Nov 2000, Randall G. Alley wrote:
> 
> Sorry, I fixed that and didn't commit it. I'll do it now.
> Thanks for catching that!

Fixed.

-- 
jvz.

Jason van Zyl
jvanzyl@periapt.com

Re: Error in latest CVS: TexenTask.java

Posted by Jason van Zyl <jv...@periapt.com>.

On Fri, 24 Nov 2000, Randall G. Alley wrote:

Sorry, I fixed that and didn't commit it. I'll do it now.
Thanks for catching that!

> Trying to compile this morning I found:
> 
>     [javac] Compiling 1 source file to D:\Jakarta\jakarta-velocity\bin\classes
>     [javac]
> D:\Jakarta\jakarta-velocity\bin\src\org\apache\velocity\texen\ant\TexenTask.java:24
> 
> 4: ';' expected.
>     [javac]     public Context initControlContext
>     [javac]                                      ^
>     [javac] 1 error
> 
> Looking up line 244:
>     public Context initControlContext
>     {
>     }
> 
> 
> No Context object is returned. Also should syntax be like:
> 
>     public Context initControlContext()
>     {
>         // return proper context object
>     }
> 
> 
> Thanks,
> Randy
> 
> 

-- 
jvz.

Jason van Zyl
jvanzyl@periapt.com

Error in latest CVS: TexenTask.java

Posted by "Randall G. Alley" <ir...@bellsouth.net>.

Trying to compile this morning I found:

    [javac] Compiling 1 source file to D:\Jakarta\jakarta-velocity\bin\classes
    [javac]
D:\Jakarta\jakarta-velocity\bin\src\org\apache\velocity\texen\ant\TexenTask.java:24

4: ';' expected.
    [javac]     public Context initControlContext
    [javac]                                      ^
    [javac] 1 error

Looking up line 244:
    public Context initControlContext
    {
    }


No Context object is returned. Also should syntax be like:

    public Context initControlContext()
    {
        // return proper context object
    }


Thanks,
Randy

Re: Pittfalls in migration from WM to VL

Posted by Fedor Karpelevitch <fe...@home.com>.

I am also for leaving "-" as a valid char. I do not care for "_" much.
Just my 2c.

Daniel Rall wrote:

> Christoph Reck <Ch...@dlr.de> writes:
> 
> 
>> replying to Geir's response (without a copy to velocity-user):
>> 
>>> That was a decision made a while ago. It's easy to fix if enough people
>>> think it's a good idea.  It would make our identifiers conform a little
>>> better to the java spec. (Can we please get rid of the '-' as an
>>> acceptable identifier character? How many people are going to regularly
>>> use 'working-dogs' as a reference, jon? :)
>> 
>> I raised this earlyer and jvz stated that it could be made it this was
>> really a "standard" and people want it (up to now I'm the only one that
>> has spoken up).
>> 
>> It would be great if you allow the "_" at the beginning of a variable.
>> 
>> +1 to get rid of the "-".
> 
> 
> I think that the "-" as a valid variable name character should stay.
> It is very standard, and LISPers do in fact use it heavily.
> 
> Daniel

Re: Pittfalls in migration from WM to VL

Posted by Daniel Rall <dl...@finemaltcoding.com>.

Christoph Reck <Ch...@dlr.de> writes:

> replying to Geir's response (without a copy to velocity-user):
> > That was a decision made a while ago. It's easy to fix if enough people
> > think it's a good idea.  It would make our identifiers conform a little
> > better to the java spec. (Can we please get rid of the '-' as an
> > acceptable identifier character? How many people are going to regularly
> > use 'working-dogs' as a reference, jon? :)
> 
> I raised this earlyer and jvz stated that it could be made it this was
> really a "standard" and people want it (up to now I'm the only one that
> has spoken up).
> 
> It would be great if you allow the "_" at the beginning of a variable.
> 
> +1 to get rid of the "-".

I think that the "-" as a valid variable name character should stay.
It is very standard, and LISPers do in fact use it heavily.

Daniel