> -----Original Message----- > From: Marc Portier [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 07, 2004 3:18 PM > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > Sent: Monday, September 06, 2004 5:21 PM > > To: [EMAIL PROTECTED] > > 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/ > [EMAIL PROTECTED] [EMAIL PROTECTED]
