You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by co...@apache.org on 2001/01/20 12:10:26 UTC

cvs commit: jakarta-ant/src/main/org/apache/tools/ant IntrospectionHelper.java

conor       01/01/20 03:10:26

  Modified:    src/main/org/apache/tools/ant IntrospectionHelper.java
  Log:
  Change to IntrospectionHelper to support creation of nested elements
  through a createElement(String elementName) factory method. This has two
  applications.
  
  It allows a task to define what nested elements are supported
  dynamically, perhaps through a configuration file. This is useful
  for tasks that support a plug-in architecture, as I am trying to
  achieve with <ejbjar>
  
  As a byproduct, it also allows a task to support nested elements which
  cannot be mapped to valid Java method names, such as <support-classes>. The
  use of hyphenated compound names is relatively common style in XML DTDs
  
  Revision  Changes    Path
  1.12      +31 -6     jakarta-ant/src/main/org/apache/tools/ant/IntrospectionHelper.java
  
  Index: IntrospectionHelper.java
  ===================================================================
  RCS file: /home/cvs/jakarta-ant/src/main/org/apache/tools/ant/IntrospectionHelper.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- IntrospectionHelper.java	2001/01/03 14:18:26	1.11
  +++ IntrospectionHelper.java	2001/01/20 11:10:25	1.12
  @@ -96,6 +96,13 @@
       private Method addText = null;
   
       /**
  +     * The method used to add nested elements which can't be added through
  +     * nested creators. It allows a task to define a factory method for creating
  +     * nested elements.
  +     */
  +    private Method elementFactoryMethod = null;
  +
  +    /**
        * The Class that's been introspected.
        */
       private Class bean;
  @@ -138,6 +145,14 @@
                   && java.lang.String.class.equals(args[0])) {
   
                   addText = methods[i];
  +                
  +            } else if ("createElement".equals(name)
  +                       && !returnType.isArray()
  +                       && !returnType.isPrimitive()
  +                       && args.length == 1
  +                       && java.lang.String.class.equals(args[0])) {
  +
  +                elementFactoryMethod = methods[i];
   
               } else if (name.startsWith("set")
                          && java.lang.Void.TYPE.equals(returnType)
  @@ -266,13 +281,23 @@
       public Object createElement(Object element, String elementName) 
           throws BuildException {
           NestedCreator nc = (NestedCreator) nestedCreators.get(elementName);
  -        if (nc == null) {
  -            String msg = "Class " + element.getClass().getName() +
  -                " doesn't support the nested \"" + elementName + "\" element";
  -            throw new BuildException(msg);
  -        }
           try {
  -            return nc.create(element);
  +            if (nc == null) {
  +                Object nestedElement = null;
  +                if (elementFactoryMethod != null) {
  +                    nestedElement 
  +                        = elementFactoryMethod.invoke(element, new Object[] {elementName});
  +                }
  +                if (nestedElement == null) {
  +                    String msg = "Class " + element.getClass().getName() +
  +                        " doesn't support the nested \"" + elementName + "\" element";
  +                    throw new BuildException(msg);
  +                }
  +                return nestedElement;
  +            }
  +            else {
  +                return nc.create(element);
  +            }
           } catch (IllegalAccessException ie) {
               // impossible as getMethods should only return public methods
               throw new BuildException(ie);
  
  
  

Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant IntrospectionHelper.java

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
From: "Peter Donald" <do...@apache.org>
>
> I am not sure I completely like this.
> [snip]
> I don't think I see this as a desirable quality (at least in the normal
> case).

Pete, you need to be more definitive :-)

> If the tasks are free to optionally support things then it can allow
> the task writer to get away with things that are plain wrong and painful
> for the user. Can you give an example of when it would *good* to allow
> tasks to do this ?

Exactly the example, I gave, where a task supports some form of plug-in
concept. In that case, it would be good to have the nested elements be data
driven, rather than having to code each createXXX method. You are probably
right, the benfits are limited, and it may be open to abuse, so I have
given it the flick :-).

Conor



Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant IntrospectionHelper.java

Posted by Peter Donald <do...@apache.org>.
At 11:10  20/1/01 -0000, conor@apache.org wrote:
>conor       01/01/20 03:10:26
>
>  Modified:    src/main/org/apache/tools/ant IntrospectionHelper.java
>  Log:
>  Change to IntrospectionHelper to support creation of nested elements
>  through a createElement(String elementName) factory method. This has two
>  applications.

I am not sure I completely like this.
  
>  It allows a task to define what nested elements are supported
>  dynamically, perhaps through a configuration file. This is useful
>  for tasks that support a plug-in architecture, as I am trying to
>  achieve with <ejbjar>

I don't think I see this as a desirable quality (at least in the normal
case). If the tasks are free to optionally support things then it can allow
the task writer to get away with things that are plain wrong and painful
for the user. Can you give an example of when it would *good* to allow
tasks to do this ? The one special case that I can think of is if someone
wanted to write an if/then/else task but I am not sure this is the way I
would do it anyways.

>  As a byproduct, it also allows a task to support nested elements which
>  cannot be mapped to valid Java method names, such as <support-classes>. The
>  use of hyphenated compound names is relatively common style in XML DTDs

I don't see this as an advantage. This can be done safer other ways and it
seems it is only being done because it can. For instance I don't think
there is many (any???) illegal xml names that are not java names except for 
1. xml names that start with a numeric
2. xml names that embedd '-'

1 is not an issue as we prefix set to it. 2 can be got around other ways.
For instance in myrmidon I would translate support-classes into the method

setSupportClasses() which is a much better way IMHO.



Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*