You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bart Molenkamp <b....@bizzdesign.nl> on 2004/09/08 12:38:40 UTC

[CForms] Small "scope" patch in JXPathBindingBuilderBase.java (was: RE: [CForms] Change proposal in Custom bindings)

Hi,

I've created a patch, and attached it in this mail. Do I need to put it
in bugzilla (it's just a very very small patch)??

Bart.

> -----Original Message-----
> From: Bart Molenkamp
> Sent: Tuesday, September 07, 2004 3:29 PM
> To: dev@cocoon.apache.org
> Subject: RE: [CForms] Change proposal in Custom bindings
> 
> 
> 
> > -----Original Message-----
> > From: Marc Portier [mailto:mpo@outerthought.org]
> > Sent: Tuesday, September 07, 2004 3:18 PM
> > To: dev@cocoon.apache.org
> > Subject: Re: [CForms] Change proposal in Custom bindings
> >
> >
> >
> > Bart Molenkamp wrote:
> >
> > > Your solution works, tetting path to "." and passing another path
in
> a
> > > config element works. But I don't think it's a logical solution,
> since
> > > all binding elements look like <fb:... id="x" path="y"/>, except
for
> > > this one, where the path is passed in a config node.
> > >
> >
> > this is a matter of viewpoint I'm afraid
> >
> > personally I don't find it logical that your property might be null
> :-)
> >
> > > There is still a (small) problem however, I need a service
manager.
> > >
> >
> > yep, got that, that's why I suggested the own binding builder
> 
> BTW the patch I submitted already passes the service manager to custom
> bindings that implement Serviceable. It doesn't change anything for
> existing custom bindings. Maybe useful for custom bindings in general?
> 
> >
> > > If I want to straigt for my own binding builder, I have another
very
> > > very small change I need. The class
> > > JXPathBindingBuilderBase.CommonAttributes and the method
> > > getCommonAttributes() needs public (or protected) scope. That way
I
> can
> > > create the builder in my own packages.
> > >
> >
> > sure, makes sense!
> 
> Okay, so I'll write my own binding builder. Shall I put a patch for
> those 2 "scope" changes in bugzilla?
> 
> >
> > -marc=
> >
> > > Bart.
> > >
> > > -----Original Message-----
> > > From: Marc Portier [mailto:mpo@outerthought.org]
> > > Sent: Monday, September 06, 2004 5:21 PM
> > > To: dev@cocoon.apache.org
> > > Subject: Re: [CForms] Change proposal in Custom bindings
> > >
> > > I had a quick scan through your problem and patches (and sorry for
> not
> > > doing that earlier)
> > >
> > >
> > > AFAICS you would get the same effect by just ommitting the xpath
> from
> > > the binding and adding it as a nested config
> > >
> > > ie not
> > >    <fb:custom id="x" path="something"
> > >               builderclass="mypack.CustomValueWrapBinding"
> > >               factorymethod="createBinding" />
> > >
> > > but rather
> > >    <fb:custom id="config"
> > >               builderclass="mypack.CustomValueWrapBinding"
> > >               factorymethod="createBinding" >
> > >        <fb:config propspath="some" />
> > >    </fb:custom>
> > >
> > > that way the path="." will be assumed on the wrapper and the
> > > parent-context will be passed down so your custom binding can
narrow
> > > down with the local config 'propspath' (potentially checking for
> null's
> > > first)
> > >
> > > see
> http://cocoon.apache.org/2.1/userdocs/forms/binding.html#fb%3Acustom
> > >
> > >
> > > if you need more control then this, I suggest skipping the
> > > custom-binding alltogether and go straight for the own builder and
> > > binding + declaring the builder in the xconf file. (you're not
that
> far
> > > off)
> > >
> > > see
> > >
>
http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/conf/for
> > > ms-binding.xconf?rev=30945&root=Apache-SVN&view=auto
> > >
> > >
> > > above seems to indicate that what you need can be done already,
pls
> > > comment if that is not the case
> > >
> > > regards,
> > > -marc=
> > >
> > >
> > > Bart Molenkamp wrote:
> > >
> > >>Hi all,
> > >>
> > >>A few weeks ago I made a request for a small change in
> > >>CustomJXPathBinding. It can be found here [1]. I already
implemented
> > >
> > > the
> > >
> > >>change, made a patch, and placed it in bugzilla [2]. But noone was
> > >
> > > gave
> > >
> > >>me some response to this change (maybe due to vacations?) So I was
> > >>wondering; are there people interested in this change, or do I
need
> to
> > >>maintain this change in the source tree of my project?
> > >>
> > >>Bart.
> > >>
> > >>[1]
> > >
> > >
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109231695032545&w=2
> > >
> > >>[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=30693
> > >>
> > >
> > >
> >
> > --
> > Marc Portier                            http://outerthought.org/
> > Outerthought - Open Source, Java & XML Competence Support Center
> > Read my weblog at                http://blogs.cocoondev.org/mpo/
> > mpo@outerthought.org                              mpo@apache.org

Re: [CForms] Small "scope" patch in JXPathBindingBuilderBase.java (was: RE: [CForms] Change proposal in Custom bindings)

Posted by Marc Portier <mp...@outerthought.org>.
Bart,

I had some troubles with eclipse + subclipse but was working on the same
my commit and your patch just crossed.

I noticed you loosened the access on the inner class to public, just 
shout if you need it.

-marc=

Bart Molenkamp wrote:

> Hi,
> 
> I've created a patch, and attached it in this mail. Do I need to put it
> in bugzilla (it's just a very very small patch)??
> 
> Bart.
> 
> 
>>-----Original Message-----
>>From: Bart Molenkamp
>>Sent: Tuesday, September 07, 2004 3:29 PM
>>To: dev@cocoon.apache.org
>>Subject: RE: [CForms] Change proposal in Custom bindings
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Marc Portier [mailto:mpo@outerthought.org]
>>>Sent: Tuesday, September 07, 2004 3:18 PM
>>>To: dev@cocoon.apache.org
>>>Subject: Re: [CForms] Change proposal in Custom bindings
>>>
>>>
>>>
>>>Bart Molenkamp wrote:
>>>
>>>
>>>>Your solution works, tetting path to "." and passing another path
> 
> in
> 
>>a
>>
>>>>config element works. But I don't think it's a logical solution,
>>
>>since
>>
>>>>all binding elements look like <fb:... id="x" path="y"/>, except
> 
> for
> 
>>>>this one, where the path is passed in a config node.
>>>>
>>>
>>>this is a matter of viewpoint I'm afraid
>>>
>>>personally I don't find it logical that your property might be null
>>
>>:-)
>>
>>>>There is still a (small) problem however, I need a service
> 
> manager.
> 
>>>yep, got that, that's why I suggested the own binding builder
>>
>>BTW the patch I submitted already passes the service manager to custom
>>bindings that implement Serviceable. It doesn't change anything for
>>existing custom bindings. Maybe useful for custom bindings in general?
>>
>>
>>>>If I want to straigt for my own binding builder, I have another
> 
> very
> 
>>>>very small change I need. The class
>>>>JXPathBindingBuilderBase.CommonAttributes and the method
>>>>getCommonAttributes() needs public (or protected) scope. That way
> 
> I
> 
>>can
>>
>>>>create the builder in my own packages.
>>>>
>>>
>>>sure, makes sense!
>>
>>Okay, so I'll write my own binding builder. Shall I put a patch for
>>those 2 "scope" changes in bugzilla?
>>
>>
>>>-marc=
>>>
>>>
>>>>Bart.
>>>>
>>>>-----Original Message-----
>>>>From: Marc Portier [mailto:mpo@outerthought.org]
>>>>Sent: Monday, September 06, 2004 5:21 PM
>>>>To: dev@cocoon.apache.org
>>>>Subject: Re: [CForms] Change proposal in Custom bindings
>>>>
>>>>I had a quick scan through your problem and patches (and sorry for
>>
>>not
>>
>>>>doing that earlier)
>>>>
>>>>
>>>>AFAICS you would get the same effect by just ommitting the xpath
>>
>>from
>>
>>>>the binding and adding it as a nested config
>>>>
>>>>ie not
>>>>   <fb:custom id="x" path="something"
>>>>              builderclass="mypack.CustomValueWrapBinding"
>>>>              factorymethod="createBinding" />
>>>>
>>>>but rather
>>>>   <fb:custom id="config"
>>>>              builderclass="mypack.CustomValueWrapBinding"
>>>>              factorymethod="createBinding" >
>>>>       <fb:config propspath="some" />
>>>>   </fb:custom>
>>>>
>>>>that way the path="." will be assumed on the wrapper and the
>>>>parent-context will be passed down so your custom binding can
> 
> narrow
> 
>>>>down with the local config 'propspath' (potentially checking for
>>
>>null's
>>
>>>>first)
>>>>
>>>>see
>>
>>http://cocoon.apache.org/2.1/userdocs/forms/binding.html#fb%3Acustom
>>
>>>>
>>>>if you need more control then this, I suggest skipping the
>>>>custom-binding alltogether and go straight for the own builder and
>>>>binding + declaring the builder in the xconf file. (you're not
> 
> that
> 
>>far
>>
>>>>off)
>>>>
>>>>see
>>>>
>>
> http://cvs.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/conf/for
> 
>>>>ms-binding.xconf?rev=30945&root=Apache-SVN&view=auto
>>>>
>>>>
>>>>above seems to indicate that what you need can be done already,
> 
> pls
> 
>>>>comment if that is not the case
>>>>
>>>>regards,
>>>>-marc=
>>>>
>>>>
>>>>Bart Molenkamp wrote:
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>A few weeks ago I made a request for a small change in
>>>>>CustomJXPathBinding. It can be found here [1]. I already
> 
> implemented
> 
>>>>the
>>>>
>>>>
>>>>>change, made a patch, and placed it in bugzilla [2]. But noone was
>>>>
>>>>gave
>>>>
>>>>
>>>>>me some response to this change (maybe due to vacations?) So I was
>>>>>wondering; are there people interested in this change, or do I
> 
> need
> 
>>to
>>
>>>>>maintain this change in the source tree of my project?
>>>>>
>>>>>Bart.
>>>>>
>>>>>[1]
>>>>
>>>>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109231695032545&w=2
> 
>>>>>[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=30693
>>>>>
>>>>
>>>>
>>>--
>>>Marc Portier                            http://outerthought.org/
>>>Outerthought - Open Source, Java & XML Competence Support Center
>>>Read my weblog at                http://blogs.cocoondev.org/mpo/
>>>mpo@outerthought.org                              mpo@apache.org
> 
> 

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org