Le mercredi 05 mars 2008 à 12:13 -0800, Nathan Bubna a écrit : > On Wed, Mar 5, 2008 at 5:53 AM, Deinhammer, Guido > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I followed the discussion here on Macros - and thought you might be > > interested in what I have done to overcome most of their shortcomings. > > > > I understand my writing turned out a little lengthy, but if you are > > using macros, it should be worth the read... > > > > Basically I am working on a web-based UI and we use velocity to render > > html. We have a number of fairly complex macros - some are recursive - > > and when I did a check on the memory consumption that finally made me > > rethink whether velocity is suited to what we do at all. The problem is > > that it includes the parsed nodetree of a macro wherever it is called > > (https://issues.apache.org/jira/browse/VELOCITY-223). In our project > > that resulted in up to 10MB of heap memory for a screen and we have > > around 800 of them. This would mean that we can cache only around 15 > > screens in the ResourceCache. > > yeah, we've heard a lot of such stories. there's also the weird > parsing issues with multi-line comments in macros we've been having. > for all the improvements made to them last summer, they still have a > long way to go. > > > This finally made me change all our (mostly generated) velocity > > templates. > > Before that there were a few other inconveniences that we got used to - > > parameter passing is not ideal - we have often well over 20 parameters > > many of them can be defaulted, so the normal macro parameters are not > > very useful for us - but that is easy enough to work around - just pass > > a single map to your macro - and inside the macro you can use a Java > > tool or a user directive to default the values in the argument map with > > values of a second - defaultValue map. > > That made the maros a lot easier to use for us - but the memory problem > > remains. > > Another problem was that the caller cannot pass a body, or velocity > > markup to the macro - that would be very convenient if you want to > > implement e.g. a collapsible section > > (https://issues.apache.org/jira/browse/VELOCITY-558 or > > https://issues.apache.org/jira/browse/VELOCITY-583) > > > > Other's reported using a variable for the name of the macro doesn't > > work. > > > > So I thought instead of using a macro call I could just implement a > > directive that renders another .vm file with the same context and the > > same Writer - similar to parse but with the option of passing > > parameters. So that's what I did. And with the three directives I have > > attached you can do something like this: > > > > #call($myMacro {"arg1": true, "arg2":false}) > > > > The $myMacro variable has to resolve to a fileName (you can set the > > directory for this, so you don't have to give the full path, and you can > > skip the .vm ending). The second parameter is a map that is added to the > > context under the name "args" - the "macro" can access the parameters > > with $args.arg1. The "macro" itself, is nothing but a .vm file > > > > You can also do this: > > > > #callBlock(collapsibleSection {"isCollapsed":$collapsed, "title":"My > > Section"}) > > My section content..... > > #end > > > > Where your collapsibleSection.vm file could look like this: > > > > <table><th><td>$args.title</td></th> > > #if($args.open) > > #content() > > #end > > </table> > > #end > > > > Where the #content() directive will just render the body of the > > callBlock directive - in this case " My section content.....". > > these look like a great improvements on #parse. > > > So have a look at the attached code, if you have similar problems with > > macros - it is quite short and should be easy to understand. > > Maybe something like this should be added for the 1.6 version - or the > > whole macro concept could be converted to a solution like that - leaving > > the existing syntax intact. > > i'm totally interested. no time to look at the code today, but i > would love to have something like #parse but with a little more > control over the variables/namespace. > > > > > > > Best regards, > > > > Guido Deinhammer > > > > Btw: we have also added another cool directive that allows partial page > > rendering...but I didn't have time to write it up yet... > > interesting. seems like new ideas are starting to pop up. :) i have > one i'm excited about, but i'm not quite ready to put it out there for > community vetting. > > in any case, if we can't work some of these new ideas into 1.6 proper, > it would be great to at least get them in 1.6's whiteboard at a very > minimum to make it easier for people to start playing with them.
Let's create the 1_7 branch, and we'll backport thinks that we managed to do in the 1.6 before the release. It's subversion, it's not subversive. It's merge, not submerge ;) We could also create the 2_0 branch right away... Agree? Claude > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
