Re: [CForms] Streaming out widget attributes?
Antonio Gallardo wrote: > IIRC, allowing to programmatically change the @required has been > requested by some users. Perhaps, we should try to implement it. I mean > in a similar way as currently we can programmatically change the @state > of a widget. It is already implemented :) > > Would this fill your need? > No :) Or, well, partially. I could solve it this way and already tried it. But the ajax request updating the model and rerendering the (partial) page is way to slow. So doing this completly on the client is much faster/easier. In addition, implementing client side validation for pre checking form values is currently not possible as there is no way to pass on validation information from the model to the stylesheets. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Sylvain Wallez escribió: [resent -- seems to have been lost] Reinhard Poetz wrote: Sylvain Wallez wrote: I'm sorry to say that over time, I found Cocoon to be more an obstactle for complex webapps pages (not talking about flow) than a real help, and that's why I'm moving away from it. So I don't care as much as I did... Can you give conrete examples on what these obstacles are? Well, here are some: - in complex use cases the GUI logic, as Carsten's use case exemplifies, becomes spread all over the pipeline, and it becomes increasingly difficult to understand what happens where. Could you explain how can you do the Carsten need easily with Wicket? - client/server communication with JSON makes it really easy to build Ajax apps, but is a pain to produce from Cocoon unless we directly send it from the controller, which actually makes Cocoon pipelines useless. Why everything needs to go through pipelines? - Dojo widgets are a nice replacement for CForm's styling stylesheets, reduce the server load, and again make pipelines less useful. Here is a trade off dojo reduce the server load but increase the client load and bandwidth: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=dojo+fat&q=b I am not telling dojo is bad, I like it, but I see here is a trade off. Dojo usage is not a free lunch after all. ;-) - enhancing the CForms styling leads to a giant XSL (even if modularized) where every possible styling used in the application must be present. It's not my experience. xslt allows us to just overwrite the required pieces to enhance the styling. - since only CForms has Ajax integration, people are over-using it for presentation purposes (e.g. paginated repeater) I agree with you, mixing binding with form definition is not good. We want to keep it separated. However, I think it is a first implementation wich show us a way to implement a paginated repeater after all it is not released yet. It is a work in progress. Is not fair to blame to a first draft implementation. Don't get me wrong: Cocoon is a killer for publication. But for webapps, other approaches, more Java-centric, are worth considering. My current choice is Wicket, which was just proposed for incubation. I took a fast look at wicket and I can see an analogy to building a form intensive application with XSP logicsheets. I already went this way and I can say it is not not easy to maintain the code. I mean it is the same code embedding concept with a new syntax sugar after all. Cocoon allows lots of non-Java people to build complicated stuff, and this is a major achievement. But I find it easier to write Java if you're fluent with it rather than finding workarounds in an XML-centric framework. I feel myself fluent in Java and I still prefer find faster to write a cform application using with cocoon. ;-) Best Regards, Antonio Gallardo.
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler escribió: Sylvain Wallez wrote Yes, now I see two solutions for this: we could just stream out the attributes of the definition (which are strings) or if we need all attributes, stream out attributes which can be streamed. I would go for the first solution, anything against this? Sounds hacky to me... Really? Why? You define something in the model which you want to access easily somewhere. Dumb question: why do you need these attributes in the XSL? Attributes were meant to allow additional information to be communicated between the application logic and the various event handlers and validators attached to widgets, whereas the XSLs are supposed to use the styling information for their job. Yes, but what if you need anything else apart from styling? For example "required" is passed from the model to the xsls. I want to pass on information like dependencies between fields, for example if field A has value 1, then field B is optional and if field A has value 2 field B is required. I need a generic mechanism here which just passes this information from the model to the xsls where I can generate some client javascript. IIRC, allowing to programmatically change the @required has been requested by some users. Perhaps, we should try to implement it. I mean in a similar way as currently we can programmatically change the @state of a widget. Would this fill your need? Best Regards, Antonio Gallardo.
[jira] Updated: (COCOON-1732) Ajax and IE empty textarea bugfix
[ http://issues.apache.org/jira/browse/COCOON-1732?page=all ] Antonio Gallardo updated COCOON-1732: - The ajax implementation shipped in cocoon 2.1.8 was dropped in favor of dojo [1] in cocon 2.1.9. Since there is no file called cocoon-ajax.jsin the trunk, we cannot apply the patch. :-( [1] http://dojotoolkit.org/ > Ajax and IE empty textarea bugfix > - > > Key: COCOON-1732 > URL: http://issues.apache.org/jira/browse/COCOON-1732 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Ajax >Affects Versions: 2.1.8 >Reporter: Fabrizio Sitzia >Priority: Minor > Attachments: empty_textarea_ie.txt, ie_empty_textarea.gif > > > Empty textareas in a repeater are displayed incorrectly by Internet > Explorer after a round-trip to the server (for example after > adding/deleting a row, or when a validation error occurs!) > Instead of being empty, the textareas display a garbled mix of text and > html-tags occurring in the html document. Submission of the form usually > won't work afterwards... > (See attachment for my post to the cocoon dev list, which contains the steps > for reproducing the bug, and a possible fix for it) -- 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
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 03 August 12:29 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-08-03 12:02:22 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] ... [get] last modified = Mon Jul 24 00:07:03 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] .. [get] last modified = Mon Jul 17 11:07:06 GMT+00:00 2006 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.input.projectInfo -- check-plugin: [echo
Re: [CForms] Streaming out widget attributes?
[resent -- seems to have been lost] Reinhard Poetz wrote: Sylvain Wallez wrote: I'm sorry to say that over time, I found Cocoon to be more an obstactle for complex webapps pages (not talking about flow) than a real help, and that's why I'm moving away from it. So I don't care as much as I did... Can you give conrete examples on what these obstacles are? Well, here are some: - in complex use cases the GUI logic, as Carsten's use case exemplifies, becomes spread all over the pipeline, and it becomes increasingly difficult to understand what happens where. - client/server communication with JSON makes it really easy to build Ajax apps, but is a pain to produce from Cocoon unless we directly send it from the controller, which actually makes Cocoon pipelines useless. - Dojo widgets are a nice replacement for CForm's styling stylesheets, reduce the server load, and again make pipelines less useful. - enhancing the CForms styling leads to a giant XSL (even if modularized) where every possible styling used in the application must be present. - since only CForms has Ajax integration, people are over-using it for presentation purposes (e.g. paginated repeater) Don't get me wrong: Cocoon is a killer for publication. But for webapps, other approaches, more Java-centric, are worth considering. My current choice is Wicket, which was just proposed for incubation. Cocoon allows lots of non-Java people to build complicated stuff, and this is a major achievement. But I find it easier to write Java if you're fluent with it rather than finding workarounds in an XML-centric framework. Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (81 issues)
Subscriber: cocoon
Key Summary
COCOON-1879 Make fd:field whitespace trimming behavior configurable
http://issues.apache.org/jira/browse/COCOON-1879
COCOON-1877 [PATCH] Pageable Repeater
http://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
http://issues.apache.org/jira/browse/COCOON-1870
COCOON-1869 MailMessageSender.java eats exception chain - which does not allow
for proper dubuging and logging
http://issues.apache.org/jira/browse/COCOON-1869
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1732 Ajax and IE empty textarea bugfix
http://issues.apache.org/jira/browse/COCOON-1732
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in "for (var k in h)" kind of
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
http://issues.apache.org/jira/browse/COCOON-1535
COCOON-1527 [PATCH] Cache control logic sheets for XSP to override getKey and
getValidity
http://issues.apache.org/jira/browse/COCOON-1527
COCOON-1526 [PATCH] processToDOM returns a read-only DOM
http://issues.apache.org/jira/browse/COCOON-1526
COCOON-1519 [PATCH] TeeTransformer refactoring
http://issues.apache.org/jira/browse/COCOON-1519
COCOON-1508 [PATCH] Avalonize TranscoderFactory
http://issues.apache.org/jira/browse/COCOON-1508
COCOON-1506 [PATCH] Manually specifying a mounted sitemap's context
http://issues.apache.org/jira/browse/COCOON-1506
COCOON-1488 [PATCH] htmlunit-based testing, needs to be porte
Re: Status of releasing M1 artifacts
hepabolu wrote:
Reinhard Poetz said the following on 2/8/06 15:08:
If all new URLs consist of only Daisy IDs, they should not break:
there should not be much of document removals, right? Even if you
intend to remove a document, you can replace it with a redirect to
correct location. So I think new documentation can be managed without
breaking any URLs.
True. 2.2 gives the opportunity to change the URLs, so let's take that
advantage.
The idea is that finally each block gets its own documentation. The
problem now is that we will split up our documentation in smaller
chunks (soon) but we aren't that far. This will cause a lot of broken
URL in the future.
Do leave the documentation in Daisy, create separate collections and if
necessary separate sites for each block, but don't move it out of Daisy
to something that is as cumbersome as the old xdocs situation.
Now that the docs are in Daisy more documentation has been written and
updated than in a very long time before.
And if you do that, and all docs are still in one repository, the Daisy
IDs won't change.
Having said this, it might take some time until we really have block
specific docs and we shouldn't wait now that maybe never get done.
True. But I'd rather spend time and energy on improving/simplifying the
current process of extracting Daisy docs onto the website than moving
the docs to yet another system.
Besides, it's good for Cocoon that the docs are created with Cocoon.
Bye, Helma
I *want* to leave the docs in Daisy. I've started to write a Daisy plugin that
gets a Daisy repository and a navigation document as configuration parameters.
If the plugin is added to the pre-site phase of the Maven build process, the
docs are added to the site. This way document generation and if we want
publishing will become very simple in the future.
--
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
[jira] Commented: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=comments#action_12425233 ] Jean-Baptiste Quenot commented on COCOON-1639: -- I can't find tidy.properties in cocoon/trunk/blocks/cocoon-html. Where is it? Where shall we put it, and how shall we reference it in the sitemap for component configuration? It is currently referenced using context://WEB-INF/tidy.properties > [patch] NekoHTMLTransformer > --- > > Key: COCOON-1639 > URL: http://issues.apache.org/jira/browse/COCOON-1639 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: HTML >Affects Versions: 2.1.8 > Environment: Operating System: All > Platform: All >Reporter: Andrew Stevens > Assigned To: Jean-Baptiste Quenot >Priority: Minor > Attachments: cocoon.log, combined.diff, htmlblock.diff, > neko.properties, neko.properties, NekoHTMLTransformer.java, > NekoHTMLTransformer.java, samples.diff > > > The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator > and... > hey, where's the NekoHTMLTransformer? > So, just to complete the set, here's one I prepared earlier :-) > I've also included an (empty) neko.properties configuration file, and updated > the neko generator's setup bits to allow for setting parser features as well > as > properties. -- 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: Status of releasing M1 artifacts
Reinhard Poetz wrote: The idea is that finally each block gets its own documentation. The problem now is that we will split up our documentation in smaller chunks (soon) but we aren't that far. This will cause a lot of broken URL in the future. Not if you keep docs in Daisy. If docs are kept in Daisy, URLs will stay the same (same IDs) even if logical organization is different (different nav doc). Vadim
Re: Status of releasing M1 artifacts
Reinhard Poetz said the following on 2/8/06 15:08: If all new URLs consist of only Daisy IDs, they should not break: there should not be much of document removals, right? Even if you intend to remove a document, you can replace it with a redirect to correct location. So I think new documentation can be managed without breaking any URLs. True. 2.2 gives the opportunity to change the URLs, so let's take that advantage. The idea is that finally each block gets its own documentation. The problem now is that we will split up our documentation in smaller chunks (soon) but we aren't that far. This will cause a lot of broken URL in the future. Do leave the documentation in Daisy, create separate collections and if necessary separate sites for each block, but don't move it out of Daisy to something that is as cumbersome as the old xdocs situation. Now that the docs are in Daisy more documentation has been written and updated than in a very long time before. And if you do that, and all docs are still in one repository, the Daisy IDs won't change. Having said this, it might take some time until we really have block specific docs and we shouldn't wait now that maybe never get done. True. But I'd rather spend time and energy on improving/simplifying the current process of extracting Daisy docs onto the website than moving the docs to yet another system. Besides, it's good for Cocoon that the docs are created with Cocoon. Bye, Helma
[jira] Commented: (COCOON-1279) caching point pipelines and smart caching
[ http://issues.apache.org/jira/browse/COCOON-1279?page=comments#action_12425222 ] Jean-Baptiste Quenot commented on COCOON-1279: -- cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java pipeline locking has not been merged to trunk, I can't apply the modifications in this issue. > caching point pipelines and smart caching > - > > Key: COCOON-1279 > URL: http://issues.apache.org/jira/browse/COCOON-1279 > Project: Cocoon > Issue Type: Improvement > Components: - Components: Avalon >Affects Versions: 2.1.5 > Environment: Operating System: Linux > Platform: PC >Reporter: Oliver Powell > Assigned To: Jean-Baptiste Quenot >Priority: Minor > > I think if you choose to use caching-point type caching, then smart-caching > should effectively be automatically turned off. Or, in other words, I would > expect when using the caching-point pipeline processor that it would by > default > behave as it does when smart-caching is off: which is to always look for > shorter > keys in the cache if a response is not found for the current key combination. > Perhaps this could be implemented by having CachingPointProcessingPipeline > override the validatePipeline method to make it always try shorter keys (at > the > same time, remove this functionality from the > AbstractCachingProcessingPipeline). -- 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: Status of releasing M1 artifacts
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Jorg Heymans wrote:
On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], "Reinhard
Poetz"
I also think that we should wait with an official announcement as
long as we
have at least some minimal docs available at
http://cocoon.apache.org/2.2-M1/.
-1 on location specified above. I don't see no sense in keeping
documentation of each and every milestone/alpha/beta/rc release. URL
should read
http://cocoon.apache.org/2.2/
Front page may say that currently these are 2.2m1 documentation and
it is a work in progress. Once first 2.2.0 release is out, this
notice could be removed.
If we don't have a problem if our urls break, we can publish our docs
to http://cocoon.apache.org/2.2/. WDYT?
If all new URLs consist of only Daisy IDs, they should not break: there
should not be much of document removals, right? Even if you intend to
remove a document, you can replace it with a redirect to correct
location. So I think new documentation can be managed without breaking
any URLs.
The idea is that finally each block gets its own documentation. The problem now
is that we will split up our documentation in smaller chunks (soon) but we
aren't that far. This will cause a lot of broken URL in the future.
Having said this, it might take some time until we really have block specific
docs and we shouldn't wait now that maybe never get done.
--
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: Status of releasing M1 artifacts
Reinhard Poetz wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], "Reinhard Poetz" I also think that we should wait with an official announcement as long as we have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/. -1 on location specified above. I don't see no sense in keeping documentation of each and every milestone/alpha/beta/rc release. URL should read http://cocoon.apache.org/2.2/ Front page may say that currently these are 2.2m1 documentation and it is a work in progress. Once first 2.2.0 release is out, this notice could be removed. If we don't have a problem if our urls break, we can publish our docs to http://cocoon.apache.org/2.2/. WDYT? If all new URLs consist of only Daisy IDs, they should not break: there should not be much of document removals, right? Even if you intend to remove a document, you can replace it with a redirect to correct location. So I think new documentation can be managed without breaking any URLs. Vadim
Re: Status of releasing M1 artifacts
Vadim Gritsenko wrote:
Jorg Heymans wrote:
On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], "Reinhard
Poetz"
I also think that we should wait with an official announcement as
long as we
have at least some minimal docs available at
http://cocoon.apache.org/2.2-M1/.
-1 on location specified above. I don't see no sense in keeping
documentation of each and every milestone/alpha/beta/rc release. URL
should read
http://cocoon.apache.org/2.2/
Front page may say that currently these are 2.2m1 documentation and it
is a work in progress. Once first 2.2.0 release is out, this notice
could be removed.
If we don't have a problem if our urls break, we can publish our docs to
http://cocoon.apache.org/2.2/. WDYT?
--
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
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 02 August 12:24 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-08-02 12:02:14 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] ... [get] last modified = Mon Jul 24 00:07:03 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] .. [get] last modified = Mon Jul 17 11:07:06 GMT+00:00 2006 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.input.projectInfo -- check-plugin: [echo
Re: Status of releasing M1 artifacts
Jorg Heymans wrote: On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], "Reinhard Poetz" I also think that we should wait with an official announcement as long as we have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/. -1 on location specified above. I don't see no sense in keeping documentation of each and every milestone/alpha/beta/rc release. URL should read http://cocoon.apache.org/2.2/ Front page may say that currently these are 2.2m1 documentation and it is a work in progress. Once first 2.2.0 release is out, this notice could be removed. Vadim
Re: Cocoon & Short Message Service
Simone Gianni wrote:
Ciao Omar,
I used this a few yars ago, to prototype an SMS application, and then
moved to a commercial HTTP based interface :
http://javasmslib.sourceforge.net/ . Otherwise, a few years ago, there
was kannel that interfaced HTTP to an SMS modem/cellphone.
There is also:
http://smsj.sourceforge.net/
example:
public class SmsSenderImpl implements SmsSender {
private final static Loglogger = LogFactory.getLog(
SmsSenderImpl.class );
private Properties props;
private SmsTransporttransport;
private String originator;
public Properties getProps() {
return props;
}
public void setProps( Properties props ) {
this.props = props;
}
public void init() {
try {
this.originator = this.props.getProperty(
"originator",
"123456789" );
this.transport = SmsTransportManager.getTransport(
"org.marre.sms.transport.gsm.GsmTransport",
props );
} catch ( SmsException e ) {
throw new RuntimeException( e );
}
}
public synchronized void send( String recipient, String content ) {
try {
SmsTextMessage textMessage = new SmsTextMessage(
content );
transport.connect();
transport.send( textMessage,
new SmsAddress(
recipient ),
new SmsAddress(
this.originator ) );
} catch ( Exception e ) {
throw new RuntimeException( e );
} finally {
try {
transport.disconnect();
} catch ( Exception e ) {
logger.error( e );
}
}
}
}
The only thing you have to do is plug your GSM terminal to a COM port
and enable serial communication in java.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Javaflow in 2.2 and the continuation class loader
Maurizio Pillitu wrote:
Torsten Curdt wrote:
That's the setup I've demonstrated in Amsterdam. (I've actually still
have that setup on disk)
Currently this is not happening : the ReloadingClassLoader is there, and
it manages Jci stores, but could not get how to actually configure a
JavaflowResourceStore in it so that my javaflow classes/sources gets
compiled/reloaded and most important enhanced.
With that sitemap feature you had a map:classpath section:
We tried to use this snippet into map:components of the sitemap, but it
gives an error :
Unknown component type 'classpath' at
file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82
Looking into the code of
org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see :
private static final String CLASSLOADER_CONFIG_NAME = "classloader";
so probably the name of the sitemap component is
instead of .
Trying with we have the following error:
No bean named 'org.apache.cocoon.components.classloader.ClassLoaderFactory' is
defined
Using ReloadingClassLoaderFactory it gives the same error.
Could you please send your configuration so that we can try to figure
out why is not working on ours?
I haven't followed this thread in every detail, but here are some comments:
- Carsten has re-added the classloader factory. I added the configuration to
cocoon-bootstrap (see cocoon-bootstrap-realoding-classloader-factory.xconf).
- In the sitemap you have to declare the classloader factory:
HTH
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Re: Javaflow in 2.2 and the continuation class loader
>> > That's the setup I've demonstrated in Amsterdam. (I've actually still >> > have that setup on disk) >> >> Currently this is not happening : the ReloadingClassLoader is there, and >> it manages Jci stores, but could not get how to actually configure a >> JavaflowResourceStore in it so that my javaflow classes/sources gets >> compiled/reloaded and most important enhanced. > > With that sitemap feature you had a map:classpath section: > > factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory"> > > > > > > class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/> > > > We tried to use this snippet into map:components of the sitemap, but it gives an error : Unknown component type 'classpath' at file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82 Looking into the code of org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see : private static final String CLASSLOADER_CONFIG_NAME = "classloader"; so probably the name of the sitemap component is instead of . Well, I know this was removed at some stage. I know Reinhard was looking into getting it back in. We wanted to work on that but did not get to do it during the Hackathon in Dublin. IIRC Carsten did some changes in that area. Could you please send your configuration so that we can try to figure out why is not working on ours? The snippet was from the configuration - so this probably has to get fixed first. cheers -- Torsten
Re: Javaflow in 2.2 and the continuation class loader
Torsten Curdt wrote: >> > That's the setup I've demonstrated in Amsterdam. (I've actually still >> > have that setup on disk) >> >> Currently this is not happening : the ReloadingClassLoader is there, and >> it manages Jci stores, but could not get how to actually configure a >> JavaflowResourceStore in it so that my javaflow classes/sources gets >> compiled/reloaded and most important enhanced. > > With that sitemap feature you had a map:classpath section: > > factory-role="org.apache.cocoon.components.classloader.ClassLoaderFactory/ReloadingClassLoaderFactory"> > > > > > > class="org.apache.commons.javaflow.stores.JavaflowResourceStore"/> > > > We tried to use this snippet into map:components of the sitemap, but it gives an error : Unknown component type 'classpath' at file:/home/mau/workspace/cocoon2.2/cocoon-crud/src/main/resources/COB-INF/sitemap.xmap:21:82 Looking into the code of org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage I see : private static final String CLASSLOADER_CONFIG_NAME = "classloader"; so probably the name of the sitemap component is instead of . Trying with we have the following error: No bean named 'org.apache.cocoon.components.classloader.ClassLoaderFactory' is defined Using ReloadingClassLoaderFactory it gives the same error. Could you please send your configuration so that we can try to figure out why is not working on ours? TIA Maurizio Pillitu
Re: [CForms] Streaming out widget attributes?
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Yeah, but the point is about the "somewhere". Each element in a
Cocoon pipeline is supposed to address a particular concern.
Now over time, reasons emerge for everything to be useful everywhere,
and we end up with a giant mix, where having different stages in a
pipeline no more really make sense, and where each stage produces as
much information as possible for the next one, for the occasional
case where it may be useful, thus impacting the general performance
just to handle these edge cases.
Ok, in general you're right; but I'm wondering why for example we added
a special handling for suggestion lists which is rarely needed and seem
to refuse to add a more general approach which helps others as well.
Uh? Don't see what you mean here...
Streaming out the attributes of the field definition should in no way
change the performance as the attributes are empty in most cases anyway.
Ok, if others are ok with it, then so be it.
I'm sorry to say that over time, I found Cocoon to be more an obstactle
for complex webapps pages (not talking about flow) than a real help, and
that's why I'm moving away from it. So I don't care as much as I did...
Can you give conrete examples on what these obstacles are?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
cocoon 2.2 xsp problem
I have managed to bring xsp block to such state that it properly compiles a xsp script. The problem is that after the script gets compiles I have ClassNotFoundException for that particular xsp class. I have tried to run cocoon both with shielding classloader and without it. No change. Could anyone help? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote: Sylvain Wallez wrote: Yeah, but the point is about the "somewhere". Each element in a Cocoon pipeline is supposed to address a particular concern. Now over time, reasons emerge for everything to be useful everywhere, and we end up with a giant mix, where having different stages in a pipeline no more really make sense, and where each stage produces as much information as possible for the next one, for the occasional case where it may be useful, thus impacting the general performance just to handle these edge cases. Ok, in general you're right; but I'm wondering why for example we added a special handling for suggestion lists which is rarely needed and seem to refuse to add a more general approach which helps others as well. Uh? Don't see what you mean here... Streaming out the attributes of the field definition should in no way change the performance as the attributes are empty in most cases anyway. Ok, if others are ok with it, then so be it. I'm sorry to say that over time, I found Cocoon to be more an obstactle for complex webapps pages (not talking about flow) than a real help, and that's why I'm moving away from it. So I don't care as much as I did... Sylvain -- Sylvain Wallez - http://bluxte.net
Just to be sure: is cocoon/blocks/cocoon-xsp shared?
Is xsp block shared between 2.1 and 2.2? If not can I remove xpatch files after I have provided appropriate .xconf files? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [CForms] Streaming out widget attributes?
Sylvain Wallez wrote: > > Yeah, but the point is about the "somewhere". Each element in a Cocoon > pipeline is supposed to address a particular concern. > > Now over time, reasons emerge for everything to be useful everywhere, > and we end up with a giant mix, where having different stages in a > pipeline no more really make sense, and where each stage produces as > much information as possible for the next one, for the occasional case > where it may be useful, thus impacting the general performance just to > handle these edge cases. > Ok, in general you're right; but I'm wondering why for example we added a special handling for suggestion lists which is rarely needed and seem to refuse to add a more general approach which helps others as well. Streaming out the attributes of the field definition should in no way change the performance as the attributes are empty in most cases anyway. > > Well, that looks like business logic to me, and can be handled by > on-change events with Ajax. I don't want to use ajax for this; i don't need a server request; I can generate javascript which completly runs in the browser - which is much faster and user friendly. Carstem -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Status of releasing M1 artifacts
David Crossley wrote:
Reinhard Poetz wrote:
So far I've been able to release
cocoon
cocoon-core-modules
cocoon-bootstrap
cocoon-core
to people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository.
I had less time than expected and it took me longer to get everything
running. I will continue with the process over the next days. The problem
now is that we need to update the license headers *before*. Once David
volunteered for this but I don't know if he has enough time these days.
I will still try. However, it is not required at this stage.
great!
--
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
[jira] Commented: (COCOON-1732) Ajax and IE empty textarea bugfix
[ http://issues.apache.org/jira/browse/COCOON-1732?page=comments#action_12425177 ] Guillaume Déflache commented on COCOON-1732: I stumbled upon the same bug recently. Is there a particular reason (other than lack of time) why this patch is not commited yet? Before finding this bug I wrote another solution at the CForms level that basically modifies the stock 'textarea' styling so that textareas are never empty. Would it be a better solution? If so, I can provide a patch. Else I will happily apply the existing patch as is, hoping it will also be in the next released version. > Ajax and IE empty textarea bugfix > - > > Key: COCOON-1732 > URL: http://issues.apache.org/jira/browse/COCOON-1732 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Ajax >Affects Versions: 2.1.8 >Reporter: Fabrizio Sitzia >Priority: Minor > Attachments: empty_textarea_ie.txt, ie_empty_textarea.gif > > > Empty textareas in a repeater are displayed incorrectly by Internet > Explorer after a round-trip to the server (for example after > adding/deleting a row, or when a validation error occurs!) > Instead of being empty, the textareas display a garbled mix of text and > html-tags occurring in the html document. Submission of the form usually > won't work afterwards... > (See attachment for my post to the cocoon dev list, which contains the steps > for reproducing the bug, and a possible fix for it) -- 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: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote: Sylvain Wallez wrote Yes, now I see two solutions for this: we could just stream out the attributes of the definition (which are strings) or if we need all attributes, stream out attributes which can be streamed. I would go for the first solution, anything against this? Sounds hacky to me... Really? Why? You define something in the model which you want to access easily somewhere. Yeah, but the point is about the "somewhere". Each element in a Cocoon pipeline is supposed to address a particular concern. Now over time, reasons emerge for everything to be useful everywhere, and we end up with a giant mix, where having different stages in a pipeline no more really make sense, and where each stage produces as much information as possible for the next one, for the occasional case where it may be useful, thus impacting the general performance just to handle these edge cases. Dumb question: why do you need these attributes in the XSL? Attributes were meant to allow additional information to be communicated between the application logic and the various event handlers and validators attached to widgets, whereas the XSLs are supposed to use the styling information for their job. Yes, but what if you need anything else apart from styling? For example "required" is passed from the model to the xsls. I want to pass on information like dependencies between fields, for example if field A has value 1, then field B is optional and if field A has value 2 field B is required. I need a generic mechanism here which just passes this information from the model to the xsls where I can generate some client javascript. Well, that looks like business logic to me, and can be handled by on-change events with Ajax. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] Release 2.2M1
* Antonio Gallardo: > Jean-Baptiste Quenot escribió: > > I made some tests (outside the scope of Cocoon), and > > encountered problems with Jetty 6 Beta, which appears to be > > shaky. If you feel confident, then at least be sure to use > > version >= 6.0.0beta17. > > Agreed. We had the same problems locally. Few weeks ago, tired > of the unstable jetty6 plugin situation, Carlos did a small > research and found we don't need to use jetty6 anymore. We can > use the stable jetty plugin now: > > http://www.nabble.com/Important-jetty-plugin-changes-t1900742.html I don't see any information regarding the Jetty servlet container version itself. Neither at the above link nor at the one below: http://jetty.mortbay.org/jetty6/maven-plugin/howto.html What makes you think you can downgrade Jetty? Dropping the "6" on the plugin name doesn't mean anything. The POM still depends on Jetty 6: http://www.mortbay.org/maven2/snapshot/org/mortbay/jetty/maven-jetty-plugin/6.0-SNAPSHOT/maven-jetty-plugin-6.0-20060723.171850-5.pom Cheers, -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Status of releasing M1 artifacts
Reinhard Poetz wrote: > > So far I've been able to release > > cocoon > cocoon-core-modules > cocoon-bootstrap > cocoon-core > > to people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository. > > I had less time than expected and it took me longer to get everything > running. I will continue with the process over the next days. The problem > now is that we need to update the license headers *before*. Once David > volunteered for this but I don't know if he has enough time these days. I will still try. However, it is not required at this stage. -David
Re: Questions re using SVG in Cocoon
hepabolu wrote: Leszek Gawron said the following on 1/8/06 22:45: http://rifers.org/blogs/gbevin/2005/4/11/embedding_images_inside_html I've read this, but I wonder if it would be suitable at all, notwithstanding the fact that IE doesn't support it and the majority of my users uses IE. Thanks anyway. So you'll probably end up with the approach known since the tcp packages were carried by pigeons: linking to images instead of embedding. True, but I fail to see the advantage of this approach. I've read the info and the comments and the only thing I got out of it was: a lot of hassle for the same result. If you could explain please do. My current (working) setup looks like this: - flowscript function calls cform for entering parameters. - parameters are stored in a javascript bean. - bean is passed onto a jx-template file: my-svg-pipeline: - generate svg with my dedicated svggenerator using parameters - serialize svg2jpg this works, at least in firefox on mac. I'll be testing it in other browsers asap. If this works well, I'm thinking of expanding it to show SVG rather than a jpg depending on the browser or a user preference. If you have a better/more elegant idea, please let me know. This is totally ok. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: My first steps with cocoon 2.2 mavenized application
Carsten Ziegeler wrote: Example: Can I have my spring beans using cocoon xml parser? If so how do I instantiate some testing environment? Using Avalon components within your spring beans is easy. Just put your bean definition xml in the WEB-INF/cocoon/spring directory. You can refer to the avalon based components by using the role as the bean name, so org.bla.bla.SAXParser is the bean name of the cocoon xml parser. Now, for testing things are more complicated as setting up avalon based components through spring still requires the avalon environment. You can inherit your test case from CocoonTestCase which sets up the avalon enviromnent for you. That is what I was afraid of. Unfortunatelly I would like the test cases to extend from AbstractTransactionalDependencyInjectionTests (or something in this matter, spring framework goes to the edge with those long class names). Is this feasible to come up with some kind of helper class that could be used in any test case? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: My first steps with cocoon 2.2 mavenized application
Reinhard Poetz wrote: Leszek Gawron wrote: Reinhard Poetz wrote: Does that mean that even simplest application needs 2 maven modules? not necessarily but it is recommended (IMO). If you put all your code into the /src/main/java and /src/main/webapp directories it should work too. Apart from the fact that some paths are hardcoded. Like in sitemap: when you call "cocoon:deploy" on a block (jar artifact), a minimal webapp is created which uses hard-coded absolute paths. I don't see a problem with this as it's only useful at development time. So I can happily do some development but not release. yes, that was my intention. Is there any way now to change the block mount point (without editing sitemaps manually of course)? Is there a way to make one block the default one and mount it under "/"? The current behaviour is that when you call "/", you are redirected to the default one. Is that not enough? For development purposes of a single block - probably enough. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
webdav does not compile for a while
cocoon-webdav-impl in 2.2 cannot compile because of not including the httpclient for a while as shown in the following:C:\apache\cocoon.home\svn\trunk\blocks\cocoon-webdav\cocoon-webdav-impl\src\main\java\org\apache\cocoon\transformation\DASLTransformer.java:[27,37] package org. apache.commons.httpclient does not existRice
Re: Run myBlock in Tomcat fail
Hi, Seems it is classloader problem because CocoonServletListener.class is not found.. See the following error message:Aug 2, 2006 2:26:02 PM org.apache.catalina.core.StandardContext listenerStart SEVERE: Error configuring application listener of class org.apache.cocoon.servlet.CocoonServletListenerjava.lang.ClassNotFoundException: org.apache.cocoon.servlet.CocoonServletListener at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1352) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1198) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3677) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4187) at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1175) at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:527) at org.apache.catalina.manager.HTMLManagerServlet.doGet (HTMLManagerServlet.java:104) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java :664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595)Aug 2, 2006 2:26:02 PM org.apache.catalina.core.StandardContext listenerStartSEVERE: Skipped installing application listeners due to previous error(s) >> Rice Yeh wrote:>> Hi,>> I have checked the web.xml and the doctype is ok. I run it in>> tomcat-5.0.28 and the error messages seems showing the problem is about the>> context listener. Hence, I comment out the listener setting in web.xml, then>> the error becomes "Error filterStart". From here, I resaon it is context>> listener problem.>> > I just rechecked with latest version of trunk. At least on my machine it > runs without any problems on Tomcat 5.0.28 and 5.5.12.> Can you send your complete tomcat log for more information?> Carsten
Re: Questions re using SVG in Cocoon
Leszek Gawron said the following on 1/8/06 22:45: http://rifers.org/blogs/gbevin/2005/4/11/embedding_images_inside_html I've read this, but I wonder if it would be suitable at all, notwithstanding the fact that IE doesn't support it and the majority of my users uses IE. Thanks anyway. So you'll probably end up with the approach known since the tcp packages were carried by pigeons: linking to images instead of embedding. True, but I fail to see the advantage of this approach. I've read the info and the comments and the only thing I got out of it was: a lot of hassle for the same result. If you could explain please do. My current (working) setup looks like this: - flowscript function calls cform for entering parameters. - parameters are stored in a javascript bean. - bean is passed onto a jx-template file: my-svg-pipeline: - generate svg with my dedicated svggenerator using parameters - serialize svg2jpg this works, at least in firefox on mac. I'll be testing it in other browsers asap. If this works well, I'm thinking of expanding it to show SVG rather than a jpg depending on the browser or a user preference. If you have a better/more elegant idea, please let me know. Bye, Helma
Re: My first steps with cocoon 2.2 mavenized application
>> Example: Can I have my spring beans using cocoon xml parser? If so how >> do I instantiate some testing environment? Using Avalon components within your spring beans is easy. Just put your bean definition xml in the WEB-INF/cocoon/spring directory. You can refer to the avalon based components by using the role as the bean name, so org.bla.bla.SAXParser is the bean name of the cocoon xml parser. Now, for testing things are more complicated as setting up avalon based components through spring still requires the avalon environment. You can inherit your test case from CocoonTestCase which sets up the avalon enviromnent for you. HTH Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
