webmacro-devel — Discuss development issues related to the core of WebMacro

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Brian G. <br...@qu...>]

> Hmm, but this is what I'd call quite a serious bug in WM. It affects how 
> people write templates.

I don't see how.  Keats' workaround deals with this case acceptably.
Because of the underlying problem, there may be others, there probably
are, but you have to find them first before you get to declare
"serious bug."  I'm inclined to let the underlying problem lie until
other incidences crop up.  The cost/benefit of fixing and testing the
underlying problem seems unattractive.

Re: [Webmacro-devel] JSP + WM together - interesting!

[Keats <ke...@ea...>]

Even better would be a WebMacro TagLib:

<wm:template>
  ## WebMacro script here ...
</wm:template>

We could even put the JspContext into the WM Context.

Keats

----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: <web...@li...>
Sent: Thursday, August 07, 2003 5:34 AM
Subject: [Webmacro-devel] JSP + WM together - interesting!


>
> Hey,
>
> While supporting that guy with the #macro problem who mailed the team
> address, he's sent me a JSP file he is using to run WM!
>
> This is really quite simple but is quite amusing / useful as a migration
> tool or a way to get employers who want you to use JSP to let you use WM
;-)
>
> Here's his JSP - the way he is locating the template is unnecessarily
> obscure because he has put them into the app doc root:
>
> <%@ page
> import='org.webmacro.*,org.webmacro.servlet.WebContext,java.util.*' %><%
>
>   WebMacro webMacro = null;
>   Context context = null;
>   Template template = null;
>   try{
>     webMacro = new WM();
>     context = new Context(webMacro.getBroker());
>     String path = pageContext.getServletContext().getRealPath("") +
> java.io.File.separator + "MacroTestMain.html";
>     template = webMacro.getTemplate(path);
>   }     catch (Exception e){
>     e.printStackTrace();
>   }
>   String htmlPath = pageContext.getServletContext().getRealPath("");
>   context.put("htmlPath",htmlPath);
>
>   try{
>     out.print(template.evaluate(context));
>   } catch (Exception e) {
>     e.printStackTrace();
>   }
> %>
>
> Anyway, this is quite interesting and may have some useful possibilities
> for WM, if shifted to an included JSP file so that you don't have to have
> this code in every JSP.
>
> Maybe someone who has real experience of JSP could write a page on this on
> the Wiki, and we could announce it in the next press release "A migration
/
> co-existence path for JSP users".
>
> Marc
>
>

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Keats <ke...@ea...>]

So I guess that means I should commit my patch for the time being?

Keats

----- Original Message -----
From: "Brian Goetz" <br...@qu...>
To: "Marc Palmer" <ma...@an...>
Cc: "Keats" <ke...@ea...>; <web...@li...>
Sent: Thursday, August 07, 2003 4:23 AM
Subject: Re: [Webmacro-devel] Parser error: StringIndexOutOfRange


> > ...can we go for a real fix then, for the sake of not causing problems
for
> > ourselves in the future - i.e. no "hidden" hacks that we forget which
cause
> > problems later and don't solve the whole problem anyway.
> >
> > Go on, Brian, please :)
>
> Nasty code.  Sleeping dog lying...
>

[Webmacro-devel] JSP + WM together - interesting!

[Marc P. <ma...@an...>]

Hey,

While supporting that guy with the #macro problem who mailed the team 
address, he's sent me a JSP file he is using to run WM!

This is really quite simple but is quite amusing / useful as a migration 
tool or a way to get employers who want you to use JSP to let you use WM ;-)

Here's his JSP - the way he is locating the template is unnecessarily 
obscure because he has put them into the app doc root:

<%@ page 
import='org.webmacro.*,org.webmacro.servlet.WebContext,java.util.*' %><%

  WebMacro webMacro = null;
  Context context = null;
  Template template = null;
  try{
    webMacro = new WM();
    context = new Context(webMacro.getBroker());
    String path = pageContext.getServletContext().getRealPath("") + 
java.io.File.separator + "MacroTestMain.html";
    template = webMacro.getTemplate(path);
  }     catch (Exception e){
    e.printStackTrace();
  }
  String htmlPath = pageContext.getServletContext().getRealPath("");
  context.put("htmlPath",htmlPath);

  try{
    out.print(template.evaluate(context));
  } catch (Exception e) {
    e.printStackTrace();
  }
%>

Anyway, this is quite interesting and may have some useful possibilities 
for WM, if shifted to an included JSP file so that you don't have to have 
this code in every JSP.

Maybe someone who has real experience of JSP could write a page on this on 
the Wiki, and we could announce it in the next press release "A migration / 
co-existence path for JSP users".

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Marc P. <ma...@an...>]

On Thu, 7 Aug 2003 01:23:27 -0700, Brian Goetz <br...@qu...> wrote:

>> ...can we go for a real fix then, for the sake of not causing problems 
>> for ourselves in the future - i.e. no "hidden" hacks that we forget 
>> which cause problems later and don't solve the whole problem anyway.
>>
>> Go on, Brian, please :)
>
> Nasty code.  Sleeping dog lying...

Hmm, but this is what I'd call quite a serious bug in WM. It affects how 
people write templates.

If you don't have time to address this, we'll have to do this without you 
:(

[BUMP... the sound of the blind leading the blind!]

Marc
-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Brian G. <br...@qu...>]

> ...can we go for a real fix then, for the sake of not causing problems for 
> ourselves in the future - i.e. no "hidden" hacks that we forget which cause 
> problems later and don't solve the whole problem anyway.
> 
> Go on, Brian, please :)

Nasty code.  Sleeping dog lying...

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Marc P. <ma...@an...>]

On Thu, 07 Aug 2003 00:56:09 -0700, Brian Goetz <br...@qu...> wrote:

>
>> Thanks for tracking this down Keats!
>>
>> Brian, is this a go-er?
>
> Sort of.  The code Keats checked in appears to work around an existing 
> bug in ParserBlockBuilder, but doesn't fix it.  It probably won't hurt, 
> but this bug is likely to come up again.

...can we go for a real fix then, for the sake of not causing problems for 
ourselves in the future - i.e. no "hidden" hacks that we forget which cause 
problems later and don't solve the whole problem anyway.

Go on, Brian, please :)

-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Brian G. <br...@qu...>]

>Thanks for tracking this down Keats!
>
>Brian, is this a go-er?

Sort of.  The code Keats checked in appears to work around an existing bug 
in ParserBlockBuilder, but doesn't fix it.  It probably won't hurt, but 
this bug is likely to come up again.


--
Brian Goetz
Quiotix Corporation
br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Marc P. <ma...@an...>]

On Tue, 5 Aug 2003 16:06:30 -0400, Keats <ke...@ea...> wrote:

> Marc,
>
> I have isolated this problem and it appears to be a whitespace issue with
> the in-line explicit #begin.
[snip]
> I have made a one-line patch to the ParserBlockBuilder.directiveOK(), 
> line
> 227, to check for an empty String which seems to fix the problem.  All 
> the
> unit tests still pass, but I guess I'd feel more confortable having Brian
> bless this before I commit the change.

Thanks for tracking this down Keats!

Brian, is this a go-er?


-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Parser error: StringIndexOutOfRange

[Keats <ke...@ea...>]

Marc,

I have isolated this problem and it appears to be a whitespace issue with
the in-line explicit #begin.

I reduced your test case to the minimal:

#if (true) #begin #set $x=0 #end

which still gives the error.  Adding a second space before the #set (or
replacing it with a newline) makes the error go away.  Apparently the parser
prematurely discards the whitespace that it needs to recognize the next
token as a directive.

I have made a one-line patch to the ParserBlockBuilder.directiveOK(), line
227, to check for an empty String which seems to fix the problem.  All the
unit tests still pass, but I guess I'd feel more confortable having Brian
bless this before I commit the change.

Keats

----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: <web...@li...>
Sent: Friday, August 01, 2003 7:12 AM
Subject: [Webmacro-devel] Parser error: StringIndexOutOfRange


>
> I just got, using the latest CVS source:
>
> org.webmacro.engine.BuildException: Error parsing template:
> FileTemplate:xxxxxx (name removed)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>
> The problem seems to be related to #begin...#end handling, possibly to do
> with nested directives (#set).
>
> If I remove my EXPLICIT #begin...#end it works fine.
>
> The line is marked in the template below. I will add a test case for this.
>
>
> #include "includes/header.wmt"
>
> <h2>Generator for SQL CREATE TABLE based on Metalizer Schema</h2>
>
> <form action="gensql.wmt" method="post">
> Schema name: <input name="$Ignition.FormFieldName.schemaName"
> #if ($Ignition.FieldValue.schemaName)
>     value="$Ignition.FieldValue.schemaName"
> #end
> >
> <input type="submit" value=" Generate ">
> </form>
>
> #if ($Ignition.FieldValue.schemaName)
> <h3>SQL follows:</h3>
>
> #set $schema = $Ignition.getSchema($Ignition.FieldValue.schemaName)
> <pre>
> CREATE TABLE tablename (
>
> #set $first = true
> #foreach $group in $schema.FieldGroups
> #begin
>     #foreach $fieldName in $schema.getFieldNamesInGroup($group)
>     #begin
>         #set $field = $schema.getField($fieldName)
> !!!!!!!!!!!! This next line is the problem
>         #if ($first) #begin #set $first = false #end #else #begin , #end
>         $field.Name $field.DataType.Name
>     #end
> #end
> );
> </pre>
>
> #end
>

Re: [Webmacro-devel] Refinement of the null testing directive idea

[Marc P. <ma...@an...>]

On Mon, 04 Aug 2003 18:11:41 -0700, Lane Sharman <la...@op...> 
wrote:

> there is nothing wrong the #if ($testIfVarIsNull) {} construction. And I 
> like it.

I was just proposing it because it:

(a) Eliminates use of a temp var if you want to avoid erroneous multiple 
dereferences (no autocomplete in Templates!), reducing context namespace 
pollution
(b) is a little nicer in that you don't need to refer to the full name of 
the property within the block.

That's all - make templates easier to read and write.

> For lax apps, do something like this:
>
> #bean $map = SparseProperties
> $map.FirstName = "Brian"
> <input name="FullName" value="$map.FirstName $map.LastName">

That's not always whay you want to do...

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Refinement of the null testing directive idea

[Lane S. <la...@op...>]

there is nothing wrong the #if ($testIfVarIsNull) {} construction. And I 
like it.

For lax apps, do something like this:

#bean $map = SparseProperties
$map.FirstName = "Brian"
<input name="FullName" value="$map.FirstName $map.LastName">

-Lane

Brian Goetz wrote:

>
>> <input name="somefield"
>> #if ($MyProp.SomeProp.FinalProp)
>>   value="$MyProp.SomeProp.FinalProp"
>> #end
>
>
> What's wrong with #if ($foo) { }
>
>
>
> -- 
> Brian Goetz
> Quiotix Corporation
> br...@qu...           Tel: 650-843-1300            Fax: 
> 650-324-8032
>
> http://www.quiotix.com
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Re: [Webmacro-devel] Refinement of the null testing directive idea

[Brian G. <br...@qu...>]

><input name="somefield"
>#if ($MyProp.SomeProp.FinalProp)
>   value="$MyProp.SomeProp.FinalProp"
>#end

What's wrong with #if ($foo) { }



--
Brian Goetz
Quiotix Corporation
br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com

[Webmacro-devel] Re: Fix new map type to better handle "put"

[Keats <ke...@su...>]

[I haven't figured out how to use SF's tracker so I'm responding to this here.]

I can't reproduce this.  Using the following test template:

#set $myMap = {"Value": "Old value"}
#set $myMap.Value = "A value"<br>
\$myMap is $myMap

I get:

$myMap is {Value=A value} 

This is exactly what one would expect and desire.

The problem *does* occur if you use the "round bracket hack" syntax.  E.g.,

#set $myMap = {"Value": "Old value"}
$myMap.put("Value","A value")<br>
\$myMap is $myMap

produces:

Old value
$myMap is {Value=A value} 

This is a different, and much less serious issue.  The workaround of course is to use a junk variable:

#set $prevValue = $myMap.put("Value","A value")<br>

You could also use your own map implementation or wrapper, e.g.,

#set $myQuietMap = $quietMap($myMap)

[It would be nice if we could specifiy the Map implementation used by WMScript by default.  Can we do this now?]

If you want to keep this as an enhancement request, please update the description.

Personally I would give this a low priority.

Keats

Re: [Webmacro-devel] Version 2.0 Updates

[Marc P. <ma...@an...>]

On Sun, 03 Aug 2003 14:58:45 -0700, Lane Sharman <la...@op...> 
wrote:

> Version number = 2.0b :)
>
> I think this accords with my part of the work for WM for the context 
> loading project.

Nice work Lane - thanks very much. Will check it out tomorrow and give 
"minimal" a spin in Ignition.

Marc


-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

[Webmacro-devel] 1.1 versus 2.0 Performance Study

[Lane S. <la...@op...>]

Attached are the performance loading reports from TestSyntheticTemplate, 
a synthetic benchmark in our test suite.

Files:
    WM1.1_Load...
    WM2.0_Load...

Env:
    Run back to back on P4, 2.5 GHZ, no WebMacro optimization. Using 
standard defaults.
    NOTE: 2.0 build style = minimal

Opening each file up side by side shows little comparable difference 
between versions 1.1 and 2.0.

regards,

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

[Webmacro-devel] Version 2.0 Updates

[Lane S. <la...@op...>]

webmacro>ant compile -Dwm-style=minimal
=======================================
The above will call to the build,  WebMacro.defaults.minimal as 
WebMacro.defaults.

This implies: NO DEFAULT TOOLS, WEB OR OTHERWISE in the build. See the 
file WebMacro.defaults.minimal for the definition of this file.

The above is for architects/developers of WebMacro. It is for those who 
want to supply there own context tool loading scheme. It is NOT THE 
DEFAULT build style.

webmacro>ant compile
=====================
This is the default and it will call in WebMacro.defaults.classic and 
classic is the standard property value. So, in this manner, going 
forward, the standard context tools will remain a part of the default build.

Thus, there are 2 files in the root to manage now: 
WebMacro.defaults.minimal and WebMacro.defaults.classic with an 
attendant build.xml property, wm-style. When you do a checkout, 
WebMacro.properties should go away.

All tests run against both styles of builds.

src-optional/
===============
This a new tree and the opendoors generational cache manager is now 
there. Other files can be selectively moved there as we study. There is 
a task to compile this in to the build, "compile-optional".

Also, I removed defunct examples file removed; some docs updated.

Version number = 2.0b :)

I think this accords with my part of the work for WM for the context 
loading project.

regards,

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Re: [Webmacro-devel] Whitespace :(

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Fri, 1 Aug 2003 13:40:58 -0400 (GMT), Keats <ke...@su...> wrote:
>
>> St
>
>
> Would produce a superfluous blank line. I know WE know var expansion 
> and directives are completely different, but to the average user why 
> should whitespace handling be any different. 

Because they are different animals and therefore the text jock is 
trained use each differently. We have a page to document the behavior. 
Token handling and white space consumption and emission are terrifically 
hard to do the way any one person would like it. And, done one way, it 
really pisses off the next person who wants it another way. And, the 10 
others who want it 10 different ways.

There is no one way to get it right because everyone has a different 
take on indents, line consumption, etc.

I realize marc that this is really irritating and I have scanned your 
email on this subject. Is this a show-stopper for you?

-Lane

>
>
>> If you want a bunch of stuff without newlines you can write:
>
> [snip]
>
>>
>> to get
>>
>> [10, (20), 50, (100)]
>>
>> Writing this all on one line would really suck.
>
>
> Perhaps...
>
>> (Note: I haven't tested this example, but it's something like that.)
>
>
> This is exactly my point though! It should be obvious from the 
> template what the output should be. It definitely isn't, unless you 
> are ready to meticulously apply the WS rules.
>
> At least if #xxx expands exactly where the "#" is, and you write it on 
> one line, you know you will get ONE line. :)
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Re: [Webmacro-devel] Whitespace :(

[Marc P. <ma...@an...>]

On Fri, 1 Aug 2003 13:40:58 -0400 (GMT), Keats <ke...@su...> wrote:

> Stripping the previous newline is definitely a major point of confusion, 
> but it makes sense once you grok it.  Making more special cases would, 
> IMHO, not only make the parser more complicated, but also make it harder 
> to learn and remember the rules.
>
> To make your example work you just need to add a blank line:
>
> [
>
> #if ($someCondition)
> #begin
> #if ($someOtherCondition)
> #begin
> This is a line
> This is another line
> #end
> #end
> ]

Yes I know that...

> Yes it's confusing, but once you understand it it works fine and it is 
> consistent.

...but it is not consistent with $xxx expansion:

[

$somethingHere
]

Would produce a superfluous blank line. I know WE know var expansion and 
directives are completely different, but to the average user why should 
whitespace handling be any different.

> If you want a bunch of stuff without newlines you can write:
[snip]
>
> to get
>
> [10, (20), 50, (100)]
>
> Writing this all on one line would really suck.

Perhaps...

> (Note: I haven't tested this example, but it's something like that.)

This is exactly my point though! It should be obvious from the template 
what the output should be. It definitely isn't, unless you are ready to 
meticulously apply the WS rules.

At least if #xxx expands exactly where the "#" is, and you write it on one 
line, you know you will get ONE line. :)

-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Whitespace :(

[Keats <ke...@su...>]

Stripping the previous newline is definitely a major point of confusion, but it makes sense once you grok it.  Making more special cases would, IMHO, not only make the parser more complicated, but also make it harder to learn and remember the rules.

To make your example work you just need to add a blank line:

[

#if ($someCondition)
#begin
   #if ($someOtherCondition)
   #begin
      This is a line
      This is another line
   #end
#end
]

Yes it's confusing, but once you understand it it works fine and it is consistent.

If you want a bunch of stuff without newlines you can write:

[
#foreach $num in [10, -20, 50, -100] indexing $i
  #if ($i>1) 
  #begin
,
  #end
  #if ($num < 0)
  #begin
 ($abs($num))     
  #end
  #else
  #begin
 $num)
  #end
]

to get

[10, (20), 50, (100)]

Writing this all on one line would really suck.

(Note: I haven't tested this example, but it's something like that.)

Keats

Re: Re: [Webmacro-devel] Whitespace :(

[Marc P. <ma...@an...>]

On Fri, 1 Aug 2003 11:34:44 -0400 (GMT), Keats <ke...@su...> wrote:

> You're absolutely write and we've agonized over this on and off for 
> years.  But no really great solutions have been put forward.
>
> I have suggested a directive, like #trim that could do things like trim 
> all leading whitespace, trim all trailing whitespace, trim all leading 
> and trailing whitespace, trim a fixed amount of leading whitespace, etc.
>
> Nobody seemed very excited about this.  Maybe your Ignition framework 
> will renew interest in this.
>
> Another idea I had was to specifiy a "leader" char, like a dot leader 
> which would be eaten from the begining of each line.
>
> Any of these sound useful to you?

Hmmm, they don't feel right either do they?

Going RIGHT back to basics, without getting overly passionate about keeping 
the status quo :)

... why do we need whitespace trimming?

1. To allow pretty formatting of directives, and the blocks within 
directives.
2. er.... ?

If there are any other reasons I have missed through ignorance (or Friday 
afternoon fuzz) please make them known!


If it is just pretty formatting that is the issue, I would say that the 
current scheme does not even live up to that requirement, when you are 
thinking of plain text output - which is what we SHOULD assume WM is 
outputting to, frankly. The fact that HTML strips consecutive WS is a 
"bonus" that WM obviously should not rely on for usability.

Take the following:

[
#if ($someCondition)
#begin
   #if ($someOtherCondition)
   #begin
      This is a line
      This is another line
   #end
#end
]

This produces (assuming my mailer does not screw up the spacing as usual):

[      This is a line
      This is another line
  ]

Now, how anybody can call this good output I do not know ;-)

Of course what we want is either:

[
      This is a line
      This is another line
]

-OR-

[
This is a line
This is another line
]

The second sample is, I think, really what we want. If we are indenting 
specifically for the sake of code prettiness, even lines that do not 
contain directives should have leading indent space stripped.

Yes, I know this is really tricky.

However, perhaps we can develop some logic that:

1. detects indent depth (contiguous whitespace from newline) 2. 
automatically strips off only indentDepth worth of whitespace from every 
line in a block, only if the whitespace at the start of the line is equal 
to or greater than the indentDepth - i.e:

#if ($a)
   #if ($b)
   Line 1
 Line 2
     Line 3
   #end
#end
 Would produce:

Line 1
 Line 2
  Line 3

This may seem more confusing perhaps.

However the most common case is where you indent everything and line it up 
nicely, in which case there will be NO problem, and you will not have to 
consider the above example. It will work "as expected". It also allows you 
to add specific whitespace at the start of a line by having less or more 
than the indent of WS. The only problem is adding the same amount of 
whitespace as the indent - but that can be solved by shifting slightly your 
block indent - not intuitive I know ;-)

Also, the above scheme requires you to align blocks with the #directive 
rather than indent them within the block - i.e. #begin/#end or {/} have to 
be at the same indent depth as the block they contain. Most people will 
probably hate this, and it would be a pretty weird convention to impose.

If we can solve that problem you still need:

1. directives to strip previous newline, only if the previous line 
contained just a block opening/closing (?)
2. directives to strip at most one space/tab at the start and end of a 
block.

...I don't think we should strip previous WS if the directive is not on a 
line where only WS appears before the directive:

<input name="x" value="spacebetween #if (true) thesewords #end">

Would yield:

<input name="x" value="spacebetween thesewords">

...and not:

<input name="x" value="spacebetweenthesewords">

as it does now.

The above problem is currently difficult/messy/unintuitive to achieve with 
WM. The above WS policy example behaves just like $xxxx expansion - it 
happens right there, where the # or $ is. I think this makes WM more 
consistent, which is a discussion we've had elsewhere on this regarding the 
value="#directivehere" not working unless WS is inserted before the 
directive.

I know this is just such a horrible subject, and even worse to contemplate 
changes to the parser... but this really is not good. I've not examined it 
closely before, but now I have and I don't like what I see for text output 
:(

Don't get me wrong, I have got -great-text output results using WM and my 
text formatting helper, but even then the template is a real mess with 
hundreds of calls to methods to write out word-wrapped formatted text, do 
indents, and lots of #setblocks.

Sure, many of those are still needed to achieve wordwrap etc., but all the 
workarounds in #macros etc. to handle spacing properly (usually suppressing 
excess due to indent WS being left in) are quite nasty indeed.

I'm not trying to completely destroy WM's whitespace handling, I'm just 
trying to brainstorm what we REALLY wanted to achieve with it and if we've 
really got a solution we are proud of for text file generation.

In my view, either we find a solution, or we stop telling people WM is good 
for plain text!

Here's another example of how illogical the scheme can appear to people who 
have to write templates and do not necessarily have the wherewithall to 
understand parser issues and complex whitespace rules:

Hello $user,

    Thank you for mailing $company. - - - - - - - - - - - - - - - -
    We are sorry but nobody is here right now, we are all on the beach.

    We will be back soon,
    Thanks, $company Team.

...that will come out beautifully, just as it looks there but with vars 
substituted. Now add some new logic:

Hello $user,

    Thank you for mailing $company. - - - - - - - - - - - - - - - -
#if ($vacation)
#begin
    We are sorry but nobody is here right now, we are all on the beach.

    We will be back soon,
    Thanks, $company Team.
#end

...which gives us:

Hello [user],

    Thank you for mailing [company].
    - - - - - - - - - - - - - - - -    We are sorry but nobody is here 
right now, we are all on the beach.

    We will be back soon,
    Thanks, [company] Team.

...however if you don't have any text on the line before the #if it will 
not run together:

Hello [user],

    Thank you for mailing [company].
    - - - - - - - - - - - - - - - -    We are sorry but nobody is here 
right now, we are all on the beach.

    We will be back soon,
    Thanks, [company] Team.


I know, I know... this is exactly the way it is supposed to work now, but 
don't you see how an obscure edit to a file by somebody 6 months later can 
end up with totally screwed up results and the will wonder why the hell it 
happened, because the - - - - in on a separate line.

Also, I know that any such changes would break existing text output 
templates, but we could work around this with an alternative (legacy) 
parser implementation they can plug in.

Anyway, enough for now. I just don't to be flame-bait again... I just 
wonder if we can collectively come up with something innovative to solve 
this.


Marc
-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Whitespace :(

[Marc P. <ma...@an...>]

On Fri, 1 Aug 2003 17:59:21 +0200 (MEST), Endre Stølsvik 
<web...@st...> wrote:

> On Fri, 1 Aug 2003, Marc Palmer wrote:
>
> |
> | Guys,
> |
> | I know this is such a seriously unpopular subject... but WM is really 
> very
> | horrible to use to produce nicely formatted text output. The whitespace
> | eating is just so hard to work with.
> |
>
> Have you read my suggestion of trimming -all-whitespace from a defined
> block, except escaped whitespace? Its at that NextRelease page;
> http://www.webmacro.org/NextRelease

That is an interesting idea. I think it would make templates extremely ugly 
though, if absolutely all whitespace must be quoted. We'd need to add a 
function like #setblock to automatically quote all the spaces in a large 
block of text.

Do you really mean this?

#if ($x)
#begin
"    "This is indented text
"        "This is more indented text
#end

It might work, but we still - I think - need a solution for the problem of 
blocks "jumping up" to the previous line by the directive eating the 
previous newline.

I think that if you want something to appear "inline" you will have to put 
all the directive code and block on one line. It's ugly but... at least 
things will appear where they look like they will appear when you view the 
template.

-- 
Marc Palmer
Contract Java Consultant/Developer
			
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

Re: [Webmacro-devel] Whitespace :(

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Fri, 1 Aug 2003 10:19:10 -0400 (GMT), Keats <ke...@su...> wrote:
>
>> Marc,
>>
>> It's really not as bad as you're making it out to be.  The only known 
>> bugs with whitespace handling are the implicit #begin and #end 
>> problems.  You can avoid this altogether by using curly braces when 
>> you need precise control of whitespace.
>>
>> The rules are a bit complex, but they were hashed out exhaustively 
>> and there is some logic behind them.
>>
>> If you have a specific case that's giving you trouble I'd be glad to 
>> take a look.
>
>
> Thanks, that's very kind. My point is though that this shouldn't be 
> necessary! 

We spent a ton of time on WS issues many moons ago and we got it good. 
Not perfect, but good.

I realize you are attached to the #begin and #end directives but try the 
curly brace and see what your results are.

-lane


>
>
> The trouble is that the templates have to end up looking really ugly 
> (for plain text formatted output), and most people who are not 
> hardcore WM users will get extremely confused by the (I'm sure very 
> logical) rules used and how they have to position things to get their 
> results.
>
> I'm just wondering if there's some other way to approach this. For 
> example I've written a pretty next text formatting helper to reduce 
> these problems - but it requires calls $textHelper.write( string) for 
> everything if you want it to work.
>
> Here's an example of that template I showed before, which now produces 
> reasonable output - although I would like an indent on every field 
> line of the SQL output:
>
> #macro SQLType( $field)
>    #set $class = $field.ConstraintProperty.ClassName
>    #if ($class == "java.lang.String") #begin  
> VARCHAR($field.ConstraintProperty.MaxLength) #end
>    #elseif ($class == "java.util.Date") #begin  DATE #end
>    #else #begin $field.DataType.Name #end
> #end
>
> <h2>Generator for SQL CREATE TABLE based on Metalizer Schema</h2>
>
> <h3>SQL follows:</h3>
>
> #set $schema = $Ignition.getSchema($Ignition.FieldValue.schemaName)
> <pre>
> CREATE TABLE tablename (
>
> #set $first = true
> #foreach $group in $schema.FieldGroups
> #begin
> #foreach $fieldName in $schema.getFieldNamesInGroup($group)
>    #begin
>    #if (!$first) #begin ,
> #end
>    #set $field = $schema.getField($fieldName)
> $field.Name  #SQLType($field) #if ($field.ConstraintProperty.Required) 
> #begin  NOT NULL #end #set $first = false #end
> #end
>
> );
> </pre>
>
>
> There are all kinds of hacks required - blocks all on one line which 
> are very nasty for long lines, #end(s) at the beginning of the next 
> line instead of indented properly so you don't get the extra spaces 
> included and so on.
>
> I really do appreciate the complexity and intentions behind the 
> current scheme. In theory, if you want everything to be on one line 
> you should have one long line of code. You -can- get around the 
> nastiness of that by avoiding directives on the line, having set their 
> results into variables before rendering the line and so on.
>
> I know that there are contradictions too... in one sense we don't want 
> WS to be eaten, so output placement is predictable, but at the same 
> time we want to be able to indent code to produce readable source.
>
> I just think... there has to be a better way, especially as we are 
> promoting WM as something that is not just for HTML.
>
> If I had to hand a WM app to somebody for them to write plain text 
> templates (say for emails) I would be nuts - $xxx and #if are one 
> thing to explain, precise positioning rules are another.
>
> $0.02
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Re: [Webmacro-devel] Whitespace :(

[<web...@st...>]

On Fri, 1 Aug 2003, Marc Palmer wrote:

|
| Guys,
|
| I know this is such a seriously unpopular subject... but WM is really v=
ery
| horrible to use to produce nicely formatted text output. The whitespace
| eating is just so hard to work with.
|

Have you read my suggestion of trimming -all- whitespace from a defined
block, except escaped whitespace? Its at that NextRelease page;
http://www.webmacro.org/NextRelease


--=20
Mvh,
Endre St=F8lsvik               M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS         -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

Re: Re: [Webmacro-devel] Whitespace :(

[Keats <ke...@su...>]

You're absolutely write and we've agonized over this on and off for years.  But no really great solutions have been put forward.

I have suggested a directive, like #trim that could do things like trim all leading whitespace, trim all trailing whitespace, trim all leading and trailing whitespace, trim a fixed amount of leading whitespace, etc.  

Nobody seemed very excited about this.  Maybe your Ignition framework will renew interest in this.

Another idea I had was to specifiy a "leader" char, like a dot leader which would be eaten from the begining of each line.  

Any of these sound useful to you?

Keats

-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 08/01/03 11:05 AM
To: ke...@ea..., web...@li...
Subject: Re: [Webmacro-devel] Whitespace :(

> 
> On Fri, 1 Aug 2003 10:19:10 -0400 (GMT), Keats <ke...@su...> wrote:

> Marc,
>
> It's really not as bad as you're making it out to be.  The only known 
> bugs with whitespace handling are the implicit #begin and #end problems. 
 
> You can avoid this altogether by using curly braces when you need
precise 
> control of whitespace.
>
> The rules are a bit complex, but they were hashed out exhaustively and 
> there is some logic behind them.
>
> If you have a specific case that's giving you trouble I'd be glad to
take 
> a look.

Thanks, that's very kind. My point is though that this shouldn't be 
necessary!

The trouble is that the templates have to end up looking really ugly (for 
plain text formatted output), and most people who are not hardcore WM
users 
will get extremely confused by the (I'm sure very logical) rules used and 
how they have to position things to get their results.

I'm just wondering if there's some other way to approach this. For example 

I've written a pretty next text formatting helper to reduce these problems 
- 
 but it requires calls $textHelper.write( string) for everything if you 
want it to work.

Here's an example of that template I showed before, which now produces 
reasonable output - although I would like an indent on every field line of 

the SQL output:

#macro SQLType( $field)
    #set $class = $field.ConstraintProperty.ClassName
    #if ($class == "java.lang.String") #begin  
VARCHAR($field.ConstraintProperty.MaxLength) #end
    #elseif ($class == "java.util.Date") #begin  DATE #end
    #else #begin $field.DataType.Name #end
#end

<h2>Generator for SQL CREATE TABLE based on Metalizer Schema</h2>

<h3>SQL follows:</h3>

#set $schema = $Ignition.getSchema($Ignition.FieldValue.schemaName)
<pre>
CREATE TABLE tablename (

#set $first = true
#foreach $group in $schema.FieldGroups
#begin
#foreach $fieldName in $schema.getFieldNamesInGroup($group)
    #begin
    #if (!$first) #begin ,
#end
    #set $field = $schema.getField($fieldName)
$field.Name  #SQLType($field) #if ($field.ConstraintProperty.Required) 
#begin  NOT NULL #end #set $first = false #end
#end

);
</pre>


There are all kinds of hacks required - blocks all on one line which are 
very nasty for long lines, #end(s) at the beginning of the next line 
instead of indented properly so you don't get the extra spaces included
and 
so on.

I really do appreciate the complexity and intentions behind the current 
scheme. In theory, if you want everything to be on one line you should
have 
one long line of code. You -can- get around the nastiness of that by 
avoiding directives on the line, having set their results into variables 
before rendering the line and so on.

I know that there are contradictions too... in one sense we don't want WS 
to be eaten, so output placement is predictable, but at the same time we 
want to be able to indent code to produce readable source.

I just think... there has to be a better way, especially as we are 
promoting WM as something that is not just for HTML.

If I had to hand a WM app to somebody for them to write plain text 
templates (say for emails) I would be nuts - $xxx and #if are one thing to 

explain, precise positioning rules are another.

$0.02

-- 
Marc Palmer
Contract Java Consultant/Developer
   	   	   	
                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio
.NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>