Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3F011DFB.6090706@outerthought.org>
Date: Tue, 01 Jul 2003 07:36:59 +0200
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: [woody] binding the forms to data
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

just want to share some thoughts on a possble nice addition for 
the woody forms, feel free to comment
(see http://wiki.cocoondev.org/Wiki.jsp?page=Woody for the 
miinimal current docs)


the woody forms as of today allow you to define the form-model 
(woody-definition file, with some validation in there) and have a 
way to template the defined widgets into an HTML-form frame 
(woody-template file)


however, filling the form with data comming from your backend 
needs to be done programmtically (various 
frm.getWidget(..).setValue (..) calls)

this got me thinking (and thinkering) towards a declarative way 
for expresiing what I would call 'form-binding'


Using a similar factory/builder pattern as the current woody 
forms there could be some binding-definition file that gets build 
  into some runtime Binding object that actually performs the 
trick for you:

Form frm ...;
BindingManager bm = serviceManager.lookup("..");
Binding b = bm.createBinding(source);

Object model = BackendService.interact();

b.loadFormFromModel(frm, model);

// and something similar for the way back?
b.saveFormToModel(frm,model)?


The actual binding definition file could be filled with:
<bnd:field id="widget-name"
            path="xpath expression into model" />

and possibly a bit more complex constructs to ease on the typing 
with context narrowing:

<bnd:context path="xpath to context">
   <bnd:field  path="relative-path" id="widget-name" />
   <bnd:field  path="relative-path" id="widget-name" />
</bnd:context>

Thinking about a context like 'address' and fields as
'addressline', 'city', 'zip'

This would call for the Binding object to be in fact a nested 
tree of binding objects reflecting the widget-tree inside the 
form.  Each of these Binding objects could then narrow the scope 
of the current context and pass over to the children to continue 
on the binding. (assuming jxpath usage for inspecting the model)

e.g. for this context-thing:
public void loadFormFromModel(
        ContainerWidget c, JXPathContext jxpc){

     JXPathContext subContext;
     subContext = jxpc.getRelativeContext(
               jxpc.getPointer(this.xpath));

     continueLoadingFromChildren(c, subContext);
}


similar there could be binding for repeaters and the new 
aggregate fields

<bnd:repeater path=".." id="..">
   <bnd:field .../>
</bnd:repeater>

<bnd:aggregate path=".." id="..">
   <bnd:field .../>
</bnd:aggregate>


Using JXPath there should be a fairly easy way to have this 
binding work for a backend producing either javabeans or XML files.


what do people think?

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org