You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2002/06/13 16:02:14 UTC

Actions and XMLForm

Hi,

I've been working on XMLForm stuff and overall it's nice.  just.....

Actions....I don't really like them.  They smell.  Okay, actually I 
think they might have their place if say
your form handling was really really really complex, but thats not the 
90% case.  (yes I realize they are
part of cocoon and not xmlform)

Is there some way of handling this in the sitemap?  Say

<actionmap name="SampleAction">
   <form name="myform">
        <command name="next">
         ...do stuff (like redirecting to the mapping for a page of the 
form or something)
         </command>
         <command name="cancel">
               ....
         </command>
    </form>
</actionmap>

Furthermore, most beans that I'll be creating are *STUPID*..  Meaning, 
they're something that a C struct would
perfectly satisfy.  In such an event is there a way to just define the 
set of fields:

<formbean name="Customer">
  <field name="firstname" type="string"/>
  <field name="lastname" type="string"/>
  <field name="irateflag" type="boolean"/>
</formbean>

While I'm not sure this should be in say the sitemap, it seems like I 
should be able to define my datatypes in XML
somewhere.  

Advantages:

1. Shortens the change/compile/test cycle and increases developer 
productivity
2. Saves typing getters and setters
3. Don't Repeat Yourself, if I'm going to create 100 practically 
identical classes, then one must ask, why am I
    creating them at all.
4. Smells like cocoon.  (where Actions and the beans smell like struts)

Disadvantages

1. Might require serialization before passing to java code.

Mitigations

1. Pass a DOM tree or something.

While I'm just betting someone already thought of this, in the event 
they didn't I am happy to contribute, though I lack
the in-depth knowledge of cocoon innards to provide it by my lonesome.

-Andy


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Actions and XMLForm

Posted by Stefano Mazzocchi <st...@apache.org>.
"Andrew C. Oliver" wrote:
> 
> Hi,
> 
> I've been working on XMLForm stuff and overall it's nice.  just.....
> 
> Actions....I don't really like them.  They smell.  

Bingo!

> Okay, actually I
> think they might have their place if say
> your form handling was really really really complex, but thats not the
> 90% case.  (yes I realize they are
> part of cocoon and not xmlform)

Bingo squared!
 
> Is there some way of handling this in the sitemap?

Yes, dude, there is, it's called flowmap: you write your flow logic in
javascript code and call it from the sitemap.

Please, checkout HEAD and look into /webapp/samples/flow/

WARNING: the current syntax and functionality is to be considered alpha
and we can't guarantee you that it will change substantially in the
future.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Actions and XMLForm

Posted by Ivelin Ivanov <iv...@apache.org>.

Andrew,

You may want to try to combine XMLForm with the flowmap.
Daniel can be your guide, because he seems to understand how to balance 
both things.

I am looking forward to an implementation of the Feedback Wizard, which
delegates the flow control to the flowmap.


Ivelin


Andrew C. Oliver wrote:
> Hi,
> 
> I've been working on XMLForm stuff and overall it's nice.  just.....
> 
> Actions....I don't really like them.  They smell.  Okay, actually I 
> think they might have their place if say
> your form handling was really really really complex, but thats not the 
> 90% case.  (yes I realize they are
> part of cocoon and not xmlform)
> 
> Is there some way of handling this in the sitemap?  Say
> 
> <actionmap name="SampleAction">
>   <form name="myform">
>        <command name="next">
>         ...do stuff (like redirecting to the mapping for a page of the 
> form or something)
>         </command>
>         <command name="cancel">
>               ....
>         </command>
>    </form>
> </actionmap>
> 
> Furthermore, most beans that I'll be creating are *STUPID*..  Meaning, 
> they're something that a C struct would
> perfectly satisfy.  In such an event is there a way to just define the 
> set of fields:
> 
> <formbean name="Customer">
>  <field name="firstname" type="string"/>
>  <field name="lastname" type="string"/>
>  <field name="irateflag" type="boolean"/>
> </formbean>
> 
> While I'm not sure this should be in say the sitemap, it seems like I 
> should be able to define my datatypes in XML
> somewhere. 
> Advantages:
> 
> 1. Shortens the change/compile/test cycle and increases developer 
> productivity
> 2. Saves typing getters and setters
> 3. Don't Repeat Yourself, if I'm going to create 100 practically 
> identical classes, then one must ask, why am I
>    creating them at all.
> 4. Smells like cocoon.  (where Actions and the beans smell like struts)
> 
> Disadvantages
> 
> 1. Might require serialization before passing to java code.
> 
> Mitigations
> 
> 1. Pass a DOM tree or something.
> 
> While I'm just betting someone already thought of this, in the event 
> they didn't I am happy to contribute, though I lack
> the in-depth knowledge of cocoon innards to provide it by my lonesome.
> 
> -Andy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



-- 

-= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org