You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Claude Warren <cl...@histio.org> on 2001/04/08 17:31:35 UTC
4 New Classes
I have written 2 new classes.
AggregatingProducer - used to aggregate static (or infrequently chaning)
XML pages into a single page. This is handy if you have documents that
are combined with infrastructure elements to create standard pages which
contain a mixture of static and active (current time for example)
elements. Conceptually it is like a "make" for xml pages. I use this
on a site that should be public soon to combine documents created by a
content editor with elements to create a standard display. The
resulting XML document is stored on disk for quick retrieval later.
This producer works correctly in front of the XSP classes.
HAUtilProcessor - a class that uses a plug in paradigm to provide an
extensible processor. I have uses this to develop a system specific time
class <hautil:time>, an include class <hautil:include> that works with
the AggregatingProducer, a navigation class <hautil:navigation> to
produce an active navigation panel, a backlinks class <hautil:backlinks>
to create a series of links to directories up the document tree,
parameter <hautil:parameter> and header <hautil:header> classes to
retrieve parameters and headers from the servlet request.
HAFormProcessor - a class that processes <haform:> tags to create online
forms. The result of the post operation is a document that has a
structure based on the structure and names of the <haform> elements in
the original document. The processor has the ability to hide data from
the form (not on the form at all) but include those data on the document
that results from the post operation.
HAFormMail - a class that provides a mechanism to mail documents via
javamail. I use this along with the HAFormProcessor to allow users to
contact people on the site without publishing the email addresses of the
contact people, thus helping to keep the contacts out of SPAM lists.
Some of these classes require several other supporting classes. If you
are interested please drop me a line and I'll send a copy of the jar
files to you.
I hope to have the code and documentation available on www.histio.org
sometime soon. In addition, the site that uses these classes will be
available at www.histio.org/society in the near future. I will have it
added to the list of active cocoon sites when it is available to the
general public
--
email: claude@histio.org
Fax +1 801 601 3586
Voice Message +1 801 601 3586
Re: 4 New Classes
Posted by Ulrich Mayring <ul...@denic.de>.
"Piroumian, Konstantin" wrote:
>
> > I think Schema validation is enough for most cases. If you require more,
> > you can use any of a number of plug-in architectures, like Schema
> > Adjuncts or so.
>
> I am not familiar with it, is that a part of XML Schema specification?
There are various efforts underway, I don't know about their status. I
just happened to hear about Schema Adjuncts on XML DevCon 2001.
> > Another reason why I don't like XForms - it doesn't play well with
> > existing standards.
>
> Standarts of what?
XML, XML-Schema, XSL(T) - these specs are written very differently from
XForms. XForms doesn't say how to integrate it with other XML-standards,
it uses a mythical XFormsProcessor to do all the hard work. An example:
if we take for granted that XML-Schema will live, then anyone writing a
validator should at first support XML-Schema. Then, if he needs more
validation, he can expand on it - but first use the existing standards,
don't always invent new ones.
> I don't quite understand what do they mean by processor - what is the
> purpose of it and how it will work.
They basically define what an XFormsProcessor should do, much like XSLT
defines what an XSLT processor should do. But XForms shouldn't need its
own processor, it should make use of the other standards. For
transformation it should use XSLT, for example.
> As I understand, XForms are closer to
> XHTML forms and supposed to replace them in browsers.
There's no browser that I know of, that supports XForms. I know of no
plans either.
> But I like ideas that
> they used to separate presentation and data. I treat XForms as a unified
> form description meta-language. I think that everybody in web development
> deals with forms and everybody has his own meta-language, so why don't use a
> standart?
Yes, I don't keep anyone from using it, but I will wait for something
better. Forms alone are pretty senseless, they will always be integrated
in some kind of workflow. So I'll wait for a workflow standard and if
that standard uses XForms internally for form handling, then I don't
care. But XForms itself doesn't help me, it doesn't bring anything new
to the table.
> Yes. I think that Cocoon 2 is the best tool for web application
> implementation and form handling, but anyway you'll need some special
> taglibs or so to describe your forms.
And your application, and your workflow and your data model and your
validation ... :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> >
> > The Schema validation is not enough for real use. There is no dependency
> > checks, constraints (like readonly) and some other things that are
essential
> > in commercial products. I think, that must be possibility to use a
special
> > class for validation, e.g.: <form
> > validator="com.some.company.ValidateCustomerData" />.
>
> I think Schema validation is enough for most cases. If you require more,
> you can use any of a number of plug-in architectures, like Schema
> Adjuncts or so.
I am not familiar with it, is that a part of XML Schema specification?
>
> > XForms goes far than XML-Schema for the data model representation.
>
> Another reason why I don't like XForms - it doesn't play well with
> existing standards.
Standarts of what?
> > As I said
> > before the XML Schema is not enough for it. Also, XForms have a good
> > extendable UI description mechanism and it is quite enough in most
cases.
>
> On one hand XForms says, they merely provide (yet another) meta-layer
> for UI description. On the other hand they make restrictions on
> implementations, e.g. it requires its own processor, so can't be
> integrated well into, say, Cocoon. XForms is IMHO not very elegant.
I don't quite understand what do they mean by processor - what is the
purpose of it and how it will work. As I understand, XForms are closer to
XHTML forms and supposed to replace them in browsers. But I like ideas that
they used to separate presentation and data. I treat XForms as a unified
form description meta-language. I think that everybody in web development
deals with forms and everybody has his own meta-language, so why don't use a
standart?
>
> > What it does not address is the workflow and application
representations.
> > But it is not the XForms purpose.
>
> I don't need XForms to handle forms well. I can do it with Cocoon very
> well or even use this Forms Processor, we've been talking about.
Yes. I think that Cocoon 2 is the best tool for web application
implementation and form handling, but anyway you'll need some special
taglibs or so to describe your forms.
> > One thing is bad with XForms - it has no implementations (or maybe I
don't
> > know?).
>
> Exactly.
>
> > I don't like SchemoX in its current state - it's too complicated to use
and
> > requires a lot of programming while several things could be done
> > declaratively. But they have workflows and application. And they have a
> > working implementation.
>
> Working more or less :-)
Kot.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by Ulrich Mayring <ul...@denic.de>.
"Piroumian, Konstantin" wrote:
>
> The Schema validation is not enough for real use. There is no dependency
> checks, constraints (like readonly) and some other things that are essential
> in commercial products. I think, that must be possibility to use a special
> class for validation, e.g.: <form
> validator="com.some.company.ValidateCustomerData" />.
I think Schema validation is enough for most cases. If you require more,
you can use any of a number of plug-in architectures, like Schema
Adjuncts or so.
> XForms goes far than XML-Schema for the data model representation.
Another reason why I don't like XForms - it doesn't play well with
existing standards.
> As I said
> before the XML Schema is not enough for it. Also, XForms have a good
> extendable UI description mechanism and it is quite enough in most cases.
On one hand XForms says, they merely provide (yet another) meta-layer
for UI description. On the other hand they make restrictions on
implementations, e.g. it requires its own processor, so can't be
integrated well into, say, Cocoon. XForms is IMHO not very elegant.
> What it does not address is the workflow and application representations.
> But it is not the XForms purpose.
I don't need XForms to handle forms well. I can do it with Cocoon very
well or even use this Forms Processor, we've been talking about.
> One thing is bad with XForms - it has no implementations (or maybe I don't
> know?).
Exactly.
> I don't like SchemoX in its current state - it's too complicated to use and
> requires a lot of programming while several things could be done
> declaratively. But they have workflows and application. And they have a
> working implementation.
Working more or less :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: [C2] Sitemap views and resources
Posted by Giacomo Pati <gi...@apache.org>.
Quoting "Piroumian, Konstantin" <KP...@flagship.ru>:
> Hi!
>
> Can anybody tell me what is the purpose of map:view and map:resource in
> the
> sitemap or give some links to documentation?
You can find information about view and resources in the
xdocs/drafts/sitemap-working-draft.xmap as well as in the mail archives.
One I've found with a quick search is
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=96942812802803&w=2
You'll find other mails concerning views and resource if you search in the marc
archives but you have to go back in time until last spring/summer/fall
Giacomo
>
> Thank you.
>
> Regards,
> Konstantin Piroumian.
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
[C2] Sitemap views and resources
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi!
Can anybody tell me what is the purpose of map:view and map:resource in the
sitemap or give some links to documentation?
Thank you.
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Form processing (was: 4 New Classes)
Posted by Ulrich Mayring <ul...@denic.de>.
"Piroumian, Konstantin" wrote:
>
> I am not sure that anybody will give up his own work and work on a common
> framework for form handling, but it would be useful to work in collaboration
I'll be happy to provide anything I have and also work on a new and
better thing. But it must be compatible with Cocoon1, otherwise I can't
be useful.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Form processing (was: 4 New Classes)
Posted by Giacomo Pati <gi...@apache.org>.
Note there is a project started at sourceforge called exformula which tries to
implement XForms based on C2. Maybe you are interested in a collaboration.
Giacomo
Quoting Elmar Christen <el...@elmartec.de>:
> AGREEEEE!!! I am working on a way to implement (a light version) of
> XForms. Up to now, it fits my needs, but there is so much more to do -
> and my solution is kind-of propietary, not 100% w3c. I think a XForms
> processor for C2 would be a nice idea...but first: w3c should straigthen
>
> out their working draft.
>
> Piroumian, Konstantin wrote:
>
> > Hi all!
> >
> > The question about form processing raises from time to time and as I
> see
> > everybody has his own solution which is more or less fits his needs,
> but
> > generally, everybody do same things, such as: form generation, data
> > validation, data processing (mapping to internal structures, error
> > handling), etc...
> >
> > I am not sure that anybody will give up his own work and work on a
> common
> > framework for form handling, but it would be useful to work in
> collaboration
> > and come to some standart way of form description meta-language (maybe
> use
> > XForms syntax or SchemoX or something else), workflow framework (maybe
> only
> > for C2, based on actions), provide some samples of usage, develope
> common
> > validation mechanisms (client-side, data format, business, etc.) and
> > develope frameworks for other common tasks.
> >
> > Even sharing ideas can make somebody's life easier.
> >
> > Are there any opinions?
> >
> > Regards,
> > Konstantin Piroumian.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
[C1.8.2] Application level object init
Posted by Tony <to...@employer.com.br>.
Hi.
Sorry if this is silly, but is there an ASP global.asa equivalent in Cocoon
with its Application_OnStart and Session_Onstart events ?
I know cocoon XSP provides a wrapped servletContext and session object, but
i don't know where to assign my application/session level object to them.
Let's say I've got a object that should be created every time a new session
is created.
How do I do that ?
Without a Global.asa equivalent, I imagine we have to do it using
logicsheets...
Thanks for you time.
Tony.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Form processing (was: 4 New Classes)
Posted by Elmar Christen <el...@elmartec.de>.
AGREEEEE!!! I am working on a way to implement (a light version) of
XForms. Up to now, it fits my needs, but there is so much more to do -
and my solution is kind-of propietary, not 100% w3c. I think a XForms
processor for C2 would be a nice idea...but first: w3c should straigthen
out their working draft.
Piroumian, Konstantin wrote:
> Hi all!
>
> The question about form processing raises from time to time and as I see
> everybody has his own solution which is more or less fits his needs, but
> generally, everybody do same things, such as: form generation, data
> validation, data processing (mapping to internal structures, error
> handling), etc...
>
> I am not sure that anybody will give up his own work and work on a common
> framework for form handling, but it would be useful to work in collaboration
> and come to some standart way of form description meta-language (maybe use
> XForms syntax or SchemoX or something else), workflow framework (maybe only
> for C2, based on actions), provide some samples of usage, develope common
> validation mechanisms (client-side, data format, business, etc.) and
> develope frameworks for other common tasks.
>
> Even sharing ideas can make somebody's life easier.
>
> Are there any opinions?
>
> Regards,
> Konstantin Piroumian.
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Form processing (was: 4 New Classes)
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi all!
The question about form processing raises from time to time and as I see
everybody has his own solution which is more or less fits his needs, but
generally, everybody do same things, such as: form generation, data
validation, data processing (mapping to internal structures, error
handling), etc...
I am not sure that anybody will give up his own work and work on a common
framework for form handling, but it would be useful to work in collaboration
and come to some standart way of form description meta-language (maybe use
XForms syntax or SchemoX or something else), workflow framework (maybe only
for C2, based on actions), provide some samples of usage, develope common
validation mechanisms (client-side, data format, business, etc.) and
develope frameworks for other common tasks.
Even sharing ideas can make somebody's life easier.
Are there any opinions?
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> > The HAFormProcessor has to be able to completely replace the output
> > document.
>
> Why that?
>
> > I could not find a way to do that and to navigate the
> > entire input document at the same time.
>
> <form>
> <hidden> ... </hidden>
> <inputfield> ... </inputfield>
> </form>
>
> Then transform that in XSLT to produce HTML forms.
>
> > on the POST each field is validates. user_name must have a value, and
> > the user_email if it has a value must pass the "email" validation.
> > Once that is done the following document would be produced:
>
> What is the validation based on? XML-Schema?
The Schema validation is not enough for real use. There is no dependency
checks, constraints (like readonly) and some other things that are essential
in commercial products. I think, that must be possibility to use a special
class for validation, e.g.: <form
validator="com.some.company.ValidateCustomerData" />.
>From the other point of view, a Schema can be used to generate code (in
JavaScript) for client-side validation: data format checks (date, email,
string, integer).
>
> > <haform:root>
> > <user_name>What ever the user entered</user_name>
> > <user_email>The user email as entered</user_email>
> > </haform:root>
> >
> > The haform:root could be renamed to something else using the
> > haform:name attribute. In addition processing instructions can be
> > added to the resulting document.
> >
> > If the form fails the validation the original document is modified to
> > add haform:error attributes that describe the error and text nodes are
> > added that contain the input values from the POST.
>
> I think this forms stuff is very important and I've been thinking about
> it for a long time. What you did as a solution is hard-code the
> functionality that you need into a processor. It would be better to have
> it in an XSP taglib, because then it would be easier to extend it (and
> port it to Cocoon2). Your functionality sounds pretty cool, but it is
> IMHO far from complete. But putting this stuff in an XSP taglib is only
> a better solution, not a good solution, which is why I have never
> produced such a taglib. Even though I have very complicated workflows
> and forms to support, but doing it manually is still easier to manage
> than a half-baked packaged solution.
> What we really need is XML-Schema support for the data model and
> validation and some kind of model to represent workflows, UIs and
> perhaps applications. The current XForms W3C proposal doesn't address
> this. Cocoon2 tries to provide some answers, but when the going gets
> tough it makes everything proprietary (sitemap, flowmap(?), linkmap(?)).
XForms goes far than XML-Schema for the data model representation. As I said
before the XML Schema is not enough for it. Also, XForms have a good
extendable UI description mechanism and it is quite enough in most cases.
What it does not address is the workflow and application representations.
But it is not the XForms purpose.
One thing is bad with XForms - it has no implementations (or maybe I don't
know?).
>
> Every time this discussion comes up I mention Schemox, these guys are
> doing the right thing in spirit. In practice I think their
> implementation is (at this point) too complicated to use, but I'm sure
> that, given some time, this will be a great product.
I don't like SchemoX in its current state - it's too complicated to use and
requires a lot of programming while several things could be done
declaratively. But they have workflows and application. And they have a
working implementation.
Best regards,
Konstantin Piroumian
Software engineer
Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: kpiroumian@flagship.ru
http://www.protek.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by Ulrich Mayring <ul...@denic.de>.
Claude Warren wrote:
>
> changed but would still be produced quickly. The result is the
> AggregatingProducer. It is intended to aggregate several sources of
> nearly static content and save the aggregated document so that it can
> be quickly produced for the remaining processing.
In what form is the aggregated document saved?
> The HAFormProcessor has to be able to completely replace the output
> document.
Why that?
> I could not find a way to do that and to navigate the
> entire input document at the same time.
<form>
<hidden> ... </hidden>
<inputfield> ... </inputfield>
</form>
Then transform that in XSLT to produce HTML forms.
> on the POST each field is validates. user_name must have a value, and
> the user_email if it has a value must pass the "email" validation.
> Once that is done the following document would be produced:
What is the validation based on? XML-Schema?
> <haform:root>
> <user_name>What ever the user entered</user_name>
> <user_email>The user email as entered</user_email>
> </haform:root>
>
> The haform:root could be renamed to something else using the
> haform:name attribute. In addition processing instructions can be
> added to the resulting document.
>
> If the form fails the validation the original document is modified to
> add haform:error attributes that describe the error and text nodes are
> added that contain the input values from the POST.
I think this forms stuff is very important and I've been thinking about
it for a long time. What you did as a solution is hard-code the
functionality that you need into a processor. It would be better to have
it in an XSP taglib, because then it would be easier to extend it (and
port it to Cocoon2). Your functionality sounds pretty cool, but it is
IMHO far from complete. But putting this stuff in an XSP taglib is only
a better solution, not a good solution, which is why I have never
produced such a taglib. Even though I have very complicated workflows
and forms to support, but doing it manually is still easier to manage
than a half-baked packaged solution.
What we really need is XML-Schema support for the data model and
validation and some kind of model to represent workflows, UIs and
perhaps applications. The current XForms W3C proposal doesn't address
this. Cocoon2 tries to provide some answers, but when the going gets
tough it makes everything proprietary (sitemap, flowmap(?), linkmap(?)).
Every time this discussion comes up I mention Schemox, these guys are
doing the right thing in spirit. In practice I think their
implementation is (at this point) too complicated to use, but I'm sure
that, given some time, this will be a great product.
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by Ulrich Mayring <ul...@denic.de>.
Claude Warren wrote:
>
> I have written 2 new classes.
>
> AggregatingProducer - used to aggregate static (or infrequently chaning)
> XML pages into a single page. This is handy if you have documents that
> are combined with infrastructure elements to create standard pages which
> contain a mixture of static and active (current time for example)
> elements. Conceptually it is like a "make" for xml pages. I use this
> on a site that should be public soon to combine documents created by a
> content editor with elements to create a standard display. The
> resulting XML document is stored on disk for quick retrieval later.
> This producer works correctly in front of the XSP classes.
Does it pick up changes to the source XML files automatically? What is
the advantage of using a producer instead of doing it all in XSP?
> HAUtilProcessor - a class that uses a plug in paradigm to provide an
> extensible processor. I have uses this to develop a system specific time
> class <hautil:time>, an include class <hautil:include> that works with
> the AggregatingProducer, a navigation class <hautil:navigation> to
> produce an active navigation panel, a backlinks class <hautil:backlinks>
> to create a series of links to directories up the document tree,
> parameter <hautil:parameter> and header <hautil:header> classes to
> retrieve parameters and headers from the servlet request.
Shouldn't this be an XSP taglib, too? Why a processor?
> HAFormProcessor - a class that processes <haform:> tags to create online
> forms. The result of the post operation is a document that has a
> structure based on the structure and names of the <haform> elements in
> the original document. The processor has the ability to hide data from
> the form (not on the form at all) but include those data on the document
> that results from the post operation.
Interesting, I'll look at it. However, IMHO it should also be an XSP
taglib, so XSP features can be used within it.
> I hope to have the code and documentation available on www.histio.org
> sometime soon.
Cool, tell us when the docs and samples are ready.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: 4 New Classes
Posted by Claude Warren <cl...@histio.org>.
Sorry, I should have specified that in the subject line. Cocoon1.
Uli Mayring wrote:
> On Sun, 8 Apr 2001, Claude Warren wrote:
>
> > I have written 2 new classes.
>
> Is this for cocoon1 or cocoon2?
>
> Ulrich
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
--
email: claude@histio.org
Fax +1 801 601 3586
Voice Message +1 801 601 3586
Re: 4 New Classes
Posted by Uli Mayring <ul...@denic.de>.
On Sun, 8 Apr 2001, Claude Warren wrote:
> I have written 2 new classes.
Is this for cocoon1 or cocoon2?
Ulrich
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>