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/16 03:36:34 UTC
Re: XMLForm & Control of flow
Ivelin,
I'm following up on the dev group as not to scare users off.
>
> The HowtoWizardAction has an identical role as a Struts action.
> It makes the decision, which is the following *logical* page to go to.
> Notice that the *sitemap* converts the logical name to a *URL*!
*so* ?
>
> Actions are appropriate for evaluating the current form content,
> applying business rules and making decision what is the next logical
> page to go to. Actions *do not* deal with absolute *URL*s and they
> *only* aware and interested in pages which immediately follow as a
> result of the Action processing.
I disagree. Thats one solution. I'm going to look at doing other
things for the bringmethis auction example. I don't like the use of
actions here. Most of my actions are trivial classes, and the complex
ones I'm convinced can be handled via the sitemap.
>
> In real world application decisions for the outcome of form submit can
> be quite complex, requiring the Action to consult with the business
> layer and possibly the database and other resources.
I disagree. In most real world applications, the decisions for handling
the outcome of a form submit is simple. What you do with that output is
complex. But using the Action to route to pages is not only "page"
centric (which I find inappropriate) but creates a larger compile test
debug loop and is very akward. Finding a sitemap approach is much
cleaner.
-Andy.
>
>
>>>> 2. When I repeated the steps and unchecked the boxes. Then when I
>>>> arrive at
>>>> confirm input everthing is still true. Do I have to invalidate the
>>>> session
>>>> or something? Shouldn't that happen the moment you push finish?
>>>
>
> This should not happen. Possibly a bug.
> Can you reproduce the problem from the time you open a new browser
> window and send me the steps.
>
>
> Ivelin
>
>
>
>>>>
>>>> Thanks,
>>>>
>>>> Edgar
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: <co...@xml.apache.org>
>>>> For additional commands, e-mail: <co...@xml.apache.org>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: <co...@xml.apache.org>
>>> For additional commands, e-mail: <co...@xml.apache.org>
>>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForm & Control of flow
Posted by "Andrew C. Oliver" <ac...@apache.org>.
That'd be nice; howver, the description I've gotten of flowmap do not
excite me or seem to achive the objective I've outlined.
That being said there are no docs really on flowmap, and I'm kinda
dull--so not my bag man. Admittedly, my understanding of it is
incomplete and probably will be for months to come until some
documentation appears. I will create a "hello xmlform" example shortly
though to provide a more basic minimalist example (actually its done, I
just need to put it in to patch form and write some text for it).
Personally, I'm more interested in a comprehensive example of how to
use Cocoon in a web app than any one feature (not a details kinda guy).
Once I've finished it (by the end of the month) I'll create the patches
and begin begging committers to apply it. After which its my hope
others will join to refactor it to be more of a best practices example
for the areas it covers without making it petshop-like in trying to
cover everything even if inappropriate.
-Andy
PS objective is: Handle page selection via sitemap (not javascript)
Ivelin Ivanov wrote:
>
> I'd be very interested to see the XMLForm feedback wizard demo
> re-written to use the sitemap (flowmap) for navigation.
> The reason why I insist on another version of the demo instead of a
> new application is that it was specificly designed to cover many
> subtle problems with HTML form handling and workflow.
> Another implementation will also allow direct comparison between two
> flow techniques.
>
>
>
>
> Andrew C. Oliver wrote:
>
>> Ivelin,
>>
>> I'm following up on the dev group as not to scare users off.
>>
>>>
>>> The HowtoWizardAction has an identical role as a Struts action.
>>> It makes the decision, which is the following *logical* page to go to.
>>> Notice that the *sitemap* converts the logical name to a *URL*!
>>
>>
>>
>>
>> *so* ?
>>
>>>
>>> Actions are appropriate for evaluating the current form content,
>>> applying business rules and making decision what is the next logical
>>> page to go to. Actions *do not* deal with absolute *URL*s and they
>>> *only* aware and interested in pages which immediately follow as a
>>> result of the Action processing.
>>
>>
>>
>> I disagree. Thats one solution. I'm going to look at doing other
>> things for the bringmethis auction example. I don't like the use of
>> actions here. Most of my actions are trivial classes, and the
>> complex ones I'm convinced can be handled via the sitemap.
>>
>>>
>>> In real world application decisions for the outcome of form submit
>>> can be quite complex, requiring the Action to consult with the
>>> business layer and possibly the database and other resources.
>>
>>
>>
>> I disagree. In most real world applications, the decisions for
>> handling the outcome of a form submit is simple. What you do with
>> that output is complex. But using the Action to route to pages is
>> not only "page" centric (which I find inappropriate) but creates a
>> larger compile test debug loop and is very akward. Finding a sitemap
>> approach is much cleaner. -Andy.
>>
>>>
>>>
>>>>>> 2. When I repeated the steps and unchecked the boxes. Then when I
>>>>>> arrive at
>>>>>> confirm input everthing is still true. Do I have to invalidate
>>>>>> the session
>>>>>> or something? Shouldn't that happen the moment you push finish?
>>>>>
>>>>>
>>>>>
>>>
>>> This should not happen. Possibly a bug.
>>> Can you reproduce the problem from the time you open a new browser
>>> window and send me the steps.
>>>
>>>
>>> Ivelin
>>>
>>>
>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Edgar
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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:
>>>>>> <co...@xml.apache.org>
>>>>>> For additional commands, e-mail:
>>>>>> <co...@xml.apache.org>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: <co...@xml.apache.org>
>>>>> For additional commands, e-mail: <co...@xml.apache.org>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForm & Control of flow
Posted by Ivelin Ivanov <iv...@apache.org>.
I'd be very interested to see the XMLForm feedback wizard demo
re-written to use the sitemap (flowmap) for navigation.
The reason why I insist on another version of the demo instead of a new
application is that it was specificly designed to cover many subtle
problems with HTML form handling and workflow.
Another implementation will also allow direct comparison between two
flow techniques.
Andrew C. Oliver wrote:
> Ivelin,
>
> I'm following up on the dev group as not to scare users off.
>
>>
>> The HowtoWizardAction has an identical role as a Struts action.
>> It makes the decision, which is the following *logical* page to go to.
>> Notice that the *sitemap* converts the logical name to a *URL*!
>
>
>
> *so* ?
>
>>
>> Actions are appropriate for evaluating the current form content,
>> applying business rules and making decision what is the next logical
>> page to go to. Actions *do not* deal with absolute *URL*s and they
>> *only* aware and interested in pages which immediately follow as a
>> result of the Action processing.
>
>
> I disagree. Thats one solution. I'm going to look at doing other
> things for the bringmethis auction example. I don't like the use of
> actions here. Most of my actions are trivial classes, and the complex
> ones I'm convinced can be handled via the sitemap.
>
>>
>> In real world application decisions for the outcome of form submit can
>> be quite complex, requiring the Action to consult with the business
>> layer and possibly the database and other resources.
>
>
> I disagree. In most real world applications, the decisions for handling
> the outcome of a form submit is simple. What you do with that output is
> complex. But using the Action to route to pages is not only "page"
> centric (which I find inappropriate) but creates a larger compile test
> debug loop and is very akward. Finding a sitemap approach is much
> cleaner.
> -Andy.
>
>>
>>
>>>>> 2. When I repeated the steps and unchecked the boxes. Then when I
>>>>> arrive at
>>>>> confirm input everthing is still true. Do I have to invalidate the
>>>>> session
>>>>> or something? Shouldn't that happen the moment you push finish?
>>>>
>>>>
>>
>> This should not happen. Possibly a bug.
>> Can you reproduce the problem from the time you open a new browser
>> window and send me the steps.
>>
>>
>> Ivelin
>>
>>
>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Edgar
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: <co...@xml.apache.org>
>>>>> For additional commands, e-mail: <co...@xml.apache.org>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: <co...@xml.apache.org>
>>>> For additional commands, e-mail: <co...@xml.apache.org>
>>>>
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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