Re: Couple newbie questions

Erich Oliphant <[email protected]> Tue, 12 Oct 2004 11:45:14 -0400
Newsgroups gmane.comp.text.fmpp
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------010200050209040003040006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Daniel Dekany wrote:

>Friday, October 8, 2004, 8:18:14 PM, Erich Oliphant wrote:
>
>  
>
>>Daniel Dekany wrote:
>>
>>    
>>
>>>Friday, October 8, 2004, 4:31:16 PM, Erich Oliphant wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Hi,
>>>>I am using FMPP w/ Ant to create a installer for our application.  
>>>>Working pretty good so far but have a couple issues:
>>>>
>>>>1) We've using the ant XMLProperty to create Ant properties based on XML 
>>>>config files.  This is great for us, as we have lots of config items and 
>>>>grouping them hierarchically is convienient.  The problem, of course, is 
>>>>that ant properties of the form 'parent.property' are a problem for 
>>>>FMPP/Freemarker since ${parent.property} tries to resolve 'parent' then 
>>>>'property' as a child.  I read the FM docs regarding the 
>>>>${.vars["parent.property"]} syntax to get around the problem.  That 
>>>>works but is syntactically clunky.  Is there a cleaner way to do this?
>>>>   
>>>>
>>>>        
>>>>
>>>No... This is actually a FreeMarker syntax issue, although I don't blame
>>>FreeMarker for this.
>>>
>>>      
>>>
>>Yeah understand it's not necessarily a bad thing from an FM point of 
>>view. Just like item 2, it's really only an issue when you are trying to 
>>do generic text proc'ing on top of it ;)
>>    
>>
>
>Whatever expression language you chose, there is a high chance that it
>will clash with something... OK, maybe if FreeMarker uses an extreme
>separator character for separating variables from subvariables, say, ~
>(foo~bar), there is far less chance for clashes, but using such extreme
>syntax would drive most users crazy... :) Actually, in XML related
>languages the usual subvariable separator is /, which is used as
>division operator in most other languages. Maybe that's a good choice
>for template languages? I don't know...
>
>  
>
>>>>2) Some of the files that we are configuring are Unix shell scripts.  In
>>>>some cases the ${SHELL_VAR} form for shell variables is used, and the 
>>>>FMPP processing throws an error when it hits one of these as they are 
>>>>not defined.  This becomes a tricky problem as it's nice to know from an 
>>>>FMPP perspective that I've hit an undefined variable reference, but in 
>>>>this case I'd like to maybe log, the undefined var and keep processing.  
>>>>Or is there some way to define an alternate variable resolution syntax 
>>>>for FMPP/Freemarker?  This is a Java web application were building so we 
>>>>are going to run into the same problem with Java Expression Language 
>>>>variables that use the ${} form as well.
>>>>   
>>>>        
>>>>
>>>That's an issue with FreeMarker (again), namely that it doesn't allow
>>>the configuration of its syntax. I know this is a real problem for
>>>general purpose file preprocessors, because so many other formats use
>>>${exp}... Currently you can write ${'$'}{SHELL_VAR}, which is obviously
>>>terrible if you have to do it frequently. A workaround would be to
>>>replace all @{...}-s with ${...}, and all ${...} with ${'$'}{...} when
>>>FMPP loads the template files, thus simulate that the FreeMarker
>>>interpolation syntax is @{exp}. That slows things down a little bit,
>>>also possibly distorts the column number in error messages, but I guess
>>>that would be better than nothing. What do you think?
>>>
>>>      
>>>
>>Sounds good to me :)  You have any sample code/expressions that would 
>>illustrate this?
>>    
>>
>
>No, it's just and idea, that can be implemented (by me, mostly). Since
>then I have realized that it has a little problem: FreeMarker has
>built-ins for evaluating FTL expressions/fragments that are given with a
>(possibly dynamically calculated) string value... in those the
>interpolations would still use ${...} syntax. Well, the replacement
>thing is a dirty hack, and the result is dirty as well.
>
I think that for now I am just gonna <noparse> the shell vars.  Done it 
so far and it's not that onerous.

>
>  
>

--------------010200050209040003040006
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Daniel Dekany wrote:<br>
<blockquote type="cite"
 cite="[email protected]">
  <pre wrap="">Friday, October 8, 2004, 8:18:14 PM, Erich Oliphant wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Daniel Dekany wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Friday, October 8, 2004, 4:31:16 PM, Erich Oliphant wrote:

 

      </pre>
      <blockquote type="cite">
        <pre wrap="">Hi,
I am using FMPP w/ Ant to create a installer for our application.  
Working pretty good so far but have a couple issues:

1) We've using the ant XMLProperty to create Ant properties based on XML 
config files.  This is great for us, as we have lots of config items and 
grouping them hierarchically is convienient.  The problem, of course, is 
that ant properties of the form 'parent.property' are a problem for 
FMPP/Freemarker since ${parent.property} tries to resolve 'parent' then 
'property' as a child.  I read the FM docs regarding the 
${.vars["parent.property"]} syntax to get around the problem.  That 
works but is syntactically clunky.  Is there a cleaner way to do this?
   

        </pre>
      </blockquote>
      <pre wrap="">No... This is actually a FreeMarker syntax issue, although I don't blame
FreeMarker for this.

      </pre>
    </blockquote>
    <pre wrap="">Yeah understand it's not necessarily a bad thing from an FM point of 
view. Just like item 2, it's really only an issue when you are trying to 
do generic text proc'ing on top of it ;)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Whatever expression language you chose, there is a high chance that it
will clash with something... OK, maybe if FreeMarker uses an extreme
separator character for separating variables from subvariables, say, ~
(foo~bar), there is far less chance for clashes, but using such extreme
syntax would drive most users crazy... :) Actually, in XML related
languages the usual subvariable separator is /, which is used as
division operator in most other languages. Maybe that's a good choice
for template languages? I don't know...

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">2) Some of the files that we are configuring are Unix shell scripts.  In
some cases the ${SHELL_VAR} form for shell variables is used, and the 
FMPP processing throws an error when it hits one of these as they are 
not defined.  This becomes a tricky problem as it's nice to know from an 
FMPP perspective that I've hit an undefined variable reference, but in 
this case I'd like to maybe log, the undefined var and keep processing.  
Or is there some way to define an alternate variable resolution syntax 
for FMPP/Freemarker?  This is a Java web application were building so we 
are going to run into the same problem with Java Expression Language 
variables that use the ${} form as well.
   
        </pre>
      </blockquote>
      <pre wrap="">That's an issue with FreeMarker (again), namely that it doesn't allow
the configuration of its syntax. I know this is a real problem for
general purpose file preprocessors, because so many other formats use
${exp}... Currently you can write ${'$'}{SHELL_VAR}, which is obviously
terrible if you have to do it frequently. A workaround would be to
replace all @{...}-s with ${...}, and all ${...} with ${'$'}{...} when
FMPP loads the template files, thus simulate that the FreeMarker
interpolation syntax is @{exp}. That slows things down a little bit,
also possibly distorts the column number in error messages, but I guess
that would be better than nothing. What do you think?

      </pre>
    </blockquote>
    <pre wrap="">Sounds good to me :)  You have any sample code/expressions that would 
illustrate this?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, it's just and idea, that can be implemented (by me, mostly). Since
then I have realized that it has a little problem: FreeMarker has
built-ins for evaluating FTL expressions/fragments that are given with a
(possibly dynamically calculated) string value... in those the
interpolations would still use ${...} syntax. Well, the replacement
thing is a dirty hack, and the result is dirty as well.</pre>
</blockquote>
I think that for now I am just gonna &lt;noparse&gt; the shell vars.&nbsp;
Done it so far and it's not that onerous.<br>
<br>
<blockquote type="cite"
 cite="[email protected]">
  <pre wrap="">

  </pre>
</blockquote>
</body>
</html>

--------------010200050209040003040006--



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl