Piroumian Konstantin wrote:
>>From: Yromem.com MailingList [mailto:[EMAIL PROTECTED]]
>>
>>I was thinking about a default javabeans, with N parameter :
>> 1. where to go when the form is validated ?
>> 2. what is the validator file ?
>> 3. other ?
>
>
> I suspect that you have a little wrong understanding of XMLForms.
>
> The XMLForm were intended to implement the Model - View - Controller
> pattern, where:
>
> Model - is your Instance data that holds the form data (JavaBean or
> DOM object) (See http://www.w3c.org/ - XForms).
>
> View - an XML description of the form that is transformed by the
> XMLFormTransformer, filled by the instance date, then transformed into
> desired format by XSLT
>
> Controller - currently, the role of the controller performs the
> sitemap, but you can use some other (maybe the flowmap) approach to control
> the sequence of actions, states, etc. - flow - of your application.
Minor note. The controller would ideally be the sitemap or the flow
engine. However in many practical situations, control and flow is
handled by java code accessible in an Action. This is how Struts
applications work.
>
> So,
>
>
>> 1. where to go when the form is validated ?
>
>
> This task is solved by the flow controller (whatever you choose). No
> JavaBean is used here.
In the HOWTO and Feedback Wizard examples, the Action makes a decision
for the next page, then the sitemap maps it to an URL.
>
>> 2. what is the validator file ?
>
>
> This one is setup in the sitemap. You specify a file with validation rules
> as a parameter for validating action/transformer.
Correct. Validation component is abstract. Schematron implementation is
currently provided. Validating schema namespace and file are specified
as parameters to the Action.
Thanks for the MVC tour, Konstantin.
Ivelin
>
>
>> 3. other ?
>
>
> Nothing else.
>
> Shortly:
>
> - Model
> {JavaBean | DOM }
>
> - View
> {XML | XSP} -> {XMLFormTransformer [ i18nTransformer | ...]}
> -> [XSLT]
>
> - Controller
> Sitemap | Sitemap + Flow | Sitemap + your approach
>
> Though, I must admit that things could have changed since we've discussed
> the implementation details for XMLForm. I have to take a fresh look at it.
>
> Konstantin
>
> P.S. Sylvain, this explanation can be an answer to your first point: How
> does Cocoon implement Struts' features.
>
>
>>
>>
>>Piroumian Konstantin wrote:
>>
>>
>>>>From: Yromem.com MailingList [mailto:[EMAIL PROTECTED]]
>>>>
>>>>Hi,
>>>>
>>>>do you plan to write a simple way to use XMLForm when we need
>>>>only one
>>>>Form :
>>>> with no need to write a javabean (or javacode)
>>>>I trie to understand all the XMLForm, but it is difficult
>>>
>>to me. (the
>>
>>>>java part)
>>>>
>>>>
>>>
>>>If you don't need a JavaBean, how would you get the data to
>>
>>fill in your
>>
>>>form with defaults and retain the entered data in case of
>>
>>errors on submit?
>>
>>>The number of forms is not relevant - everything's the same
>>
>>in processing,
>>
>>>except the redirect to the next form instead of the success
>>
>>page in case of
>>
>>>a one form/page.
>>>
>>>Anyway, you'll need either a JavaBean or a DOM object to
>>
>>store your data. If
>>
>>>none of this suit your needs then you'll need only a
>>
>>stylesheet that renders
>>
>>>your XMLForm into desired format and perform all the form
>>
>>processing in an
>>
>>>action by hand.
>>>
>>>But I wonder, where will you get data to fill your form with?
>>>
>>>--
>>>Konstantin Piroumian
>>>[EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>>
>>>>Khalid.
>>>>
>>>>
>>>>Ivelin Ivanov wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>UserBean.java:
>>>>> private Node system;
>>>>>
>>>>>This an attribute which is of type org.w3c.dom.Node
>>>>>
>>>>>This is used in the FeedBack Wiazard demo to show how
>>>>>
>>>>>
>>>>
>>>>JavaBeans can be
>>>>
>>>>
>>>>
>>>>>mixed with dom nodes. It is referenced on the page where
>>>>
>>you select
>>
>>>>>Operating System, RAM, App server, etc.
>>>>>
>>>>>If you're not going to need DOM nodes in your Form model, you can
>>>>>ignore this attribute. Just delete it.
>>>>>
>>>>>I am not sure why it is in the HowTo though. Don't think it is
>>>>>necessary. Heidi?
>>>>>
>>>>>
>>>>>Ivelin
>>>>>
>>>>>
>>>>>
>>>>
>>>>------------------------------------------------------------
>>>
>>---------
>>
>>>>Please check that your question has not already been
>>>
>>answered in the
>>
>>>>FAQ before posting.
>>>
>><http://xml.apache.org/cocoon/faq/index.html>
>>
>>>>To
>>>
>>unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>
>>>>For additional commands, e-mail:
>>>
>><[EMAIL PROTECTED]>
>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>Please check that your question has not already been answered in the
>>>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>>>
>>>To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>>For additional commands, e-mail: <[EMAIL PROTECTED]>
>>>
>>>
>>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>Please check that your question has not already been answered in the
>>FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>>
>>To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
--
-= Ivelin =-
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
