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: Brian G. <br...@qu...> - 2003-07-21 20:48:07
|
>I've removed all the Filter crap from my working copy of the sources. This >has been broken for a very long time. Any objections to me committing these >changes? THat was on my list to prune too. I can do it or you can; just sync first to make sure you've got a consistent copy of the recent pruning. Let me know if you want me to do it. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Eric B. R. <eb...@tc...> - 2003-07-21 20:13:46
|
On Monday, July 21, 2003, at 12:55 PM, Keats wrote: > I've removed all the Filter crap from my working copy of the sources. > This > has been broken for a very long time. Any objections to me committing > these > changes? get rid of it! eric > > Keats > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Brian G. <br...@qu...> - 2003-07-21 20:06:01
|
>I agree with Brian that the lazy instantiation is critical. (I don't >understand the bit about the previous implementations not exploiting this -- >I'm pretty sure they did.) The previous implementation did lazily instantiate the tool, but that was only a small part of its cost. The previous implementation relied heavily on Context pooling, which had a cost. Constructing a Context was expensive, as you still had to load the map of known tools into the Context, even if they were not instantiated. So you either paid the cost in pooling or in construction (or both.) -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Keats <ke...@ea...> - 2003-07-21 19:35:32
|
SSBhZ3JlZSB3aXRoIEJyaWFuIHRoYXQgdGhlIGxhenkgaW5zdGFudGlhdGlvbiBpcyBjcml0aWNh bC4gICAoSSBkb24ndA0KdW5kZXJzdGFuZCB0aGUgYml0IGFib3V0IHRoZSBwcmV2aW91cyBpbXBs ZW1lbnRhdGlvbnMgbm90IGV4cGxvaXRpbmcgdGhpcyAtLQ0KSSdtIHByZXR0eSBzdXJlIHRoZXkg ZGlkLikNCg0KSW4gYWRkaXRpb24sIHdlIG5lZWQgdG8gY29udGludWUgdG8gc3VwcG9ydCAic3Rh dGVmdWwiIGNvbnRleHQgdG9vbHMgKHRvb2xzDQp0aGF0IGhhdmUgYWNjZXNzIHRvIHRoZSBjdXJy ZW50IGNvbnRleHQpLg0KDQpUaGVyZSBpcyBzdGlsbCByb29tIGZvciBpbXByb3ZlbWVudCBoZXJl LiAgU3RhdGVsZXNzIHRvb2xzIHNob3VsZG4ndCBiZQ0KcmVxdWlyZWQgdG8gY29uZm9ybSB0byBh IENvbnRleHRUb29sIGludGVyZmFjZSwgYW5kIHN0YXRpYyB0b29scyBzaG91bGQgYmUNCnN1cHBv cnRlZC4NCg0KRnVuY3Rpb25zIGNhbiBhY3R1YWxseSBoYW5kbGUgdGhlIHN0YXRlbGVzcyBzdHVm ZiBwcmV0dHkgbmljZWx5LCBzbyB3ZSBtYXkNCm5vdCByZWFsbHkgbmVlZCB0aGUgc3RhdGVsZXNz IHRvb2xzIGF0IGFsbC4gICBIb3dldmVyIGl0IG1pZ2h0IGJlIG5pY2UgdG8NCmtlZXAgdGhlbSBm b3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuDQoNCkkndmUgYmVlbiB0aGlua2luZyBhYm91dCBj cmVhdGluZyBzdGF0ZWZ1bCBmdW5jdGlvbnMuICBUaGUgaWRlYSBpcyB0aGF0IGlmDQp0aGUgZmly c3QgYXJndW1lbnQgdG8gYSBmdW5jdGlvbiBpcyBhIENvbnRleHQgKG9yIHN1YmNsYXNzKSB0aGVu IGhhdmUgdGhlDQppbnRyb3NwZWN0aW9uIGVuZ2luZSBzdXBwbHkgaXQgYXV0b21hZ2ljYWxseS4g IEUuZy4sDQoNCnB1YmxpYyBjbGFzcyBMb2NhbGl6ZXIgew0KICAgIHB1YmxpYyBTdHJpbmcgbG9j YWxpemUob3JnLndlYm1hY3JvLnNlcnZsZXQuV2ViQ29udGV4dCB3YywNCmphdmEudXRpbC5EYXRl IGRhdGUpew0KICAgICAgICByZXR1cm4gamF2YS50ZXh0LkRhdGVGb3JtYXQuZ2V0RGF0ZUluc3Rh bmNlKA0KICAgICAgICAgICAgamF2YS50ZXh0LkRhdGVGb3JtYXQuU0hPUlQsDQp3Yy5nZXRSZXF1 ZXN0KCkuZ2V0TG9jYWxlKCkpLmZvcm1hdChkYXRlKTsNCiAgICB9DQp9DQoNCiAgICBQdXQgdGhp cyBpbnRvIHRoZSB0ZW1wbGF0ZSwgbGlrZToNCg0KICAgIGNvbnRleHQucHV0Q29udGV4dEZ1bmN0 aW9uKCJsb2NhbGl6ZSIsIExvY2FsaXplci5jbGFzcywgImxvY2FsaXplIik7DQoNCiAgICBvcg0K DQogICAgIyBXZWJNYWNyby5wcm9wZXJ0aWVzDQogICAgQ29udGV4dEZ1bmN0aW9ucy5sb2NhbGl6 ZT1vcmcud2VibWFjcm8udXRpbC5Mb2NhbGl6ZXIubG9jYWxpemUNCg0KICAgQW5kIHRoZW4gdXNl IGl0IGluIGEgdGVtcGxhdGU6DQoNCiAgICRsb2NhbGl6ZSgkZGF0ZSkNCg0KVGhpcyBzaG91bGQg YmUgcXVpdGUgbGlnaHR3ZWlnaHQsIGFuZCBjb3VsZCBhbGxvdyB1cyB0byByZXBsYWNlIGFsbCBv ZiBvdXINCnRvb2xzIHdpdGggZnVuY3Rpb25zLg0KDQpUaG91Z2h0cz8NCg0KS2VhdHMNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkJyaWFuIEdvZXR6IiA8YnJpYW5AcXVp b3RpeC5jb20+DQpUbzogIkxhbmUgU2hhcm1hbiIgPGxhbmVAb3BlbmRvb3JzLmNvbT4NCkNjOiAi RW5kcmUgU3T4bHN2aWsiIDx3ZWJtYWNyb0BzdG9sc3Zpay5jb20+OyAiRXJpYyBCLiBSaWRnZSIN CjxlYnJAdGNkaS5jb20+OyA8d2VibWFjcm8tZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0K U2VudDogTW9uZGF5LCBKdWx5IDIxLCAyMDAzIDI6NTIgUE0NClN1YmplY3Q6IFJlOiBbV2VibWFj cm8tZGV2ZWxdIEZ3ZDogW1dlYk1hY3JvLWN2c10NCndlYm1hY3JvL3NyYy9vcmcvd2VibWFjcm8v dXRpbCBJbnRNYXAuamF2YSwxLjQsTk9ORQ0KUXVldWVXcml0ZXIuamF2YSwxLjgsTk9ORSBTaW1w bGVTdGFjay5qYXZhLDEuNSxOT05FDQpTcGFyc2VBcnJheUl0ZXJhdG9yLmphdmEsMS40LE5PTkUg U3BhcnNlUHJvcGVydGllcy5qYXZhDQoNCg0KPiA+IEZpcnN0LCBhIGNvbnRleHQgdG9vbCBnb2Vz IGF3YXkgaW4gcmVsZWFzZSAyLiBJdCBpcyBqdXN0IGEgY29udGV4dA0KPiA+IG9iamVjdCBsaWtl IGFueSBvdGhlci4NCj4gPg0KPiA+IFNlY29uZCwgdGhlIG9ubHkgd2F5IHRvIGF1dG9tYXRpY2Fs bHkgZ2V0IGFuIG9iamVjdCBpbiB0aGUgY29udGV4dCBpcyB0bw0KPiA+IG1ha2UgYSBkZWNsYXJh dGlvbiBpbiBXZWJNYWNyby5wcm9wZXJ0aWVzIG5vdCBXZWJNYWNyby5kZWZhdWx0czoNCj4NCj4g VGhlIHN1cHBvcnQgd2Ugbm93IGhhdmUgZm9yIGxhenkgbG9hZGluZyBvZiB0b29scyBtYWtlcyBD b250ZXh0DQo+IGNvbnN0cnVjdGlvbiBtdWNoIGxpZ2h0ZXIgd2VpZ2h0LiAgVGhlIHRoaW5nIHRo YXQgZGlmZmVyZW50aWF0ZXMNCj4gY29udGV4dCB0b29scyBmcm9tIG9yZGluYXJ5IG9iamVjdHMg aXMgdGhhdCB0aGV5ICJrbm93IiB0aGF0IHRoZWlyDQo+IGluc3RhbnRpYXRpb24gY2FuIGJlIGRl ZmVycmVkIHVudGlsIHRoZXkncmUgbmVlZGVkLiAgVGhlIHByZXZpb3VzDQo+IGltcGxlbW50YXRp b24gZGlkbid0IGV4cGxvaXQgdGhpcywgYnV0IHRoZSBjdXJyZW50IG9uZSBkb2VzLiAgVGhpcyBp cw0KPiBhIHVzZWZ1bCB0aGluZyB0byBrZWVwLg0KPg0KPiBJbiBvdGhlciB3b3JkcywgdGhlIHJ1 bnRpbWUgY29zdCB0byB1c2VycyBvZiBoYXZpbmcgY29udGV4dCB0b29scw0KPiBkZWNsYXJlZCB3 aGljaCB0aGV5J3JlIG5vdCBnb2luZyB0byB1c2UgdW5kZXIgdGhlIGN1cnJlbnQNCj4gaW1wbGVt ZW1lbnRhdGlvbiBpcyB6ZXJvLiAgQW55IHJlcGxhY2VtZW50IHNob3VsZCBoYXZlIHRoZSBzYW1l DQo+IGNoYXJjdGVyaXN0aWMuDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBTRi5uZXQgZW1haWwgaXMgc3Bv bnNvcmVkIGJ5OiBWTSBXYXJlDQo+IFdpdGggVk13YXJlIHlvdSBjYW4gcnVuIG11bHRpcGxlIG9w ZXJhdGluZyBzeXN0ZW1zIG9uIGEgc2luZ2xlIG1hY2hpbmUuDQo+IFdJVEhPVVQgUkVCT09USU5H ISBNaXggTGludXggLyBXaW5kb3dzIC8gTm92ZWxsIHZpcnR1YWwgbWFjaGluZXMgYXQgdGhlDQo+ IHNhbWUgdGltZS4gRnJlZSB0cmlhbCBjbGljayBoZXJlOiBodHRwOi8vd3d3LnZtd2FyZS5jb20v d2wvb2ZmZXIvMzQ1LzANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gV2VibWFjcm8tZGV2ZWwgbWFpbGluZyBsaXN0DQo+IFdlYm1hY3JvLWRldmVs QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s aXN0cy9saXN0aW5mby93ZWJtYWNyby1kZXZlbA0KDQo= |
|
From: Lane S. <la...@op...> - 2003-07-21 18:54:30
|
Marc Palmer wrote: > > Guys, > > I've thought about this some more and I just cannot see why people > have an objection to this idea - that isn't "oh but it's a hassle and > we have better things to do". I do not think there is an objection per se. It is just that directives have been cast into a kind of parsing model which makes the leading space a protocol indicator: This thing starting with a # is probably a directive and not a text glob. Looking at your example below, I agree it makes some sense to eliminate the leading space but how hard will that be to get the parser right??? It could be really hard. -Lane > > > To focus minds a little, let's reduce the issue to this simple question. > > What rational justification can anybody give for keeping different > whitespace behaviour between the following to constructs: > > <input name="field1" value="$HTMLEscape($value)"> > <input name="field2" value="#myMacro($value)"> > > i.e. what possible sensible explanation could we offer a page writer > for the above not actually working, and that they must instead do: > > <input name="field1" value="$HTMLEscape($value)"> > <input name="field2" value=" #myMacro($value)"> > > Sure "it's just a space", but it's a consistency issue more than > anything. Plus the fact that they have to put the space in there even > though it will always be removed. > > I would be very grateful if anybody could point out some reason why > this really isn't possible or desirable, because for the life of me I > cannot see it. The current behaviour is just another small obstacle to > learning the script. > > Marc -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga Java Software Portal: http://opendoors.com |
|
From: Brian G. <br...@qu...> - 2003-07-21 18:52:52
|
> First, a context tool goes away in release 2. It is just a context > object like any other. > > Second, the only way to automatically get an object in the context is to > make a declaration in WebMacro.properties not WebMacro.defaults: The support we now have for lazy loading of tools makes Context construction much lighter weight. The thing that differentiates context tools from ordinary objects is that they "know" that their instantiation can be deferred until they're needed. The previous implemntation didn't exploit this, but the current one does. This is a useful thing to keep. In other words, the runtime cost to users of having context tools declared which they're not going to use under the current implemementation is zero. Any replacement should have the same charcteristic. |
|
From: Lane S. <la...@op...> - 2003-07-21 18:46:46
|
Let's then create a cvs module called OptionalTools and migrate code to this module that is not required by WebMacro. A lot of code will end up there and it could make using WebMacro unfriendly: I have to include two jars and search two doc bases... Regarding context tools. How does this sound: First, a context tool goes away in release 2. It is just a context object like any other. Second, the only way to automatically get an object in the context is to make a declaration in WebMacro.properties not WebMacro.defaults: ContextHelper.NameFoo=ClassFoo ContextHelper.NameBar=ClassBar WebMacro.getContext(), as a convenience, places these objects in the context under the name declared. It is the responsibility of the owner of the context to manage any clean-up on these classes when the context is no longer needed. And, this is not the responsibility of WM to know this point in time. -Lane Brian Goetz wrote: >>I don't like code that's just "laying around" for just a few people to >>use. I also think that all the macros should go .. go into some separate >>util jar or tarball. >> >> > >I think this makes a lot of sense. > > > >------------------------------------------------------- >This SF.net email is sponsored by: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the >same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga Java Software Portal: http://opendoors.com |
|
From: Lane S. <la...@op...> - 2003-07-21 18:29:08
|
Hi Keats,
This looks really promising. I am very eager to try this out; and, I
would be willing to help with unit test execution, development.
-Lane
Keats wrote:
>I'm about ready to commit the #templet and #eval directives. I added a
>couple of things to #eval. In the new context of the #eval I add the
>following variables: $OuterVars, $EvalDepth, and $Self.
>
>$OuterVars is a reference to the the _variables Map of the top level calling
>context.
>
>$EvalDepth and $Self are used for recursive templets. Currently the max
>recursion depth is hard-coded at 100, but of course this could easily be
>configurable.
>
>I'll try to cook up some unit tests and commit this in the next day or so.
>Please give feedback.
>
>Here's a simple example of a recursive templet:
>
>#templet $treeRenderer {
> <b>$node.Title</b>
> #if ($List.size($node.Children) > 0){
> <ul>
> #foreach $Child in $node.Children {
> <li>
> #eval $Self using {"node": $Child }
> </li>
> }
> </ul>
> }
>}
>#eval $treeRenderer using {"node": $treeRoot }
>
>(Note that in this example $Self is the same as $OuterVars.treeRenderer.)
>
>A simple tree is construction for this example is shown below:
>
>#set $grandchild1 = {
> "Title" : "First Grandchild",
> "Children" : []
>}
>
>#set $grandchild2 = {
> "Title" : "Second Grandchild",
> "Children" : []
>}
>
>#set $child1 = {
> "Title" : "Child 1",
> "Children" : []
>}
>
>#set $child2 = {
> "Title" : "Child 2",
> "Children" : [$grandchild1, $grandchild2]
>}
>
>#set $treeRoot = {
> "Title" : "Root Node",
> "Children" : [ $child1, $child2]
>}
>
>Keats
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
--
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
Java Software Portal: http://opendoors.com
|
|
From: Keats <ke...@ea...> - 2003-07-21 16:56:11
|
I've removed all the Filter crap from my working copy of the sources. This has been broken for a very long time. Any objections to me committing these changes? Keats |
|
From: Marc P. <ma...@an...> - 2003-07-21 16:30:47
|
Forgot to mention this - Ignition running: http://www.anyware.co.uk:8080/ignition/ The mail demos will probably only work if the to/from address is one of my addresses, but see how you go anyway - we don't have an open relay but as ignition is on the mail "localhost" it may allow it. Also the SQL demo is not setup - no query or db conn defined. Marc -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-07-21 16:20:22
|
Hi all, OK - hopefully some more of you will be able to find the time to download and install Ignition to contribute to the voting process. I plan one more alpha before going public with a beta - the remaining major functionality for alpha 4 being authentication. http://www.wangjammers.org/ignition For an idea of the new stuff since Alpha2, some excerpts from the readme: At this time Ignition has been verified to work with: * Tomcat 4.1.18 * Tomcat 4.1.24 * Resin 2.1.10 At this time Ignition has been shown to NOT to work with: * Resin 3.x beta (due to apparent classloader bugs in Resin) [snip] What's new in this version ----------------------------------------------------------------------- * New - TransactionPlugin interface and automatic commit/rollback of all transaction types at the end of an action chain * New - JDBCTransactionPlugin implementation using JNDI lookups to DataSource(s) * New - Field validation using MetadataPlugin(s). * New - Field validation plugin implemented with Metalizer library (included - no good documentation for Metalizer yet though, but see http://www.wangjammers.org/metalizer). * New - Documentation for validation/metadata and transactions. * New - $Ignition.executeInline mechanism to execute Actions in line while rendering response. * New - Demos now included in main .war distribution, no separate download. To disable/delete demoes edit WEB- INF/classes/ignition.properties and remove the module.demos= line. * Improved - Access to action descriptor object parameters changed from #set $action.ParamName to #set $action.Parameters.ParamName * Improved - Access to action descriptor object form field names for parameters changed from $action.FieldName.ParamName to $action.FormFieldName.ParamName * Improved - Rationalised Configuration. All Actions/RequestPlugin etc. are just 'plugins' in config terms, so the property prefix is now just 'plugin.' for all - so ALL CUSTOM CONFIG FILES MUST BE CHANGED * Improved - Enhanced internal plugin management with full extensibility * Alert - Config files must no longer include .action/.requestplugin/.actionplugin property prefixes - just plugin.[name]= now, Ignition auto-detects type. * New - RandomHelper for selection of random items from a list * Alert - Changed contract for all blackboard access - caller must synchronise on blackboard. * New - Separation of fields from action parameters. Fields are available to all plugins and actions, Parameters only to the action they apply to. * New - Now that fields are separate, parameters set but not declared by the action will now cause an error. * Improved - EmailRequestParameters action in the light of new fields separation - options to send either all HTTP req parameters (legacy mode) or just Ignition fields. * Bug Fix - default plugin property values not being set. * Bug Fix - documentation templates to URLEncode bookmark links (Thanks to Keats Kirsch!) * Bug Fix - new visitor flag was incorrectly being cleared after first request in first visit * Moved getHelperInfo up into Plugin interface from RequestAwarePlugin interface * Improved startup logging * Improved error handling - page render failures due to WM exceptions now show the Baby of Consolation page. * Includes new pre-alpha WebMacro build with binary accessor set fixed and no context pooling etc. -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
|
From: Keats <ke...@ea...> - 2003-07-21 15:26:26
|
I'm about ready to commit the #templet and #eval directives. I added a
couple of things to #eval. In the new context of the #eval I add the
following variables: $OuterVars, $EvalDepth, and $Self.
$OuterVars is a reference to the the _variables Map of the top level calling
context.
$EvalDepth and $Self are used for recursive templets. Currently the max
recursion depth is hard-coded at 100, but of course this could easily be
configurable.
I'll try to cook up some unit tests and commit this in the next day or so.
Please give feedback.
Here's a simple example of a recursive templet:
#templet $treeRenderer {
<b>$node.Title</b>
#if ($List.size($node.Children) > 0){
<ul>
#foreach $Child in $node.Children {
<li>
#eval $Self using {"node": $Child }
</li>
}
</ul>
}
}
#eval $treeRenderer using {"node": $treeRoot }
(Note that in this example $Self is the same as $OuterVars.treeRenderer.)
A simple tree is construction for this example is shown below:
#set $grandchild1 = {
"Title" : "First Grandchild",
"Children" : []
}
#set $grandchild2 = {
"Title" : "Second Grandchild",
"Children" : []
}
#set $child1 = {
"Title" : "Child 1",
"Children" : []
}
#set $child2 = {
"Title" : "Child 2",
"Children" : [$grandchild1, $grandchild2]
}
#set $treeRoot = {
"Title" : "Root Node",
"Children" : [ $child1, $child2]
}
Keats
|
|
From: Marc P. <ma...@an...> - 2003-07-21 11:19:29
|
Guys,
I've thought about this some more and I just cannot see why people have an
objection to this idea - that isn't "oh but it's a hassle and we have
better things to do".
To focus minds a little, let's reduce the issue to this simple question.
What rational justification can anybody give for keeping different
whitespace behaviour between the following to constructs:
<input name="field1" value="$HTMLEscape($value)">
<input name="field2" value="#myMacro($value)">
i.e. what possible sensible explanation could we offer a page writer for
the above not actually working, and that they must instead do:
<input name="field1" value="$HTMLEscape($value)">
<input name="field2" value=" #myMacro($value)">
Sure "it's just a space", but it's a consistency issue more than anything.
Plus the fact that they have to put the space in there even though it will
always be removed.
I would be very grateful if anybody could point out some reason why this
really isn't possible or desirable, because for the life of me I cannot see
it. The current behaviour is just another small obstacle to learning the
script.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-21 09:24:35
|
On Mon, 21 Jul 2003 02:01:51 -0700, Brian Goetz <br...@qu...> wrote: >> I don't like code that's just "laying around" for just a few people to >> use. I also think that all the macros should go .. go into some separate >> util jar or tarball. > > I think this makes a lot of sense. Well, if you look at http://www.webmacro.org/NextRelease you will see that I suggest exactly this for 2.0 - a separate webmacro-optional jar download for all the extra tools, directives (and macros). -- Marc Palmer Contract Java Consultant/Developer w a n g j a m m e r s java and web software design experts with an ethical outlook http://www.wangjammers.org |
|
From: <En...@St...> - 2003-07-21 09:08:35
|
Seen this? --=20 Mvh, Endre St=F8lsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ ---------- Forwarded message ---------- Date: Wed, 16 Jul 2003 21:39:36 -0700 From: Nathan Bubna <na...@es...> Reply-To: Jakarta General List <ge...@ja...> To: ann...@ja... Subject: [ANNOUNCEMENT] Velocity Tools 1.0 released The Velocity team is happy to announce the release of Velocity Tools 1.0. Velocity Tools is a collection of Velocity subprojects offering servlets = and tools for rapid, clean web development with Velocity, tools for using Vel= ocity with Struts, and a set of generic tools to help with any Velocity project= . Both source (http://jakarta.apache.org/site/sourceindex.cgi) and binary (http://jakarta.apache.org/site/binindex.cgi) distributions are available through the the usual Apache mirror sites. Please remember to verify the signatures of the distribution using the keys found on the main Apache we= b site (http://www.apache.org/dist/jakarta/velocity-tools/KEYS) when downlo= ading from a mirror. Please see the Velocity Tools website (http://jakarta.apache.org/velocity/tools/index.html) for more informatio= n. Nathan Bubna na...@es... --------------------------------------------------------------------- To unsubscribe, e-mail: ann...@ja... For additional commands, e-mail: ann...@ja... |
|
From: Brian G. <br...@qu...> - 2003-07-21 09:02:28
|
> I don't like code that's just "laying around" for just a few people to > use. I also think that all the macros should go .. go into some separate > util jar or tarball. I think this makes a lot of sense. |
On Fri, 18 Jul 2003, Lane Sharman wrote:
| SparseProperties is a very useful property class file which is
| referenced in the macros/ tree.
|
| It is a small class but is very useful in processing templates in which
| you do not know if a property is present or not:
|
| Hello $Profile.Name,
|
| would return a "" or whatever you specify as the default if get("Name")
| returned a null.
|
| I use it a lot in my webmacro applications.
I don't like code that's just "laying around" for just a few people to
use. I also think that all the macros should go .. go into some separate
util jar or tarball.
The WM is not a toolchest of smart little java.util classes. Any smart
Collections classes can for example be donated to Apache's Jakarta Commons
Collections Compontent or similar packages - or put into some separate
util download.
I even think that such things (tool classes and tool WM-macros) would
get -more- usage if put in a separate download, than if it is bundled with
the actual WM download. Who goes around poking for util classes or
whatever hidden away in the class-hierarchy in some random engine they've
downloaded?
WM is a template engine. Keep it clean and tidy.
Endre.
|
|
From: <web...@st...> - 2003-07-21 08:20:24
|
On Fri, 18 Jul 2003, Lane Sharman wrote: | btw: A context can have a vey long lifetime: | | It can be populated and then reused as a fixture against many templates | over the life of a session, a user, a transaction. | | When it is dereferenced, if the GC takes care of all the work, I am | inclined to bag any destroy methods as being the responsibility of the | context creator, populator. Hear hear! (Isn't this what one shoul say - like "I wholeheartedly agree"?!) (At least if I understood you correctly!) ;) If -you- put anything into the context (even tools), then -you- should be responsible enough to iterate through them and do the destruction - if that is really needed - don't throw all this responsibility over every single user of WebMacro. --=20 Mvh, Endre St=F8lsvik 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-07-21 05:51:07
|
Lane Sharman wrote: > I will run this unit test case down... > > [junit] Running org.webmacro.template.TestParseInclude > [junit] Tests run: 11, Failures: 0, Errors: 5, Time elapsed: 1.64 sec > [junit] TEST org.webmacro.template.TestParseInclude FAILED commit in. Be sure to do frequent updates to your local image to stay in sync. -Lane > > > -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga Java Software Portal: http://opendoors.com |
|
From: Lane S. <la...@op...> - 2003-07-19 23:10:59
|
I will run this unit test case down... [junit] Running org.webmacro.template.TestParseInclude [junit] Tests run: 11, Failures: 0, Errors: 5, Time elapsed: 1.64 sec [junit] TEST org.webmacro.template.TestParseInclude FAILED -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga Java Software Portal: http://opendoors.com |
|
From: Lane S. <la...@op...> - 2003-07-19 22:32:31
|
Marc Palmer wrote: > On Fri, 18 Jul 2003 20:00:39 -0700, Lane Sharman <la...@op...> > wrote: > >> I think the test case has been modified errantly. >> > > > However, some of us were wondering if we can support ButtingIn#if > ($foo) ... now that relaxed directive support is there. is it now? has been ever? Browsers chew up leading white space. So, I guess I do not see why we cannot do this as well. I have achieved really nicely indented Java class files with WM. Personally, the principal issue for WM is this: Creating a world class text processing engine and making it a standard in world class products. We can't do the latter without the former but in reading the posts, Brian is making some kick ass improvements to the code base which result in a clean programming model. It is on top of this model that things like Ignition and Conga will rock. I guess I disagree with you marc on your assessment to date. I think release 2 is heading in the right direction. I don't thing we have checked in templet/eval or even if this has been done. There are a couple of other things we need to nail down. My gig with the mouse is done and I have every intention of making some solid cotributions to WM as a product technology in the next few weeks. Lane > > > Surely relaxed directive support also allows non-directive # use after > any non-WS char? In which case, we should be able to remove the parser > requirement for WS before directives, making life easier for template > writers. > > If this was done, it would also allow some neat improvements to > whitespace handling in the future - as that was one of the items on > the 2.0 NextRelease wishlist too. > > For example, if we don't *require* WS before a directive any more, > then we have the opportunity to make directives not eat leading > whitespace - i.e. execute precisely "inline" - where you know the > output of the directive will start exactly where the "#" of the > directive is in your template stream. It couldn't be more > straightforward for the user. > > That would certainly seem more intuitive, because that is in effect > what happens with "$propertyName" expansion. Of course it would have > complications with indented script code - but we can probably come up > with a solution such as stripping WS only if the directive is preceded > only by WS on the current line. > > I know this kind of talk is always unpopular (I've raised enough > issues like this to know), but we should seriously entertain such > thoughts in the spirit of improvement, as the underlying code changes > are beginning to facilitate such improvements. Otherwise, what are the > real changes end- users will see in WM 2.0? What will I put in the > press release? "Underlying code much improved, performance may be > better or slightly worse but with increased maintainability"? > > ...and what we want, after all, is a script language that is as easy > to use as possible, without strange rules about where you place things. > > Marc -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga Java Software Portal: http://opendoors.com |
|
From: Brian G. <br...@qu...> - 2003-07-19 10:06:29
|
> > I think a Destroyable approach would make sense - we make the context do > > "if (tool instanceof Destroyable)" when the tool is created, and if so add > > it to a List. > > I think instanceof-tests are very costly (at least I vaguely remember Brian > saying this sometimes) and one of the goals was to make context/tool creation > less costly. Its OK if instantiating a tool that you _use_ costs something (instanceof got a lot cheaper in 1.3). Instanceof is mostly free now unless you're doing them on the critical path (which tool initialization certainly is not.) |
|
From: Sebastian K. <seb...@mu...> - 2003-07-19 09:57:11
|
Hi, On Friday 18 July 2003 18:22, Marc Palmer wrote: > I think a Destroyable approach would make sense - we make the context do > "if (tool instanceof Destroyable)" when the tool is created, and if so add > it to a List. I think instanceof-tests are very costly (at least I vaguely remember Brian saying this sometimes) and one of the goals was to make context/tool creation less costly. However, we could do this check already in the broker, when the list of tools is read from configuration by using reflection: In the configuration files the classes for context tools are given so we can check if they implement Destroyable without instantiating them. We could then save this information as a boolen and check this boolean on tool creation, which should be cheaper than the instanceof check. Together with the aquire/release methods this would give almost no overhead for users who don't need it. Sebastian -- Sebastian Kanthak PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html |
|
From: Marc P. <ma...@an...> - 2003-07-19 09:05:29
|
On Fri, 18 Jul 2003 20:00:39 -0700, Lane Sharman <la...@op...>
wrote:
> I think the test case has been modified errantly.
>
> I have examined and worked a lot of the test cases. I have some
> recollection.
>
> I have never seen
> ButtingIn#if ($foo) {....}
>
> The # is always preceded by white space or starts a new line.
>
> Relaxed directive processing takes care of:
>
> <table color=#ccddee>
Lane - if you read a head a few posts on this thread you'll see we already
covered that, and the test has been fixed.
However, some of us were wondering if we can support ButtingIn#if ($foo)
... now that relaxed directive support is there.
Surely relaxed directive support also allows non-directive # use after any
non-WS char? In which case, we should be able to remove the parser
requirement for WS before directives, making life easier for template
writers.
If this was done, it would also allow some neat improvements to whitespace
handling in the future - as that was one of the items on the 2.0
NextRelease wishlist too.
For example, if we don't *require* WS before a directive any more, then we
have the opportunity to make directives not eat leading whitespace - i.e.
execute precisely "inline" - where you know the output of the directive
will start exactly where the "#" of the directive is in your template
stream. It couldn't be more straightforward for the user.
That would certainly seem more intuitive, because that is in effect what
happens with "$propertyName" expansion. Of course it would have
complications with indented script code - but we can probably come up with
a solution such as stripping WS only if the directive is preceded only by
WS on the current line.
I know this kind of talk is always unpopular (I've raised enough issues
like this to know), but we should seriously entertain such thoughts in the
spirit of improvement, as the underlying code changes are beginning to
facilitate such improvements. Otherwise, what are the real changes end-
users will see in WM 2.0? What will I put in the press release? "Underlying
code much improved, performance may be better or slightly worse but with
increased maintainability"?
...and what we want, after all, is a script language that is as easy to use
as possible, without strange rules about where you place things.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Lane S. <la...@op...> - 2003-07-19 03:25:29
|
btw: A context can have a vey long lifetime:
It can be populated and then reused as a fixture against many templates
over the life of a session, a user, a transaction.
When it is dereferenced, if the GC takes care of all the work, I am
inclined to bag any destroy methods as being the responsibility of the
context creator, populator.
Lane
Marc Palmer wrote:
> On Fri, 18 Jul 2003 12:04:01 -0400, Eric B. Ridge <eb...@tc...> wrote:
>
>> On Friday, July 18, 2003, at 11:50 AM, Lane Sharman wrote:
>>
>>> I really like the interface signature Destroyable and use this
>>> pattern all the time.
>>>
>>> The implementation signals it needs to be destroyed and the shutdown
>>> sequence tests and invokes the method defined in the Destroyable
>>> Interface.
>>
>>
>> isn't the issue here that we (read: Brian) doesn't want a "shutdown
>> sequence" other than standard java finalization?
>
>
> That's what I thought too - but then Brian proposed this
> Destructor/Destroyable approach.
>
> I think a Destroyable approach would make sense - we make the context
> do "if (tool instanceof Destroyable)" when the tool is created, and if
> so add it to a List.
>
> Then, we still need some "context is finished with" concept and then
> the context calls all the Destroyables in the list.
>
> I think really the "when is the context finished with" point is the
> contentious issue here.
>
>> Although, Brian's suggestion of the .beginEval() and .endEval() does
>> make a lot of sense.
>
>
> Yes. I think this is probably a good solution, but in a more generic
> terminology - .enter() .leave() might be nicer, or acquire() /
> release(). That way it looks sensible if you want to share a context
> between evals:
>
>
> ctx.acquire();
> try
> {
> template.write( output, ctx);
> template.write( output2, ctx);
> template.write( output3, ctx);
> }
> finally
> {
> ctx.release();
> }
>
> This is then only a concern for people who want to share contexts like
> this. For everybody else (99% of people) the implicit acquire/release
> will be perfect.
>
> Marc
|
237 messages has been excluded from this view by a project administrator.
