Re: Google Summer of Code - projects and mentors wanted
Sylvain Wallez wrote:
Don't want to rain on the party, but this is *summer* of code, meaning 2
months of work[2]. Expecting students to implement difficult things
(e.g. continuations serialization)
After skim reading the project proposals of other Apache projects and the other
OS projects I disagree that the level of continuations serialization and the
attribute based template engine is too high. 2 months of work means (at least in
Austria) 640 hours work time which is a lot. Of course, if you have to learn
Java first, the time won't be enough. And don't forget, IIRC it was a student
who founded our beloved Cocoon ;-)
From my personal experience over the last years I'm sure that there are many
clever students out there who are definitly able to implement the difficult
topics like Rhino scope and continuations serialization but they haven't had the
itch to scratch. $4500 could change their minds ;-).
And not to forget, continuation serialization in particular, is probably more a
Rhino topic than Cocoon topic. If the students get the serialization of Rhino
scopes and continuations working, we can tackle *together* the very
Cocoon-specific topics like Avalon components and the service manager.
In the worst case nobody will apply for the topic which would mean that sooner
or later we will have to do it ourselves ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Le 3 juin 05, à 08:26, Reinhard Poetz a écrit : ...From my personal experience over the last years I'm sure that there are many clever students out there who are definitly able to implement the difficult topics like Rhino scope and continuations serialization but they haven't had the itch to scratch. $4500 could change their minds ;-)... Agreed, and by selecting 200 students out of all those who apply (I guess there will be much more than 200 applications) means only the best ones will be selected. But the burden will be on us to evaluate whether the applying student has what it takes - like we'd do for an internship I guess. -Bertrand smime.p7s Description: S/MIME cryptographic signature
ValidationAware forms
AFAICS the widget Form doesn't implement ValidationAware. Is there a special
reason why this feature hasn't been added yet?
I was asked this in some of my trainings and IIRC there have been some questions
on [EMAIL PROTECTED] My usual answer is adding an error widget that can contain
the error. Is this our 'official' recommendation or are there better ways to
achieve this?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Why does XSPMarkupLanguage wrap text in xsp:text?
Hi, I'm currently working on apatch for attribute value interpolation in
XSP [1]. I noticed that XSPMarkupLanguage.characters wraps text in
xsp:text elements. Is there a reason for this? At least my XSPs work
without this...
public void characters(char[] ch, int start, int length) throws
SAXException {
String[] tag = (String[]) stack.peek();
String tagURI = tag[0];
String tagLName = tag[1];
boolean flag = XSPMarkupLanguage.this.getURI().equals(tagURI);
if (flag tagLName.equals(page)) {
// Characters after xsp:page and before first element.
super.characters(ch, start, length);
} else if (flag (tagLName.equals(expr) ||
tagLName.equals(logic) ||
tagLName.equals(structure) ||
tagLName.equals(include))) {
super.characters(ch, start, length);
} else {
// Quote the string depending on the programming language
String value = String.valueOf(ch, start, length);
// Create a new element xsp:text that wrap the quoted
PCDATA
super.startElement(XSPMarkupLanguage.this.getURI(),
text,
localPrefix + :text, XMLUtils.EMPTY_ATTRIBUTES);
// =^ Why is this done?
super.characters(value.toCharArray(), 0, value.length());
super.endElement(XSPMarkupLanguage.this.getURI(), text,
localPrefix + :text);
}
}
Regards,
Jochen
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111693513631888w=2
cocoon-cforms-library
Dear Sir, I'm very much intrested in working for apache. I was thinking a lot about the project on which I could work on but nothing good came to my mind. The project which I liked the most among the projects given by you is cocoon-cforms-library. At present I'm pursuing my B.Tech from IIT Bombay, India. Though my department is material science, but i have a lot of interests in coding networking. As far as my previous works ar concerned, I've worked on devlopment of Proxy Server in java (platform independent) as a summer project, under an ISP company in Jaipur, India. Also I'm doing a project on computaional modeling of forging process using vc++, at cemef (Ecole des Mine de Paris, France) as my summer internship project. Please see few other projects also, which I've worked on in my resume at : http://homepages.iitb.ac.in/~vishal_nagota/Vishal_Nagota_resume.htm It would be great of you if you could let me know wether I should apply for the project or not. And what are my chances to get the project. Thanking You in Anticipation. Yours Sincerely, Vishal Nagota 3rd Yr, B.tech IIT Bombay
RE: ValidationAware forms
-Oorspronkelijk bericht-
Van: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 3 juni 2005 9:46
Aan: dev@cocoon.apache.org
Onderwerp: ValidationAware forms
AFAICS the widget Form doesn't implement ValidationAware. Is there a
special
reason why this feature hasn't been added yet?
I'm not sure, but I think it is because a form doesn't have a visual
representation in HTML, where other widgets do have a visual representation.
Where should CForms place the error marker (the red !) for a form?
I agree that it will be helpful to have this feature. And I think that
repeaters are a similar case (aren't ValidationErrorAware either, but I have
cases here where I want it to hold an error instead of creating a messages
widget).
I was asked this in some of my trainings and IIRC there have been some
questions
on [EMAIL PROTECTED] My usual answer is adding an error widget that can
contain
the error. Is this our 'official' recommendation or are there better ways
to
achieve this?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: cocoon-cforms-library
Vishal Nagota wrote:
Dear Sir,
I'm very much intrested in working for apache. I was thinking a lot
about the project on which I could work on but nothing good came to my
mind. The project which I liked the most among the projects given by
you is cocoon-cforms-library.
At present I'm pursuing my B.Tech from IIT Bombay, India. Though my
department is material science, but i have a lot of interests in
coding networking.
As far as my previous works ar concerned, I've worked on devlopment
of Proxy Server in java (platform independent) as a summer project,
under an ISP company in Jaipur, India.
Also I'm doing a project on computaional modeling of forging process
using vc++, at cemef (Ecole des Mine de Paris, France) as my summer
internship project. Please see few other projects also, which I've
worked on in my resume at :
http://homepages.iitb.ac.in/~vishal_nagota/Vishal_Nagota_resume.htm
It would be great of you if you could let me know wether I should
apply for the project or not. And what are my chances to get the
project.
Thanking You in Anticipation.
Many thanks for your application! I (we) don't know if *you* should apply for
the project or not. It mainly depends if you feel yourself able to implement the
features desribed at http://wiki.apache.org/cocoon/CocoonFormsScratchpad.
Please have a look at the proposal and the Cocoon Forms block and give us a
short summary about
* your experiences with Cocoon (if you don't have any, describe your first
impressions)
* how you want to tackle the 'cocoon-cforms-library'-project
* what are the crucial points of the 'cocoon-cforms-library'-project
in your opinion
If you don't want to publish your summary so that it can be read by your
competitors you can send it directly to me - I will ensure that the other Cocoon
committers will get it.
If you have some questions (I'm sure that you will have some in order to write
the summary ;-) ) feel free to ask on dev@cocoon.apache.org - please don't send
them to me directly.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: cocoon-cforms-library
Reinhard Poetz wrote: Vishal Nagota wrote: Dear Sir, I'm very much intrested in working for apache. I was thinking a lot about the project on which I could work on but nothing good came to my mind. The project which I liked the most among the projects given by you is cocoon-cforms-library. At present I'm pursuing my B.Tech from IIT Bombay, India. Though my department is material science, but i have a lot of interests in coding networking. As far as my previous works ar concerned, I've worked on devlopment of Proxy Server in java (platform independent) as a summer project, under an ISP company in Jaipur, India. Also I'm doing a project on computaional modeling of forging process using vc++, at cemef (Ecole des Mine de Paris, France) as my summer internship project. Please see few other projects also, which I've worked on in my resume at : http://homepages.iitb.ac.in/~vishal_nagota/Vishal_Nagota_resume.htm It would be great of you if you could let me know wether I should apply for the project or not. And what are my chances to get the project. Thanking You in Anticipation. Many thanks for your application! I (we) don't know if *you* should apply for the project or not. It mainly depends if you feel yourself able to implement the features desribed at http://wiki.apache.org/cocoon/CocoonFormsScratchpad. Please have a look at the proposal and the Cocoon Forms block and give us a short summary about * your experiences with Cocoon (if you don't have any, describe your first impressions) * how you want to tackle the 'cocoon-cforms-library'-project * what are the crucial points of the 'cocoon-cforms-library'-project in your opinion If you don't want to publish your summary so that it can be read by your competitors you can send it directly to me - I will ensure that the other Cocoon committers will get it. If you have some questions (I'm sure that you will have some in order to write the summary ;-) ) feel free to ask on dev@cocoon.apache.org - please don't send them to me directly. There is a list of what to do: --- If you would like to create a proposal for any of the above then we need to follow the following process: - student gains an overview understanding of the technologies involved in the proposal - student expands the initial project outline to a draft proposal text: - description of problem - description of a proposed solution - benefits of the solution to the Apache community - an approach - milestones in delivery - expected time line for delivery - description of relevant students skills - student and mentors work together to finalise this proposal - proposal is submitted to project community for comment/approval - student registers the proposal with Google via their website The deadline for the proposal is June 14th and the refinement of the draft proposal will probably take more than a week. So there is no time to spare. I look forward to receiving your initial *draft* proposal. I stress draft as you should not feel pressured by this it is only a starting point for our discussions. Do not waste time trying to make it perfect, that will happen as we discuss, it is more important that you show how much of the project you already understand so that we know where to start discussing. --- that have been used at Forrest: http://mail-archives.apache.org/mod_mbox/forrest-dev/200506.mbox/[EMAIL PROTECTED] and Lenya, I don't know what it origins from, it seem reasonable anyway. Considering the summary, my personal opinion is that all discussions should take place open at the list. That makes it possible to get some idea abut the applicants ability to take part in our development process and our community culture. I recognize that this possibly can be a problem in relation to the competition aspect of Summer of Code, but that is IMO not our problem. We shouldn't let any external funding affect our community values. /Daniel
Re: cocoon-cforms-library
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Vishal Nagota wrote:
Dear Sir,
I'm very much intrested in working for apache. I was thinking a lot
about the project on which I could work on but nothing good came to my
mind. The project which I liked the most among the projects given by
you is cocoon-cforms-library.
At present I'm pursuing my B.Tech from IIT Bombay, India. Though my
department is material science, but i have a lot of interests in
coding networking.
As far as my previous works ar concerned, I've worked on devlopment
of Proxy Server in java (platform independent) as a summer project,
under an ISP company in Jaipur, India.
Also I'm doing a project on computaional modeling of forging process
using vc++, at cemef (Ecole des Mine de Paris, France) as my summer
internship project. Please see few other projects also, which I've
worked on in my resume at :
http://homepages.iitb.ac.in/~vishal_nagota/Vishal_Nagota_resume.htm
It would be great of you if you could let me know wether I should
apply for the project or not. And what are my chances to get the
project.
Thanking You in Anticipation.
Many thanks for your application! I (we) don't know if *you* should
apply for the project or not. It mainly depends if you feel yourself
able to implement the features desribed at
http://wiki.apache.org/cocoon/CocoonFormsScratchpad.
Please have a look at the proposal and the Cocoon Forms block and give
us a short summary about
* your experiences with Cocoon (if you don't have any, describe your
first
impressions)
* how you want to tackle the 'cocoon-cforms-library'-project
* what are the crucial points of the 'cocoon-cforms-library'-project
in your opinion
If you don't want to publish your summary so that it can be read by
your competitors you can send it directly to me - I will ensure that
the other Cocoon committers will get it.
If you have some questions (I'm sure that you will have some in order
to write the summary ;-) ) feel free to ask on dev@cocoon.apache.org -
please don't send them to me directly.
There is a list of what to do:
---
If you would like to create a proposal for any of the above then we need
to follow the following process:
- student gains an overview understanding of the technologies involved
in the proposal
- student expands the initial project outline to a draft proposal text:
- description of problem
- description of a proposed solution
- benefits of the solution to the Apache community
- an approach
- milestones in delivery
- expected time line for delivery
- description of relevant students skills
- student and mentors work together to finalise this proposal
- proposal is submitted to project community for comment/approval
- student registers the proposal with Google via their website
The deadline for the proposal is June 14th and the refinement of the
draft proposal will probably take more than a week. So there is no time
to spare.
I look forward to receiving your initial *draft* proposal. I stress
draft as you should not feel pressured by this it is only a starting
point for our discussions. Do not waste time trying to make it perfect,
that will happen as we discuss, it is more important that you show how
much of the project you already understand so that we know where to
start discussing.
thanks for the clarification Daniel! (I read the Google pages yesterday but
forgot about them when I wrote the mail ...)
---
that have been used at Forrest:
http://mail-archives.apache.org/mod_mbox/forrest-dev/200506.mbox/[EMAIL PROTECTED]
and Lenya, I don't know what it origins from, it seem reasonable anyway.
Considering the summary, my personal opinion is that all discussions
should take place open at the list. That makes it possible to get some
idea abut the applicants ability to take part in our development process
and our community culture. I recognize that this possibly can be a
problem in relation to the competition aspect of Summer of Code, but
that is IMO not our problem. We shouldn't let any external funding
affect our community values.
yes right, hereby I withdraw my former idea of working offlist on the project
proposal.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
On Thu, Jun 02, 2005 at 02:08:13PM +0200, Reinhard Poetz wrote: Leszek Gawron wrote: 1. we still have not touched the subject of attribute driven template language. it would nicely suit as a project that could be finished till the end of summer. 2. cforms reusable widget repository... yes, I like both ideas! Who wants to mentor the projects? Tim, Leszek? While I would like to, I will not have enough time to be an offical mentor, due to buying a house and moving into it during this same timespan. However, I will gladly help unoffically with whatever time I end up having. About the reusable widget repository...there is already working code in whiteboard/forms, just needs to be reviewed to see what changes we may want and then updated to sync with svn trunk head. --Tim Larson
[Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Hi everyone, Starting at the very beginning... I am reviewing the introduction on the Cocoon home page: http://cocoon.apache.org/ (The Apache Cocoon section). I've added mention of flow, templating and the forms framework, and tried to increase the emphasis on Cocoon's suitability for web applications (not just publishing). Possibly contentiously, I've taken out the references to lego(TM) and glue. What do you think of: ++ What is Apache Cocoon? Apache Cocoon is an MVC web application framework uniquely suited to XML publishing. Apache Cocoon is founded on the principle of separation of concerns. Cocoon's Avalon-based component architecture makes it easy to create web applications from reusable components. You use the Cocoon Sitemap to assemble components into pipelines. Pipelines react to client requests, generating information from a source, transforming it, before serializing it back to the client in the desired format. This separation of concerns between generation, transformation and serialization, allows the same source to be served up to your browser, cellular phone or printer, or to be consumed by your web service. In addition to this mature publishing framework, Apache Cocoon offers features and frameworks to help you build full-featured web applications. Cocoon Flow offers continuation-based scripting for your application business logic. Cocoon Templates offer dynamic XML generation. The Cocoon Forms framework greatly simplifies client interaction with a growing library of user interface widgets for your web application forms. ++ I've embedded links to wikipedia definitions for MVC and SoC, visible at http://www.planetcocoon.com/node/2155. My company will pay me to do another four weeks of full time work reviewing Cocoon documentation (worth about £6000 I guess - a very good place to start: that's the dough taken care of). My work will include: - Patches to existing documents. - Reorganisation of existing documents. - Revisions of wiki documents. - New documents. In terms of semi-supported, semi-official documentation work I am aware of Helma's efforts at http://cocoondev.org/handbook, Ray was contributing something too, and obviously I am aware of the work Sébastien and Me are doing at http://www.planetcocoon.com. At the moment there seems only sporadic work on the wiki, see http://wiki.apache.org/cocoon/RecentChanges. Who else is writing content? Where? How shall we divide up the work? If you've followed me so Far, then I have another question. What is the best way to have my work reviewed by the community? To test my understanding of the current process: for each revision, I would do one of the following: make a change in the wiki (are these actively reviewed?); send a patch to bugzilla (it'll be a lot of patches; how do I submit reorganisations?); or as with the above, start a discussion on the dev list (I believe the docs list is for change notifications only?). A less time consuming alternative for me would be to Sew it all together at Planet Cocoon, as it is already set up with infrastructure for anyone wishing to join in, tools for workflow, categorisation, document hierarchy management etc. If I were to take that approach, then my work would be continuously visible. Naturally, all my work will be donated back to Cocoon. And then it'll be time for a nice cuppa. Which brings us back to... What do others think? Regards, Mark P.S. this took nearly all morning to write. D'oh!
Re: ValidationAware forms
Bart Molenkamp wrote:
-Oorspronkelijk bericht-
Van: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 3 juni 2005 9:46
Aan: dev@cocoon.apache.org
Onderwerp: ValidationAware forms
AFAICS the widget Form doesn't implement ValidationAware. Is there a special
reason why this feature hasn't been added yet?
I'm not sure, but I think it is because a form doesn't have a visual representation in
HTML, where other widgets do have a visual representation. Where should CForms place the
error marker (the red !) for a form?
That's exactly the reason: only widgets who have a visual representation
can be made validation-aware, as otherwise we don't know how/where to
display the error.
I agree that it will be helpful to have this feature. And I think that
repeaters are a similar case (aren't ValidationErrorAware either, but I have
cases here where I want it to hold an error instead of creating a messages
widget).
The form1 sample has a validator on the contacts repeater, which
checks uniqueness of {firstName,lastName} on the various rows. If a
duplicate is found, the error is set on the offending row as its the
most precise location indicating to the user where the problem is.
Attaching the error to the repeater itself would make finding the
problem more difficult.
The same reasoning can be applied to the form object. Since an error
means the user has to change something, then we'd better indicate
precisely what should be changed. Now in some cases the error can be of
type either change this _or_ change that and that's where the message
widget is usefull.
Hmm...
Now there's also the little-known ft:validation-error template
instruction that outputs the validation error or any given widget. This
can be a good replacement of the message widget, and would allow
non-visual widgets to be ValidationAware.
WDYT?
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Google Summer of Code - projects and mentors wanted
On Fri, Jun 03, 2005 at 02:28:36PM +0100, Tim Larson wrote: About the reusable widget repository...there is already working code in whiteboard/forms, just needs to be reviewed to see what changes we may want and then updated to sync with svn trunk head. I take part of that back...there is a good bit that still could be designed and coded with regard to extension and parameterization. --Tim Larson
RE: ValidationAware forms
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Bart Molenkamp wrote:
I'm not sure, but I think it is because a form doesn't have a visual
representation in HTML, where other widgets do have a visual
representation. Where should CForms place the error marker (the red
!)
for a form?
That's exactly the reason: only widgets who have a visual
representation
can be made validation-aware, as otherwise we don't know how/where to
display the error.
I agree that it will be helpful to have this feature. And I think
that
repeaters are a similar case (aren't ValidationErrorAware either, but
I
have cases here where I want it to hold an error instead of creating a
messages widget).
The form1 sample has a validator on the contacts repeater, which
checks uniqueness of {firstName,lastName} on the various rows. If a
duplicate is found, the error is set on the offending row as its the
most precise location indicating to the user where the problem is.
Attaching the error to the repeater itself would make finding the
problem more difficult.
It would be nice to set an error on the repeater if it has no rows, and
at
least one row is required.
The same reasoning can be applied to the form object. Since an error
means the user has to change something, then we'd better indicate
precisely what should be changed. Now in some cases the error can be
of
type either change this _or_ change that and that's where the
message
widget is usefull.
Hmm...
Now there's also the little-known ft:validation-error template
instruction that outputs the validation error or any given widget.
This
can be a good replacement of the message widget, and would allow
non-visual widgets to be ValidationAware.
WDYT?
So, then all widgets can implement ValidationErrorAware. For most
widgets, the forms-styling.xsl knows how to display the error. For the
other, special
cases we could use ft:validation-error to display the error. Am I
correct
on this?
If so, it seems like a good solution to me.
Bart.
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Mark Leicester wrote: Hi everyone, Starting at the very beginning... I am reviewing the introduction on the Cocoon home page: http://cocoon.apache.org/ (The Apache Cocoon section). I've added mention of flow, templating and the forms framework, and tried to increase the emphasis on Cocoon's suitability for web applications (not just publishing). Possibly contentiously, I've taken out the references to lego(TM) and glue. What do you think of: I've moved that bit to the end, because it seems to come second to me. My company will pay me to do another four weeks of full time work reviewing Cocoon documentation (worth about £6000 I guess - a very good place to start: that's the dough taken care of). My work will include: - Patches to existing documents. - Reorganisation of existing documents. - Revisions of wiki documents. - New documents. Hey, anyone offering time, we'll appreciate it. Time is what the docs really need, for sure. In terms of semi-supported, semi-official documentation work I am aware of Helma's efforts at http://cocoondev.org/handbook, Ray was contributing something too, and obviously I am aware of the work Sébastien and Me are doing at http://www.planetcocoon.com. At the moment there seems only sporadic work on the wiki, see http://wiki.apache.org/cocoon/RecentChanges. Who else is writing content? Where? How shall we divide up the work? There's also mine and Reinhard's effort to rework the existing docs in readiness for 2.2. Some points: * Myself and Reinhard have been working on converting the docs to 2.2. We have got a decent framework in place, but we haven't done much work on actual documentation. Rerunning the 2.1 to 2.2 conversion process wouldn't be that hard. * If we want to get anything you do published quickly (i.e. less than six months), it is going to have to end up in the 2.1.X Cocoon SVN. * This will mean that the end result will be xdocs, not HTML. However, I don't believe converting HTML to xdocs would be hard, and I'd happily knock up a script to do any necessary conversions. * I'm not that fussed where a document is worked on before it gets in to SVN, so long as: (a) it is accessible to a wide range of people who can contribute (b) change notifications are sent out whenever content is changed (this is necessary to trigger an otherwise lazy community to take notice of your work) (c) it isn't too hard to convert the content across to HTML or xdoc format. So, I'd say that the work that is required is to do sort out the reference documentation, and to extend that with tutorials and introductory material. What area would you want to be starting with? If you've followed me so Far, then I have another question. What is the best way to have my work reviewed by the community? To test my understanding of the current process: for each revision, I would do one of the following: make a change in the wiki (are these actively reviewed?); send a patch to bugzilla (it'll be a lot of patches; how do I submit reorganisations?); or as with the above, start a discussion on the dev list (I believe the docs list is for change notifications only?). Patches is how content will need to get into SVN, but isn't, as you suggest, the best way to actually go about the editorial work. A less time consuming alternative for me would be to Sew it all together at Planet Cocoon, as it is already set up with infrastructure for anyone wishing to join in, tools for workflow, categorisation, document hierarchy management etc. If I were to take that approach, then my work would be continuously visible. Naturally, all my work will be donated back to Cocoon. And then it'll be time for a nice cuppa. Which brings us back to... What do others think? Start small, do a page or two at a time, so you can stop at any point and there's something valuable left. And we can complain and say no, that's not what we want before you've wasted heaps of time. Other than that, just get on with it :-) P.S. this took nearly all morning to write. D'oh! I can believe it! ++ What is Apache Cocoon? Apache Cocoon is an MVC web application framework uniquely suited to XML publishing. Apache Cocoon is founded on the principle of separation of concerns. Cocoon's Avalon-based component architecture makes it easy to create web applications from reusable components. You use the Cocoon Sitemap to assemble components into pipelines. Pipelines react to client requests, generating information from a source, transforming it, before serializing it back to the client in the desired format. This separation of concerns between generation, transformation and serialization, allows the same source to be served up to your browser, cellular phone or printer, or to be consumed by your web service. In addition to this mature publishing framework, Apache Cocoon offers features
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Upayavira wrote:
* This will mean that the end result will be xdocs, not HTML. However,
I don't believe converting HTML to xdocs would be hard, and I'd
happily knock up a script to do any necessary conversions.
actually Forrest already does this
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
RE: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Hi Marc, I do like the introduction. A less time consuming alternative for me would be to Sew it all together at Planet Cocoon, as it is already set up with infrastructure for anyone wishing to join in, tools for workflow, categorisation, document hierarchy management etc. If I were to take that approach, then my work would be continuously visible. Naturally, all my work will be donated back to Cocoon. There is another possibility: You get an editor account at the Cocoon Handbook site and start adding docs there. You can publish docs or keep them private, while you're working on them. I know it's another source of the docs, but AFAIU there is a plan to set up a Daisy installation at one of the Apache zones and then the current set of docs from the Handbook site can be moved over. Bye, Helma
DO NOT REPLY [Bug 33812] - [Link] kyverneio.gr (patch for livesites-2.1.xml included)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33812. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33812 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33746] - [Link] TanakhML Project
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33746 [EMAIL PROTECTED] changed: What|Removed |Added URL||http://www.tanakhml.org Summary|[http://www.tanakhml.org] |[Link] TanakhML Project |TanakhML Project| -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
On 03 Jun 2005, at 16:12, Linden H van der (MI) wrote: I know it's another source of the docs, but AFAIU there is a plan to set up a Daisy installation at one of the Apache zones and then the current set of docs from the Handbook site can be moved over. ... a plan which I'm working on at this very moment - still fighting a bit with Solaris-isms. Should be OK pretty soon now. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
DO NOT REPLY [Bug 34815] - [Link] http://www.rsv.vd.ch/ Recueil systématique de la législation vaudoise
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34815 [EMAIL PROTECTED] changed: What|Removed |Added Summary|[http://www.rsv.vd.ch/] |[Link] http://www.rsv.vd.ch/ |Recueil systématique de la |Recueil systématique de la |législation vaudoise|législation vaudoise -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Hi there Helma, OK, let's do a swap: I will gratefully accept editor privileges there, in exchange for granting you editor privileges at Planet Cocoon. That way we can contribute to each other's work as necessary. What do you think? BTW I've already got an account. Cheers, Mark On 3 Jun 2005, at 15:12, Linden H van der (MI) wrote: Hi Marc, I do like the introduction. A less time consuming alternative for me would be to Sew it all together at Planet Cocoon, as it is already set up with infrastructure for anyone wishing to join in, tools for workflow, categorisation, document hierarchy management etc. If I were to take that approach, then my work would be continuously visible. Naturally, all my work will be donated back to Cocoon. There is another possibility: You get an editor account at the Cocoon Handbook site and start adding docs there. You can publish docs or keep them private, while you're working on them. I know it's another source of the docs, but AFAIU there is a plan to set up a Daisy installation at one of the Apache zones and then the current set of docs from the Handbook site can be moved over. Bye, Helma
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Reinhard Poetz wrote: Upayavira wrote: * This will mean that the end result will be xdocs, not HTML. However, I don't believe converting HTML to xdocs would be hard, and I'd happily knock up a script to do any necessary conversions. actually Forrest already does this 0.6 does work with HTML, but you have to rename the files to *.ehtml in order to have them skinned Forrest 0.7-dev will work happily with most HTML docs without any kind of modification (anything it doesn't handle well is an oversight so we will patch for it). What version of Forrest does Cocoon currently work with. It is not a major step to upgrade to 0.7 if necessary. Ross
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Ross Gardler wrote: Reinhard Poetz wrote: Upayavira wrote: * This will mean that the end result will be xdocs, not HTML. However, I don't believe converting HTML to xdocs would be hard, and I'd happily knock up a script to do any necessary conversions. actually Forrest already does this 0.6 does work with HTML, but you have to rename the files to *.ehtml in order to have them skinned Forrest 0.7-dev will work happily with most HTML docs without any kind of modification (anything it doesn't handle well is an oversight so we will patch for it). What version of Forrest does Cocoon currently work with. It is not a major step to upgrade to 0.7 if necessary. I believe we're now at 0.6 (ish). Upayavira
DO NOT REPLY [Bug 32213] - Error handling and subsitemaps - errors not handled in subsitemap in special cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32213. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32213 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 17:07 --- See exception handling samples - lots of different scenarios, including this one, are working just fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 33962] - [Link] Marine Power Europe is the manufacturing, marketing and distribution subsidiary of Mercury Marine, covering Europe, CIS, Africa and the Middle East. Mercury Marine is the biggest boat engines business in the world and a major boat builder. [ Content management (under Notes DB2) via Web and publication via Cocoon]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33962. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33962 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Summary|Marine Power Europe is the |[Link] Marine Power Europe |manufacturing, marketing and|is the manufacturing, |distribution subsidiary of |marketing and distribution |Mercury Marine, covering|subsidiary of Mercury |Europe, CIS |Marine, covering Europe, CIS Summary|Africa and the Middle East. |Africa and the Middle East. |Mercury Marine is the |Mercury Marine is the |biggest boat engines|biggest boat engines |business in the world and a |business in the world and a |major boat builder. [ |major boat builder. [ |Content management (under |Content management (under |Notes DB2) via Web and|Notes DB2) via Web and |publication via Cocoon] |publication via Cocoon] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31676. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31676 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 17:15 --- Isn't this implemented already? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 31676] - [PATCH] HolderAwareContinuationsManagerImpl
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31676. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31676 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 17:15 --- Isn't this implemented already? Yes it is. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
DO NOT REPLY [Bug 33050] - [Link] website for the faculty of Arts of Universidad Nacional de Colombia
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33050 [EMAIL PROTECTED] changed: What|Removed |Added URL||http://facartes.unal.edu.co Severity|normal |enhancement Summary|http://facartes.unal.edu.co |[Link] website for the |[website for the faculty of |faculty of Arts of |Arts of Universidad Nacional|Universidad Nacional de |de Colombia]|Colombia -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34815] - [Link] http://www.rsv.vd.ch/ Recueil systématique de la législation vaudoise
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34815 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34044] - Exception during the running of a pipeline
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34044. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34044 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 16:45 --- This scenario was not supported; now [1] should work, please test 2.1.7 or .8 Vadim [1] http://svn.apache.org/viewcvs.cgi?rev=36244view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34130] - Contribution: StreamReader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34130 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 16:38 --- IIUC, ModuleSource together with FlowAttributeModule can do that already. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 31776] - Generator for outputting profiling information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31776. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31776 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 17:12 --- What are advantages over the profiling block? This generator provides only pipeline generation time; while profiling block gives times for pipeline setup, generation, and per-transformer execution time. Marking as WONTFIX - see profiling block; or you can provide a patch to profiling block if you want to get simplier profiling information (i.e., measure only combined gen/transf/ser time). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Cocoon and Axis
Hi there, I'm trying to find a clean alternative to use Cocoon as a webservice server using Axis as a library. So I see two solutions right now : 1 - using Jan's approach with a StreamGenerator (http://wiki.apache.org/cocoon/WebServiceServer) to get the SOAP message in a ByteArrayOutputStream and then use that to build an Axis message I can manipulate from flowscript 2 - or even better, it would be great if I could use Cocoon servlet as an HTTP listener (equivalent to the Axis servlet) to get directly a Message Context somewhere. Does anybody have an idea of how I can integrate Axis inside Cocoon ? And I found that (http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/axis/SoapServer.html) in the API docs... would it be useful ? how ? Thx in advance. -- Sebastien ARBOGAST
Re: Cocoon and Axis
Sebastien, Can you please explain a bit what you are trying to achieve? (use case?). Do you need to use Axis handlers? Where is your business logic going to reside (java objects? ejb?) thanks, dims (Cocoon Emeritus Axis Committer) On 6/3/05, Sebastien Arbogast [EMAIL PROTECTED] wrote: Hi there, I'm trying to find a clean alternative to use Cocoon as a webservice server using Axis as a library. So I see two solutions right now : 1 - using Jan's approach with a StreamGenerator (http://wiki.apache.org/cocoon/WebServiceServer) to get the SOAP message in a ByteArrayOutputStream and then use that to build an Axis message I can manipulate from flowscript 2 - or even better, it would be great if I could use Cocoon servlet as an HTTP listener (equivalent to the Axis servlet) to get directly a Message Context somewhere. Does anybody have an idea of how I can integrate Axis inside Cocoon ? And I found that (http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/axis/SoapServer.html) in the API docs... would it be useful ? how ? Thx in advance. -- Sebastien ARBOGAST -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Cocoon and Axis
BTW I forgot to mention something. The purpose of my webservices is not to create some RPC interface to my business code. In fact I want to use the document style to generate XML documents using Cocoon sitemap facilities and feed them into my SOAP responses. And of course I want to use parameters I can extract from the SOAP request message body as parameters for the code that generates those documents. For example I receive this kind of SOAP request : SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; SOAP-ENV:Header/ SOAP-ENV:Body wifilist location x=23.764578 y=87.875468 z=.7688/ range radius=1000 unit=meters/ /wifilist /SOAP-ENV:Body /SOAP-ENV:Envelope And I want to send back a SOAP response with a graphic map in attachment spotting all the wifi hotspots 1000meters around the specified position. Maybe something like : soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soapenv:Body html soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; body img src=map.gif/ /body /html /soapenv:Body /soapenv:Envelope With map.gif in attachment of course. I know it's not very frequent as a usage of webservices but I need something like that. I hope it gives you a better idea of what I'm trying to achieve... -- Sebastien ARBOGAST
Re: Cocoon and Axis
Sebastien,
Can you please explain a bit what you are trying to achieve? (use
case?). Do you need to use Axis handlers? Where is your business logic
going to reside (java objects? ejb?)
Alright. My Cocoon application is based on a Spring business logic and
I'm using Flowscript as a controller language.
What I want to achieve is quite simple in fact. My application can
receive traditional http requests (for back-office administration) or
SOAP webservice requests (let's say over HTTP for now) for services.
Jan Hinzman came up with an interesting approach to get the SOAP
envelope out the the request using Cocoon sitemap and a
StreamGenerator. But then he uses a JXTemplate and some XSLT
stylesheets to extract information from the SOAP envelope he has
stored in a ByteArrayOutputStream, and then to rebuild a SOAP answer
to send back. It works for his small sample with an echo webservice,
but I intend to use more complex features of SOAP, including
attachments.
I'm reading the excellent Building Web services with Java and in the
chapter about Implementing Web Services with Apache Axis they say
that :
When you use Axis as a SOAP server, the first thing that happens is
that a transport listener receives a message. Transport listener is a
fancy term for any software that can take input and turn it into
something that Axis understand. For example this might be a
servlet...
And I thought it would be great if it could be some Cocoon component.
So more concretely here is the use case :
1- a user sends a SOAP request to this address :
http://localhost:8080/myapp/modules/echo.ws
2- I have a sitemap pipeline matching that request in
http://localhost:8080/myapp/modules/sitemap.xmap
map:match pattern=*.ws
map:call function=webservice
map:parameter name=module value={1}/
/map:call
/map:match
3- In the webservice flowscript function there are two possible subcases :
3.1 - Either I manage to get or build a org.apache.axis.MessageContext
object from the request that lead me there and it's great because I
can use all the Axis handler facilities and combine flowscript and my
Spring business layer to provide the service and build the response
3.2 - Or it's not possible and at least I'd like to use Axis Message
API to manipulate my SOAP envelope instead of fiddling something dirty
with JXT/XSLT. If I have to do that, I'm looking for a way to build a
org.apache.axis.Message from the ByteArrayOutputStream I get in
soapEnvelope variable thanks to this flowscript code :
var soapEnvelope = new java.io.ByteArrayOutputStream();
cocoon.processPipelineTo(soapEnvelope, null, soapEnvelope);
And this sitemap pattern :
map:match pattern=soapEnvelope
map:generate type=stream/
map:serialize type=xmlnope/
/map:match
The thing is I'm just learning to use Axis (I'm currently finishing to
read this chapter about it) and I don't know Cocoon architecture
enough to know what is possible or not here. You may say then RTFM
and come back later but I only have 2 days to come up with a working
prototype of my system and this is the last part of it so... I was
thinking I could speed it up thanks to your more pragmatic approach.
Anyway, if you need any precision, feel free to ask.
--
Sébastien Arbogast
Re: Cocoon and Axis
yep. makes it VERY clear. need a bit of time to think about it. note that it may be easier to add attachment support (if it is not there already) to cocoon than to integrate Axis and Cocoon on the server-side. On 6/3/05, Sebastien Arbogast [EMAIL PROTECTED] wrote: BTW I forgot to mention something. The purpose of my webservices is not to create some RPC interface to my business code. In fact I want to use the document style to generate XML documents using Cocoon sitemap facilities and feed them into my SOAP responses. And of course I want to use parameters I can extract from the SOAP request message body as parameters for the code that generates those documents. For example I receive this kind of SOAP request : SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; SOAP-ENV:Header/ SOAP-ENV:Body wifilist location x=23.764578 y=87.875468 z=.7688/ range radius=1000 unit=meters/ /wifilist /SOAP-ENV:Body /SOAP-ENV:Envelope And I want to send back a SOAP response with a graphic map in attachment spotting all the wifi hotspots 1000meters around the specified position. Maybe something like : soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soapenv:Body html soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; body img src=map.gif/ /body /html /soapenv:Body /soapenv:Envelope With map.gif in attachment of course. I know it's not very frequent as a usage of webservices but I need something like that. I hope it gives you a better idea of what I'm trying to achieve... -- Sebastien ARBOGAST -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Cocoon and Axis
2005/6/3, Davanum Srinivas [EMAIL PROTECTED]: yep. makes it VERY clear. need a bit of time to think about it. note that it may be easier to add attachment support (if it is not there already) to cocoon than to integrate Axis and Cocoon on the server-side. thank you very much to take time to think about it. I really appreciate that. In the meantime, does someone have an idea how I can use SoapServerImpl in my application ? According to the API documentation it's quite recent (last committed on 2005-01-30 by Carsten Ziegeler), written by Marcus Crafter. Any idea ? -- Sebastien ARBOGAST
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Upayavira wrote: Ross Gardler wrote: Reinhard Poetz wrote: Upayavira wrote: * This will mean that the end result will be xdocs, not HTML. However, I don't believe converting HTML to xdocs would be hard, and I'd happily knock up a script to do any necessary conversions. actually Forrest already does this 0.6 does work with HTML, but you have to rename the files to *.ehtml in order to have them skinned Forrest 0.7-dev will work happily with most HTML docs without any kind of modification (anything it doesn't handle well is an oversight so we will patch for it). What version of Forrest does Cocoon currently work with. It is not a major step to upgrade to 0.7 if necessary. I believe we're now at 0.6 (ish). OK, 0.7 is in the final stages of development, we are just tidying up before the release. If you find the need to upgrade I will offer my assistance (you will have to upgrade in order to pull docuements from external sources like Daisy as that is part of the new plugin system). Ross
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Ross Gardler wrote: Upayavira wrote: Ross Gardler wrote: Reinhard Poetz wrote: Upayavira wrote: * This will mean that the end result will be xdocs, not HTML. However, I don't believe converting HTML to xdocs would be hard, and I'd happily knock up a script to do any necessary conversions. actually Forrest already does this 0.6 does work with HTML, but you have to rename the files to *.ehtml in order to have them skinned Forrest 0.7-dev will work happily with most HTML docs without any kind of modification (anything it doesn't handle well is an oversight so we will patch for it). What version of Forrest does Cocoon currently work with. It is not a major step to upgrade to 0.7 if necessary. I believe we're now at 0.6 (ish). OK, 0.7 is in the final stages of development, we are just tidying up before the release. If you find the need to upgrade I will offer my assistance (you will have to upgrade in order to pull docuements from external sources like Daisy as that is part of the new plugin system). Well, given Steven is working on setting up Daisy right now, I think we might need that. How much change would our SVN repo require to make 0.7 work? Regards, Upayavira
Cocoon zone update
On 03 Jun 2005, at 16:49, Steven Noels wrote: On 03 Jun 2005, at 16:12, Linden H van der (MI) wrote: I know it's another source of the docs, but AFAIU there is a plan to set up a Daisy installation at one of the Apache zones and then the current set of docs from the Handbook site can be moved over. ... a plan which I'm working on at this very moment - still fighting a bit with Solaris-isms. Should be OK pretty soon now. I'll call it a night, but http://cocoon.zones.apache.org/daisy/ is live - still a crude and empty setup, however. What do we have: Apache2 mod_proxying /daisy/ to Daisy - that way we can have other Cocoon instances[1] mounted parallel to Daisy. The Daisy Wiki (Cocoon) runs on port 8081 - in order not to clash with the default Cocoon/Jetty port. The Daisy repository service and OpenJMS run on their usual ports. All Daisy-related stuff is installed in /home/daisy and runs under its own user - I've been using wrapper from tanukisoftware for this. That way, people are able to sudo into the daisy user and can do the usual start|stop|restart thing. Bertrand, Upayavira and I have root/sudo access. Any committer can ask for an account. Next week: 0) document what I've done (oh - the joy of solaris!) 1) move handbook content from cocoondev.org - the cocoon solaris zone 2) think about organization: variants, document types, collections, Daisy sites, faceted browsing, etc People interested in co-administering Daisy on the Cocoon zone should register themselves and ping me so that I can add them to the relevant role - I'll try to figure out how they can sudo into the Daisy setup as well without needing blanket root access. Make sure you read Daisy docs before pinging! ;) [1] Just for kicks, I'm running a temporary Cocoon 2.1.7 demo from my user account, proxied on /cocoondemo/ - but obviously it needs more mod_rewrite foo than Daisy ATM. Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon and Axis
I almost got it !!! (Axis is great to use !... I love it when API's
are so intuitive)
I just miss a small part to send the answer message I've built back to
the client. Here is the new cocoonWS function I came up with (with
plenty of debugging code in the middle :-P)
function webservice(){
var module = cocoon.parameters[module];
clog(module is: + module + \n);
//getting the envelope out of the request (can be done only once)
var soapEnvelope = new java.io.ByteArrayOutputStream();
cocoon.processPipelineTo(soapEnvelope, null, soapEnvelope);
clog(Request was:\n + soapEnvelope + \n);
var message = new org.apache.axis.Message(soapEnvelope.toString());
clog(Message length was: + message.getContentLength() + \n);
var soapPart = message.getSOAPPart();
clog(soapPart was :\n + soapPart + \n);
var envelope = soapPart.getEnvelope();
clog(envelope was :\n + envelope + \n);
var body = envelope.getBody();
clog(body was :\n + body + \n);
var it = body.getChildElements();
var messageContent = it.next();
clog(messageContent was :\n + messageContent + \n);
var soapMethod = messageContent.getElementName().getLocalName();
clog(soapMethod was : + soapMethod + \n);
/*
* Now that we have the method, we generate the according parameters and
* execute the code for the called method
*/
if(soapMethod == echo){
clog(echo called);
//generate the parameter
var soapParameter = messageContent.getValue();
clog(soapParameter: + soapParameter);
//process the method (echo in this case)
/*
* Here we compute something e.g. some businessprocess
* can be executed (sendMail, ftpUpload,...)
* for the echo Method it would be:
* //var answer = parameter;
* but we put this right in the answer.
*/
var answerEnvelope = new SOAPEnvelope();
var answerContent = new SOAPBodyElement(new
PrefixedQName(cocoonWS,result,cws));
answerContent.addTextNode(soapParameter);
answerEnvelope.addBodyElement(answerContent);
clog(answerEnvelope was :\n + answerEnvelope + \n);
//send the answer
//AND THE PROBLEM IS HERE CAUSE I DON'T KNOW HOW TO SEND
//THE CONTENT OF answerContent BACK TO THE USER
clog(done.);
return;
}
else { /* here you can add more methods */
//setting the answer if no method matched
//TODO in this case we should generate a SOAP-FAULT
var answer = The method you have called is not understood by
this server. +
Sorry!;
cocoon.sendPage(soapAnswer, {answer:answer});
clog(no method matched, sending error-statment);
return;
}
}
Any ideas out there to replace my uppercase desperate call with
something that actually works ?
BTW this works perfectly and it's much cleaner than the previous
approach (no more JXTemplate and XSLT to extract SOAP data) but I
still lose HTTP headers from the initial request because I build a
message from the received SOAP envelope instead of getting a
MessageContent built from the servlet request. So does anyone have an
idea for that... ?
--
Sebastien ARBOGAST
Re: Cocoon and Axis
can u get cocoon.response's outputstream and use the messages writeTo method?
On 6/3/05, Sebastien Arbogast [EMAIL PROTECTED] wrote:
I almost got it !!! (Axis is great to use !... I love it when API's
are so intuitive)
I just miss a small part to send the answer message I've built back to
the client. Here is the new cocoonWS function I came up with (with
plenty of debugging code in the middle :-P)
function webservice(){
var module = cocoon.parameters[module];
clog(module is: + module + \n);
//getting the envelope out of the request (can be done only once)
var soapEnvelope = new java.io.ByteArrayOutputStream();
cocoon.processPipelineTo(soapEnvelope, null, soapEnvelope);
clog(Request was:\n + soapEnvelope + \n);
var message = new org.apache.axis.Message(soapEnvelope.toString());
clog(Message length was: + message.getContentLength() + \n);
var soapPart = message.getSOAPPart();
clog(soapPart was :\n + soapPart + \n);
var envelope = soapPart.getEnvelope();
clog(envelope was :\n + envelope + \n);
var body = envelope.getBody();
clog(body was :\n + body + \n);
var it = body.getChildElements();
var messageContent = it.next();
clog(messageContent was :\n + messageContent + \n);
var soapMethod = messageContent.getElementName().getLocalName();
clog(soapMethod was : + soapMethod + \n);
/*
* Now that we have the method, we generate the according parameters and
* execute the code for the called method
*/
if(soapMethod == echo){
clog(echo called);
//generate the parameter
var soapParameter = messageContent.getValue();
clog(soapParameter: + soapParameter);
//process the method (echo in this case)
/*
* Here we compute something e.g. some businessprocess
* can be executed (sendMail, ftpUpload,...)
* for the echo Method it would be:
* //var answer = parameter;
* but we put this right in the answer.
*/
var answerEnvelope = new SOAPEnvelope();
var answerContent = new SOAPBodyElement(new
PrefixedQName(cocoonWS,result,cws));
answerContent.addTextNode(soapParameter);
answerEnvelope.addBodyElement(answerContent);
clog(answerEnvelope was :\n + answerEnvelope + \n);
//send the answer
//AND THE PROBLEM IS HERE CAUSE I DON'T KNOW HOW TO SEND
//THE CONTENT OF answerContent BACK TO THE USER
clog(done.);
return;
}
else { /* here you can add more methods */
//setting the answer if no method matched
//TODO in this case we should generate a SOAP-FAULT
var answer = The method you have called is not understood by
this server. +
Sorry!;
cocoon.sendPage(soapAnswer, {answer:answer});
clog(no method matched, sending error-statment);
return;
}
}
Any ideas out there to replace my uppercase desperate call with
something that actually works ?
BTW this works perfectly and it's much cleaner than the previous
approach (no more JXTemplate and XSLT to extract SOAP data) but I
still lose HTTP headers from the initial request because I build a
message from the received SOAP envelope instead of getting a
MessageContent built from the servlet request. So does anyone have an
idea for that... ?
--
Sebastien ARBOGAST
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
On Jun 3, 2005, at 8:42 AM, Mark Leicester wrote: What is Apache Cocoon? Apache Cocoon is an MVC web application framework uniquely suited to XML publishing. Apache Cocoon is founded on the principle of separation of concerns. Cocoon's Avalon-based component architecture makes it easy to create web applications from reusable components. You use the Cocoon Sitemap to assemble components into pipelines. Pipelines react to client requests, generating information from a source, transforming it, before serializing it back to the client in the desired format. This separation of concerns between generation, transformation and serialization, allows the same source to be served up to your browser, cellular phone or printer, or to be consumed by your web service. In addition to this mature publishing framework, Apache Cocoon offers features and frameworks to help you build full-featured web applications. Cocoon Flow offers continuation-based scripting for your application business logic. Cocoon Templates offer dynamic XML generation. The Cocoon Forms framework greatly simplifies client interaction with a growing library of user interface widgets for your web application forms. Mark, I applaud your efforts to improve Cocoon's documentation and I am thankful for your company footing the bill. However, I think what you have written above just continues the existing problem with a different set of words. The two paragraphs as a whole assume familiaraity with the concepts of MVC, separation of concerns, that Cocoon has a sitemap and what that is, pipelines, generation, transformation and serialization and continuation-based scripting. If I were completely unfamiliar with Cocoon, I really still would not know what it is other then a web application framework. I spent last weekend going over Cocoon's documentation, various threads concerning it and proposed TOCs. I came away with the feeling that Cocoon's documentation is written by experienced Cocoon developers for experienced Cocoon developers. The only thing Cocoon's documentation should assume is that a user is familiar with XML and XSLT. If they want to use flow the documentation needs to assume that they have some familiarity with javascript and/or Java. Its similar for each aspect of Cocoon. Assume only enough to go forward with out having to explain things outside of Cocoon. I have an email that I have been working on since Monday with an outline of how I was planing to proceed with writing new documentation. Key aspects are that we need to have separate documentation for users and developers and that the user documentation needs to assume as little as possible about the users experience. Hopefully, I will edit down to a few paragraphs and send it this weekend. In the meantime you might want to consider targeting your documentation for the most junior and least skilled website developer in your company. Better yet, a 1st year student. I mean all this in the most constructive way. Hopefully we will be able to collaborate over the next 4 weeks and get a good start on rewriting these docs. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
I spent last weekend going over Cocoon's documentation, various threads concerning it and proposed TOCs. I came away with the feeling that Cocoon's documentation is written by experienced Cocoon developers for experienced Cocoon developers. The only thing Cocoon's documentation should assume is that a user is familiar with XML and XSLT. If they want to use flow the documentation needs to assume that they have some familiarity with javascript and/or Java. Its similar for each aspect of Cocoon. Assume only enough to go forward with out having to explain things outside of Cocoon. Obviously we share exactly the same concerns. I don't know if you had a look at my documentation workflow proposal (http://www.planetcocoon.com/node/2079) but as you'll see, everything is made to put readers needs and assumptions about their knowledge at the center of our documentation writing process. And I totally agree with you : current documentation is mainly written by developers for other developers and that's precisely one of the main reasons why we started our initiative on Planet Cocoon, to create a real *user* documentation writing platform. I have an email that I have been working on since Monday with an outline of how I was planing to proceed with writing new documentation. Key aspects are that we need to have separate documentation for users and developers and that the user documentation needs to assume as little as possible about the users experience. Hopefully, I will edit down to a few paragraphs and send it this weekend. I'm looking forward to hear your ideas. Maybe it could be the occasion to join our efforts on Planet Cocoon. That's how I joined Mark in this initiative, you could join us. In the meantime you might want to consider targeting your documentation for the most junior and least skilled website developer in your company. Better yet, a 1st year student. Once more we'll even do better than that : we are going to setup a documentation request mechanism so that people can give details about what they want to know AND what they already know. That way we'll have an objective view about what we can assume or not when writing documentation, and eventually make Cocoon more accessible. I mean all this in the most constructive way. Hopefully we will be able to collaborate over the next 4 weeks and get a good start on rewriting these docs. That would be great ! Cheers -- Sebastien ARBOGAST
Re: Cocoon and Axis
2005/6/3, Davanum Srinivas [EMAIL PROTECTED]: can u get cocoon.response's outputstream and use the messages writeTo method? Technically yes I can do something like that : cocoon.response.setContentType(text/xml); var os = cocoon.response.getOutputStream(); os.println(answerContent.toString()); But I keep getting this exception: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Invalid Content-Type:text/html. Is this an error message instead of a SOAP response? It seems a bit rough to me : we don't do everything that the XML serializer does. And what if I want to apply a transformation to my document before I send it, like some i18n transformation for example. There should be a simple solution to do that sort of thing... maybe a suggestion for a method to add to the cocoon object hmmm ? BTW I had completely forgotten I could access HttpServletRequest and HttpServletResponse from flowscript using the cocoon object. Maybe it would be enough to rebuild the MessageContext object and forward it to some Axis handlers... WDYT ? -- Sebastien ARBOGAST
Re: [SUMMARY] Caching DynamicSelectionList
On Jue, 2 de Junio de 2005, 2:50, Sylvain Wallez dijo: Antonio Gallardo wrote: Are we going to deprecate @dynamic? Yes. Use of @dynamic should be logged as deprecated. Also, the default behavior should be changed to either cache=none or cache=request, whereas today it's similar to cache=static. Just committed: Cforms block: Caching selection list for best performance inside repeaters. Deprecate @dynamic in fd:selection-list in favor of @cache. Posible @cache values are: * static = equivalent to old @dynamic=false * none = equivalent to old @dynamic=true * request = is new, similar to cache=none, but caching the selection list per request. Useful to improve performance inside repeaters. Defaults are the same as before. - 0 - Now looking forward, the next task is improve the SelectionLIst performance, when it is created using: fd:on-value-changed fd:javascript var value= myWidget.setSelectionList(cocoon:/mySelectionList?id= + value); . /fd:javascript /fd:on-value-changed Thanks for all the help provided! ;-) Best Regards, Antonio Gallardo.
[forms] simple output-only datatype convertor
Hi, I have this class called Money, a fixed-point representation and arithmetic class for monetary amounts. I want to display some Moneys in an output widget in a repeater. Money has a toString() method. Am I missing some obvious, built-in easy way to make this work? What I did... (1) Wrote dumb little class StringConvertor and StringConvertorBuilder classes. This just calls toString() on the object. I added this in the Cocoon source tree. (2) Made a MoneyType and MoneyTypeBuilder (extending the abstract classes in oacf.datatype.typeimpl). I did this in my application source tree which is built separately from cocoon. To make this work, I had to change visibility on some AbstractTypeBuilder methods from protected to public. (3) Finally, added my new datatype to cocoon.xconf. It works fine. But it feels wrong. It was kind of a pain in the rear for one thing. Was there a better approach? Cheers, ml
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
Hello Glen, Thanks for your comments! They are indeed constructive, and you are right to raise this issue. Who are we writing for? In simplistic terms I imagine two groups: fairly-technical and not-so-technical. My solution has been to create one site, http://www.spreadcocoon.com, for the not-so-technical market, and another, http://www.planetcocoon.com, for the fairly-technical market. Spread Cocoon is modelled on http://spreadfirefox.com. It's for people who want to know about Cocoon, want to know how it can help them, want to hear success stories, see example sites, know about Cocoon events, and generally buy badges, posters, stickers and T-shirts. On the other hand, Planet Cocoon is a rich developer community site where technical people can find the nuts and bolts, and get on with being creative. Firefox has similarly separated sites, and I believe the same two-pronged approach may work for Cocoon. This text is targeted at Planet Cocoon: experienced developers, wanting to know more, perhaps weighing up Cocoon as a possible solution alongside other web application frameworks. Let's get this text right for developers. We can tailor it further for different types of developers, like Click here if you want to compare Cocoon with Struts, Click here if you want to compare Cocoon with .NET, Click here if you are a 1st year student who wants to change the world. For the equivalent high-level paragraphs on Spread Cocoon, I can imagine wholly different language oriented to the non-technical public. Let's develop a version of this text for the general, thrill-seeking, public. Please remember that neither of the efforts I am discussing are in any way official, or representative of the views of the Cocoon PMC. You are quite right: it's about knowing your audience. I am looking forward to hearing what you and others have to say! Regards, Mark Mark, I applaud your efforts to improve Cocoon's documentation and I am thankful for your company footing the bill. However, I think what you have written above just continues the existing problem with a different set of words. The two paragraphs as a whole assume familiaraity with the concepts of MVC, separation of concerns, that Cocoon has a sitemap and what that is, pipelines, generation, transformation and serialization and continuation-based scripting. If I were completely unfamiliar with Cocoon, I really still would not know what it is other then a web application framework. I spent last weekend going over Cocoon's documentation, various threads concerning it and proposed TOCs. I came away with the feeling that Cocoon's documentation is written by experienced Cocoon developers for experienced Cocoon developers. The only thing Cocoon's documentation should assume is that a user is familiar with XML and XSLT. If they want to use flow the documentation needs to assume that they have some familiarity with javascript and/or Java. Its similar for each aspect of Cocoon. Assume only enough to go forward with out having to explain things outside of Cocoon. I have an email that I have been working on since Monday with an outline of how I was planing to proceed with writing new documentation. Key aspects are that we need to have separate documentation for users and developers and that the user documentation needs to assume as little as possible about the users experience. Hopefully, I will edit down to a few paragraphs and send it this weekend. In the meantime you might want to consider targeting your documentation for the most junior and least skilled website developer in your company. Better yet, a 1st year student. I mean all this in the most constructive way. Hopefully we will be able to collaborate over the next 4 weeks and get a good start on rewriting these docs. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: Cocoon zone update
On 03 Jun 2005, at 23:41, Steven Noels wrote: 1) move handbook content from cocoondev.org - the cocoon solaris zone Daughter woke up early: done. Helma, can you cross-check? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon and Axis
2005/6/3, Davanum Srinivas [EMAIL PROTECTED]: com.sun.xml.messaging.saaj is NOT in axis Yep I know... but anyway I finally found a solution. I don't fully understand how it works but the solution was to use joose method advocated in Jan's approach, with a JXTemplate (with an inject macro) and a stringToSAX function to generate SAX events from a String. I had begun to write it down for the Wiki but FF crashed and I lost everything (:-|) so I don't have the courage to write it again right now. It might be an interesting subject for one of our first tutorials on Planet Cocoon, in order to test our workflow process ;-) If anyone needs more information about how I used Axis API's to access SOAP data, feel free to send me an email and I'll give you details. Now that works but I still need to solve the mystery of the SOAPServerImpl component (which appears to be properly configured in cocoon.xconf). If anyone could give me more details about that one, it would be great... -- Sebastien ARBOGAST
