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: Lane S. <la...@op...> - 2004-05-10 15:01:42
|
Greetings, I have just completed the commit to wiki for version 3.1. This release is documented at http://webmacro.org/WebMacroWiki This is a slick upgrade. Use this release whenever you want to enjoy control over a collaborative, private, invitation-only wiki. To my knowledge, there are not a lot of Wiki's out there which offer both public,anonymous run mode as well as the secure, private run mode. Furthermore, I have started on remote administration: once you get the wiki running you can administer it remotely. This is also going to be very cool once complete. (You can hand over the administration of the wiki to someone whom you do not want to give server access. Cool, huh?) The cvs commit will be tested out this week. No doubt I missed some files and it is not fully baked. I will work this out this week. regards, -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: Keats <ke...@xa...> - 2004-05-10 14:03:35
|
I use: ke...@cv...:/cvsroot/webmacro Keats ----- Original Message ----- From: "Lane Sharman" <la...@op...> To: <web...@li...> Sent: Saturday, May 08, 2004 12:30 PM Subject: [Webmacro-devel] cvs @ sourceforge > :ext:lan...@cv...:/cvsroot/webmacro > no longer works. Has there been a change at SF??? > > |
|
From: Lane S. <la...@op...> - 2004-05-08 16:42:38
|
Hi, I would like to check wiki back in to cvs. The updates are complete. The webmacro CVSROOT env var is now changed and I do not know the new one. I am working on the docs at www.webmacro.org. When the docs are complete, I will publish the urls. In short: > Wiki was upgraded to WM 2.0 > The source code from open doors was placed into a jar and all the sources were removed from the tree. This is the VLH component of Wiki. > Wiki can run in appoval mode, or not. > Wiki can run in private mode which implies approval mode. The last 2 features mean you can have an invitation-only, and completely private wiki on the net. The code to implement this has been tested reasonably. -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: Lane S. <la...@op...> - 2004-05-08 16:23:57
|
:ext:lan...@cv...:/cvsroot/webmacro no longer works. Has there been a change at SF??? -- Lane Sharman Providing Private and SPAM-Free Email http://www.opendoors.com 858-755-2868 |
|
From: Lane S. <la...@op...> - 2004-04-08 17:18:58
|
Brian would know the answer to this question as that he introduced us to this piece of magic. -Lane Tim Pizey wrote: >Hi, > >big thanks to Lane I am now back on the case. > >We (paneris) had a disk failure, so took the opportunity >to upgrade hardware and os (we were on RH 5.2 !!!) > >We are now on RH9 and are migrating to Tomcat, >so I have some work to do. >Part of which is to use Maven for deployment as well >as documentation. > >Maven rather likes jars to be named in the format >artifactId-version > >I have used concurrent-1.0.jar which happens to exist on >ibiblio. > >does anyone happen to know if that is the version >WM is shipping? > >yours >Tim Pizey >PS if any committers need space/cpu cycles just ask > > > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman For Protection from SPAM and Virus, Extend to the Network Your Perimeter of Defense: http://www.opendoors.com 858-755-2868 |
|
From: Tim P. <ti...@pa...> - 2004-04-08 15:30:17
|
Hi,=20 big thanks to Lane I am now back on the case.=20 We (paneris) had a disk failure, so took the opportunity=20 to upgrade hardware and os (we were on RH 5.2 !!!) We are now on RH9 and are migrating to Tomcat,=20 so I have some work to do.=20 Part of which is to use Maven for deployment as well=20 as documentation.=20 Maven rather likes jars to be named in the format=20 artifactId-version I have used concurrent-1.0.jar which happens to exist on=20 ibiblio. does anyone happen to know if that is the version=20 WM is shipping? yours Tim Pizey PS if any committers need space/cpu cycles just ask |
|
From: <Web...@St...> - 2004-04-05 22:05:38
|
On Mon, 5 Apr 2004, Eric Ridge wrote:
| On Apr 5, 2004, at 1:41 PM, Endre St=F8lsvik wrote:
| >
| > This is getting clearer - but why is "evaluate" there in the first
| > place,
| > then? Macro is an iface, right? Why are there two methods,
|
| Because WM can also be used to only affect the Context. You can do
| this:
| WebMacro wm =3D new WM();
| Context ctx =3D wm.getContext();
| Template t =3D wm.getTemplate("foobar.wm");
| t.evaluate(ctx);
| Object foo =3D ctx.get("Foo");
|
| And .write() was never called. Not by you, and not by the innards of
| WM.
Aha .. The evaluate() or write() is kinda "recursive"..? It would be
marvelous if this was documented, -preferrably- right in the JavaDoc,
include the little 5-liner within <core> tags as an example.
Thanks,
Endre
|
|
From: Eric R. <eb...@tc...> - 2004-04-05 18:00:31
|
On Apr 5, 2004, at 1:41 PM, Endre St=F8lsvik wrote:
>
> This is getting clearer - but why is "evaluate" there in the first=20
> place,
> then? Macro is an iface, right? Why are there two methods,
Because WM can also be used to only affect the Context. You can do=20
this:
WebMacro wm =3D new WM();
Context ctx =3D wm.getContext();
Template t =3D wm.getTemplate("foobar.wm");
t.evaluate(ctx);
Object foo =3D ctx.get("Foo");
And .write() was never called. Not by you, and not by the innards of=20
WM.
> That=B4s what I expected - it then just falls back to "normal property
> traversal" stuff, as with any Object put in the context, right?
yep.
eric
|
|
From: <Web...@St...> - 2004-04-05 17:41:15
|
On Sun, 4 Apr 2004, Eric Ridge wrote:
| On Apr 4, 2004, at 8:58 PM, Endre St=F8lsvik wrote:
| > It=B4s getting clearer..
| >
| > When I make a Macro, and shove this thing into the context as "Rock",
| > when
| > I do $Rock, or $Rock.roll, what happens?? This is, I assume, the most
| > used way to use Macro?
|
| If you initially called Template.write(out, context), then the .write()
| method is getting called in your $Rock Macro. And that method calls
| it's .evaluate() method to get the value to write:
|
| public Object evaluate(Context c) { return "Rock"; }
| public void write(FastWriter fw, Context c) {
| fw.write(this.evaluate(c).toString()); }
|
| That's how it works.
This is getting clearer - but why is "evaluate" there in the first place,
then? Macro is an iface, right? Why are there two methods, if the write
method is the only method called -from the framework- in any case? It
seems like evaluate is just there as a "guide" to how -I- should implemen=
t
write()?? "You should invoke evaluate(...)" - why? I can evaluate -and-
write to the writer in one go, that=B4s how brilliant I am..! ;-)
|
| If you call $Rock.roll, then you're simply asking for the "roll"
| property of the Rock macro (which could be a field, a method, or a
| generic .get() method)... whose .toString() value gets output to the
| template.
That=B4s what I expected - it then just falls back to "normal property
traversal" stuff, as with any Object put in the context, right?
Thanks for shedding light on this..
Endre.
|
|
From: Eric R. <eb...@tc...> - 2004-04-05 01:09:08
|
On Apr 4, 2004, at 8:58 PM, Endre St=F8lsvik wrote:
> It=B4s getting clearer..
>
> When I make a Macro, and shove this thing into the context as "Rock",=20=
> when
> I do $Rock, or $Rock.roll, what happens?? This is, I assume, the most
> used way to use Macro?
If you initially called Template.write(out, context), then the .write()=20=
method is getting called in your $Rock Macro. And that method calls=20
it's .evaluate() method to get the value to write:
public Object evaluate(Context c) { return "Rock"; }
public void write(FastWriter fw, Context c) {=20
fw.write(this.evaluate(c).toString()); }
That's how it works.
If you call $Rock.roll, then you're simply asking for the "roll"=20
property of the Rock macro (which could be a field, a method, or a=20
generic .get() method)... whose .toString() value gets output to the=20
template.
eric.
> And btw: It was the "original author" of WM that suddenly changed the
> behaviour to cache everything before output, based on -dubious-
> assumptions that this will give better performance - which I don=B4=20
> believe
> at all. I=B4d like to be able to choose whether I like "direct=20
> rendering",
> or complete buffering, in the latter case, I could easily do that=20
> myself,
> instead of the WM internals doing it.
>
>
> --=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: <Web...@St...> - 2004-04-05 00:59:00
|
On Sun, 4 Apr 2004, Eric Ridge wrote: | On Apr 3, 2004, at 7:06 PM, Endre St=F8lsvik wrote: | | > | The Macro interface is pretty simple: write() sends its output to = a | > | FastWriter, and evaluate() returns to a String. | > | > Once more: WHEN ARE THEY INVOKED??? | | Think of it like this: .evaluate() returns the Object, whose toString | value is written to the output stream by .write(). | | If your goal is to write the output of a template, just call | Template.write(). If your goal is to modify the Context, call | Template.evaluate(). | | Directives like #set, which don't .write() anything, do their | Context-changing work in .evaluate(). | | Clear as mud? It=B4s getting clearer.. When I make a Macro, and shove this thing into the context as "Rock", whe= n I do $Rock, or $Rock.roll, what happens?? This is, I assume, the most used way to use Macro? And btw: It was the "original author" of WM that suddenly changed the behaviour to cache everything before output, based on -dubious- assumptions that this will give better performance - which I don=B4 belie= ve at all. I=B4d like to be able to choose whether I like "direct rendering"= , or complete buffering, in the latter case, I could easily do that myself, instead of the WM internals doing it. --=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: Eric R. <eb...@tc...> - 2004-04-04 21:30:52
|
On Apr 3, 2004, at 7:06 PM, Endre St=F8lsvik wrote: > | The Macro interface is pretty simple: write() sends its output to a > | FastWriter, and evaluate() returns to a String. > > Once more: WHEN ARE THEY INVOKED??? Think of it like this: .evaluate() returns the Object, whose toString=20= value is written to the output stream by .write(). If your goal is to write the output of a template, just call=20 Template.write(). If your goal is to modify the Context, call=20 Template.evaluate(). Directives like #set, which don't .write() anything, do their=20 Context-changing work in .evaluate(). Clear as mud? eric= |
|
From: <Web...@St...> - 2004-04-04 21:26:06
|
On Mon, 29 Mar 2004, Keats wrote: | ----- Original Message ----- | > That said, I come to think about the Macro interface (class?). Why does it | > have two methods there? I have never understood which of the methods are | > invoked when: one fo them (I am on vacation now, so I can't find the | > details) have never been invoked when I have made Macro implementation. | > This is also very very badly documented, not explaining nothing. | | The Macro interface is pretty simple: write() sends its output to a | FastWriter, and evaluate() returns to a String. Once more: WHEN ARE THEY INVOKED??? Endre |
|
From: Lane S. <la...@op...> - 2004-03-29 22:47:46
|
Greetings, I completed the melati development and will be checking it in now that I have a new password and now that the cvs server has been restored. The practice of writing to the underlying stream in parallel with the outer template is a poor practice. In Melati, we now use a ByteBuffer to build an intermediate object. Then, we return it is a string so that the outermost template can render it in the proper sequence. Writing in parallel to the stream has a lot of drawbacks and it is being abandoned in the new release of Melati. Kindest, -- Lane Sharman For Protection from SPAM and Virus, Extend to the Network Your Perimeter of Defense: http://www.opendoors.com 858-755-2868 |
|
From: Eric R. <eb...@tc...> - 2004-03-29 20:31:44
|
On Mar 29, 2004, at 10:54 AM, Keats wrote: > The Macro interface is pretty simple: write() sends its output to a > FastWriter, and evaluate() returns to a String. Not completely true. .evaluate() returns an *Object*. eric |
|
From: Keats <ke...@xa...> - 2004-03-29 15:54:58
|
----- Original Message ----- > That said, I come to think about the Macro interface (class?). Why does it > have two methods there? I have never understood which of the methods are > invoked when: one fo them (I am on vacation now, so I can't find the > details) have never been invoked when I have made Macro implementation. > This is also very very badly documented, not explaining nothing. The Macro interface is pretty simple: write() sends its output to a FastWriter, and evaluate() returns to a String. Keats |
|
From: Keats <ke...@xa...> - 2004-03-29 15:44:32
|
There probably should be a more straightforward way to get at the FastWriter than what I outlined, but I have a hard time thinking of a good use-case to justify this. Dumping a megabyte of dynamic text into a Web page seems a bit extreme. WebMacro was designed to cache all output before writing it out. If this isn't appropriate for a particular application, maybe WM isn't the right tool for that application. However, having said this, I'm all in favor of making the system flexible. You could, of course, implement your own subclass of FastWriter that doesn't cache and put a reference to that into the context. Something like a FastWriterOutputStreamAdapter. Maybe we should provide something like this with an UnbufferedWMServlet example. Keats ----- Original Message ----- From: "Endre Stølsvik" <Web...@St...> To: "Keats" <ke...@ea...> Cc: <la...@op...>; "Tim Joyce" <ti...@ho...>; <web...@li...> Sent: Saturday, March 27, 2004 10:41 PM Subject: Re: [Webmacro-devel] Re: [Melati-developers] WebMacro Test Case: TestSharedOutputStream > On Mon, 15 Mar 2004, Keats wrote: > > | I think Lane's solution is ultimately best -- don't try to write to the > | underlying stream from within a template, just return a String and let WM > | handle it. > > (Note: I have no good suggestions here, just a point.) > > This is bad for performance, I kinda feel. Returning a megabyte String to > be included in a stream, when you really could have outputted the stuff > you were making directly to the stream is really really not good. There > are probably a StringBuffer creation, several String creations, and > whatnot, in addition to the rush of memory being used for this TOTALLY > useless intermediate object. > > Allthough I hate the FastWriter, it -must- be possible for things inside > the template to directly output (read: "render") to the "actual target". > > That said, I come to think about the Macro interface (class?). Why does it > have two methods there? I have never understood which of the methods are > invoked when: one fo them (I am on vacation now, so I can't find the > details) have never been invoked when I have made Macro implementation. > This is also very very badly documented, not explaining nothing. > > Endre. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: <Web...@St...> - 2004-03-28 03:41:41
|
On Mon, 15 Mar 2004, Keats wrote: | I think Lane's solution is ultimately best -- don't try to write to the | underlying stream from within a template, just return a String and let WM | handle it. (Note: I have no good suggestions here, just a point.) This is bad for performance, I kinda feel. Returning a megabyte String to be included in a stream, when you really could have outputted the stuff you were making directly to the stream is really really not good. There are probably a StringBuffer creation, several String creations, and whatnot, in addition to the rush of memory being used for this TOTALLY useless intermediate object. Allthough I hate the FastWriter, it -must- be possible for things inside the template to directly output (read: "render") to the "actual target". That said, I come to think about the Macro interface (class?). Why does it have two methods there? I have never understood which of the methods are invoked when: one fo them (I am on vacation now, so I can't find the details) have never been invoked when I have made Macro implementation. This is also very very badly documented, not explaining nothing. Endre. |
|
From: <Web...@St...> - 2004-03-28 03:30:44
|
On Mon, 8 Mar 2004, Lane Sharman wrote: [ - suggestions for new web development stuff removed - ] I think you guys add too much stash to WM. WM is a macro language, and should ONLY be that - the web development tools that constantly is up for suggestions and questions are NOT part of a macro language. Stash like that should be distributed in a separte bundle, and all traces of such bloat should be removed for the 2.0. IM(H)O, of course. Endre |
|
From: Lane S. <la...@op...> - 2004-03-15 16:37:18
|
Hi Keats,.
I proposed my solution after looking at the problem considerably and so
appreaciate your line of support.
-Lane
Keats wrote:
>I think Lane's solution is ultimately best -- don't try to write to the
>underlying stream from within a template, just return a String and let WM
>handle it.
>
>If you do need/want to do this for some reason, you can still get ahold of
>the FastWriter by putting it into the context. If you don't want to use the
>deprecated getFastWriter, you can manage the FastWriter explicitly:
>
>// create a context for the current request
>WebContext c = _wm.getWebContext(req,resp);
>// put junk in the context
>//...
>// create a FastWriter
>FastWriter fw = FastWriter.getInstance(c.getBroker(),
>c.getResponse().getOutputStream());
>// put the FastWriter into the context
>c.put("fw", fw);
>// get the template
>WMTemplate t = (WMTemplate)_wm.getTemplate("mytemplate.wm");
>// write the template to the output, using our context
>t.write(fw, c);
>fw.close();
>
>Hope this helps.
>
>Keats
>
>----- Original Message -----
>From: Lane Sharman
>To: Tim Joyce
>Cc: mel...@li... ;
>web...@li... ; Tim Pizey
>Sent: Sunday, March 14, 2004 12:02 PM
>Subject: Re: [Webmacro-devel] Re: [Melati-developers] WebMacro Test Case:
>TestSharedOutputStream
>
>
>Hi Tim,
>
>Thanks for adding your .2p. I'd like to get to the best solution now that we
>are in the thick of this.
>
>While I agree, as you suggest, that you _could_ flush to the output stream.
>I would not propose that we try to follow this path. It breaks a lot of
>encapsulation issues at play and getting a handle onto the instance that
>controls the backing store, the cached FastWriter instance, will be tricky.
>I see no way to reach out and get this other than thru some AOP technique.
>
>What I do propose is that the type, MarkupLanguage, return its output
>instead of writing its output. This follows the well-known pattern of
>context objects. I think there are a lot of good arguments for refactoring
>this type to behave in this manner. If there are some downsides to this, I'm
>sure you will let me know.
>
>thanks,
>
>Lane
>
>
>Tim Joyce wrote:
>
>Lane,
>
>I have only spent 5 mins on this, so much of this is from memory, but here
>is my 2p.
>
>
>The problem, as presented by Keats, is that in 2.0, WM renders a
>template to a backing store using a FastWriter impl instance, not to the
>outputstream. I kinda knew this to be the case but could not verify it.
>
>
>it always did this (buffered the output stream).
>
>
>Therefore, prior to 2.0, Melati exploited its knowledge of the behavior
>of FW. With 2.0, this knowledge of the WM implementation is no longer
>correct. WM writes to a backing store in 2.0, not directly to the output
>stream.
>
>
>ok.
>
>
>The FastWriter instance used internally to write out a template is not
>visible to the template in 2.0. In 2.0, you write to an output stream or
>to a string. In 2.0, as has been noted, the reference to the FW instance
>used to render the template internally is not available.
>
>
>
>Personally, I think it is bad form that melati exploited internal
>knowledge of the FW mechanics. This broke the encapsulation contract and
>now melati is broken. The melati template variable, $ml, instead of
>returning strings for method calls, has an internal operation which
>writes to the output stream. Since the template is buffered, this write
>op ends up at the front of the output.
>
>
>i would not cast blame here. the outputstream was (and still is) exposed
>therefor it is not unreasonable to reference it elsewhere. without an
>explicit unit test the contract is ambiguous, and melati made the assumption
>that it was allowed to make direct write calls to the outputstream.
>similarly, changing the implementation of FastWriter is also totally
>reasonable.
>
>
>My suggestion at this point is to back out the exploited knowledge. $ml,
>a context variable and object, should return renderable text, not
>attempt to write to the output stream. This would decouple it from
>internal knowledge of the templating frameworks and standardize its
>behavior in a normal manner for all template engines, not just WM.
>
>
>why can't we just flush() before we write our stuff.
>
>timj
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
>
>
--
Lane Sharman
For Protection from SPAM and Virus,
Extend to the Network Your Perimeter of Defense:
http://www.opendoors.com
858-755-2868
|
|
From: Keats <ke...@xa...> - 2004-03-15 15:24:57
|
I think Lane's solution is ultimately best -- don't try to write to the
underlying stream from within a template, just return a String and let WM
handle it.
If you do need/want to do this for some reason, you can still get ahold of
the FastWriter by putting it into the context. If you don't want to use the
deprecated getFastWriter, you can manage the FastWriter explicitly:
// create a context for the current request
WebContext c = _wm.getWebContext(req,resp);
// put junk in the context
//...
// create a FastWriter
FastWriter fw = FastWriter.getInstance(c.getBroker(),
c.getResponse().getOutputStream());
// put the FastWriter into the context
c.put("fw", fw);
// get the template
WMTemplate t = (WMTemplate)_wm.getTemplate("mytemplate.wm");
// write the template to the output, using our context
t.write(fw, c);
fw.close();
Hope this helps.
Keats
----- Original Message -----
From: Lane Sharman
To: Tim Joyce
Cc: mel...@li... ;
web...@li... ; Tim Pizey
Sent: Sunday, March 14, 2004 12:02 PM
Subject: Re: [Webmacro-devel] Re: [Melati-developers] WebMacro Test Case:
TestSharedOutputStream
Hi Tim,
Thanks for adding your .2p. I'd like to get to the best solution now that we
are in the thick of this.
While I agree, as you suggest, that you _could_ flush to the output stream.
I would not propose that we try to follow this path. It breaks a lot of
encapsulation issues at play and getting a handle onto the instance that
controls the backing store, the cached FastWriter instance, will be tricky.
I see no way to reach out and get this other than thru some AOP technique.
What I do propose is that the type, MarkupLanguage, return its output
instead of writing its output. This follows the well-known pattern of
context objects. I think there are a lot of good arguments for refactoring
this type to behave in this manner. If there are some downsides to this, I'm
sure you will let me know.
thanks,
Lane
Tim Joyce wrote:
Lane,
I have only spent 5 mins on this, so much of this is from memory, but here
is my 2p.
The problem, as presented by Keats, is that in 2.0, WM renders a
template to a backing store using a FastWriter impl instance, not to the
outputstream. I kinda knew this to be the case but could not verify it.
it always did this (buffered the output stream).
Therefore, prior to 2.0, Melati exploited its knowledge of the behavior
of FW. With 2.0, this knowledge of the WM implementation is no longer
correct. WM writes to a backing store in 2.0, not directly to the output
stream.
ok.
The FastWriter instance used internally to write out a template is not
visible to the template in 2.0. In 2.0, you write to an output stream or
to a string. In 2.0, as has been noted, the reference to the FW instance
used to render the template internally is not available.
Personally, I think it is bad form that melati exploited internal
knowledge of the FW mechanics. This broke the encapsulation contract and
now melati is broken. The melati template variable, $ml, instead of
returning strings for method calls, has an internal operation which
writes to the output stream. Since the template is buffered, this write
op ends up at the front of the output.
i would not cast blame here. the outputstream was (and still is) exposed
therefor it is not unreasonable to reference it elsewhere. without an
explicit unit test the contract is ambiguous, and melati made the assumption
that it was allowed to make direct write calls to the outputstream.
similarly, changing the implementation of FastWriter is also totally
reasonable.
My suggestion at this point is to back out the exploited knowledge. $ml,
a context variable and object, should return renderable text, not
attempt to write to the output stream. This would decouple it from
internal knowledge of the templating frameworks and standardize its
behavior in a normal manner for all template engines, not just WM.
why can't we just flush() before we write our stuff.
timj
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
--
Lane Sharman
For Protection from SPAM and Virus,
Extend to the Network Your Perimeter of Defense:
http://www.opendoors.com
858-755-2868
|
|
From: Lane S. <la...@op...> - 2004-03-14 16:56:48
|
Hi Tim, Thanks for adding your .2p. I'd like to get to the best solution now that we are in the thick of this. While I agree, as you suggest, that you _could_ flush to the output stream. I would not propose that we try to follow this path. It breaks a lot of encapsulation issues at play and getting a handle onto the instance that controls the backing store, the cached FastWriter instance, will be tricky. I see no way to reach out and get this other than thru some AOP technique. What I do propose is that the type, MarkupLanguage, return its output instead of writing its output. This follows the well-known pattern of context objects. I think there are a lot of good arguments for refactoring this type to behave in this manner. If there are some downsides to this, I'm sure you will let me know. thanks, Lane Tim Joyce wrote: >Lane, > >I have only spent 5 mins on this, so much of this is from memory, but here >is my 2p. > > > >>The problem, as presented by Keats, is that in 2.0, WM renders a >>template to a backing store using a FastWriter impl instance, not to the >>outputstream. I kinda knew this to be the case but could not verify it. >> >> > >it always did this (buffered the output stream). > > > >>Therefore, prior to 2.0, Melati exploited its knowledge of the behavior >>of FW. With 2.0, this knowledge of the WM implementation is no longer >>correct. WM writes to a backing store in 2.0, not directly to the output >>stream. >> >> > >ok. > > > >>The FastWriter instance used internally to write out a template is not >>visible to the template in 2.0. In 2.0, you write to an output stream or >>to a string. In 2.0, as has been noted, the reference to the FW instance >>used to render the template internally is not available. >> >> > > > >>Personally, I think it is bad form that melati exploited internal >>knowledge of the FW mechanics. This broke the encapsulation contract and >>now melati is broken. The melati template variable, $ml, instead of >>returning strings for method calls, has an internal operation which >>writes to the output stream. Since the template is buffered, this write >>op ends up at the front of the output. >> >> > >i would not cast blame here. the outputstream was (and still is) exposed >therefor it is not unreasonable to reference it elsewhere. without an >explicit unit test the contract is ambiguous, and melati made the assumption >that it was allowed to make direct write calls to the outputstream. >similarly, changing the implementation of FastWriter is also totally >reasonable. > > > >>My suggestion at this point is to back out the exploited knowledge. $ml, >>a context variable and object, should return renderable text, not >>attempt to write to the output stream. This would decouple it from >>internal knowledge of the templating frameworks and standardize its >>behavior in a normal manner for all template engines, not just WM. >> >> > >why can't we just flush() before we write our stuff. > >timj > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman For Protection from SPAM and Virus, Extend to the Network Your Perimeter of Defense: http://www.opendoors.com 858-755-2868 |
|
From: Tim J. <ti...@ho...> - 2004-03-14 12:46:32
|
Lane, I have only spent 5 mins on this, so much of this is from memory, but here is my 2p. > The problem, as presented by Keats, is that in 2.0, WM renders a > template to a backing store using a FastWriter impl instance, not to the > outputstream. I kinda knew this to be the case but could not verify it. it always did this (buffered the output stream). > Therefore, prior to 2.0, Melati exploited its knowledge of the behavior > of FW. With 2.0, this knowledge of the WM implementation is no longer > correct. WM writes to a backing store in 2.0, not directly to the output > stream. ok. > The FastWriter instance used internally to write out a template is not > visible to the template in 2.0. In 2.0, you write to an output stream or > to a string. In 2.0, as has been noted, the reference to the FW instance > used to render the template internally is not available. > Personally, I think it is bad form that melati exploited internal > knowledge of the FW mechanics. This broke the encapsulation contract and > now melati is broken. The melati template variable, $ml, instead of > returning strings for method calls, has an internal operation which > writes to the output stream. Since the template is buffered, this write > op ends up at the front of the output. i would not cast blame here. the outputstream was (and still is) exposed therefor it is not unreasonable to reference it elsewhere. without an explicit unit test the contract is ambiguous, and melati made the assumption that it was allowed to make direct write calls to the outputstream. similarly, changing the implementation of FastWriter is also totally reasonable. > My suggestion at this point is to back out the exploited knowledge. $ml, > a context variable and object, should return renderable text, not > attempt to write to the output stream. This would decouple it from > internal knowledge of the templating frameworks and standardize its > behavior in a normal manner for all template engines, not just WM. why can't we just flush() before we write our stuff. timj |
|
From: Lane S. <la...@op...> - 2004-03-13 23:11:41
|
Tim, Eric, Keats: The problem, as presented by Keats, is that in 2.0, WM renders a template to a backing store using a FastWriter impl instance, not to the outputstream. I kinda knew this to be the case but could not verify it. Therefore, prior to 2.0, Melati exploited its knowledge of the behavior of FW. With 2.0, this knowledge of the WM implementation is no longer correct. WM writes to a backing store in 2.0, not directly to the output stream. The FastWriter instance used internally to write out a template is not visible to the template in 2.0. In 2.0, you write to an output stream or to a string. In 2.0, as has been noted, the reference to the FW instance used to render the template internally is not available. Personally, I think it is bad form that melati exploited internal knowledge of the FW mechanics. This broke the encapsulation contract and now melati is broken. The melati template variable, $ml, instead of returning strings for method calls, has an internal operation which writes to the output stream. Since the template is buffered, this write op ends up at the front of the output. My suggestion at this point is to back out the exploited knowledge. $ml, a context variable and object, should return renderable text, not attempt to write to the output stream. This would decouple it from internal knowledge of the templating frameworks and standardize its behavior in a normal manner for all template engines, not just WM. -Lane Tim Pizey wrote: >On Saturday 13 March 2004 7:54 am, Lane Sharman wrote: > > >>Eric, >> >>Would you please do an update, look at the above class file and run it. >>Tell me I am not going crazy. Do not answer that :) >> >>For the life of me, I cannot understand why this is a failure!!! How did >>Melati run in 1.1 and now not run in 2.0??? >> >>The test case shows the obvious. If you have a reference inside a >>template that writes to the output stream. And, if the reference >>internally flushes to the stream as it needs to, how can it NOT be at >>the beginning of the destination output stream. How could it work in 1.1? >> >>In any case, I have gone as far as I can/want to go with this Melati >>failure in 2.0 without a second opinion. >> >> > >Lane, >you have my sympathies, I hit the same snags. > >I hope that TimJ may be able to help?? > >cheers >Tim P > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click >_______________________________________________ >Melati-developers mailing list >Mel...@li... >https://lists.sourceforge.net/lists/listinfo/melati-developers > > > -- Lane Sharman For Protection from SPAM and Virus, Extend to the Network Your Perimeter of Defense: http://www.opendoors.com 858-755-2868 |
|
From: Lane S. <la...@op...> - 2004-03-13 07:49:53
|
Eric, Would you please do an update, look at the above class file and run it. Tell me I am not going crazy. Do not answer that :) For the life of me, I cannot understand why this is a failure!!! How did Melati run in 1.1 and now not run in 2.0??? The test case shows the obvious. If you have a reference inside a template that writes to the output stream. And, if the reference internally flushes to the stream as it needs to, how can it NOT be at the beginning of the destination output stream. How could it work in 1.1? In any case, I have gone as far as I can/want to go with this Melati failure in 2.0 without a second opinion. thanks, -- Lane Sharman For Protection from SPAM and Virus, Extend to the Network Your Perimeter of Defense: http://www.opendoors.com 858-755-2868 |
237 messages has been excluded from this view by a project administrator.
