You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <ou...@wlkp.org> on 2004/04/06 12:30:03 UTC
CForms v2 and bizData strange handling
Hello,
I've been looking at the v2 version of cforms and AFAIU there is no way to
pass additional bizData to the showForm method. The only way is to do:
form["bizData"] = bizData;
form.showForm( viewUri );
I find it very awkward. Let me give you the example. I have a page that
contains a CForms form. This is the definition:
<?xml version="1.0" encoding="utf-8"?>
<fd:form xmlns:fd="http://apache.org/cocoon/forms/1.0#definition"
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<fd:widgets>
<!-- filtering widgets -->
<fd:field id="companyName" required="false">
<fd:datatype base="string"/>
</fd:field>
<fd:submit id="search" action-command="search" validate="true">
<fd:label>Szukaj</fd:label>
</fd:submit>
<!-- rowset ordering -->
<fd:field id="orderBy" required="true">
<fd:datatype base="string"/>
</fd:field>
<fd:field id="direction" required="true">
<fd:datatype base="string"/>
</fd:field>
<!-- rowset navigation -->
<fd:submit id="next" action-command="next" validate="true">
<fd:label>next</fd:label>
</fd:submit>
<fd:submit id="prev" action-command="prev" validate="true">
<fd:label>prev</fd:label>
</fd:submit>
<fd:submit id="first" action-command="next" validate="true">
<fd:label>first</fd:label>
</fd:submit>
<fd:submit id="last" action-command="prev" validate="true">
<fd:label>last</fd:label>
</fd:submit>
</fd:widgets>
</fd:form>
So I use the form only to provide the displayed rowset with the ability to
filter it, order the rows, navigate through the multiple paged result.
The data that is passed to the view is:
- global application context
- currently logged in user info (name, last login etc.)
- user context ( ie. user can make bookmarks to tasks in the application )
- the rowset displayed
- current page context ( i.e. if the rowset is the list of projects, the
page header contains the info on the contractor that these projects were
created for)
none of these is strictly connected to the form (the only one is the rowset
displayed as the form controls invoke actions that change this part of view).
In v2 I have to do something like this:
form = new Form( definition );
form[ "globalAppContext" ] = getGlobalAppContext();
form[ "user" ] = getLoggedInUser();
form[ "userContext" ] = getContextForUser( getLoggedInUser() );
form[ "items" ] = rowset;
form [ "pageContext" ] = contractor;
everything is doable so far but if I were to give somebody my code he would
surely ask me: why is the form top level object in your page model?
It looks like the form is the most important part of the model here while it
is completely not true. Moreover if I wanted to turn over the rowset
capabilities it would also affect other page parts (I would have to rewrite
the whole view to use new variable paths)
WDYT?
lg
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: CForms v2 and bizData strange handling
Posted by Christopher Oliver <re...@verizon.net>.
Leszek Gawron wrote:
><snip>
>
>none of these is strictly connected to the form (the only one is the rowset
>displayed as the form controls invoke actions that change this part of view).
>
>In v2 I have to do something like this:
>
>form = new Form( definition );
>
>form[ "globalAppContext" ] = getGlobalAppContext();
>form[ "user" ] = getLoggedInUser();
>form[ "userContext" ] = getContextForUser( getLoggedInUser() );
>form[ "items" ] = rowset;
>form [ "pageContext" ] = contractor;
>
>everything is doable so far but if I were to give somebody my code he would
>surely ask me: why is the form top level object in your page model?
>
>It looks like the form is the most important part of the model here while it
>is completely not true. Moreover if I wanted to turn over the rowset
>capabilities it would also affect other page parts (I would have to rewrite
>the whole view to use new variable paths)
>
>WDYT?
> lg
>
>
This is based on the fact that the current API is form.showForm(), i.e.
"show this form". Thus the context object sent to the pipeline ends up
being the (single) form.
I think your comments are valid, but calling
form.showForm(pageDataOutsideThisForm) is equally non-intuitive IMO. The
V2 API is by no means intended to be final and was meant to spur
discussion so thanks for your comments.
Chris
Re: CForms v2 and bizData strange handling
Posted by Leszek Gawron <ou...@wlkp.org>.
On Tue, Apr 06, 2004 at 02:14:24PM +0100, Tim Larson wrote:
> On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
> > In v2 I have to do something like this:
> >
> > form = new Form( definition );
> >
> > form[ "globalAppContext" ] = getGlobalAppContext();
> > form[ "user" ] = getLoggedInUser();
> > form[ "userContext" ] = getContextForUser( getLoggedInUser() );
> > form[ "items" ] = rowset;
> > form [ "pageContext" ] = contractor;
> >
> > everything is doable so far but if I were to give somebody my code he would
> > surely ask me: why is the form top level object in your page model?
>
> I also found this strange. IMHO this needs to be changed, becase as
> we are finding out, the form is not the page. Think of examples like
> portals, pages containing several forms, etc. The form should just
> use one customizable key, to allow for multiple forms and other data.
You are right. I have also doubts about how to implement a page that contains
more than one form (i.e. two managed rowsets). I would have to maintain widget
names unique across multiple widget definition.
I think it would be good if the form itself had an id. For example a top
level widget username gets a request parameter named loginform.username - this
way multipleforms wouldn't use the same req params by mistake.
WDYT?
lg
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@wlkp.org _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: CForms v2 and bizData strange handling
Posted by Christopher Oliver <re...@verizon.net>.
Tim Larson wrote:
>On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
>
>
>>In v2 I have to do something like this:
>>
>>form = new Form( definition );
>>
>>form[ "globalAppContext" ] = getGlobalAppContext();
>>form[ "user" ] = getLoggedInUser();
>>form[ "userContext" ] = getContextForUser( getLoggedInUser() );
>>form[ "items" ] = rowset;
>>form [ "pageContext" ] = contractor;
>>
>>everything is doable so far but if I were to give somebody my code he would
>>surely ask me: why is the form top level object in your page model?
>>
>>
>
>I also found this strange. IMHO this needs to be changed, becase as
>we are finding out, the form is not the page. Think of examples like
>portals, pages containing several forms, etc. The form should just
>use one customizable key, to allow for multiple forms and other data.
>
>--Tim Larson
>
>
>
Can you elaborate more on this? It seems to me that there is a
significant difference between a portal and a multi-form page. In the
case of a portal, the content of the page consists of multiple separate
applications (each with its own independent page flow). Also if CForms
were to support multi-form pages how would that work?
Regards,
Chris
Re: CForms v2 and bizData strange handling
Posted by Tim Larson <ti...@keow.org>.
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
> In v2 I have to do something like this:
>
> form = new Form( definition );
>
> form[ "globalAppContext" ] = getGlobalAppContext();
> form[ "user" ] = getLoggedInUser();
> form[ "userContext" ] = getContextForUser( getLoggedInUser() );
> form[ "items" ] = rowset;
> form [ "pageContext" ] = contractor;
>
> everything is doable so far but if I were to give somebody my code he would
> surely ask me: why is the form top level object in your page model?
I also found this strange. IMHO this needs to be changed, becase as
we are finding out, the form is not the page. Think of examples like
portals, pages containing several forms, etc. The form should just
use one customizable key, to allow for multiple forms and other data.
--Tim Larson