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

[Webmacro-devel] Argh these Apache guys are having a laugh

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

What a mess... anybody know how to get mod_jk2 working on Win32 with Apache 
2.0.45 and Tomcat 4.1? I can't even get apache to load the mod_jk2 
module... that is AFTER I've managed find it amongst all the detritus on 
the ASF site.

:(


Marc
-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] RE: Binary accessor "set" problem

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

On Tue, 29 Apr 2003 01:44:56 -0400, Keats <ke...@su...> wrote:

> I tried to do something like:
>
> #set $jdomElement.AttributeValue.Thinga = "mabob"
>
> and I got a NullPointerException.  After looking at the PropertyOperator 
> code, the problem was suddenly obvious.  WM will always look for a "unary 
> accessor" before a "binary mutator".  In this case, it finds a 
> getAttribute() method, which happens to return null, hence the NPE.
>
> Perhaps this is the problem Marc was seeing?

I don't think so but my memory is fuzzy. My problem was with setting the 
value, and I don't usually override "setter" methods. I just could never 
get "set" to work on a binary accessor.

However I did get this exact problem you mention yesterday when playing 
around with some stuff.

In short I think that really we should probably look for the most "complex" 
getter/setter first and go back to unary set/get if nothing found, but this 
could be a lot more complicated than it sounds. i.e. it should work as you 
expect it! Keats and I have come unstuck with this and we "know what we're 
doing".

Failing that, or in the interim at least, we should leave it as is but 
update the binary accessor docs on the site to say "Programmers 
implementing binary accessor methods should not override getter or setter 
methods of the same name" or something to that effect.

Marc

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] RE: Binary accessor "set" problem

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

Keats wrote:

> An update on a cold thread ...
>
> In playing around with the XmlDemo, I thought I had re-encountered 
> this elusive bug.  But then I realized the reason ...
>
> I tried to do something like:
>
>   #set $jdomElement.AttributeValue.Thinga = "mabob"
>
> and I got a NullPointerException.  After looking at the 
> PropertyOperator code, the problem was suddenly obvious.  WM will 
> always look for a "unary accessor" before a "binary mutator".  In this 
> case, it finds a getAttribute() method, which happens to return null, 
> hence the NPE. 

did you mean getAttributeValue() and not getAttribute() relative to your 
code?

>
>
> Perhaps this is the problem Marc was seeing?
>
> Anyway, it's not clear to me how to "fix" this.
>
> We could catch the exception and then look for a binary mutator before 
> throwing.  But this could result in inconsistent behavior.  For 
> example, in the above case, if the attribute "Thinga" did exist, you 
> would get an error, since you can't assign a String to a JDOM 
> Attribute field.
>
> Alternatively, we could always check for the "binary mutator" first. 
> This makes some sense, but there are issues here as well.  It would 
> break backwards compatability for anyone relying on the unary-first 
> behavior.  This probably wouldn't effect many templates, but if it did 
> it could be a puzzling error.  It also might have performance 
> implications.
>
> My feeling is that we should just document the behavior and live with 
> it.  But if anyone feels strongly that this is bad, I'm open to 
> persuasion.
>
> Keats
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

[Webmacro-devel] RE: Binary accessor "set" problem

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

An update on a cold thread ...

In playing around with the XmlDemo, I thought I had re-encountered this 
elusive bug.  But then I realized the reason ...

I tried to do something like:

   #set $jdomElement.AttributeValue.Thinga = "mabob"

and I got a NullPointerException.  After looking at the PropertyOperator 
code, the problem was suddenly obvious.  WM will always look for a 
"unary accessor" before a "binary mutator".  In this case, it finds a 
getAttribute() method, which happens to return null, hence the NPE.

Perhaps this is the problem Marc was seeing?

Anyway, it's not clear to me how to "fix" this.

We could catch the exception and then look for a binary mutator before 
throwing.  But this could result in inconsistent behavior.  For example, 
in the above case, if the attribute "Thinga" did exist, you would get an 
error, since you can't assign a String to a JDOM Attribute field.

Alternatively, we could always check for the "binary mutator" first. 
This makes some sense, but there are issues here as well.  It would 
break backwards compatability for anyone relying on the unary-first 
behavior.  This probably wouldn't effect many templates, but if it did 
it could be a puzzling error.  It also might have performance implications.

My feeling is that we should just document the behavior and live with 
it.  But if anyone feels strongly that this is bad, I'm open to persuasion.

Keats

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

Greetings,

we need to have some generality and separation:

1) output
as a tool or as a directive it can output any inline value to a stream 
or file as Marc suggested.

2) template
as a tool or as a directive it can evaluate any kind of template.

combining these together in the same template, I prefer both as directives.

#include as template "ApplicationSupport.tml"

## create a template:
#template $foo {
    #include as template "ApplicationSupport.tml"
    #include as template "$DocRoot/header.tml"
    this is a template created by:<br>
    $formatList($Names)
}
#set $foo.Context.Names = ["lane", "marc", "sebastian"]
## output the template to CurrentReport.html
#output to file  "$DocRoot/CurrentReport.html" {
    $foo.eval()
    <br>Created on $Now
    #include as template "$DocRoot/footer.tml"
}

The above or a better design would be very cool to have in WM in the 
next major release.

-Lane



Sebastian Kanthak wrote:

>Hi,
>
>On Monday 28 April 2003 15:58, Kea...@di... wrote:
>  
>
>>I had the same suggestion, except as a directive, e.g.,
>>
>>#output file="some-file" {
>>   $someMacro()
>>}
>>
>>#ouput stream=$myOutStream {
>>  $someOtherMacro($x, $y)
>>}
>>    
>>
>
>ok, now the question is "tool or directive". I tend to prefer tools for things 
>not belonging into the "core" of WebMacro. And this is certainly a 
>functionallity not needed so often.
>
>Another point for Tool is, that an #output directive would somehow overlap 
>with the planned #template directive. One day, someone wants to use #output, 
>but with different arguments (a different context), so we'll basically have 
>to duplicate the #template directive (if it exists already, at least :-). So 
>let's do a clear separation: A #template directive that builds Macro's with 
>configurable contexts and an OutputTool that can output any macro anywhere 
>(at least almost anywhere).
>
>Sebastian
>
>  
>

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

[Sebastian K. <seb...@mu...>]

Hi,

On Monday 28 April 2003 15:58, Kea...@di... wrote:
> I had the same suggestion, except as a directive, e.g.,
>
> #output file="some-file" {
>    $someMacro()
> }
>
> #ouput stream=$myOutStream {
>   $someOtherMacro($x, $y)
> }

ok, now the question is "tool or directive". I tend to prefer tools for things 
not belonging into the "core" of WebMacro. And this is certainly a 
functionallity not needed so often.

Another point for Tool is, that an #output directive would somehow overlap 
with the planned #template directive. One day, someone wants to use #output, 
but with different arguments (a different context), so we'll basically have 
to duplicate the #template directive (if it exists already, at least :-). So 
let's do a clear separation: A #template directive that builds Macro's with 
configurable contexts and an OutputTool that can output any macro anywhere 
(at least almost anywhere).

Sebastian

-- 
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

On Mon, 28 Apr 2003 09:58:20 -0400, <Kea...@di...> wrote:

> I had the same suggestion, except as a directive, e.g.,
>
> #output file="some-file" {
> $someMacro()
> }
>
> #ouput stream=$myOutStream {
> $someOtherMacro($x, $y)
> }

May I suggest a more verbose/friendly syntax:

#output to file "some-file" {
$someMacro()
}

#output to stream $myOutStream {
$someOtherMacro($x, $y)
}

Slightly more WM-like ?

Marc
-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

On Mon, 28 Apr 2003 08:34:53 -0700, Lane Sharman <la...@op...> 
wrote:

> Hi Sebastian,
>
> I have come around to your thinking.
>
> Let's create a tool called Output. Much cleaner. And, Marc, this is 
> really different than antwmcompile which is a batch processor.

Yes, I see this now. Not sure how I would use it though, but I trust you 
guys that you have a need for it :)

Marc

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

Either as a directive or as a tool, I'd like to elevate Template and 
Output to release 2.0 elements?

For data conversion as Keats mentioned, this would be killer.

-Lane

Kea...@di... wrote:

>
> I had the same suggestion, except as a directive, e.g.,
>
> #output file="some-file" {
>    $someMacro()
> }
>
> #ouput stream=$myOutStream {
>   $someOtherMacro($x, $y)
> }
>
> This wouldn't be useful for a normal servlet, but for other kinds of 
> apps it could be very handy.  For example, we built a stand-alone data 
> extraction and conversion tool, that would benefit from being able to 
> generate multiple files from a single iteration through the data.
>
> Keats
>
>
>
>
> Sebastian Kanthak <seb...@mu...>
> Sent by: web...@li...
>
> 04/26/2003 09:55 AM
>
>        
>         To:        web...@li...
>         cc:        
>         Subject:        Re: [Webmacro-devel] Ugh - the reality of XML 
> and flattened trees
>
>
>
>
> Hi Marc,
>
> On Saturday 26 April 2003 14:57, Marc Palmer wrote:
> > > I think, this should be orthogonal to the Template-Tool/Directive. We
> > > could write an "OutputTool" that can write any macro to a file. If the
> > > TemplateTool would return a macro (Keats, does it?) than one could 
> write:
> > >
> > > #template $foo {
> > > foo $x
> > > }
> > > #set $foo.Context.x = "bar"
> > >
> > > $Output.writeToFile($foo,"index.html")
> > >
> > > What do you think of this?
> >
> > If you want to easily write templates to a file, use my AntWMCompile 
> tool.
> > It just processes templates in batches, and dumps them out to an output
> > tree based on the original extension of the template.
> > http://www.wangjammers.org/antwmcompile
>
> well, I'm actually using AntWMCompile (it's great!) and added some 
> extensions,
> so that a template knows more about its location. Once I've finished 
> this,
> I'll write you another mail and explain this changes, perhaps they can be
> included.
>
> My OutputTool proposal was a reaction on Lane's wish to include such a
> possibility into the upcoming template-directive. So the requirement 
> is to
> output templates defined on the fly. I guess Lane wants to do some simple
> scripting with webmacro. Personally I don't like this, because it puts 
> too
> much control into the template, in my opinion, but if Lane doesn't care...
>
> In my posting, I wanted to express, that I would rather see this 
> feature not
> built directly into the #template-directive, because in my opinion,
> directives should be kept as simple as possible and there are so many
> different possibilities, where a template should be written to: Into a 
> file,
> a database, via ftp....
>
> Using a ContextTool for this task would give you this flexibility and 
> would be
> able to output every macro, not just templates.
>
> Sebastian
>
> -- 
> Sebastian Kanthak
> PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

Hi Sebastian,

I have come around to your thinking.

Let's create a tool called Output. Much cleaner. And, Marc, this is 
really different than antwmcompile which is a batch processor.

-Lane



Sebastian Kanthak wrote:

>Hi Marc,
>
>On Saturday 26 April 2003 14:57, Marc Palmer wrote:
>  
>
>>>I think, this should be orthogonal to the Template-Tool/Directive. We
>>>could write an "OutputTool" that can write any macro to a file. If the
>>>TemplateTool would return a macro (Keats, does it?) than one could write:
>>>
>>>#template $foo {
>>>foo $x
>>>}
>>>#set $foo.Context.x = "bar"
>>>
>>>$Output.writeToFile($foo,"index.html")
>>>
>>>What do you think of this?
>>>      
>>>
>>If you want to easily write templates to a file, use my AntWMCompile tool.
>>It just processes templates in batches, and dumps them out to an output
>>tree based on the original extension of the template.
>>http://www.wangjammers.org/antwmcompile
>>    
>>
>
>well, I'm actually using AntWMCompile (it's great!) and added some extensions, 
>so that a template knows more about its location. Once I've finished this, 
>I'll write you another mail and explain this changes, perhaps they can be 
>included.
>
>My OutputTool proposal was a reaction on Lane's wish to include such a 
>possibility into the upcoming template-directive. So the requirement is to 
>output templates defined on the fly. I guess Lane wants to do some simple 
>scripting with webmacro. Personally I don't like this, because it puts too 
>much control into the template, in my opinion, but if Lane doesn't care...
>
>In my posting, I wanted to express, that I would rather see this feature not 
>built directly into the #template-directive, because in my opinion, 
>directives should be kept as simple as possible and there are so many 
>different possibilities, where a template should be written to: Into a file, 
>a database, via ftp....
>
>Using a ContextTool for this task would give you this flexibility and would be 
>able to output every macro, not just templates.
>
>Sebastian
>
>  
>

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

[<Kea...@di...>]

I had the same suggestion, except as a directive, e.g.,

#output file="some-file" {
   $someMacro()
}

#ouput stream=$myOutStream {
  $someOtherMacro($x, $y)
}

This wouldn't be useful for a normal servlet, but for other kinds of apps 
it could be very handy.  For example, we built a stand-alone data 
extraction and conversion tool, that would benefit from being able to 
generate multiple files from a single iteration through the data.

Keats





Sebastian Kanthak <seb...@mu...>
Sent by: web...@li...
04/26/2003 09:55 AM

 
        To:     web...@li...
        cc: 
        Subject:        Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees


Hi Marc,

On Saturday 26 April 2003 14:57, Marc Palmer wrote:
> > I think, this should be orthogonal to the Template-Tool/Directive. We
> > could write an "OutputTool" that can write any macro to a file. If the
> > TemplateTool would return a macro (Keats, does it?) than one could 
write:
> >
> > #template $foo {
> > foo $x
> > }
> > #set $foo.Context.x = "bar"
> >
> > $Output.writeToFile($foo,"index.html")
> >
> > What do you think of this?
>
> If you want to easily write templates to a file, use my AntWMCompile 
tool.
> It just processes templates in batches, and dumps them out to an output
> tree based on the original extension of the template.
> http://www.wangjammers.org/antwmcompile

well, I'm actually using AntWMCompile (it's great!) and added some 
extensions, 
so that a template knows more about its location. Once I've finished this, 

I'll write you another mail and explain this changes, perhaps they can be 
included.

My OutputTool proposal was a reaction on Lane's wish to include such a 
possibility into the upcoming template-directive. So the requirement is to 

output templates defined on the fly. I guess Lane wants to do some simple 
scripting with webmacro. Personally I don't like this, because it puts too 

much control into the template, in my opinion, but if Lane doesn't care...

In my posting, I wanted to express, that I would rather see this feature 
not 
built directly into the #template-directive, because in my opinion, 
directives should be kept as simple as possible and there are so many 
different possibilities, where a template should be written to: Into a 
file, 
a database, via ftp....

Using a ContextTool for this task would give you this flexibility and 
would be 
able to output every macro, not just templates.

Sebastian

-- 
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] The double-logging bug?

[Eric B. R. <eb...@tc...>]

On Friday, April 25, 2003, at 05:17  PM, Eric B. Ridge wrote:

> On Thursday, April 24, 2003, at 09:02  AM, Marc Palmer wrote:
>> Does someone who knows the logging code fancy fixing this 
>> double-logging issue we have discussed recently? It's getting hard 
>> for me to get good info from my logs, as I have multiple instances of 
>> WM, possible multiple instances of other code, all doing logging, and 
>> if I get 4 lines of something it's hard to be sure if it is a logging 
>> bug or my code being called twice (and double logging).
>
> I'll try to take a look at it over the next few days.  I'm seeing this 
> in my projects now too (I've seen it all along but never attributed it 
> to this problem until now), so I've got a bit of motivation to fix it.

I cannot duplicate this, in standalone or servlet mode (using Resin).  
Marc, can you make an example that demonstrates?  I'm almost convinced 
that my last fix to the logging stuff (bug reported by Keats) took care 
of this...

eric

[Webmacro-devel] Does WM have this... ?

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

Hiya,

Does WM have a mechanism where directives are called AFTER an "outer" 
template (not an included one) has been fully evaluated?

For example, I'd like to have my directive pool objects, and return them to 
the pool after the template has been executed. If the objects are variables 
placed into the context I can't do this at the moment - as far as I can 
see.

...or is pooling of minor objects futile with most VMs - and our context 
pooling is just to do with the overhead of setting a new context up?

TIA

Marc

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

[Sebastian K. <seb...@mu...>]

Hi Marc,

On Saturday 26 April 2003 14:57, Marc Palmer wrote:
> > I think, this should be orthogonal to the Template-Tool/Directive. We
> > could write an "OutputTool" that can write any macro to a file. If the
> > TemplateTool would return a macro (Keats, does it?) than one could write:
> >
> > #template $foo {
> > foo $x
> > }
> > #set $foo.Context.x = "bar"
> >
> > $Output.writeToFile($foo,"index.html")
> >
> > What do you think of this?
>
> If you want to easily write templates to a file, use my AntWMCompile tool.
> It just processes templates in batches, and dumps them out to an output
> tree based on the original extension of the template.
> http://www.wangjammers.org/antwmcompile

well, I'm actually using AntWMCompile (it's great!) and added some extensions, 
so that a template knows more about its location. Once I've finished this, 
I'll write you another mail and explain this changes, perhaps they can be 
included.

My OutputTool proposal was a reaction on Lane's wish to include such a 
possibility into the upcoming template-directive. So the requirement is to 
output templates defined on the fly. I guess Lane wants to do some simple 
scripting with webmacro. Personally I don't like this, because it puts too 
much control into the template, in my opinion, but if Lane doesn't care...

In my posting, I wanted to express, that I would rather see this feature not 
built directly into the #template-directive, because in my opinion, 
directives should be kept as simple as possible and there are so many 
different possibilities, where a template should be written to: Into a file, 
a database, via ftp....

Using a ContextTool for this task would give you this flexibility and would be 
able to output every macro, not just templates.

Sebastian

-- 
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

On Sat, 26 Apr 2003 12:26:16 +0200, Sebastian Kanthak 
<seb...@mu...> wrote:

> Hi,
>
> On Friday 25 April 2003 16:24, Lane Sharman wrote:
>> Finally, I would like to have an output option:
>>
>> #set $sqr.OutputTarget = "$home/index.html"
>
> I think, this should be orthogonal to the Template-Tool/Directive. We 
> could write an "OutputTool" that can write any macro to a file. If the 
> TemplateTool would return a macro (Keats, does it?) than one could write:
>
> #template $foo {
> foo $x
> }
> #set $foo.Context.x = "bar"
>
> $Output.writeToFile($foo,"index.html")
>
> What do you think of this?

If you want to easily write templates to a file, use my AntWMCompile tool. 
It just processes templates in batches, and dumps them out to an output 
tree based on the original extension of the template. 
http://www.wangjammers.org/antwmcompile

Unless I am misunderstanding the requirements here...

Marc

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

[Sebastian K. <seb...@mu...>]

Hi,

On Friday 25 April 2003 16:24, Lane Sharman wrote:
> Finally, I would like to have an output option:
>
> #set $sqr.OutputTarget = "$home/index.html"

I think, this should be orthogonal to the Template-Tool/Directive. We could 
write an "OutputTool" that can write any macro to a file. If the TemplateTool 
would return a macro (Keats, does it?) than one could write: 

#template $foo {
foo $x
}
#set $foo.Context.x = "bar"

$Output.writeToFile($foo,"index.html")

What do you think of this?

Sebastian

-- 
Sebastian Kanthak
PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html

Re: [Webmacro-devel] The double-logging bug?

[Eric B. R. <eb...@tc...>]

On Thursday, April 24, 2003, at 09:02  AM, Marc Palmer wrote:
> Does someone who knows the logging code fancy fixing this 
> double-logging issue we have discussed recently? It's getting hard for 
> me to get good info from my logs, as I have multiple instances of WM, 
> possible multiple instances of other code, all doing logging, and if I 
> get 4 lines of something it's hard to be sure if it is a logging bug 
> or my code being called twice (and double logging).

I'll try to take a look at it over the next few days.  I'm seeing this 
in my projects now too (I've seen it all along but never attributed it 
to this problem until now), so I've got a bit of motivation to fix it.

eric

>
> It's yucky!
>
> -- 
> Marc Palmer (Wangjammer5)
> http://www.wangjammers.org
> Java Consultants
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

[<Kea...@di...>]

The $Template tool has a  copyCurrentContext() method.  It uses a fresh context by default.  The directive could work the 
same way I suppose, with a copyContext option.

The OutputTarget idea is intriging, but I think it should be its own 
directive, like #output or something.  I've been thinking about this for a 
while.  The #log directive that I created comes close to this, in that you 
can direct output to different log targets.  For certain apps, it would be 
very useful to be able to direct output to multiple streams.  (This is 
something XSLT supports for example.)

Keats





Lane Sharman <la...@op...>
04/25/2003 10:24 AM

 
        To:     Kea...@di...
        cc:     ma...@an..., web...@li...
        Subject:        Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees


Hey Keats,

Glad to hear you are newly employed. Me too!

Yeah, I think we have to do a directive. My design take on it is that it 
should get into the distro as an "in design phase" directive.

One question I have immediately. Does the template inherit the value of 
the evaluating context or not. There are pros and cons to both. Looking at 
your example below, I think not. I would prefer then to say:

#set $sqr.Context.x = 10 
as a more transparent name for what you are doing on behalf of the 
template.

Finally, I would like to have an output option:

#set $sqr.OutputTarget = "$home/index.html"

what do you think?

-Lane

Kea...@di... wrote:

Thanks, Lane. 

I introduced the $Template ContextTool quite a while ago, but I never got 
much feedback.  It's been in the distro, but not enabled by default.   

The syntax is a bit funky.  I'll try to make a Wiki page.  (I'm a bit busy 
right now, having started a new job this week.) 

The code is quite simple.  See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/webmacro/servlet/TemplateTool.java?rev=1.5&content-type=text/vnd.viewcvs-markup 

I'd also like to make a directive version of this.  Something like: 

#template $sqr {   
         #set $y = $x * $x 
         $y 
} 
$sqr.Args.x = 10 
$sqr.eval() 

Thoughts? 

Keats Kirsch
Internet Developer III
Discovery Communications
240-813-2574
Kea...@Di... 




Lane Sharman <la...@op...> 
04/23/2003 11:08 AM 
        
        To:        Kea...@di... 
        cc:        ma...@an..., web...@li... 
        Subject:        Re: [Webmacro-devel] Ugh - the reality of XML and 
flattened trees



Hi Keats,

This is __really cool__.

I would definitely check this in to WM as an example application. So, is 
Template a context tool that is part of the current distro? It basically 
follows a pattern ebr and I worked on a while ago which was to embed in 
the context an instnace of WM to do helper evaluations. I like it!

Could you give some more examples and place them in the distro and write 
up a verbose wiki page too.

-Lane

Kea...@di... wrote:

>I wrote a little demo program to show how this can be done using the
>$Template tool.
>
>The demo simulates a simple threaded message board.  I created a simple
>$Jdom tool so that I could construct the JDOM document in the template.
>The #msg macro adds a new Message element to the JDOM document.
>
>I use #text inside of a #setblock to create the template string. It would
>have been much cleaner to put this a separate file and use
>$Template.fromFile(), but I wanted to have everything in one template for
>simplicity.
>
>In order for the recursion to work, I had to pass a reference to the
>template into the templates context.
>
>Let me know what you think.
>
>Keats
>
>################################# Start of WMScript
>
>#macro msg($parent, $title, $text){
>    #set $junk = $msg.setAttribute("Title", $title)
>    #set $msg.Text = $text
>    #set $junk = $parent.addContent($msg)
>}
>
>#set $el = $Jdom.newElement("Messages")
>#set $doc = $Jdom.newDocument($el)
>
>#msg($el, "JDOM in a WebMacro template", "This is <b>way</b> cool!")
>
>#msg($el, "XSLT sucks", "Actually it's kind of cool, <i>for gear
>heads</i>.")
>
>#msg($el, "Recursive templates", "Does this stuff really work?")
>
>#set $el2 = $msg
>
>#msg($el2, "RE: Recursive templates", "Could be")
>
>#set $el3 = $msg
>
>#msg($el3, "RE: RE: Recursive templates", "Looks like it does!")
>
>#msg($el2, "RE: Recursive template", "You're friggin' nuts!")
>
><h3>Messages</h3>
>
>#setblock $tmplText {
>  #text
>    #foreach $child in $el.Children {
>      <blockquote>
>      <b>$child.AttributeValue.Title</b><br>
>      <i>$child.Text</i><br><br>
>      #set $tmpl.Args.el = $child
>      #set $tmpl.Args.tmpl = $tmpl
>      $tmpl.eval()
>      </blockquote>
>    }
>  #end
>}
>
>#set $tmpl = $Template.fromString($tmplText)
>#set $tmpl.Args.el = $el
>#set $tmpl.Args.tmpl = $tmpl
>$tmpl.eval()
>
> #################################### End of WMScript
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>   
>

Re: [Webmacro-devel] Minor issue with the new WM(Properties)

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

The Map.equals() method as it is implemented in various versions of Java 
is really awful. I would consider another strategy.

I had to fix a system bug in1.2.

Map m = new Hashmap();
Map n = new Hashmap();
m..put("1", m); n..put("1", m);
m.put("2", n);n.put("2", n);
would cause a failure in Java ante 1.3.x: if (m.equals(n))

-Lane

Marc Palmer wrote:

>
> Hiya,
>
> OK Brian's new WM(Properties) handling is largely OK.
>
> However I have found an issue. It relies on Properties.equals() to 
> compare the properties passed in against those used for previous WM 
> instances.
>
> This seems to work OK, unless you construct a Properties that defers 
> to a default Properties object. In this case it returns the wrong WM 
> instances if only the defaults are different.
>
> As I read the JDK 1.4 docs, it looks like Properties.equals is 
> implemented under the terms of Map, which I guess means it doesn't 
> call equals on the defaults. I don't have JDK source installed to 
> check this but it certainly seems like what I was getting.
>
> Basically:
>
> Properties props = new Properties( defaultProps)
> props.putAll( moduleSpecificProps);
> WM wm = new WM( this, props);
>
> Now I might do this many times in my webapp, once for each module 
> defined by the user. The thing is if there are no new properties 
> defined by the module (a rare case, but it has happened during 
> testing) but the defaultProps differ between modules (as they always 
> do), WM returns the same WM instance for all of the modules.
>
> I can workaround this with:
>
> Properties props = new Properties()
> props.putAll( defaultProps);
> props.putAll( moduleSpecificProps);
> WM wm = new WM( this, props);
>
> ...and it works fine.
>
> Marc

Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees

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

Hey Keats,

Glad to hear you are newly employed. Me too!

Yeah, I think we have to do a directive. My design take on it is that it 
should get into the distro as an "in design phase" directive.

One question I have immediately. Does the template inherit the value of 
the evaluating context or not. There are pros and cons to both. Looking 
at your example below, I think not. I would prefer then to say:

#set $sqr.Context.x = 10
as a more transparent name for what you are doing on behalf of the template.

Finally, I would like to have an output option:

#set $sqr.OutputTarget = "$home/index.html"

what do you think?

-Lane

Kea...@di... wrote:

>
> Thanks, Lane.
>
> I introduced the $Template ContextTool quite a while ago, but I never 
> got much feedback.  It's been in the distro, but not enabled by 
> default.  
>
> The syntax is a bit funky.  I'll try to make a Wiki page.  (I'm a bit 
> busy right now, having started a new job this week.)
>
> The code is quite simple.  See 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/webmacro/servlet/TemplateTool.java?rev=1.5&content-type=text/vnd.viewcvs-markup 
>
>
> I'd also like to make a directive version of this.  Something like:
>
> #template $sqr {  
>          #set $y = $x * $x
>          $y
> }
> $sqr.Args.x = 10
> $sqr.eval()
>
> Thoughts?
>
> Keats Kirsch
> Internet Developer III
> Discovery Communications
> 240-813-2574
> Kea...@Di...
>
>
>
>
> Lane Sharman <la...@op...>
>
> 04/23/2003 11:08 AM
>
>        
>         To:        Kea...@di...
>         cc:        ma...@an..., 
> web...@li...
>         Subject:        Re: [Webmacro-devel] Ugh - the reality of XML 
> and flattened trees
>
>
>
>
> Hi Keats,
>
> This is __really cool__.
>
> I would definitely check this in to WM as an example application. So, is
> Template a context tool that is part of the current distro? It basically
> follows a pattern ebr and I worked on a while ago which was to embed in
> the context an instnace of WM to do helper evaluations. I like it!
>
> Could you give some more examples and place them in the distro and write
> up a verbose wiki page too.
>
> -Lane
>
> Kea...@di... wrote:
>
> >I wrote a little demo program to show how this can be done using the
> >$Template tool.
> >
> >The demo simulates a simple threaded message board.  I created a simple
> >$Jdom tool so that I could construct the JDOM document in the template.
> >The #msg macro adds a new Message element to the JDOM document.
> >
> >I use #text inside of a #setblock to create the template string. It would
> >have been much cleaner to put this a separate file and use
> >$Template.fromFile(), but I wanted to have everything in one template for
> >simplicity.
> >
> >In order for the recursion to work, I had to pass a reference to the
> >template into the templates context.
> >
> >Let me know what you think.
> >
> >Keats
> >
> >################################# Start of WMScript
> >
> >#macro msg($parent, $title, $text){
> >    #set $junk = $msg.setAttribute("Title", $title)
> >    #set $msg.Text = $text
> >    #set $junk = $parent.addContent($msg)
> >}
> >
> >#set $el = $Jdom.newElement("Messages")
> >#set $doc = $Jdom.newDocument($el)
> >
> >#msg($el, "JDOM in a WebMacro template", "This is <b>way</b> cool!")
> >
> >#msg($el, "XSLT sucks", "Actually it's kind of cool, <i>for gear
> >heads</i>.")
> >
> >#msg($el, "Recursive templates", "Does this stuff really work?")
> >
> >#set $el2 = $msg
> >
> >#msg($el2, "RE: Recursive templates", "Could be")
> >
> >#set $el3 = $msg
> >
> >#msg($el3, "RE: RE: Recursive templates", "Looks like it does!")
> >
> >#msg($el2, "RE: Recursive template", "You're friggin' nuts!")
> >
> ><h3>Messages</h3>
> >
> >#setblock $tmplText {
> >  #text
> >    #foreach $child in $el.Children {
> >      <blockquote>
> >      <b>$child.AttributeValue.Title</b><br>
> >      <i>$child.Text</i><br><br>
> >      #set $tmpl.Args.el = $child
> >      #set $tmpl.Args.tmpl = $tmpl
> >      $tmpl.eval()
> >      </blockquote>
> >    }
> >  #end
> >}
> >
> >#set $tmpl = $Template.fromString($tmplText)
> >#set $tmpl.Args.el = $el
> >#set $tmpl.Args.tmpl = $tmpl
> >$tmpl.eval()
> >
> > #################################### End of WMScript
> >
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Webmacro-devel mailing list
> >Web...@li...
> >https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >  
> >
>
>
>
>

Re: [Webmacro-devel] Test

[<Kea...@di...>]

Sorry for the spam.  I finally convinced Earthlink to create a Postmaster 
account for surfree.com so I can post to the list again.  Apparently 
they've aquired so many domains, they can't keep track of them.

Ciao

[Webmacro-devel] Test

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

Test message.

Re: [Webmacro-devel] The double-logging bug?

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

On Thu, 24 Apr 2003 14:02:51 +0100, Marc Palmer <ma...@an...> wrote:

>
> Does someone who knows the logging code fancy fixing this double-logging 
> issue we have discussed recently? It's getting hard for me to get good 
> info from my logs, as I have multiple instances of WM, possible multiple 
> instances of other code, all doing logging, and if I get 4 lines of 
> something it's hard to be sure if it is a logging bug or my code being 
> called twice (and double logging).

To be precise, I am definitely seeing one log line per WM instance. I have 
four WM instances - one for the servlet (WMServlet), one for my default 
"module", and one for each of my other test "modules".

So, everything written to the log is appearing 4 times. It's nasty!

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

[Webmacro-devel] The double-logging bug?

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

Does someone who knows the logging code fancy fixing this double-logging 
issue we have discussed recently? It's getting hard for me to get good info 
from my logs, as I have multiple instances of WM, possible multiple 
instances of other code, all doing logging, and if I get 4 lines of 
something it's hard to be sure if it is a logging bug or my code being 
called twice (and double logging).

It's yucky!

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

[Webmacro-devel] Website stuff

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

Hi,

1. A broken link on the site: http://www.webmacro.org/NoServlet - the link 
to Examples in CVS is borked.

2. On the Velocity site they have a LOT of good detailed docs (OK I'm not 
keen on their presentation... Opera can't show it all in a normal page 
width). We have some good docs, but quite a lot is out of date / too brief.

3. See this article on Velocity. http://www.javaworld.com/javaworld/jw-12- 
2001/jw-1228-velocity.html - note how very simple it is to instantiate 
Velocity and evalute a template to a String. Can we get WM that simple, 
what with our FastWriter issues? A helper class to make this kind of thing 
simpler and easier would be useful I think. Lower the barrier to entry as 
much as possible. In fact if we don't have it already, we should be able to 
get the minimum code to eval a template down to a few lines - something 
like:

   WebMacro wm = new WM();
   Template t = wm.getTemplate("mytemplate.wmt");
   Context ctx = wm.getContext();
   wm.evaluate( t, ctx, System.out);

...we should be able to do this to aid the "instant gratification" factor. 
We could take it even further:

   WebMacro wm = new WM();
   Context ctx = wm.getContext();
   wm.evaluate( "mytemplate.wmt", ctx, System.out);

4. Ugh the Velocity syntax is ugly! #set($myvar = "something")  oooooooooh 
no! :)

Just some thoughts. :)

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants