DO NOT REPLY [Bug 24240] - Generate/XInclude/CInclude from cocoon:// has wrong context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240 Generate/XInclude/CInclude from cocoon:// has wrong context --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 07:42 --- Do you use a subsitemap?
DO NOT REPLY [Bug 24240] - Generate/XInclude/CInclude from cocoon:// has wrong context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240 Generate/XInclude/CInclude from cocoon:// has wrong context --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 08:10 --- Yes, and I'll attach a zip of all the files, but I don't think a subsitemap is related to this bug as when I start the match=** pipeline with [map:generate src=cocoon://ground//] I get an error but when I generate from the same file that cocoon://ground returns (eg. [map:generate src=withxinclude.xml/] ) then there are no errors. It seems that the context is getting messed up somewhere. This error occurs when the withxinclude.xml file has cincludes or xincludes.
DO NOT REPLY [Bug 24240] - Generate/XInclude/CInclude from cocoon:// has wrong context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240 Generate/XInclude/CInclude from cocoon:// has wrong context --- Additional Comments From [EMAIL PROTECTED] 2003-10-30 08:11 --- Created an attachment (id=8818) ZIP of site showing problem
Re: [IMPIMP] care with classpath (Was: CLI: Cannot find catalogManager.properties)
Le Jeudi, 30 oct 2003, à 05:42 Europe/Zurich, David Crossley a écrit : IMPIMP means that this is double important because no-one replied the first time. Please do various tests such as './cocoon.sh servlet' to ensure that it still runs on your platform. Just did a clean build from current CVS on macosx/jdk 1.4.1, start with ./cocoon.sh servlet. Tested a bunch of helloworld samples, ok. Petstore block sample looks ok as well. Is that what you're looking for, or do you have more specific tests in mind? -Bertrand
Re: [IMPIMP] care with classpath (Was: CLI: Cannot find catalogManager.properties)
David Crossley wrote: IMPIMP means that this is double important because no-one replied the first time. Please do various tests such as './cocoon.sh servlet' to ensure that it still runs on your platform. --David Please consider that the test target might fail unless you have put copies of the jars contained in lib/endorsed into $JAVA_HOME/jre/lib/endorsed. In other words, you might get a different XML parser and XSL-T processor when running ./cocoon.sh servlet with respect to what you get when running ./build.sh test. This is because the first prepends lib/endorsed/*.jar to the classpath and the second does not. At the moment, the woody block tests seem to trigger a bug in the version of Xalan included in Sun's JDK up to version 1.4.2 (al least on Linux) and thus they fail unless you do the endorsed trick. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
Re: [IMPIMP] care with classpath (Was: CLI: Cannot find catalogManager.properties)
Bertrand Delacretaz wrote: David Crossley a écrit : IMPIMP means that this is double important because no-one replied the first time. Please do various tests such as './cocoon.sh servlet' to ensure that it still runs on your platform. Just did a clean build from current CVS on macosx/jdk 1.4.1, start with ./cocoon.sh servlet. Tested a bunch of helloworld samples, ok. Petstore block sample looks ok as well. Is that what you're looking for, or do you have more specific tests in mind? Thanks. Nothing specific in mind, merely that i was horrified to be adding something to the classpath of the planet's infrastructure, aka cocoon. I would like someone to cast their eye over those code changes to ensure nothing drastic. --David
DO NOT REPLY [Bug 24240] - Generate/XInclude/CInclude from cocoon:// has wrong context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24240
Generate/XInclude/CInclude from cocoon:// has wrong context
--- Additional Comments From [EMAIL PROTECTED] 2003-10-30 09:04 ---
I think the problem is inside MutableEnvironmentFacade:
public void reset() {
this.env.reset();
// TODO - If we remove the line below, do we break something
//else again? If we leave it in, the SitemapSource
//object is unusable after a call to getInputStream()
//or toSAX() :(
//this.env.setURI(this.uri, this.prefix);
}
the env isn't reset to the old URI after a changeContext.
Re: [IMP] Performance problems with TraxTransformer
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote: use-store - why in hell is use-store to false??? IIRC, it was fist set to true because the transient store was actually not transient and tried to serialize compiled XSLTs in the persistant store, which failed because these objects are not serializable. History [1] says: parameter name=use-store value=false/ !-- Setting this to true will crash Cocoon for now! -- What this actually mean I'm not sure and I'm happily using use-store parameter for a long time now (currently Cocoon 2.0.4 and 2.1) Let's switch it to true an ensure the transient store is really transient. +1. Store is checking for Serializable (again, IIRC), which should be enough. We turned this on on a production box recently, it became rather unstable, usually falling down once per day. This was in Cocoon 2.1 m2. regards Jeremy
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding ValueJXPathBinding.java
[EMAIL PROTECTED] wrote: vgritsenko2003/10/29 18:31:13 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding ValueJXPathBinding.java Log: Oops. Remove debug statement. Revision ChangesPath 1.5 +0 -4 cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/ValueJXPathBinding.java -// FIXME: Remove -// System.out.println(Set lenient to true (was: + jxpc.isLenient() + ) for + jxpc); -jxpc.setLenient(true); - Was it not to much removed, esp. the line jxpc.setLenient(true); ?? Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
Re: HTML editor widget (was Re: [proposal] Doco)
On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote: I've only just started with some little javascript experiments, so it's not like any code has been written yet. ok, but it's great to see you doing this Here are some first random thoughts: * different users of the widget (like the doco project vs the project where we need it) will likely require different subsets of HTML to be used. True, even if, for XHTML, you can support different modules. For example, I didn't support tables in Linotype. * support for both Mozilla and IE is important. Other browsers should fall back to a textarea with raw HTML in it. yes * the HTML produced by the editor should be cleaned (i.e. not supported tags attributes removed) and normalized (formatted). The goal of this is to deliver a nice XHTML-subset-doc for storage, and to show nice HTML to people editing it manually. Hopefully this will also make it possible to do meaningful text-based diffs. Yep My first thought was to do this cleanup stuff serverside (could be as simple as an XSL, which would make it easily customisable too). However it seems like you want to do all that on the client side? Linotype already includes a DOM serializer, I think it already does some pretty formatting and already has the ability to distinguish between whitespace-safe elements and non. * Currently in e.g. Linotype the source for the editor (thus of the iframe) is fetched separately from the main page. This is harder to do with cforms since then the pipeline from which the content is fetched should also have access to the cforms Form which is stored somewhere in a variable in a flowscript. For the cforms widget it would be easier I think to embed the HTML directly in the page (e.g. as a Javascript variable). This also makes it possible to assign the content either to the html editor or the textarea depending on what the client supports. I thought about that too: my solution would be to have woody draw the widget as an empty iframe and then fill it up at page load time from some client-side javascript. In theory it's easy, in practice, I expect tons of bugs and incompatibilities between browsers (but haven't tried yet) Another thing I wanted to try is to embed the icons right into the page instead of having them fetched from outside, this makes is easier since you don't have to mount your icons somewhere in your URI space. * Automatic image upload: still need to think more about this. After pressing the submit button (and afterwards possibly showing the form again), the images will need to become available in the URL space. How that's done will probably differ from application to application so we could put that behaviour behind an interface. hmmm, what aobut giving back the uploaded Parts back into the object model that is accessible to the flowscript. the flow will handle them and put them in the proper place... at this point, the flow will have to be able to call a link translation on the page. * wiki syntax support: we have no need for this, so don't expect any effort from me on that. Fair enough, but please keep in mind that the editor will have multi views and need to be defined in the description of the widget for that particular form. -- Stefano.
ESQL question
Some months ago there was a slight change in ESQL. PreparedStatements were only created when there were esql:parameters existing. If not plain query were executed. Now I see that a simple query without parameters is also prepared which makes the execution a lot slower under Pervasive 2000i (I have never seen more crappy database). Is it an intentional change ? lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding ValueJXPathBinding.java
Joerg Heinicke wrote: [EMAIL PROTECTED] wrote: vgritsenko2003/10/29 18:31:13 Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding ValueJXPathBinding.java Log: Oops. Remove debug statement. Revision ChangesPath 1.5 +0 -4 cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/binding/ValueJXPathBinding.java -// FIXME: Remove -// System.out.println(Set lenient to true (was: + jxpc.isLenient() + ) for + jxpc); -jxpc.setLenient(true); - Was it not to much removed, esp. the line jxpc.setLenient(true); ?? No. This was blind set(true) for testing; Sylvain has implemented already configurable approach. Vadim
Cocoon Design Patterns EJB
Hi All, I am investigating Cocoon, but I don't obtain answers in the Cocoon user mailing list and web resources to following questions: 1) What are the Design Patterns (of small granularity, i.e., facade, etc) implemented by Cocoon? In which components are they? Are they transparent to user? 2) I desire to develop an application with Cocoon and EJB. Will I have to implement EJB Design Patterns by myself? Or, are there Components (Avalon or other) that make this integration? Anybody knows papers/articles about these questions? Thanks in advanced, Leandro Rosa Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br
Re: [IMP] Performance problems with TraxTransformer
Jeremy Quinn wrote: On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote: use-store Let's switch it to true an ensure the transient store is really transient. +1. Store is checking for Serializable (again, IIRC), which should be enough. We turned this on on a production box recently, it became rather unstable, usually falling down once per day. Can you be little bit more specific in this part -- failing down -- what have you seen? Vadim
[heads up] Keeping dependencies in sych
I tried to compile the repository block standalone but it didn't compile because it requires both the database block and the eventcache block. I don't have any problems with these dependencies (they make perfect sense) but I would like people to do a little more effort in keeping the block dependencies in synch in the blocks.properties file, expecially since this will become a big issue with real blocks. Thanks for your help. -- Stefano.
RE: [heads up] Keeping dependencies in sych
That was my fault. I'm sorry about that, I wasn't aware that dependencies should be specified in the blocks properties file. -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: donderdag 30 oktober 2003 12:46 To: Apache Cocoon I tried to compile the repository block standalone but it didn't compile because it requires both the database block and the eventcache block. I don't have any problems with these dependencies (they make perfect sense) but I would like people to do a little more effort in keeping the block dependencies in synch in the blocks.properties file, expecially since this will become a big issue with real blocks. Thanks for your help. -- Stefano.
Re: [IMP] Performance problems with TraxTransformer
On Thursday, October 30, 2003, at 11:42 AM, Vadim Gritsenko wrote: Jeremy Quinn wrote: On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote: use-store Let's switch it to true an ensure the transient store is really transient. +1. Store is checking for Serializable (again, IIRC), which should be enough. We turned this on on a production box recently, it became rather unstable, usually falling down once per day. Can you be little bit more specific in this part -- failing down -- what have you seen? :) Sorry, Vadim, it is difficult to be more specific, because we never tracked down the exact cause (we were in 'panic mode'). One week I decided to try adding the config to store XSLTs. I had tested it on a low-hit development machine, and it seemed to be faster. Then we found the site started going down on a regular basis. We would start seeing lots of Broken Pipes in the logs and TomCat would stop serving. Restart TomCat and it would be down again by the end of the day. Remove that config as (AFAIK, I am not on that job anymore) the problem has gone away. The development server is running TomCat 4.1.18, Cocoon 2.1m2. Recent RedHat, Sun Java 1.4.1.02. I could conceivably retrieve some archived logs if that would help, but they did not seem spectacularly illuminating at the time. HTH regards Jeremy
RE: [Portal] future and design questions
Hi, thanks for your offer - it would be great if others can step in and extend the portal. Now, the current version in cvs is stable and is already used in different projects around the globe. There is no real list of what is missing; so if you can think of anything that you're missing just do it :) I think in the usuability area are some things missing. One major think currently is the complicated configuration, so if anyone has a good and clever idea on how to simplify this, I would be very happy. Obviously, tools are missing. If you look at the old portal engine you have some html based administration tools. It would be great to have those as well, although imho this isn't restricted to html based tools, e.g. Ecplise based plugins would be great as well. HTH Carsten -Original Message- From: URDINA Michal [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 2:56 PM To: Cocoon-dev Subject: RE: [Portal] future and design questions Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal
[FYI] cool packages for mach-o
[since the number of switchers around here is increasing, I think this is less and less off-topic ;-)] Point your browser to http://www.serverlogistics.com/software.php where you find very nicely packages for - apache 2.0.x - mysql 4.0.x (including JDBC driver!!) - tomcat 4.1.x (including mod_jk2 for apache2!!) - php 4.3.x (including PEAR and a bunch of extensions) that install nicely on /Library/ and put themselves into StartupItems and provide a PreferencePane addon so that you can use the System Preferences to start/stop/configure/etc.. Very Nice!! There is also a package for Cocoon but it's 2.0.x Ah, if you use MySQL, don't forget CocoaMySQL, it's a beauty ;-) -- Stefano, soo happy he switched... sooo happy :-)))
AggregateField.java fieldsHaveValues()
In AggregateField.java the method fieldsHaveValues() has a conflict
with its comment. The code only returns true if every field has a
value. The comment says differently. Which is the desired behavior,
what the code currently does or what the comment says it does?
/**
* Returns true if their is at least one field which has a value.
*/
private boolean fieldsHaveValues() {
Iterator fieldsIt = fields.iterator();
while (fieldsIt.hasNext()) {
Field field = (Field)fieldsIt.next();
if (field.getValue() == null)
return false;
}
return true;
}
--Tim Larson
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
[RT] SourceRepository and davmap
I'm in the process of refactoring and furthering the davmap samples in the WebDAV block. Methods that I've added are DELETE and MKCOL, and will be adding a PROPPATCH in the following few days and look into LOCK, COPY and MOVE methods as well. I've also made some general improvements to PROPFIND, PUT and GET. All these have been tested using XMLSpy as WebDAV client (somehow couldn't get eclipse WebDAV integration to work yet). One of the things I have done to make my life a little easier is define a service called o.a.c.c.repository.SourceRepository in the repository block. It basically reuses the idea from the SourceRepository in the linotype block but instead of being a JVM-wide static it is a container managed singleton. Apart from being able to obtain a SourceResolver via the ServiceManager instead of via CocoonComponentManager.getCurrentEnvironment - which will be absent in 2.2 - and do better logging I think this will also allow us to hook in interesting stuff such as monitoring. Each method the service defines returns an integer describing the exit status of the operation. This exit status closely follows the WebDAV specification (RFC 2518). Now I think that this could map very well to other editing environments like linotype as well which is why I put it in repository for the time being. I know many of you have a lot of ideas about all these things so if people are interested in this, I'd like to hear what you think. Criticism, questions, suggestions, disagreements, any kind of remark really that will be qualitively constructive is very much welcome. Cheers, Unico
Re: [RT] SourceRepository and davmap
Talking about perfect timing ;-) On Thursday, Oct 30, 2003, at 15:46 Europe/Rome, Unico Hommes wrote: I'm in the process of refactoring and furthering the davmap samples in the WebDAV block. Methods that I've added are DELETE and MKCOL, and will be adding a PROPPATCH in the following few days and look into LOCK, COPY and MOVE methods as well. I've also made some general improvements to PROPFIND, PUT and GET. All these have been tested using XMLSpy as WebDAV client (somehow couldn't get eclipse WebDAV integration to work yet). Awesome. One of the things I have done to make my life a little easier is define a service called o.a.c.c.repository.SourceRepository in the repository block. It basically reuses the idea from the SourceRepository in the linotype block but instead of being a JVM-wide static it is a container managed singleton. Apart from being able to obtain a SourceResolver via the ServiceManager instead of via CocoonComponentManager.getCurrentEnvironment - which will be absent in 2.2 - and do better logging I think this will also allow us to hook in interesting stuff such as monitoring. Uh, very cool. How can I use this from Linotype? I would love to get rid of the repository class in the linotype block. Each method the service defines returns an integer describing the exit status of the operation. This exit status closely follows the WebDAV specification (RFC 2518). Now I think that this could map very well to other editing environments like linotype as well which is why I put it in repository for the time being. I know many of you have a lot of ideas about all these things so if people are interested in this, I'd like to hear what you think. Criticism, questions, suggestions, disagreements, any kind of remark really that will be qualitively constructive is very much welcome. I just love the idea of having a much more solid repository class for linotype to use. Even better would be the ability to have such repository polymorphic and packaged as an avalon block that I (from linotype) can simply lookup and use... and using full IoC, linotype does care if its writing on disk or writing on a WebDAV server a thousand miles away. This is the first step for Doco (and for allowing me to edit my weblog locally and rsync between webdav servers) so any help in this direction will be MOSTLY welcome!!! keep up the great work! -- Stefano.
Antwort: RE: [Portal] future and design questions
Hi! We are using the portal aswell, and did some extensions like the ApplicationCoplet and the Cachingcoplet in cooperation with Carsten from sn. Our main goal was on application integration. That means to run any existing webapp inside a coplet, featuring starting a new instance of an embedded webapp. Aggregating the normal portal menu with the menu of the integrated webapp. Also javascripts, java-applets and layers are from the embedded webapp are reused inside the coplet. We are also going to implement some new features eg admin tools for customizing and personalzation. Maybe we could collaborate? regards Manfred [EMAIL PROTECTED] am 30.10.2003 14:23:23 Bitte antworten an [EMAIL PROTECTED]@inet An: [EMAIL PROTECTED] Kopie: Thema: RE: [Portal] future and design questions Hi, thanks for your offer - it would be great if others can step in and extend the portal. Now, the current version in cvs is stable and is already used in different projects around the globe. There is no real list of what is missing; so if you can think of anything that you're missing just do it :) I think in the usuability area are some things missing. One major think currently is the complicated configuration, so if anyone has a good and clever idea on how to simplify this, I would be very happy. Obviously, tools are missing. If you look at the old portal engine you have some html based administration tools. It would be great to have those as well, although imho this isn't restricted to html based tools, e.g. Ecplise based plugins would be great as well. HTH Carsten -Original Message- From: URDINA Michal [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 2:56 PM To: Cocoon-dev Subject: RE: [Portal] future and design questions Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal
RE: [RT] SourceRepository and davmap
Stefano Mazzocchi wrote: Talking about perfect timing ;-) On Thursday, Oct 30, 2003, at 15:46 Europe/Rome, Unico Hommes wrote: I'm in the process of refactoring and furthering the davmap samples in the WebDAV block. Methods that I've added are DELETE and MKCOL, and will be adding a PROPPATCH in the following few days and look into LOCK, COPY and MOVE methods as well. I've also made some general improvements to PROPFIND, PUT and GET. All these have been tested using XMLSpy as WebDAV client (somehow couldn't get eclipse WebDAV integration to work yet). Awesome. One of the things I have done to make my life a little easier is define a service called o.a.c.c.repository.SourceRepository in the repository block. It basically reuses the idea from the SourceRepository in the linotype block but instead of being a JVM-wide static it is a container managed singleton. Apart from being able to obtain a SourceResolver via the ServiceManager instead of via CocoonComponentManager.getCurrentEnvironment - which will be absent in 2.2 - and do better logging I think this will also allow us to hook in interesting stuff such as monitoring. Uh, very cool. How can I use this from Linotype? I would love to get rid of the repository class in the linotype block. Not all functionality of the Linotype SourceRepository is implemented. For instance I have not gotten to the versioning part yet. (And haven't really thought out how this would best be done. (One idea is, continuing with the WebDAV approach, to follow the Delta-V spec as a guide to SourceRepository abstraction layer). One other difference is is that I don't use the Request and Part objects directly as input. But an operation such as save() only gets called with two strings: input location and output location that are both resolved via the SourceResolver. This way you can use what you called at the GT 'pipeline T-ing' in order to do some preprocessing. Or you could use the recently added PartSource. Anyway from a flowscript it's as easy as: importPackage(Packages.org.apache.cocoon.components.repository); var repo = cocoon.getComponent(SourceRepository.ROLE); Each method the service defines returns an integer describing the exit status of the operation. This exit status closely follows the WebDAV specification (RFC 2518). Now I think that this could map very well to other editing environments like linotype as well which is why I put it in repository for the time being. I know many of you have a lot of ideas about all these things so if people are interested in this, I'd like to hear what you think. Criticism, questions, suggestions, disagreements, any kind of remark really that will be qualitively constructive is very much welcome. I just love the idea of having a much more solid repository class for linotype to use. Even better would be the ability to have such repository polymorphic and packaged as an avalon block that I (from linotype) can simply lookup and use... and using full IoC, linotype does care if its writing on disk or writing on a WebDAV server a thousand miles away. This is the first step for Doco (and for allowing me to edit my weblog locally and rsync between webdav servers) so any help in this direction will be MOSTLY welcome!!! keep up the great work! Glad you like it :-) -- Unico -- Stefano.
[Woody] name for element containing child widgets
Lets pick a name for for the element containing child widgets. Off the top of my head, I remember these names being offered: children, items, widgets Other suggestions are welcome of course. What name do we all like? This will apply to at least the AggregateField, Repeater, Union, Struct, and Class widgets, and possibly to others in the future. --Tim Larson __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Re: Woody form2bean.flow
Giacomo Pati [EMAIL PROTECTED] writes: Anybody encountered the Exception in the form2bean.flow Woody samples under JDK 1.3? It runs smoth here with a JDK 1.4.2 In the Binding Samples I get this: resource://org/apache/cocoon/woody/flow/javascript/woody2.js, line 186: uncaught JavaScript exception: at woody (resource://org/apache/cocoon/woody/flow/javascript/woody2.js, Line 211) at (resource://org/apache/cocoon/woody/flow/javascript/woody2.js, Line 186): java.lang.NoSuchMethodError when trying the XML- as well as the Bean-Binding link. Hth, Christian P.S.: This is on WinNt using JDK 1.3.1_08 -- Recursive (ri-ker-siv): adj; See recursive
CIncludeTransformer now with sitemap params?
Hello,
because I needed a CIncludeTransformer which is able to include dynamically
resources, I had modificated the CIncludeTransformer a little bit. Now its
possible to pass sitemap parameters to the transformer. Within the src
attribute the variable will be replaced by the value of the parameter. Does
anyone need this feature, too?
For example:
somefile.xml:
element ...
...:include src=cocoon:/{filename}/
/element
pipeline:
...
map:transform type=cinclude
map:parameter name=filename value=myFile.xml/
/map:transform
...
Result:
element ...
...:include src=cocoon:/myFile.xml/
/element
Regards
Stephan
1060 NetKernel: virtual Internet operating system, XML runtime
Take a look at http://www.1060.org/ I really don't know what to make of this - lots of hot air - and a lot of similarities to Cocoon ( i vaguely remember a discussion about Cocoon as an operating system, which was quickly discarded :) ) They do compare themselves to cocoon: http://www.1060.org/netkernel/features/#analogy The serverside has a blurb: http://www.theserverside.com/home/thread.jsp?thread_id=21796 With kind regards / Met vriendelijke groeten, Rogier Peters - Content Management Department Hippo Webworks Rogier(at)hippo(dot)nl / www.hippo.nl
Re: [FYI] cool packages for mach-o
On Thursday, October 30, 2003, at 02:00 PM, Stefano Mazzocchi wrote: [since the number of switchers around here is increasing, I think this is less and less off-topic ;-)] Point your browser to http://www.serverlogistics.com/software.php where you find very nicely packages for - apache 2.0.x - mysql 4.0.x (including JDBC driver!!) - tomcat 4.1.x (including mod_jk2 for apache2!!) - php 4.3.x (including PEAR and a bunch of extensions) I use these too, very nice! I had the feeling though that they were not being updated, though I could be wrong, maybe he's sometimes a couple of versions behind. that install nicely on /Library/ and put themselves into StartupItems and provide a PreferencePane addon so that you can use the System Preferences to start/stop/configure/etc.. Yeah the PrefPanes are very handy. The TomCat one looses it occasionally. Just quit PrefPanes and restart it, and the TomCat one generally workout again whether it is on or off :) Very Nice!! There is also a package for Cocoon but it's 2.0.x Ah, if you use MySQL, don't forget CocoaMySQL, it's a beauty ;-) Its a must-have app, such a shame it does not access PostgreSQL though, I miss it! -- Stefano, soo happy he switched... sooo happy :-))) You have to write your story up for the Apple Switchers site :) http://www.apple.com/switch/stories/ regards Jeremy
Re: [RT] SourceRepository and davmap
Unico Hommes wrote: I know many of you have a lot of ideas about all these things so if people are interested in this, I'd like to hear what you think. Criticism, questions, suggestions, disagreements, any kind of remark really that will be qualitively constructive is very much welcome. Unfortunately these days I'm buried in paperwork and other stuff who does not leave me even a moment to breathe. But I'm following as closely as possible what you're doing, and I'm definitely impressed. I guess that shortly davmap could become a cocoon application on its own rather then being just a sample. Please keep it going, and thanks a lot! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: HTML editor widget (was Re: [proposal] Doco)
Bruno Dumon wrote: I've only just started with some little javascript experiments, so it's not like any code has been written yet. You can look at http://bitfluxeditor.org/ for a start. * support for both Mozilla and IE is important. That's going to give one or two headaches more :-) J.Pietschmann
Re: CIncludeTransformer now with sitemap params?
Hello Stephan,
sorry, but I don't like it that much. It looks like not needed
featuritis. The dynamic including can be more than easily and more
flexible done with XSLT. Furthermore there can occur non-obvious
collisions in the parameter names: The CIncludeTransformer already
accepts several parameters.
Please don't take any offense, it's just my opinion.
Regards,
Joerg
On 30.10.2003 17:12, Stephan Coboos wrote:
Hello,
because I needed a CIncludeTransformer which is able to include dynamically
resources, I had modificated the CIncludeTransformer a little bit. Now its
possible to pass sitemap parameters to the transformer. Within the src
attribute the variable will be replaced by the value of the parameter. Does
anyone need this feature, too?
For example:
somefile.xml:
element ...
...:include src=cocoon:/{filename}/
/element
pipeline:
...
map:transform type=cinclude
map:parameter name=filename value=myFile.xml/
/map:transform
...
Result:
element ...
...:include src=cocoon:/myFile.xml/
/element
Regards
Stephan
Re: Image-Based Authentication
Alright, here is the complete guide to how I got image-based
authentication working. I refactored it to not use interceptions, as well.
If there are any questions, please ask! :)
Here is the sitemap snippet:
map:match pattern=
map:call function=main/
/map:match
map:match pattern=form/*.flow
map:call continuation={1}/
/map:match
map:match pattern=*.jxt
map:generate type=jxt src=documents/{1}.jxt/
map:serialize type=xhtml/
/map:match
map:match pattern=auth/*.jpg
map:call continuation={1}
map:parameter name=msg value=image/
/map:call
/map:match
map:match pattern=internal/auth.jpg
map:generate type=jxt src=documents/auth-jxt.svg/
map:serialize type=svg2jpeg/
/map:match
Here is the associated Flowscript:
function main() {
var secret = generateSecret();
while (true) {
cocoon.sendPageAndWait(main.jxt, {secret:secret});
if (cocoon.parameters.msg == image) {
cocoon.sendPage(internal/auth.jpg, {text:secret});
return;
} else {
var input = cocoon.request.get(secret);
if (input == secret) {
break;
}
}
}
cocoon.sendPage(/image/success.jxt, {secret:secret});
}
function generateSecret() {
var characters =
[EMAIL PROTECTED]*(){}[].,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890;
var passwordlength = 7;
var password = ;
var randomnumber = 0;
for (var n = 0; n passwordlength; n++) {
randomnumber = Math.floor(characters.length*Math.random());
password += characters.substring(randomnumber,randomnumber + 1)
}
return password;
}
And here are the appropriate files (mostly jxtemplates):
main.jxt:
?xml version=1.0?
html xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
head
titleimage authentication/title
/head
body
h1Image-based authentication/h1
pAs a security measure, please enter the string you see below./p
img src=/image/auth/${continuation.id}.jpg/
form method=post action=/image/form/${continuation.id}.flow
input type=text name=secret/
input type=submit/
/form
/body
/html
success.jxt:
?xml version=1.0?
html xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
head
titleimage authentication/title
/head
body
h1Success!/h1
pThe code was obviously ${secret}/p
pThis sample demonstrates how you would implement an image-based
authentication using flow and the intercepted flowscript./p
pThis is most commonly used to keep robots or spiders out of an
area, but
you don't neccesarily care about humans./p
/body
/html
auth-jxt.svg:
?xml version=1.0 encoding=UTF-8?
svg width=200 height=75
defs
filter id=blur2
feGaussianBlur stdDeviation=2/
/filter
/defs
g id=imagegroup
text
style=fill:#0086B3;font-size:42;font-family:TrebuchetMS-Bold;filter:url(#blur2);
x=0 y=48${text}/text
/g
/svg
Regards,
Tony
Re: [proposal] Doco
Stefano Mazzocchi wrote: The proposal is about the creation of a content management system for apache projects, codenamed Doco snip/ I haven't followed this thread at all, but I've just come upon this site that might be interesting: http://3d17.org : People often talk to communities, but how do communities talk back? 3D17.org aims to answer that question by allowing a large number of people to collaboratively create some text, be it a letter, fax, or email. There are no details about the source code or the license, but it sure is written in Java and runs on Jetty, as can be seen from the HTTP headers. Ugo
Re: sitemap logging?
On Oct 29, 2003, at 6:41 AM, Vadim Gritsenko wrote: No problem at all; for compatibility reasons it makes sense to revert the change. Unico, do you know what change caused this? I believe I am the guilty person :) In the removal of LogKitManager / LogKitManageable, the sitemap no longer has a handle to the root LoggerManager, rather it just creates a LoggerManager based off of its current Logger. This could probably be worked around by putting the LoggerManager that is passed to the Cocoon class into the ServiceManager, and thus any component that wants to get the 'root' LoggerManager for Cocoon can just do ServiceManager.lookup( LoggerManager.class.getName() ); -pete
Re: Documenting the FOM
Reinhard Poetz wrote: From: Giacomo Pati Is the idl syntax still the way to describe the FOM documentation? AFAIK it is far from being up-to-date. Chris added the FOM description to the Control Flow documentation. I think we can remove the IDL docs. WDOT? I wouldn't object. At the very least the link off the main welcome page should not describe them as the flow docs. They don't quite cut it for the new user. Geoff
Sources of xreporter-expression-20030725.jar
Hi: Where can I found the sources of xreporter-expression-20030725.jar? I need to add there the Integer datatype to use it with woody. Best Regards, Antonio Gallardo.
Re: Sources of xreporter-expression-20030725.jar
There are in xreporter @src/java/org/outerj/expression. Right? Best Regards, Antonio Gallardo Antonio Gallardo dijo: Hi: Where can I found the sources of xreporter-expression-20030725.jar? I need to add there the Integer datatype to use it with woody. Best Regards, Antonio Gallardo.
Re: Sources of xreporter-expression-20030725.jar
If you want to find out info about any jar, then there are details and links to external projects such as Xreporter at http://cocoon.apache.org/2.1/installing/jars.html Anyway, http://xreporter.cocoondev.org/ Interestingly there are no links from there to their CVS stuff. You need to go up to the top-level project descriptions at http://www.cocoondev.org/ --David Antonio Gallardo wrote: There are in xreporter @src/java/org/outerj/expression. Right? Best Regards, Antonio Gallardo Antonio Gallardo dijo: Hi: Where can I found the sources of xreporter-expression-20030725.jar? I need to add there the Integer datatype to use it with woody. Best Regards, Antonio Gallardo.
Re: Removing whitespace in XSP generated XML
We could easily add xsl:strip-space elements=xsp:attribute/ to the xsp.xsl for avoiding the need to write xsp:attribute name=emailxsp:exprrequest.getParameterValues(users)[i]/xsp:expr/xsp:attribute (i.e. without any linebreak). The problem is, that we can break other user's code, when they rely on the whitespace handling as it is. But it's true, many people have problems with the whitespace handling for attributes and do it the way above. Furthermore we have xsp:text /xsp:text for adding single spaces (or as much as they want). Question to the developers: Can we change the whitespace handling for xsp:attribute/? Joerg On 30.10.2003 14:30, Stephanie Zohner wrote: Hi, According to the messages in the Mail Archive my problem is well known, but I could not find an proper solution in it. So maybe this time ?! I have unwanted whitespace in XSP generated attributes: For example: XSP-Code like this: user xsp:attribute name=email xsp:exprrequest.getParameterValues(users)[i]/xsp:expr /xsp:attribute /user Result into: user email=#10;[EMAIL PROTECTED]#10; / The offered solutions are: Strip the whitespace out of the XSP-page manuelly, so it won't appear in the output. I edit my XML Files with XML Spy, so this solution in not good. It obliterates the XSP file. Another offered solution is the xslt-function normalize-space. This however, did not work as expected so far. I assume this is because, normalize-space removes no #10;, which is the first character in my atibute values. Is there a way to prevent unwanted whitespace in the XSP, and if not how can XSLT help in my case (#10;) I would be very glad, if anybody can help me with this. Thanks, Stephanie
