Fixed a bug in the new conditional code; a condition is false if the return of a method o.equals(Boolean.FALSE) rather than ==.
This release adds some key functionality, and fixes several bugs:
You can also use the boolean ooerators == (equals) and != to compare objects. These do not behave like Java operators do: they rely on Object.equals() rather than object identity to determine equivalence.
A conditional can use any WebMacro Term as its operands. A Term is considered false if it is null, undefined, or equal to the constant Boolean.FALSE; and true otherwise. You are encouraged to use regular boolean primitives in your code as these will be translated to Boolean.TRUE and Boolean.FALSE during introspection.
Finally, you can group expressions based on Terms and these five operators using parentheses, as you would expect. Thus the following is a valid condition: (($User && $User.isOK()) || ($Magic == "foo"))
#set $a = 10
that is equivalent to context.put("a", new Integer(10)). You may
prefix a value with a minus sign to create negative values. Also,
you may construct a Long instead of an Integer by adding the
suffix l or L, as in Java.
An Integer will automatically be converted to an int primitive, so you can use these constants to call methods which require an int argument.
No support is provided for Double, Float, or other values. If you wish to write a numeric value as a string, enclose it in quotation marks. For example, "101L" is a four character string, whereas 101L when used as a Term, is a three digit Integer.
Note that this only applies to Terms: list members, arguments to functions, parameters of directives, etc.; numeric values in running text are unaffected.
As usual, let me know if you find any bugs! I always expect there will be a few--and will put out fixes as soon as I can once they're reported.
Thanks to everyone on the list for all the help!
This is a maintenance release which fixes several bugs:
Other changes: The Macro interface no longer has an isDefined() method, as it wasn't needed. Many classes and methods have had their visibility reduced, to clarify the API and prevent undesirable dependencies.
You will have to recompile your WebMacro servlets to upgrade. You shouldn't have to make any code changes. If you notice a template variable that acesses the WebMacro API no longer works, I probably got over-zealous in removing public visibility somewhere--add it back, and report the bug.
License note: WebMacro is now directly under the GPL, there is no longer any intermediate license. It's simpler this way. The clause stating that feedback you send to the list may be freely used by everyone is now a condition of the list, rather than WebMacro's usage license. This means nothing if you are registered as a commercial developer--and practically nothing if you are using the GPL. (This clause allows me to share feedback with non-GPL users, without worrying about copyright).
As usual, thanks to everyone on the list who helped track down these bugs!
This release fixes two bugs: meaningless exceptions were being logged when TemplatePath has multiple directories; iterator() methods were being ignored by Property introspection when extracting list from object. Also, the com.semiotek.* sources have been moved into the org.webmacro.* package. Minor documentation fixes and updates.
Note that because sources have moved from one package to another, you should recompile your WebMacro applications against this version due to binary incompatibilities. No change to your Java code itself should be necessary, though.
This release fixes several bugs, and improves functionality in some simple but important ways. WebMacro is a lot easier to use now; and better suited for use in production environments.
Here's a list:
Set "TemplateExpireTime" to zero for development and debugging; set it to a non-zero value (10 min recommended) for production use.
In particular, the return type of the handle method has changed, and you can now throw an exception from it on error. This handle method is now identical to the one in the Handler interface.
This is an incompatible change. Any template which had been using a $Form variable as the iterator in a #foreach statement must be changed to use $FormList.
This also should end the problems reported with POST data, and is more consistent with the Servlet API.
You can specify a whole list of paths separated by your platform path separtor (eg: ";" or ":") similar to your CLASSPATH evironment variable. WebMacro will search all directories in this path for a Template.
Also, the name you pass to the TemplateProvider can incldue a subdirectory, such as "foo/hello.wm". This is useful in production environments since it allows you to specify different subdirectories based on the Script Name of your Servlet, allowing you to partition the name space.
One use of these is to undefine a variable by explicitly #setting it to false.
Minor bug fixes: Error messages are now correctly displayed.
Changes in this release are on both the back end and the script side. Many of them have little visible effect, but potentially widespread implications--thus you should thorougly test your applications with the new 0.80 release before putting it into production use.
Here's an overview:
If you prefer the old way, Reactor still exists (now a subclass of WMServlet) and behaves exactly as before--with Reactor you implement a Handler and register Reactor as your servlet.
The WMServlet base class manages an instance of ResourceBroker that is shared between all instances, so you don't lose any of the benefit of working in the WebMacro framework.
The big difference is that they are statically evaluated at parse time, not dynamically evaluated against your context. They are also available to your Handler or WMServlet subclass via the Template.getParam(name) call.
This allows your Handler or WMServlet to query a template to determine how information should be processed in order to correctly populate the WebContext. One use of this feature would be to implement a WMServlet subclass that behaves like a server-side-include. In the future WebMacro will probably ship with such a subclass as an example application.
#set $myList = [ "first", second, $third ]
You could also use the initializer syntax directly in a #foreach
loop. List initializations can be nested to define lists of lists
if you so desire. You can also use the list initializer syntax
with a #param directive to pass a list back to the Handler/WMServlet.
## this is a comment
The ## must appear as the first non-whitespace on a line, like any
other directive. Unfortunately the current implementation is not
completely whitespace clean--you will notice an extra blank line
in the output in place of your comment. This should be fixed in a
future release.
$myVar.property.method( "param", $param, $$param ).property
When you name an overloaded method, WebMacro will pick the most
specific according to the real types of the parameters at runtime.
This is slightly different than Java, which would pick the most
specific according to the declared types of the objects at
compile time--but WebMacro is not a strongly typed language, and
this approximation does what you expect 99.9% of the time.
Please note that method invocation should be used only when there is no viable way to use a regular property name. For one thing it is slower. For another, it binds your template to specific knowledge about the method signatures of the target object--leaving the programmer with less flexibility in providing the information you requested.
In conjunction with method calls, this means you should be able to write things like $customer.isPaidUp() in conditionals in the templates now.
Macros are now recursively evaluated--if evaluate() returns a Macro, it will be re-evaluated until a non-Macro is obtained.
You can throw an exception out of Handler.init() if you need to now, to indicate that it failed to initialize.
Variables now evaluate to whatever object they actually represent. They used to always evaluate to a String. This is a subtle change which should have no effect, but has the potential to break things.
Fixed up the display of some error messages and other things.
Changes in this release are all on the back end Java processing side, but they are substantial:
The ResourceBroker shares resources between handlers, caches them, expires them over time, and segregates providers of information from their consumers.
It also introduces the possibility of concurrency within the same servlet, as it is capable of resolving a request for information asynchronously. For example, you could open a network connection to a database while reading your template. Your handler won't block until it actually attempts to access the requested information.
First, you can now use an array/enumeration/iterator as a list (previously you had to have an "elements()" or "iterator()" method that returned one). Now if you have a getCustomers() method that returns an enumeration, you can use that method with #foreach to iterate through your customers.
Second, "binary" property introspection is now supported. Basic introspection means the presence of a getFoo method means $Foo will work as a variable. "Binary" introspection means that if you have a getFoo("Bar") method $Foo.Bar works. This is especially useful in the case of methods like getHeader("Referer"). It also works for setting a value: setThing("name", value) can be called as #set Thing.name = value from the script language.
This release is better tested and easier to use than the previous release. It also has some hope of running under NT, as file separator and line separator bugs have been fixed. It has been tested under Linux and FreeBSD, and will be tested under NT and Solaris soon (but hasn't yet been).
We've included some examples for you to look at, and cleaned up the API documentation quite a bit--however we haven't got around to writing a proper user manual yet either for graphics designers or programmers.
Please bear with us -- this is an experimental early release. We believe it will work for you, but can't promise anything. In particular you probably should use it for production systems yet, as it may contain bugs. You've been warned.
See the LICENSE file for details about your rights and obligations with respect to the software (for example, your right to use it under the GPL), plus legal disclaimers, and so forth.
If you are interested in using WebMacro, we'd like you to join our mailing list and send us some feedback: webmacro-request@webmacro.org.
We hope you like it!