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