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