Re: [Proposal] Implementing XMLForm with Flow
I'm reposting this, since I posted it just before Christmas and I'm afraid it was overlooked. Christopher Oliver wrote: Yes, you can use Function.apply() to pass a variable argument list to another function, like this: Great! It works perfectly. Now I can use the Flow to protect all the map:call's without checking the user's credentials in every single function, BUT ... ... I still have XSP pages (views) that are invoked by the Flow via sendPage, and those of course have pipelines in the sitemap, so one could invoke them by directly invoking their URL, bypassing the Flow. This is BAD (TM) as it forces me to put further checks in my views. I've tried making the pipelines "internal-only", but doing so makes them invisible also to the Flow, even though sendPage uses the cocoon: protocol. It would be better, IMHO, if sendPage (and sendPageAndWait) could invoke internal-only pipelines. Is there any particular reason why it isn't so? Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Christopher Oliver wrote: Yes, you can use Function.apply() to pass a variable argument list to another function, like this: Great! It works perfectly. Now I can use the Flow to protect all the map:call's without checking the user's credentials in every single function, BUT ... ... I still have XSP pages (views) that are invoked by the Flow via sendPage, and those of course have pipelines in the sitemap, so one could invoke them by directly invoking their URL, bypassing the Flow. This is BAD (TM) as it forces me to put further checks in my views. I've tried making the pipelines "internal-only", but doing so makes them invisible also to the Flow, even though sendPage uses the cocoon: protocol. It would be better, IMHO, if sendPage (and sendPageAndWait) could invoke internal-only pipelines. Is there any particular reason why it isn't so? Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ugo Cei wrote:
Christopher Oliver wrote:
Try this:
function checkLogin(funarg) {
if (user == null) {
login();
this[funarg]();
}
}
Thanks, it worked! While you're at it, would it be possible to pass
arguments to "funarg", by defining them in the sitemap? I mean:
function checkLogin(funarg, ???) {
if (user == null) {
login();
this[funarg](???);
}
}
What should I put in place of the question marks? Assume that the
number of arguments is variable. Pardon my Javascript ignorance and
thanks again ;-).
Ugo
Yes, you can use Function.apply() to pass a variable argument list to
another function, like this:
function checkLogin(funArg) {
if (user == null) {
login();
}
// In JavaScript, the magic variable "arguments" contains the
actual list of arguments passed to a function.
// Arguments supports a "length" property, and array indexing.
var newArgs = new Array(arguments.length-1);
for (var i = 1; i < arguments.length; i++) {
newArgs[i-1] = arguments[i];
}
var fun = this[funArg];
fun.apply(this, newArgs);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Christopher Oliver wrote:
Try this:
function checkLogin(funarg) {
if (user == null) {
login();
this[funarg]();
}
}
Thanks, it worked! While you're at it, would it be possible to pass
arguments to "funarg", by defining them in the sitemap? I mean:
function checkLogin(funarg, ???) {
if (user == null) {
login();
this[funarg](???);
}
}
What should I put in place of the question marks? Assume that the number
of arguments is variable. Pardon my Javascript ignorance and thanks
again ;-).
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Hi Ugo,
Ugo Cei wrote:
function checkLogin(funarg)
{
if (user == null)
login();
funarg();
}
This doesn't seem to work. It always generates an error message like
"org.mozilla.javascript.EvaluatorException: checkout is not a function."
But if I invoke the same function directly from the sitemap, without
passing its name as an argument, it works.
What's happening here?
Ugo
Try this:
function checkLogin(funarg) {
if (user == null) {
login();
this[funarg]();
}
}
funarg is just the string "checkout", to get to the checkout() function
you need to dereference the global scope object (this). In JavaScript,
using the [] operator with a string argument behaves the same as using
the dot operator. However, the dot operator requires a literal
identifier. If you want to use a variable (as in this case) then you
must use the [] operator.
Regards,
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ovidiu Predescu wrote:
Not really. You can automate this task by arranging in your sitemap to
call a function that checks the login first, instead of your function.
The following will do it:
Sitemap:
Flow:
var user;
function login()
{
// send the necessary pages for the user
// to login. Assigns to the global 'user' variable
// the User object, which is later used throughout
// the script to identify the user. See the prefs.js
// sample in Cocoon for an example of such a function.
}
function checkLogin(funarg)
{
if (user == null)
login();
funarg();
}
This doesn't seem to work. It always generates an error message like
"org.mozilla.javascript.EvaluatorException: checkout is not a function."
But if I invoke the same function directly from the sitemap, without
passing its name as an argument, it works.
What's happening here?
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Konstantin Piroumian wrote: Yes, this should work. But I'd prefer to avoid passing the function name as parameter. What about this version: Which is a security nightmare, since you are allowing any logged-in user to execute ANY function in your flowscript. Or an alternate version with nested matchers: Much better IMHO. Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
> On Monday, Dec 9, 2002, at 05:21 US/Pacific, Konstantin Piroumian wrote:
>
> > In case of the flow script you should place login() function call in
> > every
> > function that needs authorized access, while for the state machine
> > approach
> > you could create a superstate - AuthorizedState - for all the
> > sub-states
> > that needs authenticated user.
>
> Not really. You can automate this task by arranging in your sitemap to
> call a function that checks the login first, instead of your function.
> The following will do it:
>
> Sitemap:
>
>
>
>
>
>
Yes, this should work. But I'd prefer to avoid passing the function name as
parameter. What about this version:
Or an alternate version with nested matchers:
etc.
Will the above work as I expect? (Each 'private/**' request is checked for
authorization and then the processing continues with one of the nested
matchers). This one looks like the state machine approach with nested
states.
>
> Flow:
>
> var user;
>
> function login()
> {
>// send the necessary pages for the user
>// to login. Assigns to the global 'user' variable
>// the User object, which is later used throughout
>// the script to identify the user. See the prefs.js
>// sample in Cocoon for an example of such a function.
> }
>
> function checkLogin(funarg)
> {
>if (user == null)
> login();
>funarg();
> }
>
> The sitemap calls checkLogin() and passes as argument the function to
> be called when the user has already logged in. The login() function
> will ask the user to login, and will return only when the user
> successfully does so. At that moment the original function to be
> invoked is called.
>
> > In the project I'd been working, we'd been generating our state machine
> > descriptions directly from a UML modeling tool (it was XMI format),
> > then it
> > were processed by an XSLT to our (simpler) format. (The source code
> > was not
> > related to Cocoon neither it was open source, unfortunately)
>
> Having to use a tool is exactly what I'm trying to avoid. I'm finding
> myself in the constant situation of running on an unsupported platform
> for most of such tools. Writing simple scripts beats any time a verbose
> XML document.
Yes that's true for most of the cases. But in the situation when you are
required to create UML diagrams for all the system, it's much easier to
generate XML from them and even actions and selectors sceletons. When there
is a bunch of developers of different expertise level, this approach works
just fine: most of the developers should not be aware of the sitemap,
JavaScript or so, they just have to implement the actions that interact with
the business logic layer.
But again, that depends on your tasks, on your team. For the XMLForm wizards
scenario I'd prefer a state-machine approach, for something else, probably,
I'd choose the flow-script.
Regards,
Konstantin
>
> Best regards,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://webweavertech.com/ovidiu/weblog/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
On Monday, Dec 9, 2002, at 05:21 US/Pacific, Konstantin Piroumian wrote:
In case of the flow script you should place login() function call in
every
function that needs authorized access, while for the state machine
approach
you could create a superstate - AuthorizedState - for all the
sub-states
that needs authenticated user.
Not really. You can automate this task by arranging in your sitemap to
call a function that checks the login first, instead of your function.
The following will do it:
Sitemap:
Flow:
var user;
function login()
{
// send the necessary pages for the user
// to login. Assigns to the global 'user' variable
// the User object, which is later used throughout
// the script to identify the user. See the prefs.js
// sample in Cocoon for an example of such a function.
}
function checkLogin(funarg)
{
if (user == null)
login();
funarg();
}
The sitemap calls checkLogin() and passes as argument the function to
be called when the user has already logged in. The login() function
will ask the user to login, and will return only when the user
successfully does so. At that moment the original function to be
invoked is called.
In the project I'd been working, we'd been generating our state machine
descriptions directly from a UML modeling tool (it was XMI format),
then it
were processed by an XSLT to our (simpler) format. (The source code
was not
related to Cocoon neither it was open source, unfortunately)
Having to use a tool is exactly what I'm trying to avoid. I'm finding
myself in the constant situation of running on an unsupported platform
for most of such tools. Writing simple scripts beats any time a verbose
XML document.
Best regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Hi! (Sorry for late jump in) From: "Ivelin Ivanov" <[EMAIL PROTECTED]> > > This is actually a good example. > > For fairness sake, I haven't seen many J2EE applications which forward to > login from different spots though. > J2EE containers usually take care of login and return to original URL. According to Servlet specification, in case of the container managed authentification, you can be forwarded to login from any URL that is constrained in web.xml. After succesful login you are redirected to the page you've originally requested. More comments below: > From: "Christopher Oliver" <[EMAIL PROTECTED]> > > > > > >Until now, it has shown to me a simple way to program simple > applications. > > > > > > > > > > > Well, actually I think the more complex the control flow the more the > > flow layer will really shine. Consider the login example, where you > > could need to login at any point during the application. With the flow > > layer you simply write a function login(), and call it from any place > > during your application. After completion of the login sequence, you are > > automatically returned to the calling page. Something like this > > (although still a simple example) is extremely difficult to implement > > with state-machine code. Other complex control flow constructs > > (conditional branching, loops, etc) are straightforward with the flow > > layer but virtually impossible to comprehend with state-machine like code. Recently, I've been dealing with a lot of state-machine based logic and I must admit that although understanding state-machines is not a simple task (including sub-states, shallow and deep histories, actions, events, etc.), but it's not a very difficult task to construct complex flows with state machines. In case of the flow script you should place login() function call in every function that needs authorized access, while for the state machine approach you could create a superstate - AuthorizedState - for all the sub-states that needs authenticated user. In the project I'd been working, we'd been generating our state machine descriptions directly from a UML modeling tool (it was XMI format), then it were processed by an XSLT to our (simpler) format. (The source code was not related to Cocoon neither it was open source, unfortunately) Just my Regards, Konstantin > > > > Regards, > > > > Chris > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote: - Original Message - From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> Only one thing: why it's great to have somebody playing devil's advocate and somebody else excited about something new, let's not forget that we *all* are working in the same team and for the same direction. I am trying my best to emphasize in my messages that this is not about emotions. See my previous email: "Again, I would love to see a better alternative to the traditional events model. However let's leave emotions aside and compare objectively." As I said, I was not talking about you personally there. [again, Ivelin, this is not personal to you, just that you happen to inspire me a lot these days... ah, btw, you still didn't trim your posts!!!] Well, I tried!!! If you look again at all my email following your comment about trimming, you will notice that most of them do not contain the full original. http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103937208527264&w=2 down at the bottom. -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
This is actually a good example. For fairness sake, I haven't seen many J2EE applications which forward to login from different spots though. J2EE containers usually take care of login and return to original URL. Ivelin - Original Message - From: "Christopher Oliver" <[EMAIL PROTECTED]> > > > > > >Until now, it has shown to me a simple way to program simple applications. > > > > > > > Well, actually I think the more complex the control flow the more the > flow layer will really shine. Consider the login example, where you > could need to login at any point during the application. With the flow > layer you simply write a function login(), and call it from any place > during your application. After completion of the login sequence, you are > automatically returned to the calling page. Something like this > (although still a simple example) is extremely difficult to implement > with state-machine code. Other complex control flow constructs > (conditional branching, loops, etc) are straightforward with the flow > layer but virtually impossible to comprehend with state-machine like code. > > Regards, > > Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
- Original Message - From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > Only one thing: why it's great to have somebody playing devil's advocate > and somebody else excited about something new, let's not forget that we > *all* are working in the same team and for the same direction. I am trying my best to emphasize in my messages that this is not about emotions. See my previous email: "Again, I would love to see a better alternative to the traditional events model. However let's leave emotions aside and compare objectively." > [again, Ivelin, this is not personal to you, just that you happen to > inspire me a lot these days... ah, btw, you still didn't trim your posts!!!] Well, I tried!!! If you look again at all my email following your comment about trimming, you will notice that most of them do not contain the full original. Regards, Ivelin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Hi Ivelin, Ivelin Ivanov wrote: I have nothing new to add, but would like to balance the discussion with a reminder: - Original Message - From: "Ovidiu Predescu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 07, 2002 10:52 PM Subject: Re: [Proposal] Implementing XMLForm with Flow Which shows exactly why continuations provide such a simple way of programming complex applications! Until now, it has shown to me a simple way to program simple applications. Well, actually I think the more complex the control flow the more the flow layer will really shine. Consider the login example, where you could need to login at any point during the application. With the flow layer you simply write a function login(), and call it from any place during your application. After completion of the login sequence, you are automatically returned to the calling page. Something like this (although still a simple example) is extremely difficult to implement with state-machine code. Other complex control flow constructs (conditional branching, loops, etc) are straightforward with the flow layer but virtually impossible to comprehend with state-machine like code. Regards, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Uh, how useful is it to insist that something be fully implemented to prove a point in a discussion on a mailing list? The purpose of my example was to show that the flow layer allows you to avoid the state-machine code required in XMLForm actions (which is what you questioned in your original message), not to implement all of the details of your example. If your only objection (now) is that you don't think it can be implemented then I believe Ugo has already offered to demonstrate that that is not the case. In any case, I don't think our perspectives are really that different. You are afraid of JavaScript spagetti code. That is a legitimate concern in my opinion as well. However, spagetti code can occur in any language (including Java), so that should also be a concern in XMLForm actions. You are concerned about the overhead of continuations. That is also a concern to me (and to Ovidiu and he has been profiling the flow layer to track this). I'm also a little surprised you don't seem to want a flow layer based interface to XMLForm. Personally, I think it could enhance the usability and value of that component (by replacing the action handling code - with the flow layer - but retaining the rest of its current functionality). Regards, Chris Ivelin Ivanov wrote: - Original Message - From: "Ovidiu Predescu" <[EMAIL PROTECTED]> Check out Christopher's implementation using the control flow: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103923083624699&w=2 Good attempt, although unfinished. I already described its shortcomings. Bottom line, it doesn't implement the same functionality. Ivelin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote: - Original Message - From: "Ovidiu Predescu" <[EMAIL PROTECTED]> Check out Christopher's implementation using the control flow: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103923083624699&w=2 Good attempt, although unfinished. I already described its shortcomings. Bottom line, it doesn't implement the same functionality. Only one thing: why it's great to have somebody playing devil's advocate and somebody else excited about something new, let's not forget that we *all* are working in the same team and for the same direction. This community has been so far wonderful to reject the notion of code and idea ownership because everybody here understands how valuable is the notion of 'being proven wrong so that you can learn something new'. But this requires openmindness and respect for others, which are sometimes hard to find in talented people. Also, consider that everybody is different: what can be easy for you, might not be easy for your neightbour and viceversa. So, when I say "I hate actions", that doesn't mean "then you should hate them too". Also, when I say "I love the concept of flowscript", maybe I'll change my mind after I wrote 1000 lines of flowscript! (that's how I got to hate actions, BTW, having to write a 1000-lines long and 7-nested layers deep sitemap for my webapp due to action complexity!) So, bottom line: it's great to compete, but *only* if there is respect and openmindness. I will do whatever it takes to make sure that technical competition doesn't ignite personal friction on this list. I sincerely hope that all of you follow me on this path and leave code/idea onwnership feelings aside in order to have a much greater time and being able to learn even more from this experience. Thank you [again, Ivelin, this is not personal to you, just that you happen to inspire me a lot these days... ah, btw, you still didn't trim your posts!!!] -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
- Original Message - From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > > Check out Christopher's implementation using the control flow: > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103923083624699&w=2 Good attempt, although unfinished. I already described its shortcomings. Bottom line, it doesn't implement the same functionality. Ivelin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
I have nothing new to add, but would like to balance the discussion
with a reminder:
- Original Message -
From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 07, 2002 10:52 PM
Subject: Re: [Proposal] Implementing XMLForm with Flow
> Brilliant example Chris, I love it!!
>
> This shows exactly what can be built with continuations and
> tail-recursive functions.
>
...
> > state-machine code as in XMLForm actions. Compare the flow version to
> > the original XMLForm action code reproduced below, and judge for
> > yourself.
> >
> > // display form, wait for submission, and
> > // apply validations; repeat until no violations
> > function sendView(form, view, uri) {
> >form.clearViolations();
> >if (uri == undefined) {
> >uri = view + ".xml";
> >}
> >sendPageAndWait(uri, {id: view});
> >form.populate(cocoon.request);
> >if (form.violations != null) {
> >sendView(form, view, uri);
> >}
> > }
>
> The recursive call to sendView here is what is called a tail-recursive
> call. This type of calls are optimized by Christopher's modified engine
> to avoid eating stack space, a common technique in functional
> languages. They behave as a simple goto to the beginning of the
> function.
Tail recursion is as old as 20 years. Most functional language
implementations use it.
The example above though is equivalent to the following java(Action) code:
if getForm().getViolations () != null )
{
return page( getFormView() );
}
Clearing violations and population are provided by the abstract action
unless explicitly overriden.
Read on.
>
> > function createForm() {
> >// create the Form object
> >// ...
> > }
> >
> > function howToWizard() {
> >// different form views
> >// participating in the wizard
> >var VIEW_START = "start";
> >var VIEW_REGISTRATION = "registration";
> >var VIEW_INTEREST = "interest";
> >var VIEW_GARDENING = "organicGardening";
> >var VIEW_COOKING = "cooking";
> >var VIEW_SMALLHOLDING = "smallholdingManagement";
> >var VIEW_CONFIRM = "confirm";
> >var VIEW_END = "end";
> >
> >var form = createForm();
> >var jBean = form.getModel();
> >sendView(form, VIEW_START);
> >sendView(form, VIEW_REGISTRATION);
> >sendView(form, VIEW_INTEREST);
> >if (jBean.organicGardening) {
> >sendView(form, VIEW_GARDENING);
> >} else if (jBean.cooking) {
> >sendView(form, VIEW_COOKING);
> >} else if (jBean.smallholdingManagement) {
> >sendView(form, VIEW_SMALLHOLDING);
> >}
> >sendView(form, VIEW_CONFIRM);
> >sendView(form, VIEW_END);
> > }
This code assumes that you are only moving one direction,
which is not what the wizard is doing.
It is supposed to handle "Prev" as well.
Additionally it always validates the input, which is again not what the demo
is doing.
"Prev" does not trigger validation.
It is unfare to compare oranges to apples!
Please, implement the exact same functionality of the demo before further
comparison.
The action code is very verbose to make it clear what it is supposed to do
in the general case.
You realize that if it were for this specific application, I could optimize
the code to
look much shorter and use a map for looking up the next/prev page in the
workflow.
I don't think that anyone on this list needs lessons on how to shorten
if ( formView.equals ( VIEW_REGISTRATION ) )
{
if ( command.equals( CMD_NEXT ) )
{
return page( VIEW_INTEREST );
}
}
to
if (formView.equals(VIEW_REGISTRATION))
return page( VIEW_INTEREST );
which assumes that there is only one way navigation.
It is not much different than the js code:
sendView(form, VIEW_REGISTRATION);
sendView(form, VIEW_INTEREST);
but it doesn't have the overhead of preserving runtime stack.
It also doesn't have to deal with abandoned runtime stacks.
I will leave the scalability issue aside, granting to the js flow its young
age.
>
> Which shows exactly why continuations provide such a simple way of
> programming complex applications!
Until now, it has shown to me a simple way to program simple applications.
Again, I would love to see a better alternative to the traditional events
model.
However let's leave emotions aside and compare objectively.
Since there are so many people excited about it, someone has to
play devil's advocate.
Re: [Proposal] Implementing XMLForm with Flow
On Friday, Dec 6, 2002, at 10:34 US/Pacific, Stefano Mazzocchi wrote: Ivelin Ivanov wrote: Sorry I wasn't clear before. I know you can call Java from the flow. The question is how to use the flow in a way which significantly reduces code while making the maintenance easier and improving the readability. I think this is a serious challenge and I'd love to see the results as well. Ivelin has a good point: if the sitemap+flowscript can't come up with an elegant way to replace the current XMLForm functionality (it doesn't have to 'clone' the logic, but cover the exact same functional needs) we might need to rethink our strategy toward cocoon web applications. Try to beat the existing XMLForm wizard demo. If you succeed, it will be great ! Yes, indeed. It will clear *much* confusion that many people see to have on the fact that XMLForm can solve all those webapp needs. Check out Christopher's implementation using the control flow: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103923083624699&w=2 Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://webweavertech.com/ovidiu/weblog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
return page( VIEW_GARDENING );
}
return page( VIEW_INTEREST );
}
}
else if ( formView.equals ( VIEW_CONFIRM ) )
{
if ( command.equals( CMD_NEXT ) )
{
return page( VIEW_END );
}
else if( command.equals( CMD_PREV ) )
{
if ( jBean.getOrganicGardening() == true )
{
return page( VIEW_GARDENING );
} return page( VIEW_INTEREST );
}
}
}
Ivelin Ivanov wrote:
Sorry I wasn't clear before.
I know you can call Java from the flow.
The question is how to use the flow in a way which significantly
reduces
code
while making the maintenance easier and improving the readability.
Try to beat the existing XMLForm wizard demo.
If you succeed, it will be great !
Fingers crossed,
Ivelin
- Original Message -
From: "Ugo Cei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 2:36 AM
Subject: Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote:
I hope you are the last hero trying to confront this monster.
The discussion how to combine the two has been going on forever,
but we
have
not come to an agreement.
I'm currently recovering the previous threads from the archive and
reading them.
I would gladly offer my tactical guidance for your effort.
Thank you.
If I was to do this with Actions, I could use well known and
standardized
Java APIs - JWSP or JDBC.
But, as Ovidiu pointed out, you can!
var schemaFactory =
Packages.org.apache.cocoon.components.validation.SchemaFactory.lookup
("http://www.ascc.net/xml/schematron";);
var is = new Packages.org.xml.sax.InputSource
("flows/newuser-schema.xml");
var schema = schemaFactory.compileSchema(is);
var validator = schema.newValidator();
validator.setProperty("http://xml.apache.org/cocoon/validator/phase";,
"NewUser");
violations = validator.validate(userBean);
This is just a quick hack I put together looking at the code for the
AbstractXMLFormAction and Form, but it works. I just need to define
some
symbolic constants for the namespaces and find a way to access a
SourceResolver from JavaScript to make it pretty.
Anyway, if you prefer to write complex business logic in Java (and
I'd
agree wholeheartedly with that), you can encapsulate it in a Java
method
that returns a boolean or an index to drive the flow that will be
implemented by an if/then/else or a switch in JavaScript.
What do we gain by this? We remove flow logic from the sitemap in the
form of actions and put it in the flowscript, where it belongs
(IMHO).
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Right on. - Original Message - From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 06, 2002 12:34 PM Subject: Re: [Proposal] Implementing XMLForm with Flow > Ivelin Ivanov wrote: > > Sorry I wasn't clear before. > > I know you can call Java from the flow. > > The question is how to use the flow in a way which significantly reduces > > code while making the maintenance easier and improving the readability. > > I think this is a serious challenge and I'd love to see the results as well. > > Ivelin has a good point: if the sitemap+flowscript can't come up with an > elegant way to replace the current XMLForm functionality (it doesn't > have to 'clone' the logic, but cover the exact same functional needs) we > might need to rethink our strategy toward cocoon web applications. > > > Try to beat the existing XMLForm wizard demo. > > If you succeed, it will be great ! > > Yes, indeed. It will clear *much* confusion that many people see to have > on the fact that XMLForm can solve all those webapp needs. > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Apparently we have different perspectives on this matter,
but that is good.
- Original Message -
From: "Christopher Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 07, 2002 9:37 AM
Subject: Re: [Proposal] Implementing XMLForm with Flow
> Ivelin Ivanov wrote:
>
> >I was refering to the demo wizard not the howto wizard, although they are
> >similar.
> >
> Uh, does it matter? Is the action code in that wizard any less convoluted?
>
> >
> >How would the flow code look if you implement the functionality of 2 way
> >navigation (prev, next).
> >
> It would look exactly the same. See Ovidiu's answer to Daniel's message
> cited below. This functionality can be implemented outside the flow
> script itself.
>
> >Additionally when prev is pressed, validation is skipped.
> >
> >
> >
> Well, there are many ways to implement this behavior, none of them
> difficult, for example:
>
> function shouldValidate(form, request) {
>// do whatever to decide if validation should happen
>return true;
> }
>
> function sendView(form, view, uri) {
> form.clearViolations();
> if (uri == undefined) {
> uri = view + ".xml";
> }
> sendPageAndWait(uri, {id: view});
> if (shouldValidate(form, cocoon.request) {
> form.populate(cocoon.request);
> if (form.violations != null) {
> sendView(form, view, uri);
> }
> }
> }
>
> Bottom line, in my opinion, there's no doubt such functionality can be
> implemented. And there's equally no doubt in my opinion that the flow
> layer provides an elegant solution compared to using actions. (Remember,
> that was the objection you most recently raised).
>
> Regards,
>
> Chris
>
> >Ivelin
> >
> >
> >
> >- Original Message -
> >From: "Christopher Oliver" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Friday, December 06, 2002 9:13 PM
> >Subject: Re: [Proposal] Implementing XMLForm with Flow
> >
> >
> >
> >
> >>Um, I think Daniel basically answered this question a long time ago:
> >>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2.
> >>
> >>Sorry, I don't have an actual implementation, but I think it's clear
> >>that the corresponding flow code would be much more readable than the
> >>action code in the XML form howto (namely something like below). That is
> >>the whole point of the flow layer - that you don't have to write
> >>state-machine code as in XMLForm actions. Compare the flow version to
> >>the original XMLForm action code reproduced below, and judge for
yourself.
> >>
> >>// display form, wait for submission, and
> >>// apply validations; repeat until no violations
> >>function sendView(form, view, uri) {
> >>form.clearViolations();
> >>if (uri == undefined) {
> >>uri = view + ".xml";
> >>}
> >>sendPageAndWait(uri, {id: view});
> >>form.populate(cocoon.request);
> >>if (form.violations != null) {
> >>sendView(form, view, uri);
> >>}
> >>}
> >>
> >>function createForm() {
> >>// create the Form object
> >>// ...
> >>}
> >>
> >>function howToWizard() {
> >>// different form views
> >>// participating in the wizard
> >>var VIEW_START = "start";
> >>var VIEW_REGISTRATION = "registration";
> >>var VIEW_INTEREST = "interest";
> >>var VIEW_GARDENING = "organicGardening";
> >>var VIEW_COOKING = "cooking";
> >>var VIEW_SMALLHOLDING = "smallholdingManagement";
> >>var VIEW_CONFIRM = "confirm";
> >>var VIEW_END = "end";
> >>
> >>var form = createForm();
> >>var jBean = form.getModel();
> >>sendView(form, VIEW_START);
> >>sendView(form, VIEW_REGISTRATION);
> >>sendView(form, VIEW_INTEREST);
> >>if (jBean.organicGardening) {
> >>sendView(form, VIEW_GARDENING);
> >>} else if (jBean.cooking) {
> >>sendView(form, VIEW_COOKING);
> >>} else if (jBean.smallholdingManagement) {
> >>sendView(form, VIEW_SMALLHOLDING);
> >>}
> >>sendView(form, VIEW_CONFIRM);
> >&
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote:
I was refering to the demo wizard not the howto wizard, although they are
similar.
Uh, does it matter? Is the action code in that wizard any less convoluted?
How would the flow code look if you implement the functionality of 2 way
navigation (prev, next).
It would look exactly the same. See Ovidiu's answer to Daniel's message
cited below. This functionality can be implemented outside the flow
script itself.
Additionally when prev is pressed, validation is skipped.
Well, there are many ways to implement this behavior, none of them
difficult, for example:
function shouldValidate(form, request) {
// do whatever to decide if validation should happen
return true;
}
function sendView(form, view, uri) {
form.clearViolations();
if (uri == undefined) {
uri = view + ".xml";
}
sendPageAndWait(uri, {id: view});
if (shouldValidate(form, cocoon.request) {
form.populate(cocoon.request);
if (form.violations != null) {
sendView(form, view, uri);
}
}
}
Bottom line, in my opinion, there's no doubt such functionality can be
implemented. And there's equally no doubt in my opinion that the flow
layer provides an elegant solution compared to using actions. (Remember,
that was the objection you most recently raised).
Regards,
Chris
Ivelin
- Original Message -
From: "Christopher Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 06, 2002 9:13 PM
Subject: Re: [Proposal] Implementing XMLForm with Flow
Um, I think Daniel basically answered this question a long time ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2.
Sorry, I don't have an actual implementation, but I think it's clear
that the corresponding flow code would be much more readable than the
action code in the XML form howto (namely something like below). That is
the whole point of the flow layer - that you don't have to write
state-machine code as in XMLForm actions. Compare the flow version to
the original XMLForm action code reproduced below, and judge for yourself.
// display form, wait for submission, and
// apply validations; repeat until no violations
function sendView(form, view, uri) {
form.clearViolations();
if (uri == undefined) {
uri = view + ".xml";
}
sendPageAndWait(uri, {id: view});
form.populate(cocoon.request);
if (form.violations != null) {
sendView(form, view, uri);
}
}
function createForm() {
// create the Form object
// ...
}
function howToWizard() {
// different form views
// participating in the wizard
var VIEW_START = "start";
var VIEW_REGISTRATION = "registration";
var VIEW_INTEREST = "interest";
var VIEW_GARDENING = "organicGardening";
var VIEW_COOKING = "cooking";
var VIEW_SMALLHOLDING = "smallholdingManagement";
var VIEW_CONFIRM = "confirm";
var VIEW_END = "end";
var form = createForm();
var jBean = form.getModel();
sendView(form, VIEW_START);
sendView(form, VIEW_REGISTRATION);
sendView(form, VIEW_INTEREST);
if (jBean.organicGardening) {
sendView(form, VIEW_GARDENING);
} else if (jBean.cooking) {
sendView(form, VIEW_COOKING);
} else if (jBean.smallholdingManagement) {
sendView(form, VIEW_SMALLHOLDING);
}
sendView(form, VIEW_CONFIRM);
sendView(form, VIEW_END);
}
From HowToWizardAction.java:
// apply control flow rules
if ( formView.equals ( VIEW_REGISTRATION ) )
{
if ( command.equals( CMD_NEXT ) )
{
return page( VIEW_INTEREST );
}
}
else if ( formView.equals ( VIEW_INTEREST ) )
{
if ( command.equals( CMD_NEXT ) )
{
if ( jBean.getOrganicGardening() == true )
{
return page( VIEW_GARDENING );
}
else if ( jBean.getCooking() == true )
{
return page( VIEW_COOKING );
}
else if ( jBean.getSmallholdingManagement() == true )
{
return page( VIEW_SMALLHOLDING );
}
//else if ( getForm().get
return page( VIEW_CONFIRM );
}
if ( command.equals( CMD_PREV ) )
{
return page( VIEW_REGISTRATION );
}
}
else if ( formView.equals ( VIEW_GARDENING ) )
{
if ( command.equals ( CMD_NEXT ) )
{
if ( jBean.getCooking() == true )
{
return page( VIEW_COOKING );
}
else if ( jBean.getSmallholdingManagement() == true )
{
return page( VIEW_SMALLHOLDING );
}
return page( VIEW_CONFIRM );
}
else if( command.equals( CMD_PREV ) )
{
r
Re: [Proposal] Implementing XMLForm with Flow
I was refering to the demo wizard not the howto wizard, although they are
similar.
How would the flow code look if you implement the functionality of 2 way
navigation (prev, next).
Additionally when prev is pressed, validation is skipped.
Ivelin
- Original Message -
From: "Christopher Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 06, 2002 9:13 PM
Subject: Re: [Proposal] Implementing XMLForm with Flow
> Um, I think Daniel basically answered this question a long time ago:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2.
>
> Sorry, I don't have an actual implementation, but I think it's clear
> that the corresponding flow code would be much more readable than the
> action code in the XML form howto (namely something like below). That is
> the whole point of the flow layer - that you don't have to write
> state-machine code as in XMLForm actions. Compare the flow version to
> the original XMLForm action code reproduced below, and judge for yourself.
>
> // display form, wait for submission, and
> // apply validations; repeat until no violations
> function sendView(form, view, uri) {
> form.clearViolations();
> if (uri == undefined) {
> uri = view + ".xml";
> }
> sendPageAndWait(uri, {id: view});
> form.populate(cocoon.request);
> if (form.violations != null) {
> sendView(form, view, uri);
> }
> }
>
> function createForm() {
> // create the Form object
> // ...
> }
>
> function howToWizard() {
> // different form views
> // participating in the wizard
> var VIEW_START = "start";
> var VIEW_REGISTRATION = "registration";
> var VIEW_INTEREST = "interest";
> var VIEW_GARDENING = "organicGardening";
> var VIEW_COOKING = "cooking";
> var VIEW_SMALLHOLDING = "smallholdingManagement";
> var VIEW_CONFIRM = "confirm";
> var VIEW_END = "end";
>
> var form = createForm();
> var jBean = form.getModel();
> sendView(form, VIEW_START);
> sendView(form, VIEW_REGISTRATION);
> sendView(form, VIEW_INTEREST);
> if (jBean.organicGardening) {
> sendView(form, VIEW_GARDENING);
> } else if (jBean.cooking) {
> sendView(form, VIEW_COOKING);
> } else if (jBean.smallholdingManagement) {
> sendView(form, VIEW_SMALLHOLDING);
> }
> sendView(form, VIEW_CONFIRM);
> sendView(form, VIEW_END);
> }
>
>
>
> From HowToWizardAction.java:
>
>
>
> // apply control flow rules
> if ( formView.equals ( VIEW_REGISTRATION ) )
> {
> if ( command.equals( CMD_NEXT ) )
> {
> return page( VIEW_INTEREST );
> }
> }
> else if ( formView.equals ( VIEW_INTEREST ) )
> {
> if ( command.equals( CMD_NEXT ) )
> {
>if ( jBean.getOrganicGardening() == true )
>{
> return page( VIEW_GARDENING );
>}
>else if ( jBean.getCooking() == true )
>{
> return page( VIEW_COOKING );
>}
>else if ( jBean.getSmallholdingManagement() == true )
>{
> return page( VIEW_SMALLHOLDING );
>}
>//else if ( getForm().get
> return page( VIEW_CONFIRM );
> }
> if ( command.equals( CMD_PREV ) )
> {
>return page( VIEW_REGISTRATION );
> }
> }
> else if ( formView.equals ( VIEW_GARDENING ) )
> {
> if ( command.equals ( CMD_NEXT ) )
> {
>if ( jBean.getCooking() == true )
>{
> return page( VIEW_COOKING );
>}
>else if ( jBean.getSmallholdingManagement() == true )
>{
> return page( VIEW_SMALLHOLDING );
>}
> return page( VIEW_CONFIRM );
> }
> else if( command.equals( CMD_PREV ) )
> {
> return page( VIEW_INTEREST );
> }
> }
> else if ( formView.equals ( VIEW_COOKING ) )
> {
> if ( command.equals ( CMD_NEXT ) )
> {
>if ( jBean.getSmallholdingManagement() == true )
>{
> return page( VIEW_SMALLHOLDING );
>}
> return page( VIEW_CONFIRM );
> }
> else if ( command.equals( CMD_PREV ) )
> {
> i
Re: [Proposal] Implementing XMLForm with Flow
w in a way which significantly reduces
code
while making the maintenance easier and improving the readability.
Try to beat the existing XMLForm wizard demo.
If you succeed, it will be great !
Fingers crossed,
Ivelin
- Original Message -----
From: "Ugo Cei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 2:36 AM
Subject: Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote:
I hope you are the last hero trying to confront this monster.
The discussion how to combine the two has been going on forever, but we
have
not come to an agreement.
I'm currently recovering the previous threads from the archive and
reading them.
I would gladly offer my tactical guidance for your effort.
Thank you.
If I was to do this with Actions, I could use well known and
standardized
Java APIs - JWSP or JDBC.
But, as Ovidiu pointed out, you can!
var schemaFactory =
Packages.org.apache.cocoon.components.validation.SchemaFactory.lookup
("http://www.ascc.net/xml/schematron";);
var is = new Packages.org.xml.sax.InputSource
("flows/newuser-schema.xml");
var schema = schemaFactory.compileSchema(is);
var validator = schema.newValidator();
validator.setProperty("http://xml.apache.org/cocoon/validator/phase";,
"NewUser");
violations = validator.validate(userBean);
This is just a quick hack I put together looking at the code for the
AbstractXMLFormAction and Form, but it works. I just need to define some
symbolic constants for the namespaces and find a way to access a
SourceResolver from JavaScript to make it pretty.
Anyway, if you prefer to write complex business logic in Java (and I'd
agree wholeheartedly with that), you can encapsulate it in a Java method
that returns a boolean or an index to drive the flow that will be
implemented by an if/then/else or a switch in JavaScript.
What do we gain by this? We remove flow logic from the sitemap in the
form of actions and put it in the flowscript, where it belongs (IMHO).
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [Proposal] Implementing XMLForm with Flow
Hi Ovidiu, I will post an example as soon as I have a free day because I have to remove some enhancements which make no sense as they require our internal libraries. I hope you'll hear from me next week but I can't promise it. Regards, Reinhard > -Original Message- > From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 8:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [Proposal] Implementing XMLForm with Flow > > > Hi Reinhard, > On Thursday, Dec 5, 2002, at 13:25 US/Pacific, Reinhard Poetz wrote: > > >> Conclusion: let's reimplement XMLForm using Flow as the controller and > >> get rid of those actions. > > > > I have already successfully reimplmented the XMLForms using the control > > flow. I would have posted an example but internal reasons made > > enhancements > > and changes to the XMLForms implementation necessary. > > > > I will come up with some more details soon. Are you interested? > > Yes, there is a great deal of interest for having this integration. > Could you please share the idea behind your implementation? Code would > also be great ;) > > Best regards, > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > http://webweavertech.com/ovidiu/weblog/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Proposal] Implementing XMLForm with Flow
> -Original Message- > From: Ugo Cei [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 9:25 AM > To: [EMAIL PROTECTED] > Subject: Re: [Proposal] Implementing XMLForm with Flow > > > Reinhard Poetz wrote: > > I have already successfully reimplmented the XMLForms using the control > > flow. I would have posted an example but internal reasons made > enhancements > > and changes to the XMLForms implementation necessary. > > > > I will come up with some more details soon. Are you interested? > > > > Regards, > > Reinhard > > Nah, I was planning to do it all myself because I'm a Real Programmer > (TM) ;-. ;-) > > Jokes aside, yes, I'm very much interested. Please share what you have > with us. If I'm right you want to start in January when your holidays start. My example should be available then. Regards, Reinhard > > Ugo > > > -- > Ugo Cei - http://www.beblogging.com/blog/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote: Sorry I wasn't clear before. I know you can call Java from the flow. The question is how to use the flow in a way which significantly reduces code while making the maintenance easier and improving the readability. I think this is a serious challenge and I'd love to see the results as well. Ivelin has a good point: if the sitemap+flowscript can't come up with an elegant way to replace the current XMLForm functionality (it doesn't have to 'clone' the logic, but cover the exact same functional needs) we might need to rethink our strategy toward cocoon web applications. Try to beat the existing XMLForm wizard demo. If you succeed, it will be great ! Yes, indeed. It will clear *much* confusion that many people see to have on the fact that XMLForm can solve all those webapp needs. -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote: Sorry I wasn't clear before. I know you can call Java from the flow. The question is how to use the flow in a way which significantly reduces code while making the maintenance easier and improving the readability. Try to beat the existing XMLForm wizard demo. If you succeed, it will be great ! Fingers crossed, Ivelin While reducing the amount of code would be a worthwile goal per se, my aim is different. First, I like flow more than actions (I think I'm not alone in that). And second, I want to enable more people (mainly inside my organization) to be able to "script" web applications and I think JavaScript could significantly lower the activation threshold in that respect. Shorten the edit/compile/correct-errors/deploy/reload-cocoon/test cycle and maybe you can be more productive. At least, I hope so. I also want to have a cleaner and more declarative sitemap. All of this, of course, while reusing most of what you have already done. Reusing the Validator and SchematronValidator is a piece of cake. Reusing the Form and the XMLFormTransformer might be harder, I still don't know. Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Reinhard Poetz wrote: I have already successfully reimplmented the XMLForms using the control flow. I would have posted an example but internal reasons made enhancements and changes to the XMLForms implementation necessary. I will come up with some more details soon. Are you interested? Regards, Reinhard Nah, I was planning to do it all myself because I'm a Real Programmer (TM) ;-. Jokes aside, yes, I'm very much interested. Please share what you have with us. Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Hi Reinhard, On Thursday, Dec 5, 2002, at 13:25 US/Pacific, Reinhard Poetz wrote: Conclusion: let's reimplement XMLForm using Flow as the controller and get rid of those actions. I have already successfully reimplmented the XMLForms using the control flow. I would have posted an example but internal reasons made enhancements and changes to the XMLForms implementation necessary. I will come up with some more details soon. Are you interested? Yes, there is a great deal of interest for having this integration. Could you please share the idea behind your implementation? Code would also be great ;) Best regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://webweavertech.com/ovidiu/weblog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
yes. - Original Message - From: "Reinhard Poetz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 05, 2002 3:25 PM Subject: RE: [Proposal] Implementing XMLForm with Flow > > Conclusion: let's reimplement XMLForm using Flow as the controller and > > get rid of those actions. > > I have already successfully reimplmented the XMLForms using the control > flow. I would have posted an example but internal reasons made enhancements > and changes to the XMLForms implementation necessary. > > I will come up with some more details soon. Are you interested? > > Regards, > Reinhard > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Sorry I wasn't clear before.
I know you can call Java from the flow.
The question is how to use the flow in a way which significantly reduces
code
while making the maintenance easier and improving the readability.
Try to beat the existing XMLForm wizard demo.
If you succeed, it will be great !
Fingers crossed,
Ivelin
- Original Message -
From: "Ugo Cei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 2:36 AM
Subject: Re: [Proposal] Implementing XMLForm with Flow
> Ivelin Ivanov wrote:
> > I hope you are the last hero trying to confront this monster.
> >
> > The discussion how to combine the two has been going on forever, but we
have
> > not come to an agreement.
>
> I'm currently recovering the previous threads from the archive and
> reading them.
>
> > I would gladly offer my tactical guidance for your effort.
>
> Thank you.
>
> > If I was to do this with Actions, I could use well known and
standardized
> > Java APIs - JWSP or JDBC.
>
> But, as Ovidiu pointed out, you can!
>
> var schemaFactory =
>Packages.org.apache.cocoon.components.validation.SchemaFactory.lookup
> ("http://www.ascc.net/xml/schematron";);
> var is = new Packages.org.xml.sax.InputSource
>("flows/newuser-schema.xml");
> var schema = schemaFactory.compileSchema(is);
> var validator = schema.newValidator();
> validator.setProperty("http://xml.apache.org/cocoon/validator/phase";,
>"NewUser");
> violations = validator.validate(userBean);
>
> This is just a quick hack I put together looking at the code for the
> AbstractXMLFormAction and Form, but it works. I just need to define some
> symbolic constants for the namespaces and find a way to access a
> SourceResolver from JavaScript to make it pretty.
>
> Anyway, if you prefer to write complex business logic in Java (and I'd
> agree wholeheartedly with that), you can encapsulate it in a Java method
> that returns a boolean or an index to drive the flow that will be
> implemented by an if/then/else or a switch in JavaScript.
>
> What do we gain by this? We remove flow logic from the sitemap in the
> form of actions and put it in the flowscript, where it belongs (IMHO).
>
> Ugo
>
> --
> Ugo Cei - http://www.beblogging.com/blog/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Chris, Yes, I am aware that I can call Java methods from the flow. The result however is a bigger spagetti than if I only used Java. If someone can produce a version of the XMLForm demo wizard which uses the flow and produces the same result with significantly less code and better readability, I would consider that a serious step ahead. Cheers, Ivelin - Original Message - From: "Christopher Oliver" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 11:26 PM Subject: RE: [Proposal] Implementing XMLForm with Flow Ivelin, Not sure if you realize this already, but you can use all those Java API's from the flow layer if you need them. Rhino provides bidirectional interoperability with Java: you can create java objects and call their methods from JavaScript, and you can extend Java classes and implement Java interfaces in JavaScript. Regards, Chris -Original Message- From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 8:43 PM To: [EMAIL PROTECTED] Subject: Re: [Proposal] Implementing XMLForm with Flow I hope you are the last hero trying to confront this monster. The discussion how to combine the two has been going on forever, but we have not come to an agreement. I would gladly offer my tactical guidance for your effort. The biggest issue that I had so far with the flow is how to implement in an elegant way, navigation logic which depends on domain knowledge. For example how to do a wizard where the next page (Car Models) depends on a selection on the previous (Brand Name) as well as a lookup to an external resource (BMW's Web Service providing a list of current car models or a db query). If I was to do this with Actions, I could use well known and standardized Java APIs - JWSP or JDBC. Maybe my issue is that I used the Struts model for too long and I can't get out of the box. Cheers, Ivelin - Original Message - From: "Ugo Cei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 2:35 AM Subject: [Proposal] Implementing XMLForm with Flow > Premise #1: XMLForm has great support for XForms and validation, but it > uses butt-ugly actions for implementing the Control part of MVC. > > Premise #2: Control Flow rocks as an MVC (or MVC+) controller. > > Conclusion: let's reimplement XMLForm using Flow as the controller and > get rid of those actions. > > Plan of action: familiarize myself with both frameworks (I just started > using flow) and their internals, then start designing and coding. I have > a couple weeks' vacation starting Jan 1st and it would be nice to have > some nice OS project to work on ;-). > > Ivelin, Ovidiu (and everybody else), what do you think? > > Ugo > > -- > Ugo Cei - http://www.beblogging.com/blog/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Proposal] Implementing XMLForm with Flow
> Conclusion: let's reimplement XMLForm using Flow as the controller and > get rid of those actions. I have already successfully reimplmented the XMLForms using the control flow. I would have posted an example but internal reasons made enhancements and changes to the XMLForms implementation necessary. I will come up with some more details soon. Are you interested? Regards, Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
I've been looking into this too, and would like to add my 2 cents. Basically I'm trying to build an interactive "wizard" type application, but don't want to author the the wizard pages themselves, or control the flow; this is because the content & flow is highly specialized, and I am not :->. It's the flow where problems persist; I have gotten branching working (if you slected this go here, if that go there) using basic javascript, but this doesn't scale at all. My approach is to break down each page into three logical parts, , which is the question and background content, , which is essentially the form itself, and which is where the flow lives. More static flow (next page doesn't depend on any responses) this is fine, and for simply branching javascript works OK, because one can change the "next" value using "onchange" attributes of the form elements. But javascript isn't a satisfactory approach because of scalability and depndence on the browser (I could actually live with it if it scaled). Anyway, I still don't know how implement flow, especially aloowing the authors to control simple flow. One ugly thought I've had is to include in each page a hidden form that contains all the previous responses, and let javascript control the flow, since it now has access to all the needed data. While I'm not endorsing javascript as the solution, let me describe how I've done the basic flow control: for each form I have a FormManager class in javascript that can register handlers for each form element. Then for each form and form element, the stylesheet defines a unique ID attribute. When specified in the section, the stylesheet creates a register handler function that registers a desired change in a target element when a trigger element is modified. So when you check "No", the hidden element that sets what the next page will be might change its value from the default "occupation" to instead "program of study" page, or some such thing. By using a central handler, this should be extensible to any variety of such actions, and if all the data were provided in a hidden form, then the domain knowledge is right there for the javascript to use. I think that it would make sense to have the data indexed by XPath values Pros: This would for many purposes fulfill the requirements, and the Action class would now be quite simple. In addition it would allow flow to be moved from the developer to the author, which will be quite useful when flow is simple (when x->y when a->b otherwise z). Also, almost all coding is now in stylesheets instead of Java itself. Also, DHTML techiques are fairly well established at this point. Cons: Javascript needed; while javascript is fairly splintered among different browsers, this would demand only the most basic & core functionality. May get more & more messy over time, lots of CDATA sections. Again, I'm not married to this idea, and am actually thinking of moving to an XSP to control flow logic for now. But I did spend some time thinking about, and still consider it a viable idea. For now I'm waiting to see what the content authors really need from the application before proceeding with flow. Anyway, my cents. rob On Wed, 4 Dec 2002, Ivelin Ivanov wrote: > > I hope you are the last hero trying to confront this monster. > > The discussion how to combine the two has been going on forever, but we have > not come to an agreement. > I would gladly offer my tactical guidance for your effort. > > The biggest issue that I had so far with the flow is how to implement in an > elegant way, navigation logic which depends on domain knowledge. > For example how to do a wizard where the next page (Car Models) depends on a > selection on the previous (Brand Name) as well as a lookup to an external > resource (BMW's Web Service providing a list of current car models or a db > query). > > If I was to do this with Actions, I could use well known and standardized > Java APIs - JWSP or JDBC. > Maybe my issue is that I used the Struts model for too long and I can't get > out of the box. > > > Cheers, > > Ivelin > > > > - Original Message - > From: "Ugo Cei" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, December 04, 2002 2:35 AM > Subject: [Proposal] Implementing XMLForm with Flow > > > > Premise #1: XMLForm has great support for XForms and validation, but it > > uses butt-ugly actions for implementing the Control part of MVC. > > > > Premise #2: Control Flow rocks as an MVC (or MVC+) controller. > > > > Conclusion: let's reimplement XMLForm using Flow as the controller and > > get rid of those actions. > > > > Plan of action: familiarize myself with both frameworks (I just started > > using flow) and their internals, then start designing and coding. I have > > a couple weeks' vacation starting Jan 1st and it would be nice to have > > some nice OS project to work on ;-). > > > > Ivelin, Ovidiu (and everybody else), what do you think? > > > > Ugo > > > > -- > > Ugo Cei -
Re: [Proposal] Implementing XMLForm with Flow
Ugo Cei wrote: But, as Ovidiu pointed out, you can! Sorry, wrong attribution again. It was Christopher Oliver actually. Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote:
I hope you are the last hero trying to confront this monster.
The discussion how to combine the two has been going on forever, but we have
not come to an agreement.
I'm currently recovering the previous threads from the archive and
reading them.
I would gladly offer my tactical guidance for your effort.
Thank you.
If I was to do this with Actions, I could use well known and standardized
Java APIs - JWSP or JDBC.
But, as Ovidiu pointed out, you can!
var schemaFactory =
Packages.org.apache.cocoon.components.validation.SchemaFactory.lookup
("http://www.ascc.net/xml/schematron";);
var is = new Packages.org.xml.sax.InputSource
("flows/newuser-schema.xml");
var schema = schemaFactory.compileSchema(is);
var validator = schema.newValidator();
validator.setProperty("http://xml.apache.org/cocoon/validator/phase";,
"NewUser");
violations = validator.validate(userBean);
This is just a quick hack I put together looking at the code for the
AbstractXMLFormAction and Form, but it works. I just need to define some
symbolic constants for the namespaces and find a way to access a
SourceResolver from JavaScript to make it pretty.
Anyway, if you prefer to write complex business logic in Java (and I'd
agree wholeheartedly with that), you can encapsulate it in a Java method
that returns a boolean or an index to drive the flow that will be
implemented by an if/then/else or a switch in JavaScript.
What do we gain by this? We remove flow logic from the sitemap in the
form of actions and put it in the flowscript, where it belongs (IMHO).
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ivelin Ivanov wrote: I hope you are the last hero trying to confront this monster. The discussion how to combine the two has been going on forever, but we have not come to an agreement. I would gladly offer my tactical guidance for your effort. The biggest issue that I had so far with the flow is how to implement in an elegant way, navigation logic which depends on domain knowledge. For example how to do a wizard where the next page (Car Models) depends on a selection on the previous (Brand Name) as well as a lookup to an external resource (BMW's Web Service providing a list of current car models or a db query). If I was to do this with Actions, I could use well known and standardized Java APIs - JWSP or JDBC. Maybe my issue is that I used the Struts model for too long and I can't get out of the box. Have you tried to use a relational->object mapping tool (say Jakarta OJB) and connect those objects from the flowscript? That's how I would do it on paper but I never tried it. It might be interesting to see others trying. -- Stefano Mazzocchi <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Proposal] Implementing XMLForm with Flow
Ivelin, Not sure if you realize this already, but you can use all those Java API's from the flow layer if you need them. Rhino provides bidirectional interoperability with Java: you can create java objects and call their methods from JavaScript, and you can extend Java classes and implement Java interfaces in JavaScript. Regards, Chris -Original Message- From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 8:43 PM To: [EMAIL PROTECTED] Subject: Re: [Proposal] Implementing XMLForm with Flow I hope you are the last hero trying to confront this monster. The discussion how to combine the two has been going on forever, but we have not come to an agreement. I would gladly offer my tactical guidance for your effort. The biggest issue that I had so far with the flow is how to implement in an elegant way, navigation logic which depends on domain knowledge. For example how to do a wizard where the next page (Car Models) depends on a selection on the previous (Brand Name) as well as a lookup to an external resource (BMW's Web Service providing a list of current car models or a db query). If I was to do this with Actions, I could use well known and standardized Java APIs - JWSP or JDBC. Maybe my issue is that I used the Struts model for too long and I can't get out of the box. Cheers, Ivelin - Original Message - From: "Ugo Cei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 2:35 AM Subject: [Proposal] Implementing XMLForm with Flow > Premise #1: XMLForm has great support for XForms and validation, but it > uses butt-ugly actions for implementing the Control part of MVC. > > Premise #2: Control Flow rocks as an MVC (or MVC+) controller. > > Conclusion: let's reimplement XMLForm using Flow as the controller and > get rid of those actions. > > Plan of action: familiarize myself with both frameworks (I just started > using flow) and their internals, then start designing and coding. I have > a couple weeks' vacation starting Jan 1st and it would be nice to have > some nice OS project to work on ;-). > > Ivelin, Ovidiu (and everybody else), what do you think? > > Ugo > > -- > Ugo Cei - http://www.beblogging.com/blog/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
I hope you are the last hero trying to confront this monster. The discussion how to combine the two has been going on forever, but we have not come to an agreement. I would gladly offer my tactical guidance for your effort. The biggest issue that I had so far with the flow is how to implement in an elegant way, navigation logic which depends on domain knowledge. For example how to do a wizard where the next page (Car Models) depends on a selection on the previous (Brand Name) as well as a lookup to an external resource (BMW's Web Service providing a list of current car models or a db query). If I was to do this with Actions, I could use well known and standardized Java APIs - JWSP or JDBC. Maybe my issue is that I used the Struts model for too long and I can't get out of the box. Cheers, Ivelin - Original Message - From: "Ugo Cei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 2:35 AM Subject: [Proposal] Implementing XMLForm with Flow > Premise #1: XMLForm has great support for XForms and validation, but it > uses butt-ugly actions for implementing the Control part of MVC. > > Premise #2: Control Flow rocks as an MVC (or MVC+) controller. > > Conclusion: let's reimplement XMLForm using Flow as the controller and > get rid of those actions. > > Plan of action: familiarize myself with both frameworks (I just started > using flow) and their internals, then start designing and coding. I have > a couple weeks' vacation starting Jan 1st and it would be nice to have > some nice OS project to work on ;-). > > Ivelin, Ovidiu (and everybody else), what do you think? > > Ugo > > -- > Ugo Cei - http://www.beblogging.com/blog/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Daniel Fagerström wrote: We had a discussion about half a year ago about how to integrate XMLForm and Flow [1], I proposed a design and booth Ovidiu and Ivelin seemed to Obviously at the time I wasn't interested in form handling at all, otherwise I'd have remembered that thread ;-). I could also send my broken implementation to the list if anybody is interested. Why not? Ugo -- Ugo Cei - http://www.beblogging.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
Ugo Cei wrote: Premise #1: XMLForm has great support for XForms and validation, but it uses butt-ugly actions for implementing the Control part of MVC. Premise #2: Control Flow rocks as an MVC (or MVC+) controller. Conclusion: let's reimplement XMLForm using Flow as the controller and get rid of those actions. Plan of action: familiarize myself with both frameworks (I just started using flow) and their internals, then start designing and coding. I have a couple weeks' vacation starting Jan 1st and it would be nice to have some nice OS project to work on ;-). Ivelin, Ovidiu (and everybody else), what do you think? Ugo We had a discussion about half a year ago about how to integrate XMLForm and Flow [1], I proposed a design and booth Ovidiu and Ivelin seemed to approve it. I also spent some time implementing the XMLForm wizard example in the propsed way, and had a working implementation for a short while. Due to non intuitive caching behaviour I succeed in breaking my implementation without noticing it and never got it to work again :(, (debuging flow scripts was a nightmare back then). It would be interesting to give it a new trial, hopefully the framework is alitle bit more mature now. I could also send my broken implementation to the list if anybody is interested. Ovidiu proposed a small extension [2] of flow script that will simplify back button handling in forms significally. Daniel Fagerstrom [1] Flow and XMLForm http://marc.theaimsgroup.com/?t=10201456875&r=1&w=2, see especially the first half of the thread. [2] Re: flowscript save-on-back http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103889984417741&w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Implementing XMLForm with Flow
I agree. I need to create a new payroll system. I will like to make it using XMLForms and ModularDB. I think the Database interface to XMLForms can be done easier. As little as I know about that, the DB interface currently must be done using JavaBeans. :-( But maybe we can find another way to implement this. :-D I hope you can include me in this effort. Best Regards, Antonio Gallardo. Ugo Cei dijo: > Premise #1: XMLForm has great support for XForms and validation, but it > uses butt-ugly actions for implementing the Control part of MVC. > > Premise #2: Control Flow rocks as an MVC (or MVC+) controller. > > Conclusion: let's reimplement XMLForm using Flow as the controller and > get rid of those actions. > > Plan of action: familiarize myself with both frameworks (I just started > using flow) and their internals, then start designing and coding. I have > a couple weeks' vacation starting Jan 1st and it would be nice to have > some nice OS project to work on ;-). > > Ivelin, Ovidiu (and everybody else), what do you think? > > Ugo > > -- > Ugo Cei - http://www.beblogging.com/blog/ > > > - To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
