Menu
▾
▴
RE: [Springframework-developer] xml dtd addition for bean id reference
|
From: <jue...@we...> - 2004-01-19 13:28:06
|
Colin, Point taken regarding making clear that it's about a reference to beans = - but the same also applies to the general "ref" tag. My main concern is = consistency across the current tags in the spring-beans DTD: That's why = I consider "idref" the best name in addition to the existing "ref". Don't bother with these changes: I've already tried the new name on my = machine, and can commit the change as soon as the SourceForge CVS server = works again (can't reach it currently). I've also already removed the = "external" support. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, January 19, 2004 2:21 PM To: spr...@li... Subject: Re: [Springframework-developer] xml dtd addition for bean id reference I'm totally ok with calling the element 'idref'. My original intent with = 'beanid' was to make it clear that it referred to bean ids, not to ids=20 of elements in general, since at some point Spring itself will hopefully = validate that it matches real bean ids. I think if it's documented=20 that's fine; beans are after the most important element in the = documents... I am also ok with removing the deprecated external tag. If I don't hear anything in a few hours I'll make these changes. j=FCrgen h=F6ller [werk3AT] wrote: >Colin, >=20 >That's a good new feature! However, I'm not entirely happy with the = name "beanid", as it misses the referential aspect - it sounds more like = you're defining a bean ID itself there. The original tag was "ref", and = I think we should build on that name: so what about "idref", as it's = about a reference to an id (instead of a full object)? I've already = tried this locally on my machine, to check whether the name was reserved = or anything. >=20 > <ref bean=3D"..."> > <idref bean=3D"..."> >=20 >Both would refer to a bean, but the former to the bean object, the = latter just to a bean ID. I think it's better than "refid", which would = suggest the ID *of* a reference rather than a reference *to* and ID. = What do you think? I'm of course open for any other suggestions. >=20 >BTW, I'd also like to remove the deprecated <ref external=3D"..."> as = of RC1, to just keep <ref local=3D"..."> and <ref bean=3D"...">. We've = announced that quite a while ago and have not been using it in any = examples. And after all, migration is easy: simply rename "ref external" = to "ref bean", and you're done. >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Sa 17.01.2004 18:10 >An: spr...@li...; = spr...@li... >Betreff: [Springframework-developer] xml dtd addition for bean id = reference > > > >I've checked in code which supports a new beanid element in the xml >beanfactory/context definition, as follows: > ><!-- > Defines a string property value, which must also be the id of = another > bean in this factory or an external factory (parent or included >factory). > While a regular 'value' element could instead be used for the same >effect, > using beanid in this case allows validation of local bean ids by = the xml > parser, and name completion by helper tools. >--> ><!ELEMENT beanid EMPTY> > ><!-- > Beanids must specify a name of the target bean. > The "bean" attribute can reference any name from any bean in the >context, > to be checked at runtime by future Spring implementations. > Local references, using the "local" attribute, have to use bean = ids; > they can be checked by this DTD, thus should be preferred for = references > within the same bean factory XML file. >--> ><!ATTLIST beanid bean CDATA #IMPLIED> ><!ATTLIST beanid local IDREF #IMPLIED> > >This is the simplistic implementation, which immediately converts the >attribute to a string property, same as a <value> element would, at >parse time, so it doesn't touch very much code. > >It is mostly useful with the 'local' attribute so that the parser >validates bean id literal values immediately, instead of relying on the >component using those values to do it later. It is also useful for any >kind of IDE plugin to do name completion. > >So a BeanNameAutoProxyCreator config which currently includes the >following property: > > <property name=3D"interceptorNames"> > <list> > <value>hibInterceptor</value> > <value>matchAllTxInterceptor</value> > </list> > </property> > >can now become > > <property name=3D"interceptorNames"> > <list> > <beanid local=3D"hibInterceptor"/> > <beanid local=3D"matchAllTxInterceptor"/> > </list> > </property> > >and benefit from parser validation. > >If somebody thinks another name would be more suitable for this = element, >please speak up. Other possibilities would be > bean-id > refid > ref-id > >Regards, >Colin > > >Rod Johnson wrote: > > =20 > >>Colin >> >>I think the first way would be preferable at this late stage. It's = backward >>compatible anyway--previous definitions will still work--so I'm happy = for >>you to do it. >> >>We can always improve the implementation in future. >> >>I'm happy with beanid/bean for naming. >> >>Regards, >>Rod >> >>----- Original Message ----- >>From: "Colin Sampaleanu" <col...@ex...> >>To: <spr...@li...> >>Sent: Saturday, January 17, 2004 4:45 AM >>Subject: Re: [Springframework-developer] xml dtd addition for bean id >>reference >> >> >> >> >> =20 >> >>>I took a bit of a look at this. It would be completely trivial to >>>support at a basic level, where the element would be converted at = parse >>>time into a string, essentially exactly resolving to exactly the same = as >>><value>xx/<value>. This would allow validation of local beans via the >>>xml parser's idref mechanism, but would not allow Spring (or anybody >>>else using the parser) to validate external bean ids, since the info >>>would be lost. >>> >>>The better option would be to treat it in a way similar to the same = way >>><ref> is treated right now, via a special placeholder similar to = ref's >>>RuntimeBeanReference. This touches a lot more code though. >>> >>>Unless there is opposition I would like to add at least the basic = level >>>mentioned in the first paragraph. I think it's a piece of low-hanging >>>fruit that will save some people from typos a bit earlier in the >>>build/deploy/test cycle... >>> >>> >>> >>>Colin Sampaleanu wrote: >>> >>> =20 >>> >>> =20 >>> >>>>Actually, now that I think about it, it's not just about validation. >>>>If you are in an IDE plugin, the new element would allow the plugin = to >>>>offer code completion on the id name... Otherwise (with the present >>>>setup), it would have to know something about the actual object = using >>>>those properties, to know they are in fact bean ids... >>>> >>>> >>>>Rod Johnson wrote: >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Mmm, I'd need to think about that. I guess the validation potential >>>>>would be >>>>>good. Thoughts? >>>>> >>>>>Btw the switch from interceptors to interceptorNames was necessary = as >>>>>the >>>>>old way was conceptually wrong. It couldn't handle common >>>>>interceptors or >>>>>advisors that were prototypes. This is important to support mixin >>>>> =20 >>>>> >>>>> =20 >>>>> >>usage, >> >> >> =20 >> >>>>>which should now always work correctly. >>>>> >>>>>Rod >>>>> >>>>>----- Original Message ----- >>>>>From: "Colin Sampaleanu" <col...@ex...> >>>>>To: <spr...@li...> >>>>>Sent: Wednesday, January 14, 2004 5:32 PM >>>>>Subject: [Springframework-developer] xml dtd addition for bean id >>>>>reference >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>>>The recent switch in AbstractAutoProxyCreate which forced me to = switch >>>>>>some BeanNameAutoProxyCreator configs from something like >>>>>>... >>>>>> <property name=3D"interceptorNames"> >>>>>> <list> >>>>>> <ref bean=3D"hibInterceptor"/> >>>>>> <ref bean=3D"matchAllTxInterceptor</ref> >>>>>> </list> >>>>>> </property> >>>>>>... >>>>>> >>>>>>to >>>>>>... >>>>>> <property name=3D"interceptorNames"> >>>>>> <list> >>>>>> <value>hibInterceptor</value> >>>>>> <value>matchAllTxInterceptor</value> >>>>>> </list> >>>>>> </property> >>>>>>... >>>>>> >>>>>>got me thinking that the former did have the advantage of being = much >>>>>>easier to validate without getting the actual user of the = properties >>>>>>(the postprocessor in this case) involved. That is, in the case of = a >>>>>> <ref local=3D"xxx" /> >>>>>>the xml processor can do it, while >>>>>> <ref bean=3D"xxx" /> >>>>>>can be validate by the loader or something like an Eclipse plugin. = But >>>>>> >>>>>> <property name=3D"interceptorNames"> >>>>>> <list> >>>>>> <value>something</value> >>>>>> </list> >>>>>> </property> >>>>>> >>>>>>can only be validate by the user of that property. So how about = we >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>add >> >> >> =20 >> >>>>>>another element which is used to produce a text value which is a = bean >>>>>>id. That is: >>>>>> <property name=3D"interceptorNames"> >>>>>> <list> >>>>>> <beanid bean=3D"a-local-or-external-bean"/> >>>>>> <beanid local=3D"a-local-bean"/> >>>>>> </list> >>>>>> </property> >>>>>> >>>>>>The latter beanid element would be checked by the xml processor. = The >>>>>>former would be checkable only by the loader or by something like = an >>>>>>IDE >>>>>>plugin. >>>>>> >>>>>>What does everybody think? >>>>>> >>>>>>Regards, >>>>>>Colin >>>>>> =20 >>>>>> ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
