Menu
▾
▴
webmacro-user — List for WebMacro users, developers, competitors, and friends.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(68) |
Dec
(77) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(75) |
Feb
(84) |
Mar
(89) |
Apr
(96) |
May
(52) |
Jun
(73) |
Jul
(99) |
Aug
(46) |
Sep
(40) |
Oct
(46) |
Nov
(45) |
Dec
(25) |
| 2004 |
Jan
(13) |
Feb
(74) |
Mar
(40) |
Apr
(18) |
May
(31) |
Jun
(1) |
Jul
(16) |
Aug
(1) |
Sep
(21) |
Oct
(19) |
Nov
(10) |
Dec
(16) |
| 2005 |
Jan
(4) |
Feb
(12) |
Mar
(46) |
Apr
(33) |
May
(64) |
Jun
(1) |
Jul
(60) |
Aug
(31) |
Sep
(26) |
Oct
(24) |
Nov
(37) |
Dec
(10) |
| 2006 |
Jan
(3) |
Feb
(31) |
Mar
(122) |
Apr
(22) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(8) |
|
From: Tim P. <ti...@pa...> - 2005-03-30 19:13:17
|
Hi gang, It is great that there is a bit more activity on the list. I have been using WM for java code generation, and it has continued to work very nicely. However I am having pain with whitespace handling. Up until 0.98p1 whitespace gobbling was perfect, then just a few versions before 1.0 there was an urgent, and I am sure genuine, need to break it, (if I remember correctly so that CSV files could be generated cleanly). The documentation at http://www.webmacro.org/WhiteSpace still refers to the oldskool rules. Those rules worked perfectly for clean and elegant HTML and similar code generation, which is the central use case for WM. Can the default be returned to the 0.98p1 rules and the current incomprehensible rules become pluggable please? yours TimP |
|
From: Mike W. <M.W...@tr...> - 2005-03-30 14:37:37
|
Hello everybody,
it would be great to have "soon" a 2.0 release.
I'd like to see the following items to be included in this new version:
1) adjusted DefaultDirective (see attachment).
Made #default pre wm2 compatible.
#default $myVar to "value" has been deprecated, but NOW it still works!
It generates a warning if LogLevel.directive: NOTICE
This is a neat trick to log all the occurences and replace them!
Log-example: ../my.wmt:34.2 uses #default $border to "default", please use:
#default $border = "default"
2) adjusted LogFile (see attachment)
ChangeLog:
14-01-2005 (Mike Weerdenburg)
LogFilePerDay
It was :
exampl. c:/logs/wm.log -> c:/logs/wm.log_20050105
exampl. c:/logs/wmlog -> c:/logs/wm_log_20050105
Now it is :
exampl. c:/logs/wm.log -> c:/logs/wm_20050105.log
exampl. c:/logs/wmlog -> c:/logs/wm_log_20050105
Write a message to the 'old' logfile when switching to a 'new' one.
17-07-2002 (Marcel Huijkman)
setting for WebMacro.properties added
LogFilePerDay
usage:
LogFilePerDay=FALSE or TRUE
LogFileAutoFlush
usage:
LogFileAutoFlush=FALSE or TRUE
(Notice: Only handy when developing on a Operating system, that buffers
file-writing, not recommended for production, since it obviously slows down
the machine.)
3) new WhileDirective (see attachment)
Just have fun with it...
Syntax: #while (condition) [limit (int)] { block } WhileDirective implements
a WebMacro directive for an while control structure. If you use it without
the limit option than it stops after 1000000 loops! Use a limit value < 0 to
create a loop without a limit, this could hang your template!
4) new SilentEvaluationExceptionHandler (see attachment)
An implementation of EvaluationExceptionHandler which throws some
exception's when it is called.
The error is stored back into the webcontext $WMERROR (as ArrayList) and
could be handled by the templatewriter.
You can use this in case of a live-situation to mail the error or show the
error in a fashioned way.
Example:
#if ( $Variable.isDefined("WMERROR") )
{
<B>Error(s):</B><BR>
#foreach $item in $WMERROR
{
$item<BR>
}
}
* This one looks like the 'DebugEvaluationExceptionHandler' but doesn't
throw all the Exeptions.
5) adjusted EvalDirective (no attachment, sorry I have no clue how to adjust
this)
#eval <Macro or String> [using { ... }]
To 'parse' a Macro or String value...
> Keats? Already back from Calif? To do some SD for the WM community? ;-)
Please add this modifications / add-ons to WebMacro 2.0 !
Greetings
Mike Weerdenburg
PS. Maybe we should make a wish list for this 'new' WebMacro 2.0 release?
And set a date! when it should be up and running?
|
|
From: <Web...@St...> - 2005-03-29 10:37:29
|
On Fri, 11 Mar 2005, Marc Palmer wrote: | Hi, | | Long time no speak! | | I finally got around to getting 2.0b1 (only a year late!) and am working | on the start of CMS using WM. Will there be a 2.0 release -anytime- (dropping "soon" this time)? Regards, Endre |
|
From: Marc P. <ma...@an...> - 2005-03-23 16:00:53
|
Keats Kirsch wrote: > The current implementation uses a HashMap. Hopefully in the future this > will become configurable. > I added some description to http://webmacro.org/WMScriptExpressions Thanks for that Keats. -- Marc Palmer wj...@wa... Wangjammers - Java, J2ME and Web Consultants ~ http://www.wangjammers.org/ |
|
From: Keats K. <ke...@xa...> - 2005-03-23 15:39:58
|
According to the Wiki page, http://webmacro.org/MacroDirective: ==================================== ... You can also create global macro libraries and make WebMacro include them automatically into every template. To do this, set the "Macros.Include" configuration setting to a space-separated list of templates you want to parse for macros. These templates will be loaded via WebMacro's usual template loading mechanism and all macros found will be available in every template loaded subsequently. For example, you could put this line into your WebMacro.properties file: ## Include all macros from globalMacros.wmm: Macros.Include: globalMacros.wmm Note, that only that only the macro definitions will be included into other templates. Things like setting variables or other side effects, will be ignored. ... ==================================== Welcome to WM. Keats Peter Smith wrote: >new to wm. > >trying to find way to define global macro without >including a 'header.wm' in all my templates. i >already have a header.wm, actually, but it's different >for about 10 subprojects I have, and I need to add a >macro (~60 lines) to all of them. can I do this >another way? either create a global macro that is >scooped-up automatically by everyone, or >programmatically do a template.includeTemplate()-type >operation? > >thanks. > >p.s. javadoc api is broken on site. > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Webmacro-user mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-user > > > |
|
From: Keats K. <ke...@xa...> - 2005-03-23 15:34:12
|
The current implementation uses a HashMap. Hopefully in the future this will become configurable. I added some description to http://webmacro.org/WMScriptExpressions Cheers. Keats Marc Palmer wrote: > > Guys, > > I'm trying to find docs on webmacro.org for the map syntax that was > added to WM. i.e. > > #set $mymap = { "a":"apple", "b":"bee" } > > I can't find anything, i.e. about what type of object is put in the > context as a result, and what properties and methods exist on it. > > Is it a Map or a Hashtable or something else? > > We need docs on this in the "expressions" part of the script trail as > currently it doesn't seem to exist anywhere. > > I'll write some up (if I can remember my wiki login) if someone can > give me the basic info. > > Cheers > |
|
From: Peter S. <sh...@ya...> - 2005-03-22 15:05:34
|
new to wm. trying to find way to define global macro without including a 'header.wm' in all my templates. i already have a header.wm, actually, but it's different for about 10 subprojects I have, and I need to add a macro (~60 lines) to all of them. can I do this another way? either create a global macro that is scooped-up automatically by everyone, or programmatically do a template.includeTemplate()-type operation? thanks. p.s. javadoc api is broken on site. |
|
From: Marc P. <ma...@an...> - 2005-03-21 12:01:20
|
Guys, I'm trying to find docs on webmacro.org for the map syntax that was added to WM. i.e. #set $mymap = { "a":"apple", "b":"bee" } I can't find anything, i.e. about what type of object is put in the context as a result, and what properties and methods exist on it. Is it a Map or a Hashtable or something else? We need docs on this in the "expressions" part of the script trail as currently it doesn't seem to exist anywhere. I'll write some up (if I can remember my wiki login) if someone can give me the basic info. Cheers -- Marc Palmer wj...@wa... Wangjammers - Java, J2ME and Web Consultants ~ http://www.wangjammers.org/ Blog ~ http://www.jroller.com/page/Wangjammer5 |
|
From: Alex Twisleton-Wykeham-F. <al...@fi...> - 2005-03-16 11:49:26
|
On Wednesday 16 March 2005 11:44, Marcel Huijkman wrote: > > Marc Palmer wrote: > > > > Sorry, am I misunderstanding you? The delegating template > > loader provider which uses protocol-based TemplateLoader implementations > > has been in WM for a -long- time now. It's part of core WM, > > it's just not enabled by default. > > Haven't played with this, sorry. > > But if it is allready there, Alex should'n't have any problems > implementing his magic into his system. It was already implemented and working by the time you entered the discussion - this could be why I was so confused about your objections to the direction that we were going in... > So forget the discussion, thanks for the hint, and... > let's watch, play and see. Alex |
|
From: Marcel H. <mar...@ra...> - 2005-03-16 11:44:53
|
> Marc Palmer wrote: > > Sorry, am I misunderstanding you? The delegating template > loader provider which uses protocol-based TemplateLoader implementations > has been in WM for a -long- time now. It's part of core WM, > it's just not enabled by default. > Haven't played with this, sorry. But if it is allready there, Alex should'n't have any problems implementing his magic into his system. So forget the discussion, thanks for the hint, and... let's watch, play and see. -=================================================- Deze mail werd verstuurd met Webmail van RaketNet Meer informatie? http://www.raketnet.nl -=================================================- |
|
From: Marc P. <ma...@an...> - 2005-03-16 08:15:35
|
marcel.huijkman wrote: > Okay, A DB-based template loader could be handy. > > However, I advise not to go this way with naming it db: and so on. > > In a month, a persons stands up, and has an idea to have templates > stored in property files, > or in xml files or or an ftp server. So it must not be a db: solution, > but more generic. Sorry, I don't get this... you can have anything you like as a "protocol" identifier and it's a perfectly good system as far as I can see, you can have as many of them as you like: property:somepath/templatename db:somepath/templatename myXMLTemplateLoader:somepath/templatename randomCodeGenerator:somepath/templatename ...whatever. > It should be a thing you could easily use in your servlet and adapt to > whatever > happens in the future. Perhaps something like: You can. You just change the WM configuration to add the protocols you want. > #include as location1 "$(TEMPLATE_DIR)_includes/init.inc" > and location1 as a property in the WebMacro.properties > I don't know, but let's think first and then program. Sorry, am I misunderstanding you? The delegating template loader provider which uses protocol-based TemplateLoader implementations has been in WM for a -long- time now. It's part of core WM, it's just not enabled by default. Cheers -- Marc Palmer - - - wj...@wa... Wangjammers, J2ME Developers ~ http://www.wangjammers.org/games/ Blog ~ http://www.jroller.com/page/Wangjammer5 |
|
From: marcel.huijkman <mar...@ra...> - 2005-03-15 22:36:50
|
Marc Palmer wrote:
>
> To address Marcel's complaint about the "abuse" of #include, multiple
> databases containing templates would be configured using multiple
> delegating template loader definitions, such as db1: and db2:
>
> However a DB-based template loader could work like the URL template
> loading, and include the server and database name etc, with a JDBC
> URL. There's no reason not to do this as far as I can see, otherwise
> you're saying that http:// or https:// is a bad machanism.
>
Okay, A DB-based template loader could be handy.
However, I advise not to go this way with naming it db: and so on.
In a month, a persons stands up, and has an idea to have templates
stored in property files,
or in xml files or or an ftp server. So it must not be a db: solution,
but more generic.
It should be a thing you could easily use in your servlet and adapt to
whatever
happens in the future. Perhaps something like:
#include as location1 "$(TEMPLATE_DIR)_includes/init.inc"
and location1 as a property in the WebMacro.properties
I don't know, but let's think first and then program.
Alex Twisleton-Wykeham-Fiennes wrote:
>If we follow the #eval method that has been proposed then the inner template
>has to magically know that the $templatePath that has been passed to it has
>to be treated differently to other normal templates and the code switches
>into something like:-
>
> outer: #set $templatePath = <somethingUnknown>
> inner: #if ($Magic.requiresEval($templatePath)) {
> #eval $templatePath
> } #else {
> #include as template "$templatePath"
> }
>
>which to me seems to be a disadvantage.
>
>
This made me think......, perhaps the solution is to handle Magic like
Magic, like this:
#include as magic "$templatePath"
I got your point, however I could imagine that a person recieving a template
from somewhere and don't know from where it came, could easily be confused.
But let's assume that is certainly not my problem.
As I positifly said before, think first, than act.
And my idea's are free, but may be used by others :-)
|
|
From: Marc P. <ma...@an...> - 2005-03-15 16:47:01
|
> It already is. > > Also, we could probably add an option like "inline" to have #eval use > the current context. Is this worthwhile? Yes, that would be great. "inline" might not be the most web-author friendly term though (I know... CSS uses it...) What about calling the option "global" ? -- Marc Palmer - - - wj...@wa... Wangjammers, J2ME Developers ~ http://www.wangjammers.org/games/ Blog ~ http://www.jroller.com/page/Wangjammer5 |
|
From: Keats K. <ke...@xa...> - 2005-03-15 16:10:55
|
Mike Weerdenburg wrote:
>Hello Marc and others,
>
>I would't like to see the following solution:
>
>#eval <Macro or String> [using { ... }]
>
>Is precisely what I want, it does the same trick as my Directive...
>
>
I'm in Calif for SD West this week, but I should be able to make this
change when I get back next week.
>Personally I would't like to see an option 'to $myOutput'
>
>So you would get:
>#eval <Macro or String> [using { ... }] [to $myOutput]
>
>
I don't think the "to $myOutput" is necessary; just use #setblock, e.g.,
#setblock $myOutput { #eval $myStringTemplate }
>Can somebody !please! pick this 'solution' up?
>
>PS. 'using { ... }' must be optional, just as the 'to $myOutput'
>
>
It already is.
Also, we could probably add an option like "inline" to have #eval use
the current context. Is this worthwhile?
Keats
>Greetings,
>Mike Weerdenburg
>
>-----Oorspronkelijk bericht-----
>Van: web...@li...
>[mailto:web...@li...] Namens Marc Palmer
>Verzonden: maandag 14 maart 2005 10:54
>Aan: web...@li...
>Onderwerp: Re: [WebMacro-user] A WM brain bender: The solution
>
>Mike Weerdenburg wrote:
>
>
>>Hello everybody,
>>
>>
>>
>>I use this 'evalStringTemplate' to convert text from a database (or other
>>source) to a 'parsed' text.
>>
>>
>>
>
>I quite like your solution, certainly more than the #include as template
>"string:xxxxx" mechanism I am using currently (hey, it works). However
>the #include with configurable "protocols" is a brilliant mechanism and
>very useful indeed.
>
>To address Marcel's complaint about the "abuse" of #include, multiple
>databases containing templates would be configured using multiple
>delegating template loader definitions, such as db1: and db2:
>
>However a DB-based template loader could work like the URL template
>loading, and include the server and database name etc, with a JDBC URL.
>There's no reason not to do this as far as I can see, otherwise you're
>saying that http:// or https:// is a bad machanism.
>
>
>Back to the main issue... the problem with #evalStringTemplate is
>name-spacing of variables. #eval does this nicely, although an option to
>-not- create a new context would be nice.
>
>I think this feature should be built into #eval really, as Keats suggested:
>
>#eval <macro or string> [using { ... }]
>
>Personally, unless "using" is optional at the moment (can't check,
>webmacro.org seems down again), I think if "using" is omitted it should
>just use the current page context.
>
>Also, you could mitigate some of the error trapping problems of allowing
>strings to eval by requiring "as string" for String evaluations:
>
>#eval <Macro | "as string" String> [using { ... }]
>
>What do you guys think?
>
>Cheers
>
>
>
>
|
|
From: Mike W. <M.W...@tr...> - 2005-03-15 07:52:13
|
Hello Marc and others,
I would't like to see the following solution:
#eval <Macro or String> [using { ... }]
Is precisely what I want, it does the same trick as my Directive...
Personally I would't like to see an option 'to $myOutput'
So you would get:
#eval <Macro or String> [using { ... }] [to $myOutput]
Can somebody !please! pick this 'solution' up?
PS. 'using { ... }' must be optional, just as the 'to $myOutput'
Greetings,
Mike Weerdenburg
-----Oorspronkelijk bericht-----
Van: web...@li...
[mailto:web...@li...] Namens Marc Palmer
Verzonden: maandag 14 maart 2005 10:54
Aan: web...@li...
Onderwerp: Re: [WebMacro-user] A WM brain bender: The solution
Mike Weerdenburg wrote:
> Hello everybody,
>
>
>
> I use this 'evalStringTemplate' to convert text from a database (or other
> source) to a 'parsed' text.
>
I quite like your solution, certainly more than the #include as template
"string:xxxxx" mechanism I am using currently (hey, it works). However
the #include with configurable "protocols" is a brilliant mechanism and
very useful indeed.
To address Marcel's complaint about the "abuse" of #include, multiple
databases containing templates would be configured using multiple
delegating template loader definitions, such as db1: and db2:
However a DB-based template loader could work like the URL template
loading, and include the server and database name etc, with a JDBC URL.
There's no reason not to do this as far as I can see, otherwise you're
saying that http:// or https:// is a bad machanism.
Back to the main issue... the problem with #evalStringTemplate is
name-spacing of variables. #eval does this nicely, although an option to
-not- create a new context would be nice.
I think this feature should be built into #eval really, as Keats suggested:
#eval <macro or string> [using { ... }]
Personally, unless "using" is optional at the moment (can't check,
webmacro.org seems down again), I think if "using" is omitted it should
just use the current page context.
Also, you could mitigate some of the error trapping problems of allowing
strings to eval by requiring "as string" for String evaluations:
#eval <Macro | "as string" String> [using { ... }]
What do you guys think?
Cheers
--
Marc Palmer - - - wj...@wa...
Wangjammers, J2ME Developers
~ http://www.wangjammers.org/games/
Blog
~ http://www.jroller.com/page/Wangjammer5
|
|
From: Marc P. <ma...@an...> - 2005-03-14 09:54:25
|
Mike Weerdenburg wrote:
> Hello everybody,
>
>
>
> I use this 'evalStringTemplate' to convert text from a database (or other
> source) to a 'parsed' text.
>
I quite like your solution, certainly more than the #include as template
"string:xxxxx" mechanism I am using currently (hey, it works). However
the #include with configurable "protocols" is a brilliant mechanism and
very useful indeed.
To address Marcel's complaint about the "abuse" of #include, multiple
databases containing templates would be configured using multiple
delegating template loader definitions, such as db1: and db2:
However a DB-based template loader could work like the URL template
loading, and include the server and database name etc, with a JDBC URL.
There's no reason not to do this as far as I can see, otherwise you're
saying that http:// or https:// is a bad machanism.
Back to the main issue... the problem with #evalStringTemplate is
name-spacing of variables. #eval does this nicely, although an option to
-not- create a new context would be nice.
I think this feature should be built into #eval really, as Keats suggested:
#eval <macro or string> [using { ... }]
Personally, unless "using" is optional at the moment (can't check,
webmacro.org seems down again), I think if "using" is omitted it should
just use the current page context.
Also, you could mitigate some of the error trapping problems of allowing
strings to eval by requiring "as string" for String evaluations:
#eval <Macro | "as string" String> [using { ... }]
What do you guys think?
Cheers
--
Marc Palmer - - - wj...@wa...
Wangjammers, J2ME Developers
~ http://www.wangjammers.org/games/
Blog
~ http://www.jroller.com/page/Wangjammer5
|
|
From: Mike W. <M.W...@tr...> - 2005-03-14 07:46:38
|
Hello everybody, I use this 'evalStringTemplate' to convert text from a database (or other source) to a 'parsed' text. In the database there is a value like this: 'This is a very cool $trick'. In some kind of way we put this String in $myEvalVar #set $trick = "Super trick!" Now we can use (put's the output in the context): #evalStringTemplate $myEvalVar or #evalStringTemplate $myEvalVar to $myOutput myOutput :<BR>$myOutput And the output will be: This is a very cool Super trick! It is clean, simple and does the trick that I personally (and I also think others) need! And yes, it does not use innervar or outervar things, but I don't care. I just want the same functionality like an include, but from a string! Not a file! Before I wrote this directive, I used to save the string in a file called 'DATETIMESTAMP.inc' and then used include as template 'DATETIMESTAMP.inc' (but this is such an overkill for your system) It would be fun if this include would be used by the community! And if not, than I hope that someone likes it for personal usage. Just have fun with it! Just keep things simple! Than people will understand it, and use WebMacro! Greetings from the Netherlands, out of a town called Hillegom next to the Keukenhof, Mike Weerdenburg (Ex-colleague of Marcel Huijkman) _____ Van: web...@li... [mailto:web...@li...] Namens marcel.huijkman Verzonden: zaterdag 12 maart 2005 8:48 Aan: web...@li... Onderwerp: Re: [WebMacro-user] A WM brain bender: The solution Please don't do this via the #include directive. It's not an include and it sounds like a workaround for a specific problem! Don't misuse directive for other tasks as for where they were made for. A ex-collegue of mine made this allready and handed me the code, to see if it is good enough for the community (nice he), and I'm sure he won't mind that I put het source with this email. (and a template too!) The trick that you want: get a string from somewhere and use is as a kind of stamp and it works like this: #evalStringTemplate $myEvalVar to $myOutput myOutput :<BR>$myOutput The $myEvalVar in this example can be filled with: webmacro stuff (and yes, that's cool!) The string stays intact and the parsed string $myOutput has the result after evaluation of the $myEvalVar. Simple, efficient and just what you need. Please take a good look at it, and if it's suitable, give Mike Weerdenburg all the credits. |
|
From: Alex Twisleton-Wykeham-F. <al...@fi...> - 2005-03-13 12:00:47
|
Marcel
On Sunday 13 March 2005 06:48, marcel.huijkman wrote:
> I get your point. You want some magic to happen based on a given front-e=
nd
> string. So you made up some protocols like Db: or String: wich
> autoMagically give you the right spot, where the temple should be.
>
> Okay, some things to think about:
>
> What if I've got more than 1 Db?
> (and on different locations, and/or different brands, and /or not all are
> rdmbs)? How would your prefix look like?
> Who would decide those prefixes?
>
> What if you have a hashmap, hashtable, array, vector where all the
> templates where is How would your prefix look like?
>
> I think, if you what some magic, you have to make magic by creating the
> directive that you want but not by 'infecting' a standard directive. The
> nature=C2=A0 (and the absolute advantage) of WM is that it has pluggable
> directives. (You might even copy-paste for your benefit.)
OK, I get your point but that still doesn't solve the problem of having a=20
Template that doesn't know where the thing that it is going to evaluate is=
=20
coming from.=20
Suppose I give a more concrete example. I have a series of templates that=
=20
provide "eye candy" around a central template. These decorator templates=20
will have been created by individuals (graphic designers) who have no conce=
pt=20
of where the template that is going to be nested inside them is coming from.
We therefore have to be able to let them include this nested functionality=
=20
using one standard command that will be forwards compatible with the source=
s=20
of Templates that we haven't yet thought of.
There are two ways of getting a template to be resolved inside a webmacro=20
context at present:-
=2D by #include
=2D by some variant of #eval
Now, when we contract our graphic designers to build our decorator template=
s,=20
we are going to have to say to them that they should use one or the other=20
(and build a test framework that passes in a dummy template using the elect=
ed=20
technology that lets them evaluate their work). Once they have completed=20
their templates then we should (using whichever technology that we settle o=
n)=20
be able to swap out the testing template for the real template using=20
whichever template source is appropriate for that particular deployment,=20
ideally using the same decorator template in multiple different locations=20
with different technologies passing in the Template to be decorated.
So, if we go with #include then we need to be able to pass in a String that=
=20
will resolve to future sources of Templates that haven't yet been defined=20
yet.
If we go with #eval then we will want to pass in a Template object that has=
=20
been generated via a method that hasn't yet been defined yet.
These are both fundamentally the same problem, but it is just a question as=
to=20
where in the hierarchy we insert out code to generate our Template from the=
=20
as yet undefined source. My 'gut feeling' is that as the majority of time=
=20
including a template for evaluation is being performed by #include then=20
keeping things consistent for the graphic designer is "a good thing".
Now, earlier you mentioned the problem of knowing what "protocol" we are us=
ing=20
and the danger of "'infecting' a standard directive". I don't understand w=
hy=20
if we have a custom Template source that is resolvable by implementing a=20
custom TemplateLoader and registering it with the DelegatingTemplateProvide=
r=20
only in deployments where we want to use it is in any way against the desig=
n=20
of the code as it stands.
The implementation of these custom TemplateLoaders would be associated with=
=20
the individual deployment that they where being utilised for. If we are=20
worried about namespace clashes on protocol names then one could use more=20
unique 'namespace' definitions, for example:-
#set $templatePath=3D"<templatePath>:<templateMetaData>"
eg:-
#set $templatePath=3D"org.acme.db.DbTemplateLoader:TemplateTable.24"
This would guarantee that my implementation of a Db resolver wouldn't confl=
ict=20
with your implementation of Db resolver (by utilising "Db:" as the standard=
=20
header), plus it would be relatively easy to debug what the problem was as =
if=20
the TemplateLoader wasn't registered then you would get a "cannot find=20
template" message which would include the path the TemplateLoader that is=20
missing, whereas if the appropriate TemplateLoader was included and record =
24=20
on the TemplateTable was not found (or whatever the tech required is) then=
=20
it would be a more informative ResourceException.
> Please rethink this over.
>
> For all I know, we could be getting 1 directive which does it all. The
> usage is so complex that people start=C2=A0 looking for more simple solut=
ions.
This kind of depends on who "people" refers to. If "people" is the graphic=
=20
designers generating the wrapper templates, then they never even need to kn=
ow=20
what is in $templatePath or what tech is being used to resolve it. From=20
their point of view it is already as simple as it can possibly get as they=
=20
just have to '#include as template "$templatePath"'. If this doesn't work=
=20
then it is not their problem, but rather the problem of the parent template.
=46rom the viewpoint the people writing the framework that is going to invo=
ke=20
the parent template, it would just be a case of them selecting the technolo=
gy=20
that they are going to utilise to deliver the templates as is appropriate f=
or=20
the task in hand. If the templates are constant, then they may just use a=
=20
standard TemplateLoader and pass in a 'conventional' $templatePath that get=
s=20
resolved with stock WebMacro TemplateLoader implementations. If they have=
=20
more complex requirements (eg dynamically generated Template sources) then=
=20
they would create a dedicated binding to them via a custom TemplateLoader a=
nd=20
register this alone in the WebMacro template file. This doesn't have to be=
a=20
global "always on" thing for all WebMacro deployments, but just for=20
situations when it is required.
> Real Magic:
> Personally, I don't like magic, because the tricks are sometimes confusi=
ng
> my mind. I see something is happening, I thinks I know how the trick went,
> and at the end, I still feel cheated.
>
> Programmers Magic:
> I do like magic, if the result is predictable and when there is absolutly
> no doubt in the way the trick did it's job.
I fully agree with you. My example:-
<snip>
> > outer: #set $templatePath =3D <somethingUnknown>
> > inner: #if ($Magic.requiresEval($templatePath)) {
> > #eval $templatePath
> > } #else {
> > #include as template "$templatePath"
> > }
> >
> > which to me seems to be a disadvantage.
was intended to illustrate something that I wanted to avoid in the decorato=
r=20
(or inner) template.
The "custom protocol include" structure currently works and enables a=20
decorator template to always include a Template in multiple different=20
situations which are delivering the templates from different technologies=20
without requiring the decorator template author to have any knowledge of th=
e=20
implementation or usage of the delivery method of the Template, and it will=
=20
be very useful to me in some situations. However, if this is not the most=
=20
correct way of achieving this result then I would of course like to refacto=
r=20
my usage patterns into a better solution so would be very happy to get some=
=20
pointers as to alternatives.
Alex
|
|
From: marcel.huijkman <mar...@ra...> - 2005-03-13 06:51:05
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
I get your point. You want some magic to happen based on a given
front-end string.<br>
So you made up some protocols like Db: or String: wich autoMagically
give you the right spot,<br>
where the temple should be.<br>
<br>
Okay, some things to think about:<br>
<br>
What if I've got more than 1 Db?<br>
(and on different locations, and/or different brands, and /or not all
are rdmbs)?<br>
How would your prefix look like?<br>
Who would decide those prefixes?<br>
<br>
What if you have a hashmap, hashtable, array, vector where all the
templates where is<br>
How would your prefix look like?<br>
<br>
I think, if you what some magic, you have to make magic by creating the
directive that<br>
you want but not by 'infecting' a standard directive. The nature (and
the absolute advantage)<br>
of WM is that it has pluggable directives. (You might even copy-paste
for your benefit.)<br>
<br>
Please rethink this over.<br>
<br>
For all I know, we could be getting 1 directive which does it all. The
usage is so complex that<br>
people start looking for more simple solutions.<br>
<br>
Real Magic:<br>
Personally, I don't like magic, because the tricks are sometimes
confusing my mind.<br>
I see something is happening, I thinks I know how the trick went, and
at the end,<br>
I still feel cheated.<br>
<br>
Programmers Magic:<br>
I do like magic, if the result is predictable and when there is
absolutly no doubt in<br>
the way the trick did it's job.<br>
<br>
That's it for now.<br>
<br>
- Marcel -<br>
<br>
<br>
Alex Twisleton-Wykeham-Fiennes wrote:
<blockquote cite="mid...@fi..." type="cite">
<pre wrap="">On Saturday 12 March 2005 07:47, marcel.huijkman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Please don't do this via the #include directive.
It's not an include and it sounds like a workaround for a specific
problem!
Don't misuse directive for other tasks as for where they were made for.
</pre>
</blockquote>
<pre wrap=""><!---->
I fully appreciate your point of view, and am happy to follow what appears to
be the general consensus, but I would just like to add this usage possiblity
into the planning:-
If I have a template that knows that it is going to be fed a sub-template that
needs to be evaluated as a template withint the current context. I don't
know what this template is or where it is going to be coming from as this is
supplied by a process outside the scope of my current template. I'm going to
be passing in the name of the template as a String variable to this template.
In a 'normal' model, we would expect the template to be a conventional
webmacro template and we just do (outer is the template that is including the
inner template):-
outer: #set $templatePath = "template/path/file.wm"
inner: #include as template "$templatePath"
and it goes off and finds and evaluates the Template.
Now, if I've registered a FileTemplateLoader onto my
DelegatingTemplateProvider then the following will also work (transparently
to my inner template):-
outer: #set $templatePath = "/absolute/webmacro/dir/template/path/file.wm"
inner: #include as template "$templatePath"
And if I implemented an HttpTemplateLoader and registered it with
DelegatingTemplateProvider then it would be able to do this:-
outer: #set $templatePath = <a class="moz-txt-link-rfc2396E" href="http://www.mytemplateserver.com/file.wm">"http://www.mytemplateserver.com/file.wm"</a>
inner: #include as template "$templatePath"
Now, supposing that I had a Db that contained templates that where being
maintained through a different purpose and I made a DbTemplateLoader, then I
would be able to do this:-
outer: #set $templatePath = "db:/file.wm"
inner: #include as template "$templatePath"
and the DbTemplateLoader would accept the request for the template, due to the
leader header and resolve it via some internal logic from the rest of the
path and then return a Template object.
So far, I don't feel that I've strayed outside the scope of the what #include
is supposed to do, and if anything I've improved encapsulation of the inner
template by not forcing it to know where the Template is coming from or how
it was generated.
So why would it be a misuse of the task to make it so that the inner template
could just parse a Template source where the source of the Template was
completely undefined?
outer: #set $templatePath = "string:$someTemplateSource"
inner: #include as template "$templatePath"
If we follow the #eval method that has been proposed then the inner template
has to magically know that the $templatePath that has been passed to it has
to be treated differently to other normal templates and the code switches
into something like:-
outer: #set $templatePath = <somethingUnknown>
inner: #if ($Magic.requiresEval($templatePath)) {
#eval $templatePath
} #else {
#include as template "$templatePath"
}
which to me seems to be a disadvantage.
I do of course think that having the #eval syntax with the opportunity to pass
in dedicated Context scopes etc etc is of course a good thing and should be
possible and utilised in situations when the inner template _knows_ that this
is the case, but for the situation that is described above, I fail to see
where the StringTemplateLoader implementation of TemplateLoader is failing in
the requirements of TemplateLoader?
Alex
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click">http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click</a>
_______________________________________________
Webmacro-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Web...@li...">Web...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/webmacro-user">https://lists.sourceforge.net/lists/listinfo/webmacro-user</a>
.
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Alex Twisleton-Wykeham-F. <al...@fi...> - 2005-03-12 12:23:40
|
On Saturday 12 March 2005 07:47, marcel.huijkman wrote: > Please don't do this via the #include directive. > It's not an include and it sounds like a workaround for a specific > problem! > > Don't misuse directive for other tasks as for where they were made for. I fully appreciate your point of view, and am happy to follow what appears to be the general consensus, but I would just like to add this usage possiblity into the planning:- If I have a template that knows that it is going to be fed a sub-template that needs to be evaluated as a template withint the current context. I don't know what this template is or where it is going to be coming from as this is supplied by a process outside the scope of my current template. I'm going to be passing in the name of the template as a String variable to this template. In a 'normal' model, we would expect the template to be a conventional webmacro template and we just do (outer is the template that is including the inner template):- outer: #set $templatePath = "template/path/file.wm" inner: #include as template "$templatePath" and it goes off and finds and evaluates the Template. Now, if I've registered a FileTemplateLoader onto my DelegatingTemplateProvider then the following will also work (transparently to my inner template):- outer: #set $templatePath = "/absolute/webmacro/dir/template/path/file.wm" inner: #include as template "$templatePath" And if I implemented an HttpTemplateLoader and registered it with DelegatingTemplateProvider then it would be able to do this:- outer: #set $templatePath = "http://www.mytemplateserver.com/file.wm" inner: #include as template "$templatePath" Now, supposing that I had a Db that contained templates that where being maintained through a different purpose and I made a DbTemplateLoader, then I would be able to do this:- outer: #set $templatePath = "db:/file.wm" inner: #include as template "$templatePath" and the DbTemplateLoader would accept the request for the template, due to the leader header and resolve it via some internal logic from the rest of the path and then return a Template object. So far, I don't feel that I've strayed outside the scope of the what #include is supposed to do, and if anything I've improved encapsulation of the inner template by not forcing it to know where the Template is coming from or how it was generated. So why would it be a misuse of the task to make it so that the inner template could just parse a Template source where the source of the Template was completely undefined? outer: #set $templatePath = "string:$someTemplateSource" inner: #include as template "$templatePath" If we follow the #eval method that has been proposed then the inner template has to magically know that the $templatePath that has been passed to it has to be treated differently to other normal templates and the code switches into something like:- outer: #set $templatePath = <somethingUnknown> inner: #if ($Magic.requiresEval($templatePath)) { #eval $templatePath } #else { #include as template "$templatePath" } which to me seems to be a disadvantage. I do of course think that having the #eval syntax with the opportunity to pass in dedicated Context scopes etc etc is of course a good thing and should be possible and utilised in situations when the inner template _knows_ that this is the case, but for the situation that is described above, I fail to see where the StringTemplateLoader implementation of TemplateLoader is failing in the requirements of TemplateLoader? Alex |
|
From: marcel.huijkman <mar...@ra...> - 2005-03-12 07:50:05
|
/* * Copyright (C) 2005. All Rights Reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted under the terms of either of the following * Open Source licenses: * * The GNU General Public License, version 2, or any later version, as * published by the Free Software Foundation * (http://www.fsf.org/copyleft/gpl.html); * * This software is provided "as is", with NO WARRANTY, not even the * implied warranties of fitness to purpose, or merchantability. You * assume all risks and liabilities associated with its use. * * See www.webmacro.org for more information on the WebMacro project. * * @author Mike Weerdenburg * * @version 14-01-2005 * */ package org.webmacro.directive; import org.webmacro.*; import org.webmacro.engine.*; /** * EvalStringTemplateDirective allows you to evaluate a string just like it is a include / template against the current context.<p> * * Syntax:<pre> * #EvalStringTemplate $valueToEvaluateAsString [to $variable] *</pre> * */ public class EvalStringTemplateDirective extends Directive { /* the argument is NOT a file, but a string represending the template! */ private static final int PARSE_VALUE = 1; private static final int PARSE_TO = 2; private static final int PARSE_TO_VARIABLE = 3; private Variable _varTarget = null; private static final UndefinedMacro UNDEF = UndefinedMacro.getInstance(); private static final ArgDescriptor[] _args = new ArgDescriptor[] { new StringArg(PARSE_VALUE), new OptionalGroup(2), new KeywordArg(PARSE_TO, "to"), new LValueArg(PARSE_TO_VARIABLE), }; private static final DirectiveDescriptor _desc = new DirectiveDescriptor("evalStringTemplate", null, _args, null); public static DirectiveDescriptor getDescriptor () { return _desc; } // // these values are customized for this directive during build() // /** Logging can be good */ protected Log _log; /** the value as a Macro, if the value arg is a Macro */ protected Macro _macroValue; /** * the name given to the directive by webmacro configuration. */ protected String _directiveName; public final Object build (DirectiveBuilder builder, BuildContext bc) throws BuildException { // Get a log-instance. // In webmacro.properties : LogLevel.directive=DEBUG _log = bc.getLog("directive"); // name of this directive _directiveName = builder.getName(); // if a target provided, then output to the target! if (builder.getArg(PARSE_TO_VARIABLE, bc) != null) { try { _varTarget = (Variable) builder.getArg(PARSE_TO_VARIABLE, bc); } catch (ClassCastException e) { // throw new NotVariableBuildException(myDescr.name, e); } } Object o = builder.getArg(PARSE_VALUE, bc); if (o instanceof Macro) { // The value passed to us was a Macro (needs to be evaluated later). // If u use : #evalStringTemplate $myDatabaseFilledStringToEvaluate _macroValue = (Macro) o; } else { // If it's not a Macro, then generate an BuildException. // If u use : #evalStringTemplate "This is a string with nothing to parse!" throw new BuildException("#" + _directiveName + " was expecting a non-static value to evaluate, example: #" + _directiveName + " \"$myDatabaseFilledStringToEvaluate is very interesting!\""); } return this; } /** * Write out the included file to the specified FastWriter. If the * included file is actually a template, it is evaluated against the * <code>context</code> parameter before being written to the FastWriter */ public void write (FastWriter out, Context context) throws PropertyException { Broker broker = context.getBroker(); String strValue = null; // the value arg passed to us was a Macro, so evaluate and check it now. if (_macroValue != null) { Object obValue = _macroValue.evaluate(context); // Only set the value if the macro provided not is null and not Undefined. if ( (obValue != null) && (obValue != UNDEF) ) { strValue = obValue.toString(); } } if (strValue == null) { throw new PropertyException("#" + _directiveName + " value cannot be undefined or null"); } // Use the current templateName as templateName for the StringTemplate. // exampl. c:/wwwroot/templates/test.wm String templateName = context.getTemplateEvaluationContext()._templateName; // Use the current template location & directive name, so whe can re-trace error's. // exampl. c:/wwwroot/templates/test.wm:46.2 #evalStringTemplate if (templateName.indexOf(" #" + _directiveName) == -1) templateName = context.getCurrentLocation() + " #" + _directiveName; if (_log.loggingDebug()) { _log.debug("#" + _directiveName + " \"valueToEvaluateAsStringTemplate\"" + ((_varTarget == null) ? "" : " to $" + _varTarget.getVariableName())); } if (_log.loggingWarning()) { if (strValue.indexOf("#" + _directiveName) > -1) { // when in debug or warning mode, output a warning if a evalStringTemplate tries to use a evalStringTemplate // there could be situtations where this is desired, but it's good to make // the user aware of what they're doing _log.warning("#" + _directiveName + " uses a #" + _directiveName + ", maybe itself? (endless loop!) at " + context.getCurrentLocation()); } } // Create the new StringTemplate. Template tmplTemplate = new StringTemplate (broker, strValue, templateName); if (_varTarget != null) { // if a target variable provided, then output to the target. _varTarget.setValue(context, tmplTemplate.evaluateAsString(context)); } else { // else output to the specified FastWriter. out.write(tmplTemplate.evaluateAsBytes(out.getEncoding(), context)); } } public void accept (TemplateVisitor v) { v.beginDirective(_desc.name); v.visitDirectiveArg("EvalStringTemplate", _macroValue); if (_varTarget != null) v.visitDirectiveArg("EvalStringTemplateTarget", _varTarget); v.endDirective(); } } |
|
From: Eric B. R. <eb...@tc...> - 2005-03-11 23:03:55
|
> #include as template "string:$contentItem.Data"
This is really nasty. If this is what we want to do, why not change
the #include directive:
#include as inline-template "\$contentItem.Data"
(You'd have to escape all WM tokens like # and $ to keep them from
being evaluated in the current template).
Although, I like Keats' idea of
#eval "\$contentItem.Data" using { ... }
much better.
eric
|
|
From: Marc P. <ma...@an...> - 2005-03-11 20:14:56
|
Keats Kirsch wrote:
> Marc Palmer wrote:
>
>> Keats Kirsch wrote:
>>
>>> Continuing the conversation with myself ...
>>>
>>> Another interesting option would be to change the #eval directive to
>>> work with Strings as well as Macros. (I would automatically convert
>>> the String to a StringMacro). This would be a simple change. The
>>> only downside is that it might make it a bit harder to catch some
>>> errors.
>>>
>>> Then you could simply say:
>>>
>>> #eval $content.Data using { "contextData": $someData }
>>>
>>> This is kind of cool. You could even do stuff like:
>>>
>>> #eval "Hello, $userName" using { "userName": $User.Name }
>>
>>
>>
>> That would be the cleanest of them all. #eval was the first thing I
>> tried.
>>
>> However, is there a shortcut for #eval to make it pass in the caller's
>> context, so you don't have to pass all the stuff in?
>
>
> As documented on the Wiki pages, you can access variables from the
> callers context via the $OuterVars reference.
Yeah, I meant without any qualification though, so that these template
fragments to not need to know they are in a #eval block.
They shouldn't know after all, it is an implementation detail of the
calling template.
#eval <string> using { x }
Would make me happy. At least then I can put the data in as a
$contentInfo Map and thus hide the $OuterVars concept.
Cheers
--
Marc Palmer - - - wj...@wa...
Wangjammers, J2ME Developers
~ http://www.wangjammers.org/games/
Blog
~ http://www.jroller.com/page/Wangjammer5
|
|
From: Keats K. <ke...@xa...> - 2005-03-11 19:40:42
|
Marc Palmer wrote:
> Keats Kirsch wrote:
>
>> Continuing the conversation with myself ...
>>
>> Another interesting option would be to change the #eval directive to
>> work with Strings as well as Macros. (I would automatically convert
>> the String to a StringMacro). This would be a simple change. The
>> only downside is that it might make it a bit harder to catch some
>> errors.
>>
>> Then you could simply say:
>>
>> #eval $content.Data using { "contextData": $someData }
>>
>> This is kind of cool. You could even do stuff like:
>>
>> #eval "Hello, $userName" using { "userName": $User.Name }
>
>
> That would be the cleanest of them all. #eval was the first thing I
> tried.
>
> However, is there a shortcut for #eval to make it pass in the caller's
> context, so you don't have to pass all the stuff in?
As documented on the Wiki pages, you can access variables from the
callers context via the $OuterVars reference.
You can also evaluate a templet (or any Macro) directly in the current
context, e.g.,
#templet $t { Hello $User }
$t
This would work for your String case however, since you wouldn't have a
Macro reference. You'd be back to converting the string to a Macro first.
We could create a new option on #templet or #setblock, or a new
directive like #stemplet to handle this, or fix the $Template tool as
mentioned before. Or maybe a $toTemplet function would fit the bill?
Keats
> I know, it's less safe... but we live in an imperfect world ;-)
>
> Cheers
>
|
|
From: Marc P. <ma...@an...> - 2005-03-11 19:08:09
|
Keats Kirsch wrote:
> Continuing the conversation with myself ...
>
> Another interesting option would be to change the #eval directive to
> work with Strings as well as Macros. (I would automatically convert the
> String to a StringMacro). This would be a simple change. The only
> downside is that it might make it a bit harder to catch some errors.
>
> Then you could simply say:
>
> #eval $content.Data using { "contextData": $someData }
>
> This is kind of cool. You could even do stuff like:
>
> #eval "Hello, $userName" using { "userName": $User.Name }
That would be the cleanest of them all. #eval was the first thing I tried.
However, is there a shortcut for #eval to make it pass in the caller's
context, so you don't have to pass all the stuff in?
I know, it's less safe... but we live in an imperfect world ;-)
Cheers
--
Marc Palmer - - - wj...@wa...
Wangjammers, J2ME Developers
~ http://www.wangjammers.org/games/
Blog
~ http://www.jroller.com/page/Wangjammer5
|
24 messages has been excluded from this view by a project administrator.
