You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by vi...@gmxpro.net on 2003/06/17 23:35:13 UTC
Clazz User Guide
Hi!
I have uploaded the first few paragraphs of my User Guide to
http://www.artive.de/clazz/docs/userguide.html
I am not promising to finish it, but if not, you can use it (put it under
the
Apache license) and change it anyway you want.
I am (for now) very willing to make corrections, especially concerning
the language (I am not a native speaker, if anyone didn't recognize yet
:-)).
Victor
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[Clazz] getFoos and addFoo: property name "foos" or "foo"
Posted by vi...@gmxpro.net.
--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Wed, 18 Jun 2003 15:24:35 +0200 (MEST)
From: victor.volle@gmxpro.net
To: commons-dev@jakarta.apache.org
Subject: getFoos and addFoo: property name "foos" or "foo"
> Hi,
>
> if I have the following class
>
> public class Hrglbrmft {
> public void addFoo(Bar bar) { ... }
> public List getFoos() { ... }
> }
>
> should the property returned by Clazz be called "foos" or "foo"?
>
> Currently "foos" is returned.
>
> Victor
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
getFoos and addFoo: property name "foos" or "foo"
Posted by vi...@gmxpro.net.
Hi,
if I have the following class
public class Hrglbrmft {
public void addFoo(Bar bar) { ... }
public List getFoos() { ... }
}
should the property returned by Clazz be called "foos" or "foo"?
Currently "foos" is returned.
Victor
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Extending Clazz
Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Victor,
1. Are you really trying to add support for a FAMILY of reflected
clazzes? It almost sounds to me that you want to modify accessor
recognition for some specific clazzes. If that's what you are trying to
accomplish. There is a much easier way to do so: you create a custom
Clazz. If it is named propery, it will be automatically discovered by
the framework. See for example
org.apache.commons.clazz.reflect.extended.CustomBean1ExtendedClazz
2. The reason all those things are implemented as subclasses rather
than configuration-based instances is precisely to avoid the need for
configuration. In any complex environment you are working with lots of
ClassLoaders, which are allocated by some container. A ClazzLoader is
automatically allocated by Clazz for each ClassLoader as needed. Where
would we put the hook for configuration?
3. AccessorMethodParsers rather than subclassing them is really not an
option either. An AccessorMethodParser needs access to the Method to
extract its piece-parts from it. There is no easy way to predict what
those parts are. Will it use the type of some argument or some part of
the method name or its visibility or exceptions thrown - who can now?
It is important to understand that you only need to go through all this
trouble of creating ClazzLoaders and custom implementation of Clazz if
you are introducing a new programming model like Extended Java Bean or
something of sorts. You don't need to do any of that if you just need
to customize an individual clazz: for that you either create a specific
custom implementation of Clazz or use BeanInfo.
- Dmitri
--- victor.volle@gmxpro.net wrote:
> From the (perhaps not quite current?) overview I concluded that
> to extend Clazz for "Customizing a Family of Reflected Clazzes"
> I have to create
>
> 1) a subclass of Reflected*PropertyInspector
> 2) some (two) AccessMethodParsers
> 3) a subclass of (Standard)ReflectedClazz
> 4) a subclass of ReflectedClazzLoader
> 5) add the ClazzLoader created in step 4 to an
> existing ClazzLoader
>
> I find this quite a lot to do.
>
> 1) Wouldn't it be possible to create a new _instance_
> of ReflectedPropertyInspector and configure the
> (two) AcessMethodParsers.
> 2) Wouldn't it be possible to simply create a new
> instance of a BaseAccessMethodParser that has
> some methods like
>
> - getRequiredPrefix AND setRequiredPrefix (etc.)
>
> so that again, I would not need to subclass
> 3) The only reason to create a new subclass of
> ReflectedClazz seems to be that it has to implement
> getPropertyInspectors().
> Why is this method in ReflectedClazz and not in
> ClazzLoader?
> And again why do I have to subclass wouldn't
> a BaseReflectedClazz with getter AND setter for
> PropertyInspectors be sufficient?
> 4) ...
>
> So it mostly boils down to subclassing vs. "configuring".
>
> (Besides the remark on the placement of the
> getPropertyInspectors() method in step 3) which I simply
> do not understand.)
>
> I do not know, if it's just my preference, but I really dislike
> having so many classes around.
>
> The simplest solution I could imagine looks something like:
>
> AccessorMethodParser readMethod = new BaseAccessMethodParser();
> readMethod.setRequiredPrefix("add");
> readMethod.setRequiredParameterCount(1);
> readMethod.set...
> // for some methods like getValueType() a subclass might still be
> needed!
>
> AccessorMethodParser writeMethod = new BaseAccessMethodParser();
> ...
>
> reflectedPropertyInspector inspector =
> new ReflectedPropertyInspector(readMethod, writeMethod);
>
> ClazzLoader clazzLoader = ...;
> clazzLoader.appendPropertyInspector(inspector);
>
> Could this work with Clazz?
>
> Regards
> Victor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Extending Clazz
Posted by vi...@gmxpro.net.
>From the (perhaps not quite current?) overview I concluded that
to extend Clazz for "Customizing a Family of Reflected Clazzes"
I have to create
1) a subclass of Reflected*PropertyInspector
2) some (two) AccessMethodParsers
3) a subclass of (Standard)ReflectedClazz
4) a subclass of ReflectedClazzLoader
5) add the ClazzLoader created in step 4 to an
existing ClazzLoader
I find this quite a lot to do.
1) Wouldn't it be possible to create a new _instance_
of ReflectedPropertyInspector and configure the
(two) AcessMethodParsers.
2) Wouldn't it be possible to simply create a new
instance of a BaseAccessMethodParser that has
some methods like
- getRequiredPrefix AND setRequiredPrefix (etc.)
so that again, I would not need to subclass
3) The only reason to create a new subclass of
ReflectedClazz seems to be that it has to implement
getPropertyInspectors().
Why is this method in ReflectedClazz and not in
ClazzLoader?
And again why do I have to subclass wouldn't
a BaseReflectedClazz with getter AND setter for
PropertyInspectors be sufficient?
4) ...
So it mostly boils down to subclassing vs. "configuring".
(Besides the remark on the placement of the
getPropertyInspectors() method in step 3) which I simply
do not understand.)
I do not know, if it's just my preference, but I really dislike
having so many classes around.
The simplest solution I could imagine looks something like:
AccessorMethodParser readMethod = new BaseAccessMethodParser();
readMethod.setRequiredPrefix("add");
readMethod.setRequiredParameterCount(1);
readMethod.set...
// for some methods like getValueType() a subclass might still be needed!
AccessorMethodParser writeMethod = new BaseAccessMethodParser();
...
reflectedPropertyInspector inspector =
new ReflectedPropertyInspector(readMethod, writeMethod);
ClazzLoader clazzLoader = ...;
clazzLoader.appendPropertyInspector(inspector);
Could this work with Clazz?
Regards
Victor
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Clazz User Guide
Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Great! Do you want to merge my overview with it?
http://jakarta.apache.org/commons/sandbox/clazz/overview.html
It would be great if the user guide were in xdocs. This way we could
easily incorporate it into the clazz website.
Thanks,
- Dmitri
--- victor.volle@gmxpro.net wrote:
> Hi!
>
> I have uploaded the first few paragraphs of my User Guide to
>
> http://www.artive.de/clazz/docs/userguide.html
>
> I am not promising to finish it, but if not, you can use it (put it
> under
> the
> Apache license) and change it anyway you want.
>
> I am (for now) very willing to make corrections, especially
> concerning
> the language (I am not a native speaker, if anyone didn't recognize
> yet
> :-)).
>
> Victor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org