[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_f

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Isabelle, Rod=0D=0A=0D=0AVery good proposal from Isabelle and Rod's an=
swer. Replacing "name" by "id" and "ref" by "refid" will simplify the fut=
ure DTD checking.=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial He=
ader -----------=0D=0A=0D=0AFrom      : springframework-developer-admin@l=
ists.sourceforge.net=0D=0ATo          : "Isabelle Muszynski" <isabelle@me=
ta-logix.com>=0D=0ACc          : <spr...@li...=
orge.net>=0D=0ADate      : Wed, 28 May 2003 09:22:04 +0100=0D=0ASubject :=
 Re: [Springframework-developer] Spring bean factory XML format=0D=0A=0D=0A=
Why not replace "name" attribute with "id"? Why do we need a name attribu=
te?=0D=0A=0D=0A----- Original Message -----=0D=0AFrom: "Isabelle Muszynsk=
i" <isa...@me...>=0D=0ATo: "Rod Johnson" <rod.johnson@interfac=
e21.com>=0D=0ACc: <spr...@li...>=0D=0A=
Sent: Wednesday, May 28, 2003 8:43 AM=0D=0ASubject: Re: [Springframework-=
developer] Spring bean factory XML format=0D=0A=0D=0A=0D=0AHi Rod,=0D=0A=0D=
=0AThere is one thing I do not like about your proposed syntax: you use <=
ref=0D=0Aname=3D"xxx"> is used in two different contexts, one when you de=
fine a bean=0D=0Athat can serve as a reference, and once when you refer t=
o such a bean from=0D=0Aanother bean.=0D=0AThat's confusing. It would be =
better to define with for ex. an id attribute,=0D=0Aand reference with a =
refid attribute:=0D=0A=0D=0A<bean name=3D"foo" id=3D"foo"/>=0D=0A<bean na=
me=3D"bar" id=3D"bar">=0D=0A  <property name=3D"thefoo" refid=3D"foo/>=0D=
=0A  <property name=3D"moo">moo</property>=0D=0A</bean>=0D=0A<bean name=3D=
baz>=0D=0A  <property name=3D"bla">blabla</property>=0D=0A</bean>=0D=0A=0D=
=0ANote that bean bar can in turn be referenced from other beans, thanks =
to its=0D=0Aid attribute. Bean baz cannot be referenced, because it doesn=
't have an id=0D=0Aattribute.=0D=0A=0D=0AA validating parser will not hel=
p you make sure that bean foo really exists=0D=0Awhen referenced, and nei=
ther will a DTD.=0D=0A=0D=0AIsabelle=0D=0A=0D=0A=0D=0AOn Wed, May 28, 200=
3 at 08:16:10AM +0100, Rod Johnson wrote:=0D=0A> I've checked in the chan=
ges (backward compatible for now).  I'll tidy it=0D=0Aup=0D=0A> after we =
decide on a definitive strategy.=0D=0A>=0D=0A> JP, thanks for your commen=
ts on the XML. The XML certainly can be changed=0D=0Aat=0D=0A> this stage=
 if we agree on an alternative.=0D=0A>=0D=0A> Regards,=0D=0A> Rod=0D=0A>=0D=
=0A> ----- Original Message -----=0D=0A> From: "JP Pawlak" <jp.pawlak@tis=
cali.fr>=0D=0A> To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <juergen.hoelle=
r...@we...>; "'Rod=0D=0A> Johnson'" <rod...@in...>;=0D=0A=
> <spr...@li...>=0D=0A> Sent: Wednesda=
y, May 28, 2003 7:56 AM=0D=0A> Subject: RE : [Springframework-developer] =
Spring bean factory XML format=0D=0A>=0D=0A>=0D=0A> Hi Rod, J=C3=BCrgen,=0D=
=0A>=0D=0A> I agree that formalism gains to be changed.=0D=0A> Mapping pr=
operties and CSV looked always strange.=0D=0A> We can keep compatibility,=
 but release 0.8=0D=0A> before fixing the new one would be a bad beginnin=
g.=0D=0A>=0D=0A> I'm not an XML expert, but worked with. I have some rema=
rks:=0D=0A>=0D=0A> First, attributes "name", "class" and "singleton" are =
straightforward and=0D=0A> clean.=0D=0A> The "beanref" as a boolean had p=
oor value and changed the meaning of the=0D=0A> body! Avoiding this will =
be safer.=0D=0A> The main isuue is with organizing the "value" part.=0D=0A=
>=0D=0A> Single values:=0D=0A> If anything is allowed in the body, the me=
aning shall always be the same.=0D=0AWe=0D=0A> can consider it will be th=
e litteral value.=0D=0A> My proposition will be:=0D=0A>   <property name=3D=
"xxx">yyy</bean>=0D=0A> An alternative could be accepted:=0D=0A>   <prope=
rty name=3D"xxx" value=3D"yyy"/>=0D=0A>=0D=0A> If the unique value is a b=
ean reference, the body has to be empty:=0D=0A>   <property name=3D"xxx" =
ref=3D"zzz"/>=0D=0A>=0D=0A> Multiple values:=0D=0A> I don't like=0D=0A>  =
 <property name=3D"jumble">=0D=0A>      <ref name=3D"david"/>=0D=0A>     =
 <value>literal</value>=0D=0A>      <ref name=3D"jenny" />=0D=0A>   </pro=
perty>=0D=0A>=0D=0A> The ref name=3D"xxx" has a poor value, we have two e=
ntities for only one=0D=0A> information.=0D=0A>=0D=0A> Because of differe=
nt tag names. "ref" and "value" are both data in the=0D=0A> collection.=0D=
=0A> I prefer such as:=0D=0A>   <property name=3D"jumble">=0D=0A>      <d=
ata ref=3D"david"/>=0D=0A>      <data value=3D"literal"/>=0D=0A>      <da=
ta>literal2</data>=0D=0A>      <data ref=3D"jenny" />=0D=0A>   </property=
>=0D=0A>=0D=0A> The "data" element could have a better name.=0D=0A>=0D=0A=
> So we could have a consistent definition, both in property and data:=0D=
=0A> The value is either the body either the value attribute.=0D=0A> The =
bean reference is always the ref attribute.=0D=0A>=0D=0A> The property el=
ement could only have in its body a text(the sole litteral=0D=0A> value) =
or a data elements collection.=0D=0A>=0D=0A>=0D=0A> Regards,=0D=0A> Jean-=
Pierre=0D=0A>=0D=0A>=0D=0A> > -----Message d'origine-----=0D=0A> > De : s=
pri...@li...=0D=0A> > [mailto:spr=
ing...@li...]=0D=0A> >  De la part =
de j=C3=BCrgen h=C3=B6ller [werk3AT]=0D=0A> > Envoy=C3=A9 : mercredi 28 m=
ai 2003 07:33=0D=0A> > =C3=80 : Rod Johnson; springframework-developer@li=
sts.sourceforge.net=0D=0A> > Objet : Re: [Springframework-developer] Spri=
ng bean factory XML format=0D=0A> >=0D=0A> >=0D=0A> > Hi Rod,=0D=0A> >=0D=
=0A> > I agree that the new format makes sense. I didn't think about=0D=0A=
> > validating the XML before, but to my understanding you're=0D=0A> > ri=
ght about the pitfalls. Keeping backwards compatibility for=0D=0A> > the =
moment makes sense, as each and every application context=0D=0A> > defini=
tion will be affected (admittedly in a straightforward way).=0D=0A> >=0D=0A=
> > So besides the <ref> tag, there's a <value> tag now, for=0D=0A> > mix=
ed collections. I guess it can also be used with a single=0D=0A> > value =
property like this:=0D=0A> >=0D=0A> > <property name=3D"name"><value>Rod<=
/value></property>=0D=0A> >=0D=0A> > Do you recommend this syntax for suc=
h properties too? Does it=0D=0A> > add any value in terms of validation? =
We should definitely=0D=0A> > stick to one recommended syntax, to avoid c=
onfusion.=0D=0A> >=0D=0A> > Regarding beans that expose CSV properties: I=
've already=0D=0A> > tried to clean many of the exposed bean properties w=
ithin=0D=0A> > Spring (e.g. both commandClass and commandClassName, now o=
nly=0D=0A> > the former because of the ClassEditor), we should try to=0D=0A=
> > continue this for multiple value properties. I guess if=0D=0A> > choi=
ce doesn't add real value, it rather causes confusion.=0D=0A> >=0D=0A> > =
I'm not an XML expert, so I can't really help in terms of=0D=0A> > furthe=
r improvements. Does anyone else have some thoughts on this?=0D=0A> >=0D=0A=
> > Regards,=0D=0A> > Juergen=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -----Ur=
spr=C3=BCngliche Nachricht-----=0D=0A> > Von: Rod Johnson [mailto:rod.joh=
ns...@in...]=0D=0A> > Gesendet: Di 27.05.2003 22:19=0D=0A> > An:=
 spr...@li...=0D=0A> > Cc:=0D=0A> > Be=
treff: Re: [Springframework-developer] Spring bean=0D=0A> > factory XML f=
ormat=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > I've successfully prototyped th=
is idea.=0D=0A> >=0D=0A> > The new format looks like:=0D=0A> >=0D=0A> > <=
bean name=3D"rod" class=3D"com.interface21.beans.TestBean">=0D=0A> > <pro=
perty name=3D"name">Rod</property>=0D=0A> > <property name=3D"age">32</pr=
operty>=0D=0A> > <property name=3D"friends">=0D=0A> >   <ref name=3D"jenn=
y"/>=0D=0A> >   <ref name=3D"david"/>=0D=0A> > </property>=0D=0A> > </bea=
n>=0D=0A> >=0D=0A> > <!--=0D=0A> > Try setting a collection property to a=
 single value=0D=0A> > -->=0D=0A> > <bean name=3D"loner" class=3D"com.int=
erface21.beans.TestBean">=0D=0A> > <property name=3D"name">loner</propert=
y>=0D=0A> > <property name=3D"age">26</property>=0D=0A> > <property name=3D=
"friends">=0D=0A> >   <ref name=3D"david"/>=0D=0A> > </property>=0D=0A> >=
 </bean>=0D=0A> >=0D=0A> > <bean name=3D"jumble"=0D=0A> > class=3D"com.in=
terface21.beans.factory.xml.MixedCollectionBean">=0D=0A> > <property name=
=3D"jumble">=0D=0A> >    <ref name=3D"david"/>=0D=0A> >    <value>literal=
</value>=0D=0A> >    <ref name=3D"jenny" />=0D=0A> > </property>=0D=0A> >=
 </bean>=0D=0A> >=0D=0A> > I haven't dropped backward compatibility, or c=
hecked=0D=0A> > anything in.=0D=0A> >=0D=0A> > If we agree this is an imp=
rovement, I'll check in these=0D=0A> > changes this week. I=0D=0A> > gues=
s I don't need to drop backward compatibility right=0D=0A> > now (beanRef=
), but=0D=0A> > I think it should be dropped before 1.0.=0D=0A> >=0D=0A> =
> I'm open to suggestions as to how to improve the XML further.=0D=0A> >=0D=
=0A> > Regards,=0D=0A> > Rod=0D=0A> >=0D=0A> > ----- Original Message ---=
--=0D=0A> > From: "Rod Johnson" <rod...@in...>=0D=0A> > To=
: <spr...@li...>=0D=0A> > Sent: Tuesda=
y, May 27, 2003 6:20 PM=0D=0A> > Subject: [Springframework-developer] Spr=
ing bean=0D=0A> > factory XML format=0D=0A> >=0D=0A> >=0D=0A> > > Guys,=0D=
=0A> > >=0D=0A> > > I've just been thinking about an important potential =
issue.=0D=0A> > >=0D=0A> > > The current XML bean-reference syntax looks =
like:=0D=0A> > > <property name=3D"foo" beanRef=3D"true">myFooBean</prope=
rty>=0D=0A> > >=0D=0A> > > and, for lists etc (where a bean exposes a "CS=
V" property)=0D=0A> > > <property name=3D"foos">a,b,c</property>=0D=0A> >=
 >=0D=0A> > > While this syntax is concise, I think there are some=0D=0A>=
 > issues we should=0D=0A> > > discuss.=0D=0A> > >=0D=0A> > > a. It's har=
d to validate this. There's no validatable=0D=0A> > reference to another=0D=
=0A> > > bean element id. It would be great if an XML editor=0D=0A> > cou=
ld help us in this=0D=0A> > > regard.=0D=0A> > > b. It's inelegant. The u=
se of the CDATA in the=0D=0A> > property element as a=0D=0A> > string=0D=0A=
> > > value or a reference (depending on the presence of an=0D=0A> > attr=
ibute) is a bit=0D=0A> > > messy.=0D=0A> > > c. The CSV format is really =
a hack, that I used once=0D=0A> > and then reused. Not=0D=0A> > > only do=
es the CSV make no sense to an XML editor=0D=0A> > (analogous to putting =
CSV=0D=0A> > > data in an RDBMS), it places the onus on each class=0D=0A>=
 > to parse the CSV and=0D=0A> > > look up the necessary beans. This make=
s classes=0D=0A> > exposing CSV properties=0D=0A> > > dependent on the ow=
ning BeanFactory, lessening the=0D=0A> > value of Spring's=0D=0A> > > tra=
nsparence. (Admittedly this is concealed in=0D=0A> > framework classes, s=
o it=0D=0A> > > doesn't really affect developers.) With the proposed=0D=0A=
> > new way, any=0D=0A> > > application code could benefit from collectio=
n &=0D=0A> > array support.=0D=0A> > > d. The new way would make it easy =
to write XSLT that=0D=0A> > showed relationships=0D=0A> > > among Spring =
beans. This could be handy for=0D=0A> > generating documentation about=0D=
=0A> > > Spring apps.=0D=0A> > >=0D=0A> > > So I've been thinking of chan=
ges along the lines of:=0D=0A> > >=0D=0A> > > <property name=3D"foo">=0D=0A=
> > >     <ref name=3D"myFooBean" />=0D=0A> > > </property>=0D=0A> > >=0D=
=0A> > > and=0D=0A> > >=0D=0A> > > <property name=3D"foos">=0D=0A> > >   =
  <ref name=3D"a" />=0D=0A> > >     <ref name=3D"b"/>=0D=0A> > >     <ref=
 name=3D"c"/>=0D=0A> > > </property>=0D=0A> > >=0D=0A> > > In this case t=
he foos bean class would expose a=0D=0A> > Collection or array=0D=0A> > >=
 property, and the bean factory would no how to=0D=0A> > populate that fr=
om the=0D=0A> > > runtime references. No dependence on the fw even for=0D=
=0A> > managing collection=0D=0A> > > properties.=0D=0A> > >=0D=0A> > > I=
've already prototyped the idea of a <ref>=0D=0A> > subelement, and that =
was=0D=0A> > pretty=0D=0A> > > simple to implement.  I'll experiment with=
=0D=0A> > collections tonight.=0D=0A> > >=0D=0A> > > Apart from changing =
XML files, the flow-on effect=0D=0A> > would mean that anything=0D=0A> > =
> that exposed a CSV property (like the AOP interceptor=0D=0A> > proxy) w=
ould change=0D=0A> > to=0D=0A> > > exposing a Collection or array.=0D=0A>=
 > >=0D=0A> > > What do you think? I'd like thoughts on the following=0D=0A=
> > questions:=0D=0A> > >=0D=0A> > > 1. Does everyone agree that this is =
worth doing?=0D=0A> > >=0D=0A> > > 2. To support a collection including l=
iteral values,=0D=0A> > should we introduce a=0D=0A> > > new <value> elem=
ent, meaning that simple properties=0D=0A> > would become=0D=0A> > > <pro=
perty name=3D"foo"><value>canConvert this=0D=0A> > string</value></proper=
ty>.=0D=0A> > More=0D=0A> > > verbose, but more elegant.=0D=0A> > >=0D=0A=
> > > 3. Is there a way to help XML enforce the references=0D=0A> > autom=
atically? E.g.=0D=0A> > > change bean "name" to "id" and use a <href> ins=
tead=0D=0A> > of a <ref>? I haven't=0D=0A> > > had a chance to explore th=
is yet, but hopefully=0D=0A> > someone knows XML better=0D=0A> > > than I=
 do.=0D=0A> > >=0D=0A> > > 4. If this is worth doing, should we do it in =
0.8,=0D=0A> > even if it delays the=0D=0A> > > release  (as it would)? On=
 the one hand, we should=0D=0A> > try to release ASAP. On=0D=0A> > > the =
other hand, this change would break all existing=0D=0A> > applications. E=
ven=0D=0A> > > though they'd be easy to fix, it might irritate=0D=0A> > u=
sers. So the choice is:=0D=0A> > > - release now with a likely incompatib=
le change in store=0D=0A> > > - accept a delay=0D=0A> > >=0D=0A> > > We'd=
 also have to introduce analogous support for the=0D=0A> > properties for=
mat,=0D=0A> > > which couldn't benefit from XML capabilities. The=0D=0A> =
> properties format would=0D=0A> > > probably change very little.=0D=0A> =
> >=0D=0A> > > Regards,=0D=0A> > > Rod=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=
=0A> > >=0D=0A> > > -----------------------------------------------------=
--=0D=0A> > > This SF.net email is sponsored by: ObjectStore.=0D=0A> > > =
If flattening out C++ or Java code to make your=0D=0A> > application fit =
in a=0D=0A> > > relational database is painful, don't do it! Check=0D=0A>=
 > out ObjectStore.=0D=0A> > > Now part of Progress Software.=0D=0A> > ht=
tp://www.objectstore.net/sourceforge=0D=0A> > >=0D=0A> > ________________=
_______________________________=0D=0A> > > Springframework-developer mail=
ing list=0D=0A> > > Spr...@li...=0D=0A=
> > >=0D=0A> > > https://lists.sourceforge.net/lists/listinfo/springframe=
work-developer=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -------------=
------------------------------------------=0D=0A> > This SF.net email is =
sponsored by: ObjectStore.=0D=0A> > If flattening out C++ or Java code to=
 make your=0D=0A> > application fit in a=0D=0A> > relational database is =
painful, don't do it! Check out=0D=0A> > ObjectStore.=0D=0A> > Now part o=
f Progress Software.=0D=0A> > http://www.objectstore.net/sourceforge=0D=0A=
> >=0D=0A> > _______________________________________________=0D=0A> > Spr=
ingframework-developer mailing list=0D=0A> > Springframework-developer@li=
sts.sourceforge.net=0D=0A> >=0D=0A> > > https://lists.sourceforge.net/lis=
ts/listinfo/springframework-developer=0D=0A> >=0D=0A> >=0D=0A> > N=18HYX=E9=
=8A=B2un7+~V=0D=0A> > /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv=0D=0A> =
> =17=E8=92=8B9r=D4=A2=0D=0A> > >=DA=BAJ   y=CB=B6=EB=B2=8Bq =E7=AE=A6 G =
j) =D4=AE)~{=0D=0A> > zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=
=96=B3 ~ G=0D=0A> >=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A> ------------------=
-------------------------------------=0D=0A> This SF.net email is sponsor=
ed by: ObjectStore.=0D=0A> If flattening out C++ or Java code to make you=
r application fit in a=0D=0A> relational database is painful, don't do it=
! Check out ObjectStore.=0D=0A> Now part of Progress Software. http://www=
.objectstore.net/sourceforge=0D=0A> _____________________________________=
__________=0D=0A> Springframework-developer mailing list=0D=0A> Springfra=
mew...@li...=0D=0A> https://lists.sourceforge.n=
et/lists/listinfo/springframework-developer=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=
=0A> -------------------------------------------------------=0D=0A> This =
SF.net email is sponsored by: ObjectStore.=0D=0A> If flattening out C++ o=
r Java code to make your application fit in a=0D=0A> relational database =
is painful, don't do it! Check out ObjectStore.=0D=0A> Now part of Progre=
ss Software. http://www.objectstore.net/sourceforge=0D=0A> ______________=
_________________________________=0D=0A> Springframework-developer mailin=
g list=0D=0A> Spr...@li...=0D=0A> http=
s://lists.sourceforge.net/lists/listinfo/springframework-developer=0D=0A>=
=0D=0A>=0D=0A=0D=0A--=0D=0AIsabelle Muszynski=0D=0ASoftware Engineer=0D=0A=
Zandweellaan 4=0D=0A2660 Antwerpen=0D=0ABelgium=0D=0ATel. 32-(0)3-830 18 =
54=0D=0AMobile: 32-(0)485 49 50 89=0D=0AEmail: isa...@me...=0D=
=0AWebsite: www.meta-logix.com=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-------------=
------------------------------------------=0D=0AThis SF.net email is spon=
sored by: ObjectStore.=0D=0AIf flattening out C++ or Java code to make yo=
ur application fit in a=0D=0Arelational database is painful, don't do it!=
 Check out ObjectStore.=0D=0ANow part of Progress Software. http://www.ob=
jectstore.net/sourceforge=0D=0A__________________________________________=
_____=0D=0ASpringframework-developer mailing list=0D=0ASpringframework-de=
ve...@li...=0D=0Ahttps://lists.sourceforge.net/lists/li=
stinfo/springframework-developer=0D=0A=0A=0A********** SPECIAL ADSL *****=
*****=0AL'ADSL =E0 partir de 15,95 EUR/mois et le modem ADSL offert ?  C'=
est en exclusivit=E9 chez Tiscali !=0APour profiter de cette offre, cliqu=
ez ici: http://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A=

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_f

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=