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: Marc P. <ma...@an...> - 2003-06-16 08:25:29
|
On Mon, 16 Jun 2003 08:33:28 +0100, Marc Palmer <ma...@an...> wrote: > Now this is quite an interesting idea that I quite like, having felt > quite strongly about this in the past. For example, we've all done this: Quite, quite, quite. Sorry it was early and strangely obsessed with the word "quite". -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-16 07:35:20
|
On Mon, 16 Jun 2003 00:25:17 -0400, Harmeet Bedi <ha...@ko...> wrote: > - Precompiled/Optimized templates: A mode to generate java code and > classes > from wm files would be good. One example is jython. It is interpretted, > there can be a pool of interpretters to execute code but it has a tool to > generate java source and class files. I would like to use WM like > precompiled JSP files and not put wm source code on production server. I > would also like to profile these end precompiled templates and see if > there > are any bottlenecks. For instance if a precompiled template does not have > any shared state and no need to reload, should ideally have no > synchronized > calls. Like Brian I think this is a bad idea. Generating (or compiling) code is not a good plan for template-based scripting. It complicates things and you just have to do almost exactly the same things - iterate over the syntax tree etc. You might benefit from some compile-time optimisations but like Brian I doubt it would be significant. > - Sandbox. I realize that WM templates depends only on model, but it > would > be nice to make the view as tight as possible, for instance if I need to > exposed, HttpServerletRequest object to WM, would it be better to instead > expose a ServletRequest Object inside a wrapper and allow server > administrator to control what can or cannot be invoked. Some support for > sandoxing say by automatically creating proxies and tying permissions to > user roles may be helpful. I don't have any concrete ideas but if you > could > keep security/safety as you add more features that would be awesome. Now this is quite an interesting idea that I quite like, having felt quite strongly about this in the past. For example, we've all done this: context.put( "myVar", myHashtable); Even though the data in the Hashtable should be immutable. Sure there's Collections.unmodifiableMap(myHashtable) but it's still ugly. There's also the problem of providing runtime help information for template writers, tackled to a large degree by my Ignition webapp. We could solve both of these problems in one go, very simply: * Add an option to WM for "StrictJavaClasses" mode. (and "StrictJavaClassesExcludes=") * Add a flagging interface called something like WMScriptSafe When "StrictJavaClasses" is true, WM would throw an exception if any object is put into the context that does not implement the (empty) interface WMScriptSafe. This immediately forces the programmer to realise that they need to make a decision about what they are doing. It stops HttpServletRequest being put in but allows WMSafeHttpServletRequest being put in, which would expose only certain properties etc. In addition to this, WM could provide a mechanism to show introspected help information about any objects placed into the context (#help ?) that implemenet WMScriptSafe, looking for the BeanInfo of the script-safe object - i.e. WMSafeHttpServletRequestBeanInfo. By having the flagging interface we are forcing people to implement a new class that wraps non-safe classes, therefore giving them the ability to implement a BeanInfo object that can provide documentation that WM template writers can understand - instead of any existing "Java programmer" BeanInfo provided on the original bean. Granted, not that many people use BeanInfo, but it's an under-used facility if you ask me. We use it to great effect in Ignition. Take any existing Bean and you can use it as a helper in WM, and if the Bean has a BeanInfo impl, you get to see all the help info about it. No special interfaces to implement. > - Safe. Loops and cyclic loops can be written in JSP. With webmacro it is > very hard. I use 1.0 with constraints on include directive to control > looping( I only allow templates in subfolders and no url include). WM > Templates should not be able to bring server down, either by intent or by > coding error. Of course this does depend on exposed model, but if model > is > safe, templates should be safe too. I think this can be done by making > some > changes to tools in 1.0 and Include directive. In later versions my > impression was that macros can cause loops. If this is true, from safety > perspective it may not be a step forward. I don't see how #include can bring the server down. You get a StackOverflowError before the server comes down. Same with infinite loops. Recursive #include or #templet (when we get that) would have the same outcome, a stack overflow which just kills the current page render, not the whole container. It is possible to create infinite loops in WM but not using WMScript. You could for example add a context variable that is an Iterator, which is badly implemented and continuously returns the same element, never stopping. There's nothing we can do about that. Best wishes, Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Brian G. <br...@qu...> - 2003-06-16 06:42:35
|
> - Precompiled/Optimized templates: A mode to generate java code and classes > from wm files would be good. Why? For performance, or for another reason? If its for performance, I'd point out that this is one of those things that everything thinks is very cool, but so far I've not seen anyone present any evidence that compiling to java code / bytecode would provide a meaningful performance improvement. (I have some doubts that this would really make a difference.) In fact, I've not seen any credible evidence that WM has any significant performance problems at all, other than a few very poorly chosen tuning parameters. Have you actually experienced a performnace problem with WM, and do you have any evidence that the problem is in page execution, or are you just assuming there's a big win to be had here? Parsing templates is slow, but since templates are cached, the amortized overhead is small. > One example is jython. It is interpretted, there can be a pool of > interpretters to execute code but it has a tool to generate java > source and class files. I would like to use WM like precompiled JSP > files and not put wm source code on production server. WM compiles templates into an object representation that could easily be made serializable and loaded without generating any bytecode. If your concern is source code, this is a far simpler solution. And loading in template classes and executing them has far more security risks than exposing template source code -- a WM template can't do all that much evil, but arbitrary bytecode could do anything. > I > would also like to profile these end precompiled templates and see if there > are any bottlenecks. For instance if a precompiled template does not have > any shared state and no need to reload, should ideally have no synchronized > calls. Again, do you have any grounds for suspecting that WM has performance problems, or is this just a "its interpreted, so it must be slow" thing? > - Throttling. Would be cool to have a way to monitor long running threads > and maybe reduce priority or kill those threads. A threshold time check and > unchecked error if limit is reached may be one way I could think of. WM doesn't create its threads, it uses the threads given it by the environment (such as the servlet container.) Pruning these is the container's job. |
|
From: Harmeet B. <ha...@ko...> - 2003-06-16 04:25:55
|
----- Original Message ----- From: "Eric B. Ridge" <eb...@tc...> > > Well, from a user perspective, what things do you think are necessary > for WM 2.0? Sorry about the huge delay in respone but here goes. - Precompiled/Optimized templates: A mode to generate java code and classes from wm files would be good. One example is jython. It is interpretted, there can be a pool of interpretters to execute code but it has a tool to generate java source and class files. I would like to use WM like precompiled JSP files and not put wm source code on production server. I would also like to profile these end precompiled templates and see if there are any bottlenecks. For instance if a precompiled template does not have any shared state and no need to reload, should ideally have no synchronized calls. - Sandbox. I realize that WM templates depends only on model, but it would be nice to make the view as tight as possible, for instance if I need to exposed, HttpServerletRequest object to WM, would it be better to instead expose a ServletRequest Object inside a wrapper and allow server administrator to control what can or cannot be invoked. Some support for sandoxing say by automatically creating proxies and tying permissions to user roles may be helpful. I don't have any concrete ideas but if you could keep security/safety as you add more features that would be awesome. - Safe. Loops and cyclic loops can be written in JSP. With webmacro it is very hard. I use 1.0 with constraints on include directive to control looping( I only allow templates in subfolders and no url include). WM Templates should not be able to bring server down, either by intent or by coding error. Of course this does depend on exposed model, but if model is safe, templates should be safe too. I think this can be done by making some changes to tools in 1.0 and Include directive. In later versions my impression was that macros can cause loops. If this is true, from safety perspective it may not be a step forward. - Throttling. Would be cool to have a way to monitor long running threads and maybe reduce priority or kill those threads. A threshold time check and unchecked error if limit is reached may be one way I could think of. - Powerful but documented. For a lot users security and safety may be less important. If you do decide to add powerful features, please do document and make it possible to disable features that could cause security/safety issues. thanks, Harmeet |
|
From: Keats <ke...@su...> - 2003-06-16 03:01:28
|
I also toyed with this notion at one point, and also realized that it wasn't practical. Taglibs depend on too much JSP plumbing. Too bad cause there are tons of them out there, and it's a shame to have to rebuild this stuff for WM. It would probably be pretty easy to go the other way ... make a WM taglib so you could embed WMScript inside of JSP pages. Could be a way to sneak WM into JSP shops. Keats Marc Palmer wrote: > On Sat, 14 Jun 2003 19:18:44 +0100, Marc Palmer <ma...@an...> wrote: > >> >> Guys, >> >> Is anyone here had the misfortune to do much JSP development? >> >> If so, do you think that it would be possible for us to build a JSP >> Taglib - >> >>> WM context vars/directives bridge so that we can lure people away from >> >> JSP into WM much more easily? > > > Ugh having looked at some JSP docs some more I'm thinking this is > probably not going to be productive. > > However I do think someone who has real JSP knowledge should write a > Wiki page "MovingFromJSP" showing how to do the various JSP-style things > in WM and why each is better in WM (i.e. #bean for "useBean", #include > for "include" and so on), with some discussion on why the functionality > of #bean might be handled better in a different way etc. > > |
|
From: Marc P. <ma...@an...> - 2003-06-14 22:26:46
|
I propose that we move the version history stuff out of the DownloadWebMacro page into a ReleaseHistory page. Any disagreements? I will do it if nobody disagrees. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-14 22:26:45
|
On Sat, 14 Jun 2003 19:18:44 +0100, Marc Palmer <ma...@an...> wrote: > > Guys, > > Is anyone here had the misfortune to do much JSP development? > > If so, do you think that it would be possible for us to build a JSP > Taglib - >> WM context vars/directives bridge so that we can lure people away from > JSP into WM much more easily? Ugh having looked at some JSP docs some more I'm thinking this is probably not going to be productive. However I do think someone who has real JSP knowledge should write a Wiki page "MovingFromJSP" showing how to do the various JSP-style things in WM and why each is better in WM (i.e. #bean for "useBean", #include for "include" and so on), with some discussion on why the functionality of #bean might be handled better in a different way etc. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-14 18:20:31
|
Guys, Is anyone here had the misfortune to do much JSP development? If so, do you think that it would be possible for us to build a JSP Taglib - > WM context vars/directives bridge so that we can lure people away from JSP into WM much more easily? Just a thought. Looking at the JSPWiki stuff Keats mentioned on webmacro- user and it's "tied" to JSP but wondering how much work it would be to provide a WM front end to it. I only say this because JSPWiki has some really nice features like file attachments (i.e. file upload) and non CamelCase linking etc. and I know Eric doesn't have the time to do all that for WM's Wiki. I just want to run a wiki without setup hell, without building, and with support for non CamelCase links :( Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-14 17:55:31
|
Opera has "lost" my wm-dev mailing list and am just seeing if this will bring it back or if I'm missing mails now... -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-13 18:56:22
|
[Keats - don't download all again - I will mail you just the new files, much smaller] Hi, I just fixed a couple of things: 1. The content-type problem for static files (API docs) under non-type- guessing browsers (i.e. Mozilla/Netscape) 2. The Visitor code not working properly for the Visitor "colour" setting demo. A bit of code required there. The new version is in the same place as the old - http://www.wangjammers.org/ignition The "colour" demo is more "impressive" now. Please have a look at Ignition if you can over the weekend. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-13 18:45:49
|
On Fri, 13 Jun 2003 13:36:55 -0400, Eric B. Ridge <eb...@tc...> wrote: >> Hmmm. Is there a nice way to get the default content-type for a file >> extension from the Servlet API. I don't think there is... :( > > Yes, there is, from within your servlet: > this.getServletContext().getMimeType(strFilename) > > However, I think strFilename needs to be in your document root somewhere. Thanks for that Eric. Fixed. By their nature these files always exist in doc root anyway, but I don't think the API cares. Cheers -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Keats <ke...@ea...> - 2003-06-13 17:48:55
|
> I think this means you haven't installed the demos as a module. It > definitely works fine here from a clean install. Remember you must unzip > the demos and then edit WEB-INF/classes/ignition.properties to add the > line: > > module.demos=ignition-demos.properties This did the trick! Thanks. Keats |
|
From: Eric B. R. <eb...@tc...> - 2003-06-13 17:40:39
|
On Friday, June 13, 2003, at 01:16 PM, Brian Goetz wrote: >> This sounds good to me, but we should monitor the performance to see >> if it really doesn't degrade. After all, we don't add optimisations >> without knowing they are really necessary, so we shouldn't take them >> away unless we know they are unnecessary :-) > > In other words, lets back out the premature optimizations and then > figure out where we need to go with performance. Can you give some examples of "premature optimizations"? eric |
|
From: Eric B. R. <eb...@tc...> - 2003-06-13 17:37:03
|
On Friday, June 13, 2003, at 01:10 PM, Marc Palmer wrote: > On Fri, 13 Jun 2003 12:09:21 -0400, Keats <ke...@ea...> wrote: > >> Also the JavaDocs show as plain text in Mozilla. This must be a >> Tomcat >> thing, cause they look fine if I open them directly from the file >> system. > > Duh. Of course. I'm serving non-WM content too (i.e. the API docs) and > not setting content-type. > > Hmmm. Is there a nice way to get the default content-type for a file > extension from the Servlet API. I don't think there is... :( Yes, there is, from within your servlet: this.getServletContext().getMimeType(strFilename) However, I think strFilename needs to be in your document root somewhere. eric > > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > http://www.wangjammers.org > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Eric B. R. <eb...@tc...> - 2003-06-13 17:35:22
|
On Friday, June 13, 2003, at 01:06 PM, Brian Goetz wrote: >> I thought this too, until Sebastian told me about: >> >> http://www.webmacro.org/DelegatingTemplateProvider >> >> It didn't show up in searches for "delegating" though. I added some >> keywords, and linked to it from the TemplatePath/wm properties page. > > Eric, are you using Lucene for searching the Wiki? If so, a trick which > makes this work pretty easily is to replace the Analyzer with one that > breaks up SmooshedTogetherWords, so I was just thinking that actually. I also need to figure out how to remove pages from the index. eric > > FooBarBaz > > gets tokenized as > > FooBarBaz Foo Bar Baz > > We did this in a recent Lucene project and it worked like a charm. > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Marc P. <ma...@an...> - 2003-06-13 17:24:25
|
On Fri, 13 Jun 2003 10:16:15 -0700, Brian Goetz <br...@qu...> wrote: [snip] > The reality is that modern JVMs do best on clean code that use common > usage patterns, and most attempts to "help" the JIT or GC, while they > might have been effective at the time, end up being counterproductive. > > In other words, lets back out the premature optimizations and then > figure out where we need to go with performance. OK. Can you give me an idea of the kind of things you want to remove? I might be doing some of them in my own code :) Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Brian G. <br...@qu...> - 2003-06-13 17:16:28
|
> This sounds good to me, but we should monitor the performance to see > if it really doesn't degrade. After all, we don't add optimisations > without knowing they are really necessary, so we shouldn't take them > away unless we know they are unnecessary :-) Truly excellent, useful, and widely applicable advice. I'd pushed for this for quite a while earlier, but we never came up with a good performance test harness. Anyway, in this case, I am inclined to summarily ignore this advice. I know for a fact that most of these optimizations are not actually optimizations. Many of them actually will make the code perform much worse, because they inhibit optimizations that can be done by more modern JITs and interface with the proper operation of generational garbage collection. Further, none of them were motivated by an actual need for optimization as determined by performance goals and demonstrated by performance measurement; they are almost all in the category of "premature optimization". And, they're nasty, crufty code, which can be better replaced by known-to-be-good-and-fast existing tools. The reality is that modern JVMs do best on clean code that use common usage patterns, and most attempts to "help" the JIT or GC, while they might have been effective at the time, end up being counterproductive. In other words, lets back out the premature optimizations and then figure out where we need to go with performance. |
|
From: Marc P. <ma...@an...> - 2003-06-13 17:11:58
|
On Fri, 13 Jun 2003 12:09:21 -0400, Keats <ke...@ea...> wrote: > Also the JavaDocs show as plain text in Mozilla. This must be a Tomcat > thing, cause they look fine if I open them directly from the file system. Duh. Of course. I'm serving non-WM content too (i.e. the API docs) and not setting content-type. Hmmm. Is there a nice way to get the default content-type for a file extension from the Servlet API. I don't think there is... :( -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-13 17:09:53
|
On Fri, 13 Jun 2003 08:58:04 -0700, Brian Goetz <br...@qu...> wrote: > One of the things I want to do for 2.0 is to get rid of all of the > performance hacks that were introduced in the early days. They might > or might not have been helpful then, but they are almost certainly > counterproductive now. This will probably get rid of a lot of code. > > Now, I know we've existed thus far without any JAR dependencies, but > one JAR we really should be using is Doug Lea's util.concurrent > library, which contains some excellent building blocks for concurrent > apps. This sounds good to me, but we should monitor the performance to see if it really doesn't degrade. After all, we don't add optimisations without knowing they are really necessary, so we shouldn't take them away unless we know they are unnecessary :-) -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-06-13 17:07:53
|
On Fri, 13 Jun 2003 12:09:21 -0400, Keats <ke...@ea...> wrote: > Kudos! > > I downloaded and installed the ignition and I think it looks *great*. I > haven't had time to put it through it's paces, but I like it so far. > > The demos/rss/showRSS.wmt template seems to be missing. (But this > allowed > me to see the "baby of consolation" so it's not all bad.) I think this means you haven't installed the demos as a module. It definitely works fine here from a clean install. Remember you must unzip the demos and then edit WEB-INF/classes/ignition.properties to add the line: module.demos=ignition-demos.properties Because the demo templates install under the ignition webapp dir, you can still access the templates if you fail to install the module, but not everything will work. If you look at ignition-demos.properties you will see it adds a template path entry pointing to a common shared area, webapp:/tools where rss/showRSS.wmt does exist. This is probably not happening for you due to the above config snafu - I'm guessing. > Also the JavaDocs show as plain text in Mozilla. This must be a Tomcat > thing, cause they look fine if I open them directly from the file system. Er... that is very weird. Happens here on Netscape 7 too. However this does not happen in Opera 7, IE 6 or IE5 and that is just static content so... Mozilla bug surely? Does this mean the web.xml should be adding a "custom" mime type for .html? Very strange. It must be that the Content-Type is not being set for some reason. Shouldn't Tomcat webapps use the default app mime mappings supplied with Tomcat? I hope to fix the Visitor data storage (the "colour" setting) problem tonight and make a new build available, time permitting. Marc -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Brian G. <br...@qu...> - 2003-06-13 17:06:35
|
> I thought this too, until Sebastian told me about: > > http://www.webmacro.org/DelegatingTemplateProvider > > It didn't show up in searches for "delegating" though. I added some > keywords, and linked to it from the TemplatePath/wm properties page. Eric, are you using Lucene for searching the Wiki? If so, a trick which makes this work pretty easily is to replace the Analyzer with one that breaks up SmooshedTogetherWords, so FooBarBaz gets tokenized as FooBarBaz Foo Bar Baz We did this in a recent Lucene project and it worked like a charm. |
|
From: Marc P. <ma...@an...> - 2003-06-13 16:59:24
|
On Fri, 13 Jun 2003 11:51:02 -0400, Keats <ke...@ea...> wrote: > ----- Original Message ----- >> I'd like to propose using Sebastian's DelegatingTemplateProvider as the >> default template provider in WM 2.0. > > We agreed to do this a while ago. I think all we need are some docs on > how > to configure it ... hint, hint. I thought this too, until Sebastian told me about: http://www.webmacro.org/DelegatingTemplateProvider It didn't show up in searches for "delegating" though. I added some keywords, and linked to it from the TemplatePath/wm properties page. Cheers -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: <ska...@di...> - 2003-06-13 16:46:12
|
Hi, On Fri, Jun 13, 2003 at 11:51:02AM -0400, Keats wrote: > ----- Original Message ----- > > I'd like to propose using Sebastian's DelegatingTemplateProvider as the > > default template provider in WM 2.0. > > We agreed to do this a while ago. I think all we need are some docs on how > to configure it ... hint, hint. well, there exists some documentation at www.webmacro.org/DelegatingTemplateProvider that should be fairly complete. Regarding changing paths at runtime: I did not include this functionality immediately, because it would require further synchronization. However, I could create a special TemplateLoader, that allows paths to be changed and pays for this by doing some more synchronization. Sebastian |
|
From: Keats <ke...@ea...> - 2003-06-13 16:09:47
|
Kudos! I downloaded and installed the ignition and I think it looks *great*. I haven't had time to put it through it's paces, but I like it so far. The demos/rss/showRSS.wmt template seems to be missing. (But this allowed me to see the "baby of consolation" so it's not all bad.) Also the JavaDocs show as plain text in Mozilla. This must be a Tomcat thing, cause they look fine if I open them directly from the file system. Keats ----- Original Message ----- From: "Marc Palmer" <ma...@an...> To: <web...@li...> Sent: Friday, June 13, 2003 7:13 AM Subject: Re: [Webmacro-devel] FINALLY! Ignition alpha 1 for download... > On Fri, 13 Jun 2003 01:19:15 +0100, Marc Palmer <ma...@an...> wrote: > > > > > Hi all, > > > > Once again it took longer than I hoped, but that's life! > > > > Finally I am pleased to announce that you can download (WebMacro?) > > Ignition 1.0 Alpha 1 from: > > > > http://www.wangjammers.org/ignition > > > > I fully realise that it is now Friday 13th. I'm sure this will not go > > smoothly... > > Well there you go. Found a "bug". Missing a "get" method on Visitor > variable, so the Visitor demo does not display the existing colour you have > stored when you return to the site. Just a template var issue. > > Will fix it today, ready for the next release. > > Marc > > -- > Marc Palmer > Contract Java Consultant/Developer > > http://www.anyware.co.uk/marc/ > http://www.wangjammers.org > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Brian G. <br...@qu...> - 2003-06-13 15:58:15
|
One of the things I want to do for 2.0 is to get rid of all of the performance hacks that were introduced in the early days. They might or might not have been helpful then, but they are almost certainly counterproductive now. This will probably get rid of a lot of code. Now, I know we've existed thus far without any JAR dependencies, but one JAR we really should be using is Doug Lea's util.concurrent library, which contains some excellent building blocks for concurrent apps. |
237 messages has been excluded from this view by a project administrator.
