Re: Documentation System [was: Spring Configurator Docs]
David Legg said the following on 12/2/09 16:42: Luca, I did some documentation port myself, but I have to admit it is not that easy, since something *may* indeed have changed in the passage... bottom line: you have to know a component's behaviour in both 2.1 and 2.2 before safely porting its doc. You're so right about that. It is a big job. I started updating the HTMLSerializer [1] but then realized there were actually two implementations of it with different sets of parameters. Not only that but a lot of 'folklore' and list wisdom was trapped in the mailing list and on the old wiki over the last few years and that needed to be set free. As one of the initiators of the current Daisy documentation route, I am feeling the same pain. My current use of Cocoon is 0% although I can't get myself to unsubscribe from the lists. ;-) The current pace of development is too quick to help out in documentation if you're not heavily involved in the project. My initial ideas about this setup was that it's fairly easy and quick to open up a page in Daisy and start adding documentation. That way the chances of actually adding documentation increase. Anything that takes a lot of time will spoil the chance of actual writing. Don't think that each page in Daisy should immediately be added to the general site, but use the update frequency to let it simmer and improve the quality. Bye, Helma
Re: Documentation System [was: Spring Configurator Docs]
Luca Morandini said the following on 12/2/09 20:27: Benjamin Boksa wrote: As there is no official cocoon blog as far as I know I think such a blog would be a good way (in addition to the existing documentation) to Once upon a time there was planetcocoon.com... with blog and all sorts of cocoon-related stuff, but it is now gone. But there was no new content in that. It was merely an aggregation of various sources. Nice to see everything in one place but not much in a way of documentation. Bye, Helma
Re: [OT] Mac OS X and Java development
Just chiming in. Came preinstalled on my mac. Did you install the dev tools? No dev tools. Are they only available for Leopard? I'm still on Tiger - and would rather switch to Linux than spending money for Leopard ;) All versions of Mac OS X (at least from Panther or Tiger) come with dev tools on the installation CD/DVD. Just pop in the installation disk and select the developer tools. That's probably personal taste. I can do lots of stuff faster with just the keyboard. LOL the ability to do much more with just the keyboard is one of the strong arguments for me to switch to OS X. ;-) But not in Eclipse ;) Anyways, I don't want to get started with letters for cursor navigation. Eclipse, jEdit and many other developer tools are more or less platform independent and therefore by definition not mac-native. Using Windows you're used to having a diversion in keybindings and GUI-interface layout, but Mac apps are much more consistent, so the exception to the rule stands out more prominently. The reason Mac apps are more consistent is the fact that a larger part of the underlying frameworks are available to the developers. This also results in applications that are much smaller. Huh, I didn't realize people still run such older versions of MacOS. Tiger? Leopard is only out since 1/2 year, so what ... And I'm not willing to pay for it. I agree. 'Older versions' should refer to pre-Tiger versions. I truly think some people are on those, but the majority has moved to Tiger or Leopard by now. From what I read Tiger is considered a very stable, very mature version, while Leopard seems to be a kind of 'infant of the new generation'. It does provide new and interesting functionality, but it also introduces problems that will probably be solved in the next updates/versions. Why a completely separated version after all? I can see the point of a native lookfeel, but beyond that ... It's not a completely separated version. AFAIK it's repackaged to fit in Apple's idea of how to layout the frameworks. At least it's set up in a way that changing versions is really simple. And yes, sometimes it would be better if Apple didn't force their ideas on the users so much. Bye, Helma
Re: [jira] Commented: (COCOON-2043) Thien Luh's new design of the Cocoon website
Sure, go ahead. Bye, Helma On Mon, Apr 21, 2008 at 10:45 PM, Grzegorz Kossakowski (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/COCOON-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591042#action_12591042 ] Grzegorz Kossakowski commented on COCOON-2043: -- Helma, since we are already happily using Thien's work at our site we can close this issue. Right? Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assignee: Helma van der Linden Attachments: Cocoon Site - Elements.zip, Home V2 - Final.psd, icons.rar, warning.gif Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Bye, hepabolu
Re: [jira] Created: (COCOON-2189) Dojo drag and drop reordering does not work
On 3/29/08, Hugh Sparks (JIRA) [EMAIL PROTECTED] wrote: Dojo drag and drop reordering does not work --- Key: COCOON-2189 URL: https://issues.apache.org/jira/browse/COCOON-2189 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Priority: Minor On the CForms block samples page in the Advanced Ajax samples using Dojo widgets section, the drag and and drop reordering examples do not work. When a field is moved using drag and drop, this error is reported: DEBUG: [Error: Unspecified error.] when calling onMouseMove$joinpoint$method on [object Object] with arguments [object Object] FATAL exception raised: Unspecified error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Sent from Gmail for mobile | mobile.google.com Bye, hepabolu
Re: FAQ dcoument
Reinhard Poetz said the following on 6/1/08 13:51: Vadim Gritsenko wrote: On Jan 5, 2008, at 9:53 AM, hepabolu wrote: Grzegorz Kossakowski said the following on 5/1/08 13:51: Hi, I added[1] FAQ-entry for the subject of much controversy among Cocoon community. Now I wonder how to get it published, I found old document aggregating all FAQ entries but it doesn't work ATM. Before I go and fix it I would like to ask your opinion on separating FAQs for Cocoon 2.1 and Cocoon 2.2. Obviously, some entries addressed to 2.2 version has no value for 2.1 user. If we are going to separate FAQ documents, how we will mark to which version particular entries are addressed? Using tags or some other mechanism? My personal opinion is that tags will be the most convenient choice. [1] http://cocoon.zones.apache.org/daisy/cdocs/1425.html [2] http://cocoon.zones.apache.org/daisy/documentation/856.html The regular Daisy approach is to create a branch for each version. That way you can answer the same FAQ different for each version. I'm not sure if you can batch move documents to a specific branch. IMHO there is no much potential for shared FAQs with two different answers for each version. I think it's a better approach to have unique FAQ document per version, meaning for 2.2 we should start from scratch. +1 additionally I've never tested if the Daisy exporter works correctly with references to branched documents. If we ever need this in the future, we will have to try it out before. What if you create different collections for different versions? Documents can be part of multiple collections, so that is a way to differentiate between the two. It would make exporting easier as well. OTOTH if you need to create different collections for each block, you quickly run into loads of collections. Reinhard, would a single version-based collection be enough to extract the documents for a specific version or does your exporter work differently? Bye, Helma
Re: FAQ dcoument
Grzegorz Kossakowski said the following on 5/1/08 13:51: Hi, I added[1] FAQ-entry for the subject of much controversy among Cocoon community. Now I wonder how to get it published, I found old document aggregating all FAQ entries but it doesn't work ATM. Before I go and fix it I would like to ask your opinion on separating FAQs for Cocoon 2.1 and Cocoon 2.2. Obviously, some entries addressed to 2.2 version has no value for 2.1 user. If we are going to separate FAQ documents, how we will mark to which version particular entries are addressed? Using tags or some other mechanism? My personal opinion is that tags will be the most convenient choice. [1] http://cocoon.zones.apache.org/daisy/cdocs/1425.html [2] http://cocoon.zones.apache.org/daisy/documentation/856.html The regular Daisy approach is to create a branch for each version. That way you can answer the same FAQ different for each version. I'm not sure if you can batch move documents to a specific branch. Bye, Helma
Re: [result][vote] Releasing from trunk: Cocoon 2.2-RC2 others
Reinhard Poetz said the following on 26/10/07 18:34: Grzegorz Kossakowski wrote: BTW. When can we expect new release officialy announced? I've started to work on it together with a What's new in Cocoon 2.2 page and hope to finish it this weekend. Sorry to reply so late, I'm currently out of internet connection at home. :-( Anyway, re 141.html: - You state that 'Apache Cocoon is a Spring-based framework'. Shouldn't that be 'Since version 2.2 Apache Cocoon is a Spring-based framework' because earlier versions are not. - A block is the unit of modularization (in comparison: Eclipse uses the term plugins, OSGi bundles) in Cocoon. Better: A block is the unit of modularization in Cocoon (in comparison: Eclipse uses the term plugins, OSGi uses bundles). Note: is that the intention: OSGi uses bundles? If not, please correct. - Everything that goes beyond that what Cocoon provides in... Remove the second 'that'. - A block can provide +THE+ following features: (add 'the') - add commas after each list item and a dot after the last item. - A block is packaged as +A+ Java archive (jar) (add 'a') - (Cocoon Configuration) It's current implementation... should be: Its current implementation... - (Cocoon database) Direct usage of releational databases should be: relational - (Cocoon Flow) ...s for building in... you might as well remove the second space between 'for' and 'building' - (Cocoon Mail) Sitemap components to send mails I'd prefer: emails. - (Cocoon Maven plugin) paching the web.xml at deployment time. should be: patching Re 1420.html: I've gone in and added a few minor changes myself. I'm not sure of the following: - General, last list item: what about it? Is it available, is it configurable. Please complete the sentence. Hope this helps. Bye, Helma
Re: Cocoon 2.2 documentation online!
Reinhard Poetz said the following on 2/10/07 18:08: hepabolu wrote: Reinhard Poetz said the following on 28/9/07 16:26: While I was creating all the release artifacts of Cocoon 2.2RC2 I also published our 2.2 docs. See http://cocoon.apache.org/2.2/ I have to say that I'm really proud of seeing this long-term effort finally materializing :-) Thanks to all the involved helping hands! Excellent work! I just noticed that the 'subprojects' link on the right leads to the directory, rather than the index.html file. hmm, on which page do you notice this behaviour? For me it works ... On all of them. I just tested the main page, the one with the picture of the graphic of the architecture (Spring framework) and some others I can't remember. Bye, Helma
Re: Cocoon 2.2 documentation online!
Reinhard Poetz said the following on 28/9/07 16:26: While I was creating all the release artifacts of Cocoon 2.2RC2 I also published our 2.2 docs. See http://cocoon.apache.org/2.2/ I have to say that I'm really proud of seeing this long-term effort finally materializing :-) Thanks to all the involved helping hands! Excellent work! I just noticed that the 'subprojects' link on the right leads to the directory, rather than the index.html file. Bye, Helma PS. Sorry, won't be at the CocoonGT. Have fun all of you.
Re: [CocoonGT] Has anyone considered inviting folks from Wicket?
Gianugo Rabellino said the following on 4/9/07 13:36: On 9/4/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: Hello, I saw that there are people interested in Cocoon-Wicket cooperation and we have already some plans to play with Wicket in Cocoon 2.2. I also have seen few folks from Wicket interested in bringing Cocoon strengths into Wicket so why not to invite some gurus? Opinions? That would be great! Would you do the honors? What about Upayavira and Sylvain? Bye, Helma
Re: How to update docs for 2.1?
Grzegorz Kossakowski said the following on 4/7/07 10:12: First: some idiot decided to 'service' my ADSL connection, thus cutting me off and now three parties are haggling about who is responsible for reconnecting me. End result: I'm on dial-up for the time being and I won't read/answer much. Isn't 2.1 documentation also generated from Daisy? That means you have to integrate your changes there. I'd guess here: http://cocoon.zones.apache.org/daisy/legacydocs/654.html. This is true. Thanks David and Joerg. I'm really confused, wiki page is talking most of the time about checking out /site from svn and updating docs there. Right. This is ancient. Please remove that text from the wiki page. However, there is a statement: Since 2.1.8, the documentation (apart from the top-level website pages described above) is written using Daisy at [WWW] http://cocoon.zones.apache.org/, and Daisy-generated pages are processed by Forrest (using forrest trunk) to generate the static pages (still in experimental phase). Does this means we really use Daisy and docs from legacydocs to generate 2.1 documentation or not? What should I edit? Yes we do. The old way was too time consuming and therefore a blocker for writing docs. That's why we moved to Daisy. I thought that legacydocs import to Daisy was meant as a start base for 2.2 docs. Could you explain it little more? Both: - generation of 2.1 docs - base for 2.2 docs Hope this helps. Bye, Helma
Re: How to update docs for 2.1?
Grzegorz Kossakowski said the following on 4/7/07 16:03: Both: - generation of 2.1 docs - base for 2.2 docs Hope this helps. Almost. :) If I want to start a document that is based on something from 2.1 I should _copy_ that document instead of _moving_ right? Legacy docs should be modified only for improvements, right? I should say: - if it holds for both 2.1 and 2.2 - add appropriate 2.2 collection to the document - if it is different in 2.1 and 2.2 - copy the 2.1 doc and create a new doc in the appropriate 2.2 collection and modify that In Daisy documents can belong to various collections, so you can simply add the appropriate collections to get it to be published in both document sets. FYI the collection can be added on one of the tabs in the doc editor. Bye, Helma
Re: [WEBSITE] 2.1/userdocs/flow/tutor.html
Jeff Schmitz said the following on 8/6/07 22:10:
There is an error in the flowscript tutorial.
http://cocoon.apache.org/2.1/userdocs/flow/tutor.html
The game.js code shows the following call:
cocoon.sendPageAndWait(guess.jxt, { random : random, hint : hint,
guesses : guesses} );
I think it needs to specify guess.jx, not guess.jxt.
Fixed. Thanks for spotting this.
Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Carsten Ziegeler said the following on 23/5/07 21:43:
If I see this correctly, the difference between the two solutions is
that in the not working case, the DOMBuilder is used to build the DOM
whereas in the working case, the serializer is used and the result is
then parsed again.
As Marc said, you're right.
As you suggested offline I've tried serializing the output of the
pipelineUtil.toDOM to a file and do a diff. The result is: the files are
identical except that elements with multiple attributes have a different
order of the attributes.
Just to be sure that I didn't disguise any errors by the way I saved the
files, here's what I did [1].
Notes:
- pipeline is simple xml-generator + xsl-transformer + xml-serializer,
all default stuff. The only thing different is the parameter of
namespace prefix=true in cocoon.xconf for the xml-parser.
- BTW this leads to NAMESPACE PREFIX!! lines in
the console. Is that what you were referring to in your other post?
So unless I have done the process of saving wrong, I don't see a
difference between the two files.
Bye, Helma
-
[1]
FILE1 = display above pipeline in firefox - view page source - copy
paste to texteditor - save
FILE2 =
var document = pipelineUtil.processToDOM(AddIDsPipeline/ +
formFileName, {});
_saveDocument(document, _makeTargetURI(documentURI));
_saveDocument(document, uri) {
...
resolver =
cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
source = resolver.resolveURI(uri);
var tf =
Packages.javax.xml.transform.TransformerFactory.newInstance();
if (source instanceof
Packages.org.apache.excalibur.source.ModifiableSource
tf.getFeature(Packages.javax.xml.transform.sax.SAXTransformerFactory.FEATURE))
{
outputStream = source.getOutputStream();
var transformerHandler = tf.newTransformerHandler();
var transformer = transformerHandler.getTransformer();
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.INDENT,
true);
transformer.setOutputProperty(Packages.javax.xml.transform.OutputKeys.METHOD,
xml);
transformerHandler.setResult(new
Packages.javax.xml.transform.stream.StreamResult(outputStream));
var streamer = new
Packages.org.apache.cocoon.xml.dom.DOMStreamer(transformerHandler);
streamer.stream(document);
...
}
Re: CForms binding with namespaces error - advice wanted
So you can't rely that you get the namespace attributes in the dom builder. I think this is where things go wrong. Note that both binding file and source are generated with a pipeline and pipelineUtil.toDOM. I've done some debugging into pipelineUtil.toDOM and this is what I found: - binding file has all the namespaces in pipeline. This is confirmed because I can save the output of the pipeline and see the namespaces in the root element: fb:context xmlns:fb=http://apache.org/cocoon/forms/1.0#binding; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:fd=http://apache.org/cocoon/forms/1.0#definition; xmlns:oe=openEHR/v1/Version path=/oe:version - After returning from SourceUtil.toDOM (which uses the default DOMBuilder()), the only namespace left is fb=http://apache.org/cocoon/forms/1.0#binding;. Attributes of this node only holds 'path=/oe:version'. - This is true for the source=pipeline situation as well: only the oe=openEHR/v1/Version is left. - The source=file situation has all namespaces in the attributes. I can understand that in the situation of source=pipeline there cannot be any matching because the oe namespace is not known in the binding file. However, this is also true for the situation of source=file and there matching happens on various fb:context until it fails on a difference in datatype. What I also don't understand is the fact that putting the source=pipeline through the savedocument function as I did this morning, gives me all the namespaces back. I'm not sure if this helps in the discussion and I have no clue on how to solve this. Anyone? Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Carsten Ziegeler said the following on 24/5/07 15:57: hepabolu schrieb: So you can't rely that you get the namespace attributes in the dom builder. I think this is where things go wrong. Note that both binding file and source are generated with a pipeline and pipelineUtil.toDOM. I've done some debugging into pipelineUtil.toDOM and this is what I found: - binding file has all the namespaces in pipeline. This is confirmed because I can save the output of the pipeline and see the namespaces in the root element: fb:context xmlns:fb=http://apache.org/cocoon/forms/1.0#binding; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:fd=http://apache.org/cocoon/forms/1.0#definition; xmlns:oe=openEHR/v1/Version path=/oe:version - After returning from SourceUtil.toDOM (which uses the default DOMBuilder()), the only namespace left is fb=http://apache.org/cocoon/forms/1.0#binding;. Attributes of this node only holds 'path=/oe:version'. - This is true for the source=pipeline situation as well: only the oe=openEHR/v1/Version is left. - The source=file situation has all namespaces in the attributes. I can understand that in the situation of source=pipeline there cannot be any matching because the oe namespace is not known in the binding file. However, this is also true for the situation of source=file and there matching happens on various fb:context until it fails on a difference in datatype. What I also don't understand is the fact that putting the source=pipeline through the savedocument function as I did this morning, gives me all the namespaces back. I'm not sure if this helps in the discussion and I have no clue on how to solve this. Anyone? I must say that this is all a little bit strange to me as well. Now, are you using the prefix oe somewhere in the xml? The prefix fb is definitly used, so it might be that there is some optimization filtering unused prefixes? Just a wild guess. Yes. Source is: oe:version xmlns:oe=openEHR/v1/Version xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=ORIGINAL_VERSION So in fact I want the first line of the binding file to bind to /oe:version I don't think there are unused prefixes in both binding and source. Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Carsten Ziegeler said the following on 24/5/07 16:14: Helma wrote Yes. Source is: oe:version xmlns:oe=openEHR/v1/Version xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=ORIGINAL_VERSION So in fact I want the first line of the binding file to bind to /oe:version I don't think there are unused prefixes in both binding and source. Ah, sorry, I meant are you really using the prefix in the binding file? Using the prefix inside of an attribute (like the path attribute) does actually not use the prefix. This is just arbitrary text for the parser. That's what I'm slowly starting to realise. For proper XML validation I do need it so I assumed the parser requires this too. That would partially explain why the binding file (without a namespaceURI for 'oe') still maps to the source (in the source=file situation). It would also explain the observations in https://issues.apache.org/jira/browse/COCOON-1671 i.e. if the prefix is the same with a matching or a different namespaceURI it binds, but if the prefix is different but the namespaceURI is identical it fails. So how should this be solved then? Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Marc Portier said the following on 24/5/07 17:35: we could start off by checking some more 1/ can jxpath in fact handle namespaces correctly as described above ( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396 the orginal reporter of the issue states that this is the case, so we can take it from there of course) right. 2/ are indeed the ns-maps inside the CommonAttributes objects on each JXPathBinding base correctly filled in (I suggest dumping those in log-debug statements during binding to verify in the various cases) No. I've done step-by-step debugging on this and the CommonAttributes are empty or null (can't remember exactly). In any case, no namespaces are available. In fact CommonAttributes calls addLocalNSAttributes (or something similar) which in turn calls Element.getAttributes() which doesn't return any namespaces. I can't say whether that's due to a flaw in addLocalNSAttributes or because I was processing the binding generated through pipelineUtil.toDOM. if those ns-declaration-maps are empty when they should not, then we should fix the binding first to populate them correctly: - probably follow the path of fixing DomHelper to use the lookupNamespaceURI() method in combo with some xpath parsing as I suggested earlier) If you could be more specific in how I should go about doing this, I'd have another look tomorrow...eh, later today. ;-) - or stop joking about it and do the sax rewrite :-) Just wondering: is this 2.1.X only or does it affect 2.2 as well? Bye, Helma
Re: CForms binding with namespaces error - advice wanted
Joerg Heinicke said the following on 23/5/07 20:03:
On 23.05.2007 13:07, hepabolu wrote:
+ I would comment (or even close-wontfix?) that bug with a reference
to the above conclusion from carsten. Just in case somebody would
want to apply the patch without giving it more thought...
I just added a comment.
Using the param is an appropriate solution and the patch is no longer
valid. Since the issue (COCOON-1686) was especially created as patch to
COCOON-1671 I closed it, but added a comment and link from COCOON-1671
to it.
Thanks. Sadly enough it still doesn't solve my problem.
I hope some of you can shed some light on this:
In flowscript I create the various cform files through pipelines (see [1]).
When I read the source from a file by using the line marked with
[X] instead of the one below, the binding starts to work (I get
an error on expected BigDecimal vs received String, but that's a
different problem). This source file is created by displaying the output
of the pipeline of the line below in a browser and saving the source of
that output in a file.
When I use the code as is below (i.e. the source is read from a
pipeline) the binding silently fails with a debug message in the log files:
PoolThread-4/ContextJXPathBinding: non-existent path: skipping
ContextJXPathBinding [xpath=/oe:version]
(oe:version is the root element).
Both binding and source file have the namespace set:
fb:context xmlns:fb=http://apache.org/cocoon/forms/1.0#binding;
xmlns:oe=openEHR/v1/Version path=/oe:version
and
oe:version xmlns:oe=openEHR/v1/Version
Anyone?
Thanks.
Bye, Helma
[1]
showmyform() {
var formFileName = cocoon.parameters[filename];
/* Generate the template from a pipeline */
var formDisplay = FormTemplatePipeline/ + formFileName;
/* Generate the model from a pipeline */
var pipelineUtil =
cocoon.createObject(org.apache.cocoon.components.flow.util.PipelineUtil);
var modelDoc = pipelineUtil.processToDOM(FormModelPipeline/+
formFileName, {}).getDocumentElement();
/* Generate the binding from a pipeline */
var bindingDoc = pipelineUtil.processToDOM(FormBindingPipeline/ +
formFileName, {}).getDocumentElement();
//var bindingDoc = FORMDIR + test-bloodfilmBinding.xml;
var form = new Form(modelDoc);
form.createBinding(bindingDoc);
/* Generate the result file */
var formResult = formFileName + Result.jx;
// get the documentURI parameter from the sitemap which contains the
// location of the file to be edited
var documentURI = cocoon.parameters[documentURI];
// parse the document to a DOM-tree
//[X]var document = _loadDocument(documentURI);
var document = pipelineUtil.processToDOM(AddIDsPipeline/ +
formFileName, {});
// bind the document data to the form
form.load(document.getDocumentElement());
// show the form to the user until it is validated successfully
form.showForm(formDisplay);
// bind the form's data back to the document
form.save(document);
cocoon.sendPage(formResult);
}
_loaddocument(uri){
.
parser =
cocoon.getComponent(Packages.org.apache.excalibur.xml.dom.DOMParser.ROLE);
resolver =
cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
source = resolver.resolveURI(uri);
print (sourceURI= + source.getURI());
var is = new
Packages.org.xml.sax.InputSource(source.getInputStream());
is.setSystemId(source.getURI());
return parser.parseDocument(is);
..
}
Re: Samples styling
Felix Knecht said the following on 17/5/07 17:46: IMO the documentation in general for the servlet services should be done somewhere else than in the sitemap itself. So I think it should be enough to have a note in the sitemap when servlet services are used. Is this ok? Sure, you DO need proper documentation in Daisy on this topic, but adding some extra documentation to the sitemap to clarify samples is helpful too. Thanks. Bye, Helma
Re: Samples styling
Felix Knecht said the following on 16/5/07 15:01: Grzegorz Kossakowski schrieb: As I previously said, I'm not sure if we need this either, so I won't push you to use services. I'm not feeling pushed ;-) But I think we should show in the samples what's the common way of doing it - otherwise only some specialists will use this (powerfull) feature and a common developer won't get notice of it. Therefore I'm going to use it in the next samples I move to servler-service. Samples are as much a source of documentation and tutorials so you should provide either way. I have plenty of cases where I've searched high and low for finding info on how to do something, only to find it in a casual reference in a post on the list. What you should do is provide the 'common' way of doing it in a general sample and the 'specialist' way in a sample that is created exactly for that purpose. And please do add plenty of comments to the sitemap pipelines to explain what's going on. Thanks for all the effort. Bye, Helma
Re: svn commit: r537202 - /cocoon/trunk/pom.xml
[EMAIL PROTECTED] said the following on 11/5/07 16:59: requireMavenVersion - version[2.0.5,)/version + version[2.0.6,)/version Looks odd: starting and ending brackets are different. Is this correct? Bye, Helma
Re: [OT] Lots of nested quotes
Grzegorz Kossakowski said the following on 9/5/07 22:09: Take a look at the snippet above, it's long trail of useless information - noise. I know that you are as lazy as I'm but there is solution for Thunderbird users: https://addons.mozilla.org/pl/thunderbird/addon/612 I hope you will like it. :-) And for those not fluent in Polish: https://addons.mozilla.org/en-US/thunderbird/addon/612 :-) Bye, Helma
Re: Upgrading Daisy
Reinhard Poetz said the following on 10/5/07 09:33: [moving over a discussion from [EMAIL PROTECTED] to [EMAIL PROTECTED] Bruno Dumon wrote: Which also makes me think of it: the Cocoon zone is still running Daisy 1.5. I could do the upgrade, but I'm not sure on the impact this might have. The maven plugin should be easy to upgrade, but I think the forrest plugin is also still in use? It could be that it works without changes but I'm not sure. I was thinking about an upgrade too but I'd prefer to wait until we have published the new documentation because I want to concentrate on that first. WDYT? IMO: Best to do the upgrade now. I've done it here with a small site and it was done in 3 hours (including figuring out the best way to upgrade a Suse machine to java 1.5). Daisy 2.0.X changes the name of the document in the url (1.html - 1-NS.html with NS = a namespacecode), which means you have to redo the publishing all over again because the link to the Daisy page breaks after the upgrade. Bye, Helma
Re: Upgrading Daisy
Reinhard Poetz said the following on 10/5/07 14:51: Daisy 2.0.X changes the name of the document in the url (1.html - 1-NS.html with NS = a namespacecode), which means you have to redo the publishing all over again because the link to the Daisy page breaks after the upgrade. I don't see a reason why we need the namespace in our published URLs at all. The Daisy plugin could cut them off. Sure, and I'm all for cutting it off, but in Daisy the namespace is there so backlink from the published page should go to the namespaced version. Now: Daisy: .../1.html Published: ../1.html (div id=EditUrla href=zones.../1.html.) After upgrading Daisy 2.0: Daisy: .../1-NS.html Published: ../1.html (div id=EditUrla href=zones.../1.html.) This is where it goes wrong ^^ Basically I'm not against the upgrade but I would like to invest my time rather in cleaning up and adding docs instead of upgrading the Daisy So true, but you need to realise that the above situation will occur when Daisy is upgraded and the publication has not been redone. plugin. In theory the upgrade shouldn't cause any problems but I learned by experience that upgrades aren't that smooth as expected most of the time. :-) Anyway, maybe I find some time over the weekend but I can't promise it ... ok. Bye, Helma
Re: svn commit: r536004 - /cocoon/trunk/site/cocoon-thien-maven-site-skin/src/main/resources/css/site.css
[EMAIL PROTECTED] said the following on 8/5/07 00:09:
+tt {
+ font-size: 1.3em;
}
Reinhard,
it's best to keep the font sizes in percentages to keep things
consistent. The only em value is in the body selector.
Bye, Helma
Re: svn commit: r535805 - in /cocoon/trunk: commons/CREDITS.txt pom.xml
Grzegorz Kossakowski said the following on 7/5/07 18:08: Typo? Sorry, I'm not sure what you mean. Please explain. Bye, Helma
Re: [OT] pronunciation
Ralph Goers said the following on 22/4/07 21:27: Grzegorz Kossakowski wrote: I was under constant pressure so could not refuse: http://reflectingonthevicissitudes.wordpress.com/2007/04/22/pal-how-can-i-call-you/ :) Very cool. If I was going to spell it from the way you say it your first name would be something like Grregosh. Americans find it difficult to roll the r's, so if we say it is will come out like Gregosh. Actually the only thing different about your last name is that the o's are not pronounced the way I would expect. I would have guessed it would be Kaw-sa-cowski. Intead it is more like Kaw-sa-kawski. LOL This is great fun! I have a Polish coworker, her first name is Agnieszka and even after 4 years I'm still not able to pronounce it correctly and I AM capable of hearing the difference between her pronunciation and mine. Fortunately she settles for Agnes. ;-) Bye, Helma
Re: building trunk.
Reinhard Poetz said the following on 16/4/07 13:07: Giacomo Pati wrote: Ok, so just for readybility. Do you use the eclipse XML-Formatter? no, I use OxygenXML but I do the formatting by hand. Basically I add empty lines between the different sections and try to move the important I use OxygenXML too, and since I hate indenting by hand, I force 'empty' lines by adding formatted comments between the sections. Like: !-- ** new section here -- enough to improve readability and Oxygen obeys. ;-) Bye, Helma
Re: [GT2007] [VOTE] Conference location + time
Arje Cahn said the following on 11/4/07 15:08: Hi all, Please cast your votes on both the location and the time for this year's Cocoon GetTogether conference: A) The Netherlands, Amsterdam +1 B) Italy, Rome / Milano +10 C) England, London / Norwich +2 When: A) Late september +1 B) Beginning of October (between the holidays season and ApacheCon) +3 C) End of October +2 Doesn't mean that I'm 100% sure of attending though. :-( Bye, Helma
Re: svn commit: r525980 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java
Joerg Heinicke said the following on 6/4/07 00:38: On 06.04.2007 00:18, [EMAIL PROTECTED] wrote: Log: COCOON-1622: Second patch applied since it's the most complete. Works. Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java What about trunk? :) I was under the impression that this block was shared. Besides: I tested it in my current Cocoon setup (read: 2.1.10-dev with only relevant blocks included) and haven't yet looked properly at trunk. Since there has not been any change in SendMailTransformer since around the time of the patch, I assumed it was safe to commit my patched version. Do feel free to copy it to trunk. ;-) Bye, Helma
Re: [graphics] Re: Publishing our new docs - what else needs to be done?
Reinhard Poetz said the following on 29/3/07 00:17: Sorry for picking up this thread again after more than a week. My apologies. No worries. See http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html. As I don't want to create dozens of JIRA tasks, I created this list. As the handling of huge tables is more comfortable in Daisy than in our Wiki, I created it in Daisy. Fine by me, I've added myself to do some tasks. Bye, Helma
Re: Daisy and JIRA karma
Felix Knecht said the following on 27/3/07 07:07: Dear all Would someone be so kind grant me the necessary karma on Daisy and JIRA? On both systems I use the username 'felixk'. Daisy karma granted. Bye, Helma
[daisy] User removed
FYI: I have removed a Daisy user from the zones who registered with 'admin' as username and 'xx xxx' as name and a hotmail address on 2/9/07 and hasn't confirmed registration ever since. Bye, Helma
Re: Daisy and JIRA karma
Jeroen Reijn said the following on 27/3/07 10:02: Me 2, me 2! :-) Daisy login: jreijn JIRA login: jeroenreijn :-) Daisy karma granted Bye, Helma
Re: [graphics] Final version of new Cocoon masthead
Gavin Carothers said the following on 20/3/07 14:46: Only one thought of something to add so that it fails a bit more gracefully at lower screen sizes (800x600). Should be fixed by now. Peter Hunsberger said the following on 20/3/07 17:48: However, note that some CSS tweaking may be required; if you increase your browser text size (ctrl + in Firefox) you get some strange things going on. People with poor eyesight may not be able to use it very well as it currently sits. Fixed as well. Check the new version at: http://people.apache.org/~hepabolu/final6.html Bye, Helma
Re: [graphics] Final version of new Cocoon masthead
Peter Hunsberger said the following on 21/3/07 14:32: Looks good. There are some quirks as you scale it larger, in particualr with IE 6. Maybe we should add a Note about Best viewed with a standards compliant browser, but I don't know No. That's so nineties. As said before: I think our primary target group will probably have good eyesight (and thus won't scale the fonts) and most of them will probably NOT use IE6 (especially with IE7 out now). Bye, Helma
[graphics] Re: Publishing our new docs - what else needs to be done?
Reinhard Poetz said the following on 20/3/07 12:02: Jeroen Reijn wrote: *Applause* Great work! :D So when are we going to put this live? there is some work left: - create a Maven skin (- writing a Velocity template) - initial content for http://cocoon.apache.org and -- http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1285.html http://cocoon.apache.org/2.2/ -- I will create a Daisy site ASAP Isn't this simply the current 'one site per block' setup? Or, the 'stuff' you put up at http://cocoon.zones.apache.org/dev-docs/? I'm getting confused about the purpose of all these different sites/collections. I'm not sure if you have shed some light on this somewhere, but here's my idea (at least that's what I assume it is): - 'legacydocs' is the 'old' documentation - now exported as Cocoon 2.1 docs - 'one site/collection per block' is the documentation for Cocoon 2.2 Probably there are some more things to do left - I will create a (more detailed) todo list this evening or tommorrow and share it with this list. Any help would be highly appreciated I'll review your list and add things when necessary. There are a few things left to do that probably need Thien's expertise. This page is the home page and it typically has a different layout than the other pages. E.g. the majority of the pages will consist of a left menu column and a wide content column. I wonder if that is not going to be too wide to read comfortably, or we should now agree that most people use their browser at a size more or less equal to 1024 x 768 or less. We also need some more styling elements: - tables - warning - FIXME/TO DO Bye, Helma
Re: [graphics] Final version of new Cocoon masthead
Gavin Carothers said the following on 20/3/07 14:46: doesn't clear it up as it drops under the left hand nav, dope. The goal of course is to drop the news section always under the floating boxes. This shouldn't change the look on a wide display but makes it a fair bit easier to read on a smaller one. I don't have too much time just at the moment and since Thien has knows the design and markup far better then I do; I imagine he can come up with a fix faster then I can. Though I will take a look at this again at some point this week if it isn't fixed before I have a chance. Hi, just let me get this straight: you mean that the News section creeps up between the download block and the about Cocoon block when viewed at sizes 800x600 and above, where the getting blocks are not in one row? I've noticed this before and worked with Thien on a solution but we finally settled on this one because you either get a large gap between the blocks and the News section or the blocks vary in size to fill up the width. Both are not as pretty as the final solution. I agree that at 800 x ... this looks a bit awkward and I'll think about it some more to see if I can find a solution. On 1024 x ... with three green blocks in a row and the blue one dropping underneath I kind of like how the News section moves up in the gap. Bye, Helma
Re: [graphics] Final version of new Cocoon masthead
Joerg Heinicke said the following on 20/3/07 20:33: On 20.03.2007 17:48, Peter Hunsberger wrote: However, note that some CSS tweaking may be required; if you increase your browser text size (ctrl + in Firefox) you get some strange things going on. People with poor eyesight may not be able to use it very well as it currently sits. The only thing I can see is that part of the white letters come out of the blocks when the size is increased. Actually I can't confirm it. Though increasing it twice to 150% it looks still really nice. True. Bye, Helma
[graphics] Final version of new Cocoon masthead
Hi guys, The final version of Cocoon's new masthead front page is available at: http://people.apache.org/~hepabolu/final6.html Once again a big round of applause to Thien. Bye, Helma
Re: [GT2007] It's that time of the year again...
Torsten Curdt said the following on 17/3/07 00:03: What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon Italy!! :-D +1! Bye, Helma
[graphics] New masthead version - final5
Guys, Thien and I have discussed the LF of the breadcrumb trail and turned it to a more bluish color. Thien has also made the colors of the masthead stronger. Check it out: http://people.apache.org/~hepabolu/final5.html Bye, Helma
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory said the following on 5/3/07 09:19: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Bye, Helma
[graphics] Artwork for cocoon.apache.org - final4
Guys, in the midst of his wedding preps Thien has provided a new version where the breadcrumb bar is a flat solid color now, rather than a glossy rounded bar. I've taken the liberty to change the shade to the same color as the getting boxes. And I've removed the French flag (only saw the messages of Sylvain and Betrand after the upload of this version). Here's the link: http://people.apache.org/~hepabolu/final4.html The only issue left now (AFAICK) is Peter Hunsberger's mentioning of the pastel colors of the blocks in the masthead. I've turned this around and asked Thien to explain why he thinks these colors work best. - Since there will not be any major changes in the design and our opinions I think we can conclude that the masthead project is finished. To be precise: the project is finished when a) we agree with Thien's arguments for the current colors; b) Thien changes the colors and we all can agree with that. I would like to go on and get the entire site redesigned (which is pretty much where we're going anyway). This means: - identify which elements need redesigning (e.g. tables, warnings, code blocks (pre) and such) - get Thien and Niclas to agree on doing the additional work WDYT? - On another level: there's the content. Let's pick the low hanging fruit here and make the 'PMC site' complete and up-to-date. This means: - identify what information goes there - remove duplicate information from the various versions - verify all information and add/update if necessary WDYT? Bye, Helma
Re: [graphics] Artwork for cocoon.apache.org - final4
Grzegorz Kossakowski said the following on 1/3/07 14:15: Could folks working on this give any rough timetable? You have to keep in mind that the website is not fully 'done' yet. Apart from the masthead and the current front page some elements such as table styles etc. are missing. And I won't make the mistake of assuming I can design it 'similar' to the rest, since up to now Thien's versions were much better. The 'bottleneck' is now Thien's availability. He's getting married soon and apart from that we need to know if he's allowed/willing to go the extra mile. OTOH: if you only want to show screenshots, I could add enough of the content to the current 'final4.html' page to get a realistic impression. Bye, Helma
Re: [vote] Grzegorz Kossakowski as a new Cocoon committer
Daniel Fagerstrom said the following on 22/2/07 17:36: Hi all! I'd like to propose Grzegorz Kossakowski (aka Grek) as a new Cocoon committer. He has been around at the user list since 2003 and has been +1 Bye, Helma
[graphics] Artwork for cocoon.apache.org - new version
Guys, after some discussion back and forth with Thien we've decided on the next version: - the masthead is adjusted to improve the display of the search box and the apache feather when resizing. - the green blocks are better at the center than on the side. - we've added a prominent download block with the latest Cocoon version. - the page curl is gone. ;-) - the navbar below the masthead now has a home icon that would go to the home page of the PMC site, while the Cocoon Core 2.2 would go to the home page of the current block. - we've added older versions at the bottom of the menu - a flag is added for the French version (now that I think of it, that would only be applicable for the PMC site) - the color of the note at the bottom is changed Note that when resizing to 800x600 the News section will creep up in the space between the blocks and the About box on the right. It might not be elegant, but it's better than the alternative of variable width blocks. We've discussed the possibility of changing the design of the Cocoon 2.1 website to this new design and most of you decided against it. Fine by me, but I think the PMC site should be definitely changed to this new design. All in all I think this design looks very good. If you agree, I would like to go on and ask Thien for further restyling of elements we're currently missing such as tables, code snippets, images + captions and warnings. Please add other elements if I forgot some. Bye, Helma
Re: [graphics] Which site to redesign?
Jeroen Reijn said the following on 12/2/07 13:22: Btw did somebody else also notice that the CSS behaves different in IE6 and FireFox 2.0? In IE the menu runs through the image left to What is Apache Cocoon and the green blocks on the right align differently. I'm currently working with Thien on an update, so I'll see if this problem is still there in the new version. Bye, Helma
Re: Site structure
Reinhard Poetz said the following on 9/2/07 10:00: actually we have it under http://cocoon.apache.org/2.2/ (Vadim convinced me at this point) I think it would make sense to have a subprojects or projects or something like that directory and put the servlet-service and configuration into it. Hold on! .../subprojects/... would give indications about using it in 2.1 and that's not true. I'd be more inclined to change it to http://cocoon.apache.org/2.2/subprojects/servlet-service/ http://cocoon.apache.org/2.2/subprojects/configuration/ --^^^ Bye, Helma
[graphics] Which site to redesign?
Guys, I'm currently working with Thien on a new version of the masthead. I'm sure you've noticed that it has gone beyond that. ;-) I'd like your opinion on the following: should the new design be used only for Cocoon 2.2 and beyond or also tweaked a bit and used for 2.1? I more or less assumed the latter, also because I think it should be used by the PMC site (using Reinhard's words), but reading the site structure thread I started wondering. WDYT? Bye, Helma
Re: [graphics] New version of masthead - update
Vadim Gritsenko said the following on 7/2/07 16:11: hepabolu wrote: Awesome! Looks good ... but ... is that a page curl beside What is Apache Cocoon ? *shudder* I suppose it is. I think it's very well done, no tackiness about it. What makes you shudder? I'm not crazy about this page curl as well... Would it perhaps be better to move both What is Apache Cocoon? and next one to the separate About page? The page curl: I'll leave that to Thien. The content of the box: I think you need to have it there, maybe not in full but as a first time visitor I want to know what I'm looking at and if it's on the front page, I get my questions solved in seconds which gives me a good impression of the project. Bye, Helma
Re: [graphics] New version of masthead
Sylvain Wallez said the following on 6/2/07 08:49: Mo :-) Don't confuse your cows and your sheep. ;-) Collecting opinions is good, but we also need to define the decision process to avoid endless discussions and frustration in the end for those that may have the feeling the decision was imposed on them. +1 Having Thien and Helma making the final choice is fine if everybody knows it in advance. Thanks for the vote of confidence. I'm working with Thien now to fix some details. Bye, Helma
Re: [graphics] New version of masthead - update
Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. Bye, Helma
Re: [graphics] New version of masthead - update
OOPS now the link: http://people.apache.org/~hepabolu/final2.html Bye, Helma On 2/6/07, hepabolu [EMAIL PROTECTED] wrote: Guys, Thien did it again: - he changed the masthead, making it a bit smaller and darker. - he also added a search box and changed the color of apache cocoon to be more prominent. - he removed some tiles to make things look better at 800x600. - the green blocks are now moved also to make things look better at 800x600. - the green blocks are also a bit darker. - he added nice icons to the content. In short, I'm very happy with this result. Bye, Helma -- Bye, hepabolu
Re: [graphics] New version of masthead
Peter Hunsberger said the following on 6/2/07 16:07: involved in web site design I do think we need to go through a limited critiquing process and that the development community is as good of source of opinions as any. +1 We need to agree on something that we all like, more or less. If you visit any project's website you get the end result whether you like it or not. In this case we have a choice, so we might get consensus. I'm not opposed, but I'm not sure that getting more opinions will help any? What value do you think they would add? I agree that asking for more opinions will only give you more _different_ opinions. I'd say the discussion about the new website design is a privilege of the committers. Bye, Helma
Re: [graphics] New version of masthead - update
Awesome! Looks good ... but ... is that a page curl beside What is Apache Cocoon ? *shudder* I suppose it is. I think it's very well done, no tackiness about it. What makes you shudder? Also, how would it look with Cocoon 2.1 somewhere in the top menubar too? True, that needs to be added. Bye, Helma
Re: [graphics] New version of masthead
Reinhard Poetz said the following on 5/2/07 11:17: Daniel Fagerstrom wrote: But it takes a little bit to much screen real estate IMHO. It is a little bit higher than our current look and nearly twice as high as the masthead and top menu for Spring framework. Would it be possible to rescale it so that it takes a little bit less space? could be worth a try I wouldn't compare it to different websites. This is OUR website and we should agree on it, no matter what size. I now miss the search box that could be in the header as well. Please note that shrinking the masthead will also take the air out of the design and I suspect that it will give a cluttered and crammed look. And don't forget you guys voted for the blocks, so you have to live with it. ;-) Also the getting ... boxes dominates the page a little bit to much for my taste (at least on my screen), they look quite heavy compared to the blue fade out in the mast head. Would it be possible to make them less visually heavy? I like these boxes as they are. IMO they should be the eye catcher number one of the homepage. I wouldn't change them. I fully agree. This is our home page and the eye catcher. Other pages will not have these green blocks, so don't worry. I resized the page to 1024 x 768 and it still works well and leaves plenty of space for the content. I assume that the majority of (potential) users will be developers that will have screens at that resolution or better. So I'm all for a minimal best resolution of 1024 x 768 and improved aesthetics. Bye, Helma
[graphics] New version of masthead
Guys, Thien did it again. He created a great new version of the blocks masthead and redesigned the rest of the homepage. http://people.apache.org/~hepabolu/final.html I don't want to bias you, but I like it a lot. ;-) WDYT? Bye, Helma
Re: [graphics] New version of masthead
Ralph Goers said the following on 4/2/07 22:51: Wow! :-) Very up-to-date and hip reaction. Bye, Helma
Re: [graphics] Artwork for cocoon.apache.org - next steps
Steven Noels said the following on 31/1/07 10:13: On 31 Jan 2007, at 07:51, Reinhard Poetz wrote: - Although I would like to have it, it is difficult for us to maintain a breadcrump navigation like Apache Cocoon Cocoon Blocks Cocoon Forms [Introduction] as we can't auto-generate them using existing (meta) data. As long as we don't have a good idea of how to do it, we should avoid having one. What's the (Daisy?) issue here? It sure is possible to have breadcrumbs + normal nav on one page - just a matter of processing the same navtree twice. That's the caveat: if the page is not in the navtree, there is no breadcrumb to be generated. I'm working on it. Bye, Helma
Re: [docs] Working with Cocoon from trunk
Mark Lundquist said the following on 20/1/07 19:22: OK... so what is the deal with http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1285.html This is the part that goes on the main site. Use this for document creation. http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g1/1285.html This shows the website layout and (I think) is used for site creation. AFAIK it's used for verification only. Looks like identical page content, but the nav tree is different...? It is the same page (look at the document number). Bye, Helma
Re: [docs] hr?
Grzegorz Kossakowski said the following on 20/1/07 22:09: Mark Lundquist napisał(a): Makes sense, OK... Heading 2 has the look I want (with its bottom border) — at least in Daisy, not sure when it gets exported to Forrest... I see your problem with images... I don't think it's good option to put images into headlines and rely on the rendering of Daisy. But if there is no better option... My random thought was to insert normal text into h1, place images on the right and let text flow on the left from them... Not so pretty and clean but safer IMO. Focus on content, not on layout. That's why we moved document creation to Daisy. Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
Hi everyone, Thien has kindly provided some awesome designs for the masthead. Thanks Thien! I've put them up at: http://people.apache.org/~hepabolu/all.html The 'all' page contains all designs at once for easy comparison, the top line contains links to four identical mockups with one of the mastheads. I'll share my opinions later to avoid immediate bias. Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
Thien said the following on 19/1/07 11:56: A little explanation to the visuals. Let me first say, I think all are fabulously done and show off your skills. 1. Typical masthead design, the dark area has the word cocoon drawn in a Lego-like look. To me this one felt like: the old one but done better, nothing new under the sun. 2. Tried a few other colors, find that green match quite well with the logo's blue, here's a simple and nice layout, with a bit of Web2.0 touch I like this one, although there's something to be said for #4. 3. Trying to describe the lightness and agility of cocoon with randomly positioned square that can be taken out or repositioned without affecting each otherok, maybe not too obvious :D My first impression: the kitchen tiles of Mum's kitchen. ;-) 4. Cocoon and nature, probably not the most appropriate association, but I wish this tells something about the framework's being easy and friendly to use. Although I like the lightness and the colors, I immediately got an association with Windows XP's default theme, also dubbed here TeleTubby theme. If you could change the link to nature (after all a 'cocoon' is a natural thing) to something different this one would really stand out. Some modifications need to be made to the left navigation to match the new masthead, once it has been chosen. Sure, the individual pages are there just to give a better impression of how the masthead looks on an actual page. I hope I was not too harsh. ;-) Bye, Helma
Re: RFC: CForms Roadmap
Jeremy Quinn said the following on 9/1/07 13:12: The next level of complexity, is all of the groups and layout stuff in the cforms xslt. In hindsight, it seems this could have been done cleaner in a separate namespace, but we do not have that option now, unless we want to force everyone to completely re-work their form templates etc. However, I do find lots of inconsistencies with the layouting code . for instance, I have not found a way to combine the layouting tags with stuff like repeaters and as you say, there is possibly too much usage of tables. I would love to see more of the layout structure use divs and css, but this was not done originally I suspect as these types of layouts are more difficult to achieve. I once started (way back when 2.1.7 or 2.1.8 was released) to convert the XSLT to divs and CSS, replacing the tables. I ran into problems with the autoformat settings like columns and rows, because there is no way to get that flexibly working without tables when you have no clue what type of widget it is and how long the label is. Also: fieldset is rendered differently in different browsers, that would mean you have to apply CSS hacks for all possible browsers thus moving the complication from XSLT to CSS. Just my 2ct. Although I'd love to tinker with this some more. Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
I'm just curious to know how things are progressing. Any news? Bye, Helma
Re: Current status of the new documentation
Jeremy Quinn said the following on 6/1/07 20:22: OK, I only have 'guest' under the role menu, so I assume someone has to enable me as a doc-editor? Fixed. Your default role is doc-editor, but I've also given you the doc-committer role (since you're a committer ;-) ) which is allowed to put documents live. HTH. Bye, Helma
Re: Docs for 2.1.10
Carsten Ziegeler said the following on 21/12/06 12:38: Ross Gardler wrote: Thanks for the info! One final question :) where do I find the docs for 2.1 in Daisy? Fairly important I suppose... http://cocoon.zones.apache.org/daisy/documentation/659.html Hmm, that does not look like the docs I find at http://cocoon.apache.org/2.1/ If you haven't found it yet: the Legacy docs in Daisy are the current 2.1 docs. It starts about here: http://cocoon.zones.apache.org/daisy/legacydocs/about/index.html Bye, Helma
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Vadim Gritsenko said the following on 18/12/06 17:14: get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. +1 Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
Jorg Heymans said the following on 7/12/06 09:06: Niclas Hedhman wrote: 3. PNG scaling == big problems. 4. Thien normally works with Illustrator, and handing over SVG instead of rendered PNG is not a big deal. I see your point. Well as long as Thien is happy in the end that's fine then :) Off-Topic Thien: how good is Illustrators SVG output nowadays? I had to process its output once and remember having to manually clean up each file to stop Batik from barfing during rendering. The way it embedded fonts, used custom elements and namespaces etc seemed to completely confuse the renderer. This was 4 years ago though, so i'm just curious to see if batik and illustrator have evolved since then ;) /Off-Topic From my very limited experience (creating simple things in Inkscape and continu in Illustrator because of easier to use features): - text blocks created in Inkscape give problems in Illustrator (CS2): they end up as gray blocks and Illustrator complains about fonts if they happen to be unavailable. I haven't yet found a solution other than going back to Inkscape, change the fonts and redo the steps in Illustrator. - there is something different between positions and scaling between Inkscape and Illustrator: a drawing that is centered on the page in Inkscape is suddenly half way off the page in Illustrator. There are issues, but I'm not sure if it's a major problem. We might do a reverse check: Illustrator SVG to Inkscape and see what happens. Just my €0.02 Bye, Helma
Re: i18nTransformer problems with static pages
Ard Schrijvers said the following on 5/12/06 12:40: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch As a friend of mine says: it's always amazing to see how easy it is to make Cocoon do very difficult things when it is so hard to make it do the trivial things, so by all means submit your transformer and I'm your first customer. ;-) Bye, Helma
Re: Releasing 2.1.10
Carsten Ziegeler said the following on 4/12/06 14:08: It's time to release again - thanks to Bruno we have solved the rhino licensing problem now and imho nothing is preventing us from a release. If there are no outstanding issues I will assemble a release next monday (11th), put it up for downloading and testing and if nothing bad happens do the release of that assembled version on monday, 18th. +0, won't be able to help though Bye, Helma
Re: i18nTransformer problems with static pages
falcorn said the following on 4/12/06 13:47:
I removed dtd declaration and xml:space attribute has gone;
But there is declaration of xmlns:i18n at html tag.
And IE dosen't like this attribute. I get blank page.
In FF everything is correct, I only get some warrnings from Tidy that there
is not standard attribute at html tag: xmlns:i18n
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
xsl:template match=*
!-- remove element prefix (if any) --
xsl:element name={local-name()}
!-- process attributes --
xsl:for-each select=@*
!-- remove attribute prefix (if any) --
xsl:attribute name={local-name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates/
/xsl:element
/xsl:template
Add a generic catchall template or you end up with nothing:
!-- = --
!-- generic catchall template --
!-- = --
xsl:template match=text()
xsl:copy
xsl:apply-templates select=text()/
/xsl:copy
/xsl:template
HTH
Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
Vadim Gritsenko said the following on 1/12/06 01:18: hepabolu wrote: All: I know it is quite early for this, but in order to review the galleries of samples that Thien will be delivering ;-) we need a space to put them. I don't mind to help out in getting them uploaded, but it would be nice if it's not a public place such as the wiki or Daisy on the zone, people.apache.org/~yourname or zones is perfectly fine for this, imho. Right, I think for now my space will do. If we have reached some agreement we could put it out in the publicity of the zones. Thien: Once you have something to show, just email me and I'll put it up on my space. Bye, Helma
Re: [graphics] Masthead artwork for cocoon.apache.org
Mark Lundquist said the following on 30/11/06 12:48: Niclas Hedhman wrote: I have just hired a Graphics Designer here at CodeDragons, and we don't think we will manage to fill his pipeline with commercial work from the start. I have previously promised that he will be available some of I'm sorry I missed this announcement completely. the time for work at Cocoon. He knows html and css a little bit, but it is not his I'll take on this part of the job. main skill. He makes graphics. Icons, logos, photo assemblies and so forth. His name is Thien Luh Tay, and will shortly start subscribing to this list, I'm not sure if you read this already, but anyway: welcome Thien. OK, well, I have in mind a Cocoon task for a graphics designer! There've been discussions here before about how the main Cocoon site needs a face-lift... compare cocoon.apache.org with maven.apache.org or springframework.org, the latter two sites have a clean, light look, and they feel modern. The Cocoon site looks heavy, kinda thick and blocky and old-school. +1 (Thien: this means I agree) I'd like to see some choices for a new treatment of the masthead/banner region along the top of the page. Just that. Not looking for a full page design here, just a different look across the top. The real site revision would incorporate some other things as well, like different visual styling for the nav sidebar, but for now let's just concentrate on the masthead. This sounds like a good idea, although I do think that the masthead/banner has a large part in the definition of the look and feel of the site. In other words the final choice for the banner is also a global decision for the look and feel of the rest of the page. Still, small steps can take us where we want to go. Here are the branding rules I would propose... 1) Elements that must be retained from the current design: (a) the Apache feather logo (though preferably reduced in size from how it appears on the site today) +1 (b) the Cocoon logo. The cocoon logo may appear in either of two forms: (i) as unadorned, stylized text, as in the current masthead on cocoon.apache.org, or (ii) as text within its traditional frame of a bordered, oblong field with rounded ends as seen on cocoon.apache.org/2.1 under the heading Apache Cocoon. I think the Cocoon logo is cool and conveys a strong identity, we should keep it. I agree that we need a Cocoon logo, although I'm not set on this one. I personally don't think this logo is cool, but I won't start a fight over it. 2) Elements that /need not/ be retained (may, but need not be): (a) the text the Apache Cocoon Project Depends on the logo. I agree that the name Cocoon should not appear twice in the masthead. (b) the text http://cocoon.apache.org; +1 (c) any of the current color scheme. I'd like to see a range of concept samples using variety of color palettes. In particular, the colors used by the Cocoon logo can be varied. I think I would still like the logo text to be either black or white depending on the background color, but the background color can be anything that looks appealing with the rest of the artwork and color palette. +1 I prefer sophisticated colors to screaming yellow and orange and the like. From there on out, it's wide open! I would love to see a half-dozen or so different ideas, and then we can see which ones people think are the coolest :-). +1 Thien: if you take on this assignment (and I do hope so), please start asking any question you'd like to be answered. Do note that you have a lot of listeners and a few people responding, which doesn't mean that the others don't care. All: I know it is quite early for this, but in order to review the galleries of samples that Thien will be delivering ;-) we need a space to put them. I don't mind to help out in getting them uploaded, but it would be nice if it's not a public place such as the wiki or Daisy on the zone, to avoid endless discussions (which we will probably have anyway) with a huge group of people. content that matters... and I agree — however, improving the content vs. styling require different skill sets and don't really compete for resources, so I say let's work on both at the same time, 'cause visual impressions matter, too :-) True. Bye, Helma
Re: The Cocoon documentation: a lot has happened here
Arje Cahn said the following on 6/11/06 16:29: News on the homepage: excellent!! I love it. It would be better if we could have the date presented as part of the title: # 10/18/06: News Management in our Docs smallsubmitted by Ross Gardler, 10/18/06 9:59:32 PM/small I tend to disagree on this, although in the new and flashy design I could have the date be displayed more prominently. Although this is fine with me, I got lost in the subsite-principle. I'd much rather have a single navigational structure for all parts. It took me a while before I noticed Cocoon core in the top navigation, clicked on it and got to something that looks like the same website, but has a completely different navigation. Maybe I've missed out on this discussion, but it makes it really hard for me to find things What is the reason for this? The current navigation is a mixture of navigation describing the new site and navigation for documentation committers. IIUC the parts below Website Only in the core site display the navigation that is shown on the site. The Main Site part is the top-level, i.e. the menu shown on the top left when you start with the site. The other parts (Core, Blocks, Maven plugins) are tabs on the top right in the light colored bar below the header. The Site Overview part is intended for a global navigation in Daisy. All other parts of this navigation contain information on documentation specific topics. All the subsites (below core) are intended for the specific block. The navigation defined in that block is also included in the site. I fully agree that this setup is not very clear and straightforward. Still, I think this is the best trade off between a setup for an automatic website creation and a clear place to jump in to write block or core specific documentation. On a sidenote, if someone has a drawing of the Cocoon 2.1/2.2/3.0 architectures (sketch would be fine), I could get it redone by the guy who is currently redesigning Hippo's architectural diagrams. Same goes for the 'pipelined transformation' graphic. Could explain a lot if we would have that on the homepage! Great! Thanks for the offer. Now, is there anything we can do about the Wiki pages? There have always been quite a bunch of pages that on the Wiki that deserve to be moved into the documentation. Also, the Wiki used to have a very low entry barrier, it would be easier to use that as a sandbox and move finished docs into the documentation website. True, I've been moving obvious pages to Daisy already. However, I think we need to have a common agreement on the role of the wiki. E.g. if some user wants to write documentation, where should he/she be doing that? The wiki? Give them an account for Daisy? I know we've had a similar discussion about a year ago but nothing definitive came out of it. I think now is the time to make a decision. Bye, Helma
Re: [SITE] - Contributions to this relase....
Antonio Gallardo said the following on 30/10/06 01:08: Hi folks, In http://cocoon.apache.org/2.1/changes.html we read for each release: snip Contributors to this release We thank the following people for their contributions to this release. This is a list of all people who participated as committers: [Committer's list] This is a list of other contributors: [contributor's list] /snip I wonder if we can improve the sentence: This is a list of other contributors: In particular I don't like the other contributor concept. Perhaps it is because I am no a native english speaker. Perhpas we should review the whole section. I really don't care less who contributed what and to which release. IMO we have a (read: ONE) release-independent committer list and, if we so choose, we can have a list of contributors, although we should specify the difference between committers and contributors. Bye, Helma
Re: [RANT] The Cocoon website: move on, nothing is happening here
Ross Gardler said the following on 18/10/06 23:36: Daniel Fagerstrom wrote: [news items] Guys, I wholeheartily welcome your ideas of news items and I fully agree with Ross that they should be entered in Daisy directly. If Daisy can be configured to auto-publish after a delay, that's great. Daisy can be used to create blog like pages that can be automatically brought together into a news page. I agree that it should be the home page, but Daisy would not limit the info to just this page. Perhaps 3 items on the home page, and a larger news only page. Note that Daisy can also be made to create RSS feeds, but that's a next step. I was thinking right along these lines, so I fully agree. Alternatively, have the site generation pull content from peoples existing blogs. Forrest has a plugin for this (although it is pretty basic), I'm sure Maven can be made to do it. The problem with this approach is that there is no control over the content that is published. I agree, I'd rather have a list of blogs of Cocoon committers/users than pull content directly from their blog. This, however, is of secondary importance. Let's focus on improving/extending the actual documentation content first. Of course there are lots of other ways, but they involve new tools so I'm steering away form those. Thanks for not going into tools discussions. First I think we need some common idea about what is a news item. Some suggestions would be: All your suggestions look just fine, I'm sure having an exhaustive list is impossible, but your list is a great starting point. I'm more +1 concerned about *who* will write these items and who will publish the site frequently. It really is a case of providing a login and password to a publishing tool after it is configured. As said earlier: I volunteer to run the process to publish the site as long as I don't have to do more than start a script, provide a login and password and get clear error messages (preferably none at all) that tell me where to look for the trouble. Posting to the list is just a step too many in my view. Why not put it straight in Daisy where it can be edited and published quickly and easily. Don't forget Daisy edits are already sent to the docs list. True, as is pointed out earlier posting news to the dev list takes more work because it needs to be copy and pasted into Daisy, while you can enter it in Daisy straight away and be done with it. I support the above as a small step, I think it may encourage more people into using Daisy a little. Great points. Thanks. Bye, Helma
Re: [RANT] The Cocoon website: move on, nothing is happening here
Bertrand Delacretaz said the following on 18/10/06 13:56: Thanks Arje for starting this thread. +1 Guys, since the documentation is my main focus, I want to chime in here. Re the redesign of the website: I haven't discussed this much with Reinhard, but my intention was a new revamped website once 2.2 is released. Revamped does not only include new shiny looks, but IMO also a restructuring of the info and a more lively homepage. When Daisy was put up on the zones as our main documentation repository, I had already planned for a restructuring, but arguments that the URL space had to be preserved prevented this. So I decided to comply and wait for 2.2. Re the information is all over the place: I fully agree and since I became committer I've tried several times to get the role of at least the website and the wiki clear. I won't bother now to find all these threads. The discussions either turned into yet another tooling proposal or faded out when other more code-related topics appeared. My own lack of time and the fact that I wasn't able to motivate/scare/bribe/kick the rest of the community into writing documentation hasn't added much to the process. I do have to say that this didn't boost my motivation either. I know that open source projects thrive on voluntary work and that we should be grateful for all the work that's contributed, but I cannot dismiss the feeling that documentation is generally considered to be done by someone else, while we all curse the moment when we turn to the documentation and find it inadequate. I know that the current process of updating the cocoon.apache.org website is cumbersome, but still it's a whole lot better than the previous process. I really don't care if it takes one step or twenty, if in the end all I need to do is set a timer that reminds me to provide my username/password to start the update process every X days, I'd be glad to do that. However, that doesn't make sense when nobody bothers to write. Moving over the legacy documentation at the time was done with reuse in mind. However, that means that people, knowledgable of the topic, have to go over it and verify it. No such actions, give or take a few, have been done. Several people have written how documentation should be written and when I read the recent version I bitterly remembered reading almost identical stuff written by Dianne Shannon way back then. However, only few actual pages have been written. I've spent both Hackathon days implementing the documentation infrastructure Reinhard has designed. Although I see some advantages in his setup, I didn't feel any pride over it. I merely contributed to more metadata, no actual documentation. This is where I think the main problem lies: - discussions on documentation on the mailinglists swerve off topic and into tooling and code before the fifth reply is in. - documentation is regarded as something evil/boring/without merits or whatever I agree with Bertrand that we should take small steps, but let's define the steps first and agree on this, put them up somewhere and stick to them. Let's not wait for the miracle of self-describing documentation, or the overall genius (me ;-) ) that can write it overnight. Let's simply agree that it's part of the job and should be done as well. For all the roadmaps that have been written, discussed and discarded, let us now finally write one for the documentation and stick to it. Use some of your code hacking time to write documentation. Don't wait for others to do, be the first to write. If you think documentation has to be perfect in the first instance, you're wrong. The only thing necessary is the correctness of the information. If you write it down in notes, full of spelling errors and grammar clashes, nobody cares and I'd be glad to go over it and polish it up. My proposal is: I start several new threads regarding the documentation on this mailinglist. Each thread contains a single topic, e.g. position of wiki vs Daisy, documentation structure, documentation roadmap. We can discuss the various ideas but WE REMAIN ON TOPIC or start a new thread. The end result should be one or more documents in Daisy that express our consensus on what the documentation should look like and how each community member can contribute and which rules we have to live by (e.g. no code release unless there is sufficient documentation). And once we agree (whether through voting or through general consensus I don't care), we stick to it and follow it through. Sorry if this sounds a bit emotional, but that's how I feel. Bye, Helma
Re: RFC: CForms + Dojo: the way forward
Jeremy Quinn said the following on 6/10/06 20:47: On 6 Oct 2006, at 18:46, hepabolu wrote: Jeremy Quinn said the following on 6/10/06 16:42: Hi All We had an informal group discussion on Tuesday at the Hackathon about CForms. The purpose of the discussion was to find a consensus on the direction to take CForms, so that everybody who would like to work on it is hopefully going to take it in the same general direction. These are some of the points that were raised and some of the tentative conclusions we reached. All these sound very good. I'm not sure if I can help out, but I'll contribute to the discussion if necessary. There is one issue I had/have with dojo that I would love to see addressed: dojo cannot be used in XHTML because it relies on dojotype attributes in various HTML tags. When I asked the dojo team they waived the issue with switch to HTML. I don't think that is a valid argument in a Cocoon environment. It would be great if you/we could find a solution that solves this issue. In XHTML could you not declare the dojo namespace and do this ? dojo:mywidgetblah/dojo:mywidget or div dojo:type=MyWidgetblah/div Namespaces is not something I create easily, but I'll look into it. I have read that instead of using : div dojotype=MyWidgetblah/div you can (or should soon be able to) use a class attribute : div class=dojo-MyWidgetblah/div Comment #5 : http://blog.dojotoolkit.org/2005/10/13/new-widgets Hmm. I've read this too, but at the time (about a year ago) not all dojo-widgets complied to that convention. I'll look into it to see if it is improved. In short: I'll see if I can find a solution and let you know/commit it. Bye, Helma
Re: RFC: CForms + Dojo: the way forward
Jeremy Quinn said the following on 6/10/06 16:42: Hi All We had an informal group discussion on Tuesday at the Hackathon about CForms. The purpose of the discussion was to find a consensus on the direction to take CForms, so that everybody who would like to work on it is hopefully going to take it in the same general direction. These are some of the points that were raised and some of the tentative conclusions we reached. All these sound very good. I'm not sure if I can help out, but I'll contribute to the discussion if necessary. There is one issue I had/have with dojo that I would love to see addressed: dojo cannot be used in XHTML because it relies on dojotype attributes in various HTML tags. When I asked the dojo team they waived the issue with switch to HTML. I don't think that is a valid argument in a Cocoon environment. It would be great if you/we could find a solution that solves this issue. Bye, Helma
Re: [RT] User poll to find unused components
Bertrand Delacretaz said the following on 3/10/06 12:05: On 10/3/06, Sylvain Wallez [EMAIL PROTECTED] wrote: ...So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution... +1 on the idea, a first step might be to do this for blocks before going down to the level of components. +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. Bye, Helma
Re: [RT] User poll to find unused components
Sylvain Wallez said the following on 3/10/06 13:26: Geert Josten wrote: +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. How about letting users classifying blocks as used: a) always, b) often (most of the time), c) rarely (only once or twice)? (and asking them how many webapps they have build using Cocoon) Sounds more informative to me than a top 5.. Sure. Defining the top 10 or top 5 is then the result of aggregating and compiling all information provided by users. First off: I definitely agree that more information gives a more informative choice. However, it's no problem to ask a lot of information of the users, but we have to make the process quick and easy. Defining a top 5 of your favorite blocks is a quick response to a mail. Walking through a list of predefined blocks and adding a, b, or c takes more time and I do hope that people will take the time to walk through them. If we want the abc options, we need to carefully construct the poll to avoid putting off people. Bye, Helma
Re: [RT] Simplify flow usage
Carsten Ziegeler said the following on 29/9/06 09:19: If noone objects I will add the stuff in the next days. I like the feature but not the location as flowscripts are not configuration files. What about ./flow only? Ok, it seems that everyone here is in favour of using just flow without an additional sub directory. I'm fine with that. How much extra effort would it take to allow overriding the location in e.g. the sitemap? E.g. as an attribute in map:flow map:flow location=my/own/path/to/flow/ Bye, Helma
Re: [RT] Simplify flow usage
Reinhard Poetz said the following on 29/9/06 11:14: Carsten Ziegeler wrote: hepabolu wrote: How much extra effort would it take to allow overriding the location in e.g. the sitemap? E.g. as an attribute in map:flow map:flow location=my/own/path/to/flow/ That shouldn't be difficult - but then the question is if this is overriding the default location or an additional location? You mention overriding but I fear others want to have an additional location and then someone comes up and wants to be able to specify more than one location :) I think we should keep it simple: Either someone puts all scripts into ./flow or he has to declare them using map:flow/, more smells like FS. Agree, but since it's more part of the application like Bertrand pointed out, I favor a way to override the default location. So: - default = all *.js in ./flow - some specification somewhere = all *.js in my/own/path/to/flow - different locations = use map:flow/ (which is also backwards compatible) WDYT? Bye, Helma
Roadmap for 2.2 (was: Re: Maven dictatorship and software parasitism)
Carsten Ziegeler said the following on 29/9/06 12:12: but I'm not very enthusiastic about it as imho time and energy could be used in different places. Let's get this 2.2 release out *now*. I agree, but does anyone know what is needed for this? I went as far back as May 2005 but every topic on roadmaps and release plans for 2.2 get mixed up with discussions on related topics/ideas/opinions etc. I've seen the phrases documentation is lacking and documentation is lagging behind several times, and would love to do something about it, but I have no clue where to start and what to do. Maybe a few of us (Reinhard a.o.) should sit down at the hackathon and decide on the new documentation setup and present that to the rest for voting. At the very least we could write up a list of docs to provide. And guys, once again: if you feel like documenting, please go ahead and DO it in Daisy. If you want me to go over it to fix English and check it from the fresh eyes POV, just mail me (pref. off-list, since I'll catch that quicker). Bye, Helma
Daisy is down on the zones
Guys, Daisy on the zones gives a 502. In an attempt to fix it myself I wanted to follow Bertrand's link in the message below, but I'm not able to access it. So please help. Bye, Helma Bertrand Delacretaz said the following on 24/11/05 21:37: Le 24 nov. 05, à 20:56, Jorg Heymans a écrit : ...It seems like the zone was restarted, I can't see any daisy processes running. Correct - I have restarted the apps as explained in https://svn.apache.org/repos/private/committers/pmc/cocoon/cocoon.zones.apache.org/admin-notes/howto-restart-zone.txt There's one step missing in that file, apparently mysql needs to be restarted manually as well, I'll add that tomorrow to the instructions. Daisy seems to be back, the live demos should be back as well in a few minutes (I have restarted them using the commands in the cdemos user's crontab). This needs some more automation, for sure ;-) -Bertrand
Re: Maven info wanted
Reinhard Poetz said the following on 28/9/06 14:55: We have invested a lot of time into making trunk build with M2. And don't forget that it's much more than just compiling the thing. We have two archetypes, one deployment plugin, the documentation which is exported using Maven, a working integration build, reports and certainly much more. Also don't forget that releasing a Cocoon artifact has become very simple. And one last point: If you build Cocoon using some different build system I think that we cannot forbear providing Maven 2 metadata files (pom.xml) because many developers will ask for them. As said: I really don't care as long as I'm able to figure out how things work. For now I'm stuck on a 'build failure' on the line $mvn clean install eclipse:clean eclipse:eclipse as described in http://cocoon.zones.apache.org/daisy/documentation/g1/756.html and I have no clue where to go and find more info. I'll settle for Maven but then we need to devote considerable hackathon time to proper documentation. I don't mind doing corrections or writeups or whatever else that's needed to make documentation a coherent piece, but I need the initial info from you guys. Bye, Helma
Re: Creating a mavenized cocoon application
Leszek Gawron said the following on 7/9/06 13:55: As I suck in writing documentation I decided to summarize first steps to create a cocoon application in a blog entry [1] If anybody finds it useful I will continue the tutorial. The best thing would be if somebody more english fluent ports it to cocoon docs. [1] http://ouzo.squash.eu.org/2006/09/creating_a_mavenized_cocoon_ap.html Sorry for not replying earlier. This looks like a good idea, I could port it to Cocoon docs and give you more permissions there (if you don't already have them) to put the info in there. AND PLEASE CONTINU. Bye, Helma
Maven info wanted
Guys, I've watched the devlist with growing astonishment seeing how you got into Maven2 and under its hood at an amazing pace. My first steps into Maven v1 were not very successful and at the time clear documentation of Maven2 was non-existent. I suppose this has changed by now, but I'm still confused and heavily rely on your documentation of what arguments to call and what poms to setup. I guess I'm not alone in this and many current Branch users might be holding off the transition to Trunk because of the magic maven mumbo-jumbo that has to be done. Don't get me wrong, I'm not criticizing the use of Maven, I merely find it very difficult to understand what's going on and why things have to be done the way they are done. What I'd like to see is some documentation on how to do things for Cocoon, but enhanced with links to the relevant information about Maven2. I'm sure you all have your favorite (web)sources, so please share them. At the least: send me a list of your favorite URLs (and please hold off the link to the Maven homepage) and I'll compile a Daisy page with links. Thanks. Bye, Helma
Re: Maven info wanted
One reply to all the others: Leszek Gawron said the following on 27/9/06 16:25: I have managed to create a single blog entry about starting a mavenized cocoon application: http://ouzo.squash.eu.org/ It enlists all the commands you need to enter to create a valid cocoon application skeleton. Yes I noticed and I'd love to hold you to your promise of more installments. With your permission I'd like to integrate it the Daisy pages that already exist. Andrew Savory said the following on 27/9/06 13:10: Sounds like a good thing to work on at the hackathon too, perhaps. +1 Jorg Heymans said the following on 27/9/06 16:19: +1, Helma if you want i'll give you a hand getting past the initial hurdles and writing things up in Daisy. Good idea. (that is, if JBQ hasn't made the maven build obsolete by that time) I'm very curious to see Ant + Ivy building Cocoon. I don't mind which one it's going to be eventually, but I think that every build method needs links into the documentation of the project. Even links to Ant documentation as a courtesy to newcomers would be good. Sylvain Wallez said the following on 27/9/06 15:09: Hmm... not Cocoon-specific, but I'd like to suggest http://bluxte.net/blog/2006-09/17-52-51.html and all its sequels (related blog posts and comments) I've read the initial post and all its comments. I didn't follow through to the other posts, because I recognized my previous experience in your post: I couldn't get Maven to comfortably build my project and it felt very arbitrarily and artificial to split my project according to Maven's wishes. I suppose that before I start putting a big effort into writing about builds with Maven, we could use the Hackathon to decide on Maven vs something else. One more remark, something that was in the comments of your posts: Maven provides an easy way to build a consistent project website. I both agree and disagree. It's true that Maven gives you a consistent project site with the usual what, who, where and how to install stuff. I strongly suggest that Cocoon has a consistent way of providing this information in an easy to find place. However, proper documentation about the USE of the project, be it Maven, be it Cocoon or any other project, needs quite different tools. Using Maven for the Cocoon documentation takes us back from Daisy to handcrafted xdocs.
Re: Cocoon 2.2 documentation
Reinhard Poetz said the following on 23/9/06 11:56: hepabolu wrote: Reinhard Poetz said the following on 22/9/06 17:46: -- First, thanks for reading so far! If you agree, I would like that we use the new documentation structure in Daisy for our Cocoon 2.2 docs and polish the Maven skin. If we like we can even use Continuum to deploy our docs at What about the (Forrest) skin I created about half a year ago? http://web.inter.nl.net/users/hepabolu/cocoondocsskin/ I'll change it to Maven if necessary. Yes, that would be necessary. Have we already decided for your skin? If no, what would be an appropriate process to reach a decision? (e.g. contest + voting) I don't think there was a formal voting although there have been positive reactions at the time (Feb/March 2006). I'll leave it up to you to start the voting process and if everyone agrees, I'll start working on changing it to Maven. Bye, Helma
Re: Cocoon 2.2 documentation
Reinhard Poetz said the following on 22/9/06 17:46: -- First, thanks for reading so far! If you agree, I would like that we use the new documentation structure in Daisy for our Cocoon 2.2 docs and polish the Maven skin. If we like we can even use Continuum to deploy our docs at What about the (Forrest) skin I created about half a year ago? http://web.inter.nl.net/users/hepabolu/cocoondocsskin/ I'll change it to Maven if necessary. cocoon.zones.apache.org which would help us to find out how the result docs look like. A lot of stuff that we could trigger at the GT and I'd happily introduce to everybody who is interested in helping out. Count me in. Bye, Helma
Re: [GT2006] 17 talks proposed!
Arje Cahn said the following on 15/9/06 14:35: I think this is really awsome list of talks. What do you think?? GREAT! +100 Things your mother never told you about Cocoon (The secret gems of Cocoon rebranded) +1 wednesdaymorning 10 Reasons to use Cocoon +1 wednesdaymorning Cocoon reloaded: moving from xsp and actions to newer technologies +1 for hackaton day 2 talk Case studies -1 (there's already a couple of them..) An illustrated guide to Cocoon technologies +1 (good fun to have in the morning sessions) Cocoon archetypes (How to create a typical project with cocoon rebranded) +0 I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. Bye, Helma
Re: [GT2006] 17 talks proposed!
Andrew Savory said the following on 18/9/06 17:38: Hi, Arje Cahn wrote: I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? It all sounds good - and doing the article during the hackathon would be a great way to contribute for those of us (me included) that never manage to close bugs ;-) Great! I'll help out. Bye, Helma
Re: [GT2006] 17 talks proposed!
Arje Cahn said the following on 14/9/06 18:04: My first reaction was: can't we fit all of them in? Hold on... Are you suggesting we squeeze *all* talks to 30 minutes slots, effectively raising the number of talks from 8 to 12 ?? That's a *lot* of talks..! On the other hand, it would fit right in... If me and Reinhard only need 15 minutes, and Andrew drops 4 out of his 6 proposals, we'll have 11 30-minute talks left.. This is INSANE! If done properly, it could be very snappy and a lot of fun. But it could get really messy as wel.. WDYT?? As said: it was my first reaction, based on the fact that I'd love to hear all of them. Nevertheless, it would be great if we could pull it off. Some ideas: - is it possible to do two tracks? I.e. two rooms with speakers (one for Andrew and one for the rest ;-)), e.g. one more geared towards management (10 reasons to choose Cocoon) and/or beginners and one for intermediate or advanced level? - can some presentations be merged? E.g. some of Andrews talks sound as if they are a consecutive series of ideas, maybe they could be merged. - pick some talks and put the rest on a CD that can be bought (price to be defined). - pick some talks, put the rest on a website to be downloaded in advance and add an ask the expert slot where people can ask questions about the downloaded talks. - if some talks can be turned into a poster, we could put them up so people can have a look at them between talks e.g. WDYT? Bye, Helma
Re: [GT2006] Diners... Evening things.
Bertrand Delacretaz said the following on 13/9/06 11:07: On 9/13/06, Arje Cahn [EMAIL PROTECTED] wrote: ...I need to have a time on which to order the pizza's... I guess several of us have to start the day very early on monday morning to travel, so an early dinner might be good? 6:30PM maybe? IIRC last year's first dinner was good, and anyway I trust Arje about anything related to Amsterdamso whatever you feel is good for Tuesday is good IMHO. +1 from me. Bye, Helma
Re: [GT2006] 17 talks proposed!
Ross McDonald said the following on 13/9/06 14:07: No problem with a 30 minute speech, the shorter, the simpler the better! Same feeling here. Bye, Helma On 13 Sep 2006, at 12:56, Bertrand Delacretaz wrote: On 9/13/06, Arje Cahn [EMAIL PROTECTED] wrote: ...In total, we can host about 8 45-minute sessions, so we need to decide on which 8 or 9 talks have to go... Maybe some speakers would agree to bring their session down to 30 minutes? I'm willing to do it for mine, if it allows more material to be presented.
