Menu
▾
▴
webmacro-user
|
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-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: 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: 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: 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-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 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: 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: 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-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-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: <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: 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?
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X