I was able to narrow down the bug that I have signalled yesterday concerning
global sitemap parameter
map:match pattern=test1/*
map:generate src=data/{1}/form.xml/
map:transform src=cocoon://{global:baseURL}/stylesheets/reportform2html.xsl
map:parameter name=baseURL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18547.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Upayavira wrote, On 02/04/2003 0.25:
Nicola Ken wrote
...
In the Environment there is
boolean isResponseModified(long lastModified);
void setResponseIsNotModified();
But it's never implemented. In AbstractEnvironment:
public boolean isResponseModified(long lastModified) {
ivelin wrote:
I am proposing to move XMLForm to a block, following the recent suggestions
by Torsten and Vadim.
Very similar to
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
The lib directory will include the jar file with all the files shared
between the standalone and the
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
However, allowing a generator in map:handle-errors is incompatible
with the current syntax.
The idea was to allow it and make it *optional*. I.e., if no generator
specified - use noifier, if user specified some generator - use it
instead of
On Wed, 2003-04-02 at 05:32, ivelin wrote:
Bruno,
It is funny enough that it's April 1, but your email reminds me about the
one Torsten sent out about a year ago, not on April 1 ;)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg14370.html
Maybe in spirit, but not in concrete ideas (see
Cocoon 20030402 [1999-2003]
[echo]
+---+
[echo] Building with Apache Ant version 1.6alpha compiled on April 2 2003
[echo] using build file /home/rubys/jakarta/cocoon-2.1/build.xml
[echo] Compiling
ivelin wrote:
I am proposing to move XMLForm to a block, following the recent suggestions
by Torsten and Vadim.
Very similar to
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
The lib directory will include the jar file with all the files shared
between the standalone and the
Pier Fumagalli wrote:
On 1/4/03 23:36, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Artur Bialecki wrote:
Thanks for the info it makes things clearer for me. But lets say
I do have to fork cocoon for the reasons you mentioned and I have
to name it something different. Do I have to change all
Bruno Dumon wrote:
I think this is where my approach differs from most of the other form
solutions discussed here: I'm not interested in being able to edit any
XML instance governed by any WXS or RNG schema.
I see a form as a collection of widgets holding strongly typed data
(strings, numbers,
Stefano Mazzocchi wrote, On 02/04/2003 12.47:
...
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the*
solution for data-logic control.
2) allows people to experiment different approaches (XForm-based or
not)
Finally - an XML form model (makes sense for Cocoon) AND with a decent
(mature) validation framework!
Brilliant. You've saved us much pain in our project.
Many Thanks.
This is some code we are working on.
It provides an implementation of the XML Form action allowing an XML
model and also
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 02/04/2003 12.47:
...
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the*
solution for data-logic control.
2) allows people to experiment different
Stefano Mazzocchi wrote:
snip/
During the last year of consultancies, I found out that several people
identified XMLForm as the possible way to turn cocoon into better
webapp-capable system.
And having a good form-handling package in Cocoon is absolutely
necessary to have it adopted to
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 02/04/2003 12.47:
...
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the*
solution for data-logic control.
2) allows people to experiment different
cocoon -v gump-core
I get
...
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar
from path as it doesn't exist
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/instrument/build
$ build cocoon gump-core
and I get a bunch of compilation errors.
If I run
$ build cocoon -v gump-core
I get
...
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar
from path as it doesn't exist
Don't
Correct me if I'm wrong but I think there is currently no easy way to
deploy a Jetty + cocoon system by just copying files created by the
cocoon build.
One way that I found is as follows:
-create build/jetty-standalone directory
-copy lib/endorsed, tools/loader, tools/jetty, cocoon.sh and
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Correct me if I'm wrong but I think there is currently no easy way to
deploy a Jetty + cocoon system by just copying files created by the
cocoon build.
And there should not. The Jetty version included in Cocoon is _not_ the full
version. If you
Bruno Dumon wrote:
The last few days I've been doing some thinking about form-handling.
I've been looking at the current solutions in Cocoon and IMHO there
still is room for improvement here and there. BTW, all this has nothing
to do with Ivelin's announcements, or with the fact that it's April 1
Hi,
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 3:25 AM
To: [EMAIL PROTECTED]
But I also want to point out something that I'll need a lot in the
future: the XML datatype in a form.
I would like to be able to submit an
Pier Fumagalli wrote:
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Correct me if I'm wrong but I think there is currently no easy way to
deploy a Jetty + cocoon system by just copying files created by the
cocoon build.
And there should not. The Jetty version included in Cocoon is _not_
Le Mercredi, 2 avr 2003, à 15:27 Europe/Zurich, Sylvain Wallez a écrit :
...I guess Bertrand's purpose is not to use it on production servers,
but to have a small standalone server that can be used for e.g.
demonstrations.
Exactly, demos and teaching.
Problem is, with the current setup people
src/documentation/sitemap.xmap contains:
map:transformer name=idgen
src=org.apache.cocoon.transformation.IdGeneratorTransformer
From revision 1.5 (jefft 26-Mar-03)
Which causes http://localhost:/docs/ to fail as this class is not
included in the webapp build (it comes from Forrest).
As
Hi,
I've been watching this thread for a while now, and as a regular Cocoon
power-user, I am keen to see a good forms framework. Rob's comments have
prompted an important consideration for such a framework.
Where client-side validation is used, it *must* be matched but a second-pass
server side.
Hi,
Thanks for your comments. What is an example of something dangerous?
During a preview view, the submitter would not be able to access the file,
but through the CMS tool, which would perform a server-side transformation
on the XML (or fail). How could some dangerous content piece be used in
$ build cocoon clean
$ build cocoon gump-core
and I get a bunch of compilation errors.
If I run
$ build cocoon -v gump-core
I get
...
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar
from path
On Wed, Apr 02, 2003 at 03:38:10PM +0200, Bertrand Delacretaz wrote:
src/documentation/sitemap.xmap contains:
map:transformer name=idgen
src=org.apache.cocoon.transformation.IdGeneratorTransformer
From revision 1.5 (jefft 26-Mar-03)
Which causes http://localhost:/docs/ to fail as
What I was thinking of was vulnerability to a potential hack attempt. Such
vulnerability can take many forms, ranging from buffer-overruns to
inconsistent record data. I am not an expert on web-security, but know that
providing a solid data-validation boundary is a good first step in securing
my
Le Mercredi, 2 avr 2003, à 16:55 Europe/Zurich, Jeff Turner a écrit :
... I forgot
to do it for the 'webapp' target. Will fix ASAP.
Thanks - nothing urgent for me, just wanted to let you know.
-Bertrand
On Thu, Apr 03, 2003 at 12:55:01AM +1000, Jeff Turner wrote:
On Wed, Apr 02, 2003 at 03:38:10PM +0200, Bertrand Delacretaz wrote:
...
Which causes http://localhost:/docs/ to fail as this class is not
included in the webapp build (it comes from Forrest).
Sorry, my fault. The
Sylvain Wallez wrote:
snip/
Now from an implementation point of view, finding if a generator is
present by analyzing the sitemap is difficult, if not impossible,
since a generator can be inside a matcher/action/selector (will we go
in that path or not ?), or included in a resource also used in
On Wednesday, April 2, 2003, at 08:32 AM, Bertrand Delacretaz wrote:
...I guess Bertrand's purpose is not to use it on production servers,
but to have a small standalone server that can be used for e.g.
demonstrations.
Exactly, demos and teaching.
What if the build target were called
Le Mercredi, 2 avr 2003, à 16:45 Europe/Zurich, Diana Shannon a écrit :
...What if the build target were called teaching/demo-target instead
of jetty-standalone, with a disclaimer including some of Pier's
concerns, so that it wouldn't appear that we were promoting jetty,
rather, just helping
Diana Shannon [EMAIL PROTECTED] wrote:
On Wednesday, April 2, 2003, at 08:32 AM, Bertrand Delacretaz wrote:
...I guess Bertrand's purpose is not to use it on production servers,
but to have a small standalone server that can be used for e.g.
demonstrations.
Exactly, demos and
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Le Mercredi, 2 avr 2003, à 16:45 Europe/Zurich, Diana Shannon a écrit :
...What if the build target were called teaching/demo-target instead
of jetty-standalone, with a disclaimer including some of Pier's
concerns, so that it wouldn't appear that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
Now from an implementation point of view, finding if a generator is
present by analyzing the sitemap is difficult, if not impossible,
since a generator can be inside a matcher/action/selector (will we go
in that path or not ?), or included in
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users (the
ones that write Cocoon apps) that they use such deprecated features in a
way that allows them to be found easily, and not intermixed in the usual
ivelin wrote:
I am proposing to move XMLForm to a block, following the recent suggestions
by Torsten and Vadim.
Very similar to
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
The lib directory will include the jar file with all the files shared
between the standalone and the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
The more I use the flow inside cocoon, the more I think there is no way
back. Not only it enforces SoC, it also removes over-SoC, which happens
where you have your information scattered around the entire place (as
for PHP stuff, for example).
But if the sitemap is the ultimate pipeline engine
$ build cocoon clean
$ build cocoon gump-core
and I get a bunch of compilation errors.
If I run
$ build cocoon -v gump-core
I get
...
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar
from path
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
But once again, I prefer to avoid automagic implicit behaviour of
the sitemap engine, and encourage people to migrate to writing a
map:generate in their error handling and consider implicit generator
and 'type' attributes on handle-error as
Sylvain Wallez wrote:
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users
(the ones that write Cocoon apps) that they use such deprecated
features in a way that allows them to be found easily, and not
gump scripts
$ build cocoon clean
$ build cocoon gump-core
and I get a bunch of compilation errors.
If I run
$ build cocoon -v gump-core
I get
...
dropping
/usr/serverlocal/gump/cocoon-2.1/usr/serverlocal/gump/avalon-excalibur/compatibility/build/lib/excalibur-compatibility-20030402.jar
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Robert Koberg wrote:
Hi,
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 3:25 AM
To: [EMAIL PROTECTED]
But I also want to point out something that I'll need a lot in the
future: the XML datatype in a form.
I would like to be able to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
The more I use the flow inside cocoon, the more I think there is no way
back. Not only it enforces SoC, it also removes over-SoC, which happens
where you have your information scattered around the entire place (as
for PHP stuff, for example).
But if the sitemap is the
Stefano Mazzocchi wrote:
snip/
What do you think?
Have you thought about XSPT (XSP for Transformations): XSP-like
transformers on top of STX transformation language syntax?
Vadim
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 2/04/2003 20:25 Stefano Mazzocchi wrote:
IMHO, the template language which is closer to the optimum is XSLT but
only with one change:
FORGET THE XML SYNTAX!
Corollary, we should drop the XML syntax for the sitemap. I customarily
use this syntax when RT'ing snippets:
match pattern=foo
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
The more I use the flow inside cocoon, the more I think there is no
way back. Not only it enforces SoC, it also removes over-SoC, which
happens where you have your information scattered around the entire
place (as for PHP stuff, for example).
But if the sitemap is the
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users
(the ones that write Cocoon apps) that they use such deprecated
features in a way that allows them to be
Steven Noels wrote:
On 2/04/2003 20:25 Stefano Mazzocchi wrote:
IMHO, the template language which is closer to the optimum is XSLT
but only with one change:
FORGET THE XML SYNTAX!
Corollary, we should drop the XML syntax for the sitemap. I
customarily use this syntax when RT'ing snippets:
On 2/04/2003 21:13 Sylvain Wallez wrote:
We can easily guess that. Please, please add braces !!!
Bah. Syntactic sugar. Who needs braces when you've got spaces! ;-)
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
snip/
What do you think?
Have you thought about XSPT (XSP for Transformations): XSP-like
transformers on top of STX transformation language syntax?
yes, but still too many angle brakets around.
Stefano.
Berin Loritsch wrote:
Stefano Mazzocchi wrote:
The more I use the flow inside cocoon, the more I think there is no
way back. Not only it enforces SoC, it also removes over-SoC, which
happens where you have your information scattered around the entire
place (as for PHP stuff, for example).
But
Steven Noels wrote:
On 2/04/2003 20:25 Stefano Mazzocchi wrote:
IMHO, the template language which is closer to the optimum is XSLT but
only with one change:
FORGET THE XML SYNTAX!
Corollary, we should drop the XML syntax for the sitemap. I customarily
use this syntax when RT'ing snippets:
Sylvain Wallez wrote:
5) control should be inverted: the template must be a view, it should
be 'pushed' the data in, it should not contain any data-pulling logic
other than the one used to pull data from the dataset passed on by the
underlying controlling stage.
Some restrictions on the push
Stefano Mazzocchi [EMAIL PROTECTED]
snip/
if the sitemap is the ultimate pipeline engine and the
flow is the
ultimate (and transparently statefull!) controller engine,
what is the
*ultimate* view, the best template system?
There are a bunch of paradigms on the table but they can be
Stefano Mazzocchi wrote:
Looking at the generated build.sh file, the classpath is set up
correctly, and no variables are passed on the ant command that would
explain this. I've grepped the various .properties and .xml files in
the cocoon directory and don't see how the excalibur jars are
On Wed, 2 Apr 2003, Hunsberger, Peter wrote:
snip/
Interesting, but I don't see that it really buys me anything I don't already
have with XSLT except the requirement to implement and maintain Yet Another
Language (YAL(tm))...
The whole idea is interesting. The mindbomb has yet to explode
On Wed, 2003-04-02 at 15:25, Sylvain Wallez wrote:
[...]
Since everybody is throwing ideas here in a somehow unordered way, let
me throw in mine, considering my experience with our home-grown forms
framework that we use since late 2000.
First of all, we use a model to define entities,
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
...
So I'm thinking about a global logger dedicated to deprecation
messages. This would allow to write all messages going to that
logger to e.g. a deprecated.log file.
...
Nice suggestion; but can't we just use WARN for
Stefano Mazzocchi wrote, On 02/04/2003 20.25:
...
IMHO, the template language which is closer to the optimum is XSLT but
only with one change:
FORGET THE XML SYNTAX!
*chuckle* I see that your basicness is biting still ;-))
I'm entering wild mode now, so bear with me. Suppose you had:
1) a
On Wed, 02 Apr 2003 21:53:38 +0200, Stefano Mazzocchi wrote:
snip/
In that case, we must have an hybrid model where the flow pushed
information that allows the view to pull its content. E.g. the flow will
push the parameters of a SQL query which is executed by the view and has
its result
On Wed, 02 Apr 2003 21:23:18 +0200, Stefano Mazzocchi wrote:
snip/
Have you thought about XSPT (XSP for Transformations): XSP-like
transformers on top of STX transformation language syntax?
yes, but still too many angle brakets around.
Some time ago (and unfortunately there doesn't seem to
Hello folks!
Maybe you've heard that there was a conference on open source in e-govt in
Washington DC in March 2003, http://www.egovos.org/march-2003/index.html
I gave a speech there about Cocoon.
Now, the organizers are going to publish a book on open source projects.
I've got an impression
Argyn wrote:
Hello folks!
Maybe you've heard that there was a conference on open source in e-govt in
Washington DC in March 2003, http://www.egovos.org/march-2003/index.html
I gave a speech there about Cocoon.
Now, the organizers are going to publish a book on open source projects.
I've got an
cool,
If nobody's objecting I'll submit info later on this weekend
Argyn
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2003 7:20 PM
To: [EMAIL PROTECTED]
Subject: Re: Open Source Reference Book 2003
Argyn wrote:
Hello folks!
Dear developers,
the Chiba project has released the first version of the Chiba/Cocoon
(Chicoon) integration package. By integrating Chiba into Cocoon the
power and functionality of Chiba's XForms processing is now available to
any Cocoon application. The set of special connectors in Chicoon
Title: RE: AbstractMethodError: org/apache/excalibur/event/impl/AbstractQueue.enqueue
Did anybody ever figure out this problem? I seem to be experiencing it as well.
I am running a tomcat application server version 4.1.24 on a freebsd server.
I just compiled a fresh snapshot of the cvs
In response to the multiple messages in the recent days about using commons
validator,
I am currently studying hard JavaServer Faces EA3.
I will be looking to incorporate the JFC model into XMLForm without the JSP
taglib part.
Any comments in this direction are welcome.
-=Ivelin=-
-
Sam Ruby wrote:
Even if this were corrected, however, I do see a jar in the
avalon-excalibur/compatibility/build/lib directory. What's odd is that
it was built this morning, but has yesterday's date on it. This I can't
explain either.
Solved this problem. Something is misconfigured on
The code in the attached zip contains a wrapper around the Commons
Validator for XMLForm using JXPath. (Schematron is still supported)
The Example org.apache.cocoon.acting.XMLFormAction class shows how it
can be integrated and looks for 2 additional parameters in the form
action,
i.e.
This part of the JSF is encouraging:
While JavaServer Faces technology includes a JSP custom tag library for
representing components on a JSP page, the JavaServer Faces technology APIs
are layered directly on top of the JavaServlet API. This allows you to do a
few things: to use another
Quite interesting. It's always great to offer better selection to users.
Can you summarize what is the advantage of the commons validator vs
Schematron?
Their expressive power seems identical.
The syntax is obviously different.
-=Ivelin=-
- Original Message -
From: Stephen Burns [EMAIL
Le Mercredi, 2 avr 2003, à 20:25 Europe/Zurich, Stefano Mazzocchi a
écrit :
snips cause=commenting on some specifics only/
...IMHO, the template language which is closer to the optimum is XSLT
but only with one change:
FORGET THE XML SYNTAX!
+1
This is happening to some extent with the wiki
Le Mercredi, 2 avr 2003, à 21:22 Europe/Zurich, Steven Noels a écrit :
...Who needs braces when you've got spaces! ;-)
hehe - I see that my Whitespace proposal is bearing some fruit ;-)
-Bertrand
We have found the Commons Validator is more easily customized than
Schematron and it's more familiar to Struts users. (Can add new methods
to the JXPathValidator)
Also its easier to provide i18n, i.e don't need any extra transforms in
the sitemap, and don't need the i18n tags everywhere.
Stephen
On Wed, Apr 02, 2003 at 08:25:49PM +0200, Stefano Mazzocchi wrote:
snip interesting stuff
IMHO, the template language which is closer to the optimum is XSLT but
only with one change:
...
then we can have the following templatesheet:
namespace (ns) {
http://whatever;
}
template (/) {
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
FORGET THE XML SYNTAX!
I agree. The optimum is Lisp.
http://ssax.sourceforge.net/
On 3/04/2003 8:52 Jeff Turner wrote:
Pity about losing the declarative processing model.
Cannot agree more. Declarative is great SoC.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at
fyi
Original Message
Subject: [ANNOUNCEMENT] Sirvisetti AppTalk Server 3.1.0 using Cocoon 2.0.4
Date: Wed, 2 Apr 2003 17:51:59 -0500 (EST)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Hi all,
Sirvisetti Systems is very happy to
Just thought y'all (as in both developers and users, hence the
cross-posting) might like to hear: Last week, I taught a 90-minute
session on Cocoon at the Software Development West conference in Santa
Clara.
It was pretty well received, according to the eval forms I peeked at.
But it was at the
89 matches
Mail list logo
