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: Eric B. R. <eb...@tc...> - 2003-03-26 19:59:17
|
On Wednesday, March 26, 2003, at 02:49 PM, Marc Palmer wrote: <snip> > THEN I would pass that Properties to the constructor of WM... which I > can't. Is there any reason anyone can see why I can't just add a ctor > to WM that takes a Properties object instead of the filename? Of coure > I'd have to add WM(Servlet, Properties) too. Actually, Brian and I have chatted about this off-list before. We thought it was a good thing to do, but neither of us got around to doing it. If you need it now, I say go for it. eric |
|
From: Marc P. <ma...@an...> - 2003-03-26 19:48:18
|
Hi all, I'm trying to create instances of WM at runtime based on the "modules" a user has configured in this webapp I'm writing. Basically each "module" has its own properties file with settings for the webapp, but also they can supply WebMacro properties that would normally be in WebMacro.properties. The problem is that I need to load templates from the webapp context, but if I use the WM(Servlet) constructor I cannot force it to use a specific .properties file for the settings. If I don't use the WM(Servlet) constructor, things won't work obviously. I'm using the delegating template provider and need to use webapp:/WEB- INF/templates (for example) as a path. I think I would need to introduce a new ctor for WM - WM(Servlet, String configFile). What do you think? Following on from this, I actually want my webapp to predetermine some of the settings, without them existing in a file. For example I want to set the template provider to the delegating template provider, and set the default template path to webapp:/WEB-INF/templates and webapp:/templates and webapp:/ - and still allow the module writer to override this with new settings in their module properties file. To do this programmatically I would plan to create a Properties object and set my template path properties on it. Then I would create another Properties and set the first Properties I created as its "ancestor" in the constructor - and then load the module's specific properties into it. THEN I would pass that Properties to the constructor of WM... which I can't. Is there any reason anyone can see why I can't just add a ctor to WM that takes a Properties object instead of the filename? Of coure I'd have to add WM(Servlet, Properties) too. Thoughts? Marc |
|
From: Eric B. R. <eb...@tc...> - 2003-03-25 15:27:31
|
On Tuesday, March 25, 2003, at 02:58 AM, Endre St=F8lsvik wrote: > On Mon, 24 Mar 2003, Eric B.Ridge wrote: > > | On Monday, March 24, 2003, at 12:40 PM, Endre St=F8lsvik wrote: > | > | > Using Cranky, this evaluates as false, printing "(Dead)". > | > | Using which version of WM? 1.1final? If not, better upgrade! > > Right. > > I'm using 1.1final. Can you work up a little TestCase and send it to me or the list? This was something I thought I fixed many months ago. eric |
|
From: Eric B. R. <eb...@tc...> - 2003-03-25 15:22:14
|
On Tuesday, March 25, 2003, at 02:57 AM, Endre St=F8lsvik wrote:
> | Brian convinced me that we can somewhat easily get this particular
> | error message changed to something like:
> | "no zero-arg macro named #contentString"
>
> That would of course be _heaps and bounds_ (is that the English term?)
"Leaps and Bounds", but I kinda like "Heaps and Bounds"!
> better, and would of course lead me to look for the bug in the=20
> args-list,
> not scrutinize the spelling..
>
> And it's a much better error message anyway, since it says "I _do_=20
> have a
> directive of that name, but the one I know of have got some arguments,
> 'kay?".
>
> But .. shouldn't all such error messages say "directive or macro" .. ?
In this case, we'd be able to guess that it was a #macro.
> | However, we're still not gunna be able to pick up on the fact that=20=
> the
> | right-hand paren is missing. That's something you'll still need to
> | figure out manually by looking at the error message and line/column
> | information.
>
> The parser often says things like "Found this thing, was expecting one=20=
> of
> these thingys ' ... ' ". Why couldn't it notice that there is missing =
a
> paren, given that it encounters "}" before the started "(" ?
No, because the parser doesn't count parens or braces. At least I=20
think that's the case.
eric=
|
|
From: <web...@st...> - 2003-03-25 07:58:46
|
On Mon, 24 Mar 2003, Eric B.Ridge wrote: | On Monday, March 24, 2003, at 12:40 PM, Endre Stølsvik wrote: | | > Using Cranky, this evaluates as false, printing "(Dead)". | | Using which version of WM? 1.1final? If not, better upgrade! Right. I'm using 1.1final. -- 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: <web...@st...> - 2003-03-25 07:57:57
|
On Mon, 24 Mar 2003, Eric B.Ridge wrote:
| On Monday, March 24, 2003, at 01:31 PM, Eric B. Ridge wrote:
| > On Monday, March 24, 2003, at 12:19 PM, Endre Stølsvik wrote:
|
| >> "no such directive".. well, it's a macro, goddamnit! And it's there!
| >>
| >> Adding the missing ")" fixes everything.
| >
| > Because of your missing ")", WM's parser thought the directive (or
| > macro) you requested was a zero-arg directive/macro named
| > "#contentString".
| >
| > This isn't a bug, it's user error.
Well, thanks, dude! ;)
|
| Brian convinced me that we can somewhat easily get this particular
| error message changed to something like:
| "no zero-arg macro named #contentString"
That would of course be _heaps and bounds_ (is that the English term?)
better, and would of course lead me to look for the bug in the args-list,
not scrutinize the spelling..
And it's a much better error message anyway, since it says "I _do_ have a
directive of that name, but the one I know of have got some arguments,
'kay?".
But .. shouldn't all such error messages say "directive or macro" .. ?
|
| However, we're still not gunna be able to pick up on the fact that the
| right-hand paren is missing. That's something you'll still need to
| figure out manually by looking at the error message and line/column
| information.
The parser often says things like "Found this thing, was expecting one of
these thingys ' ... ' ". Why couldn't it notice that there is missing a
paren, given that it encounters "}" before the started "(" ?
--
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: Eric B. R. <eb...@tc...> - 2003-03-25 01:38:16
|
On Monday, March 24, 2003, at 01:31 PM, Eric B. Ridge wrote: > On Monday, March 24, 2003, at 12:19 PM, Endre St=F8lsvik wrote: >> "no such directive".. well, it's a macro, goddamnit! And it's there! >> >> Adding the missing ")" fixes everything. > > Because of your missing ")", WM's parser thought the directive (or=20 > macro) you requested was a zero-arg directive/macro named=20 > "#contentString". > > This isn't a bug, it's user error. Brian convinced me that we can somewhat easily get this particular=20 error message changed to something like: "no zero-arg macro named #contentString" However, we're still not gunna be able to pick up on the fact that the=20= right-hand paren is missing. That's something you'll still need to=20 figure out manually by looking at the error message and line/column=20 information. eric > > eric > > > ------------------------------------------------------- > 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: Marc P. <ma...@an...> - 2003-03-24 19:32:25
|
On Mon, 24 Mar 2003 11:32:32 -0500, <kea...@na...> wrote: > I think Lane's approach is probably the simplest solution for you -- > just > use two servlets and map one to *.wmt and the other to Ignition/* or > whatever. The *.wmt servlet should probably just extend the Ignition/* > servlet adding some logic to deal with the template name. Yeah I see this, but I don't like it. There's a lot of data and structures loaded to support the application, and these should not be duplicated - which would require using a singleton for that data, which I also don't really like - for example it might be desirable to set up several instances of the main WM servlet while keeping -separate-data i.e. different configs - within the same web app. I don't like to restrict myself unless I really have to. I'll see how it goes :-) -- Marc Palmer |
|
From: Eric B. R. <eb...@tc...> - 2003-03-24 18:31:24
|
On Monday, March 24, 2003, at 12:19 PM, Endre St=F8lsvik wrote:
> Check this line.. :
>
> #if ($crossstate.ShowDetails) { #contentString ($collection, =20
> $crossstate, $entitytype }
>
> Notice the missing ")" ?
>
> That produce this not-quite-correct stack-trace:
>
<snip>
> org.webmacro.parser.ParseException: No such directive #contentString =20=
> at =20
> /data/devel/endre/new/coredoc/webapp/WEB-INF/classes/com/coredocument/=20=
> impl/ui/corepage/corelets/helpers/Recurser.wm:53.2
> at =20
> =
org.webmacro.directive.IncludeDirective.makePropertyException(IncludeDi=20=
> rective.java:536)
> at =20
> =
org.webmacro.directive.IncludeDirective.getTemplate(IncludeDirective.ja=20=
> va:465)
> at =20
> =
org.webmacro.directive.IncludeDirective.getThingToInclude(IncludeDirect=20=
> ive.java:433)
> at =20
> =
org.webmacro.directive.IncludeDirective.write(IncludeDirective.java:354=20=
> )
> at org.webmacro.engine.Block.write(Block.java:135)
> at org.webmacro.engine.WMTemplate.write(WMTemplate.java:262)
> ...
>
> "no such directive".. well, it's a macro, goddamnit! And it's there!
>
> Adding the missing ")" fixes everything.
Because of your missing ")", WM's parser thought the directive (or =20
macro) you requested was a zero-arg directive/macro named =20
"#contentString".
This isn't a bug, it's user error.
eric=
|
|
From: Eric B. R. <eb...@tc...> - 2003-03-24 18:29:34
|
On Monday, March 24, 2003, at 12:40 PM, Endre St=F8lsvik wrote:
> Using Cranky, this evaluates as false, printing "(Dead)".
Using which version of WM? 1.1final? If not, better upgrade!
eric
>
> #if ($collcetionreference.DirectlyDead)
> {<td><span class=3D"alert">(Directly Dead)</span></td>}
> #else {<td><span class=3D"notice">(Dead)</span></td>}
>
>
> Fixing spelling error of "collection", and thus creating a valid
> reference, fixes the problem, and it prints "(Diretly Dead)" as it=20
> should.
>
>
> --=20
> Mvh,
> Endre St=F8lsvik M[+47 93054050] F[+47 51625182]
> Developer @ CoreTrek AS - http://www.coretrek.com/
> CoreTrek corporate portal / EIP - http://www.corelets.com/
>
>
> -------------------------------------------------------
> 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: <web...@st...> - 2003-03-24 17:41:00
|
Using Cranky, this evaluates as false, printing "(Dead)".
#if ($collcetionreference.DirectlyDead)
{<td><span class="alert">(Directly Dead)</span></td>}
#else {<td><span class="notice">(Dead)</span></td>}
Fixing spelling error of "collection", and thus creating a valid
reference, fixes the problem, and it prints "(Diretly Dead)" as it should.
--
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: <web...@st...> - 2003-03-24 17:19:28
|
Check this line.. :
#if ($crossstate.ShowDetails) { #contentString ($collection, $crossstate, $entitytype }
Notice the missing ")" ?
That produce this not-quite-correct stack-trace:
org.webmacro.PropertyException: #parse com/coredocument/impl/ui/corepage/corelets/collectionBrowser/CollectionTreeElement.wm: Unable to get template
org.webmacro.ResourceException: Error parsing template com/coredocument/impl/ui/corepage/corelets/collectionBrowser/CollectionTreeElement.wm
org.webmacro.engine.BuildException: Error parsing template: FileTemplate:/data/devel/endre/new/coredoc/webapp/WEB-INF/classes/com/coredocument/impl/ui/corepage/corelets/collectionBrowser/CollectionTreeElement.wm
org.webmacro.engine.ParseException: Parser Exception
org.webmacro.parser.ParseException: No such directive #contentString at /data/devel/endre/new/coredoc/webapp/WEB-INF/classes/com/coredocument/impl/ui/corepage/corelets/helpers/Recurser.wm:53.2
at org.webmacro.directive.IncludeDirective.makePropertyException(IncludeDirective.java:536)
at org.webmacro.directive.IncludeDirective.getTemplate(IncludeDirective.java:465)
at org.webmacro.directive.IncludeDirective.getThingToInclude(IncludeDirective.java:433)
at org.webmacro.directive.IncludeDirective.write(IncludeDirective.java:354)
at org.webmacro.engine.Block.write(Block.java:135)
at org.webmacro.engine.WMTemplate.write(WMTemplate.java:262)
...
"no such directive".. well, it's a macro, goddamnit! And it's there!
Adding the missing ")" fixes everything.
--
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: <kea...@na...> - 2003-03-24 16:32:47
|
I think Lane's approach is probably the simplest solution for you -- just use two servlets and map one to *.wmt and the other to Ignition/* or whatever. The *.wmt servlet should probably just extend the Ignition/* servlet adding some logic to deal with the template name. Keats |
|
From: Lane S. <la...@op...> - 2003-03-23 00:31:30
|
Hi Marc,
I only parsed out some of your post.
I have a servlet that maps *.tml files. And, it tries to find the
template in the usual suspect places. I also have an action servlet to
handle posts of data. Here is my mapping.
<servlet-mapping url-pattern='/action/*'
servlet-name='action-servlet'/>
<servlet-mapping url-pattern='*.tml' servlet-name='template' />
If you want I can send you both servlets to take a look at. They are, of
course, supported by composition. Nothing really smart inside the
servlet per se.
-Lane
Marc Palmer wrote:
>
> Hi guys,
>
> I'd appreciate it if I could get a bit of input from anybody
> interested in this webapp I am writing which has the potential (if
> people agree) to become a core WM project.
>
> The issue I'm currently wrestling with is using a servlet mapping to
> tie the webapp's servlet to a file type, i.e.
> <servlet-mapping>*.wmt</servlet- mapping>, so that templates in the
> webapp root (not WEB-INF) can be returned without referencing the
> servlet name. i.e. a URI like:
>
> http://yourserver/wmwebapp/mypage.wmt
>
> (wmwebapp is the context path)
>
> Now I'm questioning how useful this is - because I have already
> implemented, because it is required, URIs of the form:
>
> http://yourserver/wmwebapp/ignition/mypage.wmt
>
> (where ignition is the name of the servlet mapping i.e. /ignition/*)
>
> ...with the difference that in this case the template comes from the
> normal template location mechanisms - i.e. from the classpath etc.
>
> There is also (nearly implemented) the ability to define "modules"
> which are segregated mini-apps (each has its own set of actions,
> helpers, templates etc) which means that you would not need to have
> all templates on the normal webapp classpath - the plan is that each
> module can have its own WebMacro.properties and therefore can use
> explicit template paths / alternative template provider schemes. A
> page served from a specific module would have a URI like:
>
> http://yourserver/wmwebapp/ignition/mymodule1/mypage.wmt
>
> Anything
> Now, back to the first scenario - templates served from the webapp
> root - if implemented - will have a couple of problems:
>
> 1. Where do they get their included templates from? A custom template
> provider could be used to load templates from the context root (not
> under WEB-INF) if not already supported by WM. It would seem odd to
> allow pages to be served from the context root but not allow them to
> be included from that location also.
>
> 2. Having templates in the context/webapp root is a security risk. The
> nature of this webapp is such that people will likely to a bit more
> than the usual MVC work in templates and as such sensitive info might
> be available in templates, and if the web.xml is fouled or the servlet
> container freaks out, it could return raw template files instead of
> processing them.
>
> 3. How do I know reliably how the servlet is being called? I need
> HttpServletRequest.getServletPath() to work so that I can
> automatically formulate correct URIs from my helper placed into the
> web context. Using a /ignition/* servlet mapping means this works -
> getServletPath returns things like "/ignition" and getPathInfo()
> returns the template requested i.e. "mymodule1/mypage.wmt". However if
> using a *.wmt servlet mapping, getServletPath returns
> "mymodule1/mypage.wmt" and getPathInfo returns null! Also
> getPathInfo() can return null under normal operation (/ignition/*
> mapping) if there is no template name as part of the URI (not forced
> by the webapp) - so I am not sure how I can tell whether the servlet
> was called as a result of a "/ignition/mymodule1" URI or a
> "/mywebappsubdir/mypage.wmt" URI, both of which would have null PathInfo.
>
> Basically I don't like the way this all feels so I am thinking of not
> supporting *.wmt mappings of the servlet, and using the module
> mechanism described throughout. We can of course change the web.xml so
> that we have slightly nicer URIs - i.e.
> http://myserver/ignition/execute/mymodule1/mypage.wmt - but even that
> is somewhat lengthy for me. If I use a /* mapping for the servlet then
> we stop people being able to efficiently serve resource files like
> images from the webapp.
>
> I suppose I can call getPathTranslated when using a *.wmt mapping and
> then call File.exists() on it to see if there is a resource with that
> name, and if so parse that and return it... and if not then I can try
> to see if I can pass a valid module out of it - but the same thing
> applies here... my helper object placed into the templates needs to
> know the base URI of the servlet (including context path) to produce
> URIs for the designer without them having to hardcode it. Currently it
> works like this:
>
> #set $action1 = $Ignition.newAction( "sendEmail")
> #set $action1.ToAddress = "ma...@an..."
> #set $action1.FromAddress = "server@localhost"
> #set $action1.BodyTemplate = "emailtemplate.wmt"
> #set $action2 = $Ignition.newAction( "viewTemplate")
> #set $action2.Template = "thankyouforemail.wmt"
>
> <a href="$Ignition.execute( [$action1, $action2])">Send the email</a>
>
> ...so you never deal with URIs or the syntax needed to munge and
> namespace the params for each action. Sorry probably very confusing
> all this because I haven't explained much about the webapp yet...
>
> I am very keen however that it is as easy as possible to return
> templated pages - I would love it to be as simple as
> http://myserver/ignition/myshop/mytemplate.wmt but I can't see how I
> can do that without using a "/*" mapping and all the performance
> problems with doing that if non-template files are also served from
> the app.
>
> Maybe I'm being dumb. Any ideas / encouragement welcome :-)
>
>
--
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
Java Software Portal: http://opendoors.com
|
|
From: Marc P. <ma...@an...> - 2003-03-22 13:17:44
|
On Fri, 21 Mar 2003 15:24:18 -0500, <kea...@na...> wrote: > Marc, > > I don't have a clear picture of what exactly you want or what the problem > is, but there are various ways to get the different parts of the Request > URL. For instance, > > HttpServletRequest.getRequestURI(): [snip] > or HttpUtil.getRequestURL(): Hehe, thanks for that Keats. Indeed they would make it possible but I'm trying to find a simple way that uses existing mechanisms rather than writing a whole bunch of parsing code to do it. The problem I was trying to get across is the different treatment that servlets get with respect to getPathInfo and getServletPath when you are using a servlet-mapping that is for file types rather than for a URI. It's very annoying. IMO getPathInfo should return the filename part of the URI (everything after context path) when a servlet is called for a file type servlet-mapping request. This would make it consistent with getPathInfo when using a URI servlet-mapping. That way you could just check if getServletPath() returns null and if so it means you've been called from a file type mapping, and if the servlet path is non-null it means it was a URI mapping. This is what I'm seeing with Tomcat 4 anyway. It's horrible. > By default templates can be loaded from the Webapp context root. This > could > be a security concern in some environments, as you've indicated, which is > why there are various ways to configure this. > > Probably the best way, imho, is to use the delegating template provider > to > restrict templates to a special template directory under WEB-INF. That sounds like a good idea. I need to catch up with the new Delegating template provider stuff. Thanks Marc -- Marc Palmer |
|
From: Tyler B. <tb...@bl...> - 2003-03-21 22:33:07
|
I'm on it... thanks Keats. At 04:45 PM 3/21/2003 -0500, kea...@na... wrote: >Tyler, > >Unfortunately, I don't think anybody's been keeping up with the Bugzilla >stuff, but you can learn about the whitespace issues from the Wiki page: > ><http://www.webmacro.org/WhiteSpace>http://www.webmacro.org/WhiteSpace > >I just highlighted the two issues that I'm aware of in red on the >page. They have to do with implicit #begin and #end block markers. > >Keats > > > -----Original Message----- > > From: Tyler Bye [<mailto:tb...@bl...>mailto:tb...@bl...] > > Sent: Friday, March 21, 2003 4:15 PM > > To: web...@li... > > Subject: [Webmacro-devel] Bug numbers corresponding to > > whitespace issues > > > > > > > > I figured this was better suited for the devel list. Are > > there any specific > > bug numbers in bugzilla for the whitespace issues or is this > > something I > > should research in the mailing list archives? > > > > Thanks, > > Tyler > > |
|
From: <kea...@na...> - 2003-03-21 21:53:37
|
Tyler, Unfortunately, I don't think anybody's been keeping up with the Bugzilla stuff, but you can learn about the whitespace issues from the Wiki page: http://www.webmacro.org/WhiteSpace I just highlighted the two issues that I'm aware of in red on the page. They have to do with implicit #begin and #end block markers. Keats > -----Original Message----- > From: Tyler Bye [mailto:tb...@bl...] > Sent: Friday, March 21, 2003 4:15 PM > To: web...@li... > Subject: [Webmacro-devel] Bug numbers corresponding to > whitespace issues > > > > I figured this was better suited for the devel list. Are > there any specific > bug numbers in bugzilla for the whitespace issues or is this > something I > should research in the mailing list archives? > > Thanks, > Tyler > |
|
From: Tyler B. <tb...@bl...> - 2003-03-21 21:15:34
|
I figured this was better suited for the devel list. Are there any specific bug numbers in bugzilla for the whitespace issues or is this something I should research in the mailing list archives? Thanks, Tyler |
|
From: <kea...@na...> - 2003-03-21 20:24:35
|
Marc, I don't have a clear picture of what exactly you want or what the problem is, but there are various ways to get the different parts of the Request URL. For instance, HttpServletRequest.getRequestURI(): http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpServ letRequest.html#getRequestURI() or HttpUtil.getRequestURL(): http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpUtil s.html#getRequestURL(javax.servlet.http.HttpServletRequest) By default templates can be loaded from the Webapp context root. This could be a security concern in some environments, as you've indicated, which is why there are various ways to configure this. Probably the best way, imho, is to use the delegating template provider to restrict templates to a special template directory under WEB-INF. Hope this helps. Keats > -----Original Message----- > From: Marc Palmer [mailto:ma...@an...] > Sent: Friday, March 21, 2003 1:06 PM > To: web...@li... > Subject: [Webmacro-devel] Input wanted! > > > > Hi guys, > > I'd appreciate it if I could get a bit of input from anybody > interested in > this webapp I am writing which has the potential (if people agree) to > become a core WM project. > > The issue I'm currently wrestling with is using a servlet > mapping to tie > the webapp's servlet to a file type, i.e. > <servlet-mapping>*.wmt</servlet- > mapping>, so that templates in the webapp root (not WEB-INF) can be > returned without referencing the servlet name. i.e. a URI like: > > http://yourserver/wmwebapp/mypage.wmt > > (wmwebapp is the context path) > > Now I'm questioning how useful this is - because I have already > implemented, because it is required, URIs of the form: > > http://yourserver/wmwebapp/ignition/mypage.wmt > > (where ignition is the name of the servlet mapping i.e. /ignition/*) > > ...with the difference that in this case the template comes > from the normal > template location mechanisms - i.e. from the classpath etc. > > There is also (nearly implemented) the ability to define > "modules" which > are segregated mini-apps (each has its own set of actions, helpers, > templates etc) which means that you would not need to have > all templates on > the normal webapp classpath - the plan is that each module > can have its own > WebMacro.properties and therefore can use explicit template paths / > alternative template provider schemes. A page served from a > specific module > would have a URI like: > > http://yourserver/wmwebapp/ignition/mymodule1/mypage.wmt > > Anything > Now, back to the first scenario - templates served from the > webapp root - > if implemented - will have a couple of problems: > > 1. Where do they get their included templates from? A custom template > provider could be used to load templates from the context > root (not under > WEB-INF) if not already supported by WM. It would seem odd to > allow pages > to be served from the context root but not allow them to be > included from > that location also. > > 2. Having templates in the context/webapp root is a security > risk. The > nature of this webapp is such that people will likely to a > bit more than > the usual MVC work in templates and as such sensitive info might be > available in templates, and if the web.xml is fouled or the servlet > container freaks out, it could return raw template files instead of > processing them. > > 3. How do I know reliably how the servlet is being called? I need > HttpServletRequest.getServletPath() to work so that I can > automatically > formulate correct URIs from my helper placed into the web > context. Using a > /ignition/* servlet mapping means this works - getServletPath returns > things like "/ignition" and getPathInfo() returns the > template requested > i.e. "mymodule1/mypage.wmt". However if using a *.wmt servlet > mapping, > getServletPath returns "mymodule1/mypage.wmt" and getPathInfo > returns null! > Also getPathInfo() can return null under normal operation > (/ignition/* > mapping) if there is no template name as part of the URI (not > forced by the > webapp) - so I am not sure how I can tell whether the servlet > was called as > a result of a "/ignition/mymodule1" URI or a > "/mywebappsubdir/mypage.wmt" > URI, both of which would have null PathInfo. > > Basically I don't like the way this all feels so I am thinking of not > supporting *.wmt mappings of the servlet, and using the > module mechanism > described throughout. We can of course change the web.xml so > that we have > slightly nicer URIs - i.e. > http://myserver/ignition/execute/mymodule1/mypage.wmt - but > even that is > somewhat lengthy for me. If I use a /* mapping for the > servlet then we stop > people being able to efficiently serve resource files like > images from the > webapp. > > I suppose I can call getPathTranslated when using a *.wmt > mapping and then > call File.exists() on it to see if there is a resource with > that name, and > if so parse that and return it... and if not then I can try > to see if I can > pass a valid module out of it - but the same thing applies here... my > helper object placed into the templates needs to know the > base URI of the > servlet (including context path) to produce URIs for the > designer without > them having to hardcode it. Currently it works like this: > > #set $action1 = $Ignition.newAction( "sendEmail") > #set $action1.ToAddress = "ma...@an..." > #set $action1.FromAddress = "server@localhost" > #set $action1.BodyTemplate = "emailtemplate.wmt" > #set $action2 = $Ignition.newAction( "viewTemplate") > #set $action2.Template = "thankyouforemail.wmt" > > <a href="$Ignition.execute( [$action1, $action2])">Send the email</a> > > ...so you never deal with URIs or the syntax needed to munge > and namespace > the params for each action. Sorry probably very confusing all > this because > I haven't explained much about the webapp yet... > > I am very keen however that it is as easy as possible to > return templated > pages - I would love it to be as simple as > http://myserver/ignition/myshop/mytemplate.wmt but I can't > see how I can do > that without using a "/*" mapping and all the performance > problems with > doing that if non-template files are also served from the app. > > Maybe I'm being dumb. Any ideas / encouragement welcome :-) > > > -- > Marc Palmer > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: Marc P. <ma...@an...> - 2003-03-21 18:10:06
|
Hi guys, I'd appreciate it if I could get a bit of input from anybody interested in this webapp I am writing which has the potential (if people agree) to become a core WM project. The issue I'm currently wrestling with is using a servlet mapping to tie the webapp's servlet to a file type, i.e. <servlet-mapping>*.wmt</servlet- mapping>, so that templates in the webapp root (not WEB-INF) can be returned without referencing the servlet name. i.e. a URI like: http://yourserver/wmwebapp/mypage.wmt (wmwebapp is the context path) Now I'm questioning how useful this is - because I have already implemented, because it is required, URIs of the form: http://yourserver/wmwebapp/ignition/mypage.wmt (where ignition is the name of the servlet mapping i.e. /ignition/*) ...with the difference that in this case the template comes from the normal template location mechanisms - i.e. from the classpath etc. There is also (nearly implemented) the ability to define "modules" which are segregated mini-apps (each has its own set of actions, helpers, templates etc) which means that you would not need to have all templates on the normal webapp classpath - the plan is that each module can have its own WebMacro.properties and therefore can use explicit template paths / alternative template provider schemes. A page served from a specific module would have a URI like: http://yourserver/wmwebapp/ignition/mymodule1/mypage.wmt Anything Now, back to the first scenario - templates served from the webapp root - if implemented - will have a couple of problems: 1. Where do they get their included templates from? A custom template provider could be used to load templates from the context root (not under WEB-INF) if not already supported by WM. It would seem odd to allow pages to be served from the context root but not allow them to be included from that location also. 2. Having templates in the context/webapp root is a security risk. The nature of this webapp is such that people will likely to a bit more than the usual MVC work in templates and as such sensitive info might be available in templates, and if the web.xml is fouled or the servlet container freaks out, it could return raw template files instead of processing them. 3. How do I know reliably how the servlet is being called? I need HttpServletRequest.getServletPath() to work so that I can automatically formulate correct URIs from my helper placed into the web context. Using a /ignition/* servlet mapping means this works - getServletPath returns things like "/ignition" and getPathInfo() returns the template requested i.e. "mymodule1/mypage.wmt". However if using a *.wmt servlet mapping, getServletPath returns "mymodule1/mypage.wmt" and getPathInfo returns null! Also getPathInfo() can return null under normal operation (/ignition/* mapping) if there is no template name as part of the URI (not forced by the webapp) - so I am not sure how I can tell whether the servlet was called as a result of a "/ignition/mymodule1" URI or a "/mywebappsubdir/mypage.wmt" URI, both of which would have null PathInfo. Basically I don't like the way this all feels so I am thinking of not supporting *.wmt mappings of the servlet, and using the module mechanism described throughout. We can of course change the web.xml so that we have slightly nicer URIs - i.e. http://myserver/ignition/execute/mymodule1/mypage.wmt - but even that is somewhat lengthy for me. If I use a /* mapping for the servlet then we stop people being able to efficiently serve resource files like images from the webapp. I suppose I can call getPathTranslated when using a *.wmt mapping and then call File.exists() on it to see if there is a resource with that name, and if so parse that and return it... and if not then I can try to see if I can pass a valid module out of it - but the same thing applies here... my helper object placed into the templates needs to know the base URI of the servlet (including context path) to produce URIs for the designer without them having to hardcode it. Currently it works like this: #set $action1 = $Ignition.newAction( "sendEmail") #set $action1.ToAddress = "ma...@an..." #set $action1.FromAddress = "server@localhost" #set $action1.BodyTemplate = "emailtemplate.wmt" #set $action2 = $Ignition.newAction( "viewTemplate") #set $action2.Template = "thankyouforemail.wmt" <a href="$Ignition.execute( [$action1, $action2])">Send the email</a> ...so you never deal with URIs or the syntax needed to munge and namespace the params for each action. Sorry probably very confusing all this because I haven't explained much about the webapp yet... I am very keen however that it is as easy as possible to return templated pages - I would love it to be as simple as http://myserver/ignition/myshop/mytemplate.wmt but I can't see how I can do that without using a "/*" mapping and all the performance problems with doing that if non-template files are also served from the app. Maybe I'm being dumb. Any ideas / encouragement welcome :-) -- Marc Palmer |
|
From: Marc P. <ma...@an...> - 2003-03-20 03:18:59
|
Hi all, I'm working against WM 1.1 final source, developing this WM "run and go" webapp currently codenamed "WebMacro Ignition". I've come across a funny. I can't -set-a property that has a binary accessor. A glance over the WM source for this (PropertyOperatorCache) has not enlightened me and the laptop I'm using is just toooo slow for interactive debug against Tomcat at the mo. Anyway, I'm getting this error in my template: Ignition encountered an error while executing a template: FileTemplate:C:\Program Files\Apache Group\Tomcat 4.1\webapps\ignition\WEB- INF\classes\index.wm: org.webmacro.PropertyException$NoSuchPropertyException: No public property Parameters on variable $action of class org.webmacro.ignition.api.action.ActionParams at C:\Program Files\Apache Group\Tomcat 4.1\webapps\ignition\WEB-INF\classes\index.wm:17.2 The part of the template causing offence is: #set $action.Parameters.Template = "itworked.wm" ...and $action is of type ActionParams which has the following methods: public void setParameters(String key, Object value) public String getParameters(String key) ... I know binary accessor "get" works as have used it elsewhere but this is the first time I've tried to "set" using it. Also, while binary accessor is certainly a convenience I'm starting to wonder whether it is a bit of an abomination. i.e. you cannot rewrite my previous bit of WM script as this: #set $params = $action.Parameters #set $params.Template = "itworked.wm" Well... you could if there was a "proxy" created to represent the virtual field "Parameters" internally in WM that handled this but it would be pretty nasty. Granted many web developers would not think of doing this, but it disturbs me that we can get ourselves into an inconsistent situation by using binary accessors. I think I may stop using them having realised this. $0.02 The webapp thing is coming along nicely though. I've got the meat of it done, and it's serving evaluated WM templates now. Doesn't sound like much but this is the tip of the iceberg, all the action mechanism stuff (including unlimited length action chains) is coded by not debugged. :-) I've also thrown in support for segregated "modules" where each module has its own WebMacro instance and therefore is separated from any others - i.e. a "WebMacro App Container" where you can deploy multiple webmacro "applications" without affecting any other code/templates. Best wishes, Marc -- Marc Palmer http://www.wangjammers.org |
|
From: Lane S. <la...@op...> - 2003-03-16 08:08:33
|
ebr,
a while back you made some changes to allow "#include as text...{arg}"
to work as "include as template {arg}" (i think it was to allow the use
of the classpath to address text templates.).
I think there is a case in which "#include as text..." is broken. An
"include as text..." inside a macro file where the arg contains a var.
It appears to be a regression. Here is the code inside a macro file:
#macro header($page) {
<html>
<head>
<link rel="stylesheet" type="text/css" href=/style.css>
<title>$page.title</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- Fireworks MX Dreamweaver MX target. Created Tue Jan 28 22:11:19
GMT-0800 (Pacific Standard Time) 2003-->
#include as text "$RootDir/template_includes/header.js" << this is where
the error msg points to.
</head>
}
error message:
[wmcontent] 11:52:33 PM IncludeDirective WARNING Included a
'static' file type using a dynamic filename. File will be included, but
any included #macro's will not at template_includes/sitemacros.wmm:11.2
does this help or am I missing something?
gracie,
--
Lane Sharman
Conga Spec Sheet: http://opendoors.com/conga/2.2/docs/CongaSpecSheet.pdf
Java Software Portal: http://opendoors.com
How I expended my youth: http://opendoors.com/lane.pdf
|
|
From: Lane S. <la...@op...> - 2003-03-16 07:45:34
|
I am running the latest cvs and using this before a commit of the relaxed builder stuff. Not much changed on my end. But, a run of the evaluator is now giving me this message: [wmcontent] 10:30:53 PM IncludeDirective WARNING Included a 'static' file type using a dynamic filename. File will be included, but any included #macro's will not at template_includes/sitemacros.wmm:11.2 Are there some changes you know of that would trigger this? -- Lane Sharman Conga Spec Sheet: http://opendoors.com/conga/2.2/docs/CongaSpecSheet.pdf Java Software Portal: http://opendoors.com How I expended my youth: http://opendoors.com/lane.pdf |
|
From: Lane S. <la...@op...> - 2003-03-07 19:08:31
|
Hi Dario,
I have done some work with macros. The design, which is robust, requires
you to include macros on a per file basis, not a per request basis. This
was explained to me by bg as following a common pattern and I have come
to adopt it but like you can imagine some alternatives. To include the
"standard" WM macro library, as in std.h, look at the docs and macros in
the distribution dir macros/. This model includes all macros in all
subdirectories and each macro in the varying subDirs get tested.
I liked a lot your example below which shows the power of #setblock as
macro {..}. I had never thought of passing a block like this into a
macro and using $body. Very cool.
-Lane
Dario Liberman wrote:
>RE: Passing a block to a macro?Hello all,
>
>Thanks again Keats, and also to Eric! :-)
>
>I tryed to pass a block to a macro and works fine.
>
>for example:
>
>#macro loop($body,$times) #begin
> #count $i from 1 to $times {
> $body
> }
>#end
>
>#set $piramid=""
>#setblock as macro $blk {
> #set $piramid="$piramid@"
> $piramid<BR>
>}
>
><CENTER>
>#loop($blk,7)
></CENTER>
>
>produces what expected:
> @
> @@
>@@@
>...
>
>
>And althought it is true that a directive can be made writing java code,
>what am I saying is that defining macros with body is much easier. So
>wrinting only one directive, say #macrowithbody or #nestedmacro we have a
>kind of directive-alike macro creation directive.
>
>So I would have a special variable inside the macro definition (that can be
>configured, like the counter variable).
>So the above code would look like:
>
>#macrowithbody loop($times) #begin
> #count $i from 1 to $times {
> $body
> }
>#end
>
><CENTER>
>#set $piramid=""
>#loop(7) {
> #set $piramid="$piramid@"
> $piramid<BR>
>}
></CENTER>
>
>which in my opinion is much intuitive.
>
>I will anyway see the directive programming tutorial, seems pretty
>interesting. Thank you!
>
>Regarding macro includes:
>
>my main WMs go like this:
>
>#Include as macro "header.wmi"
>wm code and html
>some includes in the main body of the wm may appear.
>#Include "footer.wmi"
>
>So, what I did is to include de macros in the header, and include the header
>as a macro too, dispite it is mixed (macros and normal code). This enables
>macros at the main body of the wm automatically. But the included wms inside
>it, need to include the macro again. So it seems it is not a per request
>include (the macro definition) but a per file include in order for the
>compiler/parser to know exactly what code gets expanded per file.
>perhaps if there was a way to make a late bound of the included wmi
>(on-the-fly parsing) it would not be needed to include the macros in each
>file... but to me, it seems much better to have a configuration option to
>include macros globally. Which for sure would give performance enhancement.
>
>Cheers!
>
>Dario.
>
>
>----- Original Message -----
>From: kea...@na...
>To: lib...@in... ; web...@li...
>Sent: Wednesday, March 05, 2003 19:36
>Subject: [Webmacro-devel] RE: Passing a block to a macro?
>
>
>Dario,
>I'm not the macro expert, so someone else should probably chime in. I'm
>pretty sure you only need to declare your macro once per context (i.e.,
>request). Using an #include is probably the preferred way. There has been
>discussion of implementing global macros, but this is still in the
>discussion stage.
>You are correct that you cannot directly use a block as an argument to a
>macro call. (Your #setblock work-around is right on.) You might want to
>consider changing your macro to a directive, which would allow you to use a
>block. E.g.,
>#xsltranform stylesheet="/myFile.xsl" {
> <xmltag name="hello" value="$myvar"/>
>}
>This could make a pretty cool addition to WM. Directives aren't really too
>hard to create. See http://www.webmacro.org/PluggableDirectiveMechanism and
>look at the source for some simple directives.
>Hope this helps.
>Keats
>
>
>-----Original Message-----
>From: Dario Liberman [mailto:lib...@in...]
>Sent: Wednesday, March 05, 2003 2:26 PM
>To: kea...@na...; web...@li...
>Subject: Re: [Webmacro-devel] special characters - now slash directory
>separator problem
>
>
>Keats, Thank you very very much.
>By the way... I am using macros now :-)
>I am supposed to include the macro file in all my files???
>Also, including it in the main wm, does not heredate it to its internal
>included files. So it seems that not only the main wms, but really all wms
>need the macro include statement, right?
>It would be nice to have it included in my configuration file or something
>for global access.
>Also, is there any way to make a macro with body?
>by now, instead of for example doing:
>#ApplyXSL ("http://myfile.xsl") {
> <xmltag name="hello" value="$myvar"/>
>}
>I am doing this:
>#setblock as macro $thebodyblk {
> <xmltag name="hello" value="$myvar"/>
>}
>#ApplyXSL ("/myfile.xsl", $thebodyblk)
>The first sintax is much nicer I beleave. There shoud be a directive that
>creates a macro with body, say.. #macrowb
>the people at freemarker, I think use the word "nested" to refer to the
>bodyblock during the macro definition.
>
>
>When I finish this ApplyXSL tool (I hope to have the time to do it), I will
>expose it to the list, maybe someone likes it.
>Cheers,
>Dario.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
>for complex code. Debugging C/C++ programs can leave you feeling lost and
>disoriented. TotalView can help you find your way. Available on major UNIX
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
--
Lane Sharman
Conga Spec Sheet: http://opendoors.com/conga/2.2/docs/CongaSpecSheet.pdf
Java Software Portal: http://opendoors.com
How I expended my youth: http://opendoors.com/lane.pdf
|
|
From: Dario L. <lib...@in...> - 2003-03-07 16:29:55
|
RE: Passing a block to a macro?Hello all,
Thanks again Keats, and also to Eric! :-)
I tryed to pass a block to a macro and works fine.
for example:
#macro loop($body,$times) #begin
#count $i from 1 to $times {
$body
}
#end
#set $piramid=""
#setblock as macro $blk {
#set $piramid="$piramid@"
$piramid<BR>
}
<CENTER>
#loop($blk,7)
</CENTER>
produces what expected:
@
@@
@@@
...
And althought it is true that a directive can be made writing java code,
what am I saying is that defining macros with body is much easier. So
wrinting only one directive, say #macrowithbody or #nestedmacro we have a
kind of directive-alike macro creation directive.
So I would have a special variable inside the macro definition (that can be
configured, like the counter variable).
So the above code would look like:
#macrowithbody loop($times) #begin
#count $i from 1 to $times {
$body
}
#end
<CENTER>
#set $piramid=""
#loop(7) {
#set $piramid="$piramid@"
$piramid<BR>
}
</CENTER>
which in my opinion is much intuitive.
I will anyway see the directive programming tutorial, seems pretty
interesting. Thank you!
Regarding macro includes:
my main WMs go like this:
#Include as macro "header.wmi"
wm code and html
some includes in the main body of the wm may appear.
#Include "footer.wmi"
So, what I did is to include de macros in the header, and include the header
as a macro too, dispite it is mixed (macros and normal code). This enables
macros at the main body of the wm automatically. But the included wms inside
it, need to include the macro again. So it seems it is not a per request
include (the macro definition) but a per file include in order for the
compiler/parser to know exactly what code gets expanded per file.
perhaps if there was a way to make a late bound of the included wmi
(on-the-fly parsing) it would not be needed to include the macros in each
file... but to me, it seems much better to have a configuration option to
include macros globally. Which for sure would give performance enhancement.
Cheers!
Dario.
----- Original Message -----
From: kea...@na...
To: lib...@in... ; web...@li...
Sent: Wednesday, March 05, 2003 19:36
Subject: [Webmacro-devel] RE: Passing a block to a macro?
Dario,
I'm not the macro expert, so someone else should probably chime in. I'm
pretty sure you only need to declare your macro once per context (i.e.,
request). Using an #include is probably the preferred way. There has been
discussion of implementing global macros, but this is still in the
discussion stage.
You are correct that you cannot directly use a block as an argument to a
macro call. (Your #setblock work-around is right on.) You might want to
consider changing your macro to a directive, which would allow you to use a
block. E.g.,
#xsltranform stylesheet="/myFile.xsl" {
<xmltag name="hello" value="$myvar"/>
}
This could make a pretty cool addition to WM. Directives aren't really too
hard to create. See http://www.webmacro.org/PluggableDirectiveMechanism and
look at the source for some simple directives.
Hope this helps.
Keats
-----Original Message-----
From: Dario Liberman [mailto:lib...@in...]
Sent: Wednesday, March 05, 2003 2:26 PM
To: kea...@na...; web...@li...
Subject: Re: [Webmacro-devel] special characters - now slash directory
separator problem
Keats, Thank you very very much.
By the way... I am using macros now :-)
I am supposed to include the macro file in all my files???
Also, including it in the main wm, does not heredate it to its internal
included files. So it seems that not only the main wms, but really all wms
need the macro include statement, right?
It would be nice to have it included in my configuration file or something
for global access.
Also, is there any way to make a macro with body?
by now, instead of for example doing:
#ApplyXSL ("http://myfile.xsl") {
<xmltag name="hello" value="$myvar"/>
}
I am doing this:
#setblock as macro $thebodyblk {
<xmltag name="hello" value="$myvar"/>
}
#ApplyXSL ("/myfile.xsl", $thebodyblk)
The first sintax is much nicer I beleave. There shoud be a directive that
creates a macro with body, say.. #macrowb
the people at freemarker, I think use the word "nested" to refer to the
bodyblock during the macro definition.
When I finish this ApplyXSL tool (I hope to have the time to do it), I will
expose it to the list, maybe someone likes it.
Cheers,
Dario.
|
237 messages has been excluded from this view by a project administrator.
