Re[2]: [CRAZY IDEA] sitemaps in javascript
Hi, He suggested that the sitemaps should instead be written in a general purpose server-side interpreted language, maybe javascript. I was horrified at the idea at first, but I've been thinking about it a little more and I think he just may be right. Yes, I hear you all groaning :-) I think a fully scripted sitemap will lead to that users do more stuff in the sitemap as they really should do. It's maybe the same as with the JXTemplates and Flow today. * Eclipse has much better editor support for Javascript than xmap, with the several quality plugins available. Yep. Especially with the amazing Interakt JSEclipse plugin [2] IIRC someone has started the Lepido project to face that problem. -- * best regards * Jens Maukisch
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-31012006.jar -Dbuild=build/cocoon-31012006
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-31012006.jar -Dbuild=build/cocoon-31012006
Re: Java objects in JX templates
Not without a stack trace.
Bart Molenkamp wrote:
I've had problems with the following expression:
jx:when test=${java.lang.Class.forName( \
'com.bizzdesign.risks.assessment.UploadedEvidence'). \
isAssignableFrom(evidence.getClass())}
(the expression is one line).
This expression works, but somehow after calling the page a few times,
the application hangs. Took me a long time to figure it out. (I've
already solved it, simply by having a method
evidence.isUploadableEvidence() with the expression written in Java).
Does anybody know what might be going wrong? (I'm just curious)
Bart.
Re: [CRAZY IDEA] sitemaps in javascript
Jens Maukisch wrote: Hi, He suggested that the sitemaps should instead be written in a general purpose server-side interpreted language, maybe javascript. I was horrified at the idea at first, but I've been thinking about it a little more and I think he just may be right. Yes, I hear you all groaning :-) I think a fully scripted sitemap will lead to that users do more stuff in the sitemap as they really should do. It's maybe the same as with the JXTemplates and Flow today. Honestly, many people already do too much in the sitemap, and are eventing creative but frightening constructs that would be way cleaner and maintainable if written with a real programming language like JavaScript. * Eclipse has much better editor support for Javascript than xmap, with the several quality plugins available. Yep. Especially with the amazing Interakt JSEclipse plugin [2] IIRC someone has started the Lepido project to face that problem. I heard from this someone that a JS editor has never been in the scope of Lepido. Especially as one is provided with WebTools, although less featured than Interakt's plugin. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re[2]: [CRAZY IDEA] sitemaps in javascript
Hi, Honestly, many people already do too much in the sitemap, and are eventing creative but frightening constructs that would be way cleaner and maintainable if written with a real programming language like JavaScript. And you think its getting better if we open the door even wider instead of restricting more an providing cleaner ways? I heard from this someone that a JS editor has never been in the scope of Lepido. Especially as one is provided with WebTools, although less featured than Interakt's plugin. Yes, but a nice and usable sitemap-editor is certainly in the scope of Lepido, right? -- * best regards * Jens Maukisch
RE: Java objects in JX templates
java.lang.ClassNotFoundException:
com/bizzdesign/risks/assessment/UploadedEvidence
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
file:/app/was/installedApps/riskmanager/riskmanager.ear/riskmanager-1.1.
0.132.war/content/secure/reports/templates/ineffective-controls.xml:104:
93:org.mozilla.javascript.JavaScriptException:
java.lang.ClassNotFoundException:
com/bizzdesign/risks/assessment/UploadedEvidence
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process
XMLPipeline(AbstractProcessingPipeline.java:582)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:183)
...
Similair exceptions were thrown everywhere, saying that lots of classes
couldn't be found anymore (UploadedEvidence class was only one of them).
The application needed a reboot to get rid of this exception. Seems like
the expression, after being evaluated for several times, messes up the
class loader somehow...
Bart.
-Oorspronkelijk bericht-
Van: Ralph Goers [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 31 januari 2006 14:48
Aan: dev@cocoon.apache.org
Onderwerp: Re: Java objects in JX templates
Not without a stack trace.
Bart Molenkamp wrote:
I've had problems with the following expression:
jx:when test=${java.lang.Class.forName( \
'com.bizzdesign.risks.assessment.UploadedEvidence'). \
isAssignableFrom(evidence.getClass())}
(the expression is one line).
This expression works, but somehow after calling the page a few
times,
the application hangs. Took me a long time to figure it out. (I've
already solved it, simply by having a method
evidence.isUploadableEvidence() with the expression written in
Java).
Does anybody know what might be going wrong? (I'm just curious)
Bart.
Re: [CRAZY IDEA] sitemaps in javascript
Jens Maukisch wrote: Hi, Honestly, many people already do too much in the sitemap, and are eventing creative but frightening constructs that would be way cleaner and maintainable if written with a real programming language like JavaScript. And you think its getting better if we open the door even wider instead of restricting more an providing cleaner ways? Yes, because people invented these constructs because they needed it, and because the sitemap language wasn't expressive enough to implement their needs in a clean way. So adding more restrictions will IMO only lead to the invention of even weirder ways to circumvent them... I heard from this someone that a JS editor has never been in the scope of Lepido. Especially as one is provided with WebTools, although less featured than Interakt's plugin. Yes, but a nice and usable sitemap-editor is certainly in the scope of Lepido, right? Experience showed that the sitemap language is actually very simple, and that people quickly find it more productive to write their sitemap with a content-assist editor. In this regard, the WebTools XML editor auto-learning feature does quite a good job once a sitemap contains one instance of each of the base instructions (match, generate, transform, etc). Now, to speak clearly, I'm thinking about closing Lepido at Eclipse, first because for a number of reasons on which I could expand it didn't attract people, and because the future of Cocoon is so unclear to me that investing in the development of a tool that may quickly be obsolete looks like wasted energy. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
Question is is there an interim thing that we can release before whole
OSGi is implemented? We were talking about an RC when Maven build was
done, but we seem to be moving away from that.
Sure there are a number possible interim things.
We can release more or less as is, what is lacking is a Maven
correspondence of the block.properties file and a plugin that collect
and install the configuration snippets in the blocks to the webapp.
I'm working on that and the design of the block deployer already supports
property replacement. Only the implementation is missing but will come soon.
We can also release with non OSGi blocks. The blocks are ongoing work,
the most important thing that lacks is two level configuration. As
discussed before the component configuration is part of the block and
constant, so they need to be parametrized in some way for making them
user configurable. We have not had much discussion about how to do this
yet.
My understanding is that a user can parameterize a block at deployment (which is
supported by the block deployer) if he wants. Otherwise the default values are
taken.
Also the APIs and concepts for blocks need to actually be used for some
real life examples before we can be convinced that we got it right.
Of course. I'm working on getting trunk as far as making it very simple to use
it for custom projects. Then I will start to rework at least one of my projects
to use blocks and learn more about their real life usage. We should make it easy
that at least we developers (and some brave users) can start to experiment.
Gradual steps, release often is good.
Agree, but as it will be the first release from trunk the threshold is
higher.
IMO we should consolidate the current status and make trunk useable for projects
again which should result in agreeing on our external contracts.
Making life harder for future
exciting developments by releasing too early isn't good.
Exactly, one point i that trunk contains nice mechanisms for
parameterizing components and sitemaps at a global level and also for
having foreign component managers within sitemaps. While very usefull
for the current development style in Cocoon they are not very relevant
for blocks. For blocks we should avoid global configurations as it is in
the way for splitting Cocoon in small reusable parts. And also component
configurations in sitemaps is rather unnecessary when we have component
configurations on the block level.
So what should we do about introducing things that we know that we will
want to remove in a later release?
As long as we have milestone releases, I have no problem with sitemap
classloaders and sitemap application containers. If both features become block
functionality, people have to migrate. (IIRC also Eclipse had some incompatible
changes in their 3.0 milestone series.)
If this is the case, then it would seem timely to improve these
interfaces now, as 2.2 given the greater flexibility could become _the_
future Cocoon, and we may miss the boat if we don't make this change
now.
Yes, I feel some urgency. With enough focus and dedication on
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
regain its momentum. Focusing on 2.2 seem more like losing valuable time
for me.
Well, define 2.2 :-)
I presume you mean releasing a Maven based Cocoon without a ready blocks
system would loose valuable momentum.
Yes.
Do you have a roadmap on what's open?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Extending the image reader
* Upayavira: Ah. And currently the cache doesn't survive restarts in the CLI, which it should. So your approach is now more understandable. AFAICT it does not survive restarts in servlet mode either, notwithstanding the before-to-last argument set to true (corresponds to diskPersistent argument) passed to the Cache() constructor called from EHDefaultStore. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Created: (COCOON-1745) [cocoon-deployer-core] Tidy up test suite
[cocoon-deployer-core] Tidy up test suite - Key: COCOON-1745 URL: http://issues.apache.org/jira/browse/COCOON-1745 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz The test suite runs through (at the moment of writing this) but contains some wrong examples in parts that are not tested by assertions. This needs to be corrected so that it doesn't confuse people studying the code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1746) [cocoon-deployer-core] Automate mock block creation
[cocoon-deployer-core] Automate mock block creation Key: COCOON-1746 URL: http://issues.apache.org/jira/browse/COCOON-1746 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Write some Ant task that automates the creation of mock block archives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1747) [cocoon-deployer-core] Enable property resolving in deployment descriptors
[cocoon-deployer-core] Enable property resolving in deployment descriptors -- Key: COCOON-1747 URL: http://issues.apache.org/jira/browse/COCOON-1747 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1748) [cocoon-deployer-core] Create the cocoon:deploy Mojo
[cocoon-deployer-core] Create the cocoon:deploy Mojo Key: COCOON-1748 URL: http://issues.apache.org/jira/browse/COCOON-1748 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Implementation should be straight forward. Most work is reading in some plugin configuration (deployment descriptor file, properties file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1748) [cocoon-deployer-core] Implement the cocoon:deploy Mojo
[ http://issues.apache.org/jira/browse/COCOON-1748?page=all ] Reinhard Poetz updated COCOON-1748: --- Summary: [cocoon-deployer-core] Implement the cocoon:deploy Mojo (was: [cocoon-deployer-core] Create the cocoon:deploy Mojo) it's already created [cocoon-deployer-core] Implement the cocoon:deploy Mojo --- Key: COCOON-1748 URL: http://issues.apache.org/jira/browse/COCOON-1748 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assignee: Reinhard Poetz Implementation should be straight forward. Most work is reading in some plugin configuration (deployment descriptor file, properties file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1749) [cocoon-deployer-core] Create the cocoon block archetype
[cocoon-deployer-core] Create the cocoon block archetype Key: COCOON-1749 URL: http://issues.apache.org/jira/browse/COCOON-1749 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Create the archetype as described in http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1749) [cocoon-deployer-block-archetype] Create the cocoon block archetype
[ http://issues.apache.org/jira/browse/COCOON-1749?page=all ] Reinhard Poetz updated COCOON-1749: --- Summary: [cocoon-deployer-block-archetype] Create the cocoon block archetype (was: [cocoon-deployer-core] Create the cocoon block archetype) [cocoon-deployer-block-archetype] Create the cocoon block archetype --- Key: COCOON-1749 URL: http://issues.apache.org/jira/browse/COCOON-1749 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assignee: Reinhard Poetz Create the archetype as described in http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: AFAIK you can't call filters and listeners from within servlets, so they are at the servlet container level, and I don't see how a block would need them. A block could certainly need something that a listener put in a context attribute or that a filter did to the request, but that is another question. There was recently a discussion here about adding a servlet listener for some functionality in the xsp block - I don't know what, but the important message is that this will happen and already happens: some blocks need more than just the servlet: like listeners or filters or whatever the servlet spec requires. And as soon as a block uses these features you need a full servlet environment and not just a http request, response and context. In addition, I could imagine that Cocoon provides filters which might be used by other web frameworks running in the same web app as Cocoon. I might be wrong, but I think another issue is if you are using spring. Spring is initialized through a servlet listener and is assuming a servlet context to work properly. So as soon as you don't have the listener, you can use Spring in that way. Of course there are other ways of using Spring which would also work in a CLI but they do not leverage the special web functionality. So you either don't use that or you have two versions, one for the Cli and one for the web. I can imagine more scenarios for these kind of things and we could avoid all of them. The only drawback - if you want to call it drawback - is that the CLI is firing up internally a servlet engine. But I could imagine that this clarification of environments would also make the work for Forrest easier in the end. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: For me these things make more sense for a higher version than 2.2. I would love to get 2.2 out today with the main changes being ECM++ and the Maven build. I'm not so certain about this anymore as you can see in my answer to Upayavira. But go ahead and write a release plan, so that we can discuss what it will mean. Sorry, but I don't have time for these kind of things atm - so someone else has to do come up with a release plan if we want to have a release soon. But on the other hand, the maven build is not finished yet, and this is the first thing which has to work - currently you can't run 2.2 at all. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1750) Make tutorial I (simple block deployment) work - Part I
Make tutorial I (simple block deployment) work - Part I --- Key: COCOON-1750 URL: http://issues.apache.org/jira/browse/COCOON-1750 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Make http://cocoon.zones.apache.org/daisy/documentation/g2/796.html work: except: - Use a component of another block - Write your own component that can be used from another block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1751) Make tutorial I (simple block deployment) work - Part II
Make tutorial I (simple block deployment) work - Part II Key: COCOON-1751 URL: http://issues.apache.org/jira/browse/COCOON-1751 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Make http://cocoon.zones.apache.org/daisy/documentation/g2/796.html work completly - also cover topics that were excluded in COCOON-1750 - Use a component of another block - Write your own component that can be used from another block -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] The environment abstraction, part II
Sylvain Wallez wrote: Sorry, but I still fail to see how this changes anything. It makes it easier to develop with Cocoon as using the standard servlet API rather than with a proprietary clone eases the learning process and facilitates the integration with 3rd-party libraries. But does it change something for the internal code? I fail to see how. We get rid off the whole o.a.c.environment package - and this is the another step to make the core cleaner. I can imagine a lot of changes based on this one making the internal handling of requests easier to understand and implement. I never said it doesn't make sense, rather the contrary. But there's a difference IMO between let's use the standard servlet API and let's fire up a servlet engine to process a simple XML pipeline. Sure, but see my latest response to Daniel showing some use cases where you need the whole servlet engine. And I of course web apps have their servlet engine running, so there is only the cli left. But starting jetty inside is really a small thing and totally transparent from a user pov. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: 2.1 portal won't compile in jdk 1.3
Ralph Goers schrieb: I went to build with jdk 1.3 to make sure a change I'm in the process of validating works. Unfortunately, the latest 2.1 fails to compile. My guess is that portal bridges requires jdk 1.4? Does the portal now require 1.4? No, it seems that the bridges release has been compiled with 1.4. I'll talk to Ate tomorrow and ask him if they can come up with a new release for 1.3 or if we have to recompile bridges ourselves. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1753) XInclude transformer uses href fragment rather than xpointer attribute (spec conformance)
XInclude transformer uses href fragment rather than xpointer attribute (spec conformance) - Key: COCOON-1753 URL: http://issues.apache.org/jira/browse/COCOON-1753 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.9-dev (current SVN) Reporter: Jason Johnston The XInclude 1.0 spec (see http://www.w3.org/TR/xinclude/#include_element) states the following about the href attribute: Fragment identifiers must not be used; their appearance is a fatal error. Cocoon's XIncludeTransformer incorrectly allows xpointer fragments to be specified using a fragment identifier in the href attribute. The correct way to support xpointers is the xpointer attribute on xi:include, which the transformer does not currently recognize. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 2.1 portal won't compile in jdk 1.3
Carsten Ziegeler wrote: Ralph Goers schrieb: I went to build with jdk 1.3 to make sure a change I'm in the process of validating works. Unfortunately, the latest 2.1 fails to compile. My guess is that portal bridges requires jdk 1.4? Does the portal now require 1.4? No, it seems that the bridges release has been compiled with 1.4. I'll talk to Ate tomorrow and ask him if they can come up with a new release for 1.3 or if we have to recompile bridges ourselves. If the code compiles for java 1.3, the later is faster than the former. Best Regards, Antonio Gallardo.
[jira] Created: (COCOON-1754) [cocoon-deployer-core] Enable referencing of other blocks connections
[cocoon-deployer-core] Enable referencing of other blocks connections - Key: COCOON-1754 URL: http://issues.apache.org/jira/browse/COCOON-1754 Project: Cocoon Type: Sub-task Components: - Build System: Maven Versions: 2.2-dev (Current SVN) Reporter: Reinhard Poetz Assigned to: Reinhard Poetz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1755) [cocoon-deployer-core] Add more restrictions to schema files (block, deploy)
[cocoon-deployer-core] Add more restrictions to schema files (block, deploy) Key: COCOON-1755 URL: http://issues.apache.org/jira/browse/COCOON-1755 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz add some regular expressions to blocks (deploy.xml) and review types -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1756) [cocoon-deployer-core] More validations
[cocoon-deployer-core] More validations --- Key: COCOON-1756 URL: http://issues.apache.org/jira/browse/COCOON-1756 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz more validations are possible: - turn on schema validation of Castor - make sure that a block really implements an interface - make sure that only properties are used in block-deploy.xml that are set in block.xml - make sure that only connections are used in block-deploy.xml that are required in block.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1757) [cocoon-deployer-core] Support extends/
[cocoon-deployer-core] Support extends/ - Key: COCOON-1757 URL: http://issues.apache.org/jira/browse/COCOON-1757 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz extend/ isn't valued at dependency resolution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1726) Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=comments#action_12364767 ] David Crossley commented on COCOON-1726: Fantastic, thanks for this ability. It seems to work nicely. Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Attachments: patch.txt Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-31012006.jar -Dbuild=build/cocoon-31012006
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-31012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-31012006.jar -Dbuild=build/cocoon-31012006
Re: How to embed Cform in larger web site layout
Hi Peter,
On Jan 28, 2006, at 2:03 AM, [EMAIL PROTECTED] wrote:
I modeled a cocoon form (based on the registration example in the docs)
which I would like to incoperate into a classic web site layout (header,
footer etc).
Right... we Do That All The Time™ :-)
When I have done all the cform transformations the form is already in html.
OK, as someone else has pointed out, your form is HTML in two distinct senses, (a) it is expressed in the HTML vocabulary, and (b) an HTML serialization has been created by the pipeline you show below:
map:generate type=jx src=registration_template.xml/>
map:transform type=browser-update/>
map:transform type=i18n/>
map:transform src=forms-samples-styling.xsl/>
map:serialize type=html/>
As for (a), you will realize that the reason you have an XML document that uses HTML markup is that this comes from your JXTG template (registration_template.xml), and that if you don't want it to be HTML you can always write your template to generate some other kind of markup. I am going to argue that you _do_ in fact want it to be HTML (in sense (a)), but the point is that nothing's forcing it to be that way.
As for (b), you just need to make sure that you wrap your chrome around the form before you invoke the serialization to HTML. You do that with an XSLT that stylesheet converts the form template markup (HTML or whatever, see above and below!) into the final presentation HTML.
There are many ways to do this. Most obviously, you could add another transform> for that XSLT to the pipeline shown above. Better yet, you could have a common resource> that you would call at the end of the pipeline instead of serializing, and the resource comprises both the final transformation and the serialization, something like this (note, I write my sitemaps w/ a default namespace so that I don't have to write the 'map:' prefix all over the place):
resource name=to-html>
transform src=xslt/site/page.xslt /> !-- sitewide layout/styling -->
serialize type=html/>
/resource>
and then instead of calling the serializer at the end of your forms pipeline, you say
call resource=to-html/>
... which you also call from other pipelines that serve your other content.
So it does already contain the body> and head> tags. Now I would like to
include the cform in a larger HTML document. But the problem is the cform is
already html so would have to write an XSLT Transformation which transforms
the HTML to another HTML document. This is clearly not a clean solution.
On the contrary, it's a very clean solution (remember we are talking about transforming HTML markup to HTML markup, not serialized HTML to... whatever). You could invent your own little document language in XML, but why bother? That's what HTML is for, and you already know HTML. My sites typically have content that is written/generated in HTML that looks pretty much just like this:
html>
head>
title>A Fine Page This Is/title>
/head>
body>
Content, wonderful content.
/body>
/html>
and my site/page.xslt template turns that into something like this:
html>
head>
{...link> for stylesheets, meta> elements and all that crap, maybe some JS crap...}
title>FooBarCo, Inc. ::: A Fine Page This Is/title>
/head>
body>
{all kinds of layout/styling crap, masthead graphics, nav menus whatever other chrome there may be}
div id=main-content>
Content, wonderful content.
/div>
{more chrome, e.g. a footer or whatever}
/body>
/html>
So, you just write your form template to emit the same sort of simple, cut-down HTML as in the content example above, and then run it through the common styling template to get the chrome wrapped around it.
Finally, I recommend not talking and thinking in terms of HTML fragments :-). Working with fragments is not a fundamental web programming task. It's a specific idiom that is served by certain frameworks/languages. When you are working with XSLT, the key thought is not fragment or include, but template.
HTH,
—ml—
