Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <web...@st...> - 2003-05-19 15:56:51
|
On Tue, 13 May 2003, Marc Palmer wrote: | | Hiya, | | I was wondering if you guys can share some thoughts on a deployment issue | with the forthcoming "WM app". | | The problem is with the WAR web-application concept really. A WAR file is a jar that includes everything, including the doc-root? So how are you going to put templates in there as well afterwards? | | I want this app to be able to serve (and process) *.wmt files out of the | box. You just install the webapp WAR, webapps/ignition is created | automatically, and you stick your templates under webapps/ignition. | | These pages are retrieved simply using a URI that matches with a file- | mapping in web.xml (i.e. *.wmt) - or by directly referring to the servlet | and document by name (http://yourserver:8080/ignition/engine/yourdoc.wmt). | | The file-mapping scheme is nicer, but only works if the templates are under | the webapp's document root (not WEB-INF) but that is no big deal unless you | accidentally delete your web.xml in which case all your templates are | downloaded as text (oh yes, I did it by mistake). That is a very bad security problem. I've mentioned this tons of times, and I can't understand that this isn't OBVIOUS to people!!! ;) Put your templates where the dangerous hackah' web-user out there can't find them, that is, beneath WEB-INF. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Marc P. <ma...@an...> - 2003-05-17 17:34:54
|
Hi, Anyone with experience of PropertyOperator stuff (I think that's where this lies) fancy tackling a simple snafu? I got this: org.webmacro.PropertyException: No method to set "xmlCV.Advanced" to type class java.lang.Boolean in supplied context (class org.webmacro.servlet.WebContext) at jndi:/localhost/ignition/marc/portholes/blurb.wmt:4.2 ...but the method DOES exist. However it was throwing a RuntimeException in its implementation. This is incorrectly being caught and reported as "No method" instead of reporting the real exception. Marc -- Marc Palmer AnyWare Ltd. http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-05-16 17:55:54
|
On Fri, 16 May 2003 12:04:03 -0400, <Kea...@di...> wrote:
> It should be up to the filter to decide how to handle nulls. In fact we
> used to have a "silence" filter that would return "" on any exception.
> Some folks would probably want that functionality again.
>
> I'm not sure what you mean by filtering only in evaluations not
> expressions. Variables are always evaluated in expressions. My
> conception is to filter only during expansion, not during evaluation.
> You could still get the filtered value of a variable using #setblock:
>
> #setblock $filteredX { $x }
OK that's almost what I meant. I meant that expressions are what is passed
to something like #if ( ) in parens, and an evaluation occurs when you
"expand" a variable. $myVar-1 inline in a template is not an expression,
its only an expression in #if ($myVar-1) for example.
I guess I've got my terminology confused that's all. Sounds like we are
talking about the same thing.
Marc
--
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/
|
|
From: <Kea...@di...> - 2003-05-16 16:04:19
|
It should be up to the filter to decide how to handle nulls. In fact we
used to have a "silence" filter that would return "" on any exception.
Some folks would probably want that functionality again.
I'm not sure what you mean by filtering only in evaluations not
expressions. Variables are always evaluated in expressions. My
conception is to filter only during expansion, not during evaluation. You
could still get the filtered value of a variable using #setblock:
#setblock $filteredX { $x }
Keats
#varfilter "HTMLEscape"
#if ($myVar)
Escaped it's $myVar
#end
#end
In this situation if $myVar is null it might be converted to "" by the
escaping (for example) and hence the logic is broken.
We could tackle this by not performing filtering in expressions (only in
evaluations) but this could be obtuse for the template writer. However it
would be quite a nice solution - if you need to use the filtered version
in
an expression you just #set it to a temp var.
|
|
From: Eric B. R. <eb...@tc...> - 2003-05-16 15:40:36
|
On Friday, May 16, 2003, at 11:04 AM, Kea...@di... wrote: > I don't see a big advantage of this over what we have today: > > $HTMLEscape($stuff) =A0 Personally, I like this a lot (and use it a lot too!), and would choose=20= this over any #filter-like directive we might cook up. I like looking=20= at the template and knowing exactly what is happening. Having #filter=20= munge my values in a part of the template I'm not currently looking at=20= would make it difficult to debug. Marc's point of it getting "really nasty in anything other than trivial=20= examples" doesn't hit home with me. In my world, the need for=20 filtering seems to be the exception. So I'm willing to deal with a=20 slightly more complicated syntax for those cases, simply so I can see=20 exactly what is going on. Also, you can almost fake the global filter with this: #set $stuff =3D "<b>Stuff</b>" #set $stuff_filtered =3D $HTMLEscape($stuff) $stuff_filtered renders as $stuff > versus > > $stuff.$HTMLEscape $stuff.HTMLEscape (w/o the extra $). > I'm not in love with the extra parens, but it's clean and simple and=20= > it works today. =A0The other way would involve hacking into the=20 > PropertyOperator class ... not for the faint of heart. I agree. Just trying to toss around different idea. eric > > Keats > > > > What about making filters as some kind of "virtual property": > > #set $stuff =3D "<b>Stuff</b>" > $stuff.HTMLEscape renders as $stuff > > You don't have the global (or local) application of filters to all > variables, but it's easy to type, makes your intentions clear, and can > be easily turned on or off, at will, per $variable. > > Just an idea. > > eric > |
|
From: Marc P. <ma...@an...> - 2003-05-16 15:26:32
|
That previous message made me think - How about a directive equivalent to #set but called something like #temp that will create variables whose scope is confined to the enclosing block, or the current template only if no enclosing block? This could help keep variable namespace pollution down. Thoughts? -- Marc Palmer AnyWare Ltd. http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-05-16 15:23:35
|
On Fri, 16 May 2003 11:04:14 -0400, <Kea...@di...> wrote:
> I don't see a big advantage of this over what we have today:
>
> $HTMLEscape($stuff)
>
> versus
>
> $stuff.$HTMLEscape
>
> I'm not in love with the extra parens, but it's clean and simple and it
> works today. The other way would involve hacking into the
> PropertyOperator class ... not for the faint of heart.
Plus you still have to specify it for every property and value, which gets
really nasty in anything other than trivial examples especially when you
are calling other helper's methods passing in a value, and then you need to
HTMLEscape the result.
It's just another level of dereferencing "noise".
There is a problem with the directive approach however. You have to be very
careful what you do:
#varfilter "HTMLEscape"
#if ($myVar)
Escaped it's $myVar
#end
#end
In this situation if $myVar is null it might be converted to "" by the
escaping (for example) and hence the logic is broken.
We could tackle this by not performing filtering in expressions (only in
evaluations) but this could be obtuse for the template writer. However it
would be quite a nice solution - if you need to use the filtered version in
an expression you just #set it to a temp var.
Which makes me think... starting another little thread...
Marc
--
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/
|
|
From: <Kea...@di...> - 2003-05-16 15:04:45
|
I don't see a big advantage of this over what we have today:
$HTMLEscape($stuff)
versus
$stuff.$HTMLEscape
I'm not in love with the extra parens, but it's clean and simple and it
works today. The other way would involve hacking into the
PropertyOperator class ... not for the faint of heart.
Keats
What about making filters as some kind of "virtual property":
#set $stuff = "<b>Stuff</b>"
$stuff.HTMLEscape renders as $stuff
You don't have the global (or local) application of filters to all
variables, but it's easy to type, makes your intentions clear, and can
be easily turned on or off, at will, per $variable.
Just an idea.
eric
On Friday, May 16, 2003, at 10:48 AM, Kea...@di... wrote:
>
> Originally filters where global to the template. I had hoped to
> simplify
> some things by giving them a block scope. But I guess I can't get away
> with that. Global filters are really the same as local filters anyway.
> Since there is an implicit block around the template you could just add
> global filters to the bottom of the stack where they would never get
> popped.
>
> One issue with global filters is how to turn them on and off.
> Personally
> the "#filter on/off" idea is not particularly appealing. It just seems
> messy and error prone.
>
> This is related to another issue that I'd hoped to side-step -- having
> filters apply only to selected variables. This is a cool idea, but
> trying
> to come up with decent way to specify this is WMScript is tricky. (I
> was
> thinking that you could do some of this with custom filters. For
> example
> you could write an HTMLEscape filter that only escapes variables with
> names
> that start with "ht" or something like that.)
>
> It occurs to me that since filtering, as I've delineated it, only
> happens
> at expansion time, we could "unfilter" a variable by using my $eval()
> function (or something similar). If filters don't apply to functions
> you
> could do something like:
>
> #filter "HTMLEscape" global
> #set $boldHTML = "<b>Bold</b>"
> The following HTML: $boldHTML would render as $eval($boldHTML)
>
> Keats
>
>
>
>
>
> Marc Palmer
> <ma...@an...> To:
> Sent by: web...@li...
> webmacro-devel-admin@lists cc:
> .sourceforge.net Subject: Re:
> [Webmacro-devel]
> Filter redux (was: A nice HTML Escaping
> solution?)
> 05/16/2003 08:37 AM
> Please respond to marc
>
>
>
>
>
>
> On Wed, 14 May 2003 15:41:31 -0400, <Kea...@di...> wrote:
>
>> I've thought quite a bit about this. My latest thinking is that
>> filters
>> (or variable filters) should be used as follows.
>>
>> #varfilter "HTMLEscape" {
>> #varfilter "NumberFormat" {
>> Hello $Customer,
>> You have the following items in your shopping cart: #foreach $item in
>> $Cart indexing $i {
>> $i - $item.Name, $item.Price
>> }
>> }
>> }
>
> In essence I think you're heading in the right direction here.
>
> However I am not too happy about the use of blocks - because it could
> make
> templates very messy if you have large amounts of content to apply to
> the
> filter - in terms of balancing block ends.
>
> For example, in most cases if you are reading values from objects
> (such as
> XML nodes) that are in a raw state, you need to HTMLEscape
> -everything-.
> This could lead to a #varfilter block that spans a huge amount of
> content
> and included content, with a lonely "#end" 500 lines down the template.
> It's a maintenance nightmare!
>
> Sure you can push that long content out into a template and use
> #include
> but having to do that just because we are filtering seems like bad
> news to
> me.
>
> What I was thinking of is a toggle-like system with no blocks, i.e:
>
> #varfilter "HTMLEscape" on
> #varfilter "NumberFormat" on
>
> ...
> #varfilter "HTMLEscape" off
> ...pre-escaped stuff here...
> #varfilter "HTMLEscape" on
> #varfilter "NumberFormat" off
> ...
>
> And so on. This would also give more flexibility than a strict
> hierarchical
>
> block system.
>
> The only trouble here is the order of application of filters. I would
> suggest that the directive builds up a list of filters that have been
> turned on (the first time they are turned on) - not a stack.
>
> This way the order of filters is maintained by the order in which they
> were
>
> first turned on - which is probably what people would expect anyway -
> last
> turned on, first executed.
>
> The internal list would maintain the current state of each filter,
> ordered
> by first activation (or the reverse - order of execution):
>
> HTMLEscape --> on
> NumberFormat --> off
> OtherFilter --> on
>
> In this scenario OtherFilter is executed first, NumberFormat is
> skipped,
> and HTMLEscape done last.
>
> While this might seem a bit strange, I think it might work really well
> -
> because if there are semantic reasons for specific ordering of some
> filters
>
> (HTMLEscape should in general always be the last) then they likely
> apply
> relative to the other filters you are using and remain constant
> throughout.
>
> Alternatively we could do it the showbiz way - "in order of
> appearance" -
> which allows a form of "declaration" of filters. So, if you don't use
> them
> all in the order you want them applied, you can simply "fudge" it at
> the
> start of your template:
>
> #varfilter HTMLEscape on
> #varfilter NumberFormat off
> #varfilter OtherFilter on
>
>> From then on it is obvious what the ordering is.
>
> I am sure there are some niche orderings or changed orderings that
> could
> lead to this, but right now we have no filtering and have never
> dreamed of
> such problems :-)
>
> At best we're looking at HTMLEscape and maybe one or two other filters
> active at the same time. It's never going to get that complicated. I
> don't
> mean we should code in limits - just that the scheme should be simple.
> Having said that though, you could stack up (via a #include !) all the
> filters you will use and just toggle them on/off when you need them.
> This
> also has its benefits.
>
> What do you think?
>
> --
> Marc Palmer
> AnyWare Ltd.
> http://www.anyware.co.uk/marc/
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Eric B. R. <eb...@tc...> - 2003-05-16 14:54:34
|
What about making filters as some kind of "virtual property":
#set $stuff = "<b>Stuff</b>"
$stuff.HTMLEscape renders as $stuff
You don't have the global (or local) application of filters to all
variables, but it's easy to type, makes your intentions clear, and can
be easily turned on or off, at will, per $variable.
Just an idea.
eric
On Friday, May 16, 2003, at 10:48 AM, Kea...@di... wrote:
>
> Originally filters where global to the template. I had hoped to
> simplify
> some things by giving them a block scope. But I guess I can't get away
> with that. Global filters are really the same as local filters anyway.
> Since there is an implicit block around the template you could just add
> global filters to the bottom of the stack where they would never get
> popped.
>
> One issue with global filters is how to turn them on and off.
> Personally
> the "#filter on/off" idea is not particularly appealing. It just seems
> messy and error prone.
>
> This is related to another issue that I'd hoped to side-step -- having
> filters apply only to selected variables. This is a cool idea, but
> trying
> to come up with decent way to specify this is WMScript is tricky. (I
> was
> thinking that you could do some of this with custom filters. For
> example
> you could write an HTMLEscape filter that only escapes variables with
> names
> that start with "ht" or something like that.)
>
> It occurs to me that since filtering, as I've delineated it, only
> happens
> at expansion time, we could "unfilter" a variable by using my $eval()
> function (or something similar). If filters don't apply to functions
> you
> could do something like:
>
> #filter "HTMLEscape" global
> #set $boldHTML = "<b>Bold</b>"
> The following HTML: $boldHTML would render as $eval($boldHTML)
>
> Keats
>
>
>
>
>
> Marc Palmer
> <ma...@an...> To:
> Sent by: web...@li...
> webmacro-devel-admin@lists cc:
> .sourceforge.net Subject: Re:
> [Webmacro-devel]
> Filter redux (was: A nice HTML Escaping
> solution?)
> 05/16/2003 08:37 AM
> Please respond to marc
>
>
>
>
>
>
> On Wed, 14 May 2003 15:41:31 -0400, <Kea...@di...> wrote:
>
>> I've thought quite a bit about this. My latest thinking is that
>> filters
>> (or variable filters) should be used as follows.
>>
>> #varfilter "HTMLEscape" {
>> #varfilter "NumberFormat" {
>> Hello $Customer,
>> You have the following items in your shopping cart: #foreach $item in
>> $Cart indexing $i {
>> $i - $item.Name, $item.Price
>> }
>> }
>> }
>
> In essence I think you're heading in the right direction here.
>
> However I am not too happy about the use of blocks - because it could
> make
> templates very messy if you have large amounts of content to apply to
> the
> filter - in terms of balancing block ends.
>
> For example, in most cases if you are reading values from objects
> (such as
> XML nodes) that are in a raw state, you need to HTMLEscape
> -everything-.
> This could lead to a #varfilter block that spans a huge amount of
> content
> and included content, with a lonely "#end" 500 lines down the template.
> It's a maintenance nightmare!
>
> Sure you can push that long content out into a template and use
> #include
> but having to do that just because we are filtering seems like bad
> news to
> me.
>
> What I was thinking of is a toggle-like system with no blocks, i.e:
>
> #varfilter "HTMLEscape" on
> #varfilter "NumberFormat" on
>
> ...
> #varfilter "HTMLEscape" off
> ...pre-escaped stuff here...
> #varfilter "HTMLEscape" on
> #varfilter "NumberFormat" off
> ...
>
> And so on. This would also give more flexibility than a strict
> hierarchical
>
> block system.
>
> The only trouble here is the order of application of filters. I would
> suggest that the directive builds up a list of filters that have been
> turned on (the first time they are turned on) - not a stack.
>
> This way the order of filters is maintained by the order in which they
> were
>
> first turned on - which is probably what people would expect anyway -
> last
> turned on, first executed.
>
> The internal list would maintain the current state of each filter,
> ordered
> by first activation (or the reverse - order of execution):
>
> HTMLEscape --> on
> NumberFormat --> off
> OtherFilter --> on
>
> In this scenario OtherFilter is executed first, NumberFormat is
> skipped,
> and HTMLEscape done last.
>
> While this might seem a bit strange, I think it might work really well
> -
> because if there are semantic reasons for specific ordering of some
> filters
>
> (HTMLEscape should in general always be the last) then they likely
> apply
> relative to the other filters you are using and remain constant
> throughout.
>
> Alternatively we could do it the showbiz way - "in order of
> appearance" -
> which allows a form of "declaration" of filters. So, if you don't use
> them
> all in the order you want them applied, you can simply "fudge" it at
> the
> start of your template:
>
> #varfilter HTMLEscape on
> #varfilter NumberFormat off
> #varfilter OtherFilter on
>
>> From then on it is obvious what the ordering is.
>
> I am sure there are some niche orderings or changed orderings that
> could
> lead to this, but right now we have no filtering and have never
> dreamed of
> such problems :-)
>
> At best we're looking at HTMLEscape and maybe one or two other filters
> active at the same time. It's never going to get that complicated. I
> don't
> mean we should code in limits - just that the scheme should be simple.
> Having said that though, you could stack up (via a #include !) all the
> filters you will use and just toggle them on/off when you need them.
> This
> also has its benefits.
>
> What do you think?
>
> --
> Marc Palmer
> AnyWare Ltd.
> http://www.anyware.co.uk/marc/
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: <Kea...@di...> - 2003-05-16 14:48:29
|
Originally filters where global to the template. I had hoped to simplify
some things by giving them a block scope. But I guess I can't get away
with that. Global filters are really the same as local filters anyway.
Since there is an implicit block around the template you could just add
global filters to the bottom of the stack where they would never get
popped.
One issue with global filters is how to turn them on and off. Personally
the "#filter on/off" idea is not particularly appealing. It just seems
messy and error prone.
This is related to another issue that I'd hoped to side-step -- having
filters apply only to selected variables. This is a cool idea, but trying
to come up with decent way to specify this is WMScript is tricky. (I was
thinking that you could do some of this with custom filters. For example
you could write an HTMLEscape filter that only escapes variables with names
that start with "ht" or something like that.)
It occurs to me that since filtering, as I've delineated it, only happens
at expansion time, we could "unfilter" a variable by using my $eval()
function (or something similar). If filters don't apply to functions you
could do something like:
#filter "HTMLEscape" global
#set $boldHTML = "<b>Bold</b>"
The following HTML: $boldHTML would render as $eval($boldHTML)
Keats
Marc Palmer
<ma...@an...> To:
Sent by: web...@li...
webmacro-devel-admin@lists cc:
.sourceforge.net Subject: Re: [Webmacro-devel]
Filter redux (was: A nice HTML Escaping
solution?)
05/16/2003 08:37 AM
Please respond to marc
On Wed, 14 May 2003 15:41:31 -0400, <Kea...@di...> wrote:
> I've thought quite a bit about this. My latest thinking is that filters
> (or variable filters) should be used as follows.
>
> #varfilter "HTMLEscape" {
> #varfilter "NumberFormat" {
> Hello $Customer,
> You have the following items in your shopping cart: #foreach $item in
> $Cart indexing $i {
> $i - $item.Name, $item.Price
> }
> }
> }
In essence I think you're heading in the right direction here.
However I am not too happy about the use of blocks - because it could make
templates very messy if you have large amounts of content to apply to the
filter - in terms of balancing block ends.
For example, in most cases if you are reading values from objects (such as
XML nodes) that are in a raw state, you need to HTMLEscape -everything-.
This could lead to a #varfilter block that spans a huge amount of content
and included content, with a lonely "#end" 500 lines down the template.
It's a maintenance nightmare!
Sure you can push that long content out into a template and use #include
but having to do that just because we are filtering seems like bad news to
me.
What I was thinking of is a toggle-like system with no blocks, i.e:
#varfilter "HTMLEscape" on
#varfilter "NumberFormat" on
...
#varfilter "HTMLEscape" off
...pre-escaped stuff here...
#varfilter "HTMLEscape" on
#varfilter "NumberFormat" off
...
And so on. This would also give more flexibility than a strict hierarchical
block system.
The only trouble here is the order of application of filters. I would
suggest that the directive builds up a list of filters that have been
turned on (the first time they are turned on) - not a stack.
This way the order of filters is maintained by the order in which they were
first turned on - which is probably what people would expect anyway - last
turned on, first executed.
The internal list would maintain the current state of each filter, ordered
by first activation (or the reverse - order of execution):
HTMLEscape --> on
NumberFormat --> off
OtherFilter --> on
In this scenario OtherFilter is executed first, NumberFormat is skipped,
and HTMLEscape done last.
While this might seem a bit strange, I think it might work really well -
because if there are semantic reasons for specific ordering of some filters
(HTMLEscape should in general always be the last) then they likely apply
relative to the other filters you are using and remain constant throughout.
Alternatively we could do it the showbiz way - "in order of appearance" -
which allows a form of "declaration" of filters. So, if you don't use them
all in the order you want them applied, you can simply "fudge" it at the
start of your template:
#varfilter HTMLEscape on
#varfilter NumberFormat off
#varfilter OtherFilter on
>From then on it is obvious what the ordering is.
I am sure there are some niche orderings or changed orderings that could
lead to this, but right now we have no filtering and have never dreamed of
such problems :-)
At best we're looking at HTMLEscape and maybe one or two other filters
active at the same time. It's never going to get that complicated. I don't
mean we should code in limits - just that the scheme should be simple.
Having said that though, you could stack up (via a #include !) all the
filters you will use and just toggle them on/off when you need them. This
also has its benefits.
What do you think?
--
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Marc P. <ma...@an...> - 2003-05-16 13:12:15
|
On Fri, 16 May 2003 13:37:57 +0100, Marc Palmer <ma...@an...> wrote: > #varfilter HTMLEscape on > #varfilter NumberFormat off > #varfilter OtherFilter on > > From then on it is obvious what the ordering is. > > I am sure there are some niche orderings or changed orderings that could > lead to this, but right now we have no filtering and have never dreamed > of such problems :-) Should read "I am sure there are some niche orderings or changed orderings that could lead to problems with this, ..." -- Marc Palmer AnyWare Ltd. http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-05-16 12:39:38
|
On Wed, 14 May 2003 15:41:31 -0400, <Kea...@di...> wrote:
> I've thought quite a bit about this. My latest thinking is that filters
> (or variable filters) should be used as follows.
>
> #varfilter "HTMLEscape" {
> #varfilter "NumberFormat" {
> Hello $Customer,
> You have the following items in your shopping cart: #foreach $item in
> $Cart indexing $i {
> $i - $item.Name, $item.Price
> }
> }
> }
In essence I think you're heading in the right direction here.
However I am not too happy about the use of blocks - because it could make
templates very messy if you have large amounts of content to apply to the
filter - in terms of balancing block ends.
For example, in most cases if you are reading values from objects (such as
XML nodes) that are in a raw state, you need to HTMLEscape -everything-.
This could lead to a #varfilter block that spans a huge amount of content
and included content, with a lonely "#end" 500 lines down the template.
It's a maintenance nightmare!
Sure you can push that long content out into a template and use #include
but having to do that just because we are filtering seems like bad news to
me.
What I was thinking of is a toggle-like system with no blocks, i.e:
#varfilter "HTMLEscape" on
#varfilter "NumberFormat" on
...
#varfilter "HTMLEscape" off
...pre-escaped stuff here...
#varfilter "HTMLEscape" on
#varfilter "NumberFormat" off
...
And so on. This would also give more flexibility than a strict hierarchical
block system.
The only trouble here is the order of application of filters. I would
suggest that the directive builds up a list of filters that have been
turned on (the first time they are turned on) - not a stack.
This way the order of filters is maintained by the order in which they were
first turned on - which is probably what people would expect anyway - last
turned on, first executed.
The internal list would maintain the current state of each filter, ordered
by first activation (or the reverse - order of execution):
HTMLEscape --> on
NumberFormat --> off
OtherFilter --> on
In this scenario OtherFilter is executed first, NumberFormat is skipped,
and HTMLEscape done last.
While this might seem a bit strange, I think it might work really well -
because if there are semantic reasons for specific ordering of some filters
(HTMLEscape should in general always be the last) then they likely apply
relative to the other filters you are using and remain constant throughout.
Alternatively we could do it the showbiz way - "in order of appearance" -
which allows a form of "declaration" of filters. So, if you don't use them
all in the order you want them applied, you can simply "fudge" it at the
start of your template:
#varfilter HTMLEscape on
#varfilter NumberFormat off
#varfilter OtherFilter on
From then on it is obvious what the ordering is.
I am sure there are some niche orderings or changed orderings that could
lead to this, but right now we have no filtering and have never dreamed of
such problems :-)
At best we're looking at HTMLEscape and maybe one or two other filters
active at the same time. It's never going to get that complicated. I don't
mean we should code in limits - just that the scheme should be simple.
Having said that though, you could stack up (via a #include !) all the
filters you will use and just toggle them on/off when you need them. This
also has its benefits.
What do you think?
--
Marc Palmer
AnyWare Ltd.
http://www.anyware.co.uk/marc/
|
|
From: Marc P. <ma...@an...> - 2003-05-15 12:55:32
|
Has anyone noticed that SourceForge now provide RSS news feeds for every project? I only just discovered this. Now I have WebMacro project news coming up on my site, using the new WebMacro webapp: If you want to see this in action, go to the following URL (this is not blatant self-promotion - just the nicest way to show it to you) and look on the right hand side, down under the BBC news feed. http://www.anyware.co.uk/ignition/marc/ The layout's a little ugly with the huge description in there from SF, but you get the idea. I'm also using a helper to "summarise" text to a max length. Unfortunately some of the news items have HTML markup in them such as <a href=.... The RSS 2 feeds from SF do not have a doctype and are therefore not validated, which allows them to put crap HTML in there. As a result I have had to HTML escape it all, as I am truncating the news items to a maximum length as some can be very long. That is our fault though - the RSS news items come from the project news so if we refrain from using HTML in the news releases then we will get much better results. You can get project stats too - the raw XML is here: http://sourceforge.net/export/rss2_projsummary.php?group_id=64597 This is kind of cool, I have to say. It would be nice to work RSS into webmacro.org so we can have a single point where we update our release news - i.e. SF. Then the WM site can feed off that, saving us all time. We should be able to do this easily using the XML helper we have written, and the RSS display templates (handle RSS 0.91, 1.0 and 2.0). I wouldn't know how to modify the Wiki app to do this though. One annoying thing, due to the way Wiki URLs work, is that I don't think it would be possible to run Wiki over the WebMacro webapp. Maybe I'm wrong... we'll see later. I'm hoping to release Alpha 1 of the webapp to you wm-dev guys either this weekend or Monday(ish). Just polishing up docs and some "must fix" issues, some refactoring in the XML helper and hopefully a rudimentary SQL query action by then. The plan is that I will show this to you guys and you can decide whether or not this should become part of the whole WebMacro project. If so, that is great. However if you guys don't like it, or the fact that I've just designed and written this all myself so far, then I am happy to just release it myself from our wangjammers.org site. I was just thinking, now I am using the project on a live server myself and how cool it is, that this project is too big to sit in WM's /contrib gathering dust. Best wishes, Marc -- Marc Palmer AnyWare Ltd. http://www.anyware.co.uk/marc/ |
|
From: <Kea...@di...> - 2003-05-14 22:01:26
|
No I'm not touching the indexing variable, just the loop variable ($foo in
your example).
#set $a=0
#foreach $a in [1,2,3]{ ... }
$a would now be 0 instead of 3. It would be UNDEFINED if it hadn't been
defined prior to the #foreach.
Keats
>I've made a patch to ForeachDirective.java for this. I haven't created
>unit tests yet, but they should be easy enough. However, I'm a bit
>hesitant to commit the change since it might break some templates. (Not
>very sensible templates, but still ...) Perhaps I should make a
>configuration option to disable this for backwards compatibility? Or is
>that overkill?
Seems like overkill to add an option.
But I think I'm in favor of leaving it as is:
- at the end of the loop, the index tells you how many rows were
processed -- this is useful and I could see people using this.
- What about this case:
#set $a=1
#foreach $foo in $foos indexing $a {
}
Should $a be UNDEFINED at the end of this? This seems wrong.
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Marc P. <ma...@an...> - 2003-05-14 22:00:15
|
On Wed, 14 May 2003 14:54:54 -0700, Brian Goetz <br...@qu...> wrote:
>
>> I've made a patch to ForeachDirective.java for this. I haven't created
>> unit tests yet, but they should be easy enough. However, I'm a bit
>> hesitant to commit the change since it might break some templates. (Not
>> very sensible templates, but still ...) Perhaps I should make a
>> configuration option to disable this for backwards compatibility? Or is
>> that overkill?
>
> Seems like overkill to add an option.
>
> But I think I'm in favor of leaving it as is:
> - at the end of the loop, the index tells you how many rows were
> processed -- this is useful and I could see people using this.
> - What about this case:
>
> #set $a=1
> #foreach $foo in $foos indexing $a {
> }
>
> Should $a be UNDEFINED at the end of this? This seems wrong.
No. The way I described it initially, if $foo or $a exist before the loop,
they remain after the loop.
If you really need $a to last beyond the loop you can #set it to a var.
Seems annoying I know but relying on this kind of behaviour is just bad
news - especially when #include comes into the picture.
Effectively in a #include you don't know what variables are around, and
having loop vars lingering around can lead to some really obscure bugs.
Marc
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
|
From: Brian G. <br...@qu...> - 2003-05-14 21:55:17
|
>I've made a patch to ForeachDirective.java for this. I haven't created
>unit tests yet, but they should be easy enough. However, I'm a bit
>hesitant to commit the change since it might break some templates. (Not
>very sensible templates, but still ...) Perhaps I should make a
>configuration option to disable this for backwards compatibility? Or is
>that overkill?
Seems like overkill to add an option.
But I think I'm in favor of leaving it as is:
- at the end of the loop, the index tells you how many rows were
processed -- this is useful and I could see people using this.
- What about this case:
#set $a=1
#foreach $foo in $foos indexing $a {
}
Should $a be UNDEFINED at the end of this? This seems wrong.
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
|
|
From: <Kea...@di...> - 2003-05-14 21:45:56
|
I've made a patch to ForeachDirective.java for this. I haven't created unit tests yet, but they should be easy enough. However, I'm a bit hesitant to commit the change since it might break some templates. (Not very sensible templates, but still ...) Perhaps I should make a configuration option to disable this for backwards compatibility? Or is that overkill? Keats Hi, Could we make the loop "current value" var in #foreach "disappear" from the context after the #foreach block completes - just as in java an inline var declaration in for() will? It seems silly that they hang around after the directive completes, and it can lead to confusing errors when editing lots of included templates. Some people may be taking advantage of this feature and any changes would break it - but a setting in WebMacro.properties could deal with that. Could we be more clever though? i.e: #set $mycounter = "" #foreach $mycounter in $list ... #end In the above case #foreach could detect that mycounter exists and leave it "as is" when the loop exits. In the following case: #foreach $mycounter in $list ... #end ...as the var is not previously in the context, #foreach could add it as it does now, but then remove it when the block ends. Thoughts? -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webmacro-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Eric B. R. <eb...@tc...> - 2003-05-14 19:57:15
|
On Wednesday, May 14, 2003, at 03:45 PM, Kea...@di...=20
wrote:
> Why the limitation on comparison operators? =A0Wouldn't it be simpler=20=
> and more intuitive to treat all newlines like ordinary whitespace=20
> within any kind of bracketed expression?
I'm not sure yet. I need to do some more work on it. I dropped the=20
.jar into my project and damn near all my existing (and known good)=20
templates throw all sorts of nasty parser exceptions now. Grrrr. I'll=20=
beat it into submission!
eric
>
> Keats
>
>
>
> On Wednesday, May 14, 2003, at 09:48 =A0AM, Kea...@di...
> wrote:
>
> >
> > Eric you rule! =A0This will be a major leap forward for WM. =A0The =
single
> > line limitation on lists and #if expressions has always been=20
> annoying.
> > =A0And native Map declaration syntax ... we're well on our way to =
2.0!
>
> I'm pretty excited about it. =A0I hope to build it here at the office
> today and pop it in my current project just to see what breaks. =A0Gunna=
> have to write a bunch of test cases. =A0One thing to note, you can't =
put
> newlines between comparison operators. =A0For example:
>
> #if ($foo
> =A0 =A0 =A0 =A0 =3D=3D
> =A0 =A0 =A0 1) {
>
> }
> is invalid. =A0At least it should be. =A0Didn't actually test this =
yet.
>
> My concern is that this was really easy to do. =A0And it makes me =
wonder
> why Brian didn't do it to begin with. =A0I'm sure he thought about it =
and
> I'd like to know why he decided against it. =A0Brian?
>
> eric
>
> >
> > Keats
> >
> >
> >
> <image.tiff>
> >
> >
> >
> >
> > On Tuesday, May 13, 2003, at 10:48 =A0PM, Eric B. Ridge wrote:
> >
> > >> This does look really good, but I wonder how many people will
> > >> realistically use the syntax to create a mapping of more than a
> > >> couple of items - as we don't support multi-line RValues (AFAIK)
> > this
> > >> would get "hella-ugly".
> > >
> > > I was thinking about this today, and I think it may be possible to
> > > allow <CRLF>'s in there.
> >
> > This is probably going to freak Brian out...
> >
> > Okay, not only did I get multi-line values to work for maps and=20
> lists,
> > but I managed to hook us up with multi-line #ifs, #macros(),
> > $functions(), and other $Variable.methodCalls(). =A0Basically =
anything
> > that takes an argument list... plus expressions.
> >
> > Checkout the attached template. =A0Yeah, it's ugly, but it parses =
and
> > executes correctly... along with our existing test suite. =A0 The
> > multi-line #if stuff is just way cool!
> >
> > Oh yeah, I also changed the map syntax to use a colon instead of=20
> "=3D>".
> >
> > I've committed all of this into CVS in the hopes that somebody will
> > attempt to use it. =A0Still gotta do test cases... and losts of 'em.
> >
> > eric
> >
> >
> >
> > <foo.wm>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise=20
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
|
|
From: <Kea...@di...> - 2003-05-14 19:45:28
|
Why the limitation on comparison operators? Wouldn't it be simpler and=20
more intuitive to treat all newlines like ordinary whitespace within any=20
kind of bracketed expression?
Keats
On Wednesday, May 14, 2003, at 09:48 AM, Keats=5FK...@di...=20
wrote:
>
> Eric you rule! =A0This will be a major leap forward for WM. =A0The single=
=20
> line limitation on lists and #if expressions has always been annoying.=20
> =A0And native Map declaration syntax ... we're well on our way to 2.0!
I'm pretty excited about it. I hope to build it here at the office=20
today and pop it in my current project just to see what breaks. Gunna=20
have to write a bunch of test cases. One thing to note, you can't put=20
newlines between comparison operators. For example:
#if ($foo
=3D=3D
1) {
}
is invalid. At least it should be. Didn't actually test this yet.
My concern is that this was really easy to do. And it makes me wonder=20
why Brian didn't do it to begin with. I'm sure he thought about it and=20
I'd like to know why he decided against it. Brian?
eric
>
> Keats
>
>
>
<image.tiff>
>
>
>
>
> On Tuesday, May 13, 2003, at 10:48 =A0PM, Eric B. Ridge wrote:
>
> >> This does look really good, but I wonder how many people will
> >> realistically use the syntax to create a mapping of more than a
> >> couple of items - as we don't support multi-line RValues (AFAIK)=20
> this
> >> would get "hella-ugly".
> >
> > I was thinking about this today, and I think it may be possible to
> > allow <CRLF>'s in there.
>
> This is probably going to freak Brian out...
>
> Okay, not only did I get multi-line values to work for maps and lists,
> but I managed to hook us up with multi-line #ifs, #macros(),
> $functions(), and other $Variable.methodCalls(). =A0Basically anything
> that takes an argument list... plus expressions.
>
> Checkout the attached template. =A0Yeah, it's ugly, but it parses and
> executes correctly... along with our existing test suite. =A0 The
> multi-line #if stuff is just way cool!
>
> Oh yeah, I also changed the map syntax to use a colon instead of "=3D>".
>
> I've committed all of this into CVS in the hopes that somebody will
> attempt to use it. =A0Still gotta do test cases... and losts of 'em.
>
> eric
>
>
>
> <foo.wm>
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: <Kea...@di...> - 2003-05-14 19:41:40
|
Marc,
We've been hashing over this filtering issue for years now. There was a
filter mechanism in WM long ago, but it has been broken since well before
1.0.
I've thought quite a bit about this. My latest thinking is that filters
(or variable filters) should be used as follows.
#varfilter "HTMLEscape"
{
#varfilter "NumberFormat"
{
Hello $Customer,
You have the following items in your shopping cart:
#foreach $item in $Cart indexing $i {
$i - $item.Name, $item.Price
}
}
}
Internally each #varfilter directive:
- gets the configured VariableFilter instance using the supplied key
(e.g., HTMLEscape)
- puts the filter on the filter stack in the current context
- evaluates its block
- pops the filter off the stack
In the Variable.write() method we would call "applyFilters" which would
look something like:
Object applyFilters(Context context, Variable var){
java.util.List filterStack =
(java.util.Stack)context.get("~FilterStack");
Object val = var.getValue(context);
if (filterStack != null){
for (int i=filterStack.size(); i>=0; i--){
VariableFilter filt = (VariableFilter)filterStack.get(i);
val = filt.apply(context, var, val);
}
}
return val;
}
The simple VariableFilter interface with the single "apply" method would
give filters the ability to look at the variable and the context and
decide whether to pass the value through unchanged, or to modify it. For
example the HTMLEscapeFilter might look like:
public class HTMLEscapeFilter implements VariableFilter {
public Object apply(Context c, org.webmacro.engine.Variable v,
Object val) {
if (val instanceof java.lang.String)
return org.webmacro.util.HTMLEscaper.escape((String)val);
else return val;
}
}
I think this is a bit less ambitious than the original Filter concept, but
I think it could be quite powerful and not difficult to implement.
Keats
Marc Palmer <ma...@an...>
Sent by: web...@li...
05/13/2003 10:09 AM
Please respond to marc
To: web...@li...
cc:
Subject: [Webmacro-devel] A nice HTML Escaping solution?
Hi,
I haven't yet seen a nice solution for the HTML escaping problem.
I've tried several solutions myself over the years, and the most
successful
one to date was having my servlet automatically generate HTMLEscape'd
clones of objects to put into the template.
Calling $Text.HTMLEscape or similar is just horribly ugly in complex
templates.
However that doesn't work if you are just using simple generic helper
classes to bring in data into WM templates. i.e. our XML Helper. You can
get all the data you like but it is in unescaped form.
Now from a design point of view I don't want to add a
"setHTMLEscaping(boolean)" property to our helper. It breaks an otherwise
elegant and orthogonal design. However it is the easiest solution for now.
What I have thought of though, is some kind of directive mechanism for
setting a filter for all values evaluated in the template. i.e.
#set $myVar = "This is some <<<unescaped>>> text & I like it"
Unescaped: $myVar
#setfilter "htmlescape"
Auto-escaped: $myVar
#setfilter "none"
Unescaped again: $myVar
The output of this would be:
Unescaped: This is some <<<unescaped>>> text & I like it
Auto-escaped: This is some <<<unescaped>>> text & I
like it
Unescaped again: This is some <<<unescaped>>> text & I like it
The idea here being that we have some way, from a directive (perhaps using
package access code), to hook into the evaluation mechanism of WM and
insert a filter that will execute on EVERY evaluation, after the result
has
been converted to a string if necessary. i.e.
public interface WMEvaluationFilter
{
String filterValue( String src)
}
Trivial - but whether we can plug this into WM easily is yet to be
determined.
What do you think? I think this is a very nice solution to the problem as
you can turn escaping on and off during template evaluation, and you don't
need to write ugly $Text.HTMLEscape everywhere.
It also means you could provide other filters that do interesting things,
as I am sure HTML escaping is not the only boring conversion task we will
need to do in coming years. What about producing XML output and using
customised escaping/entities.
Another possibility might be, instead of using a directive, have a special
syntax for escaped evaluation, and set the escaping once in a template as
needed - i.e:
$@myVar
The $@ could signify evaluation with filtering, and #setfilter or similar
is only used if you want to change the default filter.
Any thoughts?
Marc
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Marc P. <ma...@an...> - 2003-05-14 14:47:37
|
On Wed, 14 May 2003 09:56:02 -0400, <Kea...@di...> wrote: > I'm pretty sure this is a known Tomcat limitation. (I learned about this > when trying to use a J2EE plug-in for Eclipse.) I'd bet that you > wouldn't have this issue with Resin or Jetty or one of the big commercial > Servlet containers. Hmm. Trouble is we need this to work out of the box for free, and Tomcat is the only real solution for that I think. I am starting to think the "server everything through the servlet" approach with a separate "docRoot" property for the application is the best idea. This way all docs can be out of the webapps tree and are immune to upgrade complications. Of course you could set the docRoot to within the webapp dir too. This way you can just drop in new .WARs whenever you like, and your docRoot could even be the same as your httpd doc root (if you have one). This would make it trivial to mix static and dynamic content that refer to the same resources. Any body know more about the servlet RequestDispatcher stuff and whether it can take advantage of thinks like mod_jk2 to improve the performance? I doubt it unless you can provide the local filesystem path to the resource... Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Marc P. <ma...@an...> - 2003-05-14 14:38:47
|
On Wed, 14 May 2003 01:04:54 -0400, Eric B. Ridge <eb...@tc...> wrote: > This is probably going to freak Brian out... If this is working fine then it really is fantastic - good work! However, like you, I suspect there might be a reason Brian didn't do it before. Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Eric B. R. <eb...@tc...> - 2003-05-14 14:20:21
|
On Wednesday, May 14, 2003, at 09:48 AM, Kea...@di...=20
wrote:
>
> Eric you rule! =A0This will be a major leap forward for WM. =A0The =
single=20
> line limitation on lists and #if expressions has always been annoying.=20=
> =A0And native Map declaration syntax ... we're well on our way to 2.0!
I'm pretty excited about it. I hope to build it here at the office=20
today and pop it in my current project just to see what breaks. Gunna=20=
have to write a bunch of test cases. One thing to note, you can't put=20=
newlines between comparison operators. For example:
#if ($foo
=3D=3D
1) {
}
is invalid. At least it should be. Didn't actually test this yet.
My concern is that this was really easy to do. And it makes me wonder=20=
why Brian didn't do it to begin with. I'm sure he thought about it and=20=
I'd like to know why he decided against it. Brian?
eric
>
> Keats
>
>
>
<image.tiff>
>
>
>
>
> On Tuesday, May 13, 2003, at 10:48 =A0PM, Eric B. Ridge wrote:
>
> >> This does look really good, but I wonder how many people will
> >> realistically use the syntax to create a mapping of more than a
> >> couple of items - as we don't support multi-line RValues (AFAIK)=20
> this
> >> would get "hella-ugly".
> >
> > I was thinking about this today, and I think it may be possible to
> > allow <CRLF>'s in there.
>
> This is probably going to freak Brian out...
>
> Okay, not only did I get multi-line values to work for maps and lists,
> but I managed to hook us up with multi-line #ifs, #macros(),
> $functions(), and other $Variable.methodCalls(). =A0Basically anything
> that takes an argument list... plus expressions.
>
> Checkout the attached template. =A0Yeah, it's ugly, but it parses and
> executes correctly... along with our existing test suite. =A0 The
> multi-line #if stuff is just way cool!
>
> Oh yeah, I also changed the map syntax to use a colon instead of "=3D>".=
>
> I've committed all of this into CVS in the hopes that somebody will
> attempt to use it. =A0Still gotta do test cases... and losts of 'em.
>
> eric
>
>
>
> <foo.wm>=
|
|
From: <Kea...@di...> - 2003-05-14 13:56:19
|
I'm pretty sure this is a known Tomcat limitation. (I learned about this
when trying to use a J2EE plug-in for Eclipse.) I'd bet that you wouldn't
have this issue with Resin or Jetty or one of the big commercial Servlet
containers.
Keats
Marc Palmer <ma...@an...>
Sent by: web...@li...
05/13/2003 06:36 PM
Please respond to marc
To: web...@li...
cc:
Subject: [Webmacro-devel] Request for help/advice on the WM app
Hiya,
I was wondering if you guys can share some thoughts on a deployment issue
with the forthcoming "WM app".
The problem is with the WAR web-application concept really.
I want this app to be able to serve (and process) *.wmt files out of the
box. You just install the webapp WAR, webapps/ignition is created
automatically, and you stick your templates under webapps/ignition.
These pages are retrieved simply using a URI that matches with a file-
mapping in web.xml (i.e. *.wmt) - or by directly referring to the servlet
and document by name (http://yourserver:8080/ignition/engine/yourdoc.wmt).
The file-mapping scheme is nicer, but only works if the templates are
under
the webapp's document root (not WEB-INF) but that is no big deal unless
you
accidentally delete your web.xml in which case all your templates are
downloaded as text (oh yes, I did it by mistake).
The big WIN with using file-mapping and templates in your webapp doc root
is that you can use relative links in your pages to other documents
(templates or not) and images. If referring to the servlet by name you can
use relative links still for templates, but anything else (static HTML or
images) will not work relative.
This makes it completely natural for web developers.
What we want specifically, is the same behaviour you can experience with
JSP - your templates in with your normal documents, so that links work as
you'd expect.
This all currently works fine with the webapp. Except when you want to re-
deploy the webapp to upgrade it.
If you have a .WAR to upgrade with, you can't (well I can't) get Tomcat
4.x
to overwrite the existing webapps/ignition directory when doing an auto-
deploy. You have to delete the directory and then restart tomcat with the
new .WAR in place ready for auto-deploy.
Now this totally sucks because it makes upgrading complete hell. Not only
do you have to stop Tomcat, you also have to copy all your document files
back over the new upgraded auto-deployed webapps/ignition directory.
This is a bit like having to reinstall your entire httpd doc root just to
upgrade apache. It's a nightmare.
Now I could easily allow WM Ignition to get its templates from a path -
outside- of the webapp directory tree. However this also breaks relative
linking, as a servlet file-mapping will not work if the documents are not
under the webapp docroot.
So in that scenario we win on upgrading ease, but lose a lot in linking
ease of use.
Once scenario I have thought of is using Tomcat's global "web.xml" to set
up the ignition servlet just like Jasper is set up - i.e. for *.wmt files
in any web application. This would be a perfect solution - except I do not
want to tie us to Tomcat. Is this a standard feature of servlet containers
these days, or is it peculiar to Tomcat?
Are there any other solutions you guys can think of?
It is highly desirable to have the WebMacro templates in exactly the same
place existing HTML or other content will be stored.
We can't have people losing their content when they upgrade - and we
shouldn't expect them to have to manually unzip the .WAR file over their
existing webapps directory.
...why won't Tomcat just redeploy a .WAR? It's very annoying. All the
options are on. Is this a problem peculiar to Tomcat 4.1 - do other
servlet
containers happily redeploy a .WAR without requiring a restart or the
deletion of the webapp directory?
Thanks in advance.
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Marc P. <ma...@an...> - 2003-05-14 09:04:36
|
Sorry I replied to the admin address....
------- Forwarded message -------
From: Marc Palmer <ma...@an...>
To: web...@li...
Subject: Re: Map Support (was: Re: [Webmacro-devel] #templet directive)
Date: Wed, 14 May 2003 10:03:06 +0100
> On Tue, 13 May 2003 22:48:27 -0400, Eric B. Ridge <eb...@tc...> wrote:
>
>>> On that basis I can't see it being much more useful than my #newobject
>>> directive
>>
>> Except you can't use #newobject in-line in a method call, but you can
>> use {}:
>> $Object.doSomething({"key" : "value"})
>
> You've got a very good point there. That is nice.
>
>> Plus, you have the ability to use (evaluated) $variables as _key_ names
>> (when defining the map, of course). This isn't very helpful for doing
>> output, but if the point of your template is to build up some kind of
>> complicated Map structure to pass along somewhere else, it'll be very
>> useful.
>
> You can do that with anything, though it is slightly uglier. i.e.
> $myNewObjectInstance.set($keyname, $value)
>
>>> (sorry still not in CVS), and the directive has the "inherits"
>>> functionality to virtually "inherit" properties from another #newobject
>>> created object (or Map). Also have copyFrom() and copyTo methods and
>>> things like that.
>>
>> Well, and so does {}:
>>
>> #set $map = {"a" : "b", "c" : "d" }
>> #set $map2 = $map.clone()
>> #set $map3 = {}
>> $map3.putAll($map2)
>
> Yes, of course.
>
> Keep up the good work! I will be interested to see how the CRLF in {} and
> [] goes. Surely using { } is going to cause problems with blocks?
>
> Marc
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
237 messages has been excluded from this view by a project administrator.
