[jira] Commented: (COCOON-1238) Improvements for CustomJXPathBinding

["Bart Molenkamp (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/COCOON-1238?page=comments#action_12364955 ] 

Bart Molenkamp commented on COCOON-1238:
----------------------------------------

The patch looks good to me. If I look at the files that I have here, they don't look the same as those that I uploaded. I guess I uploaded the wrong files, sorry. Your patch looks pretty much to what I have here, most important is that the statement 'jxpc.getRelativeContext(jxpc.getPointer(this.xpath))' is gone, and is left to the custom binding (this was causing crashes at the time).

I do think that this patch breaks backward compatibility, I don't know if that's a big problem.

> Improvements for CustomJXPathBinding
> ------------------------------------
>
>          Key: COCOON-1238
>          URL: http://issues.apache.org/jira/browse/COCOON-1238
>      Project: Cocoon
>         Type: Improvement
>   Components: Blocks: Forms
>     Versions: 2.1.5
>  Environment: Operating System: All
> Platform: All
>     Reporter: Bart Molenkamp
>     Assignee: Jean-Baptiste Quenot
>     Priority: Minor
>  Attachments: 20060201-cocoon-forms-1238, AbstractCustomBinding.java.patch, CustomJXPathBinding.java.patch, CustomJXPathBindingBuilder.java, CustomJXPathBindingBuilder.java.patch
>
> 2 improvements:
> 1. Custom bindings get a service manager when they implement Serviceable.
> 2. Relative JXPath context is not created. Instead, the current context, and the
> xpath query are passed to the custom binding. This allows bindings to set values
> for objects that are null (whereas a getRelativeContext() will throw an
> exception). Custom bindings now can do a
> context.createPathAndSetValue(getXpath(), ...) to set a value that was null
> before setting it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Improvements for CustomJXPathBinding

[Jean-Baptiste Quenot <jb...@apache.org>]

* Ralph Goers:

> The  question  is,  does  the current  behavior  work  for  some
> people or  is this a  flat-out bug? (This is a  general question
> applicable to any incompatible change).

The current way can work provided that the XML path already exists
in the  target document.  In  short, you  have to create  the path
manually to get  it to work!  Nobody seems to  object against this
modification, the feedback I received is rather positive.

This will  of course be mentioned  in the ChangeLog.  Is  there an
XML vocabulary allowing to add warnings in status.xml?
-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/

Re: Improvements for CustomJXPathBinding

[Ralph Goers <Ra...@dslextreme.com>]

My 2 cents.

The question is, does the current behavior work for some people or is 
this a flat-out bug? (This is a general question applicable to any 
incompatible change).

If the current way of working is broken then providing an incompatible 
fix is OK IMO.  If the current way can work for some people then the new 
behavior needs to be enabled via configuration.

Ralph


Jean-Baptiste Quenot wrote:

>Dear committers,
>
>Could  you  please comment  on  this?   Are  we allowed  to  break
>backwards compatibility on custom Java bindings?
>
>See http://issues.apache.org/jira/browse/COCOON-1238
>  
>

Re: Improvements for CustomJXPathBinding

[Jean-Baptiste Quenot <jb...@apache.org>]

Dear committers,

Could  you  please comment  on  this?   Are  we allowed  to  break
backwards compatibility on custom Java bindings?

See http://issues.apache.org/jira/browse/COCOON-1238
-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/