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-08 13:39:59
|
> Given that a quote from Jason and a permitted mention of AV would be > extremely desirable, I think we should make the press release on Monda= y > 8th. That should be Monday 13th. Sorry. Marc ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ W<A> ~~~~~ (o) Wangjammer5 (Marc Palmer)=20 ( ) Wangjammer7=20 www.wangjammers.org =3D Java Consultants (Web|Smartcards|Crypto) |
From: Marc P. <ma...@an...> - 2003-01-08 13:27:30
|
Guys, I'm progressing the quote request with AV. It will not materialise until= =20 after this release but we will probably be allowed to mention that AV=20= use it in this release. Also, I've mailed Jason Hunter to see if we can get a quote.=20 However we can't wait too long =96 we should issue the press release tod= ay=20 or tomorrow, or failing that delay it until Monday. Friday is not usuall= y=20 a good time. Given that a quote from Jason and a permitted mention of AV would be=20= extremely desirable, I think we should make the press release on Monday = 8th. I will post the release on The Server Side (www.theserverside.com). As for Lane's PDF related comments. I can produce a basic PDF of the=20= release with a WM logo on it, but I don't have time to spend ages playin= g=20 around with the formatting. I'm just wondering what the real value of a = PDF version is. Also, how would I get the PDF version onto the site? Using CVS? I have absorbed and assimilated all the comments including Lane's=20 grammatically corrections. I'll post a final draft as soon as we have th= e=20 quotes in. If nothing comes in by close of business on Friday though,=20= I'll go with what we have and use my name for one of the quoted people, = and someone else's for the other. Any volunteers? Alternative wording fo= r=20 a quote that someone can put their reputation behind is of course=20 possible too. I've had no volunteers yet. Best wishes, Marc |
From: Marc P. <ma...@an...> - 2003-01-08 11:59:47
|
For Eric (and others) who aren't aware of what RSS is: http://www2.theserverside.com/rss/theserverside-1.0.rdf That is an RSS file containing the news from www.theserverside.com See, if we can grab a WM-template friendly RSS parser we'll be laughing.= =20 Instant news portals with WM :) Best wishes, Marc |
From: Nick S. <NSa...@ms...> - 2003-01-08 08:59:34
|
Hi Marc I'm pleased to see that webMacro is making an effort at publicity. I couldn't see the serverside www.serverside.com amongst the list of portals. This is one of the biggest j2ee portals on the web and regularly announces new products etc. Regards Nick Sanderson |
From: Marc P. <ma...@an...> - 2003-01-08 00:52:09
|
Hi, I just checked out the download stats on SF for WM and there's something= =20 odd. http://sourceforge.net/project/stats/?group_id=3D64597 It shows 525 downloads on 30 Dec 2002 and not one single download since.= This doesn't sound right to me at all.=20 Any ideas? We need to be sure the stats are working before we make the=20= press release... for a start this should propel us up the list of most=20= popular projects. I note that there are 5 or more other SF projects that use / mention WM.= Marc |
From: Eric B. R. <eb...@tc...> - 2003-01-07 18:48:54
|
On Tuesday, January 7, 2003, at 01:33 PM, Marc Palmer wrote: > Hi, > > Also, before I start posting out this press release =96 do we get > hit/download stats from the WM site already or not? If we do, are we > -sure- they are still working. we have a standard access_log that can be grepped if necessary. SourceForge also keeps some basic statistics on page views and=20 downloads. eric > > We want this working before I do the announcement so that we can see=20= > how > much traffic we have generated. > > Also, I think I will change the title of the press release to = something > like > > "Version 1.1 of WebMacro released - an alternative to JSP" > > It might catch a few more eyeballs! > > Best wishes, > 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 |
From: Eric B. R. <eb...@tc...> - 2003-01-07 18:47:37
|
On Tuesday, January 7, 2003, at 01:30 PM, Marc Palmer wrote: > Barring any significant further comments on the press release text, > I'll > post it off to sites by email. I don't know who (if anyone) is "in > charge" of the WM site or how we go about putting the press release on > there apart from through normal Wiki mechanisms. Just the normal Wiki mechanisms. eric > > The sites I intend to target (and expect success with) are listed > below. > If you do not see your favourite Java tech portal listed please let me > know: > > JavaWorld > jGuru > Freshmeat > ITToolbox > Java-Channel > Jsurfer > Javable > Java Lobby > > Java Boutique (internet.com) and Java Skyline would be on the list but > they don't seem to pay attention to announcements. I'll try them > anyway. > > Best wishes, > 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 |
From: Marc P. <ma...@an...> - 2003-01-07 18:32:03
|
Hi, Also, before I start posting out this press release =96 do we get=20 hit/download stats from the WM site already or not? If we do, are we=20= -sure- they are still working. We want this working before I do the announcement so that we can see how= =20 much traffic we have generated. Also, I think I will change the title of the press release to something = like=20 "Version 1.1 of WebMacro released - an alternative to JSP" It might catch a few more eyeballs! Best wishes, Marc |
From: Marc P. <ma...@an...> - 2003-01-07 18:29:56
|
Barring any significant further comments on the press release text, I'll= =20 post it off to sites by email. I don't know who (if anyone) is "in=20 charge" of the WM site or how we go about putting the press release on=20= there apart from through normal Wiki mechanisms. The sites I intend to target (and expect success with) are listed below.= =20 If you do not see your favourite Java tech portal listed please let me=20= know: JavaWorld jGuru Freshmeat ITToolbox Java-Channel Jsurfer Javable Java Lobby Java Boutique (internet.com) and Java Skyline would be on the list but=20= they don't seem to pay attention to announcements. I'll try them anyway.= Best wishes, Marc |
From: Lane S. <la...@op...> - 2003-01-07 16:27:01
|
Hi, I have followed the thread and believe we should be careful not to try to wedge two similar tools into one. The context tool is really for a java programmer who wants to automate the inclusion of an object in the context. A sql connection object, form processor, whatever. It may need to be reengineered some to minimize the number of times it instantiates itself per Keats' analysis. The context tool, I do not think, was originally designed for a collection of static methods although this purpose became popular but is now obsolete given the power of WM functions. I would like to see the context tool re-engineered for better performance; also, some more contributions for lucene-based searching, menu and page formatting would be nice. So, I would leave Context tool as one kind of screw-driver and #bean as another. #bean is really a template friendly construct allowing the build-up of page and global content for reuse within a site or a request flow. Context and #bean address two similar but different needs: the former for the java engineer and the latter for the template designer. The end state is the same but the road that gets you there is very different and for different classes of WM users. my $.02 -lane kea...@na... wrote: > > -----Original Message----- > > From: Eric B. Ridge [mailto:eb...@tc...] > <snip> > > isn't this what the init(Context) method is for? It's the > > return value > > of init() that actually gets put into the context. If you > > need config > > settings, shouldn't you do this: > > > > public Object init (Context c) { > > Settings s = c.getBroker().getSettings(); > > return new ThingieTool(s.get("Thingie.Key1")); > > } > > > > Or, if you don't need settings: > > > > public Object init (Context c) { > > return this; > > } > > > > Makes me think that we don't need to support the 1 and 2 arg ctors. > > > > Init is called once on each template evaluation. This is for tools > that need access to the current context (request, response, session, > etc) like the FormTool or the CookieTool. Some tools might get > initialized once -- imagine a SQL tool that needs some database > connection parameters. (This is actually what triggered this whole > investigation -- but more on that later.) > > <snip> > > > The ContextTool is really supposed to just be a wrapper for another > > object, right? So why would we need a > > StaticContextToolWrapper when we > > can just "return this" from init()? > > Well currently tools need to conform to the ContextTool interface, so > having a simple adaptor for any static class would make it work with > minimal fuss. > > > > Maybe we should junk ContextTools completely and use #bean. > > Ship some > > kind of default "context.wm" template that has a bunch of #bean > > statements that is auto-included as the first block of every template > > loaded. > > > > I don't know the syntax for #bean off the top of my head, but > > basically: > > > > --- context.wm --- > > #bean $String = "org.webmacro.util.StringUtil" scope global > > #bean $List = "org.webmacro.util.ListUtil" scope global > > #bean $Cast = "org.webmacro.util.CastUtil" scope global > > #bean $Form = "org.webmacro.util.FormUtil" scope request initArgs > > [$Request] > > > > Yes, I think we're thinking along the same lines. I hadn't actually > thought of using > > initArgs [$Request] > > but it should work. Of course $Request is a ContextTool ... so we may > not be able to dispense with them altogether. > > Keats > > > eric > > > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
From: <kea...@na...> - 2003-01-07 16:04:10
|
> -----Original Message----- > From: Eric B. Ridge [mailto:eb...@tc...] <snip> > isn't this what the init(Context) method is for? It's the > return value > of init() that actually gets put into the context. If you > need config > settings, shouldn't you do this: > > public Object init (Context c) { > Settings s = c.getBroker().getSettings(); > return new ThingieTool(s.get("Thingie.Key1")); > } > > Or, if you don't need settings: > > public Object init (Context c) { > return this; > } > > Makes me think that we don't need to support the 1 and 2 arg ctors. > Init is called once on each template evaluation. This is for tools that need access to the current context (request, response, session, etc) like the FormTool or the CookieTool. Some tools might get initialized once -- imagine a SQL tool that needs some database connection parameters. (This is actually what triggered this whole investigation -- but more on that later.) <snip> > The ContextTool is really supposed to just be a wrapper for another > object, right? So why would we need a > StaticContextToolWrapper when we > can just "return this" from init()? Well currently tools need to conform to the ContextTool interface, so having a simple adaptor for any static class would make it work with minimal fuss. > Maybe we should junk ContextTools completely and use #bean. > Ship some > kind of default "context.wm" template that has a bunch of #bean > statements that is auto-included as the first block of every template > loaded. > > I don't know the syntax for #bean off the top of my head, but > basically: > > --- context.wm --- > #bean $String = "org.webmacro.util.StringUtil" scope global > #bean $List = "org.webmacro.util.ListUtil" scope global > #bean $Cast = "org.webmacro.util.CastUtil" scope global > #bean $Form = "org.webmacro.util.FormUtil" scope request initArgs > [$Request] > Yes, I think we're thinking along the same lines. I hadn't actually thought of using initArgs [$Request] but it should work. Of course $Request is a ContextTool ... so we may not be able to dispense with them altogether. Keats > eric > |
From: Marc P. <ma...@an...> - 2003-01-07 14:25:44
|
Any more comments? I still have no takers for XXXXX, YYYY and ZZZZ. ------------ Version 1.1 of the WebMacro Open Source web-scripting engine released. January 7, 2003 -- The WebMacro team (www.webmacro.org) today=20 released version 1.1 of the WebMacro templating library. A mature=20 product already used by many web sites and applications, this new=20 release of WebMacro adds powerful new features as well as improvements=20= and bug fixes.=20 WebMacro is a extensible templating engine written in Java, which=20 can be used in Java Servlets as well as regular Java applications.=20 What distinguishes WebMacro from most other web scripting technologies=20= such as Java Server Pages (JSP) is the focus on using pages purely=20 for the presentation of dynamic information, leaving the actual=20 data manipulation in the application where it belongs. This MVC (Model, = View, Controller) approach results in cleaner and easily maintained=20 applications. The simple WebMacro scripting language is typically used to produce=20 HTML output that contains data from a web application, though it is=20 equally well suited to XML or any plain text output. Directives are the main "commands" available, and they are deliberately few in number to keep the language simple. What sets WebMacro's scripting apart=20 from other templating libraries is that developers are free to add=20 their own directives to the language without the need to modify the=20 WebMacro source. The vibrant community of users and developers=20 contribute a wealth of tools and extensions for other WebMacro users. This new release includes several major new features, including=20 support for "macros" which allow the definition of sections of=20 WebMacro script that can be reused with parameters passed to them.=20 There is also now support for "global" functions in addition to the=20 usual object method and property access. "WebMacro has been incredibly stable for years now, with high=20 performance and a simplicity that has brought smiles to our developers AND our web-designers" said XXXXXX. YYYYYY, who uses WebMacro at=20 ZZZZZ Inc. explained "I would be lost without WebMacro - I cannot=20 count the days it has saved me in development time on my web projects."= Amongst WebMacro's larger users are AltaVista who have been using it to = serve the pages on their site since January 2001. WebMacro 1.1 is available for free from http://www.webmacro.org About WebMacro WebMacro was originally devised and developed by Justin Wells during 1998. The current releases are developed through the joint efforts of=20= several people from around the world. The core development team=20 currently has five primary members, with contributions from its many=20= users. WebMacro has been used on major high-availability server=20 projects right down to embedded systems with only 32MB RAM and J2ME CDC.= |
From: Eric B. R. <eb...@tc...> - 2003-01-07 14:16:03
|
On Monday, January 6, 2003, at 08:12 PM, Marc Palmer wrote: > Hi all, > > Here's a draft of the press release. Constructive comments are very > welcome =96 I have no pride! (and often little shame) cool! <snip> > Version 1.1 of the WebMacro Open Source web-scripting engine released. <snip> Any use in mentioning the "community" of WM developers and users as one=20= of its selling points? This in my opinion is one of the biggest=20 benefits to OSS in general. Also, maybe if Jason Hunter is listening we could convince him to give=20= us a quote? He's written about us in his books. People have heard his=20= name. > About WebMacro > > WebMacro is an open source project, originally started by Justin > Wells around 1998. Current developers include Eric Ridge, Keats > Kirsch, Lane Sharman, Brian Goetz and Fergus Gallagher. It enjoys > a loyal following and has been used on major high-availability > server projects right down to embedded systems with only 32MB RAM. Probably want to grab the "official" list from=20 www.webmacro.org/CoreDevelopers. But if it needs to be trimmed down,=20 the people most recently active in committing code are: Brian Goetz Keats Kirsch Sebastian Kanthak Lane Sharman Eric Ridge Endre Stolsvik, you, and Mark Crocker have been a tremendous help in=20 taking care of user questions on the -user list. Not to mention the=20 code they've submitted over the years. Justin Wells deserves recognition too. Thanks to him, we're all stuck=20= with this project. :) eric= |
From: <web...@st...> - 2003-01-07 12:40:20
|
On Tue, 7 Jan 2003, Marc Palmer wrote: | | Hi all, | | Here's a draft of the press release. Constructive comments are very | welcome I have no pride! (and often little shame) | | It's a bit cheesy, a bit fluffy, but that's press release's for you. Excellent! | | Also, the list of current developers at the end is probably not complete | I just used the names that came to mind most readily. If there is | anyone I have missed, please tell me! (I'm not going to get my hand | slapped again by Lane! <g>) Drop the "current list of developers". This is not because I'm not there (!), but a Open Source project usually does not "front" single people in that way, I feel.. | WebMacro is an open source project, originally started by Justin | Wells around 1998. Instead something like: ".. originally devised and developed by Justin Wells at around 1998. The current releases are developed by a joint effort of several people from around the world. The core development team currently has X active members, with contributions from its many users." " The project .. " | .. enjoys | a loyal following and has been used on major high-availability | server projects right down to embedded systems with only 32MB RAM. What's that weird tool someone talked about here once? A watch or something? This is cool! -- 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: Lane S. <la...@op...> - 2003-01-07 06:00:15
|
> > >Hey... you took my "us lazy people" too seriously Lane! I know full well >many people have worked on it. I was referring to putting together the >release though, rather than doing all the coding :-) > my macro library is feeling lonely and under-appreciated :). > > > >>now.... as to your offer below. I, for one, think it would be marvelous >>if you would produce a slick pdf press release. I think you should add >>photos of the main contributors as well as their locations on the bottom >>in the section "for contact information". This would give the press >>release some pizazz and substance. Put real people behind the wm >>community. Also, I think it would be a good idea to develop on our wiki >>site, a list of contacts for pr purposes. I will add some names from my >>file. >> >> > >Well I could produce a PDF release, but I don't think this will work for >the online sites. The sites I am planning to target will just want a >plain text release they can paste into their site - it's what they've >done with everything else. > >Online sites are our main target... and the key with press is to make it >a no-brainer for them to include your content on their site. > good point. we can produce the doc as text, html, pdf. > > > >>as to the web project, my thinking follows along these lines which I >>think are close to yours. >> >> > > > >>a) a general purpose plug-in servlet which has some lifecyle methods >>specific to webMacro and good servlet design: >>installWMPlugins(); //on init, read the plugin property list (in >>dependency order!), initialize >>getUser(); // adapter method to get user object making request >>authenticate(); // adapter method to authenticate user for this request, >>if required >>authorize(); // adapter method to authorize user for this request, if >>required >>refreshWMPlugins(); // a call back to the servlet to refresh the >>services installed >>addWMPlugin(); // allow a plugin to be added dynamically >>removeWMPlugin(); // allow a plugin to be removed dynamically >>dispatchRequest(); // dispatch the request object returning a template >>evaluateTemplate(); // evaluate the template and return a completed page >>for sending. >> >> > >I assume you mean here that a servlet with this design would work "out of >the box" but would also work as a base class for developers' own >servlets. > This class would work out of the box and a) by writing a plug-in you could dramatically alter the base class behavior or b) write a sub-class for a specific purpose, eg, to upload a file. > > > >>Instead of loading plugins and objects from a properties file, I >>strongly urge the use of a webmacro template file so as to benefit from >>caching and the ability to create a list, not a map of plugins to >>initialize. To your thinking, how is a plugin different from a context >> >> >tool? > >Um, not at all. I just mean an object to put into the page context. Nice >and simple stuff. > >We could of course use the ActionServlet concept and allow setup of >custom action objects to handle specific requests with more complex >behaviour than just returning a template. > I think we have to thrash out a Request Delegation protocol 'cause obviously this is not something the servlet will know how to do. Alternatively, my preference would be protocol neutral. A plugin implementor would implement the "RequestProcessor" plugin and all requests authorized and authenticated would be forwarded to this plugin. > > > >>b) plug-in contributions. Each of us could contribute some plugins from >>our APIs. I can add some physical-independent storage for authentication >>and authorization. >> >> > >Yep! SQL helpers, XML helpers, RSS helpers etc. would all be fantastic. >If we have something like this in WM 1.2 then we can expect to get a much >larger audience (amongst the Freshmeat crowd etc.) and then hopefully the >list of plugins/helpers will grow. > >I think we should settle on a specific name for this - plugin or helper >for example, rather than context tool. > Lets work on a cool name for a WM plugin. I have a product name guy I can use. I will talk with him about this. > >How about: > >Handler ("Request Handler") - a "plugin" object that handles requests >with a certain "action" value > >Plugin - an object placed in to the page context. > As Keats suggested, plugins, #bean, ContextTool and WM functions should all be integrated into a common startup framework making it possible to mix and match what the webmaster wants. To this end, I would add a WebMacro.default property: Plugin.InitTemplate=path/to/defaultPlugInInitializerTemplate.wmt -Lane > >Any more thoughts on this? > >Best wishes, >Marc > > > > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
From: Lane S. <la...@op...> - 2003-01-07 05:45:08
|
keats (and others doing any gui development) http://opendoors.com to download the first and best GUI builder for Java: Conga. No AWT or Swing. Just a kick-ass widget set and visual builder. Since it has a rich text syntax checker built-in, plese give this a try at subclassing it! Conga was written well before Swing was on the drawing board and is a complete, all-Java implementation of AWT and Swing should have been written. -Lane kea...@na... wrote: > Hey Marc, > > I like your ideas. I've written a sample servlet which does pretty > much what you're suggesting, but I never packaged it up as a WAR. I > think Lane has done something along these lines as well. > > My servlet extracts the template name from the extra path info of the > request, like > > http://www.mysite.com/wmlab/mytemplate.wmt > > I spent some time figuring out how to pass in other stuff from the > URL, but then I realized that you can just use CGI form variables for > most stuff. > > The ContextTools stuff already works as you describe, although imho > "functions" are even cooler, 'cause you don't need to implement any > special interface. Couple this with the #bean directive and you have > a pretty decent workbench out of the box for developing WM apps. > > I've also been working on enhancing the /contrib/datatable stuff to > give an out-of-the-box database query and reporting capability. One > other thing I've been playing with is a very simple WMScript editor > that reports syntax errors and puts the cursor on them. This is still > very rough. > > Anyway, it would be great to kick some ideas around on this. > > Keats > > > > > -----Original Message----- > > From: Marc Palmer [mailto:ma...@an...] > > Sent: Monday, January 06, 2003 8:50 AM > > To: web...@li... > > Subject: [Webmacro-devel] Some WM PR stuff > > > > > > > > Hi all, > > > > Seeing as Eric has done all the hard work for us lazy people > > in producing > > a WM 1.1 release, we should do our most to promote it! > > > > Nobody seems to be "in charge" of issuing WM press releases. > > It is vital > > that we issue press releases to let people know WM is around, > > maturing, > > and used by some very BIG people (i.e. AltaVista). The more > > exposure, the > > more users we will have. > > > > I am willing to write and send out this press release. I did > > it recently > > for one of our own products and had some reasonable success > > (announcement > > covered by people like JavaWorld, ITToolbox, Javable, > > JavaLobby, jGuru > > etc.) which generated several thousand hits for us. > > > > Also, I want to ask a related question - because I don't have time to > > check - if WM comes with a default web application yet, that > > will server > > up templates and provide context tool classes, the class > > names of which > > are loaded from some .properties file? > > > > If not, I will write this. I have been planning it myself as > > I need it, > > and this could completely change the market for WM. > > > > Instead of WM just being for web-app/Java developers, it > > would suddenly > > become a tool that any webmaster can download and install, to get > > world-class templating of site pages with configurable "plugins" that > > they can write in Java or download. > > > > As such, a repository of general-purpose Java classes that > > work well in > > templates would also be very useful to such people. > > > > With this I think we can turn WM's user-base from 100s into 1000s. > > > > So, if someone can fill me in on the above / supply comments, > > I would be > > grateful. I'm thinking of a single servlet in .WAR with WM in > > WEB-INF/lib > > and a way to pass a list of context tool classnames to it, > > probably via > > WebMacro.properties. These would be instantiated at servlet > > startup, and > > put into every page. It would just be a case of using URIs like: > > > > www.mysite.com/WebMacro?template=mytemplate.wm > > > > ...which is obviously something any webdesigner can > > understand, and means > > they can get the basic advantages of running WM with absolutely NO > > programming at all. > > > > I will run a 1.1 press release by you guys in the next couple of days > > (unless somebody else feels they are more qualified for this). I'm no > > expert on this stuff, but I've done it before which is something. > > > > I want to give something back to WM... for me WM has been the > > gift that > > keeps on giving! > > > > Best wishes, > > Marc > > > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
From: Marc P. <ma...@an...> - 2003-01-07 01:12:47
|
Hi all, Here's a draft of the press release. Constructive comments are very=20 welcome =96 I have no pride! (and often little shame) It's a bit cheesy, a bit fluffy, but that's press release's for you. As you will see there are people named XXXX, YYYY and ZZZZ in it. I need= =20 volunteers for the quotes provided. I don't mind being one of them if=20= nobody wants to commit. I can certainly put my heart behind both=20 "quotes". Also, the list of current developers at the end is probably not complete= =20 =96 I just used the names that came to mind most readily. If there is=20= anyone I have missed, please tell me! (I'm not going to get my hand=20 slapped again by Lane! <g>) Here goes: Version 1.1 of the WebMacro Open Source web-scripting engine released. January 7, 2003 -- The WebMacro team (www.webmacro.org) today=20 released version 1.1 of the WebMacro templating library. A mature=20 product already used by many web sites and applications, this new=20 release of WebMacro adds new powerful features as well as improvements=20= and bug fixes. WebMacro is a extensible templating engine written in Java, which=20 can be used in Java Servlets as well as regular Java applications.=20 What distinguishes WebMacro from other web scripting technologies is the focus on using pages purely for formatting the presentation of dynamic information, leaving the actual data manipulation in the=20 application where it belongs. The simple WebMacro scripting language is typically used to produce=20 HTML output that contains data from a web application, though it is=20 equally well suited to XML or any plain text output. Directives are the main "commands" available, and they are deliberately few in number to keep the language simple. What sets WebMacro's scripting apart=20 from similar templating libraries is that developers are free to add=20= their own directives to the language without modifying the WebMacro source. This new release includes several major new features, including=20 support for "macros" which allow definition of sections of WebMacro=20 script that can be reused with parameters passed to them. There is=20 also now support for "global" functions in addition to the usual=20 object method and property access. "WebMacro has been incredibly stable for years now, with high=20 performance and a simplicity that has brought smiles to our developers AND our web-designers" said XXXXXX. YYYYYY, who uses WebMacro at=20 ZZZZZ Inc. explained "I would be lost without WebMacro - I cannot=20 count the days it has saved me in development time on my web projects."= Amongst WebMacro's larger users are AltaVista who have been using it to = serve the pages on their site since January 2001. WebMacro 1.1 is available for free from http://www.webmacro.org About WebMacro WebMacro is an open source project, originally started by Justin=20 Wells around 1998. Current developers include Eric Ridge, Keats=20 Kirsch, Lane Sharman, Brian Goetz and Fergus Gallagher. It enjoys a loyal following and has been used on major high-availability=20 server projects right down to embedded systems with only 32MB RAM. |
From: Eric B. R. <eb...@tc...> - 2003-01-07 00:46:10
|
On Monday, January 6, 2003, at 06:23 PM, Marc Palmer wrote: <snip> > Um, not at all. I just mean an object to put into the page context.=20 > Nice > and simple stuff. > > We could of course use the ActionServlet concept and allow setup of > custom action objects to handle specific requests with more complex > behaviour than just returning a template. I've never used Petr's ActionServlet, but I've studied it closely. We=20= here at TCDI have a similar framework we work in. Maybe we should try=20= to include ActionServlet (I think Petr finally hosts on SF) w/ WM? Or=20= otherwise "partner up" with it. I'd really hate for us to re-invent=20 the wheel here. > >> b) plug-in contributions. Each of us could contribute some plugins=20 >> from >> our APIs. I can add some physical-independent storage for=20 >> authentication >> and authorization. > > Yep! SQL helpers, XML helpers, RSS helpers etc. would all be = fantastic. > If we have something like this in WM 1.2 then we can expect to get a=20= > much > larger audience (amongst the Freshmeat crowd etc.) and then hopefully=20= > the > list of plugins/helpers will grow. Now this isn't a bad idea. But that's what ContextTools are. We're=20 just lacking the real useful tools like SQLTool and XMLTool. WTF is=20 RSS? :) > I think we should settle on a specific name for this =96 plugin or = helper > for example, rather than context tool. What's wrong with ContextTool? > How about: > > Handler ("Request Handler") =96 a "plugin" object that handles = requests > with a certain "action" value Again, maybe we should try to partner up with a project like=20 ActionServlet or *gasp* Struts. Oh wait. Struts is jakarta. That'll=20= be the day... > Plugin =96 an object placed in to the page context. You mean ContextTool? :) eric= |
From: Eric B. R. <eb...@tc...> - 2003-01-07 00:43:53
|
On Monday, January 6, 2003, at 07:07 PM, kea...@na...=20= wrote: > I've been playing around with ContextTools and I've learned some=20 > things that I found a bit surprising.=A0 > > (Maybe everybody already knows these things but I figured I'd share=20 > them anyway.=A0 This will probably turn into a Wiki page.) I had no idea. > > ContextTools are loaded by the Context.addTool() method, called from=20= > the constructor in Context. > > Using reflection, addTool instantiates each ContextTool listed in the=20= > configuration.=A0 It looks for one of three constructor signatures in=20= > the following order: > > =A0 2-arg: String, Settings > =A0 1-arg: String > =A0 0-arg > > I hadn't seen anyone use the args, so I tried it out.=A0 The first arg=20= > is the key, e.g., "Form" for the FormTool.=A0 The second arg is a=20 > Settings object that gives the tool's constructor access to all the=20 > configured properties that are prefixed with the key, e.g., "Form.".=A0=20= > (The 1-arg version seems pretty useless, but I can see using the 2-arg=20= > constructor to pass configuration information to the tool, e.g., how=20= > to locate resources that it uses.) isn't this what the init(Context) method is for? It's the return value=20= of init() that actually gets put into the context. If you need config=20= settings, shouldn't you do this: public Object init (Context c) { Settings s =3D c.getBroker().getSettings(); return new ThingieTool(s.get("Thingie.Key1")); } Or, if you don't need settings: public Object init (Context c) { return this; } Makes me think that we don't need to support the 1 and 2 arg ctors. > One unfortunate side-effect of this architecture is that you can't use=20= > singletons -- although people try to.=A0 WM will instantiate each tool=20= > for each Context created, which means that each tool is instantiated=20= > at least three times!=A0 (WM creates a prototype Context and = WebContext=20 > object before delivering the first Context.) > > Since most ContextTools are really just collections of static methods=20= > (i.e., "Functions") this is unfortunate.=A0 People have tried to use = the=20 > singleton design pattern to get around this, but it doesn't work.=A0=20= > Since you can't make the constructor private, each tool gets=20 > instantiated N+2 times, where N is the number of Contexts put into the=20= > pool. > > The #bean directive avoids this problem by allowing "global" or=20 > "static" scoped beans. > > It occurs to me that an obvious way around this problem is to allow=20 > tools with no public constructor to be used as static classes.=A0 They=20= > could be stored in a static map and reused for each new context.=A0 = This=20 > would have the added benefit of not having to implement the=20 > ContextTool interface.=A0 (We would probably still need a=20 > StaticContextToolWrapper class or something as a facade, but this=20 > would be trivial.) The ContextTool is really supposed to just be a wrapper for another=20 object, right? So why would we need a StaticContextToolWrapper when we=20= can just "return this" from init()? Maybe we should junk ContextTools completely and use #bean. Ship some=20= kind of default "context.wm" template that has a bunch of #bean=20 statements that is auto-included as the first block of every template=20 loaded. I don't know the syntax for #bean off the top of my head, but basically: --- context.wm --- #bean $String =3D "org.webmacro.util.StringUtil" scope global #bean $List =3D "org.webmacro.util.ListUtil" scope global #bean $Cast =3D "org.webmacro.util.CastUtil" scope global #bean $Form =3D "org.webmacro.util.FormUtil" scope request initArgs=20 [$Request] eric= |
From: Marc P. <ma...@an...> - 2003-01-07 00:22:47
|
Hi, Is Glenn Schute on this list, or on the user list? If anyone has his=20= email address to hand, please send it to me (ma...@an...) because= =20 I want to see if we can get a quote from AltaVista, or at least=20 permission to mention their usage of WM for the press release. Best wishes, Marc |
From: Marc P. <ma...@an...> - 2003-01-07 00:18:29
|
> > We could of course use the ActionServlet concept and allow setup of= > > custom action objects to handle specific requests with more complex= > > behaviour than just returning a template. > I've never used Petr's ActionServlet, but I've studied it closely. We= > here at TCDI have a similar framework we work in. Maybe we should try= > to include ActionServlet (I think Petr finally hosts on SF) w/ WM? Or= > otherwise "partner up" with it. I'd really hate for us to re-invent= > the wheel here. Yes, we definitely should look at this. The core emphasis must be that i= t=20 will simply install from a prebuilt .war downloaded from webmacro.org an= d=20 allow the web author to create .wm/.wmt files and see them work=20 immediately. The pluggable "actions" will be more for the Java developer =96 I would = use=20 it for simple web solutions that don't warrant their own web=20 applications, such as an EmailSendPlugin etc. > Now this isn't a bad idea. But that's what ContextTools are. We're > just lacking the real useful tools like SQLTool and XMLTool. WTF is > RSS? :) RSS is an XML grammar for serialising news content. It's how many=20 thousands of websites exchange news content automatically. Many of the=20= Java "portal" websites use it. For example, if we get the press release = listed on JavaWorld, the release will also appear on many other java=20= sites that take an RSS news feed from JW. Imagine if you could write a trivial WM template that pulled in news fro= m=20 CNN and a whole host of websites without -any- coding. The trouble with RSS is that there are many versions of it, with subtle = differences. It would still be possible to do this. > > I think we should settle on a specific name for this =96 plugin or h= elper > > for example, rather than context tool. > What's wrong with ContextTool? It's very opaque to people who are not Java developers. Remember, my=20= "grand idea" here is to open up WM to non-Java developers =96 people who= =20 just want a templating mechanism for their websites. This is MUCH bigger= =20 than the conventional Java WM market. Think rivalling PHP. > > Handler ("Request Handler") =96 a "plugin" object that handles reque= sts > > with a certain "action" value > Again, maybe we should try to partner up with a project like > ActionServlet or *gasp* Struts. Oh wait. Struts is jakarta. That'll= > be the day... LOL. > > Plugin =96 an object placed in to the page context. > You mean ContextTool? :) This servlet I am talking about would effectively be a web application=20= that is separate from WM (it -uses- WM) and downloaded as a separate=20= binary .war that any web developer can use. As such the documentation would need to be simple, and avoid any WM/Java= =20 related terminology that is not important to people who just want to=20= write templates. This servlet would also be a MAJOR boon for web designers who are being = told to use WM by their programmers. They will be able to prototype WM=20= templates very easily without getting any code from their programmers. Get it? Best wishes, Marc |
From: <kea...@na...> - 2003-01-07 00:04:33
|
I've been playing around with ContextTools and I've learned some things that I found a bit surprising. (Maybe everybody already knows these things but I figured I'd share them anyway. This will probably turn into a Wiki page.) ContextTools are loaded by the Context.addTool() method, called from the constructor in Context. Using reflection, addTool instantiates each ContextTool listed in the configuration. It looks for one of three constructor signatures in the following order: 2-arg: String, Settings 1-arg: String 0-arg I hadn't seen anyone use the args, so I tried it out. The first arg is the key, e.g., "Form" for the FormTool. The second arg is a Settings object that gives the tool's constructor access to all the configured properties that are prefixed with the key, e.g., "Form.". (The 1-arg version seems pretty useless, but I can see using the 2-arg constructor to pass configuration information to the tool, e.g., how to locate resources that it uses.) One unfortunate side-effect of this architecture is that you can't use singletons -- although people try to. WM will instantiate each tool for each Context created, which means that each tool is instantiated at least three times! (WM creates a prototype Context and WebContext object before delivering the first Context.) Since most ContextTools are really just collections of static methods (i.e., "Functions") this is unfortunate. People have tried to use the singleton design pattern to get around this, but it doesn't work. Since you can't make the constructor private, each tool gets instantiated N+2 times, where N is the number of Contexts put into the pool. The #bean directive avoids this problem by allowing "global" or "static" scoped beans. It occurs to me that an obvious way around this problem is to allow tools with no public constructor to be used as static classes. They could be stored in a static map and reused for each new context. This would have the added benefit of not having to implement the ContextTool interface. (We would probably still need a StaticContextToolWrapper class or something as a facade, but this would be trivial.) I have more ideas about this, but that's enough for now. Keats |
From: Marc P. <ma...@an...> - 2003-01-06 23:24:17
|
> ebr has been a terrific asset to wm but wm is a jewel to which many, > many have added countless hours and to which others continue to add th= e > fruits of their knowledge. Hey... you took my "us lazy people" too seriously Lane! I know full well= =20 many people have worked on it. I was referring to putting together the=20= release though, rather than doing all the coding :-) > now.... as to your offer below. I, for one, think it would be marvelou= s > if you would produce a slick pdf press release. I think you should add= > photos of the main contributors as well as their locations on the bott= om > in the section "for contact information". This would give the press > release some pizazz and substance. Put real people behind the wm > community. Also, I think it would be a good idea to develop on our wik= i > site, a list of contacts for pr purposes. I will add some names from m= y > file. Well I could produce a PDF release, but I don't think this will work for= =20 the online sites. The sites I am planning to target will just want a=20= plain text release they can paste into their site =96 it's what they've = done with everything else. Online sites are our main target... and the key with press is to make it= =20 a no-brainer for them to include your content on their site. > as to the web project, my thinking follows along these lines which I > think are close to yours. > a) a general purpose plug-in servlet which has some lifecyle methods > specific to webMacro and good servlet design: > installWMPlugins(); //on init, read the plugin property list (in > dependency order!), initialize > getUser(); // adapter method to get user object making request > authenticate(); // adapter method to authenticate user for this reques= t, > if required > authorize(); // adapter method to authorize user for this request, if= > required > refreshWMPlugins(); // a call back to the servlet to refresh the > services installed > addWMPlugin(); // allow a plugin to be added dynamically > removeWMPlugin(); // allow a plugin to be removed dynamically > dispatchRequest(); // dispatch the request object returning a template= > evaluateTemplate(); // evaluate the template and return a completed pa= ge > for sending. I assume you mean here that a servlet with this design would work "out o= f=20 the box" but would also work as a base class for developers' own=20 servlets. > Instead of loading plugins and objects from a properties file, I > strongly urge the use of a webmacro template file so as to benefit fro= m > caching and the ability to create a list, not a map of plugins to > initialize. To your thinking, how is a plugin different from a context= =20 tool? Um, not at all. I just mean an object to put into the page context. Nice= =20 and simple stuff. We could of course use the ActionServlet concept and allow setup of=20 custom action objects to handle specific requests with more complex=20 behaviour than just returning a template. > b) plug-in contributions. Each of us could contribute some plugins fro= m > our APIs. I can add some physical-independent storage for authenticati= on > and authorization. Yep! SQL helpers, XML helpers, RSS helpers etc. would all be fantastic. = If we have something like this in WM 1.2 then we can expect to get a muc= h=20 larger audience (amongst the Freshmeat crowd etc.) and then hopefully th= e=20 list of plugins/helpers will grow. I think we should settle on a specific name for this =96 plugin or helpe= r=20 for example, rather than context tool. How about: Handler ("Request Handler") =96 a "plugin" object that handles requests = with a certain "action" value Plugin =96 an object placed in to the page context. Any more thoughts on this? Best wishes, Marc |
From: Lane S. <la...@op...> - 2003-01-06 19:27:27
|
marc, ebr has been a terrific asset to wm but wm is a jewel to which many, many have added countless hours and to which others continue to add the fruits of their knowledge. now.... as to your offer below. I, for one, think it would be marvelous if you would produce a slick pdf press release. I think you should add photos of the main contributors as well as their locations on the bottom in the section "for contact information". This would give the press release some pizazz and substance. Put real people behind the wm community. Also, I think it would be a good idea to develop on our wiki site, a list of contacts for pr purposes. I will add some names from my file. as to the web project, my thinking follows along these lines which I think are close to yours. a) a general purpose plug-in servlet which has some lifecyle methods specific to webMacro and good servlet design: installWMPlugins(); //on init, read the plugin property list (in dependency order!), initialize getUser(); // adapter method to get user object making request authenticate(); // adapter method to authenticate user for this request, if required authorize(); // adapter method to authorize user for this request, if required refreshWMPlugins(); // a call back to the servlet to refresh the services installed addWMPlugin(); // allow a plugin to be added dynamically removeWMPlugin(); // allow a plugin to be removed dynamically dispatchRequest(); // dispatch the request object returning a template evaluateTemplate(); // evaluate the template and return a completed page for sending. Instead of loading plugins and objects from a properties file, I strongly urge the use of a webmacro template file so as to benefit from caching and the ability to create a list, not a map of plugins to initialize. To your thinking, how is a plugin different from a context tool? b) plug-in contributions. Each of us could contribute some plugins from our APIs. I can add some physical-independent storage for authentication and authorization. -Lane Marc Palmer wrote: >Hi all, > >Seeing as Eric has done all the hard work for us lazy people in producing >a WM 1.1 release, we should do our most to promote it! > >Nobody seems to be "in charge" of issuing WM press releases. It is vital >that we issue press releases to let people know WM is around, maturing, >and used by some very BIG people (i.e. AltaVista). The more exposure, the >more users we will have. > >I am willing to write and send out this press release. I did it recently >for one of our own products and had some reasonable success (announcement >covered by people like JavaWorld, ITToolbox, Javable, JavaLobby, jGuru >etc.) which generated several thousand hits for us. > >Also, I want to ask a related question because I don't have time to >check if WM comes with a default web application yet, that will server >up templates and provide context tool classes, the class names of which >are loaded from some .properties file? > >If not, I will write this. I have been planning it myself as I need it, >and this could completely change the market for WM. > >Instead of WM just being for web-app/Java developers, it would suddenly >become a tool that any webmaster can download and install, to get >world-class templating of site pages with configurable "plugins" that >they can write in Java or download. > >As such, a repository of general-purpose Java classes that work well in >templates would also be very useful to such people. > >With this I think we can turn WM's user-base from 100s into 1000s. > >So, if someone can fill me in on the above / supply comments, I would be >grateful. I'm thinking of a single servlet in .WAR with WM in WEB-INF/lib >and a way to pass a list of context tool classnames to it, probably via >WebMacro.properties. These would be instantiated at servlet startup, and >put into every page. It would just be a case of using URIs like: > > www.mysite.com/WebMacro?template=mytemplate.wm > >...which is obviously something any webdesigner can understand, and means >they can get the basic advantages of running WM with absolutely NO >programming at all. > >I will run a 1.1 press release by you guys in the next couple of days >(unless somebody else feels they are more qualified for this). I'm no >expert on this stuff, but I've done it before which is something. > >I want to give something back to WM... for me WM has been the gift that >keeps on giving! > >Best wishes, >Marc > > > >------------------------------------------------------- >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 > > > -- Lane Sharman http://opendoors.com Conga, GoodTimes and Application Hosting Services http://opendoors.com/lane.pdf BIO |
From: <kea...@na...> - 2003-01-06 19:25:20
|
Hey Marc, I like your ideas. I've written a sample servlet which does pretty much what you're suggesting, but I never packaged it up as a WAR. I think Lane has done something along these lines as well. My servlet extracts the template name from the extra path info of the request, like http://www.mysite.com/wmlab/mytemplate.wmt I spent some time figuring out how to pass in other stuff from the URL, but then I realized that you can just use CGI form variables for most stuff. The ContextTools stuff already works as you describe, although imho "functions" are even cooler, 'cause you don't need to implement any special interface. Couple this with the #bean directive and you have a pretty decent workbench out of the box for developing WM apps. I've also been working on enhancing the /contrib/datatable stuff to give an out-of-the-box database query and reporting capability. One other thing I've been playing with is a very simple WMScript editor that reports syntax errors and puts the cursor on them. This is still very rough. Anyway, it would be great to kick some ideas around on this. Keats > -----Original Message----- > From: Marc Palmer [mailto:ma...@an...] > Sent: Monday, January 06, 2003 8:50 AM > To: web...@li... > Subject: [Webmacro-devel] Some WM PR stuff > > > > Hi all, > > Seeing as Eric has done all the hard work for us lazy people > in producing > a WM 1.1 release, we should do our most to promote it! > > Nobody seems to be "in charge" of issuing WM press releases. > It is vital > that we issue press releases to let people know WM is around, > maturing, > and used by some very BIG people (i.e. AltaVista). The more > exposure, the > more users we will have. > > I am willing to write and send out this press release. I did > it recently > for one of our own products and had some reasonable success > (announcement > covered by people like JavaWorld, ITToolbox, Javable, > JavaLobby, jGuru > etc.) which generated several thousand hits for us. > > Also, I want to ask a related question - because I don't have time to > check - if WM comes with a default web application yet, that > will server > up templates and provide context tool classes, the class > names of which > are loaded from some .properties file? > > If not, I will write this. I have been planning it myself as > I need it, > and this could completely change the market for WM. > > Instead of WM just being for web-app/Java developers, it > would suddenly > become a tool that any webmaster can download and install, to get > world-class templating of site pages with configurable "plugins" that > they can write in Java or download. > > As such, a repository of general-purpose Java classes that > work well in > templates would also be very useful to such people. > > With this I think we can turn WM's user-base from 100s into 1000s. > > So, if someone can fill me in on the above / supply comments, > I would be > grateful. I'm thinking of a single servlet in .WAR with WM in > WEB-INF/lib > and a way to pass a list of context tool classnames to it, > probably via > WebMacro.properties. These would be instantiated at servlet > startup, and > put into every page. It would just be a case of using URIs like: > > www.mysite.com/WebMacro?template=mytemplate.wm > > ...which is obviously something any webdesigner can > understand, and means > they can get the basic advantages of running WM with absolutely NO > programming at all. > > I will run a 1.1 press release by you guys in the next couple of days > (unless somebody else feels they are more qualified for this). I'm no > expert on this stuff, but I've done it before which is something. > > I want to give something back to WM... for me WM has been the > gift that > keeps on giving! > > Best wishes, > Marc > |