cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
Date Thu, 04 Dec 2003 00:02:57 GMT
Timothy,

the rudimentary dox (see wiki) on the simple-repeater-binding are 
explaining this:

It is currently only supporting binding back to XML (so I suspect that 
you were testing versus a java beans backend model here?)

we briefly discussed this recently (and I was getting into doing it, but 
am caught up on a local conference here the next few days)

see this thread:
http://marc.theaimsgroup.com/?t=106976455300001&r=1&w=2

the idea would be to have a similar entry for <on-insert-row> nested in 
the simple-repeater-binding as borrowed from the classic repeater-binding?

in fact I started thinking about this some more first (also based on 
some private mails with Jeremy who was so kind to let me in on some more 
  hibernate details and issues in his current project)

some (random order) observations/suggestions on repeater binding as is now:

- repeater-bindings have no @readonly to shut down the save() operation
   like the field-binding has it.

- in fact it also struck me that the @readonly concept only allows us to 
choose between two modes of operation : 1/ do load AND save 2/ do only 
load.  Maybe we should provide a generic attribute on all bindings that 
looks like @direction and can hold load|save|both (probably even 
implement this at the level of the abstract base class?)

- confusion between simple and classic repeater binding... I understand 
that we have two strategies that both have their special uses cases, but 
I would like to have a more syntactic similarities between both to lower 
the usage confusion (and switching effort) ... in fact maybe we should 
even go for a single <wb: element-name for both and switch between both 
by using some @strategy, @flavour or @type

- in any case we should remove the XML only limitation from the simple 
repeater, since it's somewhat fighting with the principle of least 
surprise, no?


oh, I also thought some about this:
http://marc.theaimsgroup.com/?t=107035200100002&r=1&w=2
and currently have a patch on HD that is introducing an extra attribute 
row-path-insert for the classic (not-simple) repeater-binding that is 
used for depicting where the rows to be inserted should go in... (in 
stead of just reusing the @row-path for that purpose)


but maybe we should take a more holistic view on things and maybe first 
discuss a broader binding-syntax redo starting from above suggestions?

(by the way: any suggestions from users having a more usability opinion 
is welcome, maybe I was (we are) a tad too much focussed on processing 
the thing when we defined the original semantics of the file?)


in any case I hope we can synchronize our updating efforts here?

wdot?

regards,
-marc=
PS: sorry for lagging behind on your new widget-types, but wouldn't they 
require separate and specific binding-types rather then fixing the 
repeater-binding to work on them as well?



Timothy Larson wrote:

> --- Timothy Larson <timlarsonwork@yahoo.com> wrote:
> 
>>Does anybody have a working sample of a simple-repeater binding?
>>I am trying to adapt the binding to work with (you guessed it)
>>class, new, struct, and union, but I am having trouble getting
>>the simple-repeater binding working.
> 
> 
> More information:
> The regular repeater binding works for me, but the simple-repeater
> throws an exception about the factory not being set on the jxpath
> context.
> 
>   <!-- Regular repeater binding: works -->
>   <wb:repeater id="contacts"
>     parent-path="contacts"
>     row-path="contact"
>     unique-row-id="id"
>     unique-path="@id">
>     <wb:on-bind>
>       <wb:value id="sample" path="name"/>
>     </wb:on-bind>
>   </wb:repeater>
> 
>   <!-- Simple repeater binding: does not work -->
>   <wb:simple-repeater id="contacts"
>     parent-path="contacts"
>     row-path="contact">
>     <wb:value id="sample" path="name"/>
>   </wb:simple-repeater>
> 
> Exception:
> 
> cause: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1];
> Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
> 
> -----------------------------------------------
> Interesting part of exception chain stacktrace:
> 
> Original Exception: org.apache.commons.jxpath.JXPathException: Exception trying to create
xpath
> contact[1]; Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
> 
> 	at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
> 
> 	at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
> 
> 	at
> org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
> 
> 	at
> org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
> 
> 	at
> org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
> 
> 	at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
> 
> 	at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
> 
> -------------------------------
> Interesting part of stacktrace:
> 
> Caused by: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath
contact[1];
> Factory is not set on the JXPathContext - cannot create path:
> /wd:form[1]/wd:widgets[1]/contacts[1]
> 
> 	at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420)
> 
> 	at
> org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397)
> 
> 	at
> org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149)
> 
> 	at
> org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108)
> 
> 	at
> org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107)
> 
> 	at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119)
> 
> 	at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
> 
> ------------
> --Tim Larson
> 
> 
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> 

-- 
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


Mime
View raw message