Re: [Simple-support] Using constructors with arguments

[Niall G. <gal...@ya...>]

Hi,

Also, just to mention you can do this.

public class Tuple {

  private Tuple() {
     super();
  }

  // etc...
}

Private no-arg constructors will also get invoked.

Niall


--- On Mon, 1/26/09, Niall Gallagher <gal...@ya...> wrote:

> From: Niall Gallagher <gal...@ya...>
> Subject: Re: [Simple-support] Using constructors with arguments
> To: sim...@li..., "Kevin Day" <for...@tr...>
> Date: Monday, January 26, 2009, 11:40 AM
> Hi,
> 
> Take a look at this. I will add this form of instantiation
> without a no-arg constructor in the next release.
> 
> http://simple.svn.sourceforge.net/viewvc/simple/trunk/download/stream/src/test/java/org/simpleframework/xml/core/ObjectStreamClassTest.java?revision=1158&view=markup
> 
> Let me know if this is suitable.
> 
> Niall
> 
> 
> --- On Mon, 1/26/09, Niall Gallagher
> <gal...@ya...> wrote:
> 
> > From: Niall Gallagher
> <gal...@ya...>
> > Subject: Re: [Simple-support] Using constructors with
> arguments
> > To: sim...@li..., "Kevin
> Day" <for...@tr...>
> > Date: Monday, January 26, 2009, 11:20 AM
> > Hi,
> > 
> > Thanks for the feedback, if you have any suggestions I
> am
> > open to them. I was thinking of something like.
> > 
> > 
> > public class Tuple {
> > 
> >     @Attribute
> >     private String name;
> >     
> >     @Element
> >     private String value;
> > 
> >     public Tuple(@Inject String name, @Inject String
> value)
> > {
> >         this.name = name;
> >         this.value = value;
> >     }
> > }
> > 
> > This would make it readable and writable. Taking the
> > parameters and seeing where they can be injected. This
> would
> > be easy to write.
> > 
> > Niall
> > 
> > 
> > --- On Mon, 1/26/09, Kevin Day
> > <for...@tr...> wrote:
> > 
> > > From: Kevin Day <for...@tr...>
> > > Subject: Re: [Simple-support] Using constructors
> with
> > arguments
> > > To: sim...@li...
> > > Date: Monday, January 26, 2009, 10:51 AM
> > > Thanks for taking a look.  I may be trying to use
> this
> > > framework for more than what it is intented to
> do.  If
> > you
> > > are interested in pursuing some use-cases,
> I'd be
> > happy
> > > to work with you on aspects of the design, etc...
>  But
> > I
> > > also understand that different projects have
> different
> > > goals, and direct encapsulation of business layer
> > objects
> > > (which are more likely to be required to be
> immutable)
> > may
> > > not be part of the goal of Simple-XML.
> > > 
> > > Using the @Commit or a combination of
> > @Replace/@Resolve
> > > requires an aweful lot of coding that it seems a
> > persistence
> > > framework could address...  Coding with the
> @Commit,
> > etc...
> > > style is roughly similar to using a JAXB
> generated
> > object
> > > structure for persistence, then having a bunch of
> > > translators written to convert persistent values
> into
> > > business objects and vice-versa.  It can be done,
> but
> > > I'm looking for something a lot more elegant.
> > > 
> > > 
> > > I'm also fine with using a Strategy to
> achieve the
> > goal
> > > (I've implemented a really rough first cut at
> this
> > > already), but there may be a couple of
> challenges.
> > > 
> > > As an example, my work so far indicates that the
> > Strategy
> > > interface can provide a hook for instantiation of
> > objects
> > > (i.e. via a factory that could use injected
> parameters
> > from
> > > a DI container) - however, unless I'm missing
> > something,
> > > it doesn't look like Strategy has access to
> the
> > Type
> > > objects generated from parsing the XML tree,
> which
> > means
> > > that I can't use objects recovered from the
> > > deserialization during instantiation.  If the
> objects
> > are
> > > simple (String or something easily handled with
> the
> > > *Transform classes), then this is no big deal (we
> can
> > just
> > > instantiate from the Type object in the node
> map), but
> > for
> > > complicated objects, I'm not sure how to
> handle
> > it.
> > > 
> > > This makes me wonder if I'm trying to get
> Strategy
> > to
> > > do something that it just isn't designed to
> do
> > (maybe
> > > this kind of thing should be implemented using a
> > different
> > > layer of the API), or if I can somehow use the
> map
> > passed
> > > into the getElement method to make this work.
> > > 
> > > 
> > > So, is it possible that the Instantiator class is
> the
> > place
> > > where this functionality needs to take place?  If
> so,
> > then
> > > the Instantiator would need to have access to the
> > > deserialization's context during the call to
> > getType(). 
> > > For example, if there were some way to obtain
> named
> > Type
> > > objects for the fields/values of the object being
> > > deserialized?  These could be used to instantiate
> > values
> > > that could then be passed to a factory or
> constructor.
> >  I
> > > suspect this would involve making a read-only
> view of
> > the
> > > Collector available to Instantiator.
> > > 
> > > I'm not sure how much control Simple has over
> the
> > > *order* that instantiation occurs in, or whether
> this
> > would
> > > impact things.  It appears that Simple builds the
> Type
> > > hierarchy before it starts instantiating objects,
> so
> > that
> > > should be OK (unless there is a cyclic reference
> in
> > the
> > > constructor parameters - but that won't
> happen in
> > a well
> > > designed object hierarchy :-)  )
> > > 
> > > I'm wondering if you have a philosophical
> overview
> > of
> > > the Simple architecture captured anywhere?  The
> > JavaDocs
> > > don't really provide a high level overview,
> and
> > the API
> > > has a *lot* of layers to it that make it
> difficult for
> > > someone new the source to get a handle on what
> types
> > of
> > > behavior should be implemented at which level. 
> My
> > > assumption is that the system takes several
> logical
> > passes
> > > over the object hierarchy:
> > > 
> > > Parse XML into nodes
> > > For each node, obtain it's Type (this is the
> job
> > of
> > > Strategy I think?)
> > > Determine the class for each Type and determine
> > it's
> > > fields/parameters/etc... and create Contacts for
> those
> > (this
> > > is the job of Scanner I think?  And that
> interacts
> > with the
> > > Collector somehow)
> > > Use each Type to instantiate a concrete object
> and
> > inject
> > > it into the Contacts (I think the Collector does
> this)
> > > 
> > > Is that approximately correct?
> > > 
> > > - K
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ----------------------- Original Message
> > > -----------------------
> > >  
> > > From: <Nia...@ub...>
> > > To: <for...@tr...>,
> > > <sim...@li...>
> > > Cc: 
> > > Date: Mon, 26 Jan 2009 09:11:54 -0000
> > > Subject: RE: [Simple-support] Using constructors
> with
> > > arguments
> > >  
> > > Hi,
> > > 
> > > Ill take a look at the read resolve and write
> replace
> > > issues you
> > > mention. The reason @Replace and @Resolve do not
> work
> > in
> > > lists is they
> > > go through the Traverser object, rather than the
> > Composite
> > > object
> > > directly. This is something I will have to
> address. So
> > > there are two
> > > options, the first is to use a strategy (there
> should
> > be
> > > plenty of
> > > examples in the test cases), the second is to use
> > @Commit
> > > to build the
> > > Tuples like so. 
> > > 
> > > public class TupleDatabase {
> > > 
> > >  private List<Tuple> tuples;
> > > 
> > >  @ElementList
> > >  private List<TupleEntry> entries;
> > > 
> > >  @Commit
> > >  private void commit() {
> > >     for(TupleEntry entry : entries) {
> > >        tuples.add(entry.name, entry.value);
> > >     }
> > >  }
> > > 
> > >  @Root
> > >  private static class TupleEntry {
> > >     @Element String name;
> > >     @Element String value;
> > >  }
> > > }
> > > 
> > > Here when building the list you can create the
> tuples
> > > without a no-arg
> > > constructor.
> > > 
> > > Hope this helps,
> > > Niall
> > > 
> > > -----Original Message-----
> > > From: Kevin Day [mailto:for...@tr...]
> 
> > > Sent: 24 January 2009 00:21
> > > To: sim...@li...
> > > Subject: Re: [Simple-support] Using constructors
> with
> > > arguments
> > > 
> > > Thanks for the suggestion, this type of strategy
> is
> > exactly
> > > what we do
> > > with our current Java serialization based
> persistence,
> > so
> > > it's easy to
> > > relate to (even though there's a lot of
> duplicate
> > > code).
> > > 
> > > 
> > > For some reason, though, @Replace isn't
> working
> > (the
> > > getSubstitute()
> > > method is never called).
> > > 
> > > After a bit of digging into the source, I think
> that
> > the
> > > problem is that
> > > the only place that Caller#replace() is actually
> > called is
> > > in
> > > Composite#writeReplace().  And that method is
> only
> > called
> > > for composite
> > > objects.  We are dealing with a list of objects,
> so it
> > > seems that maybe
> > > writeReplace() hasn't been properly
> implemented
> > for
> > > ElementList
> > > handlers?
> > > 
> > > If I place my object outside the list (as part of
> a
> > > composite element),
> > > then it serializes fine.
> > > 
> > > 
> > > Another issue I'm running into is during
> > > deserialization.  In this case,
> > > I am using @Resolve on the replaced object (which
> is
> > part
> > > of a composite
> > > object structure).  I set a break point on
> > > Composite.readResolve(), but
> > > readResolve never gets called.  The framework
> throws
> > an
> > > InstantiationException from
> Factory#getOverride().
> > > 
> > > 
> > > I'm not sure if the problem here is my lack
> of
> > > understanding of the API,
> > > or if this is just a corner case that didn't
> get
> > unit
> > > testing written
> > > for it.  I am attaching a self contained unit
> test
> > case
> > > that exhibits
> > > all of the above behavior.  Please let me know if
> you
> > have
> > > any
> > > pointers/suggestions, or if I may just be missing
> > > something!
> > > 
> > > Cheers,
> > > 
> > > - Kevin
> > > 
> > > 
> > > PS - I suspect that the use of @Replace and
> @Resolve
> > may
> > > not solve our
> > > entire use case, but it is a great start at a
> solution
> > and
> > > is helping me
> > > understand the Simple framework better.  Our
> ultimate
> > need
> > > also includes
> > > injection of resources via a DI framework, and
> I'm
> > > having a hard time
> > > figuring out how that's going to happen
> without
> > using
> > > some sort of
> > > factory instantiation strategy (I suppose that we
> > could use
> > > a singleton
> > > to get the DI hook, but that's an anti-design
> > pattern
> > > that I really
> > > would prefer to avoid at all costs).  Hopefully
> we can
> > > discuss this
> > > aspect a bit more after I understand why my
> @Replace
> > and
> > > @Resolve aren't
> > > working!
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ----------------------- Original Message
> > > -----------------------
> > > 
> > > From: <Nia...@ub...>
> > > To: <for...@tr...>,
> > > <sim...@li...>
> > > Cc: 
> > > Date: Thu, 22 Jan 2009 16:45:15 -0000
> > > Subject: RE: [Simple-support] Using constructors
> with
> > > arguments
> > > 
> > > Hi,
> > > 
> > > There is no need to do this. You can do the
> following.
> > > 
> > > @Root
> > > public class Tuple {
> > > 
> > > final private String from;
> > > final private String to;
> > > 
> > > public Tuple(String from, String to){
> > >     this.from = from;
> > >     this.to = to;
> > > }
> > > 
> > > @Replace
> > > private TupleSubstitute getSubstitute() {
> > >    return new TupleSubstitute(from, to);
> > > }
> > > 
> > > public String getFrom() {
> > >     return from;
> > > }
> > > 
> > > public String getTo() {
> > >     return to;
> > > }
> > > 
> > > public String toString() {
> > >     return from + " -> " + to;
> > > }
> > > 
> > > }
> > > 
> > > @Root
> > > private class TupleSubstitute {
> > > 
> > > @Element
> > > private String from;
> > > @Element
> > > private String to;
> > > 
> > > public TupleSubstitute() {
> > >   super();
> > > }
> > > 
> > > public TupleSubstitute(String from, String to) {
> > >   this.from = from;
> > >   this.to = to;
> > > }
> > > 
> > > @Resolve
> > > public Tuple getTuple() {
> > >   return new Tuple();
> > > }
> > > }
> > > 
> > > This should work, for you. The @Resolve
> annotation
> > resolves
> > > the
> > > deserialized object before assigning it to the
> field
> > or
> > > method. The
> > > @Replace object replaces the object in the
> stream.
> > Just
> > > like java object
> > > serialization. Let me know how this works out for
> you.
> > > 
> > > Hope this helps,
> > > Niall
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Kevin Day [mailto:for...@tr...]
> > > Sent: 21 January 2009 22:56
> > > To: Simple (Java Project)
> > > Subject: Re: [Simple-support] Using constructors
> with
> > > arguments
> > > 
> > > I've done some additional work on handling
> classes
> > that
> > > do not have
> > > zero-arg constructors.  First, I've put
> together
> > some
> > > simple sample code
> > > (attached, start with TryIt#main) that shows one
> of
> > the
> > > situations we
> > > are facing: we have a number of immutable Tuple
> > objects
> > > that we need to
> > > serialize/deserialze.  The values used in the
> Tuple
> > > class' constructor
> > > come from attributes (or elements) from the XML. 
> The
> > > attached
> > > serializes fine, but we can't deserialize it
> b/c
> > of the
> > > lack of
> > > no-argument constructor.  We can't add a
> no-arg
> > > constructor because the
> > > class is intended to be immutable (in fact, the
> fields
> > are
> > > marked as
> > > final).  In addition, the sample code shows the
> Tuple
> > > values as holding
> > > simple strings - but in our application, the
> values
> > are
> > > going to be
> > > complex objects.
> > > 
> > > 
> > > I have put together a Strategy and Type
> implementation
> > that
> > > *kind* of
> > > works, but I'm running into some issues (may
> be
> > related
> > > to my lack of
> > > familiarity with the code base).
> > > 
> > > The approach that I'm working on now creates
> a new
> > > Strategy that allows
> > > us to register special Type objects that can
> handle
> > object
> > > instantiation
> > > based on state of the deserialization process
> (for
> > now,
> > > I'm calling this
> > > FactoryGeneratedStrategy).  Ideally,
> > > FactoryGeneratedStrategy would be
> > > able to inter-operate with any other Strategy
> > > (DefaultStrategy,
> > > CycleStrategy, TreeStrategy) - after all,
> it's
> > only
> > > purpose is to help
> > > instantiate objects during deserialization - the
> > behavior
> > > of the other
> > > strategies is still desirable.
> > > 
> > > I ran into a couple of problems with this type of
> > Strategy
> > > chaining
> > > approach:
> > > 
> > > 1.  DefaultStrategy is not instantiable due to
> package
> > > scope visibility
> > > (this is the smaller issue) 2.  The other
> strategies
> > appear
> > > to be
> > > implemented in a way that assumes use of zero-arg
> > > constructors.  For
> > > example, CycleStrategy#getElement returns an
> Allocate
> > > object depending
> > > on the deserialization state.  The Allocate
> object is
> > > ultimately backed
> > > by an Instance object as it's delegate Type. 
> > Instance
> > > assumes a
> > > zero-arg constructor.
> > > 
> > > 
> > > Short of re-implementing all of the *Strategy
> classes,
> > I
> > > can't see how
> > > to go about providing a factory to create new
> object
> > > instances (without
> > > losing functionality provided by various Strategy
> > classes).
> > > 
> > > 
> > > My initial impression based on the above is that
> > Strategy
> > > may not be the
> > > appropriate place in the hierarchy to add object
> > > instantiation behavior.
> > > If not, where?  The Instantiator class seems a
> likely
> > > candidate, except
> > > that it's getInstace() method doesn't
> have
> > access
> > > to deserialization
> > > context information.
> > > 
> > > 
> > > 
> > > Maybe I'm just going about this all wrong... 
> If
> > anyone
> > > can provide some
> > > suggestions, I'd love to hear them!
> > > 
> > > 
> > > Thanks,
> > > 
> > > - K
> > > 
> > > 
> > > ----------------------- Original Message
> > > -----------------------
> > > 
> > > From: Kevin Day <ke...@tr...>
> > > To: Simple (Java Project)
> > > <sim...@li...>
> > > Cc: 
> > > Date: Tue, 20 Jan 2009 17:28:05 -0700
> > > Subject: [Simple-support] Using constructors with
> > arguments
> > > 
> > > For starters, I really like what I see in this
> project
> > > (just started
> > > reviewing it this afternoon).  I'm hoping
> that I
> > can
> > > get some pointers
> > > on a specific use-case.
> > > 
> > > 
> > > I would like to use Simple in conjunction with a
> > dependency
> > > injection
> > > system (probably Guice) and List implementations
> from
> > the
> > > GlazedLists
> > > project.
> > > 
> > > We have to use a constructor on our list
> > implementations
> > > that contains
> > > arguments (some of the arguments provided by
> Guice,
> > some
> > > from element or
> > > attribute data in the XML).
> > > 
> > > What is the best way to approach this with
> Simple?
> > > 
> > > It seems that some sort of Strategy mixed with a
> > custom
> > > Type is in
> > > order, but I'm not entirely clear on the best
> > approach.
> > >  The
> > > architecture of the framework looks powerful
> enough to
> > do
> > > what we need,
> > > but I can't see where to get started just
> yet.
> > > 
> > > 
> > > To give a pseudo-code example of what we are
> trying to
> > do
> > > (in real life,
> > > we'll be injecting SomeInjectedObject using
> Guice
> > or a
> > > factory/service
> > > provider call):
> > > 
> > > class SpecialList<E>{
> > > public SpecialList(SomeInjectedObject injected,
> String
> > > valueFromAttribute, SomeObject valueFromElement){
>  ...
> > > }
> > > }
> > > 
> > > 
> > > class MyObject{
> > > @ElementList
> > > SpecialList<ElementObject> list = new
> > >
> >
> SpecialList<ElementObject>(SomeInjectedObject.defaultInstance,
> > > "test",
> > > new SomeObject());
> > > 
> > > }
> > > 
> > > 
> > > When we serialize this with Simple, we'd like
> to
> > see
> > > something
> > > approximately like the following:
> > > 
> > > <myObject
> valueFromAttribute="test">
> > > <someObject> ... </someObject>
> > > <list>
> > > <elementObject> ... whatever goes into this
> ...
> > > </elementObject>
> > > <elementObject> ... whatever goes into this
> ...
> > > </elementObject>  ...
> > > </list>
> > > </myObject>
> > > 
> > > 
> > > Note that:
> > > 
> > > 1.  The <list> element doesn't have a
> class
> > > attribute 2.  When we
> > > construct the list during deserialization, we
> need to
> > be
> > > able to pull
> > > the 'valueFromAttribute' and
> > 'someObject'
> > > values to use during
> > > construction of the SpecialList object 3.  The
> > SpecialList
> > > object needs
> > > to have the 3 argument constructor called (not a
> > zero-arg
> > > constructor).
> > > And it is not possible to call a zero arg
> constructor,
> > then
> > > modify the
> > > object afterwards to get the same result.
> > > 
> > > 
> > > Any pointers?  I may be pushing the framework too
> hard
> > > (some of the
> > > above requirements can be relaxed - if it
> isn't
> > > possible to obtain
> > > valueFromAttribute or someObject at construction
> time,
> > we
> > > can find
> > > workarounds - but we have to be able to create
> the
> > > SpecialList instance
> > > using values from a factory/Guice/etc...).  For
> what
> > > it's worth, we have
> > > this type of behavior working in Betwixt using
> custom
> > > BeanCreator
> > > implementations.
> > > 
> > > Thanks much,
> > > 
> > > - Kevin
> > >
> >
> ------------------------------------------------------------------------
> > > ------
> > > This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > > 
> > > 
> > > _______________________________________________
> > > Simple-support mailing list
> > > Sim...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
> > > Visit our website at http://www.ubs.com
> > > 
> > > This message contains confidential information
> and is
> > > intended only for
> > > the individual named.  If you are not the named
> > addressee
> > > you should not
> > > disseminate, distribute or copy this e-mail. 
> Please
> > notify
> > > the sender
> > > immediately by e-mail if you have received this
> e-mail
> > by
> > > mistake and
> > > delete this e-mail from your system.
> > >  
> > > E-mails are not encrypted and cannot be
> guaranteed to
> > be
> > > secure or
> > > error-free as information could be intercepted,
> > corrupted,
> > > lost,
> > > destroyed, arrive late or incomplete, or contain
> > viruses. 
> > > The sender
> > > therefore does not accept liability for any
> errors or
> > > omissions in the
> > > contents of this message which arise as a result
> of
> > e-mail
> > > transmission.
> > > 
> > > If verification is required please request a
> hard-copy
> > > version.  This
> > > message is provided for informational purposes
> and
> > should
> > > not be
> > > construed as a solicitation or offer to buy or
> sell
> > any
> > > securities or
> > > related financial instruments.
> > > 
> > > UBS Limited is a company registered in England
> &
> > Wales
> > > under company
> > > number 2035362, whose registered office is at 1
> > Finsbury
> > > Avenue, London,
> > > EC2M 2PP, United Kingdom.
> > > 
> > > UBS AG (London Branch) is registered as a branch
> of a
> > > foreign company
> > > under number BR004507, whose registered office is
> at
> > > 1 Finsbury Avenue, London, EC2M 2PP, United
> Kingdom.
> > > 
> > > UBS Clearing and Execution Services Limited is a
> > company
> > > registered in
> > > England & Wales under company number
> 03123037,
> > whose
> > > registered office
> > > is at 1 Finsbury Avenue, London, EC2M 2PP, United
> > Kingdom.
> > > Visit our website at http://www.ubs.com
> > > 
> > > This message contains confidential information
> and is
> > > intended only 
> > > for the individual named.  If you are not the
> named
> > > addressee you 
> > > should not disseminate, distribute or copy this
> > e-mail. 
> > > Please 
> > > notify the sender immediately by e-mail if you
> have
> > > received this 
> > > e-mail by mistake and delete this e-mail from
> your
> > system.
> > >    
> > > E-mails are not encrypted and cannot be
> guaranteed to
> > be
> > > secure or 
> > > error-free as information could be intercepted,
> > corrupted,
> > > lost, 
> > > destroyed, arrive late or incomplete, or contain
> > viruses. 
> > > The sender 
> > > therefore does not accept liability for any
> errors or
> > > omissions in the 
> > > contents of this message which arise as a result
> of
> > e-mail
> > > transmission.  
> > > If verification is required please request a
> hard-copy
> > > version.  This 
> > > message is provided for informational purposes
> and
> > should
> > > not be 
> > > construed as a solicitation or offer to buy or
> sell
> > any
> > > securities 
> > > or related financial instruments.
> > > 
> > > UBS Limited is a company registered in England
> &
> > Wales
> > > under company
> > > number 2035362, whose registered office is at 1
> > Finsbury
> > > Avenue,
> > > London, EC2M 2PP, United Kingdom.
> > > 
> > > UBS AG (London Branch) is registered as a branch
> of a
> > > foreign company
> > > under number BR004507, whose registered office is
> at
> > > 1 Finsbury Avenue, London, EC2M 2PP, United
> Kingdom.
> > > 
> > > UBS Clearing and Execution Services Limited is a
> > company
> > > registered
> > > in England & Wales under company number
> 03123037,
> > whose
> > > registered
> > > office is at 1 Finsbury Avenue, London, EC2M 2PP,
> > United
> > > Kingdom.
> > > 
> > >
> >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > SourcForge Community
> > > SourceForge wants to tell your story.
> > > http://p.sf.net/sfu/sf-spreadtheword
> > > _______________________________________________
> > > Simple-support mailing list
> > > Sim...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
> > 
> > 
> >       
> > 
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Simple-support mailing list
> > Sim...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/simple-support
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Simple-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simple-support