[betwixt]:: MixedEncodingStrategy

[George Papastamatopoulos <ge...@lawlex.com.au>]

Hi

First of all, thanks for Betwixt!  Looks like it'll make our life a
whole lot easier.

We are needing to save a lot of bean properties around CDATA sections. 
I just downloaded the latest nightly build and it looks like 
MixedEncodingStrategy will do the job for us.

Just wondering what people thought about the idea of possible breaking
this out into an interface something along the lines of:

public interface EncodingStrategy {
 String encode(String, ElementDescriptor);
}

Then could have a static factory class or something similar that would
create various strategies for us :

public class EncodingStrategies {
 public static final EncodingStrategy createDefault(){
   return new DefaultEncodingStrategy();
 }
 public static final EncodingStrategy createCData(){
   return new CDATAEncodingStrategy();
 }
 public static final EncodingStrategy createSomeOtherStrategy(){
   return new SomeOtherClass();
 }
}

The stragey implementations may be private inner classes or something of
the like.  

Any thoughts as to whether something like this would be useful?

George


-- 
___________________________
George Papastamatopoulos

Lawlex Compliance Solutions
+61 3 9278 1182
___________________________


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [betwixt]:: MixedEncodingStrategy

[robert burrell donkin <ro...@blueyonder.co.uk>]

hi george

good to hear from you

On 26 Mar 2004, at 03:05, George Papastamatopoulos wrote:

<snip>

> Just wondering what people thought about the idea of possible breaking
> this out into an interface something along the lines of:
>
> public interface EncodingStrategy {
>  String encode(String, ElementDescriptor);
> }

the MixedContentEncodingStrategy is a logical interface implemented by 
an abstract class.  long (and bitter ;) experience has taught me (and 
many other folks here in the commons) that backwards compatibility 
concerns mean that abstract classes are usual preferable to java 
interfaces for library components.

changing the name of the class is worth considering, though. i couldn't 
think of any other occasion where this would apply but there seemed a 
chance that someday EncodingStrategy might be confusing with something 
like encodings for character data. on reflection, this doesn't seem 
like a very strong argument so i'd be interested to hear any other 
opinions about which is the best name.

> Then could have a static factory class or something similar that would
> create various strategies for us :
>
> public class EncodingStrategies {
>  public static final EncodingStrategy createDefault(){
>    return new DefaultEncodingStrategy();
>  }
>  public static final EncodingStrategy createCData(){
>    return new CDATAEncodingStrategy();
>  }
>  public static final EncodingStrategy createSomeOtherStrategy(){
>    return new SomeOtherClass();
>  }
> }

i do like this kind of construction. i prefer using EncodingStrategies 
for collective classes so i'd probably use the name 
EncodingStrategyFactory. i will add easy constructs for the 
implementations you suggest but there are a few design issues to think 
about.

my thinking about putting the most common implementations in the actual 
abstract class (rather than a separate factory class) is that it should 
be easier for users to find them if they are actually in the 
documentation of the (logical) interface (rather than buried away in a 
factory class). i'd be interested to know whether others share this 
view (or am i just gripped by a fad ;)

the default implementation is obtained as a constant. there is no 
reason why two instances should ever be created and i've been drawn 
towards the opinion that constants communicate this better than factory 
methods but again, i'd be very happy to change to factory method if 
that's more obvious.

> Any thoughts as to whether something like this would be useful?

anyone else want to add their opinions on this?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org