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

Re: [Webmacro-devel] How does #param get to store the value???

[Keats K. <ke...@xa...>]

After going back through the code to refresh my memory, here's what I
believe:

#const is an alias for #attribute.
#attribute and #param are functionally equivalent. 
ParamDirective.build() returns a SetDirective, but I don't think this
serves any useful purpose.

Template.getParameter() returns any variable that is resolved during the
build step.

Keats


Eric B. Ridge wrote:
> One difference, I thought, was that #param made the value accessible
> via Template.getParameter(), whereas #const and #attribute don't.
>
> eric
>
> On Aug 18, 2006, at 11:17 AM, Keats Kirsch wrote:
>
>> The #attribute and #param directives are equivalent, as is the #const
>> directive and even the #set directive if the RHS can be resolved to a
>> constant value at build time.
>>
>> I think we should deprecate #attribute and #param in favor of #const.
>>
>> Keats
>>
>> Alex Fiennes wrote:
>>> Webmacro Gurus,
>>>
>>> I've been having a little bit of a poke around the ParamDirective
>>> functionality to get my head round it and I've just ended up
>>> confusing myself
>>> and I wonder if anyone could give me a quick heads up...
>>>
>>> Where in the codebase does the value the #param get into the Map
>>> that is
>>> picked up in the WMTemplate.parse() functionality and stored in the
>>> newParameters and then the _parameters variable?
>>>
>>> I'm presuming that it must be in the
>>> BlockBuilder.build(BuildContext), but it
>>> is a twisty turny mazy of passages and I can't work it out.
>>>
>>> I'm also confused by the difference between #attribute and #param. 
>>> As far as
>>> I can tell they both do the same thing (ie set an external parameter
>>> and
>>> update the value in the Context for the template to refer to if it
>>> likes).
>>> However, after diffing between the two they are not the same, i.e:-
>>>
>>> - ParamDirective has a named DirectiveDescription, although I'm
>>> assuming that
>>> this is irrelevant
>>>
>>> - ParamDirective returns a new SetDirective as the result of the
>>> build(DirectiveBuilder, BuildContext) whereas AttributeDirective
>>> returns
>>> null.  I haven't as yet worked out what this SetDirective is used
>>> for because
>>> AttributeDirective seems to set the value in the context quite
>>> fine.  There
>>> is no functional difference (that I can spot) between:-
>>>     #attribute $foo = "bar"
>>>     $foo
>>> and
>>>     #param $foo = "bar"
>>>     $foo
>>> even though the javadoc for ParamDirective implies that there should
>>> be a
>>> change.
>>> What is the difference and if there isn't one then why not make a
>>> single class
>>> and then extend it for compatability if required?
>>>
>>> There is one more question that I have about params.
>>> http://www.webmacro.org/ParamDirective &
>>> http://www.webmacro.org/AttributeDirective both state that "The
>>> $variable
>>> argument must be a simple variable (only one term) and the expression
>>> argument must be able to be evaluated statically (not depend on
>>> anything in
>>> the context.)" but this is not strictly speaking true which leads to
>>> some
>>> slightly confusing situations in differences between external
>>> resolutions of
>>> params and in-template resolution of params that can be ambiguous /
>>> confusing.
>>>
>>> Suppose that I write the following:-
>>>
>>> #set $a = "A"
>>> #param $b = $a
>>> $a
>>>
>>> When I evaluate the template I get "A" which is what I would expect
>>> if I was
>>> to treat #param as equal to #set within the template space.
>>>
>>> However, if I invoke template.getParam("b") then I get back a
>>> PropertyVariable
>>> wrapper around $a, which if I was to just assume that my #param was
>>> a String
>>> (which under legitimate usage it should be) would give me
>>> "property:a" with
>>> no warning that I was doing anything at all contrary to the expected
>>> usage of
>>> #param.
>>>
>>> Is there a reason why #param doesn't throw an exception when it has
>>> a RHS that
>>> is *not* statically parseable?  Doing so would not break anything
>>> that wasn't
>>> broken anyway and would make it completely unambiguous.
>>>
>>> In fact I would even go so far as to say that given the target usage
>>> of #param
>>> that the RHS should just be a single basic datatype.  While it is
>>> very nice
>>> to be able to say:-
>>>
>>> #attribute $a = 1
>>> #attribute $b = $a+1
>>>
>>> and have it statically compile to {a=1,b=2} as external parameters,
>>> but my
>>> feeling is that this is still giving you the ability to perform
>>> clever hacks
>>> which may well have very unintended side effects.  Trying to get
>>> #param to
>>> play ball with the in-template code can lead you to start trying to say
>>> things like:-
>>>
>>> #if ($dynamicCondition) {
>>>   #param $foo = "bar"
>>> }
>>> $foo
>>>
>>> which will have the external param *always* set to bar with the
>>> internal value
>>> of $foo conditional on $dynamicCondition.
>>>
>>> Finally there is a bug (feature?) in the implementation of #param and
>>> #attribute that causes a namespace feature in the Context of the
>>> evaluating
>>> template.
>>>
>>> Consider the following three cases:-
>>>
>>> 1.
>>> #set $a = 1
>>> #set $a = 2
>>> $a
>>>
>>> 2.
>>> #set $a = 1
>>> #param $a = 2
>>> $a
>>>
>>> 3.
>>> #param $a = 1
>>> #set $a = 2
>>> $a
>>>
>>> One would expect the value of $a in the Context to be the same for
>>> all three
>>> items, with the value of the external param to be (undefined,2,1)
>>> respectively but in fact case 3 fails with a:-
>>>
>>> org.webmacro.servlet.HandlerException: Unexpected Error
>>> org.webmacro.resource.InvalidResourceException: Error while parsing
>>> template:
>>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
>>> org.webmacro.directive.Directive$NotVariableBuildException: #set:
>>> Argument
>>> must be a variable
>>> java.lang.ClassCastException: java.lang.Integer at
>>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>>>
>>> (line 39 is actually line 2 of my test case above)
>>>
>>> On further investigation, you also get this situation:-
>>>
>>> #param $a = 1
>>> #param $a = 2
>>> $a
>>>
>>> which gives you a:-
>>>
>>> org.webmacro.servlet.HandlerException: Unexpected Error
>>> org.webmacro.resource.InvalidResourceException: Error while parsing
>>> template:
>>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
>>> org.webmacro.directive.Directive$NotVariableBuildException: #null:
>>> Argument
>>> must be a variable
>>> java.lang.ClassCastException at
>>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>>>
>>> So there is obviously some quite odd things going on in terms of the
>>> way that
>>> #param sort of behaves like a #set variable apart from the fact that
>>> you
>>> can't change the value in the template once you've set it (although
>>> you can
>>> override an existing value) and it doesn't honour any other template
>>> flow
>>> logic (but does kind of parse dynamic objects which could then be
>>> resolved
>>> against the context to give a value).
>>>
>>> I'd be tempted to be a little bit radical and state the following (with
>>> blatent disregard as to whether or not it is possible within the
>>> implementation framework):-
>>>
>>> 1. #param can only take really static things, ie static strings or
>>> simple
>>> numbers (ie no arithmetic).  To accept anything else just adds
>>> confusion and
>>> I cannot think of a real-world situation when you would want to do so.
>>>
>>> 2. #params must occur at the beginning of the template in a kind of
>>> "static
>>> declaration block".  By forcing them to come before all other
>>> directives
>>> (content?) it would remove the possible ambiguity with putting them
>>> inside
>>> directives that have no static meaning (#if) yet have very definite
>>> dynamic
>>> meaning.
>>>
>>> 3. I can understand why a template would want dynamic access to the
>>> statically
>>> declared variable.  I can also understand why you would want to make
>>> this
>>> variable immutable (ie if the external world is always going to see
>>> a given
>>> value then the internal template should also see the same value). 
>>> But the
>>> error message when it is redefined should make it clear what it is that
>>> you've done wrong.
>>>
>>> Actually, to tell you the truth I'm not sure about 3 any more
>>> either.  Here's
>>> a nice test case:-
>>>
>>> **template1.wm**
>>> #param $a = 1
>>> Template 1-pre: $a
>>> #include as template "template2.wm"
>>> Template 1-post $a
>>>
>>> **template2.wm**
>>> #param $a = 2
>>> Template 2: $a
>>>
>>> Now we have the external value of $a on template1.wm being 1, the
>>> external
>>> value of $a on template2.wm being 2 and the output of the parse being:-
>>>
>>> Template 1-pre: 1
>>> Template 2: 2
>>> Template 1-post: 1
>>>
>>> And if you change template2.wm to:-
>>>
>>> #set $a=2
>>> Template 2: $a
>>>
>>> then you still get:-
>>>
>>>
>>> Template 1-pre: 1
>>> Template 2: 2
>>> Template 1-post: 1
>>>
>>> which is really odd and in-consistent, ie if you chop your template
>>> up into
>>> sub-templates and invoke them linearly they would behave differently
>>> to if
>>> you just re-assembled the templates back into a single master
>>> template which
>>> feels really odd.  So I'd say that if #param variables are readable
>>> inside
>>> the template then they should be *really* immutable, not just immutable
>>> within their current template.  Otherwise you should go:-
>>>
>>> #param $foo = "bar"
>>> #set $foo = "bar"
>>>
>>> and have two namespaces, one immutable external and one mutable
>>> internal.
>>>
>>> I appear to have strayed somewhat from my original brief (getting my
>>> head
>>> around the character encodings in a sensible fashion) but there is a
>>> method
>>> to my madness - I just need to get a couple of things straight first...
>>> Alex
>>>
>>> -------------------------------------------------------------------------
>>>
>>> Using Tomcat but need to do more? Need to support web services,
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make your
>>> job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>
>>> _______________________________________________
>>> Webmacro-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>

Re: [Webmacro-devel] How does #param get to store the value???

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

One difference, I thought, was that #param made the value accessible  
via Template.getParameter(), whereas #const and #attribute don't.

eric

On Aug 18, 2006, at 11:17 AM, Keats Kirsch wrote:

> The #attribute and #param directives are equivalent, as is the #const
> directive and even the #set directive if the RHS can be resolved to a
> constant value at build time.
>
> I think we should deprecate #attribute and #param in favor of #const.
>
> Keats
>
> Alex Fiennes wrote:
>> Webmacro Gurus,
>>
>> I've been having a little bit of a poke around the ParamDirective
>> functionality to get my head round it and I've just ended up  
>> confusing myself
>> and I wonder if anyone could give me a quick heads up...
>>
>> Where in the codebase does the value the #param get into the Map  
>> that is
>> picked up in the WMTemplate.parse() functionality and stored in the
>> newParameters and then the _parameters variable?
>>
>> I'm presuming that it must be in the BlockBuilder.build 
>> (BuildContext), but it
>> is a twisty turny mazy of passages and I can't work it out.
>>
>> I'm also confused by the difference between #attribute and  
>> #param.  As far as
>> I can tell they both do the same thing (ie set an external  
>> parameter and
>> update the value in the Context for the template to refer to if it  
>> likes).
>> However, after diffing between the two they are not the same, i.e:-
>>
>> - ParamDirective has a named DirectiveDescription, although I'm  
>> assuming that
>> this is irrelevant
>>
>> - ParamDirective returns a new SetDirective as the result of the
>> build(DirectiveBuilder, BuildContext) whereas AttributeDirective  
>> returns
>> null.  I haven't as yet worked out what this SetDirective is used  
>> for because
>> AttributeDirective seems to set the value in the context quite  
>> fine.  There
>> is no functional difference (that I can spot) between:-
>> 	#attribute $foo = "bar"
>> 	$foo
>> and
>> 	#param $foo = "bar"
>> 	$foo
>> even though the javadoc for ParamDirective implies that there  
>> should be a
>> change.
>> What is the difference and if there isn't one then why not make a  
>> single class
>> and then extend it for compatability if required?
>>
>> There is one more question that I have about params.
>> http://www.webmacro.org/ParamDirective &
>> http://www.webmacro.org/AttributeDirective both state that "The  
>> $variable
>> argument must be a simple variable (only one term) and the expression
>> argument must be able to be evaluated statically (not depend on  
>> anything in
>> the context.)" but this is not strictly speaking true which leads  
>> to some
>> slightly confusing situations in differences between external  
>> resolutions of
>> params and in-template resolution of params that can be ambiguous /
>> confusing.
>>
>> Suppose that I write the following:-
>>
>> #set $a = "A"
>> #param $b = $a
>> $a
>>
>> When I evaluate the template I get "A" which is what I would  
>> expect if I was
>> to treat #param as equal to #set within the template space.
>>
>> However, if I invoke template.getParam("b") then I get back a  
>> PropertyVariable
>> wrapper around $a, which if I was to just assume that my #param  
>> was a String
>> (which under legitimate usage it should be) would give me  
>> "property:a" with
>> no warning that I was doing anything at all contrary to the  
>> expected usage of
>> #param.
>>
>> Is there a reason why #param doesn't throw an exception when it  
>> has a RHS that
>> is *not* statically parseable?  Doing so would not break anything  
>> that wasn't
>> broken anyway and would make it completely unambiguous.
>>
>> In fact I would even go so far as to say that given the target  
>> usage of #param
>> that the RHS should just be a single basic datatype.  While it is  
>> very nice
>> to be able to say:-
>>
>> #attribute $a = 1
>> #attribute $b = $a+1
>>
>> and have it statically compile to {a=1,b=2} as external  
>> parameters, but my
>> feeling is that this is still giving you the ability to perform  
>> clever hacks
>> which may well have very unintended side effects.  Trying to get  
>> #param to
>> play ball with the in-template code can lead you to start trying  
>> to say
>> things like:-
>>
>> #if ($dynamicCondition) {
>>   #param $foo = "bar"
>> }
>> $foo
>>
>> which will have the external param *always* set to bar with the  
>> internal value
>> of $foo conditional on $dynamicCondition.
>>
>> Finally there is a bug (feature?) in the implementation of #param and
>> #attribute that causes a namespace feature in the Context of the  
>> evaluating
>> template.
>>
>> Consider the following three cases:-
>>
>> 1.
>> #set $a = 1
>> #set $a = 2
>> $a
>>
>> 2.
>> #set $a = 1
>> #param $a = 2
>> $a
>>
>> 3.
>> #param $a = 1
>> #set $a = 2
>> $a
>>
>> One would expect the value of $a in the Context to be the same for  
>> all three
>> items, with the value of the external param to be (undefined,2,1)
>> respectively but in fact case 3 fails with a:-
>>
>> org.webmacro.servlet.HandlerException: Unexpected Error
>> org.webmacro.resource.InvalidResourceException: Error while  
>> parsing template:
>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
>> org.webmacro.directive.Directive$NotVariableBuildException: #set:  
>> Argument
>> must be a variable
>> java.lang.ClassCastException: java.lang.Integer at
>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>>
>> (line 39 is actually line 2 of my test case above)
>>
>> On further investigation, you also get this situation:-
>>
>> #param $a = 1
>> #param $a = 2
>> $a
>>
>> which gives you a:-
>>
>> org.webmacro.servlet.HandlerException: Unexpected Error
>> org.webmacro.resource.InvalidResourceException: Error while  
>> parsing template:
>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
>> org.webmacro.directive.Directive$NotVariableBuildException: #null:  
>> Argument
>> must be a variable
>> java.lang.ClassCastException at
>> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>>
>> So there is obviously some quite odd things going on in terms of  
>> the way that
>> #param sort of behaves like a #set variable apart from the fact  
>> that you
>> can't change the value in the template once you've set it  
>> (although you can
>> override an existing value) and it doesn't honour any other  
>> template flow
>> logic (but does kind of parse dynamic objects which could then be  
>> resolved
>> against the context to give a value).
>>
>> I'd be tempted to be a little bit radical and state the following  
>> (with
>> blatent disregard as to whether or not it is possible within the
>> implementation framework):-
>>
>> 1. #param can only take really static things, ie static strings or  
>> simple
>> numbers (ie no arithmetic).  To accept anything else just adds  
>> confusion and
>> I cannot think of a real-world situation when you would want to do  
>> so.
>>
>> 2. #params must occur at the beginning of the template in a kind  
>> of "static
>> declaration block".  By forcing them to come before all other  
>> directives
>> (content?) it would remove the possible ambiguity with putting  
>> them inside
>> directives that have no static meaning (#if) yet have very  
>> definite dynamic
>> meaning.
>>
>> 3. I can understand why a template would want dynamic access to  
>> the statically
>> declared variable.  I can also understand why you would want to  
>> make this
>> variable immutable (ie if the external world is always going to  
>> see a given
>> value then the internal template should also see the same value).   
>> But the
>> error message when it is redefined should make it clear what it is  
>> that
>> you've done wrong.
>>
>> Actually, to tell you the truth I'm not sure about 3 any more  
>> either.  Here's
>> a nice test case:-
>>
>> **template1.wm**
>> #param $a = 1
>> Template 1-pre: $a
>> #include as template "template2.wm"
>> Template 1-post $a
>>
>> **template2.wm**
>> #param $a = 2
>> Template 2: $a
>>
>> Now we have the external value of $a on template1.wm being 1, the  
>> external
>> value of $a on template2.wm being 2 and the output of the parse  
>> being:-
>>
>> Template 1-pre: 1
>> Template 2: 2
>> Template 1-post: 1
>>
>> And if you change template2.wm to:-
>>
>> #set $a=2
>> Template 2: $a
>>
>> then you still get:-
>>
>>
>> Template 1-pre: 1
>> Template 2: 2
>> Template 1-post: 1
>>
>> which is really odd and in-consistent, ie if you chop your  
>> template up into
>> sub-templates and invoke them linearly they would behave  
>> differently to if
>> you just re-assembled the templates back into a single master  
>> template which
>> feels really odd.  So I'd say that if #param variables are  
>> readable inside
>> the template then they should be *really* immutable, not just  
>> immutable
>> within their current template.  Otherwise you should go:-
>>
>> #param $foo = "bar"
>> #set $foo = "bar"
>>
>> and have two namespaces, one immutable external and one mutable  
>> internal.
>>
>> I appear to have strayed somewhat from my original brief (getting  
>> my head
>> around the character encodings in a sensible fashion) but there is  
>> a method
>> to my madness - I just need to get a couple of things straight  
>> first...
>> Alex
>>
>> --------------------------------------------------------------------- 
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>
>>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] How does #param get to store the value???

[Keats K. <ke...@xa...>]

The #attribute and #param directives are equivalent, as is the #const
directive and even the #set directive if the RHS can be resolved to a
constant value at build time.

I think we should deprecate #attribute and #param in favor of #const.

Keats

Alex Fiennes wrote:
> Webmacro Gurus,
>
> I've been having a little bit of a poke around the ParamDirective 
> functionality to get my head round it and I've just ended up confusing myself 
> and I wonder if anyone could give me a quick heads up...
>
> Where in the codebase does the value the #param get into the Map that is 
> picked up in the WMTemplate.parse() functionality and stored in the 
> newParameters and then the _parameters variable?
>
> I'm presuming that it must be in the BlockBuilder.build(BuildContext), but it 
> is a twisty turny mazy of passages and I can't work it out.
>
> I'm also confused by the difference between #attribute and #param.  As far as 
> I can tell they both do the same thing (ie set an external parameter and 
> update the value in the Context for the template to refer to if it likes).  
> However, after diffing between the two they are not the same, i.e:-
>
> - ParamDirective has a named DirectiveDescription, although I'm assuming that 
> this is irrelevant
>
> - ParamDirective returns a new SetDirective as the result of the 
> build(DirectiveBuilder, BuildContext) whereas AttributeDirective returns 
> null.  I haven't as yet worked out what this SetDirective is used for because 
> AttributeDirective seems to set the value in the context quite fine.  There 
> is no functional difference (that I can spot) between:-
> 	#attribute $foo = "bar"
> 	$foo
> and
> 	#param $foo = "bar"
> 	$foo
> even though the javadoc for ParamDirective implies that there should be a 
> change.
> What is the difference and if there isn't one then why not make a single class 
> and then extend it for compatability if required?
>
> There is one more question that I have about params.  
> http://www.webmacro.org/ParamDirective & 
> http://www.webmacro.org/AttributeDirective both state that "The $variable 
> argument must be a simple variable (only one term) and the expression 
> argument must be able to be evaluated statically (not depend on anything in 
> the context.)" but this is not strictly speaking true which leads to some 
> slightly confusing situations in differences between external resolutions of 
> params and in-template resolution of params that can be ambiguous / 
> confusing.
>
> Suppose that I write the following:-
>
> #set $a = "A"
> #param $b = $a
> $a
>
> When I evaluate the template I get "A" which is what I would expect if I was 
> to treat #param as equal to #set within the template space.
>
> However, if I invoke template.getParam("b") then I get back a PropertyVariable 
> wrapper around $a, which if I was to just assume that my #param was a String 
> (which under legitimate usage it should be) would give me "property:a" with 
> no warning that I was doing anything at all contrary to the expected usage of 
> #param.
>
> Is there a reason why #param doesn't throw an exception when it has a RHS that 
> is *not* statically parseable?  Doing so would not break anything that wasn't 
> broken anyway and would make it completely unambiguous.
>
> In fact I would even go so far as to say that given the target usage of #param 
> that the RHS should just be a single basic datatype.  While it is very nice 
> to be able to say:-
>
> #attribute $a = 1
> #attribute $b = $a+1
>
> and have it statically compile to {a=1,b=2} as external parameters, but my 
> feeling is that this is still giving you the ability to perform clever hacks 
> which may well have very unintended side effects.  Trying to get #param to 
> play ball with the in-template code can lead you to start trying to say 
> things like:-
>
> #if ($dynamicCondition) {
>   #param $foo = "bar"
> }
> $foo
>
> which will have the external param *always* set to bar with the internal value 
> of $foo conditional on $dynamicCondition.
>
> Finally there is a bug (feature?) in the implementation of #param and 
> #attribute that causes a namespace feature in the Context of the evaluating 
> template.
>
> Consider the following three cases:-
>
> 1.
> #set $a = 1
> #set $a = 2
> $a
>
> 2.
> #set $a = 1
> #param $a = 2
> $a
>
> 3.
> #param $a = 1
> #set $a = 2
> $a
>
> One would expect the value of $a in the Context to be the same for all three 
> items, with the value of the external param to be (undefined,2,1) 
> respectively but in fact case 3 fails with a:-
>
> org.webmacro.servlet.HandlerException: Unexpected Error
> org.webmacro.resource.InvalidResourceException: Error while parsing template: 
> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
> org.webmacro.directive.Directive$NotVariableBuildException: #set: Argument 
> must be a variable
> java.lang.ClassCastException: java.lang.Integer at 
> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>
> (line 39 is actually line 2 of my test case above)
>
> On further investigation, you also get this situation:-
>
> #param $a = 1
> #param $a = 2
> $a
>
> which gives you a:-
>
> org.webmacro.servlet.HandlerException: Unexpected Error
> org.webmacro.resource.InvalidResourceException: Error while parsing template: 
> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
> org.webmacro.directive.Directive$NotVariableBuildException: #null: Argument 
> must be a variable
> java.lang.ClassCastException at 
> jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2
>
> So there is obviously some quite odd things going on in terms of the way that 
> #param sort of behaves like a #set variable apart from the fact that you 
> can't change the value in the template once you've set it (although you can 
> override an existing value) and it doesn't honour any other template flow 
> logic (but does kind of parse dynamic objects which could then be resolved 
> against the context to give a value).
>
> I'd be tempted to be a little bit radical and state the following (with 
> blatent disregard as to whether or not it is possible within the 
> implementation framework):-
>
> 1. #param can only take really static things, ie static strings or simple 
> numbers (ie no arithmetic).  To accept anything else just adds confusion and 
> I cannot think of a real-world situation when you would want to do so.
>
> 2. #params must occur at the beginning of the template in a kind of "static 
> declaration block".  By forcing them to come before all other directives 
> (content?) it would remove the possible ambiguity with putting them inside 
> directives that have no static meaning (#if) yet have very definite dynamic 
> meaning.
>
> 3. I can understand why a template would want dynamic access to the statically 
> declared variable.  I can also understand why you would want to make this 
> variable immutable (ie if the external world is always going to see a given 
> value then the internal template should also see the same value).  But the 
> error message when it is redefined should make it clear what it is that 
> you've done wrong.
>
> Actually, to tell you the truth I'm not sure about 3 any more either.  Here's 
> a nice test case:-
>
> **template1.wm**
> #param $a = 1
> Template 1-pre: $a
> #include as template "template2.wm"
> Template 1-post $a
>
> **template2.wm**
> #param $a = 2
> Template 2: $a
>
> Now we have the external value of $a on template1.wm being 1, the external 
> value of $a on template2.wm being 2 and the output of the parse being:-
>
> Template 1-pre: 1
> Template 2: 2
> Template 1-post: 1
>
> And if you change template2.wm to:-
>
> #set $a=2
> Template 2: $a
>
> then you still get:-
>
>
> Template 1-pre: 1
> Template 2: 2
> Template 1-post: 1
>
> which is really odd and in-consistent, ie if you chop your template up into 
> sub-templates and invoke them linearly they would behave differently to if 
> you just re-assembled the templates back into a single master template which 
> feels really odd.  So I'd say that if #param variables are readable inside 
> the template then they should be *really* immutable, not just immutable 
> within their current template.  Otherwise you should go:-
>
> #param $foo = "bar"
> #set $foo = "bar"
>
> and have two namespaces, one immutable external and one mutable internal.
>
> I appear to have strayed somewhat from my original brief (getting my head 
> around the character encodings in a sensible fashion) but there is a method 
> to my madness - I just need to get a couple of things straight first...
> Alex
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>   

[Webmacro-devel] Single encoding for all depths of template nesting?

[Alex F. <al...@fi...>]

All,

Currently (due to my work on not building lots of FastWriters) the 
EvalDirective would not be able to do an elegant and correct thing in the 
following situation:-

*template1*
#param $TemplateOutputEncoding="utf-8"
$paramToBeRenderedAsUtf8
#include as template "template2"

*template2*
#param $TemplateOutputEncoding="iso-8859-1"
$paramToBeRenderedAs8859

Now, I can think of no earthly reason *why* you would want to be able to do 
that as even if it was supported then the outer template would convert the 
88859 rendered inner template to utf-8 as it got written to the outer 
template so it would theoretically come up with the same thing.

However, if you had a non-8859 supported character inside 
$paramToBeRenderedAs8859 then template2 would end up with a '?' inside the 
output that would be preserved out into the utf-8 representation whereas if 
we just treated the entire thing as a single utf-8 FastWriter (ie only honour 
the outermost TemplateOutputEncoding) then the non-8859 character would be 
preserved.

I'm tempted to say that trying to declare a second value of 
TemplateOutputEncoding that is either different from the initial 
TemplateOutputEncoding should be an error condition.  The only time that I 
can see (from a servlet perspective) a reason to set the 
TemplateOutputEncoding is to ensure that you are writing your (X)HTML in an 
encoding that can be sent to the client and in which case there is absolutely 
nothing to be gained by being able to override it on nested templates (other 
than bad performance and a nightmare debugging situation).

In fact the only time that I can possibly think of wanting to set different 
TemplateOutputEncodings for your rendering in a servlet context are:-

- if you are automatically trying to provide something that the client can 
support.  However, in this case it is *not* a statically evaluatable variable 
as it requires the data inside the HttpRequest and therefore cannot be 
handled by #param and instead would be much better handled by a tool inside 
the WMServlet.  In this case you might be looking at saying:-
  #param $SupportedTemplateOutputEncodings = "utf-8, iso-8859-1, ascii"
and then writing some code that sits between the Template parse and the 
Template eval which grabs SupportedTemplateOutputEncodings, matches it up 
against the supported encodings in the HttpRequest, picks the best one, sets 
up the FastWriter and then drops a value of TemplateOutputEncoding into the 
Context (just in case you really want to know what you are rendering to).

- if you have a series of different root templates for different language 
versions of your site.  These would be responsible for setting up the 
appropriate encodings for the different regions, and therefore would probably 
want to be able to set their TemplateOutputEncodings appropriately, but this 
would be handled fine by the above.

Is there anyone out there who is using #param TemplateOutputEncoding in their 
production servlets in a WMServlet context who would continue to use it if 
the TemplateOutputEncoding functionality in the WebMacro.properties worked 
correctly in the current version of WMServlet?  Can you send me a summary of 
how you are using it?

Alex

[Webmacro-devel] How does #param get to store the value???

[Alex F. <al...@fi...>]

Webmacro Gurus,

I've been having a little bit of a poke around the ParamDirective 
functionality to get my head round it and I've just ended up confusing myself 
and I wonder if anyone could give me a quick heads up...

Where in the codebase does the value the #param get into the Map that is 
picked up in the WMTemplate.parse() functionality and stored in the 
newParameters and then the _parameters variable?

I'm presuming that it must be in the BlockBuilder.build(BuildContext), but it 
is a twisty turny mazy of passages and I can't work it out.

I'm also confused by the difference between #attribute and #param.  As far as 
I can tell they both do the same thing (ie set an external parameter and 
update the value in the Context for the template to refer to if it likes).  
However, after diffing between the two they are not the same, i.e:-

- ParamDirective has a named DirectiveDescription, although I'm assuming that 
this is irrelevant

- ParamDirective returns a new SetDirective as the result of the 
build(DirectiveBuilder, BuildContext) whereas AttributeDirective returns 
null.  I haven't as yet worked out what this SetDirective is used for because 
AttributeDirective seems to set the value in the context quite fine.  There 
is no functional difference (that I can spot) between:-
	#attribute $foo = "bar"
	$foo
and
	#param $foo = "bar"
	$foo
even though the javadoc for ParamDirective implies that there should be a 
change.
What is the difference and if there isn't one then why not make a single class 
and then extend it for compatability if required?

There is one more question that I have about params.  
http://www.webmacro.org/ParamDirective & 
http://www.webmacro.org/AttributeDirective both state that "The $variable 
argument must be a simple variable (only one term) and the expression 
argument must be able to be evaluated statically (not depend on anything in 
the context.)" but this is not strictly speaking true which leads to some 
slightly confusing situations in differences between external resolutions of 
params and in-template resolution of params that can be ambiguous / 
confusing.

Suppose that I write the following:-

#set $a = "A"
#param $b = $a
$a

When I evaluate the template I get "A" which is what I would expect if I was 
to treat #param as equal to #set within the template space.

However, if I invoke template.getParam("b") then I get back a PropertyVariable 
wrapper around $a, which if I was to just assume that my #param was a String 
(which under legitimate usage it should be) would give me "property:a" with 
no warning that I was doing anything at all contrary to the expected usage of 
#param.

Is there a reason why #param doesn't throw an exception when it has a RHS that 
is *not* statically parseable?  Doing so would not break anything that wasn't 
broken anyway and would make it completely unambiguous.

In fact I would even go so far as to say that given the target usage of #param 
that the RHS should just be a single basic datatype.  While it is very nice 
to be able to say:-

#attribute $a = 1
#attribute $b = $a+1

and have it statically compile to {a=1,b=2} as external parameters, but my 
feeling is that this is still giving you the ability to perform clever hacks 
which may well have very unintended side effects.  Trying to get #param to 
play ball with the in-template code can lead you to start trying to say 
things like:-

#if ($dynamicCondition) {
  #param $foo = "bar"
}
$foo

which will have the external param *always* set to bar with the internal value 
of $foo conditional on $dynamicCondition.

Finally there is a bug (feature?) in the implementation of #param and 
#attribute that causes a namespace feature in the Context of the evaluating 
template.

Consider the following three cases:-

1.
#set $a = 1
#set $a = 2
$a

2.
#set $a = 1
#param $a = 2
$a

3.
#param $a = 1
#set $a = 2
$a

One would expect the value of $a in the Context to be the same for all three 
items, with the value of the external param to be (undefined,2,1) 
respectively but in fact case 3 fails with a:-

org.webmacro.servlet.HandlerException: Unexpected Error
org.webmacro.resource.InvalidResourceException: Error while parsing template: 
jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
org.webmacro.directive.Directive$NotVariableBuildException: #set: Argument 
must be a variable
java.lang.ClassCastException: java.lang.Integer at 
jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2

(line 39 is actually line 2 of my test case above)

On further investigation, you also get this situation:-

#param $a = 1
#param $a = 2
$a

which gives you a:-

org.webmacro.servlet.HandlerException: Unexpected Error
org.webmacro.resource.InvalidResourceException: Error while parsing template: 
jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html
org.webmacro.directive.Directive$NotVariableBuildException: #null: Argument 
must be a variable
java.lang.ClassCastException at 
jndi:/localhost/spa/WEB-INF/templates/spa/home.wm.html:39.2

So there is obviously some quite odd things going on in terms of the way that 
#param sort of behaves like a #set variable apart from the fact that you 
can't change the value in the template once you've set it (although you can 
override an existing value) and it doesn't honour any other template flow 
logic (but does kind of parse dynamic objects which could then be resolved 
against the context to give a value).

I'd be tempted to be a little bit radical and state the following (with 
blatent disregard as to whether or not it is possible within the 
implementation framework):-

1. #param can only take really static things, ie static strings or simple 
numbers (ie no arithmetic).  To accept anything else just adds confusion and 
I cannot think of a real-world situation when you would want to do so.

2. #params must occur at the beginning of the template in a kind of "static 
declaration block".  By forcing them to come before all other directives 
(content?) it would remove the possible ambiguity with putting them inside 
directives that have no static meaning (#if) yet have very definite dynamic 
meaning.

3. I can understand why a template would want dynamic access to the statically 
declared variable.  I can also understand why you would want to make this 
variable immutable (ie if the external world is always going to see a given 
value then the internal template should also see the same value).  But the 
error message when it is redefined should make it clear what it is that 
you've done wrong.

Actually, to tell you the truth I'm not sure about 3 any more either.  Here's 
a nice test case:-

**template1.wm**
#param $a = 1
Template 1-pre: $a
#include as template "template2.wm"
Template 1-post $a

**template2.wm**
#param $a = 2
Template 2: $a

Now we have the external value of $a on template1.wm being 1, the external 
value of $a on template2.wm being 2 and the output of the parse being:-

Template 1-pre: 1
Template 2: 2
Template 1-post: 1

And if you change template2.wm to:-

#set $a=2
Template 2: $a

then you still get:-


Template 1-pre: 1
Template 2: 2
Template 1-post: 1

which is really odd and in-consistent, ie if you chop your template up into 
sub-templates and invoke them linearly they would behave differently to if 
you just re-assembled the templates back into a single master template which 
feels really odd.  So I'd say that if #param variables are readable inside 
the template then they should be *really* immutable, not just immutable 
within their current template.  Otherwise you should go:-

#param $foo = "bar"
#set $foo = "bar"

and have two namespaces, one immutable external and one mutable internal.

I appear to have strayed somewhat from my original brief (getting my head 
around the character encodings in a sensible fashion) but there is a method 
to my madness - I just need to get a couple of things straight first...
Alex

Re: [Webmacro-devel] Interesting character encoding behaviour

[Alex F. <al...@fi...>]

On Wednesday 16 August 2006 15:33, you wrote:
> the tests ... what you see is what you get :)=20

thats a shame.  writing tests for character encodings makes my head hurt!

I've been having a little think about it and for servlets it basically brea=
ks=20
down into 3 things that need to be defined:-

1 what encoding the templates are stored in on the disk
2 what encoding the FastWriter is going to render to
3 what encoding the HttpResponse tells the browser that the encoding is in.

My understanding is that 1 is pretty well handled and we don't need to worr=
y=20
about this that much.

2 & 3 are currently a bit decoupled and it would be nice to bring them back=
=20
into some kind of situation where there is a clean way of setting both of=20
them (almost definitely a #param call).

=46inally there is the possibility of looking at the Accept-Charset header =
in=20
the HttpRequest to see whether or not our proposed character encoding is=20
going to be accepted by the requested browser.  If we start to look at this=
=20
then we will need to also look at specifying lists of character encodings,=
=20
ie "use utf-8 if possible otherwise fall back to iso-8859-1", but this migh=
t=20
be over-complicating things.  I think that it would definitely be nice to t=
ry=20
and get some kind of logged warning if you try and use an encoding that the=
=20
client doesn't support...

Now if we are not working in a servlet environment then I think that the li=
st=20
pretty much shortens down to 1 & 2 and becomes a lot simpler.  However, I m=
ay=20
have missed some of the more obscure usages of webmacro in the real world. =
=20
Does anyone have any examples of this which I should know about?

> and when you have the=20
> solution to global warming, please forward to calif where it has been
> awfully warm lately.

Same in Scotland.  Might be popping over to your neck of the woods in a mon=
th=20
or so for a little music tour so I'll pack light clothes...

Alex

> -Lane
>
> Alex Fiennes wrote:
> >On Tuesday 15 August 2006 20:06, Lane Sharman wrote:
> >>Hi Alex,
> >>
> >>Why don't you propose a solution that is consistent, undestandable and
> >>that can be implemented for the benefit of all users?
> >
> >I'll do this once I've finished sorting out the global warming problem...
> > ;-)
> >
> >Seriously though - I'll try and put together some unit tests and some
> >documentation that accurately reflects the current CVS tree and then we
> > can decide what (if any) tweaks would make it more transparent.
> >
> >I think that most of the tools are all there, but there are a couple of
> > quirks in terms of which ones get used depending on the usage of the
> > various usage models for the framework.  So it may well just be a case =
of
> > clear documentation to reduce confusion.
> >
> >Before I get started, are there any other relevant unit tests other than=
:-
> >./template/EncodingTestCase.java
> >./template/TestISO88591Encoding.java
> >./template/TestWindows1251Encoding.java
> >
> >Alex
> >
> >>Lane
> >>
> >>Alex Fiennes wrote:
> >>>Keats (et al),
> >>>
> >>>On Monday 14 August 2006 18:29, Keats Kirsch wrote:
> >>>>This is all a very faint (and painful) memory, but I believe that when
> >>>>running as a Servlet the output encoding from the request is preferre=
d.
> >>>>
> >>>>Hope this helps.
> >>>
> >>>I've been doing a little bit of digging around on this and it appears
> >>> from a quick scan of the current CVS that doing anything from the
> >>> $Response context tool in the templates is not going to work for the
> >>> following reason:-
> >>>
> >>>WMServlet.java defines the execute method as follows (logging methods
> >>>stripped out):-
> >>>
> >>>HttpServletResponse resp =3D c.getResponse();
> >>>Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
> >>>if (locale !=3D null) {
> >>> setLocale(resp, locale);
> >>>}
> >>>String encoding
> >>> =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >>>if (encoding =3D=3D null) {
> >>> encoding =3D resp.getCharacterEncoding();
> >>>}
> >>>byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
> >>>writeResponseBytes(resp, bytes, encoding);
> >>>
> >>>On first glance this *will* honour the character encoding of the
> >>> response, but unfortunately if you are setting the character encoding
> >>> via the context tool in terms of:-
> >>>
> >>>#set $Response.ContentType =3D "text/html;charset=3Dutf-8"
> >>>
> >>>then this will not happen until the template is evaluated which is
> >>> *after* the encoding has been derived from the template and therefore
> >>> the template will always take the default encoding (from the javadoc
> >>> "If no character encoding has been specified, ISO-8859-1 is returned"=
).
> >>>  So unless you use an explicit call to set up the template encoding
> >>> using something like:-
> >>>
> >>>#param $TemplateOutputEncoding=3D"utf-8"
> >>>
> >>>then the actual encoding of the template will always be done as 8859-1,
> >>>although the HTTP headers (as defined by the response) may well say th=
at
> >>>it is *supposed* to be utf-8.
> >>>
> >>>I am not aware of anything other than the #param to enable a template =
to
> >>>define information that is available to webmacro before it is executed.
> >>>If this is correct then the information on the
> >>>http://www.webmacro.org/CharacterEncoding is probably actually incorre=
ct
> >>>as this will not set the encoding used to render the template when it =
is
> >>>evaluated.
> >>>
> >>>The only change that I would suggest to the actual code is to make it =
so
> >>>that if you do set the encoding with the #param call then it should
> >>>automatically update the response character encoding to at least try a=
nd
> >>>keep the webmacro encoding in sync with the response headers.  The oth=
er
> >>>change would be to make it so that it is prepared to use the
> >>>TemplateOutputEncoding in the WebMacro.properties file as well (which =
is
> >>>currently only utilised in the writeTemplate methods and completely
> >>>ignored for the default execute method). This would give us a code blo=
ck
> >>>of something like:-
> >>>
> >>>HttpServletResponse resp =3D c.getResponse();
> >>>Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
> >>>if (locale !=3D null) {
> >>> setLocale(resp, locale);
> >>>}
> >>>String encoding
> >>> =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >>>if (encoding =3D=3D null) {
> >>> encoding =3D getConfig(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >>>}
> >>>if (encoding =3D=3D null) {
> >>> encoding =3D resp.getCharacterEncoding();
> >>>} else {
> >>> resp.setCharacterEncoding(encoding);
> >>>}
> >>>byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
> >>>writeResponseBytes(resp, bytes, encoding);
> >>>
> >>>You can of course still cause it to freak out by doing something just
> >>>awkward like this:-
> >>>
> >>>#param $TemplateOutputEncoding =3D "utf-8"
> >>>#set $Response.ContentType =3D "text/html;charset=3Diso-8859-1"
> >>>
> >>>which would cause it to render the template in utf-8 but tell the
> >>> browser that it was in iso-8859-1, but that is kind of your own fault=
=2E=20
> >>> More importantly, a single call to:-
> >>>
> >>>#param $TemplateOutputEncoding =3D "utf-8"
> >>>
> >>>with no $Response tweaking should get the correct headers sent to the
> >>>client...
> >>>
> >>>let me know if this makes any kind of sense to you guys.
> >>>
> >>>Alex
> >>>
> >>>>Alex Fiennes wrote:
> >>>>>All,
> >>>>>
> >>>>>just been playing around with some character encoding bugs (oh how I
> >>>>>love character encodings) and I found the following behaviours that
> >>>>>didn't seem to be quite correct and I thought I'd drop them out to t=
he
> >>>>>list and see if other folk thought that they were actually bugs or
> >>>>> not.
> >>>>>
> >>>>>I've got a web application running under tomcat5 on linux so the
> >>>>> default platform encoding is iso-8859-1.
> >>>>>
> >>>>>I have a variable $string that contains some utf8 characters, namely
> >>>>>8217 or "strange backwards apostrophe".
> >>>>>
> >>>>>I am overriding WMServlet, and if I just drop $string into the conte=
xt
> >>>>>and return a template that references $string then I get a "?" inste=
ad
> >>>>>of a "=E2=80=99", which is because it is being flattened into ISO-88=
59-1 and
> >>>>>this is a non-supported character.  All good and fine.
> >>>>>
> >>>>>After a bit of hacking around in the source code, I discovered that
> >>>>> you can do:-
> >>>>>
> >>>>>#param $TemplateOutputEncoding =3D "utf-8"
> >>>>>
> >>>>>which now gives me the correct result. (It might be worth adding this
> >>>>> to http://www.webmacro.org/CharacterEncoding for future reference)
> >>>>>
> >>>>>Interestingly enough, if I ommit the #param from my template, but
> >>>>>instead define:-
> >>>>>TemplateOutputEncoding=3Dutf-8
> >>>>>...in my WebMacro.properties file then it doesn't work and I'm back =
to
> >>>>>the "?" so presumably it is 8859-1 again.  So
> >>>>>http://www.webmacro.org/WebMacroPropertiesFile is probably not
> >>>>> accurate.
> >>>>>
> >>>>>Now comes the weird one.  Before I found out about the #param settin=
gs
> >>>>>above, I tried to debug the actual String inside the WMServlet to fi=
nd
> >>>>>out whether or not I was getting the correct data from my db into my
> >>>>>servlet.  I wrote a little utility method that dumped out the String
> >>>>> as a series of (int) conversions and the char representations and in
> >>>>> order to test it I did this inside my handle method:-
> >>>>>
> >>>>>context.put("string", utf8string);
> >>>>>Template t =3D getTemplate("mytemplatename");
> >>>>>StringUtils.debugString(t.evaluateAsString(context))
> >>>>>return t;
> >>>>>
> >>>>>The good news was that the debugString funtionality confirmed that t=
he
> >>>>>utf8string did in fact have the correct (8217) character inside it.=
=20
> >>>>> The bizarre thing was that the rendered template in the browser was
> >>>>> also rendered as utf8 as well!
> >>>>>
> >>>>>So, then I just commented out the debug functionality giving me:-
> >>>>>
> >>>>>context.put("string", utf8string);
> >>>>>Template t =3D getTemplate("mytemplatename");
> >>>>>//StringUtils.debugString(t.evaluateAsString(context))
> >>>>>return t;
> >>>>>
> >>>>>and now the rendered template was coming back as 8859-1.
> >>>>>
> >>>>>so this implies that the order in which methods you use to evaluate a
> >>>>>template can change the character encoding of the output which to me
> >>>>>doesn't seem to be quite right.
> >>>>>
> >>>>>This is not an immediately pressing concern (because of the #param
> >>>>>method) but it would be nice to have a look at it in the future, so =
if
> >>>>>anyone has any thoughts as to why this might be happening (and wheth=
er
> >>>>>or not it is expected / correct behaviour) then that would be
> >>>>>appreciated before I start delving too deeply.
> >>>>>
> >>>>>Alex
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>--------------------------------------------------------------------=
=2D-
> >>>>>-- - Using Tomcat but need to do more? Need to support web services,
> >>>>> security? Get stuff done quickly with pre-integrated technology to
> >>>>> make your job easier Download IBM WebSphere Application Server
> >>>>> v.1.0.1 based on Apache Geronimo
> >>>>>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&=
dat=3D1216
> >>>>>42 _______________________________________________
> >>>>>Webmacro-devel mailing list
> >>>>>Web...@li...
> >>>>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >>>
> >>>----------------------------------------------------------------------=
=2D-
> >>>- Using Tomcat but need to do more? Need to support web services,
> >>> security? Get stuff done quickly with pre-integrated technology to ma=
ke
> >>> your job easier Download IBM WebSphere Application Server v.1.0.1 bas=
ed
> >>> on Apache Geronimo
> >>>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
> >>>_______________________________________________
> >>>Webmacro-devel mailing list
> >>>Web...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >-------------------------------------------------------------------------
> >Using Tomcat but need to do more? Need to support web services, security?
> >Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> >Webmacro-devel mailing list
> >Web...@li...
> >https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Interesting character encoding behaviour

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

the tests ... what you see is what you get :) and when you have the 
solution to global warming, please forward to calif where it has been 
awfully warm lately.

-Lane

Alex Fiennes wrote:

>On Tuesday 15 August 2006 20:06, Lane Sharman wrote:
>  
>
>>Hi Alex,
>>
>>Why don't you propose a solution that is consistent, undestandable and
>>that can be implemented for the benefit of all users?
>>    
>>
>
>I'll do this once I've finished sorting out the global warming problem... ;-)
>
>Seriously though - I'll try and put together some unit tests and some 
>documentation that accurately reflects the current CVS tree and then we can 
>decide what (if any) tweaks would make it more transparent.
>
>I think that most of the tools are all there, but there are a couple of quirks 
>in terms of which ones get used depending on the usage of the various usage 
>models for the framework.  So it may well just be a case of clear 
>documentation to reduce confusion.
>
>Before I get started, are there any other relevant unit tests other than:-
>./template/EncodingTestCase.java
>./template/TestISO88591Encoding.java
>./template/TestWindows1251Encoding.java
>
>Alex
>
>  
>
>>Lane
>>
>>Alex Fiennes wrote:
>>    
>>
>>>Keats (et al),
>>>
>>>On Monday 14 August 2006 18:29, Keats Kirsch wrote:
>>>      
>>>
>>>>This is all a very faint (and painful) memory, but I believe that when
>>>>running as a Servlet the output encoding from the request is preferred.
>>>>
>>>>Hope this helps.
>>>>        
>>>>
>>>I've been doing a little bit of digging around on this and it appears from
>>>a quick scan of the current CVS that doing anything from the $Response
>>>context tool in the templates is not going to work for the following
>>>reason:-
>>>
>>>WMServlet.java defines the execute method as follows (logging methods
>>>stripped out):-
>>>
>>>HttpServletResponse resp = c.getResponse();
>>>Locale locale = (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
>>>if (locale != null) {
>>> setLocale(resp, locale);
>>>}
>>>String encoding
>>> = (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>>>if (encoding == null) {
>>> encoding = resp.getCharacterEncoding();
>>>}
>>>byte[] bytes = tmpl.evaluateAsBytes(encoding, c);
>>>writeResponseBytes(resp, bytes, encoding);
>>>
>>>On first glance this *will* honour the character encoding of the response,
>>>but unfortunately if you are setting the character encoding via the
>>>context tool in terms of:-
>>>
>>>#set $Response.ContentType = "text/html;charset=utf-8"
>>>
>>>then this will not happen until the template is evaluated which is *after*
>>>the encoding has been derived from the template and therefore the
>>>template will always take the default encoding (from the javadoc "If no
>>>character encoding has been specified, ISO-8859-1 is returned").  So
>>>unless you use an explicit call to set up the template encoding using
>>>something like:-
>>>
>>>#param $TemplateOutputEncoding="utf-8"
>>>
>>>then the actual encoding of the template will always be done as 8859-1,
>>>although the HTTP headers (as defined by the response) may well say that
>>>it is *supposed* to be utf-8.
>>>
>>>I am not aware of anything other than the #param to enable a template to
>>>define information that is available to webmacro before it is executed. 
>>>If this is correct then the information on the
>>>http://www.webmacro.org/CharacterEncoding is probably actually incorrect
>>>as this will not set the encoding used to render the template when it is
>>>evaluated.
>>>
>>>The only change that I would suggest to the actual code is to make it so
>>>that if you do set the encoding with the #param call then it should
>>>automatically update the response character encoding to at least try and
>>>keep the webmacro encoding in sync with the response headers.  The other
>>>change would be to make it so that it is prepared to use the
>>>TemplateOutputEncoding in the WebMacro.properties file as well (which is
>>>currently only utilised in the writeTemplate methods and completely
>>>ignored for the default execute method). This would give us a code block
>>>of something like:-
>>>
>>>HttpServletResponse resp = c.getResponse();
>>>Locale locale = (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
>>>if (locale != null) {
>>> setLocale(resp, locale);
>>>}
>>>String encoding
>>> = (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>>>if (encoding == null) {
>>> encoding = getConfig(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>>>}
>>>if (encoding == null) {
>>> encoding = resp.getCharacterEncoding();
>>>} else {
>>> resp.setCharacterEncoding(encoding);
>>>}
>>>byte[] bytes = tmpl.evaluateAsBytes(encoding, c);
>>>writeResponseBytes(resp, bytes, encoding);
>>>
>>>You can of course still cause it to freak out by doing something just
>>>awkward like this:-
>>>
>>>#param $TemplateOutputEncoding = "utf-8"
>>>#set $Response.ContentType = "text/html;charset=iso-8859-1"
>>>
>>>which would cause it to render the template in utf-8 but tell the browser
>>>that it was in iso-8859-1, but that is kind of your own fault.  More
>>>importantly, a single call to:-
>>>
>>>#param $TemplateOutputEncoding = "utf-8"
>>>
>>>with no $Response tweaking should get the correct headers sent to the
>>>client...
>>>
>>>let me know if this makes any kind of sense to you guys.
>>>
>>>Alex
>>>
>>>      
>>>
>>>>Alex Fiennes wrote:
>>>>        
>>>>
>>>>>All,
>>>>>
>>>>>just been playing around with some character encoding bugs (oh how I
>>>>>love character encodings) and I found the following behaviours that
>>>>>didn't seem to be quite correct and I thought I'd drop them out to the
>>>>>list and see if other folk thought that they were actually bugs or not.
>>>>>
>>>>>I've got a web application running under tomcat5 on linux so the default
>>>>>platform encoding is iso-8859-1.
>>>>>
>>>>>I have a variable $string that contains some utf8 characters, namely
>>>>>8217 or "strange backwards apostrophe".
>>>>>
>>>>>I am overriding WMServlet, and if I just drop $string into the context
>>>>>and return a template that references $string then I get a "?" instead
>>>>>of a "’", which is because it is being flattened into ISO-8859-1 and
>>>>>this is a non-supported character.  All good and fine.
>>>>>
>>>>>After a bit of hacking around in the source code, I discovered that you
>>>>>can do:-
>>>>>
>>>>>#param $TemplateOutputEncoding = "utf-8"
>>>>>
>>>>>which now gives me the correct result. (It might be worth adding this to
>>>>>http://www.webmacro.org/CharacterEncoding for future reference)
>>>>>
>>>>>Interestingly enough, if I ommit the #param from my template, but
>>>>>instead define:-
>>>>>TemplateOutputEncoding=utf-8
>>>>>...in my WebMacro.properties file then it doesn't work and I'm back to
>>>>>the "?" so presumably it is 8859-1 again.  So
>>>>>http://www.webmacro.org/WebMacroPropertiesFile is probably not accurate.
>>>>>
>>>>>Now comes the weird one.  Before I found out about the #param settings
>>>>>above, I tried to debug the actual String inside the WMServlet to find
>>>>>out whether or not I was getting the correct data from my db into my
>>>>>servlet.  I wrote a little utility method that dumped out the String as
>>>>>a series of (int) conversions and the char representations and in order
>>>>>to test it I did this inside my handle method:-
>>>>>
>>>>>context.put("string", utf8string);
>>>>>Template t = getTemplate("mytemplatename");
>>>>>StringUtils.debugString(t.evaluateAsString(context))
>>>>>return t;
>>>>>
>>>>>The good news was that the debugString funtionality confirmed that the
>>>>>utf8string did in fact have the correct (8217) character inside it.  The
>>>>>bizarre thing was that the rendered template in the browser was also
>>>>>rendered as utf8 as well!
>>>>>
>>>>>So, then I just commented out the debug functionality giving me:-
>>>>>
>>>>>context.put("string", utf8string);
>>>>>Template t = getTemplate("mytemplatename");
>>>>>//StringUtils.debugString(t.evaluateAsString(context))
>>>>>return t;
>>>>>
>>>>>and now the rendered template was coming back as 8859-1.
>>>>>
>>>>>so this implies that the order in which methods you use to evaluate a
>>>>>template can change the character encoding of the output which to me
>>>>>doesn't seem to be quite right.
>>>>>
>>>>>This is not an immediately pressing concern (because of the #param
>>>>>method) but it would be nice to have a look at it in the future, so if
>>>>>anyone has any thoughts as to why this might be happening (and whether
>>>>>or not it is expected / correct behaviour) then that would be
>>>>>appreciated before I start delving too deeply.
>>>>>
>>>>>Alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>- Using Tomcat but need to do more? Need to support web services,
>>>>>security? Get stuff done quickly with pre-integrated technology to make
>>>>>your job easier Download IBM WebSphere Application Server v.1.0.1 based
>>>>>on Apache Geronimo
>>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>>_______________________________________________
>>>>>Webmacro-devel mailing list
>>>>>Web...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>>>          
>>>>>
>>>-------------------------------------------------------------------------
>>>Using Tomcat but need to do more? Need to support web services, security?
>>>Get stuff done quickly with pre-integrated technology to make your job
>>>easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>_______________________________________________
>>>Webmacro-devel mailing list
>>>Web...@li...
>>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>      
>>>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>  
>


-- 
Kindest Regards,

Lane Sharman
858-342-1415

Re: [Webmacro-devel] Interesting character encoding behaviour

[Alex F. <al...@fi...>]

On Tuesday 15 August 2006 20:06, Lane Sharman wrote:
> Hi Alex,
>
> Why don't you propose a solution that is consistent, undestandable and
> that can be implemented for the benefit of all users?

I'll do this once I've finished sorting out the global warming problem... ;=
=2D)

Seriously though - I'll try and put together some unit tests and some=20
documentation that accurately reflects the current CVS tree and then we can=
=20
decide what (if any) tweaks would make it more transparent.

I think that most of the tools are all there, but there are a couple of qui=
rks=20
in terms of which ones get used depending on the usage of the various usage=
=20
models for the framework.  So it may well just be a case of clear=20
documentation to reduce confusion.

Before I get started, are there any other relevant unit tests other than:-
=2E/template/EncodingTestCase.java
=2E/template/TestISO88591Encoding.java
=2E/template/TestWindows1251Encoding.java

Alex

> Lane
>
> Alex Fiennes wrote:
> >Keats (et al),
> >
> >On Monday 14 August 2006 18:29, Keats Kirsch wrote:
> >>This is all a very faint (and painful) memory, but I believe that when
> >>running as a Servlet the output encoding from the request is preferred.
> >>
> >>Hope this helps.
> >
> >I've been doing a little bit of digging around on this and it appears fr=
om
> > a quick scan of the current CVS that doing anything from the $Response
> > context tool in the templates is not going to work for the following
> > reason:-
> >
> >WMServlet.java defines the execute method as follows (logging methods
> > stripped out):-
> >
> >HttpServletResponse resp =3D c.getResponse();
> >Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
> >if (locale !=3D null) {
> >  setLocale(resp, locale);
> >}
> >String encoding
> >  =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >if (encoding =3D=3D null) {
> >  encoding =3D resp.getCharacterEncoding();
> >}
> >byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
> >writeResponseBytes(resp, bytes, encoding);
> >
> >On first glance this *will* honour the character encoding of the respons=
e,
> > but unfortunately if you are setting the character encoding via the
> > context tool in terms of:-
> >
> >#set $Response.ContentType =3D "text/html;charset=3Dutf-8"
> >
> >then this will not happen until the template is evaluated which is *afte=
r*
> > the encoding has been derived from the template and therefore the
> > template will always take the default encoding (from the javadoc "If no
> > character encoding has been specified, ISO-8859-1 is returned").  So
> > unless you use an explicit call to set up the template encoding using
> > something like:-
> >
> >#param $TemplateOutputEncoding=3D"utf-8"
> >
> >then the actual encoding of the template will always be done as 8859-1,
> >although the HTTP headers (as defined by the response) may well say that
> > it is *supposed* to be utf-8.
> >
> >I am not aware of anything other than the #param to enable a template to
> >define information that is available to webmacro before it is executed.=
=20
> > If this is correct then the information on the
> >http://www.webmacro.org/CharacterEncoding is probably actually incorrect
> > as this will not set the encoding used to render the template when it is
> > evaluated.
> >
> >The only change that I would suggest to the actual code is to make it so
> > that if you do set the encoding with the #param call then it should
> > automatically update the response character encoding to at least try and
> > keep the webmacro encoding in sync with the response headers.  The other
> > change would be to make it so that it is prepared to use the
> > TemplateOutputEncoding in the WebMacro.properties file as well (which is
> > currently only utilised in the writeTemplate methods and completely
> > ignored for the default execute method). This would give us a code block
> > of something like:-
> >
> >HttpServletResponse resp =3D c.getResponse();
> >Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
> >if (locale !=3D null) {
> >  setLocale(resp, locale);
> >}
> >String encoding
> >  =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >if (encoding =3D=3D null) {
> >  encoding =3D getConfig(WMConstants.TEMPLATE_OUTPUT_ENCODING);
> >}
> >if (encoding =3D=3D null) {
> >  encoding =3D resp.getCharacterEncoding();
> >} else {
> >  resp.setCharacterEncoding(encoding);
> >}
> >byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
> >writeResponseBytes(resp, bytes, encoding);
> >
> >You can of course still cause it to freak out by doing something just
> > awkward like this:-
> >
> >#param $TemplateOutputEncoding =3D "utf-8"
> >#set $Response.ContentType =3D "text/html;charset=3Diso-8859-1"
> >
> >which would cause it to render the template in utf-8 but tell the browser
> > that it was in iso-8859-1, but that is kind of your own fault.  More
> > importantly, a single call to:-
> >
> >#param $TemplateOutputEncoding =3D "utf-8"
> >
> >with no $Response tweaking should get the correct headers sent to the
> >client...
> >
> >let me know if this makes any kind of sense to you guys.
> >
> >Alex
> >
> >>Alex Fiennes wrote:
> >>>All,
> >>>
> >>>just been playing around with some character encoding bugs (oh how I
> >>> love character encodings) and I found the following behaviours that
> >>> didn't seem to be quite correct and I thought I'd drop them out to the
> >>> list and see if other folk thought that they were actually bugs or no=
t.
> >>>
> >>>I've got a web application running under tomcat5 on linux so the defau=
lt
> >>>platform encoding is iso-8859-1.
> >>>
> >>>I have a variable $string that contains some utf8 characters, namely
> >>> 8217 or "strange backwards apostrophe".
> >>>
> >>>I am overriding WMServlet, and if I just drop $string into the context
> >>>and return a template that references $string then I get a "?" instead
> >>> of a "=E2=80=99", which is because it is being flattened into ISO-885=
9-1 and
> >>> this is a non-supported character.  All good and fine.
> >>>
> >>>After a bit of hacking around in the source code, I discovered that you
> >>>can do:-
> >>>
> >>>#param $TemplateOutputEncoding =3D "utf-8"
> >>>
> >>>which now gives me the correct result. (It might be worth adding this =
to
> >>>http://www.webmacro.org/CharacterEncoding for future reference)
> >>>
> >>>Interestingly enough, if I ommit the #param from my template, but
> >>> instead define:-
> >>>TemplateOutputEncoding=3Dutf-8
> >>>...in my WebMacro.properties file then it doesn't work and I'm back to
> >>>the "?" so presumably it is 8859-1 again.  So
> >>>http://www.webmacro.org/WebMacroPropertiesFile is probably not accurat=
e.
> >>>
> >>>Now comes the weird one.  Before I found out about the #param settings
> >>>above, I tried to debug the actual String inside the WMServlet to find
> >>>out whether or not I was getting the correct data from my db into my
> >>>servlet.  I wrote a little utility method that dumped out the String as
> >>> a series of (int) conversions and the char representations and in ord=
er
> >>> to test it I did this inside my handle method:-
> >>>
> >>>context.put("string", utf8string);
> >>>Template t =3D getTemplate("mytemplatename");
> >>>StringUtils.debugString(t.evaluateAsString(context))
> >>>return t;
> >>>
> >>>The good news was that the debugString funtionality confirmed that the
> >>>utf8string did in fact have the correct (8217) character inside it.  T=
he
> >>>bizarre thing was that the rendered template in the browser was also
> >>>rendered as utf8 as well!
> >>>
> >>>So, then I just commented out the debug functionality giving me:-
> >>>
> >>>context.put("string", utf8string);
> >>>Template t =3D getTemplate("mytemplatename");
> >>>//StringUtils.debugString(t.evaluateAsString(context))
> >>>return t;
> >>>
> >>>and now the rendered template was coming back as 8859-1.
> >>>
> >>>so this implies that the order in which methods you use to evaluate a
> >>>template can change the character encoding of the output which to me
> >>>doesn't seem to be quite right.
> >>>
> >>>This is not an immediately pressing concern (because of the #param
> >>>method) but it would be nice to have a look at it in the future, so if
> >>>anyone has any thoughts as to why this might be happening (and whether
> >>> or not it is expected / correct behaviour) then that would be
> >>> appreciated before I start delving too deeply.
> >>>
> >>>Alex
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>----------------------------------------------------------------------=
=2D-
> >>>- Using Tomcat but need to do more? Need to support web services,
> >>> security? Get stuff done quickly with pre-integrated technology to ma=
ke
> >>> your job easier Download IBM WebSphere Application Server v.1.0.1 bas=
ed
> >>> on Apache Geronimo
> >>>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da=
t=3D121642
> >>>_______________________________________________
> >>>Webmacro-devel mailing list
> >>>Web...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >-------------------------------------------------------------------------
> >Using Tomcat but need to do more? Need to support web services, security?
> >Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> >Webmacro-devel mailing list
> >Web...@li...
> >https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Interesting character encoding behaviour

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

Hi Alex,

Why don't you propose a solution that is consistent, undestandable and 
that can be implemented for the benefit of all users?

Lane

Alex Fiennes wrote:

>Keats (et al),
>
>On Monday 14 August 2006 18:29, Keats Kirsch wrote:
>  
>
>>This is all a very faint (and painful) memory, but I believe that when
>>running as a Servlet the output encoding from the request is preferred.
>>
>>Hope this helps.
>>    
>>
>
>I've been doing a little bit of digging around on this and it appears from a 
>quick scan of the current CVS that doing anything from the $Response context 
>tool in the templates is not going to work for the following reason:-
>
>WMServlet.java defines the execute method as follows (logging methods stripped 
>out):-
>
>HttpServletResponse resp = c.getResponse();
>Locale locale = (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
>if (locale != null) {
>  setLocale(resp, locale);
>}
>String encoding 
>  = (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>if (encoding == null) {
>  encoding = resp.getCharacterEncoding();
>}
>byte[] bytes = tmpl.evaluateAsBytes(encoding, c);
>writeResponseBytes(resp, bytes, encoding);
>
>On first glance this *will* honour the character encoding of the response, but 
>unfortunately if you are setting the character encoding via the context tool 
>in terms of:-
>
>#set $Response.ContentType = "text/html;charset=utf-8"
>
>then this will not happen until the template is evaluated which is *after* the 
>encoding has been derived from the template and therefore the template will 
>always take the default encoding (from the javadoc "If no character encoding 
>has been specified, ISO-8859-1 is returned").  So unless you use an explicit 
>call to set up the template encoding using something like:-
>
>#param $TemplateOutputEncoding="utf-8"
>
>then the actual encoding of the template will always be done as 8859-1, 
>although the HTTP headers (as defined by the response) may well say that it 
>is *supposed* to be utf-8.
>
>I am not aware of anything other than the #param to enable a template to 
>define information that is available to webmacro before it is executed.  If 
>this is correct then the information on the 
>http://www.webmacro.org/CharacterEncoding is probably actually incorrect as 
>this will not set the encoding used to render the template when it is 
>evaluated.
>
>The only change that I would suggest to the actual code is to make it so that 
>if you do set the encoding with the #param call then it should automatically 
>update the response character encoding to at least try and keep the webmacro 
>encoding in sync with the response headers.  The other change would be to 
>make it so that it is prepared to use the TemplateOutputEncoding in the 
>WebMacro.properties file as well (which is currently only utilised in the 
>writeTemplate methods and completely ignored for the default execute method).  
>This would give us a code block of something like:-
>
>HttpServletResponse resp = c.getResponse();
>Locale locale = (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
>if (locale != null) {
>  setLocale(resp, locale);
>}
>String encoding 
>  = (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>if (encoding == null) {
>  encoding = getConfig(WMConstants.TEMPLATE_OUTPUT_ENCODING);
>}
>if (encoding == null) {
>  encoding = resp.getCharacterEncoding();
>} else {
>  resp.setCharacterEncoding(encoding);
>}
>byte[] bytes = tmpl.evaluateAsBytes(encoding, c);
>writeResponseBytes(resp, bytes, encoding);
>
>You can of course still cause it to freak out by doing something just awkward 
>like this:-
>
>#param $TemplateOutputEncoding = "utf-8"
>#set $Response.ContentType = "text/html;charset=iso-8859-1"
>
>which would cause it to render the template in utf-8 but tell the browser that 
>it was in iso-8859-1, but that is kind of your own fault.  More importantly, 
>a single call to:-
>
>#param $TemplateOutputEncoding = "utf-8"
>
>with no $Response tweaking should get the correct headers sent to the 
>client...
>
>let me know if this makes any kind of sense to you guys.
>
>Alex
>
>  
>
>>Alex Fiennes wrote:
>>    
>>
>>>All,
>>>
>>>just been playing around with some character encoding bugs (oh how I love
>>>character encodings) and I found the following behaviours that didn't
>>>seem to be quite correct and I thought I'd drop them out to the list and
>>>see if other folk thought that they were actually bugs or not.
>>>
>>>I've got a web application running under tomcat5 on linux so the default
>>>platform encoding is iso-8859-1.
>>>
>>>I have a variable $string that contains some utf8 characters, namely 8217
>>>or "strange backwards apostrophe".
>>>
>>>I am overriding WMServlet, and if I just drop $string into the context
>>>and return a template that references $string then I get a "?" instead of
>>>a "’", which is because it is being flattened into ISO-8859-1 and this is
>>>a non-supported character.  All good and fine.
>>>
>>>After a bit of hacking around in the source code, I discovered that you
>>>can do:-
>>>
>>>#param $TemplateOutputEncoding = "utf-8"
>>>
>>>which now gives me the correct result. (It might be worth adding this to
>>>http://www.webmacro.org/CharacterEncoding for future reference)
>>>
>>>Interestingly enough, if I ommit the #param from my template, but instead
>>>define:-
>>>TemplateOutputEncoding=utf-8
>>>...in my WebMacro.properties file then it doesn't work and I'm back to
>>>the "?" so presumably it is 8859-1 again.  So
>>>http://www.webmacro.org/WebMacroPropertiesFile is probably not accurate.
>>>
>>>Now comes the weird one.  Before I found out about the #param settings
>>>above, I tried to debug the actual String inside the WMServlet to find
>>>out whether or not I was getting the correct data from my db into my
>>>servlet.  I wrote a little utility method that dumped out the String as a
>>>series of (int) conversions and the char representations and in order to
>>>test it I did this inside my handle method:-
>>>
>>>context.put("string", utf8string);
>>>Template t = getTemplate("mytemplatename");
>>>StringUtils.debugString(t.evaluateAsString(context))
>>>return t;
>>>
>>>The good news was that the debugString funtionality confirmed that the
>>>utf8string did in fact have the correct (8217) character inside it.  The
>>>bizarre thing was that the rendered template in the browser was also
>>>rendered as utf8 as well!
>>>
>>>So, then I just commented out the debug functionality giving me:-
>>>
>>>context.put("string", utf8string);
>>>Template t = getTemplate("mytemplatename");
>>>//StringUtils.debugString(t.evaluateAsString(context))
>>>return t;
>>>
>>>and now the rendered template was coming back as 8859-1.
>>>
>>>so this implies that the order in which methods you use to evaluate a
>>>template can change the character encoding of the output which to me
>>>doesn't seem to be quite right.
>>>
>>>This is not an immediately pressing concern (because of the #param
>>>method) but it would be nice to have a look at it in the future, so if
>>>anyone has any thoughts as to why this might be happening (and whether or
>>>not it is expected / correct behaviour) then that would be appreciated
>>>before I start delving too deeply.
>>>
>>>Alex
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------------------------
>>>Using Tomcat but need to do more? Need to support web services, security?
>>>Get stuff done quickly with pre-integrated technology to make your job
>>>easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>_______________________________________________
>>>Webmacro-devel mailing list
>>>Web...@li...
>>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>      
>>>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>  
>


-- 
Kindest Regards,

Lane Sharman
858-342-1415

Re: [Webmacro-devel] Interesting character encoding behaviour

[Alex F. <al...@fi...>]

Keats (et al),

On Monday 14 August 2006 18:29, Keats Kirsch wrote:
> This is all a very faint (and painful) memory, but I believe that when
> running as a Servlet the output encoding from the request is preferred.
>
> Hope this helps.

I've been doing a little bit of digging around on this and it appears from =
a=20
quick scan of the current CVS that doing anything from the $Response contex=
t=20
tool in the templates is not going to work for the following reason:-

WMServlet.java defines the execute method as follows (logging methods strip=
ped=20
out):-

HttpServletResponse resp =3D c.getResponse();
Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
if (locale !=3D null) {
  setLocale(resp, locale);
}
String encoding=20
  =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
if (encoding =3D=3D null) {
  encoding =3D resp.getCharacterEncoding();
}
byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
writeResponseBytes(resp, bytes, encoding);

On first glance this *will* honour the character encoding of the response, =
but=20
unfortunately if you are setting the character encoding via the context too=
l=20
in terms of:-

#set $Response.ContentType =3D "text/html;charset=3Dutf-8"

then this will not happen until the template is evaluated which is *after* =
the=20
encoding has been derived from the template and therefore the template will=
=20
always take the default encoding (from the javadoc "If no character encodin=
g=20
has been specified, ISO-8859-1 is returned").  So unless you use an explici=
t=20
call to set up the template encoding using something like:-

#param $TemplateOutputEncoding=3D"utf-8"

then the actual encoding of the template will always be done as 8859-1,=20
although the HTTP headers (as defined by the response) may well say that it=
=20
is *supposed* to be utf-8.

I am not aware of anything other than the #param to enable a template to=20
define information that is available to webmacro before it is executed.  If=
=20
this is correct then the information on the=20
http://www.webmacro.org/CharacterEncoding is probably actually incorrect as=
=20
this will not set the encoding used to render the template when it is=20
evaluated.

The only change that I would suggest to the actual code is to make it so th=
at=20
if you do set the encoding with the #param call then it should automaticall=
y=20
update the response character encoding to at least try and keep the webmacr=
o=20
encoding in sync with the response headers.  The other change would be to=20
make it so that it is prepared to use the TemplateOutputEncoding in the=20
WebMacro.properties file as well (which is currently only utilised in the=20
writeTemplate methods and completely ignored for the default execute method=
). =20
This would give us a code block of something like:-

HttpServletResponse resp =3D c.getResponse();
Locale locale =3D (Locale) tmpl.getParam(WMConstants.TEMPLATE_LOCALE);
if (locale !=3D null) {
  setLocale(resp, locale);
}
String encoding=20
  =3D (String) tmpl.getParam(WMConstants.TEMPLATE_OUTPUT_ENCODING);
if (encoding =3D=3D null) {
  encoding =3D getConfig(WMConstants.TEMPLATE_OUTPUT_ENCODING);
}
if (encoding =3D=3D null) {
  encoding =3D resp.getCharacterEncoding();
} else {
  resp.setCharacterEncoding(encoding);
}
byte[] bytes =3D tmpl.evaluateAsBytes(encoding, c);
writeResponseBytes(resp, bytes, encoding);

You can of course still cause it to freak out by doing something just awkwa=
rd=20
like this:-

#param $TemplateOutputEncoding =3D "utf-8"
#set $Response.ContentType =3D "text/html;charset=3Diso-8859-1"

which would cause it to render the template in utf-8 but tell the browser t=
hat=20
it was in iso-8859-1, but that is kind of your own fault.  More importantly=
,=20
a single call to:-

#param $TemplateOutputEncoding =3D "utf-8"

with no $Response tweaking should get the correct headers sent to the=20
client...

let me know if this makes any kind of sense to you guys.

Alex

> Alex Fiennes wrote:
> > All,
> >
> > just been playing around with some character encoding bugs (oh how I lo=
ve
> > character encodings) and I found the following behaviours that didn't
> > seem to be quite correct and I thought I'd drop them out to the list and
> > see if other folk thought that they were actually bugs or not.
> >
> > I've got a web application running under tomcat5 on linux so the default
> > platform encoding is iso-8859-1.
> >
> > I have a variable $string that contains some utf8 characters, namely 82=
17
> > or "strange backwards apostrophe".
> >
> > I am overriding WMServlet, and if I just drop $string into the context
> > and return a template that references $string then I get a "?" instead =
of
> > a "=E2=80=99", which is because it is being flattened into ISO-8859-1 a=
nd this is
> > a non-supported character.  All good and fine.
> >
> > After a bit of hacking around in the source code, I discovered that you
> > can do:-
> >
> > #param $TemplateOutputEncoding =3D "utf-8"
> >
> > which now gives me the correct result. (It might be worth adding this to
> > http://www.webmacro.org/CharacterEncoding for future reference)
> >
> > Interestingly enough, if I ommit the #param from my template, but inste=
ad
> > define:-
> > TemplateOutputEncoding=3Dutf-8
> > ...in my WebMacro.properties file then it doesn't work and I'm back to
> > the "?" so presumably it is 8859-1 again.  So
> > http://www.webmacro.org/WebMacroPropertiesFile is probably not accurate.
> >
> > Now comes the weird one.  Before I found out about the #param settings
> > above, I tried to debug the actual String inside the WMServlet to find
> > out whether or not I was getting the correct data from my db into my
> > servlet.  I wrote a little utility method that dumped out the String as=
 a
> > series of (int) conversions and the char representations and in order to
> > test it I did this inside my handle method:-
> >
> > context.put("string", utf8string);
> > Template t =3D getTemplate("mytemplatename");
> > StringUtils.debugString(t.evaluateAsString(context))
> > return t;
> >
> > The good news was that the debugString funtionality confirmed that the
> > utf8string did in fact have the correct (8217) character inside it.  The
> > bizarre thing was that the rendered template in the browser was also
> > rendered as utf8 as well!
> >
> > So, then I just commented out the debug functionality giving me:-
> >
> > context.put("string", utf8string);
> > Template t =3D getTemplate("mytemplatename");
> > //StringUtils.debugString(t.evaluateAsString(context))
> > return t;
> >
> > and now the rendered template was coming back as 8859-1.
> >
> > so this implies that the order in which methods you use to evaluate a
> > template can change the character encoding of the output which to me
> > doesn't seem to be quite right.
> >
> > This is not an immediately pressing concern (because of the #param
> > method) but it would be nice to have a look at it in the future, so if
> > anyone has any thoughts as to why this might be happening (and whether =
or
> > not it is expected / correct behaviour) then that would be appreciated
> > before I start delving too deeply.
> >
> > Alex
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------------=
=2D-
> > Using Tomcat but need to do more? Need to support web services, securit=
y?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] Interesting character encoding behaviour

[Alex F. <al...@fi...>]

All,

just been playing around with some character encoding bugs (oh how I love=20
character encodings) and I found the following behaviours that didn't seem =
to=20
be quite correct and I thought I'd drop them out to the list and see if oth=
er=20
folk thought that they were actually bugs or not.

I've got a web application running under tomcat5 on linux so the default=20
platform encoding is iso-8859-1.

I have a variable $string that contains some utf8 characters, namely 8217=20
or "strange backwards apostrophe".

I am overriding WMServlet, and if I just drop $string into the context and=
=20
return a template that references $string then I get a "?" instead of a "=
=E2=80=99",=20
which is because it is being flattened into ISO-8859-1 and this is a=20
non-supported character.  All good and fine.

After a bit of hacking around in the source code, I discovered that you can=
=20
do:-

#param $TemplateOutputEncoding =3D "utf-8"

which now gives me the correct result. (It might be worth adding this to=20
http://www.webmacro.org/CharacterEncoding for future reference)

Interestingly enough, if I ommit the #param from my template, but instead=20
define:-
TemplateOutputEncoding=3Dutf-8
=2E..in my WebMacro.properties file then it doesn't work and I'm back to th=
e "?"=20
so presumably it is 8859-1 again.  So=20
http://www.webmacro.org/WebMacroPropertiesFile is probably not accurate.

Now comes the weird one.  Before I found out about the #param settings abov=
e,=20
I tried to debug the actual String inside the WMServlet to find out whether=
=20
or not I was getting the correct data from my db into my servlet.  I wrote =
a=20
little utility method that dumped out the String as a series of (int)=20
conversions and the char representations and in order to test it I did this=
=20
inside my handle method:-

context.put("string", utf8string);
Template t =3D getTemplate("mytemplatename");
StringUtils.debugString(t.evaluateAsString(context))
return t;

The good news was that the debugString funtionality confirmed that the=20
utf8string did in fact have the correct (8217) character inside it.  The=20
bizarre thing was that the rendered template in the browser was also render=
ed=20
as utf8 as well!

So, then I just commented out the debug functionality giving me:-

context.put("string", utf8string);
Template t =3D getTemplate("mytemplatename");
//StringUtils.debugString(t.evaluateAsString(context))
return t;

and now the rendered template was coming back as 8859-1.

so this implies that the order in which methods you use to evaluate a templ=
ate=20
can change the character encoding of the output which to me doesn't seem to=
=20
be quite right.

This is not an immediately pressing concern (because of the #param method) =
but=20
it would be nice to have a look at it in the future, so if anyone has any=20
thoughts as to why this might be happening (and whether or not it is=20
expected / correct behaviour) then that would be appreciated before I start=
=20
delving too deeply.

Alex

Re: [Webmacro-devel] CVS access broken?

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

Interesting.  Seems SourceForge has changed things a little bit.   
According to http://sourceforge.net/cvs/?group_id=64597, the new  
CVSROOT should be:

	ano...@we...:/cvsroot/webmacro

I'll update Wiki now.

eric

On Aug 14, 2006, at 11:20 AM, Alex Fiennes wrote:

> All,
>
> Returning back from the dead after a bit of a nasty HDD crash and  
> trying to
> rebuild my webmacro tree I find that trying to follow the  
> instructions on
> http://www.webmacro.org/CVSAccess for gaining anonymous CVS access  
> to the
> webmacro tree is giving me a:-
>
> alex@burroughs:~/cvsroot> cvs login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/ 
> webmacro
> CVS password:
> cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207): 
> 2401
> failed: No route to host
>
> Does anyone know if this is a problem at my end or is it a sourceforge
> problem?  I can ping cvs.sourceforge.net so it is definitely there...
>
> Alex
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] CVS access broken?

[Alex F. <al...@fi...>]

All,

Returning back from the dead after a bit of a nasty HDD crash and trying to 
rebuild my webmacro tree I find that trying to follow the instructions on 
http://www.webmacro.org/CVSAccess for gaining anonymous CVS access to the 
webmacro tree is giving me a:-

alex@burroughs:~/cvsroot> cvs login
Logging in to :pserver:ano...@cv...:2401/cvsroot/webmacro
CVS password:
cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 
failed: No route to host

Does anyone know if this is a problem at my end or is it a sourceforge 
problem?  I can ping cvs.sourceforge.net so it is definitely there...

Alex

Re: [Webmacro-devel] Re: Call for Vote: WebMacro License Change

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

Brian, do you have 15 minutes to review this proposed license and  
give your vote/input?  It would be great if you sign off on it too.   
I think you're the last core member.  Once you do, we can move  
forward with the real work.

hugs-n-kisses,

eric

On Apr 19, 2006, at 4:53 PM, Eric B. Ridge wrote:

> http://www.webmacro.org/PossibleNewLicense
>
> "Sign it" if you want it.
>
> eric
>
> On Apr 19, 2006, at 4:47 PM, Justin Wells wrote:
>
>> * Copyright (c) 1996, 2006, Semiotek Inc.
>> * All rights reserved.
>> * Redistribution and use in source and binary forms, with or without
>> * modification, are permitted provided that the following  
>> conditions are met:
>> *
>> *     * Redistributions of source code must retain the above  
>> copyright
>> *       notice, this list of conditions and the following disclaimer.
>> *
>> *     * Redistributions in binary form must reproduce the above  
>> copyright
>> *       notice, this list of conditions and the following  
>> disclaimer in the
>> *       documentation and/or other materials provided with the  
>> distribution.
>> *
>> *     * Neither the name WebMacro, nor the name Semiotek Inc., nor  
>> the names
>> *       of any of the contributors may be used to endorse or  
>> promote products
>> *       derived from this software without specific prior written  
>> permission.
>> *
>> * THIS SOFTWARE IS PROVIDED BY SEMIOTEK INC., WEBMACRO.ORG, THE  
>> WEBMACRO
>> * DEVELOPMENT TEAM, AND OTHER CONTRIBUTORS AND COPYRIGHT OWNERS  
>> ``AS IS''
>> * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT  
>> LIMITED TO, THE
>> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A  
>> PARTICULAR PURPOSE
>> * ARE DISCLAIMED. IN NO EVENT SHALL SEMIOTEK INC., WEBMACRO.ORG,  
>> THE WEBMACRO
>> * DEVELOPMENT TEAM, OR ANY OTHER CONTRIBUTOR OR COPYRIGHT HOLDER  
>> BE LIABLE FOR
>> * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
>> CONSEQUENTIAL DAMAGES
>> * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS  
>> OR SERVICES;
>> * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER  
>> CAUSED AND
>> * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT  
>> LIABILITY, OR TORT
>> * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
>> THE USE OF
>> * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Current directory metaphor for including templates

[Keats K. <ke...@xa...>]

I'd like to understand the requirements or use cases for this, but I'll 
give some preliminary thoughts.

I believe the DelegatingTemplateProvider allows you to define your own 
template loading protocols, so that might be a place to start.

But I think the simplest thing would be to add a ContextTool, like 
CurrentDirectoryTool, which you could use like:

  #include "$CurrentDirectory/sometemplate.wmt"

Keats

Tim Pizey wrote:

>Hi, 
>
>I know I have raised this before, but I am afraid I have lost my 
>mail archives, so sorry if you remember the last time I asked.
>
>Would it be useful/sensible to introduce, at this late stage, a 
>notion of 'current directory' for template inclusion?
>
>Looking at the code it would seem that Context.java could have something like 
>
>    public final String getCurrentNode ()
>    {
>      if (_teContext._templateName != null) {
>        int lastSlash = _teContext._templateName.lastIndexOf('/');
>        if (lastSlash > 0) {
>          StringBuffer node = new StringBuffer();
>          node.append( _teContext._templateName.substring(0, lastSlash + 1));
>          return node.toString();
>        }
>        return null; 
>      } else {
>        return null; 
>      }
>    }
>
>
>Then IncludeDirective.build could have 
>
>            if (_strFilename.indexOf('/') == -1) 
>              _strFilename = bc.getCurrentNode() + _strFilename;
>
>I can see one backward compatibility problem with error.wm 
>which is genuinely expected to be at the top level. 
>
>Does this make any sense?
>
>Tim
>
>  
>

Re: [Webmacro-devel] Current directory metaphor for including templates

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Mon 24 April 2006 22:49, Tim Pizey wrote:
> Hi,
>
> I know I have raised this before, but I am afraid I have lost my
> mail archives, so sorry if you remember the last time I asked.
>
> Would it be useful/sensible to introduce, at this late stage, a
> notion of 'current directory' for template inclusion?

This is fine if your current template delivery method is using a namespace 
where the concept of a current directory makes sense, but this is not 
necessarily the case.

I've got some Provider implementations that enable me to use template names 
such as:-

#include as template "evaluate:$abc"

which can then be passed into a function that expects to include a template 
and therefore can dynamically create virtual templates which "look" like 
normal templates.  In this case, the idea of a virtual hierarchy would make 
no sense at all, for example:-

#include as template "evaluate:#include as template \"def.wm\""

To avoid this you would need some kind of way of saying "this is a relative 
template space" which could then be trapped by the DelegatingTemplateProvider 
and processed accordingly.  For example:-

#include as template "./abc.wm"

Then I would reckon that the appropriate place to resolve this would be on the 
definition of the TemplateLoader method which currently provides:-

Template load(String query, CacheElement ce)

with an additional method of:-

Template load(Template invokingTemplate, String query, CacheElement ce)

and then it would be the responsibility of the TemplateLoader implementation 
to do something sensible with the request using the knowledge of where it is 
actually getting the Template from to resolve the relative request.

Then you just need to make a RelativeTemplateLoader that trapped any template 
path starting with "." and passed it to the TemplateLoader that was 
responsible for the invoking Template.  

(Of course we would then have to define how the RelativeTemplateLoader knew 
which Template it was getting invoked *from* and which TemplateLoader was 
responsible for it, but that is left as an exercise for the reader...)

Alex

> Looking at the code it would seem that Context.java could have something
> like
>
>     public final String getCurrentNode ()
>     {
>       if (_teContext._templateName != null) {
>         int lastSlash = _teContext._templateName.lastIndexOf('/');
>         if (lastSlash > 0) {
>           StringBuffer node = new StringBuffer();
>           node.append( _teContext._templateName.substring(0, lastSlash +
> 1)); return node.toString();
>         }
>         return null;
>       } else {
>         return null;
>       }
>     }
>
>
> Then IncludeDirective.build could have
>
>             if (_strFilename.indexOf('/') == -1)
>               _strFilename = bc.getCurrentNode() + _strFilename;
>
> I can see one backward compatibility problem with error.wm
> which is genuinely expected to be at the top level.
>
> Does this make any sense?
>
> Tim
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Current directory metaphor for including templates

[<Web...@St...>]

On Mon, 24 Apr 2006, Tim Pizey wrote:

| 
| Does this make any sense?

The instant gut feeling is that this isn't desireable - it introduces 
"even more magic" to the template-finding logic, which already is rather 
convoluted using lots of unknown rules based on whether you construct a 
Servlet 2.0, 2.2 or file-based, properties-based, whatever-based Broker..

However, I do think I see the reason for it. But I think that at the 
current point, things should be cleared up, rather than more magic 
included.
  If the entire Broker stuff could be refactored heavily, then the 
suggested feature could become a logical "plugin" that one added during 
the instantiation of the WM-instance, maybe an interface "TemplateLoader" 
that could look up into the context, get the current name from there, and 
then do your stuff.

But this refactoring is probably a long way away - so feel free to ignore 
these whines! And really, the requested feature seems kinda logical at any 
rate: if the template requested starts with "/", then it should be 
absolute according to the current TemplateLoader (ref. ClassLoader) (or 
chain!), while if it didn't, it should be relative to the current 
"execution context" (but then what about included files, and worse, 
macros, templets and what-are-they-calleds?).

Regards,
Endre.

[Webmacro-devel] Current directory metaphor for including templates

[Tim P. <ti...@pa...>]

Hi, 

I know I have raised this before, but I am afraid I have lost my 
mail archives, so sorry if you remember the last time I asked.

Would it be useful/sensible to introduce, at this late stage, a 
notion of 'current directory' for template inclusion?

Looking at the code it would seem that Context.java could have something like 

    public final String getCurrentNode ()
    {
      if (_teContext._templateName != null) {
        int lastSlash = _teContext._templateName.lastIndexOf('/');
        if (lastSlash > 0) {
          StringBuffer node = new StringBuffer();
          node.append( _teContext._templateName.substring(0, lastSlash + 1));
          return node.toString();
        }
        return null; 
      } else {
        return null; 
      }
    }


Then IncludeDirective.build could have 

            if (_strFilename.indexOf('/') == -1) 
              _strFilename = bc.getCurrentNode() + _strFilename;

I can see one backward compatibility problem with error.wm 
which is genuinely expected to be at the top level. 

Does this make any sense?

Tim

Re: [Webmacro-devel] License, Maven

[Tim P. <ti...@pa...>]

On Saturday 22 April 2006 15:57, Lane Sharman wrote:
> I have signed the new license and like it a lot.
>
> re maven: I would like to see a transform operation on the existing
> ditribution so that the existing distribution can be preserved. the
> transform operation would make a copy (much as a copy is made prior to
> compilation). The copy would create maven1/ and maven2/ which would
> allow you to work in a maven1/ and maven2/ build environment if that was
> your gig.
>
> in other words, I do not want to see an either/or. Rather, maven1/ and
> maven2/ depend on using the existing distribution model which works for
> a lot of people. I have to do the distribution to sf so I do not want to
> have to learn a whole new deal to do the distros. There could be 2 tasks
> in build.xml: "copyMaven1" and "copyMaven2" which would set up the new
> structure.
>
> I like the idea of maven as that if you start to manage a lot of
> projects, it does make sense to have  a common distribution model. From
> an SCM standpoint, absolutely concur with the objective of Maven. But as
> a development team, we are pretty comfy with using the current model.
>
> What do you think?

Spot on.
We add the maven files (project.xml and project.properties for maven1 and 
pom.xml for maven2)  and also the checkstyle config files and the job is done.

I have pretty much finished project.xml, I can point to the correct location 
of the new license (I prefer to see these files in the root but can work with 
current location).

I have done an initial checkstyle configuration.

The POM may be a bit more difficult to shoehorn our current structure into, 
but probably not. 

I was wondering if it would be good to publish the jars as 
WebMacro-version-m1.jar and WebMacro-version-m2.jar, not quite sure if this 
would buy us anything. 

There is a Maven Sourceforge plugin, which deals with SF, but I have yet to 
investigate it. 

The above setup would enable the current procedure to remain completely 
unchanged and enable us to publish in Maven form simply by 
maven deploy (for m1) and 
mvn deploy for m2. 

I would like to commit what I have done and play with deploying to 
http://melati.org/maven
I have yet to setup a m2 repository, but when I have done that and 
ironed out the wrinkles we should be fit to go. 

I would also like to version the jars in lib in accordance with 
http://www.paneris.org/~timp/webmacro/dependencies.html

cheers
TimP

[Webmacro-devel] License, Maven

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

I have signed the new license and like it a lot.

re maven: I would like to see a transform operation on the existing 
ditribution so that the existing distribution can be preserved. the 
transform operation would make a copy (much as a copy is made prior to 
compilation). The copy would create maven1/ and maven2/ which would 
allow you to work in a maven1/ and maven2/ build environment if that was 
your gig.

in other words, I do not want to see an either/or. Rather, maven1/ and 
maven2/ depend on using the existing distribution model which works for 
a lot of people. I have to do the distribution to sf so I do not want to 
have to learn a whole new deal to do the distros. There could be 2 tasks 
in build.xml: "copyMaven1" and "copyMaven2" which would set up the new 
structure.

I like the idea of maven as that if you start to manage a lot of 
projects, it does make sense to have  a common distribution model. From 
an SCM standpoint, absolutely concur with the objective of Maven. But as 
a development team, we are pretty comfy with using the current model.

What do you think?

-- 
Kindest Regards,

Lane

[Webmacro-devel] Re: Call for Vote: WebMacro License Change

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

> I think we should change the WebMacro License to:
>
>    [X] BSD w/o "advertising clause" (http://en.wikipedia.org/wiki/ 
> BSD_license)
>    [ ] Apache v2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt)
>    [ ] GPL + Apache v2.0
>    [ ] No change

What no proportional representation, single non-transferrable vote ;-)

Re: [Webmacro-devel] Re: WM license changes

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

On 19 Apr 2006, at 16:04, Justin Wells wrote:

>
> My mails are apparently not making it through to the list, so you  
> might
> want to do a full reply to my messages so others can see it. I will  
> look
> into why, sourceforge is complaining that my domain does not have a
> postmaster address. I've added one, not sure how I tell sourceforge
> that.
>
> At any rate, the FSF does acknowledge the BSD license, sans  
> advertising,
> as a compatible license, so that does fulfill Semiotek's promise to
> those who assigned the copyrights over in a way that the Apache  
> license
> does not. So, you have two options:
>
>    -- Dual GPL + Apache 2.0
>    -- BSD
>
> It's up to you, both are acceptable to me.

That's great news.

BSD!

Re: [Webmacro-devel] Re: Call for Vote: WebMacro License Change

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Thu 20 April 2006 18:32, Alex Twisleton-Wykeham-Fiennes wrote:
> On Wed 19 April 2006 21:53, Eric B. Ridge wrote:
> > http://www.webmacro.org/PossibleNewLicense
> >
> > "Sign it" if you want it.
>
> I've not contibuted to the wiki for many moons and don't remember my login.
> Am I just being stupid or is there not a "mail me my password", or a "reset
> my password" function?

(just to clarify - I do remember my login and my email address, it is just the 
password that is escaping me...)

> (and just for the record, I support the license proposal)
>
> Alex
>
> > eric
> >
> > On Apr 19, 2006, at 4:47 PM, Justin Wells wrote:
> > > * Copyright (c) 1996, 2006, Semiotek Inc.
> > > * All rights reserved.
> > > * Redistribution and use in source and binary forms, with or without
> > > * modification, are permitted provided that the following
> > > conditions are met:
> > > *
> > > *     * Redistributions of source code must retain the above copyright
> > > *       notice, this list of conditions and the following disclaimer.
> > > *
> > > *     * Redistributions in binary form must reproduce the above
> > > copyright
> > > *       notice, this list of conditions and the following
> > > disclaimer in the
> > > *       documentation and/or other materials provided with the
> > > distribution.
> > > *
> > > *     * Neither the name WebMacro, nor the name Semiotek Inc., nor
> > > the names
> > > *       of any of the contributors may be used to endorse or
> > > promote products
> > > *       derived from this software without specific prior written
> > > permission.
> > > *
> > > * THIS SOFTWARE IS PROVIDED BY SEMIOTEK INC., WEBMACRO.ORG, THE
> > > WEBMACRO
> > > * DEVELOPMENT TEAM, AND OTHER CONTRIBUTORS AND COPYRIGHT OWNERS
> > > ``AS IS''
> > > * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> > > TO, THE
> > > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > > PARTICULAR PURPOSE
> > > * ARE DISCLAIMED. IN NO EVENT SHALL SEMIOTEK INC., WEBMACRO.ORG,
> > > THE WEBMACRO
> > > * DEVELOPMENT TEAM, OR ANY OTHER CONTRIBUTOR OR COPYRIGHT HOLDER BE
> > > LIABLE FOR
> > > * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > > CONSEQUENTIAL DAMAGES
> > > * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> > > OR SERVICES;
> > > * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > > CAUSED AND
> > > * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> > > LIABILITY, OR TORT
> > > * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > > USE OF
> > > * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Re: Call for Vote: WebMacro License Change

[Alex Twisleton-Wykeham-F. <al...@fi...>]

On Wed 19 April 2006 21:53, Eric B. Ridge wrote:
> http://www.webmacro.org/PossibleNewLicense
>
> "Sign it" if you want it.

I've not contibuted to the wiki for many moons and don't remember my login.  
Am I just being stupid or is there not a "mail me my password", or a "reset 
my password" function?

(and just for the record, I support the license proposal)

Alex

> eric
>
> On Apr 19, 2006, at 4:47 PM, Justin Wells wrote:
> > * Copyright (c) 1996, 2006, Semiotek Inc.
> > * All rights reserved.
> > * Redistribution and use in source and binary forms, with or without
> > * modification, are permitted provided that the following
> > conditions are met:
> > *
> > *     * Redistributions of source code must retain the above copyright
> > *       notice, this list of conditions and the following disclaimer.
> > *
> > *     * Redistributions in binary form must reproduce the above
> > copyright
> > *       notice, this list of conditions and the following
> > disclaimer in the
> > *       documentation and/or other materials provided with the
> > distribution.
> > *
> > *     * Neither the name WebMacro, nor the name Semiotek Inc., nor
> > the names
> > *       of any of the contributors may be used to endorse or
> > promote products
> > *       derived from this software without specific prior written
> > permission.
> > *
> > * THIS SOFTWARE IS PROVIDED BY SEMIOTEK INC., WEBMACRO.ORG, THE
> > WEBMACRO
> > * DEVELOPMENT TEAM, AND OTHER CONTRIBUTORS AND COPYRIGHT OWNERS
> > ``AS IS''
> > * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> > TO, THE
> > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > PARTICULAR PURPOSE
> > * ARE DISCLAIMED. IN NO EVENT SHALL SEMIOTEK INC., WEBMACRO.ORG,
> > THE WEBMACRO
> > * DEVELOPMENT TEAM, OR ANY OTHER CONTRIBUTOR OR COPYRIGHT HOLDER BE
> > LIABLE FOR
> > * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > CONSEQUENTIAL DAMAGES
> > * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> > OR SERVICES;
> > * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > CAUSED AND
> > * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> > LIABILITY, OR TORT
> > * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > USE OF
> > * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Re: Call for Vote: WebMacro License Change

[<Web...@St...>]

On Wed, 19 Apr 2006, Eric B. Ridge wrote:

| Believe it or not, I don't live in Florida.  At any rate, here's a new ballot:
| 
| I think we should change the WebMacro License to:
| 
|   [!] BSD w/o "advertising clause" (http://en.wikipedia.org/wiki/BSD_license)
|   [ ] GPL + Apache v2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt)
|   [ ] No change

Of those, BSD is best, IMHO.

However, I think I'd really more like it to be public domain, as e.g. 
concurrent.jar is:

  Original Doug Lea work:

  http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
    " ... All classes are released to the public domain and may be used 
for any purpose whatsoever without permission or acknowledgment. "

  Now the 1.5 backport also has it:

  http://dcl.mathcs.emory.edu/util/backport-util-concurrent/
    " ... This software is released to the public domain, in the spirit of 
the original code written by Doug Lea. The code can be used for any 
purpose, modified, and redistributed without acknowledgment. No warranty 
is provided, either express or implied. "

  Creative Commons' Public Domain "definition", referred to from the 
above webpage:

  http://creativecommons.org/licenses/publicdomain
    " ... Dedicator recognizes that, once placed in the public domain, the 
Work may be freely reproduced, distributed, transmitted, used, modified, 
built upon, or otherwise exploited by anyone for any purpose, commercial 
or non-commercial, and in any way, including by methods that have not yet 
been invented or conceived. "


I don't think I have any votes here, but I'd still like to point it out!

Regards,
Endre.