Re: [OT] [Job] Cocoon developer required (London)
in the HTML Robby Pelssers wrote: What did you do to make it crash? ;-) I can open the home page without any issues. I've tried it on another XP machine and an Ubuntu system and... Doh! both work fine. I suspect my machine doesn't like the video object in the HTML for some reason. I have performed video editing on it before so maybe I have an errant codec installed somewhere. As you were! ;-) Regards, David Legg
Re: Cocoon documentation
Jos Snellings wrote: The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\ I stumbled upon the HTML deliverable of that on http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. I'd think it would be best if the official documentation focused on being primarily a comprehensive reference with a quick bootstrap guide. A community documentation site could then supplement that with all the typical tutorials/how-to's and tips tricks which gets the reader where he wants to be with a straightforward, minimalist approach which then references the official docs and other more enlightening sources. Regular articles/blog entries could then highlight the activity in the community, and the possibilities of various Cocoon components could be showcased. Guides to all of the overlapping processes which can be [easily] extrapolated from existing material can be given a home so that a potential new developer with a specific need is provided with an apparent foot in the door. Basically a site which presents a welcoming, active community rather than seemingly a group of scattered people developing in Cocoons and enabling me to make bad wordplay (such is the price). To that end, an agreed upon forum would be ideal. The cocoon community will be delighted at some good documentation. Talking about community I fear such as an active community is to be reestablished, so I think we'd better provide some sweet stuff. What would Reinhard think of starting with as a table of contents? I will be glad to write some documentation as well. I have some goose feathers available after Christmas, when I will be through the experience of creating a first How about you? Jos On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote: I'm a recent transplant to Cocoon (and Java), in particular because Cocoon 3 appears as though it is/will be closely in line with my own perspective on web application development. I'm interested in contributing to the development of the framework itself, but likely won't be able to produce anything remotely useful for a couple months as I familiarize myself with all of the related technologies. I've just read some of the attacks on the poor documentation of the project and the resulting difficult entry for those unfamiliar. This is, of course, easily confirmed by the combination of woefully out of date references and dead links on the Web site (i.e. to the Daisy site). As I am (obviously) hopeful to see Cocoon succeed, I certainly don't want it to become mired in isolation like so many good projects. As such I'd like to try to contribute some documentation. Is there any idea among the community as to where documentation should end up, or should I just create a new site? Also, I'd lean towards focusing on Cocoon 3, as having documentation in place for a new release would likely have larger impact than attaching possibly overdue docs to an older, in the process of being superseded one. This would be premature if there's no foreseeable beta
Re: StringTemplateGenerator
Jos Snellings schrieb:
Dear,
Just a small question, testing:
When I get:
java.lang.NullPointerException
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.constructCacheKey(StringTemplateGenerator.java:75)
I notice that StringTemplateGenerator has two constructors: one with a
'source' argument, and one without.
The one without source argument is called.
Does this make sense? Am I making a mistake in the sitemap?
Here's the code:
map:match pattern=testcases/{name}.st
map:generate src=testcases/{map:name}.st
type=string-template/
map:serialize type=xhtml/
/map:match
Hi,
the two constructors serve two different purposes:
* the default contructor is used by the sitemap to assemble pipelines in
the way described by the sitemap definition (so that one being called is
expected in your case)
* the constructor with the source parameter is intended for the
programmatic use (pure convenience)
Looking at the code in the StringTemplateGenerator suggests that the
source you're passing testcases/{map:name}.st cannot be resolved for
the name you are using, thus resolving in the URL being null and
causing a NPE.
URL resolution in your case (using a sitemap) is performed by the
GenerateNode, which delegates back to the Invocation(Impl).
No logging in that area *sigh* so you will either need to double check
your name parameter and resources and/or go debugging...
The sitemap fragment you posted is perfectly fine BTW.
hth,
Steven
Thanks,
Jos
Re: REST / Can't find URLResponseBuilder
Johannes Lichtenberger schrieb:
On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote:
In the samples, a typical use of StringTemplate is shown: a page is to
be interpreted by the StringTemplate engine, and a number of properties
are passed via the hashtable.
The idea is that you would open a view on the object.
So,
- the query points to a resource
- the controller decodes what the resource is and what you want (view
it, update it?)
- the way to view it could be: pass my resource to a StringTemplate
invocation: new Page('stringtemplateinvocation',resource);
However, I have not tried to elaborate this so far. Shall I post it when
i have a useable example?
Yes it would be great. My concern is that I don't want to display a
template page. I want to process the request (the parameters Google
Earth sends when zooming in) and within my Generator query a native XML
database system and built the algorithmic logic inside the generator
(what data out of the shreddered xml file is needed and has to be
transformed with an XSLT stylesheet). So I basically know how RESTful
webservices work, but I don't know how to use cocoon3 in this case (I
assume new Page(...) isn't the right thing to return when I just want to
pass the request params to my generator. So I don't want to use
StringTemplate in this case (but it's nontheless a great thing). So the
query points to a controller, which decides that it's a GET request
(view) and passes the parameters on to my generator (which I still have
to write).
Would be great if you or someone else could help me out (it's a project
in a course of our university ;-) and I thought cocoon is great for this
concern (get RESTful parameters, hand it on to a generator which selects
the needed data out of a shreddered xml file according to the
parameters, then transform the xml fragments with a XSLT stylesheet and
serialize the result, so that Google Earth can use the KML fragments
generated).
Hi,
I'm not entirely sure I understand what you want to do (or to be more
precise which parts already exist and which don't), but I'll try to
improvise.
I can imagine two approaches:
1.
You can access HTTP request parameters from a generator (or any other
PipelineComponent - a Controller is just a fancy PipelineComponent) as well.
The SitemapServlet will add all HTTP request parameters to the
invocation that is built to handle the request and will be passed to
every PipelineComponent in the
org.apache.cocoon.pipeline.component.PipelineComponent.setup(MapString,
Object) method. The keys will be the names of the HTTP request parameters.
Read the parameters in your generator, and then perform the rest of your
logic.
2.
Keep the controller and do all pre-processing necessary within the
controller: the XML DB, XSLT (if you just want to use XLST have a look
at org.apache.cocoon.sax.util.TransformationUtils) etc.
When you are ready, store the data required for your generator in a
parameter map (just like you did in the code fragment you posted) and
delegate to a pipeline that uses your generator.
The generator will be able to access the data the same way I described
above.
Only difference would be that in this case the key would be defined by
your controller, while in the approach above the key would be determined
by the name of the HTTP request parameter.
hth,
Steven
Thank you,
Johannes
Re: REST / Can't find URLResponseBuilder
Steven Dolg schrieb:
Johannes Lichtenberger schrieb:
On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote:
In the samples, a typical use of StringTemplate is shown: a page is to
be interpreted by the StringTemplate engine, and a number of properties
are passed via the hashtable.
The idea is that you would open a view on the object.
So, - the query points to a resource
- the controller decodes what the resource is and what you want (view
it, update it?)
- the way to view it could be: pass my resource to a StringTemplate
invocation: new Page('stringtemplateinvocation',resource);
However, I have not tried to elaborate this so far. Shall I post it
when
i have a useable example?
Yes it would be great. My concern is that I don't want to display a
template page. I want to process the request (the parameters Google
Earth sends when zooming in) and within my Generator query a native XML
database system and built the algorithmic logic inside the generator
(what data out of the shreddered xml file is needed and has to be
transformed with an XSLT stylesheet). So I basically know how RESTful
webservices work, but I don't know how to use cocoon3 in this case (I
assume new Page(...) isn't the right thing to return when I just want to
pass the request params to my generator. So I don't want to use
StringTemplate in this case (but it's nontheless a great thing). So the
query points to a controller, which decides that it's a GET request
(view) and passes the parameters on to my generator (which I still have
to write).
Would be great if you or someone else could help me out (it's a project
in a course of our university ;-) and I thought cocoon is great for this
concern (get RESTful parameters, hand it on to a generator which selects
the needed data out of a shreddered xml file according to the
parameters, then transform the xml fragments with a XSLT stylesheet and
serialize the result, so that Google Earth can use the KML fragments
generated).
Hi,
I'm not entirely sure I understand what you want to do (or to be more
precise which parts already exist and which don't), but I'll try to
improvise.
I just found your other mail from earlier (REST / own generator) and
it seems your only problem is to access the HTTP request parameters.
If that's the case ditch the controller and access them in your
generator like I explained in the first approach below.
They are already there - no need to use a controller to make them
accessible...
I can imagine two approaches:
1.
You can access HTTP request parameters from a generator (or any other
PipelineComponent - a Controller is just a fancy PipelineComponent) as
well.
The SitemapServlet will add all HTTP request parameters to the
invocation that is built to handle the request and will be passed to
every PipelineComponent in the
org.apache.cocoon.pipeline.component.PipelineComponent.setup(MapString,
Object) method. The keys will be the names of the HTTP request
parameters.
Read the parameters in your generator, and then perform the rest of
your logic.
2.
Keep the controller and do all pre-processing necessary within the
controller: the XML DB, XSLT (if you just want to use XLST have a look
at org.apache.cocoon.sax.util.TransformationUtils) etc.
When you are ready, store the data required for your generator in a
parameter map (just like you did in the code fragment you posted) and
delegate to a pipeline that uses your generator.
The generator will be able to access the data the same way I described
above.
Only difference would be that in this case the key would be defined by
your controller, while in the approach above the key would be
determined by the name of the HTTP request parameter.
hth,
Steven
Thank you,
Johannes
Re: Cocoon documentation
Yes, that would be it... agreed. On Tue, 2009-12-01 at 06:23 -0500, Matt Whipple wrote: Jos Snellings wrote: The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\ I stumbled upon the HTML deliverable of that on http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. I'd think it would be best if the official documentation focused on being primarily a comprehensive reference with a quick bootstrap guide. A community documentation site could then supplement that with all the typical tutorials/how-to's and tips tricks which gets the reader where he wants to be with a straightforward, minimalist approach which then references the official docs and other more enlightening sources. Regular articles/blog entries could then highlight the activity in the community, and the possibilities of various Cocoon components could be showcased. Guides to all of the overlapping processes which can be [easily] extrapolated from existing material can be given a home so that a potential new developer with a specific need is provided with an apparent foot in the door. Basically a site which presents a welcoming, active community rather than seemingly a group of scattered people developing in Cocoons and enabling me to make bad wordplay (such is the price). To that end, an agreed upon forum would be ideal. The cocoon community will be delighted at some good documentation. Talking about community I fear such as an active community is to be reestablished, so I think we'd better provide some sweet stuff. What would Reinhard think of starting with as a table of contents? I will be glad to write some documentation as well. I have some goose feathers available after Christmas, when I will be through the experience of creating a first How about you? Jos On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote: I'm a recent transplant to Cocoon (and Java), in particular because Cocoon 3 appears as though it is/will be closely in line with my own perspective on web application development. I'm interested in contributing to the development of the framework itself, but likely won't be able to produce anything remotely useful for a couple months as I familiarize myself with all of the related technologies. I've just read some of the attacks on the poor documentation of the project and the resulting difficult entry for those unfamiliar. This is, of course, easily confirmed by the combination of woefully out of date references and dead links on the Web site (i.e. to the Daisy site). As I am (obviously) hopeful to see Cocoon succeed, I certainly don't want it to become mired in isolation like so many good projects. As such I'd like to try to contribute some documentation. Is there any idea among the community as to where documentation should end up, or should I just create a new site? Also, I'd lean towards focusing on Cocoon 3, as having documentation in place for a new release would likely have larger impact than attaching possibly overdue docs to an older, in the process of being superseded one. This would be premature if there's no foreseeable beta
[jira] Updated: (COCOON3-3) Provide an XInclude transformer as a PipelineComponent
[ https://issues.apache.org/jira/browse/COCOON3-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi updated COCOON3-3: - Attachment: XIncludeTransformer.patch Last uploaded patch (XIncludeTransformer.patch ~92K) contains a new implementation of the XInclude processor based strictly only on SAX APIs, no more DOM to extract elements by ids or by xpath expressions. Like always, don't hesitate to contact me if some help or extra work is needed to apply the patch. Provide an XInclude transformer as a PipelineComponent -- Key: COCOON3-3 URL: https://issues.apache.org/jira/browse/COCOON3-3 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-3 Attachments: XInclude.patch, XIncludeTransformer.patch, XIncludeTransformerFixedAndApacheHeaders.patch Oldest versions of cocoon already contain an XInclude transformer, it could be a good starting point: http://svn.eu.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XIncludeTransformer.java XPointer package's dependencies should be reduced to be imported in the new pipeline: http://svn.eu.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/xpointer An alternative solution could be using xerces2 APIs: http://xerces.apache.org/xerces2-j/faq-xinclude.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon documentation
Matt Whipple wrote:
Jos Snellings wrote:
The documentation of cocoon-3 can be checked out as:
svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
I stumbled upon the HTML deliverable of that on
http://people.apache.org/~reinhard/c3-ref/html/ after sending my email.
I'd think it would be best if the official documentation focused on
being primarily a comprehensive reference with a quick bootstrap guide.
A community documentation site could then supplement that with all the
typical tutorials/how-to's and tips tricks which gets the reader where
he wants to be with a straightforward, minimalist approach which then
references the official docs and other more enlightening sources.
Regular articles/blog entries could then highlight the activity in the
community, and the possibilities of various Cocoon components could be
showcased. Guides to all of the overlapping processes which can be
[easily] extrapolated from existing material can be given a home so that
a potential new developer with a specific need is provided with an
apparent foot in the door. Basically a site which presents a welcoming,
active community rather than seemingly a group of scattered people
developing in Cocoons and enabling me to make bad wordplay (such is the
price). To that end, an agreed upon forum would be ideal.
Agreed. When I started to write the C3 documentation, I had the Spring
reference documentation in mind. I think it's one of the best examples
because it focuses on describing the technology and the concepts.
As a forum for everything beyond reference docs we could either use
Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon)
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Cocoon documentation
Reinhard Pötz wrote: Matt Whipple wrote: Jos Snellings wrote: The documentation of cocoon-3 can be checked out as: svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\ I stumbled upon the HTML deliverable of that on http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. I'd think it would be best if the official documentation focused on being primarily a comprehensive reference with a quick bootstrap guide. A community documentation site could then supplement that with all the typical tutorials/how-to's and tips tricks which gets the reader where he wants to be with a straightforward, minimalist approach which then references the official docs and other more enlightening sources. Regular articles/blog entries could then highlight the activity in the community, and the possibilities of various Cocoon components could be showcased. Guides to all of the overlapping processes which can be [easily] extrapolated from existing material can be given a home so that a potential new developer with a specific need is provided with an apparent foot in the door. Basically a site which presents a welcoming, active community rather than seemingly a group of scattered people developing in Cocoons and enabling me to make bad wordplay (such is the price). To that end, an agreed upon forum would be ideal. Agreed. When I started to write the C3 documentation, I had the Spring reference documentation in mind. I think it's one of the best examples because it focuses on describing the technology and the concepts. As a forum for everything beyond reference docs we could either use Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon) My thought would be Daisy (cocoondev.org?) so the site itself can be Cocoon powered and then the wiki can remain legacy docs.
