springframework-developer

Re: [Springframework-developer] xml dtd addition for bean id reference

[<jue...@we...>]

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:

>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
>>
>>>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
>>>
>>>>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
>>>>
>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
>>>>
>>>>>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
>>>>>
>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

RE: [Springframework-developer] xml dtd addition for bean id reference

[<jue...@we...>]

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

Re: [Springframework-developer] xml dtd addition for bean id reference

[Colin S. <col...@ex...>]

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 
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 
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ürgen höller [werk3AT] wrote:

>Colin,
> 
>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.
> 
>  <ref bean="...">
>  <idref bean="...">
> 
>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.
> 
>BTW, I'd also like to remove the deprecated <ref external="..."> as of RC1, to just keep <ref local="..."> and <ref bean="...">. 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.
> 
>Juergen
> 
>
>________________________________
>
>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="interceptorNames">
>     <list>
>       <value>hibInterceptor</value>
>       <value>matchAllTxInterceptor</value>
>     </list>
>   </property>
>
>can now become
>
>   <property name="interceptorNames">
>     <list>
>       <beanid local="hibInterceptor"/>
>       <beanid local="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:
>
>  
>
>>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
>>
>>
>>
>>
>>    
>>
>>>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:
>>>
>>>  
>>>
>>>      
>>>
>>>>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:
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>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
>>>>>      
>>>>>
>>>>>          
>>>>>
>>usage,
>>
>>
>>    
>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>>>The recent switch in AbstractAutoProxyCreate which forced me to switch
>>>>>>some BeanNameAutoProxyCreator configs from something like
>>>>>>...
>>>>>>   <property name="interceptorNames">
>>>>>>    <list>
>>>>>>      <ref bean="hibInterceptor"/>
>>>>>>      <ref bean="matchAllTxInterceptor</ref>
>>>>>>    </list>
>>>>>>  </property>
>>>>>>...
>>>>>>
>>>>>>to
>>>>>>...
>>>>>>  <property name="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="xxx" />
>>>>>>the xml processor can do it, while
>>>>>> <ref bean="xxx" />
>>>>>>can be validate by the loader or something like an Eclipse plugin. But
>>>>>>
>>>>>>  <property name="interceptorNames">
>>>>>>    <list>
>>>>>>      <value>something</value>
>>>>>>    </list>
>>>>>>  </property>
>>>>>>
>>>>>>can only be validate by the user of that property.  So how about we
>>>>>>        
>>>>>>
>>>>>>            
>>>>>>
>>add
>>
>>
>>    
>>
>>>>>>another element which is used to produce a text value which is a bean
>>>>>>id. That is:
>>>>>>  <property name="interceptorNames">
>>>>>>    <list>
>>>>>>      <beanid bean="a-local-or-external-bean"/>
>>>>>>      <beanid local="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
>>>>>>            
>>>>>>