cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [status & RT] design challenges
Date Sun, 07 Apr 2002 15:22:07 GMT
Ovidiu,


----- Original Message -----
From: "Ovidiu Predescu" <ovidiu@apache.org>
To: "Stefano Mazzocchi" <stefano@apache.org>
Cc: <cocoon-dev@xml.apache.org>
Sent: Friday, April 05, 2002 10:25 PM
Subject: Re: [status & RT] design challenges

<snip/>

> Currently JavaScript is the only language fully supported, but Scheme
> is in the works. Depending on the Scheme implementation performance
> compared to the JavaScript one, I may decide to go ahead and implement
> jWeave, the Java-like language front-end for the Scheme interpreter.

Would it be feasible to think about XSLT support?
The reason I am saying that is not that JavaScript or Scheme are scary or
anything,
but having lead projects with mixed support for Java, C++, SQL, PL/SQL and
TransactSQL,
I found it quite mind boggling to switch back and forth between development
environments,
debuggers and language syntaxes.
It's an usability and productivity point I am trying to make, nothing else.

> There is a very basic calculator example available in Schecoon, that
> shows how the control flow integrates with the sitemap. Check out the
> sitemap and the webapp/examples/calc/calc.js files for more details.
>
> I'd like to work on a more complex example, perhaps a simple shopping
> site, but I don't have the bandwidth to do it alone. If somebody else
> would like to join as a volunteer, please let me know.

I would be interested, since we need a more sophisticated example for Form
handling as well.
Our current scenario is a multi page wizard which collects information about
the user and sends it to the
(non existing yet) Cocoon registration feedback archive. Would that be
enough?

> I'm working on writing documentation, which will include a description
> of how things are designed to work together, and a best practices
> document. There are several issues one needs to be aware of when
> writing using the flow control layer, and I want to make sure I
> document them.

Is there a draft in CVS?

> I've also started working on a functional regression test suite for
> Cocoon. This is based on the Anteater framework, and it currently
> tests the calculator sample from Schecoon. It should be very easy to
> adapt it to the main Cocoon, to test the main Cocoon pages. I'll
> create a similar setup for the main Cocoon distribution; I would be
> grateful if people will start writing tests for it.
>
> For the future, I'd like to explore how the control flow integrates
> with:
>
> - Ivelin's work on form validation.

I'm all ears.

>
> - exposing business logic as Web services. The control flow layer
> doesn't care what is the output generated by a Cocoon pipeline, so
> this should be feasible.

Whoop, a third ear pops out.

>
> - security and scalability issues when using the usage of potentially
> large continuation objects maintained by the control flow.

Tough to test, but very necessary.



Cheers,

Ivelin



>
> The immediate problem is fixing the bug in ExcaliburComponentManager,
> that prevents Schecoon from running. If anyone knows more about this,
> please let me know.
>
> Greetings,
> Ovidiu
> --
> Ovidiu Predescu <ovidiu@apache.org>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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


Mime
View raw message