[Forms] Protected methods in o.a.c.forms.datatype.typeimpl.AbstractDatatype

[Ugo Cei <ug...@apache.org>]

Folks,

I'm trying to write a custom CForms datatype. I'd have some general 
considerations about how hard this is, considering the need to patch 
cocoon.xconf to extend the forms type system, which makes me want to go 
growing vineyards in the hillsides (do we really need all this Avalon 
stuff just to configure a set of factories?), but I'll leave that for 
another thread.

Anyway, my problem at the moment is that I started by copying 
StringType and StringTypeBuilder and trying to modify them for my 
needs. I also copied them to a package belonging to my application and 
outside of o.a.c.forms.datatype.typeimpl. This datatype is peculiar to 
my app and it makes no sense as part of Cocoon.

Unfortunately, this breaks StringTypeBuilder (which is now called, say, 
MyTypeBuilder) because it does things like:

type.setArrayType(arrayType);
type.setBuilder(this);

those methods are inherited from AbstractDatatype, where they are 
declared as "protected". Thus, I was painfully reminded that protected 
members in Java are visible not only to subclasses, but to all other 
classes in the same package as well! As long as StringTypeBuilder is in 
the same package as AbstractDatatype, all is well, but as soon as I 
copy it to com.example.mypackage.MyTypeBuilder, it doesn't compile 
anymore.

Now, there's a quick workaround to that: I could just override the 
methods in MyType and delegate to super. Somehow I think this is not 
very elegant.

I'd like to make them public, but this bugs me a little, as it means 
increasing the "surface complexity" of AbstractDatatype. However, I 
cannot think of a better solution. Do you?

	Ugo

-- 
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/

Re: [Forms] Protected methods in o.a.c.forms.datatype.typeimpl.AbstractDatatype

[Ugo Cei <ug...@apache.org>]

Il giorno 18/lug/05, alle 22:56, Jason Johnston ha scritto:

> It's not the exact same problem as Ugo is describing but the end effect
> is the same... it is impossible to create a custom CForms component in 
> a
> package other than o.a.c.forms.

Well, nothing is impossible. You can always ovveride the protected 
methods and delegate to super, as a workaround.

> Perhaps both Ugo's issue and mine could be fixed at the same time.
> --Jason

I could certainly fix it with a simple patch, but I wanted to publicly 
raise the issue before. Since I got no reply beside yours, I will 
probably do it right away.

	Ugo

-- 
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/

Re: [Forms] Protected methods in o.a.c.forms.datatype.typeimpl.AbstractDatatype

[Jason Johnston <ja...@Intrado.com>]

On Fri, 2005-07-15 at 17:29 +0200, Ugo Cei wrote:
> 
> those methods are inherited from AbstractDatatype, where they are 
> declared as "protected". Thus, I was painfully reminded that protected 
> members in Java are visible not only to subclasses, but to all other 
> classes in the same package as well! As long as StringTypeBuilder is in 
> the same package as AbstractDatatype, all is well, but as soon as I 
> copy it to com.example.mypackage.MyTypeBuilder, it doesn't compile 
> anymore.

I think this might be a good opportunity to bring up again a similar
problem with creating jxpath bindings outside the o.a.c.forms.binding
package.  I had posted this problem on this list several months ago with
no reply.  Here is the message again:

> On Tue, 2005-01-04 at 14:43 -0700, Jason Johnston wrote:
> Hi folks-- I'm trying to create a custom binding by extending
> JXPathBindingBase and JXPathBindingBuilderBase for the binding and
> binding builder respectively.  My classes, of course, live in a
> different package than o.a.c.forms.binding.
> 
> My builder class is able to access the protected inner class
> JXPathBindingBuilderBase.CommonAttributes just fine, because it is a
> direct subclass of JXPathBindingBuilderBase.  But the binding class
> fails because it also needs access to CommonAttributes (see the
> JXPathBindingBase constructor), but neither extends nor resides in the
> same package as JXPathBindingBuilderBase so CommonAttributes is not
> visible.
> 
> Anyone know of a reason why CommonAttributes is protected rather than
> public?  Any objections to making it public?

It's not the exact same problem as Ugo is describing but the end effect
is the same... it is impossible to create a custom CForms component in a
package other than o.a.c.forms.

Perhaps both Ugo's issue and mine could be fixed at the same time.
--Jason