Re: [Webmacro-devel] Re: [Melati-developers] WebMacro Test Case: TestSharedOutputStream

[Lane S. <la...@op...>]

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