Re: This text would be nice on the blocks.properties

Juan Jose Pablos apache.org> writes: > Hi, > I think that it would be nice to add half line text on the deprecated > section on blocks.properties to point out what is the block replacement. > > Please apply this patch. blocks.properties is auto-generated, so a commit of the patch makes no se

i18n catalogues and caching

Hello, this is my first post for the new company I work for - and I have a problem with the caching of the i18n catalogues. The location of one i18n catalogue is defined to be dependent on {request-attr:xyz}, so it can change on each request. But the first access to this i18n transformer caches th

Re: i18n catalogues and caching

Joerg Heinicke gmx.de> writes: > I have a problem with > the caching of the i18n catalogues. The location of one i18n catalogue is > defined to be dependent on {request-attr:xyz}, so it can change on each > request. But the first access to this i18n transformer caches the cata

Re: i18n catalogues and caching

Reinhard Poetz apache.org> writes: > >>I have a problem with the caching of the i18n catalogues. > > > > Any idea what can go wrong? > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110064557022481&w=2 - maybe > the 4th paragraph gives some hint ... Thanks for the hint, it was an interesti

Re: i18n catalogues and caching

Reinhard Poetz apache.org> writes: > > > src="org.apache.cocoon.transformation.I18nTransformer"> > > > > >name="dictionary"/> > > > > ../resources/translations > > resources/translations > > {request-attr:group}/resources/tr

Re: i18n catalogues and caching

Sylvain Wallez apache.org> writes: > > I have a problem with the caching of the i18n catalogues. The location of > > one i18n catalogue is defined to be dependent on {request-attr:xyz}, so it > > can change on each request. > > But the first access to this i18n transformer caches the catalogue an

Re: Importing libraries from ibiblio

On 14.01.2005 11:06, Sylvain Wallez wrote: What that means is that we can create the list of jars to download from our jars.xml or the gump descriptor, and have them automatically downloaded from the ibiblio repo. Very few modifications on the current build are needed. That could allow to reall

Re: Importing libraries from ibiblio

On 14.01.2005 23:51, Sylvain Wallez wrote: What that means is that we can create the list of jars to download from our jars.xml or the gump descriptor, and have them automatically downloaded from the ibiblio repo. Very few modifications on the current build are needed. That could allow to reall

Re: Planning 2.1.7

On 24.01.2005 07:47, Reinhard Poetz wrote: Anyway, as we agreed that 2.2 should come soon, I don't think it's worth doing the refactoring. +1 Joerg

Re: svn commit: r149029 - /cocoon/trunk/gump.xml

On 29.01.2005 13:07, [EMAIL PROTECTED] wrote: Author: cziegeler URL: http://svn.apache.org/viewcvs?view=rev&rev=149029 Log: Fix dependencies for portal Modified: cocoon/trunk/gump.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/gump.xml?view=diff&rev=149029&p1=cocoon/trunk/gump.xml&r1=149028&p

Re: [announcement/proposal] Moving Linotype out of Cocoon

On 30.01.2005 05:37, Stefano Mazzocchi wrote: For this reason, I propose that we discontinue the distribution of Linotype inside cocoon as a block, by deprecating it in the next 2.1.x release and by removing it alltogether in 2.2 +1 Joerg

Re: [proposal] move cforms in core

Stefano Mazzocchi apache.org> writes: > > Just like other people, I think distinguishing "core blocks" is a good > > thing to show people where to look at while still keeping the core small. > > I'm sorry, but I think the "core block" idea is plain wrong and smells > of over componentization.

Release process: "Version @version@ (@date@)" in "History of Changes"

Hi all, I have been rarely on the lists in the last weeks. I even had to read the changes file to know what's going on with Cocoon. :-) But when reading the "History of Changes" [1] I saw the string "Version @version@ (@date@)" instead of the release's version. Though the web site seems not to

Re: Release process: "Version @version@ (@date@)" in "History of Changes"

On 27.03.2005 14:33, Joerg Heinicke wrote: Hi all, I have been rarely on the lists in the last weeks. I even had to read the changes file to know what's going on with Cocoon. :-) But when reading the "History of Changes" [1] I saw the string "Version @version@ (@date@)"

Re: JIRA

Leszek Gawron apache.org> writes: > Have I missed the discussion about possible moving to JIRA? > If not is there anything in favour/against it? > > I would personally love to see cocoon use JIRA. Bugzilla does not look > user friendly to me. Bugzilla might not look "up to date" and so less us

Component vs. ComponentSelector (or Service vs. ServiceSelector)

Hello, whenever I try to lookup my component I get a ClassCastException when I want to cast it to the component's class. This is probably due to the intermediate selector one needs(?), but I don't know exactly. I just don't want to have the additional selector as there is just one implementation.

Re: Component vs. ComponentSelector (or Service vs. ServiceSelector)

Vadim Gritsenko reverycodes.com> writes: > > Hello, > > > > whenever I try to lookup my component I get a ClassCastException when I want > > to cast it to the component's class. > > Does your component implementation implements Component interface? Try if it > does not. Of course (it did not,

Re: ApacheCon / Hackathon / Blockathon

Torsten Curdt apache.org> writes: > Any Cocooners based in Stuttgart? I'm near Stuttgart (Reutlingen to be exact) since the beginning of this year. But I guess I can not help much as I have not been in Stuttgart except at the station in these 4 months. Joerg

Re: Cocoon vs Struts

enieto isotrol.com isotrol.com> writes: > >>Hi all! > >> > >>I have a web project with Java and Struts. This project is adapted for > >>PC's and PDA's web navigator. For this i have written a css file and > >>Struts' forward (JSP file) for each kind of navigator. > >> > >>I`ve noticed about Coco

synchronization in flow script

Hello, I have a question regarding synchronization in flow script. I need an object per session, so the instantiation must be synchronized. Furthermore the object is an Avalon component, so I need to call something like cocoon.createComponent(). Now how is it possible in Flow script? The alternat

Re: synchronization in flow script

Sylvain Wallez apache.org> writes: > > Joerg Heinicke wrote: > > >Hello, > > > >I have a question regarding synchronization in flow script. I need an object > >per session, so the instantiation must be synchronized. Furthermore the > >object &g

[IMP] synchronization on session object in Cocoon

Hello, I think I have found a more general problem with synchronization in Cocoon. I tried to solve my problem with synchronization in flow script with an intermediate object. This object handles the synchronized instantiation of my component. Unfortunately I found out that "synchronized (session)

Re: [IMP] synchronization on session object in Cocoon

Nathaniel Alfred swx.com> writes: > > As you can see on every request a new wrapper is instantiated > > which is really > > bad. It is not possible to synchronize on Cocoon session > > objects. What we > > probably need is a Map mapping the server sessions to the > > wrapper objects. > > Servlet

Re: [IMP] synchronization on session object in Cocoon

Sylvain Wallez apache.org> writes: > >I think I have found a more general problem with synchronization in Cocoon. I > >tried to solve my problem with synchronization in flow script with an > >intermediate object. This object handles the synchronized instantiation of my > >component. Unfortunately

Re: Re: [IMP] synchronization on session object in Cocoon

Nathaniel Alfred swx.com> writes: > AFAIKS is the purpose of the existing synchronized(session) bits to > protect the consistency of the session object in case it is shared > between parallel executing requests. Yes. > IIUC you need a lock object to really synchronize parallel requests. > The

Re: [IMP] synchronization on session object in Cocoon

Ralph Goers dslextreme.com> writes: > serverSession is a local variable. Synchronizing it accomplishes nothing > since every caller gets their own copy. Sytnchronizing on a member of > the HttpRequest object also accomplishes nothing. Huh? Why shall synchronization not work? It is not synched

Re: [IMP] synchronization on session object in Cocoon

Sylvain Wallez apache.org> writes: > This approach has the problem of entering a synchronized block each time > getSession is called. Although this may not that be much a problem in > this particular case because it's unlikely that many parallel requests > exist for a single request, we may to

Re: [IMP] synchronization on session object in Cocoon

Sylvain Wallez apache.org> writes: > Or more simply we could store the wrapper in the session itself using an > attribute. That way it would be guaranteed to be created only once. > > > >>>Yes, that's another possibility I also had in mind. But on the one hand > >>>this

Re: [IMP] synchronization on session object in Cocoon

Sylvain Wallez apache.org> writes: > >This solution looks really cool and elegant. Unfortunately > >HttpSessionActivationListener is Servlet Spec 2.3. In Cocoon 2.1. we are > >still on 2.2 and I guess (and suggest) we will stay with that. So only the > >WeakHashMap solution remains. > > > 2.2,

Re: Re: [IMP] synchronization on session object in Cocoon

Nathaniel Alfred swx.com> writes: > I think there is a memory leak in > http://svn.apache.org/viewcvs?rev=169806&view=rev. > There is a strong reference session.wrappedSession from value to key in > > // create new wrapper > session = new HttpSession(serve

Re: svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java

Ralph Goers dslextreme.com> writes: > Why is "sessions" a synchronized map if you are only accessing it in a > block synchronized on the session. I would much prefer that you > a) not use a synchronized map > b) synchronize on the map instead of the session. > > Is there a reason that this wou

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

On 15.03.2005 23:33, Sylvain Wallez wrote: Again and again, there is no such "readonly" attribute. You can set the state of a widget to "disabled" which leads to something similar to what you describe: the input is readonly, and the calendar icon is still visible but disabled. There is, but

Re: Sitemap problem... help! :-)

On 30.01.2005 21:32, Mark Lundquist wrote: It can be argued that it should be possible to match any continuation resource in any context and have it resumed correctly. The rationale is the intuition that the sitemap context is part of the control thread being resumed. I agree. Isn't it poss

Re: [VOTE] Alfred Nathaniel as committer

On 09.04.2005 12:10, Bertrand Delacretaz wrote: So, I'm pleased to propose Alfred, should he accept the nomination, as a committer. Of course, my secret hope is that he will contribute many additional automated tests, but the committment is to the project, not to a particular task! Back to a

Re: [IMP] synchronization on session object in Cocoon

On 16.05.2005 06:39, Ralph Goers wrote: Yes, there was considerable discussion about this. Yes, the version in svn is wrong. I was hoping it would get fixed after our discussion, but that hasn't happened, so I'll try to commit something tonight (it is still Sunday night here in California).

Re: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java)

On 13.05.2005 11:37, Nathaniel Alfred wrote: I think synchronized(session) should never be used as vehicle to coordinate concurrent requests because there is no convincing guarantee that it is always working as expected. Joerg, if you want to do it in your usercode, I don't mind, but please

Re: Cform: Field 2 SelectionList, and the otherway??

On 15.02.2005 12:21, oceatoon wrote: I have a field widget(1) that becomes a selection list by a value change of another widget(2) in the page. This works great. But for a certain value of the widget(2), on change, I would need to make that selection list back into a field widget??? I f

Re: svn commit: r178778 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/datatype/DynamicSelectionList.java /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Field.java /cocoon/branches/BRANCH_2_1_X/status.xml

On 27.05.2005 16:05, [EMAIL PROTECTED] wrote: Author: antonio Date: Fri May 27 07:05:02 2005 New Revision: 178778 URL: http://svn.apache.org/viewcvs?rev=178778&view=rev Log: Cforms block: Improved dynamic selection list performance inside repeaters. Sorry, but I absolutely don't like it for th

Re: svn commit: r178819 - /cocoon/branches/BRANCH_2_1_X/src/webapp/stylesheets/system/status2htm l.xslt

On 28.05.2005 01:21, Antonio Gallardo wrote: On Vie, 27 de Mayo de 2005, 15:47, [EMAIL PROTECTED] dijo: Author: vgritsenko Date: Fri May 27 13:47:38 2005 New Revision: 178819 URL: http://svn.apache.org/viewcvs?rev=178819&view=rev Log: add xalan / xerces version info Is change this saxon co

Re: svn commit: r178778 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/datatype/DynamicSelectionList.java /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/formmodel/Field.java /cocoon/branches/BRANCH_2_1_X/status.xml

On 28.05.2005 03:20, Antonio Gallardo wrote: Hi Joerg: I am glad to see you active on the list again. As I told you in GT2004, I like your radar over my work. :-) Hi Antonio, yeah, I'm back again at least for a few days (starting last weekend, ending tomorrow). I hope to get my internet acc

Re: [RT] Cforms selection-lists

On 28.05.2005 14:45, Sylvain Wallez wrote: So this must be handled entirely either in the pipeline or in the selection-list. +1 You're right in saying that a pipeline querying a database cannot easily be cached. Now we have in the scratchpad (and this should IMO be promoted to core) a nice

Re: [RT] Cforms selection-lists

On 29.05.2005 10:10, Sylvain Wallez wrote: I don't see why you consider it as pollution. Request attributes do exist, and their purpose is to provide temporary storage for the various things that participate in processing a request and are isolated either in space (different classes) or time (

Re: [RT] Cforms selection-lists

On 29.05.2005 04:03, Antonio Gallardo wrote: Per form is not a good option, IMHO because I suppose the life of the form can have more than one request. Please correct me if I am wrong here. You are correct. I meant only a part of the form lifecycle, the form processing during a request. Joe

Re: [SUMMARY] Caching DynamicSelectionList

Vadim's comments made me think again about the caching of selection lists. And I don't think having a shorter cache period than a form processing (as part of one request) makes no sense as it leads to inconsistent forms when a selection list is reused. Having this you *can* use time-based caching a

Re: [SUMMARY] Caching DynamicSelectionList

Antonio Gallardo agssa.net> writes: > > I don't think having a shorter cache period than a > > form processing (as part of one request) makes no sense as it leads > > to inconsistent forms when a selection list is reused. > > Please explain. More this. Are you telling a cache life shorter than a

Re: svn commit: r191020 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/i18n/XMLResourceBundleFactory.java /cocoon/branches/BRANCH_2_1_X/status.xml

On 17.06.2005 00:37, [EMAIL PROTECTED] wrote: Author: vgritsenko Date: Thu Jun 16 15:37:31 2005 New Revision: 191020 URL: http://svn.apache.org/viewcvs?rev=191020&view=rev Log: Regression: cacheKey != fileName It took some time until I found the regression I introduced. But I wonder why the u

Re: community input on the GSoC

On 06.07.2005 12:36, Jorg Heymans wrote: Is having a separate branch per GSOC project an option? That way they can play all they like, all it would need is a few days of integration maybe at the end of the project. Repository permissions are clearer, and anyone interested in the progress would j

Re: [vote] Give Max Pfingsthorn temporary and restricted commit privileges to our code repository

On 10.07.2005 13:23, Reinhard Poetz wrote: In order to make his life and the life of his two mentors (Sylvain and I) easier, I want to give him *temporary* and *restricted* (http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/**) commit privileges to our SVN code repository. +1 Joerg

Re: Supported and unsupported blocks

On 17.03.2005 07:52, Bertrand Delacretaz wrote: The things that disturb me are the name "supported" and the list of committers. Perhaps we should remove that Wiki page once the "job" is done... Agreed, associating people's names with blocks is useful at this decision stage but the page shoul

Re: [CForms] Add isValid() to a widget?

On 07.07.2005 17:32, Carsten Ziegeler wrote: Ok, I could cast it to ValidationErrorAware but it seems a little bit strange to have a validate() method on the widget but no isValid() method. +1 makes sense. Joerg

Re: [CForms] ValidationError, Was: Add isValid() to a widget?

On 08.07.2005 20:58, Vadim Gritsenko wrote: While on the subject of forms validation... I noticed several very annoying things: * Field.getValidationError() *does not* simply return validation error: it has side effects!!! It calls getValue() which can invoke parsing and validation - de

Re: [CForms] Stylesheets incompatible with Saxon 8

On 12.07.2005 17:42, Jason Johnston wrote: It works. The only nagging doubt I have is whether removing the parameter declaration from the included files means that they cannot be used anymore by themselves. I doubt anyone is doing this, however. I'm doing this :-) As the name says, it's forms

Re: DirectoryGenerator using abstract Source

On 13.07.2005 00:28, Michael Wechner wrote: It seems to me that the directory generator is not really based on the "abstract methods" of an excalibur Source, but rather takes the source and "maps" it onto a java.io.File. Is that intended or just not implemented for the lack of time? I would lik

Re: DirectoryGenerator using abstract Source

On 13.07.2005 23:38, Gianugo Rabellino wrote: DirectoryGenerator extends TraversableGenerator We've been through this before: http://marc.theaimsgroup.com/?t=10578281593&r=1&w=2 In a word: backward compatibility. Wow, 2 years ago! And what about starting a real migration now by starti

Re: DirectoryGenerator using abstract Source

Michael Wechner wyona.com> writes: > > Wow, 2 years ago! And what about starting a real migration now by > > starting with the unclean way (DirectoryG extends TraversableG with > > old namespace and directory/file metaphore as you wrote it), > > deprecating it at the same time and making the T

Re: DirectoryGenerator using abstract Source

On 14.07.2005 10:59, Gianugo Rabellino wrote: Don't want to rain on the party, but this has been exactly the kind of discussion that led nowhere a couple years ago. Sorry for that ... I'm now convinced that File/DirectoryGenerator are there to stay, there is just too much stuff depending on

Re: [VOTE] Give Robert Graham temporary and restricted commit privileges to our code repository

On 18.07.2005 09:52, Bertrand Delacretaz wrote: In order to make his life and the life of his two mentors (Ross Gardler and I) easier, I'd like to give him *temporary* and *restricted* (http://svn.apache.org/repos/asf/cocoon/whiteboard/refdoc/**) commit privileges to our SVN code repository.

Re: Moving TraversableGenerator into Cocoon core

On 24.07.2005 14:53, Michael Wechner wrote: Sylvain Wallez wrote: Nope. And while you're at it (/me is lazy), would you mind moving also CSVGenerator? sure (if nobody else minds). So I will move TraversableGenerator XPathTraversableGenerator I have done it already yesterday. The main reas

Re: [vote] Remove 2.0.4 release from dist server?

On 25.07.2005 14:48, Carsten Ziegeler wrote: Our policy asks to just have the latest release on the dist server - all old releases are in the archives and still available. If noone objects I will remove the 2.0.4 from the dist server, leaving just 2.1.7 there. Now that we have eight release in t

Re: [EMAIL PROTECTED]: Project cocoon-block-jcr (in module cocoon) failed

On 25.07.2005 13:56, Gump wrote: [javac] /x1/gump/public/workspace/cocoon/src/blocks/jcr/trunk/test/org/apache/cocoon/jcr/source/JCRSourceTestCase.java:94: cannot resolve symbol [javac] symbol : class JCRNodeSource [javac] location: class org.apache.cocoon.jcr.source.JCRSourceTes

Re: Moving TraversableGenerator into Cocoon core

On 24.07.2005 22:08, Ralph Goers wrote: My understanding is that gump only builds the "latest" version. That would be trunk. This should not prevent us from building 2.1 branch as it would control also our dependencies between the blocks. Joerg

Re: Moving TraversableGenerator into Cocoon core

On 25.07.2005 09:54, Carsten Ziegeler wrote: We voted some time ago to have the scratchpad block only once (in trunk). This makes developing new stuff easier as you don't have to synchronize with the branch etc. Ok, did not kow that. I copied the CSVGenerator from trunk to the branch. Will th

Re: Moving TraversableGenerator into Cocoon core

On 25.07.2005 10:57, Upayavira wrote: I have done it already yesterday. The main reason was that you don't seem to have commit rights on Cocoon: http://people.apache.org/~jim/projects.html#cocoon. Furthermore we talked about it since two years and nobody complained. See this in subversion/au

Re: Cforms Library design decision(s)

On 26.07.2005 13:53, Max Pfingsthorn wrote: Hi everyone! First of all, thank you very much for your warm welcome on our little excursion to ApacheCon last week! It was great! :) Now, it is down to business for me though. I discussed with Silvain about the problem of inclusion/inheritance/part

Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed

On 26.07.2005 13:39, Gump wrote: [cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiLoggerManager.OSGiLogger [cocoon.javac]return isLevelEnabled(LogService.LOG_ERROR); [cocoon.javac] ^ [cocoon.javac] /x1/gump/public/workspace/cocoon/src/

Re: GSoC project - cform XUL status request

On 26.07.2005 20:06, Heh wrote: Next is the XUL form processing. My understanding is that XUL is inherently a "form", that's what a User Interface is supposed to do. But a html form is an add-on to the HTML document, so compared to HTML forms, XUL has no equivalent to the tag (maybe because it

Re: GSoC project - cform XUL status request

On 27.07.2005 00:34, Upayavira wrote: In your previous email, you mentioned something like: "The really interesting part with XUL is to use it as rich client, i.e. to avoid rendering the complete page on each request, but only the parts that need to be rendered." Are you talking about some s

Re: GSoC project - cform XUL status request

On 27.07.2005 07:04, Antonio Gallardo wrote: If you do, you might want to look at Sylvain's work on Ajax with CForms. With that, JavaScript on the browser does XMLHTTPRequests back to Cocoon, and CForms replies with partial XML based upon just the part of the form that has changed. This, to my

Re: [VOTE] Give Heh Huang temporary and restricted commit privileges to our code repository

On 27.07.2005 06:40, Antonio Gallardo wrote: In order to make his life and the life of his two mentors (Jörg Heinicke and I) easier, I'd like to give him *temporary* and *restricted* (http://svn.apache.org/repos/asf/cocoon/whiteboard/xului/**

Re: [VOTE] Jorg Heymans as new committer

On 31.07.2005 08:18, Antonio Gallardo wrote: Hi folks, Jorg Heymans has been around for more than 2 years now, and has contributed with comments on the dev, help on the user list and several patches along the way, [grep -i heymans status.xml] will tell you more), all of good quality. So, I'm p

Re: When do we ask people for a CLA?

On 01.08.2005 11:32, Bertrand Delacretaz wrote: We have accepted several sizeable contributions without requiring a CLA in the past, now the question is, do we want to follow the flow and ask for CLAs for all contributions? From my non-legal, but practical view: What are the ways we receive

snapshot releases (was: target release 1.3 conflicts with default source release 1.5 (on daily snapshot))

On 04.08.2005 22:20, Joerg Heinicke wrote: Compiling 268 source files to /export/home/ray/cocoon-2.1/build/cocoon-2.2.0-dev/blocks/forms/dest /export/home/ray/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/event/ProcessingPhase.java:22: as of release 1.5, 'enum' is a keywor

Re: Suggestion for XHTMLSerializer

On 05.08.2005 13:49, BURGHARD Éric wrote: In fact the XMLSerializer didn't take the 'method' parameter into account. At least in saxon8 (never test with other xslt processor, but it should work too), if you put all tags like div, script, or inputarea remains unclosed. I think this is a bug wit

Re: Suggestion for XHTMLSerializer

On 06.08.2005 11:03, BURGHARD Éric wrote: I wrote a much more powerfull solution: the XSLSerializer, which let you control the serialization through an xsl stylesheet (an so use the xsl:output tag as well as some template rules to make final cleanup like namespace deletion or href contextualizat

Re: Suggestion for XHTMLSerializer

On 07.08.2005 01:27, Jason Johnston wrote: But the important thing is that using an XSLT internally is merely an implementation detail. Exposing the XSLT implementation to users is what Joerg and I take issue with. (Don't mean to speak for you here, Joerg, correct me if I'm misquoting you.)

Re: Suggestion for XHTMLSerializer

On 07.08.2005 10:53, BURGHARD Éric wrote: Perhaps I overused the term "model". I was referring more to the _Document_Object_ Model (DOM) represented by the various stages of the SAX stream. A generator creates one DOM, a transformer converts that DOM into another, and a serializer takes the DO

Re: Suggestion for XHTMLSerializer

On 07.08.2005 14:51, BURGHARD Éric wrote: Of course serializers do transformations, you already wrote it: from SAX to bytes. But there is one important difference: The behaviour of a serializer (and at the end the output) is absolutely predictable. If you feed the same SAX events into a specific

Re: Suggestion for XHTMLSerializer

On 07.08.2005 19:22, BURGHARD Éric wrote: Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go ahead man, you're rich. For me a svg serialization is not reversible, you loose layers, labels, structure and of course scalability. Man, 1:1 does not mean that you can go in b

Re: Suggestion for XHTMLSerializer

On 08.08.2005 21:30, Vadim Gritsenko wrote: Completely wrong. If you find a 1:1 relation between a svg and a bitmap, go ahead man, you're rich. For me a svg serialization is not reversible, you loose layers, labels, structure and of course scalability. Man, 1:1 does not mean that you can go

Re: Suggestion for XHTMLSerializer

On 08.08.2005 23:10, Vadim Gritsenko wrote: XSLT serialization (as per spec Eric quoted) provides a way for "one way 1:1 transformation" of xml into the desired view format exactly in the same way as batik transforms svg into png. XSLT has more capabilities, one even might say that it allows f

Re: Suggestion for XHTMLSerializer

On 09.08.2005 02:17, Vadim Gritsenko wrote: From the pipeline's POV it's not 1:1 as the serializer decides to which output format the XML is serialized, so it is 1:n, so the output is also not predictable for the pipeline. Output of the serializer is never predictable, otherwise no need for

Re: Suggestion for XHTMLSerializer

On 09.08.2005 02:03, Vadim Gritsenko wrote: * Serializers are allowed to implement SitemapModelComponent * SitemapModelComponent has setup method * setup() method passes src parameter - src attribute from the sitemap. Now, from Cocoon design perspective, this is all legal and supported.

Re: Suggestion for XHTMLSerializer

On 10.08.2005 01:44, Antonio Gallardo wrote: OK Guys, I am wondering if all the developers are following this very interesting thread. The pure number of mails speaks for the importance of this thread ;-) I will suggest to start a new one and include in the title the "TraxTransformer" keywor

Re: Proposal: Make defaults for text serializers UTF-8

On 10.08.2005 17:41, Vadim Gritsenko wrote: What do you propose? src="org.apache.cocoon.serialization.TextSerializer" mime-type="text/plain" logger="sitemap.serializer.text"> utf-8 +1 for adding ;charset=utf-8. Long ago we already had a bug about it: http://issues.apache.org/bugzill

Re: Architectural concerns

On 10.08.2005 11:18, Kees Broenink wrote: Suppose the data of the client does not have XML but only request parameters. Now map this to Cocoon: - generator that builds the SQL query using request parameters - SQL transformer (adjusted to throw an exception on error) - XSLT that creates a new pie

Re: EHCache exception

On 12.08.2005 20:38, Ralph Goers wrote: Thanks Peter. I can understand that the in-memory caching makes a huge difference. I am not sure as to whether you are talking about that or external caching. I guess what I am wondering is if setting overflowToDisk to false in ehcache.xml would make muc

Re: CoWarp (was Re: svn commit: r232855...)

On 16.08.2005 17:51, Vadim Gritsenko wrote: Comparing lots of other software out there, Cocoon is among the best one with regards to the effort needed to get up and running. All you need is: download/unzip build.bat cocoon.bat No need to fight with dependency-fetching-tools, hunt for wo

Re: CoWarp (was Re: svn commit: r232855...)

On 16.08.2005 15:04, Carsten Ziegeler wrote: It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces c

Re: CoWarp (was Re: svn commit: r232855...)

On 17.08.2005 11:22, Andrew Stevens wrote: Although as a mere user my vote probably doesn't count, It's a so-called non-binding vote, but your opinion is important though. from my perspective I'm extremely grateful that Cocoon still supports 1.3 and hope that remains the case for the 2.1.x

Re: Manually specifying a mounted sub sitemap's context

On 12.04.2005 12:23, Jochen Kuhnle wrote: So do I enter the context patch into bugzilla now? What's the progress on this? Though I found the bug [1] I can not read it, bugzilla has problems at the moment. Joerg [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=34781

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

On 22.08.2005 19:12, Ralph Goers wrote: Is there a cost for the hackathon? See the button of the registration page. Joerg

Re: [GT2005] ANNOUNCE: Cocoon GetTogether registration NOW open

Is there a cost for the hackathon? See the button of the registration page. Ouch! *Bottom* of course. Joerg

Re: svn commit: r234450 - in /cocoon/trunk: legal/jakarta-regexp-1.3.jar.license.txt legal/jakarta-regexp-1.4.jar.license.txt lib/endorsed/jakarta-regexp-1.3.jar lib/endorsed/jakarta-regexp-1.4.jar li

Could you please update the Bundle-Classpath (used by OSGi) in trunk/src/java/Manifest.mf when you update jars in lib/core or lib/endorsed. I did it for your update, but I might miss updates so it is good if more people remember it. This is only a temporary situation, the jars should be separat

Re: [GSoC] status reports?

Hello Heh, On 24.08.2005 00:39, Heh wrote: Since last discussion, I've been working on how to use rdf data source and xul template to populate XUL widgets, how to connect to cocoon using XMLHttpRequest and update widgets through js scripts. So far I am able to create simple examples to demonstra

Re: (flow) pipelineUtil.processToDOM eating my namespaces declarations

On 25.08.2005 00:09, Johann wrote: It seems that pipelineUtil.processToDOM remove all my namespaces declarations in the DOM it generates. Anyone aware of this limitation, and know a workaround or a fix? I also tried pipelineUtil.processToStream to be sure, and it outputs the right thing, wi

Re: [WHOAMI] Jorg Heymans

On 25.08.2005 13:51, Jorg Heymans wrote: meantime here are some random trivia about my current and past person. A warm welcome! See (hopefully lots of) you in Amsterdam, Jorg oh and my name really is Jorg, so not Joerg or Jörg. This seems to bring confusion sometimes, mostly for German peop

Re: [2.2] Readd jx or move template block to core

On 29.08.2005 16:42, Carsten Ziegeler wrote: The current core uses jxtg in many places (junit tests and a lot of the samples). Currently they are all broken if you just build core which is imho bad. So can we readd the jxtg until the template block is mature enough? Or can we move the template bl

Re: [2.2] Readd jx or move template block to core

On 30.08.2005 10:20, Carsten Ziegeler wrote: That's exactly the idea. After all, we want to be able to have a core that excludes samples. Easiest way to achieve that is to have the samples in an excludable block. Hmm, moving samples into an own block is one thing (which I think we should real

Re: [2.2] Past, present and future of the maven build

On 30.08.2005 17:31, Ralph Goers wrote: A word of caution. One thing we ran into with Maven 1 was that we ended up splitting individual components into 3 parts; api, impl and test. As you start moving from one monolithic project into smaller subcomponents which are compiled separately you wil

Re: [2.2] Past, present and future of the maven build

On 31.08.2005 09:16, Nicola Ken Barozzi wrote: Did I mention that I hate tools needing changes in the subject they should work on to make them work? The above scenario and the other mentioned necessary restructurings were the reason why I ever were against a change of the build system to Maven.

  1   2   3   4   5   6   7   8   9   10   >