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-01-31 23:28:48
|
On Fri, 31 Jan 2003 15:27:20 -0500, Eric B. Ridge <eb...@tc...> wrote: > On Friday, January 31, 2003, at 12:13 PM, Brian Goetz wrote: > >> I think the real issue is that WM is lacking any sort of framework for >> easily starting only the parts you need. > > Is this something we should try to do for 1.2 (or whatever we call it)? > Well I definitely think so - but it should/would involve an overhaul of the Broker which I have mentioned previously but was balked at due to the wideranging changes this would require. Basically, I was looking at how I could replace WM's Broker with our GOBS generic broker framework. It's not possible at the moment, but it would be nice if it was. It would make a lot of neat things possible and greatly enhance decoupling in WM, which to me doesn't look as decoupled as it could be. If your interest is piqued, please view http://www.wangjammers.org/gobs and read the "crash course" document I wrote. It's all very simple - trivial almost - but with hidden power. Even if WM never uses GOBS, it might prove an interesting read to see the approach we've taken - because it's a bit more than a Map of services. Basically I "resent" the fact that the way WM gets its component instances (template providers etc.) is "hardcoded" and incompatible with other broker/service frameworks. It should be possible to integrate WM with other service frameworks, such as OSGi. However using a more powerful generalised broker in WM means that code that uses WM (and context tools etc.) have more options in terms of how they communicate with other components of the application. </rant> Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Eric B. R. <eb...@tc...> - 2003-01-31 20:30:14
|
On Friday, January 31, 2003, at 12:13 PM, Brian Goetz wrote:
> I think the real issue is that WM is lacking any sort of framework for
> easily starting only the parts you need.
Is this something we should try to do for 1.2 (or whatever we call it)?
My initial thought is to make some of these things more configurable,
then provide a few different WebMacro.defaults files. Maybe:
WebMacro-servlet.defaults
WebMacro-standalone.defaults
WebMacro-lightweight.defaults (minimal #directives and $functions())
eric
|
|
From: Brian G. <br...@qu...> - 2003-01-31 17:14:29
|
> IMHO, I think that WM shouldn't fire up _any_ threads w/o being asked. The problem here is that WM is many things to many people. Some use it as a servlet-based templating service. In this context, it is entirely reasonable for it to use threads (although marking them as daemon threads would be polite.) Some people use it strictly for its formatting capabilities -- in this case, a lighter-weight means of invoking it (no caching, no threads, etc) makes more sense. But in the context of something that's going to live in a servlet engine, a "no threads" rule is kind of silly. That's almost as arbitrary as saying "no inner classes." Individual threads are just not that expensive. If it turns out to be more efficient to have a housekeeping thread or two, there's nothing wrong with that. I think the real issue is that WM is lacking any sort of framework for easily starting only the parts you need. |
|
From: Eric B. R. <eb...@tc...> - 2003-01-31 16:58:47
|
On Friday, January 31, 2003, at 07:57 AM, Endre St=F8lsvik wrote: > On Wed, 29 Jan 2003, Brian Goetz wrote: > > | > | >I remember this as well. I think it was Brian who pointed out that=20= > using > | >the System.currentTimeMillis() is really slow. But it seems like=20= > managing > | >a separate thread just for logging is a bit overkill. If this is > | >primarily useful for benchmarking maybe we can have this be a (yet > | >another) configurable option. E.g., > | > | It certainly was slow at one point in the past. I'm not sure if its=20= > still > | as bad. > | > | Having a separate logging thread seems like a pretty practical > | approach. It reduces IO latency in processing threads, reduces=20 > locking > | contention for the logger, and generally seems more scalable. Use a > | dl.u.c.LinkedQueue which other threads could write to, and have the=20= > logger > | thread wake up only when there's stuff on the queue, and calculate=20= > the time > | once, at time of logging. > > Read about this in the o.apache.log4j package; a separate thread is a > waste of pretty much anything when it comes to logging. I don't have any evidence, but that's how I feel about it too. I do=20 know that my own logging system is "fast enough", and it uses=20 System.currentTimeMillis() with a custom (and much faster) version of=20 SimpleDateFormatter. > The clock thread thing is also a waste. Millis is fast on my linux = box. > > IMHO, I think that WM shouldn't fire up _any_ threads w/o being asked. I basically agree with this too. Currently there's Clock.java,=20 TimeLoop.java, and PostponeObservable.java (if using the=20 GenerationalCacheManager). Since the "clock" thread is used outside of the logging we can't easily=20= delete it from CVS, but we can stop using it in the log system. Would=20= this be acceptable to everyone? One (small) step closer to getting rid=20= of it completely. > Idea for 1.2, 2.0: the standard template cache-thing should be more > intelligent. Why drop templates if there aren't any reason for it? I'd > like to turn on "reloading" in a development context, and have it=20 > totally > static for production envirnoments. For my part, I'd like to have the > entire set of templates in RAM all the time in the production=20 > environemnt. > Then I could have a "drop all templates" _method_ in the cache that=20 > forces > reload. What would this involve? Maybe an ImmutableCacheManager that reads a=20 list of templates to pre-load from WebMacro.properties (or by walking=20 your template path)? That could be nice for a production environment. =20= It would basically be a cache that *only* provides pre-loaded=20 templates. There'd be no need for threading or synchronization if it=20 were immutable. Is this idea even sensible? eric |
|
From: <web...@st...> - 2003-01-31 12:57:16
|
On Wed, 29 Jan 2003, Brian Goetz wrote: | | >I remember this as well. I think it was Brian who pointed out that using | >the System.currentTimeMillis() is really slow. But it seems like managing | >a separate thread just for logging is a bit overkill. If this is | >primarily useful for benchmarking maybe we can have this be a (yet | >another) configurable option. E.g., | | It certainly was slow at one point in the past. I'm not sure if its still | as bad. | | Having a separate logging thread seems like a pretty practical | approach. It reduces IO latency in processing threads, reduces locking | contention for the logger, and generally seems more scalable. Use a | dl.u.c.LinkedQueue which other threads could write to, and have the logger | thread wake up only when there's stuff on the queue, and calculate the time | once, at time of logging. Read about this in the o.apache.log4j package; a separate thread is a waste of pretty much anything when it comes to logging. The clock thread thing is also a waste. Millis is fast on my linux box. IMHO, I think that WM shouldn't fire up _any_ threads w/o being asked. Idea for 1.2, 2.0: the standard template cache-thing should be more intelligent. Why drop templates if there aren't any reason for it? I'd like to turn on "reloading" in a development context, and have it totally static for production envirnoments. For my part, I'd like to have the entire set of templates in RAM all the time in the production environemnt. Then I could have a "drop all templates" _method_ in the cache that forces reload. -- 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: Brian G. <br...@qu...> - 2003-01-29 20:22:13
|
>I remember this as well. I think it was Brian who pointed out that using >the System.currentTimeMillis() is really slow. But it seems like managing >a separate thread just for logging is a bit overkill. If this is >primarily useful for benchmarking maybe we can have this be a (yet >another) configurable option. E.g., It certainly was slow at one point in the past. I'm not sure if its still as bad. Having a separate logging thread seems like a pretty practical approach. It reduces IO latency in processing threads, reduces locking contention for the logger, and generally seems more scalable. Use a dl.u.c.LinkedQueue which other threads could write to, and have the logger thread wake up only when there's stuff on the queue, and calculate the time once, at time of logging. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Lane S. <la...@op...> - 2003-01-29 20:15:45
|
> > new Date() calls System.currentTimeMillis(). This is a always very > slow call, as it requires native code. I think ebr's point is that this call is not made all that often. Right? |
|
From: Eric B. R. <eb...@tc...> - 2003-01-29 18:09:57
|
On Wednesday, January 29, 2003, at 01:08 PM, Lane Sharman wrote: > Sebastian Kanthak wrote: > Why exactly do you want to remove it? Because of the extra thread? > This should > not matter in the bunch of threads servlet engines usually create. And > a > while ago, I added some methods that terminate the clock-thread when > the > web-application is stopped. > this is a good reason to keep it as is? > > -lane I'm now thinking it is. Apparently I didn't see that usage of it last night while I was digging through the code. I see it now. eric |
|
From: Lane S. <la...@op...> - 2003-01-29 17:59:05
|
Sebastian Kanthak wrote: >Hi Eric, > >On Wednesday 29 January 2003 01:22, Eric B. Ridge wrote: > > >>Is it really necessary to use org.webmacro.util.Clock (a background >>thread) to calculate the timestamp for logging? This seems like >>overkill considering WM should only log when your templates are messed >>up. It's not like WM's performance is going to drop 2-fold by using >>"new Date()" instead. >> >>Clock is only used in 3 places: o.wm.servlet.ServletLog, >>o.wm.util.LogFile, and o.wm.util.LogSource >> >> > >well, that's not true. It's also used in o.w.resource.TimedReloadContext, that >limits the amounts of checks, whether a given resource has been modified. >Here, the current time (or an approximation) is needed everytime, a template >is used, which can be really often. > >Why exactly do you want to remove it? Because of the extra thread? This should >not matter in the bunch of threads servlet engines usually create. And a >while ago, I added some methods that terminate the clock-thread when the >web-application is stopped. > this is a good reason to keep it as is? -lane > >Sebastian > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >http://www.vasoftware.com >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
|
From: Lane S. <la...@op...> - 2003-01-29 17:28:50
|
ebr: if you are of a mind to remove detritus in the api, I support you. I do not think you are hearing a chorus of opposition. +1 from me. -Lane Marc Palmer wrote: > On Wed, 29 Jan 2003 12:00:05 -0500, Eric B. Ridge <eb...@tc...> wrote: > >> On Wednesday, January 29, 2003, at 12:10 PM, Lane Sharman wrote: >> >>>> >>>> new Date() calls System.currentTimeMillis(). This is a always very >>>> slow call, as it requires native code. >>> >>> >>> I think ebr's point is that this call is not made all that often. >>> Right? >> >> >> In a well-behaved production environment, it shouldn't be called at all. > > > Indeed - typically it only happens 3 times at startup :-) > > But, I suppose some people use WM logging for their application-level > logging. I tend not to, I use a separate logging library. > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
|
From: Sebastian K. <seb...@mu...> - 2003-01-29 17:28:45
|
Hi Eric, On Wednesday 29 January 2003 01:22, Eric B. Ridge wrote: > Is it really necessary to use org.webmacro.util.Clock (a background > thread) to calculate the timestamp for logging? This seems like > overkill considering WM should only log when your templates are messed > up. It's not like WM's performance is going to drop 2-fold by using > "new Date()" instead. > > Clock is only used in 3 places: o.wm.servlet.ServletLog, > o.wm.util.LogFile, and o.wm.util.LogSource well, that's not true. It's also used in o.w.resource.TimedReloadContext, that limits the amounts of checks, whether a given resource has been modified. Here, the current time (or an approximation) is needed everytime, a template is used, which can be really often. Why exactly do you want to remove it? Because of the extra thread? This should not matter in the bunch of threads servlet engines usually create. And a while ago, I added some methods that terminate the clock-thread when the web-application is stopped. Sebastian |
|
From: Marc P. <ma...@an...> - 2003-01-29 17:11:44
|
On Wed, 29 Jan 2003 12:00:05 -0500, Eric B. Ridge <eb...@tc...> wrote: > On Wednesday, January 29, 2003, at 12:10 PM, Lane Sharman wrote: > >>> >>> new Date() calls System.currentTimeMillis(). This is a always very slow >>> call, as it requires native code. >> >> I think ebr's point is that this call is not made all that often. Right? > > In a well-behaved production environment, it shouldn't be called at all. Indeed - typically it only happens 3 times at startup :-) But, I suppose some people use WM logging for their application-level logging. I tend not to, I use a separate logging library. -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Eric B. R. <eb...@tc...> - 2003-01-29 17:02:58
|
On Wednesday, January 29, 2003, at 12:10 PM, Lane Sharman wrote: >> >> new Date() calls System.currentTimeMillis(). This is a always very >> slow call, as it requires native code. > > I think ebr's point is that this call is not made all that often. > Right? In a well-behaved production environment, it shouldn't be called at all. eric |
|
From: Marc P. <ma...@an...> - 2003-01-29 16:44:59
|
On Wed, 29 Jan 2003 11:18:31 -0500, Eric B. Ridge <eb...@tc...> wrote: >> # Enabling the clock thread makes logging timestamps more efficient, but >> introduces >> # an extra thread. It may be useful when using logging for performance >> metrics. >> UseClockThread: false > > That's just it, it's not used for benchmarking per se. It's used for > calculating the timestamp for log messages. And on top of that, the > value returned isn't guaranteed to be 100% accurate. Which means if you > were trying to profile stuff based on log timestamps (bad idea), your > numbers would most likely be skewed. That's not what I meant though. I don't mean profiling based on timestamps - I mean using a real profiling tool, but running with code with logging turned on. Perhaps a niche case. This would completely trash profiling, thus making it impossible to do any profiling with logging turned on. Given the usually quite low overhead of logging, this could be annoying. > I'd like to just get rid of it completely. In this day and age of 2.4gHz > hyper-threaded servers and JDK 1.4.1 and 500mHz FSB, I really can't see > how Clock.java is saving us that much more over "new Date()". Besides, > the real performance problems with java.util.Date are actually when you > try to format the output using SimpleDateFormatter (for which I've grown > my own that smokes SDF. Be glad to contribute if it sounds interesting). new Date() calls System.currentTimeMillis(). This is a always very slow call, as it requires native code. -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Eric B. R. <eb...@tc...> - 2003-01-29 16:21:19
|
On Wednesday, January 29, 2003, at 11:11 AM,=20 kea...@na... wrote: > I remember this as well.=A0 I think it was Brian who pointed out that=20= > using the System.currentTimeMillis() is really slow.=A0 But it seems=20= > like managing a separate thread just for logging is a bit overkill.=A0=20= > If this is primarily useful for benchmarking maybe we can have this be=20= > a (yet another) configurable option.=A0 E.g., > > # Enabling the clock thread makes logging timestamps more efficient,=20= > but introduces > # an extra thread.=A0 It may be useful when using logging for=20 > performance metrics. > UseClockThread: false That's just it, it's not used for benchmarking per se. It's used for=20 calculating the timestamp for log messages. And on top of that, the=20 value returned isn't guaranteed to be 100% accurate. Which means if=20 you were trying to profile stuff based on log timestamps (bad idea),=20 your numbers would most likely be skewed. I'd like to just get rid of it completely. In this day and age of=20 2.4gHz hyper-threaded servers and JDK 1.4.1 and 500mHz FSB, I really=20 can't see how Clock.java is saving us that much more over "new Date()".=20= Besides, the real performance problems with java.util.Date are=20 actually when you try to format the output using SimpleDateFormatter=20 (for which I've grown my own that smokes SDF. Be glad to contribute if=20= it sounds interesting). eric= |
|
From: <kea...@na...> - 2003-01-29 16:09:01
|
> > Clock is only used in 3 places: o.wm.servlet.ServletLog, > > o.wm.util.LogFile, and o.wm.util.LogSource > > > > Can I remove this? Please? > > If I recall, this really was introduced due to heavy > performance penalties. > I think not using means getting very poor (unrealistic) > performance while > debugging, and this could in turn foul up your plans if your > debugging > involves an element of profiling. > > I may be wrong, but I remember this... I remember this as well. I think it was Brian who pointed out that using the System.currentTimeMillis() is really slow. But it seems like managing a separate thread just for logging is a bit overkill. If this is primarily useful for benchmarking maybe we can have this be a (yet another) configurable option. E.g., # Enabling the clock thread makes logging timestamps more efficient, but introduces # an extra thread. It may be useful when using logging for performance metrics. UseClockThread: false _______________________________________ Keats Kirsch Senior Technology Advisor NatureServe (http://www.natureserve.org) email: kea...@na... phone: (703)908-1895 |
|
From: Marc P. <ma...@an...> - 2003-01-29 10:14:27
|
On Tue, 28 Jan 2003 19:22:42 -0500, Eric B. Ridge <eb...@tc...> wrote: > Is it really necessary to use org.webmacro.util.Clock (a background > thread) to calculate the timestamp for logging? This seems like overkill > considering WM should only log when your templates are messed up. It's > not like WM's performance is going to drop 2-fold by using "new Date()" > instead. > > Clock is only used in 3 places: o.wm.servlet.ServletLog, > o.wm.util.LogFile, and o.wm.util.LogSource > > Can I remove this? Please? If I recall, this really was introduced due to heavy performance penalties. I think not using means getting very poor (unrealistic) performance while debugging, and this could in turn foul up your plans if your debugging involves an element of profiling. I may be wrong, but I remember this... Marc |
|
From: Marc P. <ma...@an...> - 2003-01-29 10:14:21
|
On Tue, 28 Jan 2003 23:26:44 -0500, Eric B. Ridge <eb...@tc...> wrote: > On Friday, January 24, 2003, at 12:27 PM, Marc Palmer wrote: >> Anyone else think removing these final modifiers on many of the methods >> in WMServlet is a good idea? > > Done and in CVS. WMServlet no longer contains public/protected final > methods. Eric - thanks so much for doing this. Sorry I didn't get around to it - I did download the 1.1 source in preparation for doing it ;-) Started work on the webapp yesterday... Marc |
|
From: Eric B. R. <eb...@tc...> - 2003-01-29 04:26:52
|
On Friday, January 24, 2003, at 12:27 PM, Marc Palmer wrote: > Anyone else think removing these final modifiers on many of the > methods in WMServlet is a good idea? Done and in CVS. WMServlet no longer contains public/protected final methods. eric |
|
From: Eric B. R. <eb...@tc...> - 2003-01-29 00:25:31
|
Is it really necessary to use org.webmacro.util.Clock (a background thread) to calculate the timestamp for logging? This seems like overkill considering WM should only log when your templates are messed up. It's not like WM's performance is going to drop 2-fold by using "new Date()" instead. Clock is only used in 3 places: o.wm.servlet.ServletLog, o.wm.util.LogFile, and o.wm.util.LogSource Can I remove this? Please? eric |
|
From: Lane S. <la...@op...> - 2003-01-24 20:10:33
|
> > Anyone else think removing these final modifiers on many of the > methods in WMServlet is a good idea? remove them. They are generally a poor idea especially when one intends the class to be subclassed. A bit arrogant in this case too! -Lane > > > Marc > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
|
From: Eric B. R. <eb...@tc...> - 2003-01-24 18:03:28
|
On Friday, January 24, 2003, at 12:27 PM, Marc Palmer wrote: <snip> > Anyone else think removing these final modifiers on many of the > methods in WMServlet is a good idea? Petr already put a request for this in the SF Tracker. It's on my TODO list. If you wanna go ahead and send a patch, it'll be gleefully accepted. eric |
|
From: Marc P. <ma...@an...> - 2003-01-24 17:28:09
|
Hi, Ugh I am having some fun :( I have a template spewing a PropertyException. I can solve the cause of it later, but right now I need to trap it. Using WMServlet as your base class I think this is impossible. Basically, all my error handling produces an email sent to an admin address. Except for template errors, because I can't trap PropertyException etc. The WMServlet.error method is final, so I cannot override it. Damn those final methods in WMServlet. They've dogged us for a long time. Why don't we get rid of most/all of them, instead of just doGet (a recent modification, for example). My options are: 1. Use my own modified build of WM (not desirable) 2. Write a custom evaluation handler that does the emailing (also not desirable) 3. Abandone extending WMServlet and encapsulate a WM instance myself. None of these are filling me with glee right now! How easy it would have been to just override error() and do my emailing in there. Anyone else think removing these final modifiers on many of the methods in WMServlet is a good idea? Marc |
|
From: <kea...@na...> - 2003-01-22 20:37:25
|
I've been out of town so I haven't had a chance to really follow this thread, but I definitely like the general idea. On the issue of helpers vs. ContextTools, I've been playing around with generic ContextTool loaders which I think can go a long way to addressing the issue. For example, I've created a FactoryToolLoader class which lets you configure any factory method to put objects into the context. This is basically a "Flyweight" factory class for loading singletons into the context. You configure it as follows: ================================================================ # Load a class using SampleFatoryTool.getInstance() into the context as $Sample ContextTools.Sample: org.webmacro.datatable.FactoryToolLoader Sample.ClassName: org.webmacro.datatable.SampleFactoryTool # Load a class using ListUtil.getInstance() into the context as $Lister ContextTools.Lister: org.webmacro.datatable.FactoryToolLoader Lister.ClassName: org.webmacro.servlet.ListUtil ================================================================ By default it uses "getInstance" as the method name, although you can specify a MethodName parameter if you want. We could do something similar for "scoped" classes (global/static, per app, per session, per request). Per request classes with an method matching "void setContext(Context)" could get access to the current context. Session and app classes could use setSession and setBroker or some such. I haven't worked out the destroy() semantics yet, but that should be straightforward. The beauty of this is that it requires no changes to any classes, just a couple new context tools, and then virtually any class can be used as a tool with minimal configuration and no WM specific code. Of course we could simplify things even further by having new configuration options, e.g., StaticContextTool.Thingy: o.w.u.SomeStaticThingy GlobalContextTool.Dodad: o.w.u.SomeGlobalDodad AppContextTool.Whatzama: o.w.u.SomeAppWhatzamajigger SessionContextTool.Dohick: o.w.u.SomeSessionDohicky RequestContextTool.Mabob: o.w.u.SomeRequestThingamabob Thoughts? Keats |
|
From: Lane S. <la...@op...> - 2003-01-21 15:24:48
|
Marc Palmer wrote:
>>> Am I on the nail now?
>>
>>
>> Yeah. You let the template author control the expert action flow. Not
>> the servlet writer. In this case, the action control flow is
>> delegated to a template writer's expert knowledge of the action flow,
>> rule base. The programmer writes the ugly stuff like transaction
>> commits, etc.
>
>
> OK, the only thing I don't like about this is using WM as a general
> purpose language. We don't have all the syntax and capabilities of a
> "full" language as well as the WM philosophy consideration that it's
> just for presentation.
Expert rule processing is business processing rule stuff like
#if ($customerInGoldClub) {#setDisccount(.10, $customer) }
it is this kind of stuff that you want to expose to the web app team.
>
>
> Is this really necessary anyway? I mean, a template will expose links
> to a bunch of actions so the user clicks on them / submits forms.
> These will execute the appropriate action, and return the appropriate
> response.
the actions must have a way to evaluate user rules, settings. this can
be as simple as providing a WebMacro instance by itself for rule processing.
>
>
> Actions will be able to support some kind of "nextAction" parameter
> that indicates what should happen next after the Action executes.
I do not think you want to go there. I think you leave this protocol to
the user to define as required or not required.
>
>
> i.e. an InsertIntoDatabaseAction might look for the nextAction
> parameter and use some supplied mechanism to execute that action after
> the insert. If the nextAction parameter is not present, it could just
> return a results template with the new database contents. (for example)
Again, you are making predictions about the recipe. Let's build the
kitchen with a lot of clean and powerful, process-neutrality. The cooks
are the web-app builders. Let them come in with their own recipes.
>
>
> I can't see how the business rules of an application can be cleanly
> coded into a WM template (or main template plus included parts).
> Wouldn't it be really ugly?
see above.
>
>
> One thing I am planning to add to the idea is a default helper for
> generating URIs to execute actions, so the template need not know the
> details of "hidden" parameter names and so on. This concept could be
> extended to support creating a single URI that will result in the
> execution of several actions i.e:
>
> <FORM METHOD=POST ACTION="$WebMacro.executeActions( ["insertIntoDB",
> "commitToDB", "queryDB"])">
> ...hidden fields containing parameters such as table name and fields....
> ...visible data fields...
> </FORM>
I think this is a good tool.
>
>
> This function would make a pretty complex long URI, or put the info
> into the session and return a short URI that identifies the info in
> the session so the servlet can retrieve it and work out what actions
> to execute.
I do this now but use a #macro do the formatting. Could easily be done
by a java helper tho.
>
>
> This would make things quite modular and allow actions to be stacked -
> writing to a DB and then emailing the data for example - with the
> proviso that all the info necessary to perform all actions must be
> available in the first request. We could allow per-action parameters
> to be supplied too:
>
> <FORM METHOD=POST ACTION="$WebMacro.executeActions(
> ["insertIntoDB:table=testdata", "commitToDB",
> "queryDB:sqlselect='SELECT * FROM
> testdata',template='dataresults.wmt'"])">
>
> As every, thoughts welcome... but I really don't believe this webapp
> will be the cure for all web application needs... just enough for 90%
> of websites, and at the very least a much better replacement for
> server side includes and related technologies.
agreed.
>
>
> Marc
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO
|
237 messages has been excluded from this view by a project administrator.
