Menu
▾
▴
webmacro-devel
|
From: Marc P. <ma...@an...> - 2003-07-05 19:11:31
|
Guys, As (from what I know) there is no "StringOutputStream" in the JDK and StringWriter (from 1.4?) does exist, it really strikes me that we should accept normal Writer(s). i.e. we really should be able to let end users trivially output the results of a template to a String Preferably this should include performance benefits from using FastWriter internally, or at the very leasy should perform OK and with the same output mechanism through template.write() instead of requiring some other obscure knowledge of WM - there's Macro.toString() or something isn't there? Users should be able to: Template template = new FileTemplate( "myfile.wmt"); StringWriter sw = new StringWriter(); template.write( sw, webContext); This is just one reason why exposing FastWriter is bad news. Why should it even be exposed at all anyway?! Just make it delegate to a normal Writer and have no "public API" methods that use it. -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
|
From: Marc P. <ma...@an...> - 2003-07-05 19:21:56
|
On Sat, 05 Jul 2003 20:07:28 +0100, Marc Palmer <ma...@an...> wrote: > > Guys, > > As (from what I know) there is no "StringOutputStream" in the JDK and > StringWriter (from 1.4?) does exist, it really strikes me that we should > accept normal Writer(s). > > i.e. we really should be able to let end users trivially output the > results of a template to a String PS I know we are working on this for 2.0 - this is just to back up the reasoning. |
|
From: Brian G. <br...@qu...> - 2003-07-05 23:27:15
|
> As (from what I know) there is no "StringOutputStream" in the JDK and > StringWriter (from 1.4?) does exist, it really strikes me that we should > accept normal Writer(s). The reason fastwriter is 'fast' is that it caches the encoded bytes that correspond to the strings in a template. This makes a pretty big difference. What my plan is is to pass in an OutputStream and encoding to template.write, and hide the FW implementation so it is internal only. This is very easy and retains all the benefits of using FW. > i.e. we really should be able to let end users trivially output the results > of a template to a String FW does this already. We can expose this via templates. > This is just one reason why exposing FastWriter is bad news. Why should it > even be exposed at all anyway?! Just make it delegate to a normal Writer > and have no "public API" methods that use it. That's the plan. |
|
From: Eric B. R. <eb...@tc...> - 2003-07-05 23:31:18
|
On Saturday, July 5, 2003, at 07:26 PM, Brian Goetz wrote: >> As (from what I know) there is no "StringOutputStream" in the JDK and >> StringWriter (from 1.4?) does exist, it really strikes me that we >> should >> accept normal Writer(s). > > The reason fastwriter is 'fast' is that it caches the encoded bytes > that > correspond to the strings in a template. This makes a pretty big > difference. > > What my plan is is to pass in an OutputStream and encoding to > template.write, and hide the FW implementation so it is internal only. > This is very easy and retains all the benefits of using FW. so are you saying that WM will continue to write to a FastWriter, but then only to the OutputStream once the rendering is complete? eric > >> i.e. we really should be able to let end users trivially output the >> results >> of a template to a String > > FW does this already. We can expose this via templates. > >> This is just one reason why exposing FastWriter is bad news. Why >> should it >> even be exposed at all anyway?! Just make it delegate to a normal >> Writer >> and have no "public API" methods that use it. > > That's the plan. > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/ > 01 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Lane S. <la...@op...> - 2003-07-06 02:28:39
|
Eric B. Ridge wrote:
> On Saturday, July 5, 2003, at 07:26 PM, Brian Goetz wrote:
>
>
> so are you saying that WM will continue to write to a FastWriter, but
> then only to the OutputStream once the rendering is complete?
>
> eric
If I know Brian, it will be some decorator around FastWriter that
extends OutputStream:
instead of this...
FastWriter w;
w = context.getBroker().getFastWriter(out, encoding);
context.put("FastWriter", w); // allow template writers to access
the output stream!
tmpl.write(w, context);
w.flush();
we could have:
OutputStream o;
o = context.getBroker().getOutputStream(System.out, encoding); //
send template to s.o
context.put("Writer", o); // allow template writers to access the
output stream!
tmpl.write(w, context);
o.flush();
Is this close to what you are proposing, Brian?
Lane
>
>
>>
>>> i.e. we really should be able to let end users trivially output the
>>> results
>>> of a template to a String
>>
>>
>> FW does this already. We can expose this via templates.
>>
>>> This is just one reason why exposing FastWriter is bad news. Why
>>> should it
>>> even be exposed at all anyway?! Just make it delegate to a normal
>>> Writer
>>> and have no "public API" methods that use it.
>>
>>
>> That's the plan.
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/
>> 01
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
|
|
From: Marc P. <ma...@an...> - 2003-07-06 07:47:17
|
> If I know Brian, it will be some decorator around FastWriter that extends
> OutputStream:
>
> instead of this...
> FastWriter w;
> w = context.getBroker().getFastWriter(out, encoding);
> context.put("FastWriter", w); // allow template writers to access the
> output stream!
> tmpl.write(w, context);
> w.flush();
>
> we could have:
> OutputStream o;
> o = context.getBroker().getOutputStream(System.out, encoding); // send
> template to s.o
> context.put("Writer", o); // allow template writers to access the output
> stream!
> tmpl.write(w, context);
> o.flush();
Ugh, I hope not. This really isn't intuitive or simple enough in my
opinion.
I really, truly, think we should be able to find a way to replace all
internal uses of FastWriter with Writer.
Then the caller has the option of passing in a (slow) Writer of their own,
or getting a FastWriter from WM and using that.
Most of all, it should be trivial.
That context.put in there looks like such a nasty idea. I really don't
think template writers should even know about the writer let alone have
access to it. Any flushing-while-rendering issues should be dealt with
another way, say using a #flush directive.
Is the caching performed by FastWriter really so beneficial, especially if
you compare it to JDK 1.4 NIO charset encoders/decoders working on a
Channel?
Perhaps we should look to WebMacro 3 (yes three!) being JDK 1.4 or higher
only, and replacing all the output stuff with Channels etc. to potentially
get higher performance if the Servlet container also uses NIO.
This line of thinking makes me wonder if actually we should not use
java.io.Writer or FastWriter at all in our internal code for writing out.
Let's abstract it totally to something like WebMacroOutput, with a trivial
interface.
Then we can just have the publicly-accessible "front facing" methods take
whatever we like - Writer, FastWriter, Channel etc and just wrap them in a
WebMacroOutput implementation.
Surely we have to bear in mind NIO for the future? One day it may become
the de facto I/O mechanism.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
http://www.anyware.co.uk/marc/
http://www.wangjammers.org
|
|
From: Brian G. <br...@qu...> - 2003-07-07 02:53:16
|
> > If I know Brian, it will be some decorator around FastWriter that extends > > OutputStream: You don't know Brian at all, then :) > I really, truly, think we should be able to find a way to replace all > internal uses of FastWriter with Writer. > > Then the caller has the option of passing in a (slow) Writer of their own, > or getting a FastWriter from WM and using that. > > Most of all, it should be trivial. It is. Stop worrying about it. It'll be fine. |
|
From: Lane S. <la...@op...> - 2003-07-07 06:52:57
|
Brian Goetz wrote: >It is. Stop worrying about it. It'll be fine. > will you be committing something to look at in the next few days? -l |
|
From: <web...@st...> - 2003-07-07 09:31:05
|
On Sun, 6 Jul 2003, Brian Goetz wrote: | > I really, truly, think we should be able to find a way to replace all | > internal uses of FastWriter with Writer. | > | > Then the caller has the option of passing in a (slow) Writer of their own, | > or getting a FastWriter from WM and using that. | > | > Most of all, it should be trivial. | | It is. Stop worrying about it. It'll be fine. Slightly "I'm The Coder of the Universe"-ish remark, though. -- 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: Eric R. <eb...@tc...> - 2003-12-08 23:52:28
|
On Jul 5, 2003, at 7:26 PM, Brian Goetz wrote:
> What my plan is is to pass in an OutputStream and encoding to
> template.write, and hide the FW implementation so it is internal only.
> This is very easy and retains all the benefits of using FW.
I realize I'm finally getting around to responding to a message that is
5 months old, but....
Why does org.webmacro.Template no longer "extend Macro"?
Doesn't this prohibit one from simply referencing a template object
that is in the context and have it expand correctly? For example:
{
context.put("MyTemplate", new StringTemplate("$foo"));
}
#set $foo = "FOO!"
$MyTemplate
isn't this broken now?
eric
|
|
From: Lane S. <la...@op...> - 2003-12-09 17:17:59
|
Is there a cvs record of the change to o.w.Template?
-lane
Eric Ridge wrote:
> On Jul 5, 2003, at 7:26 PM, Brian Goetz wrote:
>
>> What my plan is is to pass in an OutputStream and encoding to
>> template.write, and hide the FW implementation so it is internal only.
>> This is very easy and retains all the benefits of using FW.
>
>
> I realize I'm finally getting around to responding to a message that
> is 5 months old, but....
>
> Why does org.webmacro.Template no longer "extend Macro"?
>
> Doesn't this prohibit one from simply referencing a template object
> that is in the context and have it expand correctly? For example:
>
> {
> context.put("MyTemplate", new StringTemplate("$foo"));
> }
>
> #set $foo = "FOO!"
> $MyTemplate
>
> isn't this broken now?
>
> eric
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
--
Lane Sharman
Just Do IT, Better.
858-755-2868
|
|
From: Eric R. <eb...@tc...> - 2003-12-09 18:12:33
|
On Dec 9, 2003, at 12:40 PM, Lane Sharman wrote:
> Is there a cvs record of the change to o.w.Template?
Of course there is. But it doesn't explain this particular change.
eric
>
> -lane
>
> Eric Ridge wrote:
>
>> On Jul 5, 2003, at 7:26 PM, Brian Goetz wrote:
>>
>>> What my plan is is to pass in an OutputStream and encoding to
>>> template.write, and hide the FW implementation so it is internal
>>> only.
>>> This is very easy and retains all the benefits of using FW.
>>
>>
>> I realize I'm finally getting around to responding to a message that
>> is 5 months old, but....
>>
>> Why does org.webmacro.Template no longer "extend Macro"?
>>
>> Doesn't this prohibit one from simply referencing a template object
>> that is in the context and have it expand correctly? For example:
>>
>> {
>> context.put("MyTemplate", new StringTemplate("$foo"));
>> }
>>
>> #set $foo = "FOO!"
>> $MyTemplate
>>
>> isn't this broken now?
>>
>> eric
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IBM Linux Tutorials.
>> Become an expert in LINUX or just sharpen your skills. Sign up for
>> IBM's
>> Free Linux Tutorials. Learn everything from the bash shell to sys
>> admin.
>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>
>
> --
> Lane Sharman
> Just Do IT, Better.
> 858-755-2868
>
>
>
|
|
From: Lane S. <la...@op...> - 2003-12-09 19:19:12
|
my question was directed at finding an explanation.
Let's see if there is some recollection about this change before making
any hasty revisions, or resets.
-Lane
Eric Ridge wrote:
> On Dec 9, 2003, at 12:40 PM, Lane Sharman wrote:
>
>> Is there a cvs record of the change to o.w.Template?
>
>
> Of course there is. But it doesn't explain this particular change.
>
> eric
>
>>
>> -lane
>>
>> Eric Ridge wrote:
>>
>>> On Jul 5, 2003, at 7:26 PM, Brian Goetz wrote:
>>>
>>>> What my plan is is to pass in an OutputStream and encoding to
>>>> template.write, and hide the FW implementation so it is internal only.
>>>> This is very easy and retains all the benefits of using FW.
>>>
>>>
>>>
>>> I realize I'm finally getting around to responding to a message that
>>> is 5 months old, but....
>>>
>>> Why does org.webmacro.Template no longer "extend Macro"?
>>>
>>> Doesn't this prohibit one from simply referencing a template object
>>> that is in the context and have it expand correctly? For example:
>>>
>>> {
>>> context.put("MyTemplate", new StringTemplate("$foo"));
>>> }
>>>
>>> #set $foo = "FOO!"
>>> $MyTemplate
>>>
>>> isn't this broken now?
>>>
>>> eric
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IBM Linux Tutorials.
>>> Become an expert in LINUX or just sharpen your skills. Sign up for
>>> IBM's
>>> Free Linux Tutorials. Learn everything from the bash shell to sys
>>> admin.
>>> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>>> _______________________________________________
>>> Webmacro-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>
>>
>> --
>> Lane Sharman
>> Just Do IT, Better.
>> 858-755-2868
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
--
Lane Sharman
Just Do IT, Better.
858-755-2868
|
|
From: Eric R. <eb...@tc...> - 2003-12-10 23:22:33
|
On Dec 9, 2003, at 2:41 PM, Lane Sharman wrote: > my question was directed at finding an explanation. yeah, and so was mine. > Let's see if there is some recollection about this change before > making any hasty revisions, or resets. Nobody's touching anything yet. And I know *why* the change was made (not exposing FastWriter to the world), but I'm not convinced Brian realized the complete impact of this change. eric |
|
From: <web...@st...> - 2003-07-07 09:23:46
|
On Sat, 5 Jul 2003, Marc Palmer wrote: | This is just one reason why exposing FastWriter is bad news. Why should it | even be exposed at all anyway?! Just make it delegate to a normal Writer | and have no "public API" methods that use it. YES! I HATE FASTWRITER! I can't see no reason at all to expose internal "performance hacks". Gimme a Writer, and write to it the normal Writer-methods. OR, do a "instanceof" on the crucial places, and do the performance magic there. And how much performance gain is it anyways? -- 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/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X