Makes flow script the sitemap ugly? (was: Re: [vote] forbidding flowscripts with no sendpage redirects)

[Joerg Heinicke <jh...@virbus.de>]

On 11.11.2003 15:48, Geoff Howard wrote:

> In fact, I think that flow in some cases needlessly 
> complicates the composition of a pipeline.  Now I have to have two 
> pipelines where I used to need one.  I have to have one that matches the 
> external request and calls the flow function, and another one for the 
> default result of that pipeline.

I have exactly the same feeling about the flow. I talked about exactly 
the same with Sylvain in private communication (btw: Did you ignore my 
last email or didn't you receive it, Sylvain. I sent it on the day you 
had problems with Anywhere mail to your Apache account - which is 
probably forwarded to Anywhere :-( ). In German slang I would call the 
flow "drangepappt". How can this be translated into English: The flow is 
not integrated into the sitemap very well and makes the sitemap flow 
somewhat opaque or obfusicated. How must look into the flow to 
understand what's going on in the sitemap. And if it is so why not 
integrating the flow script into the sitemap directly? No, I don't want 
to have Javascript in the sitemap, it's only a bad feeling about that. 
Especially because of the two-side dependency from sitemap to flow to 
sitemap.

> So far this has felt like needless 
> additional complexity to me (and I think will to others).
> 
> To try to make this point a little clearer:
> Part of the beauty of the sitemap prior to flow was that you could at a 
> glance see what each request url was triggering.  Now, I look at the 
> sitemap, have to locate the flowscript, parse through it for the various 
> sendPage etc. and then back to the sitemap to find where the action 
> really happens.  This could perhaps be handled with some best practice 
> naming conventions.  Perhaps a practice of passing in the various 
> possible view uris to the flowscript should be considered.  I don't know.

Naming conventions is to weak to handle this IMHO.

> I'm not negative on flow, and not positive on actions - just pointing 
> out a loss of readability of the sitemap that has resulted from our move 
> forward.

I can not be negative on flow, because I don't have participated in flow 
discussions at that time. But it's my bad feeling about this stuff.

Any comments or flames ;-)

Joerg

Using a generic sitemap + flow (was: Makes flow script the sitemap ugly?)

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi:

I read the lastest comments about flow and I want to share with the rest
of you my own experiences.

We are developing database oriented webapp. We are using, well I will
repeat it again :-), Flow+Woody+OJB, JXGenerator and Druid.

And I think Flow help us in the SoC. I will try to explain it:

1-Main sitemap: Just declare all the components that the application need.
Here we have all the <map:components> + some pipelines that manage:

a) transition to business objects (subsitemaps)
b) All the common resources: images (*.gif, *.png), *.css, *.js (client).
c) Handle errors.

In the main sitemap you will not find any flow script at all.

2-"Business Object": They contains all the forms needed to manage the
particular object inside the webapp. Each Businnes Objects have the same
structure. Also they have the same sitemap. That way we don't need to
create a new sitemap every time we start one Business Object. You can also
have other forms (for example "list" not showed in the below sample). Here
is the structure of each business object:

ModuleName
+--- forms
|   +--- create
|   |   +--- bind.xml
|   |   +--- definition.xml
|   |   +--- flow.js
|   |   +--- template.xml
|   +--- search
|   +--- remove
|   +--- update
+---sitemap.xmap

Every business object has his own BOH (Business Object Handler) written in
Java. The BOH is used inside the flow. The BOH contains all the functions
needed to manipulate beans used in the forms of the Business Object. The
BOH must contains the CRUD operations related to the object.

All BOHs are almost similars thanks to OJB-JDO.

The underlying part of the O/R mapping is done using Druid (hey?! here is
again Druid!).

Here is some flow script:

**********************************************************************
Create:
**********************************************************************
function createform(form) {
    form.showForm("create-form-display");

    var factory = cocoon.getComponent(Packages.o.a.c....JdoPMF.ROLE);
    var bean = new Packages.test.forms.area.Bean();
    var handler = new Packages.test.forms.area.Handler();

    form.save(bean);
    handler.insert(bean, factory);
    cocoon.releaseComponent(factory);
    success("Areas", "Area procesada con éxito",
"¿Desea procesar una nueva área?","create");
}

**********************************************************************
Search:
**********************************************************************

function searchform(form) {
    form.showForm("search-form-display");
    cocoon.sendPage("list",
       {"criteria" : form.getWidget("criteria").getValue()});
}

**********************************************************************
List:
**********************************************************************
function listform(form) {
    var factory = cocoon.getComponent(Packages.o.a.c.....JdoPMF.ROLE);
    var bean = new Packages.test.forms.area.List();
    var handler = new Packages.test.forms.Handler();
    var criteria = new String (cocoon.request.criteria);

    handler.getList(bean, criteria, factory);

    form.load(bean);
    form.showForm("list-form-display");
    var nuevoBean = new Packages.test.forms.area.List();
    form.save(bean);
    handler.setList(bean, criteria, factory);
    cocoon.releaseComponent(factory);
    success("Administración de Areas", "Actualización de Áreas",
       "Todos los cambios se procesaron existosamente. ¿Desea volver a
procesar la lista de áreas?", "search");
}


The sitemap looks:

<map:flow language="javascript">
  <map:script src="forms/create/flow.js"/>
  <map:script src="forms/search/flow.js"/>
  <map:script src="forms/list/flow.js"/>
</map:flow>

<map:pipelines>
  <!-- Woody forms display -->
  <map:pipeline internal-only="true">
    <map:match pattern="*-form-display">
      <map:generate src="forms/{1}/template.xml"/>
      <map:transform type="woody"/>
      <map:transform type="i18n"/>
      <map:transform src="context://stylesheets/agssa.xslt"/>
      <map:transform src="context://resources/woody/woody-styling.xsl"/>
      <map:transform type="encodeURL"/>
      <map:serialize/>
    </map:match>
    <!-- jx forms -->
    <map:match pattern="ver-form">
      <map:generate type="jx" src="forms/ver.xml"/>
      <map:serialize/>
    </map:match>
  </map:pipeline>

  <!-- Manejo de las continuaciones -->
  <map:pipeline>
    <map:match pattern="*.continue">
      <map:call continuation="{1}"/>
    </map:match>

   <!-- Crea el flow -->
   <map:match pattern="*">
     <map:call function="woody">
       <map:parameter name="function" value="{1}form"/>
       <map:parameter name="form-definition"
          value="forms/{1}/definition.xml"/>
       <map:parameter name="bindingURI" value="forms/{1}/bind.xml"/>
       <map:parameter name="attribute-name" value="{1}form"/>
     </map:call>
   </map:match>
 </map:pipeline>
</map:pipelines>

We are still developing this idea. The "Business Objects" modules and the
best generic structure for them in any webapp.

If we found it, then we will try to develop a tool for building database
oriented webapp using Cocoon. We tought the start must be the form
definition. Based on the form definition the tool will generate the
database script, the woody forms, the java classes, the O/R mapping etc.
It would be very nice, is it? Here again, I see druid as an important part
of the overall tool helping us in the database arena.

We are now developing 2 webapp at the same time and we are trying to
follow some technics that will help us in the automatization of the code.
Under this approach we don't see to the sitemap as the most dynamic part
of the application. Or maybe?

As I told you I am lazy enough to write the same code over and over just
changing some names. :-D

Comments are welcome.

Best Regards,

Antonio Gallardo.

Re: Makes flow script the sitemap ugly?

[Sylvain Wallez <sy...@apache.org>]

Joerg Heinicke wrote:

> On 11.11.2003 15:48, Geoff Howard wrote:
>
>> In fact, I think that flow in some cases needlessly complicates the 
>> composition of a pipeline.  Now I have to have two pipelines where I 
>> used to need one.  I have to have one that matches the external 
>> request and calls the flow function, and another one for the default 
>> result of that pipeline.
>
>
> I have exactly the same feeling about the flow. I talked about exactly 
> the same with Sylvain in private communication (btw: Did you ignore my 
> last email or didn't you receive it, Sylvain. I sent it on the day you 
> had problems with Anywhere mail to your Apache account - which is 
> probably forwarded to Anywhere :-( ).


I received it, but was so swamped with work and mail problems that I 
failed to answer...

> In German slang I would call the flow "drangepappt". How can this be 
> translated into English: The flow is not integrated into the sitemap 
> very well and makes the sitemap flow somewhat opaque or obfusicated. 
> How must look into the flow to understand what's going on in the 
> sitemap. And if it is so why not integrating the flow script into the 
> sitemap directly? No, I don't want to have Javascript in the sitemap, 
> it's only a bad feeling about that. Especially because of the two-side 
> dependency from sitemap to flow to sitemap.
>
>> So far this has felt like needless additional complexity to me (and I 
>> think will to others).
>>
>> To try to make this point a little clearer:
>> Part of the beauty of the sitemap prior to flow was that you could at 
>> a glance see what each request url was triggering.  Now, I look at 
>> the sitemap, have to locate the flowscript, parse through it for the 
>> various sendPage etc. and then back to the sitemap to find where the 
>> action really happens.  This could perhaps be handled with some best 
>> practice naming conventions.  Perhaps a practice of passing in the 
>> various possible view uris to the flowscript should be considered.  I 
>> don't know.
>
>
> Naming conventions is to weak to handle this IMHO.


Exactly. My personal way of doing things is very close to Antonio's: 
here's a typical sitemap of my flow+woody applications:

<map:pipelines>
  <!-- internal URIs -->
  <map:pipeline internal-only="true">
    <map:match pattern="_view-*.html">
      ....
    </map:match>
  </map:pipeline>

  <!-- public URIs -->
  <map:pipeline>
    <map:match pattern="edit-*.html">
      <map:select type="request-method">
        <map:otherwise>
           <map:call function="public_{1}"/>
        </map:otherwise>
        <map:when test="POST">
          <map:call continuation="{request-param:continuation-id}"/>
        </map:when>
      </map:select>
    </map:match>
     .... other matchers...
  </map:pipeline>
</map:pipelines>

Several noticeable things:
- internal pipeline is placed first. It makes things faster, as it's 
checked first for internal request, and ignored for external ones
- "_" prefix for internal URIs avoids most name clashes with external URIs.
- prefixing externally-callable flow functions with the "public_" prefix 
(or something else) prevents hackers to call non public flow functions
- Distinguishing call/continue with the request method allows to have 
<form action="">. This is convenient when writing form templates and 
keeps the browser location bar clean (the address doesn't change)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com