You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@gmx.net> on 2002/06/11 15:46:58 UTC
XMLForms and Flowmap
Currently the "logic" of XMLForms is handled by the action. I read a few
weeks ago that there are plans to use the flowmap for it.
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102071048209644&w=2)
Is anybody working on an implemenation? What's the current status?
Regards,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Torsten Curdt <tc...@dff.st>.
On Sunday 16 June 2002 22:08, Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
> > Ivelin Ivanov wrote:
> >>Reinhard,
> >>
> >>We are looking for someone to step up and show us how these two can work
> >>together in a nice way.
> >>
> >>Interested?
> >
> > I am.
> >
> > IMNSHO, the flowmap should totally replace actions and deprecate them.
>
> Ahem, I thought we decided *not* to deprecate them, as they make sense
> as elements in the declarative sitemap.
>
> For web apps Actions should be *strongly* discouraged, but can have uses
> in sitemap-only publishing sites.
+10!!
We may discourage them for flow reasons - but as long as you want things to
happen outside the webapp context (where you usually don't need / want the
overhead of continuations) we should keep them!!
There are lots of examples for such....
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Stefano Mazzocchi wrote:
> Ivelin Ivanov wrote:
>
>
>>How about binding http request parameters to objects?
>>myobject.setName( cocoon.request.getParameter( "name" ) );
>>for each parameter for each form is not pretty code.
>
>
> Please, just keep one thing in mind: we have the ability to extend the
> FOM (flowmap object model) with *anything* we want.
>
> Want to perform automatic binding between your bean and the user
> request? we might simply do
>
> flowmap.populate(myobject,cocoon.request);
Something like that.
Although there are a few more things which are specific about input
handling.
1) Handling checkbox widgets. They can't be automatically populated when
no checked.
2) Branching the flow in accordance with the user selection.
3) Branching based on validation result
I've posted another email with 5 requirements a flow map demo should
satisfy, before it can be considered for real web apps, not just cool
personal sites with 10 visitors.
>
> and that is it.
>
> And I'm just scratching the surface of this concept!
>
> Food for thought.
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
> How about binding http request parameters to objects?
> myobject.setName( cocoon.request.getParameter( "name" ) );
> for each parameter for each form is not pretty code.
Please, just keep one thing in mind: we have the ability to extend the
FOM (flowmap object model) with *anything* we want.
Want to perform automatic binding between your bean and the user
request? we might simply do
flowmap.populate(myobject,cocoon.request);
and that is it.
And I'm just scratching the surface of this concept!
Food for thought.
--
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: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Stefano Mazzocchi wrote:
> Ivelin Ivanov wrote:
>
>>Reinhard,
>>
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
>>
>>Interested?
>
>
> I am.
>
> IMNSHO, the flowmap should totally replace actions and deprecate them.
>
> I've looked at XMLForms and I must say it looks extremely unfriendly to
> my eyes. The reason? massive use of actions, which hide the flow logic
> from the sitemap.
>
> In the example I've seen, you use the same URI, passing the
> cocoon-action parameter to trigger a different state.
>
> I'm not against the concept, not at all, but I think that actions are
> evil, bad, harder to use than it first seems and not RAD at all.
>
> What I love about Ovidiu's work is the ability to use it even without
> continuations: you are not forced to use continuations to store your
> state and you can simply write your flow logic in javascript and run it,
> instead of using actions, compile them, include them and so on.
>
> So, I don't think they should work together at all: form validation
> should be a cocoon component that you simply call from your flow logic.
How about binding http request parameters to objects?
myobject.setName( cocoon.request.getParameter( "name" ) );
for each parameter for each form is not pretty code.
>
> Does it make sense?
>
Not quite yet. I'll keep following the discussion.
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Thanks for your thouts.
I would like to see an example at least as complex as the XMLForm demo
before I can comment.
The example needs to
1) Be able to handle most UI widgets, including checkboxes
2) Allow 2 way navigation
3) Make decisions about the next page based on:
a) validity of the input
b) user selection in the current page
4) Show how data in a page can be pulled from a db source, only if it is
needed.
5) Show how input data can be wrapped in a transaction which will write
the data to a db and will also trigger other steps that need to be part
of the same transaction, so that either everything succeeds or nothing.
These 5 steps are what people writing Web Apps have to deal with all the
time. Having data processing in the action, allows use of standard J2EE
APIs, like JTA, JDBC, etc. which have proven solid. It also allows clean
interaction with the business layer through strongly typed objects,
allows easy debugging and performance profiling.
These three benefits are vital for a web app which has the potential to
scale in size and usage.
Cheers,
Ivelin
Stefano Mazzocchi wrote:
> Ivelin Ivanov wrote:
>
>>Reinhard,
>>
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
>>
>>Interested?
>
>
> I am.
>
> IMNSHO, the flowmap should totally replace actions and deprecate them.
>
> I've looked at XMLForms and I must say it looks extremely unfriendly to
> my eyes. The reason? massive use of actions, which hide the flow logic
> from the sitemap.
>
> In the example I've seen, you use the same URI, passing the
> cocoon-action parameter to trigger a different state.
>
> I'm not against the concept, not at all, but I think that actions are
> evil, bad, harder to use than it first seems and not RAD at all.
>
> What I love about Ovidiu's work is the ability to use it even without
> continuations: you are not forced to use continuations to store your
> state and you can simply write your flow logic in javascript and run it,
> instead of using actions, compile them, include them and so on.
>
> So, I don't think they should work together at all: form validation
> should be a cocoon component that you simply call from your flow logic.
>
> Does it make sense?
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Nicola Ken Barozzi wrote:
>
> Per-Olof Norén wrote:
>
>> Ivelin Ivanov wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>> IMNSHO, the flowmap should totally replace actions and deprecate them.
>>>>
>>>>
>>>> Ahem, I thought we decided *not* to deprecate them, as they make
>>>> sense as elements in the declarative sitemap.
>>>>
>>>> For web apps Actions should be *strongly* discouraged, but can have
>>>> uses in sitemap-only publishing sites.
>>>
>>>
>>>
>>> I agree that Actions are not as natural to Cocoon sitemap as
>>> Generator, Transformers and Serializers are. What is the right
>>> replacement for them which will glue front end with the business
>>> logic layer.
>>> Are you saying that the flowmap will call Java code directly?
>>> Would you need to write gluing JavaScript even for simple one page
>>> input handling?
>>
>>
>>
>> My interpretation would be that if that input handling is needed it
>> should be done in the flowmap.
>
>
> I agree.
>
>> If there is a need for an action, one should use flow.
>
>
> Actions are not only for input handling.
>
>> Personally I tend to hesitate to write an action and if a actually do
>> it i tend to "overwork" it, costing lots of unneccecary hours to the
>> project at hand. Therefore i agree with Stefano on his quest for an
>> action-free cocoon, given that it is expanded from its current form of
>> course :)
>
>
> :-)
>
> If I want to log every request to my custom system, I could make an
> action that does it and it would be simple.
> Do I have to write a one-line flowmap for it?
> Dunno, maybe it could be ok, maybe not...
>
> ...I think that this decision (of deprecating Actions) will have to be
> taken when the flow is really working well; ATM we don't have enough
> elements to discuss it correctly.
While the flow script is a cool thing, no one is going to code
everything in java script. Especially not complex things. Database
operations are an example.
So, put them into an avalon component. Great. But doing all the look up
manually in javascript is tiresome. Uh, could we come up with a
simplification? But then we would need a common interface for it, yes,
that's it!
But wait - we do have that already! It's called "Action". Just that we
currently can't use it in flow script.
Wouldn't it be cool if we could use an action in the sitemap as well as
in a flow script? There are currently about 50 actions available in C2.
Wouldn't that boost flow script?
Just my 2¢
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Stefano Mazzocchi <st...@apache.org>.
"Andrew C. Oliver" wrote:
>
> I've taken my first crack at this and its undergoing review before I
> post it. I dislike both actions and the flowmap. More
> specifically principally depending on Javascript.
Uh, thanks. I'm sure we'll be able to come up with a much better design
with such great constructive criticism.
--
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: XMLForms and Flowmap
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I've taken my first crack at this and its undergoing review before I
post it. I dislike both actions and the flowmap. More
specifically principally depending on Javascript.
-Andy
Christian Haul wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Per-Olof Norén wrote:
>>
>>> Ivelin Ivanov wrote:
>>>
>>>> Nicola Ken Barozzi wrote:
>>>>
>>>>>> IMNSHO, the flowmap should totally replace actions and deprecate
>>>>>> them.
>>>>>
>>>>>
>>>>>
>>>>> Ahem, I thought we decided *not* to deprecate them, as they make
>>>>> sense as elements in the declarative sitemap.
>>>>>
>>>>> For web apps Actions should be *strongly* discouraged, but can
>>>>> have uses in sitemap-only publishing sites.
>>>>
>>>>
>>>>
>>>>
>>>> I agree that Actions are not as natural to Cocoon sitemap as
>>>> Generator, Transformers and Serializers are. What is the right
>>>> replacement for them which will glue front end with the business
>>>> logic layer.
>>>> Are you saying that the flowmap will call Java code directly?
>>>> Would you need to write gluing JavaScript even for simple one page
>>>> input handling?
>>>
>>>
>>>
>>>
>>> My interpretation would be that if that input handling is needed it
>>> should be done in the flowmap.
>>
>>
>>
>> I agree.
>>
>>> If there is a need for an action, one should use flow.
>>
>>
>>
>> Actions are not only for input handling.
>>
>>> Personally I tend to hesitate to write an action and if a actually
>>> do it i tend to "overwork" it, costing lots of unneccecary hours to
>>> the project at hand. Therefore i agree with Stefano on his quest for
>>> an action-free cocoon, given that it is expanded from its current
>>> form of course :)
>>
>>
>>
>> :-)
>>
>> If I want to log every request to my custom system, I could make an
>> action that does it and it would be simple.
>> Do I have to write a one-line flowmap for it?
>> Dunno, maybe it could be ok, maybe not...
>>
>> ...I think that this decision (of deprecating Actions) will have to
>> be taken when the flow is really working well; ATM we don't have
>> enough elements to discuss it correctly.
>
>
> While the flow script is a cool thing, no one is going to code
> everything in java script. Especially not complex things. Database
> operations are an example.
>
> So, put them into an avalon component. Great. But doing all the look
> up manually in javascript is tiresome. Uh, could we come up with a
> simplification? But then we would need a common interface for it, yes,
> that's it!
>
> But wait - we do have that already! It's called "Action". Just that we
> currently can't use it in flow script.
>
> Wouldn't it be cool if we could use an action in the sitemap as well
> as in a flow script? There are currently about 50 actions available in
> C2.
> Wouldn't that boost flow script?
>
> Just my 2¢
>
> Chris.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
Nicola Ken Barozzi wrote:
>
> Per-Olof Norén wrote:
>
>> Ivelin Ivanov wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>> IMNSHO, the flowmap should totally replace actions and deprecate them.
>>>>
>>>>
>>>> Ahem, I thought we decided *not* to deprecate them, as they make
>>>> sense as elements in the declarative sitemap.
>>>>
>>>> For web apps Actions should be *strongly* discouraged, but can have
>>>> uses in sitemap-only publishing sites.
>>>
>>>
>>>
>>> I agree that Actions are not as natural to Cocoon sitemap as
>>> Generator, Transformers and Serializers are. What is the right
>>> replacement for them which will glue front end with the business
>>> logic layer.
>>> Are you saying that the flowmap will call Java code directly?
>>> Would you need to write gluing JavaScript even for simple one page
>>> input handling?
>>
>>
>>
>> My interpretation would be that if that input handling is needed it
>> should be done in the flowmap.
>
>
> I agree.
>
>> If there is a need for an action, one should use flow.
>
>
> Actions are not only for input handling.
>
>> Personally I tend to hesitate to write an action and if a actually do
>> it i tend to "overwork" it, costing lots of unneccecary hours to the
>> project at hand. Therefore i agree with Stefano on his quest for an
>> action-free cocoon, given that it is expanded from its current form of
>> course :)
>
>
> :-)
>
> If I want to log every request to my custom system, I could make an
> action that does it and it would be simple.
> Do I have to write a one-line flowmap for it?
> Dunno, maybe it could be ok, maybe not...
>
> ...I think that this decision (of deprecating Actions) will have to be
> taken when the flow is really working well; ATM we don't have enough
> elements to discuss it correctly.
While the flow script is a cool thing, no one is going to code
everything in java script. Especially not complex things. Database
operations are an example.
So, put them into an avalon component. Great. But doing all the look up
manually in javascript is tiresome. Uh, could we come up with a
simplification? But then we would need a common interface for it, yes,
that's it!
But wait - we do have that already! It's called "Action". Just that we
currently can't use it in flow script.
Wouldn't it be cool if we could use an action in the sitemap as well as
in a flow script? There are currently about 50 actions available in C2.
Wouldn't that boost flow script?
Just my 2¢
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Per-Olof Norén wrote:
> Ivelin Ivanov wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>>> IMNSHO, the flowmap should totally replace actions and deprecate them.
>>>
>>> Ahem, I thought we decided *not* to deprecate them, as they make
>>> sense as elements in the declarative sitemap.
>>>
>>> For web apps Actions should be *strongly* discouraged, but can have
>>> uses in sitemap-only publishing sites.
>>
>>
>> I agree that Actions are not as natural to Cocoon sitemap as
>> Generator, Transformers and Serializers are. What is the right
>> replacement for them which will glue front end with the business logic
>> layer.
>> Are you saying that the flowmap will call Java code directly?
>> Would you need to write gluing JavaScript even for simple one page
>> input handling?
>
>
> My interpretation would be that if that input handling is needed it
> should be done in the flowmap.
I agree.
> If there is a need for an action, one
> should use flow.
Actions are not only for input handling.
> Personally I tend to hesitate to write an action and if
> a actually do it i tend to "overwork" it, costing lots of unneccecary
> hours to the project at hand. Therefore i agree with Stefano on his
> quest for an action-free cocoon, given that it is expanded from its
> current form of course :)
:-)
If I want to log every request to my custom system, I could make an
action that does it and it would be simple.
Do I have to write a one-line flowmap for it?
Dunno, maybe it could be ok, maybe not...
...I think that this decision (of deprecating Actions) will have to be
taken when the flow is really working well; ATM we don't have enough
elements to discuss it correctly.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XMLForms and Flowmap
Posted by Reinhard Poetz <re...@gmx.net>.
> Ivelin Ivanov wrote:
> > I agree that Actions are not as natural to Cocoon sitemap as Generator,
> > Transformers and Serializers are. What is the right replacement
> for them
> > which will glue front end with the business logic layer.
> > Are you saying that the flowmap will call Java code directly?
> > Would you need to write gluing JavaScript even for simple one
> page input
> > handling?
> Per-Olof Norén wrote:
> My interpretation would be that if that input handling is needed it
> should be done in the flowmap. If there is a need for an action, one
> should use flow. Personally I tend to hesitate to write an action and if
> a actually do it i tend to "overwork" it, costing lots of unneccecary
> hours to the project at hand. Therefore i agree with Stefano on his
> quest for an action-free cocoon, given that it is expanded from its
> current form of course :)
I think there a few good reasons implementing web applications on the basis
of
the flowmap (I don't know if they will/should replace actions - maybe in the
long
run)
1) Higher visibility
If you want to know what an action does you have to look into
the source code. That's not a problem for java programmers but
I think for many developers who love the framework but don't want
to touch java code ...
2) Faster development cycles
You don't need to restart cocoon because of a change in an action.
3) Separation of java code and business logic
You can put your business logic completly in flowmaps. This means that
you can separate the cocoon installation from that you want to do
with it.
4) Continuations
--> good documentation of the flowmap will be absolutly necessary
1) How to implement the connection between the functionality provided by
cocoon and javascript-functions
2) How to write your flows
3) Performance guide
- Are there any impacts on the performance because of the flow layer?
- Are there dos and donts?
4) If there is still a need for actions in the future we should explain
the advantages and disadvantages of actions and flows
Regards,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Per-Olof Norén <pe...@alma.nu>.
Ivelin Ivanov wrote:
> Nicola Ken Barozzi wrote:
>
>>> IMNSHO, the flowmap should totally replace actions and deprecate them.
>>
>>
>>
>> Ahem, I thought we decided *not* to deprecate them, as they make sense
>> as elements in the declarative sitemap.
>>
>> For web apps Actions should be *strongly* discouraged, but can have
>> uses in sitemap-only publishing sites.
>
>
> I agree that Actions are not as natural to Cocoon sitemap as Generator,
> Transformers and Serializers are. What is the right replacement for them
> which will glue front end with the business logic layer.
> Are you saying that the flowmap will call Java code directly?
> Would you need to write gluing JavaScript even for simple one page input
> handling?
My interpretation would be that if that input handling is needed it
should be done in the flowmap. If there is a need for an action, one
should use flow. Personally I tend to hesitate to write an action and if
a actually do it i tend to "overwork" it, costing lots of unneccecary
hours to the project at hand. Therefore i agree with Stefano on his
quest for an action-free cocoon, given that it is expanded from its
current form of course :)
whats bothering me:
I´ve tried to instantiate a simple home-brewn bean-like object in the
flowmap and passing it to the xsp with values from the flowlayer.
However, this seems to fail, with jxpath throwing exceptions not giving
any leads to what might be the trouble. Skimming through Javadoc spec i
found a way to import arbitrary objects in javascript, and this seems to
work fine. Its when trying to access a "object from an object" such as a
getting hashtable entry from a class holding a reference to the
hastable. It works fine "one level" down reference hierarchies.
I´ll post this into bugzilla, just don´t have time to do it today though.
/Per-Olof
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Ivelin Ivanov wrote:
> Andrew C. Oliver wrote:
>
>>
>
> The spirit of this group has been that every contributor's opinion
> matters.
>
> One of the reasons I got hooked and am spending so much time on the
> list...
>
>
Don't mind me I'm just having a bad week. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Andrew C. Oliver wrote:
> I'm under the gun at work (P1 issues all over the place) so I haven't
> had time to respond. I'm not sure
> I like the flowmap approach, in particular I feel the javascript could
> quickly become a nightmere in
> living applications. I'll study this more closely in the days to come
> and give feedback (not that my
> opinion is that relevant).
The spirit of this group has been that every contributor's opinion matters.
One of the reasons I got hooked and am spending so much time on the list...
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I'm under the gun at work (P1 issues all over the place) so I haven't
had time to respond. I'm not sure
I like the flowmap approach, in particular I feel the javascript could
quickly become a nightmere in
living applications. I'll study this more closely in the days to come
and give feedback (not that my
opinion is that relevant).
-andy
Stefano Mazzocchi wrote:
>Ivelin Ivanov wrote:
>
>
>>Nicola Ken Barozzi wrote:
>>
>>
>>
>>>>IMNSHO, the flowmap should totally replace actions and deprecate them.
>>>>
>>>>
>>>Ahem, I thought we decided *not* to deprecate them, as they make sense
>>>as elements in the declarative sitemap.
>>>
>>>For web apps Actions should be *strongly* discouraged, but can have uses
>>> in sitemap-only publishing sites.
>>>
>>>
>>I agree that Actions are not as natural to Cocoon sitemap as Generator,
>>Transformers and Serializers are. What is the right replacement for them
>>which will glue front end with the business logic layer.
>>Are you saying that the flowmap will call Java code directly?
>>
>>
>
>Absolutely. I still have to find out the limitations of this, but being
>Rhyno a javascript engine written in java, it would be pretty easy to
>see the mapping between the two.
>
>
>
>>Would you need to write gluing JavaScript even for simple one page input
>>handling?
>>
>>
>
>No. Nothing forces you thru this path. But I would personally suggest it
>instead of using actions.
>
>Anyway, as I said, we won't deprecate existing functionality until
>everybody is perfectly positive about it, so do not be worried about we
>changing the ground beneath your feet :)
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Stefano Mazzocchi wrote:
>
> Anyway, as I said, we won't deprecate existing functionality until
> everybody is perfectly positive about it, so do not be worried about we
> changing the ground beneath your feet :)
>
This is comforting to hear ;->
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
>
> Nicola Ken Barozzi wrote:
>
> >> IMNSHO, the flowmap should totally replace actions and deprecate them.
> >
> >
> > Ahem, I thought we decided *not* to deprecate them, as they make sense
> > as elements in the declarative sitemap.
> >
> > For web apps Actions should be *strongly* discouraged, but can have uses
> > in sitemap-only publishing sites.
>
> I agree that Actions are not as natural to Cocoon sitemap as Generator,
> Transformers and Serializers are. What is the right replacement for them
> which will glue front end with the business logic layer.
> Are you saying that the flowmap will call Java code directly?
Absolutely. I still have to find out the limitations of this, but being
Rhyno a javascript engine written in java, it would be pretty easy to
see the mapping between the two.
> Would you need to write gluing JavaScript even for simple one page input
> handling?
No. Nothing forces you thru this path. But I would personally suggest it
instead of using actions.
Anyway, as I said, we won't deprecate existing functionality until
everybody is perfectly positive about it, so do not be worried about we
changing the ground beneath your feet :)
--
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: XMLForms and Flowmap
Posted by giacomo <gi...@apache.org>.
On Sun, 16 Jun 2002, Ivelin Ivanov wrote:
> Nicola Ken Barozzi wrote:
>
> >> IMNSHO, the flowmap should totally replace actions and deprecate them.
> >
> >
> > Ahem, I thought we decided *not* to deprecate them, as they make sense
> > as elements in the declarative sitemap.
> >
> > For web apps Actions should be *strongly* discouraged, but can have uses
> > in sitemap-only publishing sites.
>
> I agree that Actions are not as natural to Cocoon sitemap as Generator,
> Transformers and Serializers are. What is the right replacement for them
> which will glue front end with the business logic layer.
> Are you saying that the flowmap will call Java code directly?
Exactly.
> Would you need to write gluing JavaScript even for simple one page input
> handling?
You can write it as JavaScript directly if it is "simple one page input
handling", right?
But as Stefano said a few times, Actions are not going to be deprecated
before everybody agrees and sees that the flowmap is the better place
for it.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Nicola Ken Barozzi wrote:
>> IMNSHO, the flowmap should totally replace actions and deprecate them.
>
>
> Ahem, I thought we decided *not* to deprecate them, as they make sense
> as elements in the declarative sitemap.
>
> For web apps Actions should be *strongly* discouraged, but can have uses
> in sitemap-only publishing sites.
I agree that Actions are not as natural to Cocoon sitemap as Generator,
Transformers and Serializers are. What is the right replacement for them
which will glue front end with the business logic layer.
Are you saying that the flowmap will call Java code directly?
Would you need to write gluing JavaScript even for simple one page input
handling?
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Ivelin Ivanov wrote:
>
>>Reinhard,
>>
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
>>
>>Interested?
>
>
> I am.
>
> IMNSHO, the flowmap should totally replace actions and deprecate them.
Ahem, I thought we decided *not* to deprecate them, as they make sense
as elements in the declarative sitemap.
For web apps Actions should be *strongly* discouraged, but can have uses
in sitemap-only publishing sites.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
>
> Reinhard,
>
> We are looking for someone to step up and show us how these two can work
> together in a nice way.
>
> Interested?
I am.
IMNSHO, the flowmap should totally replace actions and deprecate them.
I've looked at XMLForms and I must say it looks extremely unfriendly to
my eyes. The reason? massive use of actions, which hide the flow logic
from the sitemap.
In the example I've seen, you use the same URI, passing the
cocoon-action parameter to trigger a different state.
I'm not against the concept, not at all, but I think that actions are
evil, bad, harder to use than it first seems and not RAD at all.
What I love about Ovidiu's work is the ability to use it even without
continuations: you are not forced to use continuations to store your
state and you can simply write your flow logic in javascript and run it,
instead of using actions, compile them, include them and so on.
So, I don't think they should work together at all: form validation
should be a cocoon component that you simply call from your flow logic.
Does it make sense?
--
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: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Reinhard Poetz wrote:
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
>>
>>Interested?
>>
>>
>>Ivelin
>
>
> Yes I am but my time and my java knowledge are limited (... but I'm
> learning)
So you have the itch. That's all it takes ;-]
>
> Anyway, I'll try it. Maybe there is somebody who has already some experience
> (Daniel?) who want's to join.
>
> Reinhard
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: XMLForms and Flowmap
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerström wrote:
[skip lots of great stuff]
> I strongly sugests that we should _not_ make general use of
> continuations available in the flowmap language as there is no need for
> it for what flowmaps are intended to do: describing multipage flow in
> webapps.
Daniel,
thanks for your great feedback.
Now that Ovidiu came up with a reasonable first step implementation of
the flowmap concept (no intention to reduce his incredible work, just a
statement reflecting the fact that this has been, so far, a single
person effort and I want it to run community design over again on his
great ideas and code), I'm going to challenge it.
I'm preparing an RT as soon as I finish reading the thousands of emails
I have left from this week of zurich consulting :)
Ciao
--
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: XMLForms and Flowmap
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/13/02 7:49 AM, "Daniel Fagerström" <da...@nada.kth.se> wrote:
> Diana Shannon wrote:
>
>>
>> On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
>>
>>> Feel free to ask if you need further clarification about my integration
>>> proposal.
>>
>>
>> What *I'm* most interested in is a statement you made a while ago on
>> this list about the difficulties students can have learning about
>> continuations, from your direct experience teaching continuations.
>
>
> Why are continuations difficult?
> --------------------------------
>
> Continuations are a little bit like "goto on steroids". They are used in
> the study of denotional semantics which is a subarea of theoretical
> computer science. The aim of denotional semantics, is to describe (and
> prove properties of) programming constructs in terms of a very small
> functional language, (lambda calculus) that includes continuations.
> Continuations are extremely powerfull; program language constructs like
> assignement, goto, while, for-loops, throw-catch and coroutines to name
> a few can be defined in terms of a terse and cryptic, (but elegant, if
> you happen to like mathematical puzzles ;) functional program.
>
> Some functional program langages, Scheme e.g. have continuations. A good
> use for continuations in such languages is to use them together with
> macros to define new language constructions. You can also use them for
> building a more intelectually demanding form of spagetti code ;)
>
> Why can continuation based code be difficult to grasp? Even if most of
> us might not remember it anymore, learning to understand and use even
> the simplest programming language construct required a considerable
> effort once, allowing ad hoc introduction of new constructs forces us to
> repeat this effort often. Continuations forces us to think about the
> whole state of the program rather than about state changes.
> Continuations introduces non-local effects in the code, non-local
> effects are the main reason why gotos and exception handling can be hard
> to follow.
>
> Flowmaps and continuations
> --------------------------
>
> In Flowmaps, continuations are used for implementing something quite
> similar to coroutines.
>
>> Do you have any suggestions for the doc effort in this regard?
>
>
> Focus on the coroutine aspect of the flowmaps, it is fairly easy to
> understand, while general use of continuations just isn't. For the
> flowmap user, the fact that flowmaps are implemented in terms of
> continuations should be of very limited importance otherwise we have a
> severe mix of concerns in the design.
>
> I strongly sugests that we should _not_ make general use of
> continuations available in the flowmap language as there is no need for
> it for what flowmaps are intended to do: describing multipage flow in
> webapps.
I definitely agree here. The last thing we want to do is describe
continuations as the complex concepts from denotational semantics, or their
usage patterns in Scheme.
>> In what
>> aspects do students have problems: understanding the concept, applying
>> them to real-world situations, etc.? I've read up on continuations,
>> generally, but so many existing docs are tied to Scheme implementations
>> (which could frighten users, as has also been discussed). Can you point
>> to any existing teaching resources that you use? Care to donate anything
>> of your own, even a teaching outline? Any tips?
>
>
> I tought denotatinal semantics, and the literature in that area is even
> more frightening than the Scheme literature;)
>
> IMO we would make the effort to use flowmaps to high if we require
> people to learn continuations. I belive that it should be enough to
> teach about the coroutine like control structure, that happen to be
> implemented in terms of continuations. If it's not possible I think that
> is important feedback on that we have to work more on the basic concepts
> in the flowmap. I have a long unfinished RT where I compare FSM:s with
> the basics concepts in the Flowmap proposal and develop the coroutine
> analog a bit further. I'll check if it is in a comprehensible state and,
> if so, I'll send it to you.
>
> I would also like to remind about some mails I wrote a couple of months
> ago where I explain why it's IMO is FS or even harmfull to allow local
> variables in the flowmap language: see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101861458122598&w=2 and
> some other mails in the "continuation fear" thread.
I need to write down the ideas which are specific to the usage of
continuations in Cocoon's implementation. I've described most of these in
various threads in the past, but I didn't manage to put them together in a
single document.
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Daniel Fagerström <da...@nada.kth.se>.
Diana Shannon wrote:
>
> On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
>
>> Feel free to ask if you need further clarification about my integration
>> proposal.
>
>
> What *I'm* most interested in is a statement you made a while ago on
> this list about the difficulties students can have learning about
> continuations, from your direct experience teaching continuations.
Why are continuations difficult?
--------------------------------
Continuations are a little bit like "goto on steroids". They are used in
the study of denotional semantics which is a subarea of theoretical
computer science. The aim of denotional semantics, is to describe (and
prove properties of) programming constructs in terms of a very small
functional language, (lambda calculus) that includes continuations.
Continuations are extremely powerfull; program language constructs like
assignement, goto, while, for-loops, throw-catch and coroutines to name
a few can be defined in terms of a terse and cryptic, (but elegant, if
you happen to like mathematical puzzles ;) functional program.
Some functional program langages, Scheme e.g. have continuations. A good
use for continuations in such languages is to use them together with
macros to define new language constructions. You can also use them for
building a more intelectually demanding form of spagetti code ;)
Why can continuation based code be difficult to grasp? Even if most of
us might not remember it anymore, learning to understand and use even
the simplest programming language construct required a considerable
effort once, allowing ad hoc introduction of new constructs forces us to
repeat this effort often. Continuations forces us to think about the
whole state of the program rather than about state changes.
Continuations introduces non-local effects in the code, non-local
effects are the main reason why gotos and exception handling can be hard
to follow.
Flowmaps and continuations
--------------------------
In Flowmaps, continuations are used for implementing something quite
similar to coroutines.
> Do you have any suggestions for the doc effort in this regard?
Focus on the coroutine aspect of the flowmaps, it is fairly easy to
understand, while general use of continuations just isn't. For the
flowmap user, the fact that flowmaps are implemented in terms of
continuations should be of very limited importance otherwise we have a
severe mix of concerns in the design.
I strongly sugests that we should _not_ make general use of
continuations available in the flowmap language as there is no need for
it for what flowmaps are intended to do: describing multipage flow in
webapps.
> In what
> aspects do students have problems: understanding the concept, applying
> them to real-world situations, etc.? I've read up on continuations,
> generally, but so many existing docs are tied to Scheme implementations
> (which could frighten users, as has also been discussed). Can you point
> to any existing teaching resources that you use? Care to donate anything
> of your own, even a teaching outline? Any tips?
I tought denotatinal semantics, and the literature in that area is even
more frightening than the Scheme literature;)
IMO we would make the effort to use flowmaps to high if we require
people to learn continuations. I belive that it should be enough to
teach about the coroutine like control structure, that happen to be
implemented in terms of continuations. If it's not possible I think that
is important feedback on that we have to work more on the basic concepts
in the flowmap. I have a long unfinished RT where I compare FSM:s with
the basics concepts in the Flowmap proposal and develop the coroutine
analog a bit further. I'll check if it is in a comprehensible state and,
if so, I'll send it to you.
I would also like to remind about some mails I wrote a couple of months
ago where I explain why it's IMO is FS or even harmfull to allow local
variables in the flowmap language: see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101861458122598&w=2 and
some other mails in the "continuation fear" thread.
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/13/02 4:57 AM, "Diana Shannon" <sh...@apache.org> wrote:
>
> On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
>
>> Feel free to ask if you need further clarification about my integration
>> proposal.
>
> What *I'm* most interested in is a statement you made a while ago on
> this list about the difficulties students can have learning about
> continuations, from your direct experience teaching continuations. Do
> you have any suggestions for the doc effort in this regard? In what
> aspects do students have problems: understanding the concept, applying
> them to real-world situations, etc.? I've read up on continuations,
> generally, but so many existing docs are tied to Scheme implementations
> (which could frighten users, as has also been discussed). Can you point
> to any existing teaching resources that you use? Care to donate anything
> of your own, even a teaching outline? Any tips?
>
> Look how much attention XMLForm has already received, simply as a result
> of the XMLForm Wizard How-To being published to release and live site,
> announced, etc. ... If anyone feels their work/component is languishing
> in HEAD, please reconsider what a focused, user-friendly How-To can do
> for it. If you need help writing, contact me. Perhaps we can set up team
> writing efforts.
Thanks Diana for bringing up the documentation aspect of it. I'm still
trying to find time to continue working on it, I've been doing all sorts of
things lately.
Daniel, I'd love it very much if you could contribute some documentation on
continuations and their usage. Please let us know if you have something
already written or if you could write something on the subject.
Best regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, June 12, 2002, at 06:31 PM, Daniel Fagerstrom wrote:
> Feel free to ask if you need further clarification about my integration
> proposal.
What *I'm* most interested in is a statement you made a while ago on
this list about the difficulties students can have learning about
continuations, from your direct experience teaching continuations. Do
you have any suggestions for the doc effort in this regard? In what
aspects do students have problems: understanding the concept, applying
them to real-world situations, etc.? I've read up on continuations,
generally, but so many existing docs are tied to Scheme implementations
(which could frighten users, as has also been discussed). Can you point
to any existing teaching resources that you use? Care to donate anything
of your own, even a teaching outline? Any tips?
Look how much attention XMLForm has already received, simply as a result
of the XMLForm Wizard How-To being published to release and live site,
announced, etc. ... If anyone feels their work/component is languishing
in HEAD, please reconsider what a focused, user-friendly How-To can do
for it. If you need help writing, contact me. Perhaps we can set up team
writing efforts.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XMLForms and Flowmap
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Reinhard Poetz wrote:
> > We are looking for someone to step up and show us how these two can work
> > together in a nice way.
> >
> > Interested?
> >
> >
> > Ivelin
>
> Yes I am but my time and my java knowledge are limited (... but I'm
> learning)
>
> Anyway, I'll try it. Maybe there is somebody who has already some
> experience
> (Daniel?) who want's to join.
I'm afraid I won't have enough time to spare to do any programming, but I
will be happy to try to answer any questions that you might have.
I believe that the integration scheme that I proposed in:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2
should be fairly straight forward to implement and that it could be done
without any need to modify XMLForms or the Flowmap or even any Java
programming, it is probably enough with flowmap and sitemap writing. As I
haven't tried to implement it, and could of course missed some important
issues.
Feel free to ask if you need further clarification about my integration
proposal.
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XMLForms and Flowmap
Posted by Reinhard Poetz <re...@gmx.net>.
> We are looking for someone to step up and show us how these two can work
> together in a nice way.
>
> Interested?
>
>
> Ivelin
Yes I am but my time and my java knowledge are limited (... but I'm
learning)
Anyway, I'll try it. Maybe there is somebody who has already some experience
(Daniel?) who want's to join.
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XMLForms and Flowmap
Posted by Ivelin Ivanov <iv...@apache.org>.
Reinhard,
We are looking for someone to step up and show us how these two can work
together in a nice way.
Interested?
Ivelin
Reinhard Poetz wrote:
> Currently the "logic" of XMLForms is handled by the action. I read a few
> weeks ago that there are plans to use the flowmap for it.
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102071048209644&w=2)
>
> Is anybody working on an implemenation? What's the current status?
>
> Regards,
> Reinhard
>
>
> ---------------------------------------------------------------------
> 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
Re: XMLForms and Flowmap
Posted by Ovidiu Predescu <ov...@cup.hp.com>.
Hi Reinhard,
On 6/11/02 6:46 AM, "Reinhard Poetz" <re...@gmx.net> wrote:
> Currently the "logic" of XMLForms is handled by the action. I read a few
> weeks ago that there are plans to use the flowmap for it.
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102071048209644&w=2)
>
> Is anybody working on an implemenation? What's the current status?
I am currently doing other things, I didn't have much time to play with the
samples. I've got some new ideas on how to make the flow layer even more
powerful, by allowing multiple functions to be called in the same context.
This will improve the usability tremendously, as you can have multiple
functions as entry points, all sharing the same global variables space.
The current code also has a bug, as global variables are shared across all
client invocations, which is really dangerous. What should happen is that
the value of the global variables should be visible to only one client, and
each client should have its own global variable space. An application global
space should then be added, for values which are shared across the
application. I have a solution to this problem, I started to work on it, but
is not yet finished.
--
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org