Re: [RT] what cocoon forms lack
Andrzej Jan Taramina wrote: now, what do you think? I think that following/supporting the XForms standard, which seems to be getting traction, would be a good thing. Not sure the world needs YAFF (yet another forms framework). Or is the NIH syndrome rearing it's ugly head here? ;-) We have been through this so many times that unless something new (but it should be _incredibly_ new) comes up the discussion is pretty much over. Please do dig the archives: you'll find that this XForms/Woody debate showed up in quite a few occasions and in the end there was consensus on simply not being good enough for server side form handling. 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: Renaming Woody to Cocoon Forms ?
Stefano Mazzocchi wrote: Which is a nice example, here, btw: the OT team proposed an alternative flow control concept and an alternative form framework, the community considered the first inferior to what we already had, but considered superior the second and promoted it as official. Adapting to better reflect historical accuracy: no single line of Woody was written until _after_ Bruno's form proposal was discussed on the list. So in the end, the proposal was about design, and not about a finished code package being donated to the project. I tend to believe that this is exactly the reason why Woody has been able to grow into Cocoon Forms. [at the hackaton, there was a discussion on why the REST-based approach that Marc proposed cannot be matched one-2-one with the flow approach. Marc agreed that his idea of continuation and the current continuation are different concepts and forcing them into the same terminology might stretch the paradigm too much] No matter what the result was, I think forcing people with one solution forced discussions to happen, which helped all the parties involved, even to understand thing that were not previously understood by both sides. This is why having one official direction on the various areas is good(tm) and having a simple name for it cocoon sitemap cocoon flow cocoon forms would help our users to choose and feel more protected and a more solid foundation. +1 - let's go for Cocoon Forms - even if I feel kind of sad seeing the name I suggested going away. Oh well - it's about seeing you kids grow up, I guess. Bearing in mind the amount of work that requires a _real_ renaming, like changing package names, namespaces and all that - who's going to do that? Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: [RT] Separation of Blocks and Avalon
Stephen McConnell wrote: The million little details that cocoon assumes on top of ECM is also the thing that scares me the most. Me, too. And I'm really wondering if we can keep our nice little additions if we move away from ECM. Is there someone who provide the breakdown of what Cocoon is doing over and above ECM? However things roll out - one of the biggest obsticles I see is that we need to move away from ECM/Fortress extension and to a solution where Cocoon does not need to access container APIs. With that information the Avalon crowd can address how to addres these requirements in a way that makes the concern indpendent of the container implementaiton. We extend the ECM with our CocoonComponentManager, you can have a look at that class. All the features (hacks?) in there have to be somehow available using fortress, merlin or whatever. We have another lifecycle type, the request lifecycle component. This is an extension to poolable and means that per request only one instance of this component is used. So if two other components lookup this request lifecycle component, they get the same instance. The implementation of this extension is a little bit difficult as we have sub requests that run in the same thread but have a different set of request lifecycle components. In addition it's possible to process on request multi threaded which makes this even more difficult. There are some other important extensions like the environment handling for the source resolver and the sitemap configurable components. They use more or less the same technique used for the request lifecycle components. I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this). Carsten
Re: Renaming Woody to Cocoon Forms ?
Steven Noels wrote:
Stefano Mazzocchi wrote:
snip/
This is why having one official direction on the various areas is
good(tm) and having a simple name for it cocoon sitemap cocoon
flow cocoon forms would help our users to choose and feel more
protected and a more solid foundation.
+1 - let's go for Cocoon Forms - even if I feel kind of sad seeing
the name I suggested going away. Oh well - it's about seeing you kids
grow up, I guess.
I propose that we put in the docs some notes about the history of
Woody/Cocoon Forms: who started it (you deserve credit), the initial
name and where it came from, etc, etc, including the australian meaning
of woody ;-)
Bearing in mind the amount of work that requires a _real_ renaming,
like changing package names, namespaces and all that - who's going to
do that?
I volunteer for this. This move should also be the occasion of doing the
refactoring (rather a polishing, actually) I proposed in august so that
we quickly have some stable APIs.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Renaming Woody to Cocoon Forms ?
Sylvain Wallez wrote: I propose that we put in the docs some notes about the history of Woody/Cocoon Forms: who started it (you deserve credit), the initial name and where it came from, etc, etc, including the australian meaning of woody ;-) +1 (apart from the australian meaning) We have the CREDITS text for exactly that purpose. I volunteer for this. This move should also be the occasion of doing the refactoring (rather a polishing, actually) I proposed in august so that we quickly have some stable APIs. Just curious, when are you planning to do so? Carsten
Re: Renaming Woody to Cocoon Forms ?
Sylvain Wallez wrote:
snip
I volunteer for this. This move should also be the occasion of doing
the refactoring (rather a polishing, actually) I proposed in august so
that we quickly have some stable APIs.
But as far as the continuation and flowscript support for this goes, I
think refactoring is the proper term. IMO the hack to support
${continuation.id} and the whole JS (woody.js, woody2.js) interface
needs to be redesigned.
My $0.02,
Chris
RE: [RT] FirstFriday - monthly virtual Hackathon
Title: RE: [RT] FirstFriday - monthly virtual Hackathon De : Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 9 octobre 2003 15:26 ... http://irc.codehaus.org/channels/geronimo/2003-09-15.html Impressive example of zero signal/noise ratio, BTW. I really hope we do better than this. Since you won't prevent people from joking and saying hello and asking news about wives and children, we should either have two IRC channel in parralel (/join #cocoon #cocoon_logged) (handy with ircII, but boring with mirc), or have a protocol to tell the bot what need to be logged. I'd suggest tu use the java syntax (do not log messages that beging with //, stop logging a user if message == /* until message==*/), but it poses the problem of code copy/paste. Two other problems with code copy/paste are : -Bot's flood protection should be disabled at least for code -Since the client will send each line as one message, ligned might be mixed with other peoples messages. That might be prevented with introducing the code and /code message with would also allow pretty printing of logs and use of java-like comments. fabien.
Re: Renaming Woody to Cocoon Forms ?
Carsten Ziegeler wrote: Sylvain Wallez wrote: I propose that we put in the docs some notes about the history of Woody/Cocoon Forms: who started it (you deserve credit), the initial name and where it came from, etc, etc, including the australian meaning of woody ;-) +1 (apart from the australian meaning) Hehe. It was funny seeing people finding that out - though it was the first thing which came to my mind when seeing Debian Woody quite some time ago. I must have been lectured English using tasty reading material, I guess. Or I've been subject to too much crafterm'isms over the past years. ;-) We have the CREDITS text for exactly that purpose. CREDITS should be used for proper donations, developed parallel to the collaborative community process, IMHO, and donated in an official way to the ASF (using the proper paperwork). Looking at the current list, we should actively try to keep it as short as possible. Web3 should be in it, as well, to give an example. I'm -0 to add any little company-funded piece of code into the CREDITS file, since it would become a marketing tool then. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Renaming Woody to Cocoon Forms ?
Christopher Oliver wrote:
But as far as the continuation and flowscript support for this goes, I
think refactoring is the proper term. IMO the hack to support
${continuation.id} and the whole JS (woody.js, woody2.js) interface
needs to be redesigned.
+1, and a big thank you for this cool-headed remark.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: Track feature requests in bugzilla?
Bertrand Delacretaz wrote: Another issue is the configuration of bugzilla itself. Isn't it customizable? Furthermore more recent versions offer more options. I bet ...but doesn't Bertrand know? :) Newer versions of bugzilla use HTML templates which can make it look much nicer if that's the problem. I think it is part of the problem if we're going to make more serious use of bugzilla, there's no excuse for looking bad on the web today. Also, the query form in 2.16 has a better layout which helps a lot when you start using it. Good to hear. Finally, saved queries help a lot, you can create the 4-5 queries that you need regularly and then mostly forget about the query page. I don't know if they exist in the 2.14.2 version that we're using, but if they are they seem to be disabled (Pier?). No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And they are simple to use with an URL like http://nagoya.apache.org/bugzilla/buglist.cgi?cmdtype=runnamednamedcmd=Cocoon. Why do you think they are disabled? An easy workaround if saved queries cannot be enabled for some reason is to create more links like the patch queue and open bugs links that we have on the web and wiki. What happened in the last X days and what's unassigned come to mind and are easy to do. But I agree with Andrew and Jeff that the current bugzilla works - it might not be pretty (it is ugly actually), and is lacking in ways of classifying issue types, but it does the job if one is willing to use it. I'm not sure about switching to another tracking system. The new toy syndrom could help people make more use of it, OTOH if people are not willing to use it they will not and we will only have wasted time. A bugzilla upgrade might be good though. My suggestion would be to stay with bugzilla until the next 1-2 FirstFridays at least and see how we do. Until then, have a vote on where we want to track feature requests, bugzilla or wiki will both work for these IMHO, this is not such a big deal. +1 Joerg
Re: mounting blocks question
On Friday, Oct 10, 2003, at 04:43 Europe/Rome, Geoff Howard wrote: We decided that wiring.xml would have entries like: mount/mail//mount How would this work for using hostname based mounting? no. this concerns applies to the servlet hosting environment, there is nothing we can do from this side of the Servlet API fence to trigger virtual host configuration. Use case: http://mail.mydomain.com http://www.mydomain.com Two different applications, same cocoon instance. (mail block) mount host=mail.mydomain.com//mount ?? (main site block) mount host=www.mydomain.com//mount ... (authentication block) mount/login/mount (defaults to all hosts) single sign-on, right? yeah, thought about it extensively but no, we can't do it from this side, unless we hook to a particular servlet container and we modify its configuration files directly and not thru the servlet API. and in a two-tier environment (think apache+tomcat), this is not even enough, since the virtual hosts are configured in httpd.conf. Is it possible to achieve the same functionality? yeah, you bet, with a little tuning of httpd.conf, a few aliases and/or mod_rewrite URI rewriting. -- Stefano.
FYI: DocSynch as a collaborative editing tool?
Just found out about it at http://placebo.hpi.uni-potsdam.de/~alexklim/#docsynch and http://trieloff.dyndns.org/archive/000427.html It is a JEdit plugin and uses IRC (and DCC - what's this?) to exchange data, so we wouldn't need additional communications tech or service registrations. I have to run to bread-and-butter work and won't be able to test it soon, but if someone wants to try, keep us posted! -Bertrand
Re: Renaming Woody to Cocoon Forms ?
On Friday, Oct 10, 2003, at 09:15 Europe/Rome, Steven Noels wrote: Bearing in mind the amount of work that requires a _real_ renaming, like changing package names, namespaces and all that - who's going to do that? I would suggest we do that in Cocoon 2.2 For the users, a planned incompatibility is not so bad, expecially if it's just a matter of doing namespace changes between (very few users care about package names). thoughts? -- Stefano.
Re: Renaming Woody to Cocoon Forms ?
Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:15 Europe/Rome, Steven Noels wrote: Bearing in mind the amount of work that requires a _real_ renaming, like changing package names, namespaces and all that - who's going to do that? I would suggest we do that in Cocoon 2.2 For the users, a planned incompatibility is not so bad, expecially if it's just a matter of doing namespace changes between (very few users care about package names). thoughts? Fine with me - it's a community thing now (which we will actively try to support, of course). /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] what cocoon forms lack
On Friday, Oct 10, 2003, at 09:27 Europe/Rome, Bertrand Delacretaz wrote: (commenting on the editor stuff only) Le Jeudi, 9 oct 2003, à 23:28 Europe/Zurich, Stefano Mazzocchi a écrit : ...I see two potential types of editor: - plain text - stuctured text Rich text is one of the potential structured text. I dislike textarea as a style if an string input field. it doesn't feel right: a textarea is the style of an editor OTOH being able to edit (wiki-like?) text from a plain textarea must be possible as a fallback for when people don't have the right browser, mobile stuff, etc. It is certainly easy to do but must be taken into account. Sure. but you missed my point. The critic was not about HTML textarea but about where the textarea concept resides on woody. Today, woody believes that textarea is a style of a string input widget. I dislike this. I think textarea is a mode of a yet-to-be-there editor widget, exactly for the reasons you mention above and because widget should be separate for their use, not for the output they create. ...In linotype you have Wysiwig and markup, introducing a wiki mode is in my todo list. Do you envision a server-side format converter for this? no, client-side. I plan to write javascript to do this, so that I'm able to move back and forward from a wiki view, a markup view and a WYSIWIG view from the client side. I'm asking because a good birdirectional wiki-to-xhtml conversion component in java would be very useful. The current chaperon stuff doesn't provide this. a javascript wiki2xhtml parser would be just as functional and can be used on both sides (even if would require some tricky things, since in the client side the dom is already there, exposed) ...I would love to have linotype as a cform widget with pluggable editing modes that share content: so that you can write your wiki text, then click on the wysiwig tag and edit content like that, back and forward, you can cut/paste stuff in and out now, what do you think? I like this - if this is used for our docs later on, being able to cut/paste wiki stuff in and out would be very useful for offline work. yep, the gt-notes-editing experience showed me this as well! -- Stefano.
Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf
On Thu, 9 Oct 2003, Antonio Gallardo wrote: antonio 2003/10/09 13:12:35 Modified:src/webapp/WEB-INF cocoon.xconf Log: Fixing bug related to woody form handling posted by Carlos Chávez. Bruno Dumon suggested the fix and it works back again. Revision ChangesPath 1.31 +1 -1 cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf Index: cocoon.xconf === RCS file: /home/cvs//cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- cocoon.xconf 6 Oct 2003 16:10:55 - 1.30 +++ cocoon.xconf 9 Oct 2003 20:12:35 - 1.31 -parameter name=reuse-parsers value=true/ +parameter name=reuse-parsers value=false/ Next time we need to be more carefully :) Best Regards, Antonio Gallardo Andrew. -- Andrew Savory [EMAIL PROTECTED]
Re: [RT] Separation of Blocks and Avalon
On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this). Amen. -- Stefano.
Re: Track feature requests in bugzilla?
Le Vendredi, 10 oct 2003, à 10:11 Europe/Zurich, Joerg Heinicke a écrit : Bertrand Delacretaz wrote: ...Finally, saved queries help a lot, you can create the 4-5 queries that you need regularly and then mostly forget about the query page. I don't know if they exist in the 2.14.2 version that we're using, but if they are they seem to be disabled (Pier?). No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And they are simple to use with an URL like http://nagoya.apache.org/bugzilla/ buglist.cgi?cmdtype=runnamednamedcmd=Cocoon. Why do you think they are disabled? You mean saving bookmarks to queries, right? In 2.16 you can actually save a query, give it a name and it can appear as a link at the bottom of the bugzilla page when you're logged in, it's much more convenient and stays on the server. According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest this seems to exist in our version, but I don't see the corresponding fields on the query form. Am I overlooking something? -Bertrand
RE: [site docs] build failing
Building the docs failed because plan/changes.rss could not be generated (no pipeline found). I just checked in a hack to the doc sitemap, so this pipeline is now found and building the docs, especially the site docs works again. Does anyone know where plan/changes.rss is used and why? Carsten
Re: [RT] what cocoon forms lack
Stefano Mazzocchi wrote:
Thanks to the great energy that Sylvain is able to put into things, we
now have a community consensus on making woody the official cocoon
form framework.
On the trip back from the GT, I spent some time talking to David
Nuescheler. A while ago, I suggested him to take a look at linotype
and he liked the concept and told his guys to use it.
On the train, he told me: you know, the idea of making linotype a
woody widget is not so far off as it seems, we did our own form
framework and editing framework and came up with nothing that could
distinguish the two, so we are making an effort to merge the two.
This triggered an incredible amount of thinking... during the hours
that took me to get back and thanks to sylvain's handouts, I was able
to have a solid reference for my thinking.
- o -
There are two widgets that cforms are missing:
- editor
- uploader
Hey, you know what, some of the people that went to me after my talk
proposed just the same ;-)
I see two potential types of editor:
- plain text
- stuctured text
Rich text is one of the potential structured text.
I dislike textarea as a style if an string input field. it doesn't
feel right: a textarea is the style of an editor.
Mmmh... What I understand above is that you distinguish two types of
string inputs:
- single line inputs that go through a regular input
- multi-line strings or structured documents that go through an editor
widget of which textarea is a particular representation (styling, in
the current terminology). Am I right?
This also calls for an additional built-in field datatype: xml, that
would automatically parse the input string upon submit. We can also have
specialized validators for this datatype that check that the document is
valid according to some kind of schema.
I also see two potential types of uploaders:
- active
- passive
Passive uploaders are the usual ones, the ones with a input field and
a browse button. (normally native widgets that are not CSS modifiable)
Active uploaders are the one that react on the content being uploaded
and show it (like the image uplaoder in linotype).
Active upload is really cool.
An associated need for upload, along with drag'n dropping images in an
editor, is for generic binary attachements to a document (in the general
meaning of document). Graphically, this could be a drop zone
associated to the (growing) list of file names.
The idea is the following: both widgets make available to the
controller (after having been processed), an object model that
contains the content. The template generators should be able to
process the object model of a structured text and crawl it
transparently to generate SAX events.
This calls again for the xml datatype, with an associated set of
converters (xml/wiki/slop parsers).
- o -
Note, however that these widgets don't resolve the need for a
semi-structured editing capabilities of the page (a-la
contentEditable), but they go a pretty long way to provide capabilities.
Another interesting feature would be providing different modes for
the editor, just like different tab panes that react on the content.
In linotype you have Wysiwig and markup, introducing a wiki mode is in
my todo list.
I would love to have linotype as a cform widget with pluggable editing
modes that share content: so that you can write your wiki text, then
click on the wysiwig tag and edit content like that, back and forward,
you can cut/paste stuff in and out.
Implementation-wise, having multiple simultaneous formats client-side
may be require tricky javascript development. Since we must have the
parsers for these formats server-side, we can use the submit-on-change
feature so that clicking on a format tab does a round-trip to the server
to convert the format.
now, what do you think?
I think: kewl ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: FYI: DocSynch as a collaborative editing tool?
On Fri, Oct 10, 2003 at 10:13:04AM +0200, Bertrand Delacretaz wrote: Just found out about it at http://placebo.hpi.uni-potsdam.de/~alexklim/#docsynch and http://trieloff.dyndns.org/archive/000427.html It is a JEdit plugin and uses IRC (and DCC - what's this?) to exchange data, so we wouldn't need additional communications tech or service registrations. DCC stands for Direct Client Communication, allowing you to bypass the irc server. its used for sending and recieving files between users. Michael I have to run to bread-and-butter work and won't be able to test it soon, but if someone wants to try, keep us posted! -Bertrand
Re: Renaming Woody to Cocoon Forms ?
Christopher Oliver wrote:
Sylvain Wallez wrote:
snip
I volunteer for this. This move should also be the occasion of doing
the refactoring (rather a polishing, actually) I proposed in august
so that we quickly have some stable APIs.
But as far as the continuation and flowscript support for this goes, I
think refactoring is the proper term. IMO the hack to support
${continuation.id} and the whole JS (woody.js, woody2.js) interface
needs to be redesigned.
+1
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [GT2003] Thank you
Here's another Very Late Thank You to all at the Cocoon GetTogether! Special thanks to Steven for all his hard work and of course Marc, Bruno and the Orixo gang as a whole who made this possible. I had fun. We've been brutally abusing the flamish hospitality, and I hope to do so again next year! Regards, Arjé Cahn Hippo Webworks Grasweg 35 1031 HW Amsterdam The Netherlands Tel +31 (0)20 6345173 Fax +31 (0)20 6345179 - [EMAIL PROTECTED] / www.hippo.nl --
Re: ResolverImpl test case broken again?
Ugo Cei wrote: David Crossley wrote: I tested your patch and that works fine on my system. Well done, i believe that you have fixed it. Would you please commit. I'll do this ASAP. So we can leave the resolver test cases there until we find something better to do with them. We really need to clean up all of the testcases. Having slept over the issue (not much, just a little more than 4 hours :-(), these are my thoughts: We should strive for 100% test coverage. Removing a test case without removing the class being tested is no good, in my book. Should we remove the ResolverImpl class? As far as I can see, it's not used anywhere in our codebase, apart from the test case. On the other hand, it's not @deprecated, even though it implements a deprecated interface. Should we call a vote on the issue? If no-one says anything in the next few days, then i will remove the resolver testcases. They served their purpose here in Cocoon while developing the entity-resolver stuff, to ensure that it worked on all platforms. --David
Re: Renaming Woody to Cocoon Forms ?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I volunteer for this. This move should also be the occasion of doing the
refactoring (rather a polishing, actually) I proposed in august so that
we quickly have some stable APIs.
Just curious, when are you planning to do so?
I should be starting this by the end of next week. The start of the week
will be occupied giving a... Flowscript Woody training!!!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] what cocoon forms lack
Le Vendredi, 10 oct 2003, à 10:21 Europe/Zurich, Stefano Mazzocchi a écrit : ...I dislike textarea as a style if an string input field. it doesn't feel right: a textarea is the style of an editor OTOH being able to edit (wiki-like?) text from a plain textarea must be possible as a fallback for when people don't have the right browser, mobile stuff, etc. It is certainly easy to do but must be taken into account. Sure. but you missed my point. The critic was not about HTML textarea but about where the textarea concept resides on woody. Today, woody believes that textarea is a style of a string input widget. I dislike this. I think textarea is a mode of a yet-to-be-there editor widget, exactly for the reasons you mention above and because widget should be separate for their use, not for the output they create. ok, got it now ;-) ...In linotype you have Wysiwig and markup, introducing a wiki mode is in my todo list. Do you envision a server-side format converter for this? no, client-side. I plan to write javascript to do this, so that I'm able to move back and forward from a wiki view, a markup view and a WYSIWIG view from the client side. Why not server-side java? Is it a design or implementation concern? Client-side avoids a round-trip but introduces client dependencies which could be avoided. And being able to write pluggable format converters in java for Linotype editing would be cool. Not sure about javascript. ...I'm asking because a good birdirectional wiki-to-xhtml conversion component in java would be very useful. The current chaperon stuff doesn't provide this. a javascript wiki2xhtml parser would be just as functional and can be used on both sides (even if would require some tricky things, since in the client side the dom is already there, exposed) hmm..back to DOM server-side? (but if you're writing the code and I'm not, who am I to argue ;-) ...I like this - if this is used for our docs later on, being able to cut/paste wiki stuff in and out would be very useful for offline work. yep, the gt-notes-editing experience showed me this as well! I'm glad to hear this! -Bertrand (trying hard to get back to this bread-and-butter stuff ;-)
[RT] Updating the website
Due to my nice(?) rearranging of the docs we are not able to update our website without breaking some external links. And this is (to say it friendly) very bad. But we have updated/new docs that should be published asap. So how can we manage this? Stefano had an impressing (wild) idea at the GT which sounds very cool, but will unlikely not happen today or tomorrow. I personally wanted to update the site asap, at least with the next release for 2.1.3 - our great bug fix release. I wanted to start this RT to discuss some possibilities, so here are some: a) I revert the structural changes (cause in the end it's my fault) b) We update and don't care about external links c) We update and care a little bit about external links and redirect a 404 to let's say the start page Thoughts? Carsten
Re: Track feature requests in bugzilla?
Bertrand Delacretaz wrote: Joerg Heinicke a écrit: Bertrand Delacretaz wrote: ...Finally, saved queries help a lot, you can create the 4-5 queries that you need regularly and then mostly forget about the query page. I don't know if they exist in the 2.14.2 version that we're using, but if they are they seem to be disabled (Pier?). No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And they are simple to use with an URL like http://nagoya.apache.org/bugzilla/ buglist.cgi?cmdtype=runnamednamedcmd=Cocoon. Why do you think they are disabled? You mean saving bookmarks to queries, right? In 2.16 you can actually save a query, give it a name and it can appear as a link at the bottom of the bugzilla page when you're logged in, it's much more convenient and stays on the server. According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest this seems to exist in our version, but I don't see the corresponding fields on the query form. Am I overlooking something? You must be missing it. I use that feature all the time. I have a few queries stored in my Bugzilla user space: cocoon2-outstanding and cocoon2-major Look for the Remember this query, and name it feature on the query page. I am quite happy with using Bugzilla and see no need to change. --David
Re: Track feature requests in bugzilla?
Bertrand Delacretaz wrote: ...Finally, saved queries help a lot, you can create the 4-5 queries that you need regularly and then mostly forget about the query page. I don't know if they exist in the 2.14.2 version that we're using, but if they are they seem to be disabled (Pier?). No, I'm using them heavily. One for Cocoon, one for XSLTC, ... And they are simple to use with an URL like http://nagoya.apache.org/bugzilla/ buglist.cgi?cmdtype=runnamednamedcmd=Cocoon. Why do you think they are disabled? You mean saving bookmarks to queries, right? In 2.16 you can actually save a query, give it a name and it can appear as a link at the bottom of the bugzilla page when you're logged in, it's much more convenient and stays on the server. No, I have different queries in my footer. I have to login to use them. Nothing about bookmarks. According to http://nagoya.apache.org/bugzilla/queryhelp.cgi#therest this seems to exist in our version, but I don't see the corresponding fields on the query form. Am I overlooking something? If I go to http://nagoya.apache.org/bugzilla/query.cgi I have this part of the form at the end of the page above the footer. Joerg
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository?
Re: Track feature requests in bugzilla?
Le Vendredi, 10 oct 2003, à 10:41 Europe/Zurich, David Crossley a écrit : ...You must be missing it. I use that feature all the time. I have a few queries stored in my Bugzilla user space: cocoon2-outstanding and cocoon2-major Look for the Remember this query, and name it feature on the query page crawling-under-the-table err..blush...I was not logged in to bugzilla ;-) It's this age thing again I guess, sorry for the noise. /crawling-under-the-table I am quite happy with using Bugzilla and see no need to change. so am I, except for a non-urgent upgrade to a newer version. -Bertrand
Re: [RT] Using modifiers within Cocoon components
Puh, finally arrived at home. I took some days to visit the belgium coast. The name 'modifiers' comes from the java grammar, and include more than private and public. But if we talking only about accessibility, then @access is ok. On Thu, 9 Oct 2003, Sylvain Wallez wrote: Geoff Howard wrote: I like access=private and access=public. - Which is the default if none is specified? (public) Hmmm, on second thought, uri access : @internal-only block access : @access are these two orthoganal concepts named deceptively in the case of pipelines? @access is not meant to imply whether a pipeline can be accessed but whether it can be extended or used outside the block. I think your analysis is right: @internal-only is related to the origin of the request, while @access is about inter-block relations. It may make sense to have a pipeline with internal-only=true and access=public, meaning it's not visible from the non-Cocoon world (i.e. only through cocoon: requests), but that other blocks can use it. If we never envision anything other than private/public would something like block-private=true convey more meaning? block-access=private might do the same but leave freedom for other than private/public. Blocks can be extended, and so having protected along with public and private may be needed. I don't see a need for package visibility, though. What about using the access modifier 'protected' for internal-only pipelines map:pipeline access=private - Accessible only by the current sitemap map:pipeline access=public- Accessible from outside of Cocoon map:pipeline access=protected - Accessible by all blocks, but not outside of Cocoon BTW, shouldn't the 'root' block decide which resources are public and which are private?! So that everything is protected, except the 'root' block exposes them. Stephan.
Re: FYI: DocSynch as a collaborative editing tool?
Bertrand Delacretaz wrote:
Just found out about it at
http://placebo.hpi.uni-potsdam.de/~alexklim/#docsynch
and
http://trieloff.dyndns.org/archive/000427.html
It is a JEdit plugin and uses IRC (and DCC - what's this?) to exchange
data, so we wouldn't need additional communications tech or service
registrations.
Wow, looks cool! And an Eclipse plugin is planned also!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Finishing the first phase of block design
On Friday, Oct 10, 2003, at 04:01 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
I have updated the block design documents on the wiki. Changes were:
...
A few things are left to decide:
1) the block metadata information in the block.xml file
see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
2) how blocks expose classloading to other blocks
...
Exposing classes
Stephen proposed to separate the classes to expose in a different
jar and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks,
I propose to extend the block FS layout so that we have
for individual classes and resources:
/classes
/classes/public
/classes/private
for jars:
/lib
/lib/public
/lib/private
Hmmm. That is quite different than what one would expect from the
WAR paradigm, no? Would
COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or
COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?
This might suggest the concept that private is the location of all
the things that are private so
private/lib
means I have libraries in the private section, so maybe I can put
something else as well to have it protected? while
lib/private
means these are the private libraries... but doesn't say anything
about non-lib things. I still like this approach better, even if it
moves away from the WAR paradigm (which is not a big deal, IMO, since
blocks are different enough already)
Ok, that's a good point. I have a parallel concern that something like
COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
or
package public.com.myconfused.package
public Class StillNotFound {...
will pop up regularly on the users list.
hmmm, don't think so, don't see many users actually adding their own
single classes to those blocks and then deploy. I think they will put
their prepackaged jars in there. but hey, you might be right.
One more idea to try to avert potential confusion.
COB-INF/private-lib/
COB-INF/private-classes/
COB-INF/public-lib/
COB-INF/public-classes/
?
I'm -0 on this, don't see the need, but I see your point.
- Not found resources will have to go through every pipeline to
determine that it's not found. With fallback behavior due to
polymorphism this gets worse.
I fail to see this, can you explain why you think this is the case?
sitemap references:
block:external-skin:/stylesheets/news2html.xslt
block manager has external-skin -
http://mycompany.com/skins/corporate/34.3.345
- extends -
http://yetanothercompany.com/skins/fancy/1.2.2
checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob
samples at the wiki don't have sitemaps for the skins blocks which
would presumably need them to expose their xslt in the example right?)
no, if the sitemap is not explicitly exposed, then the block manager
will default to sitemap.xmap in the root. if *that* is not present,
than the block does not expose resources and the block: protocol would
return a 404 or trigger an exception.
If that sitemap doesn't override /stylesheets/news2html.xslt, every
pipeline in that sitemap needs to be checked _then_ block manager goes
on to
WEB-INF/blocks/how-does-the-block-wiring-handle-blocks-extended-but-
not-otherwise-used/sitemap.xmap
if there are several levels of extension, this could be a long process.
true
But now a worse thought comes to mind:
suppose http://yetanothercompany.com/skins/fancy/1.2.2 has defined
map:match pattern=stylesheets/*.xslt
map:read src=styles/{1}.xslt/
/map:match
but http://mycompany.com/skins/corporate/34.3.345 only wants to
override /stylesheets/news2html.xslt and /stylesheets/another.xslt
if it is allowed it do
map:match pattern=stylesheets/*.xslt
map:read src=mystyles/{1}.xslt/
/map:match
then we must make the block manager and sitemap engine have a new
behavior: if a match exists, but the source is not actually found,
proceed to the super-block etc.
nono, inheritance works as the URI matching level, not at the resource
level. If you match the URI and then you failed to provide a resource,
you get a 404. So, at least, you know where you are.
That's a mess, but so is having to set up a whole series of identical
pipelines for every image, stylesheet, etc you need to override from a
super-block, isn't it?
You can use regexp matching. It's not that bad.
I don't picture extension to change *everything* inside the block, but
just a few details. anti-patterns will emerge and verbosity of the
sitemap would reduce the change of abusing block extension.
Now, perhaps this could be handled in other ways by using selectors
instead of wildcards in matchers, but this could make writing a block
a little finicky.
i think regexp matching is perfect for this
If we decide to go with existing semantics with no explicit list of
provided or overridden
RE: FYI: DocSynch as a collaborative editing tool?
I'm trying to get it running... Does anyone care to join me on #cocoon and give it a
try?
Arje
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Posted At: vrijdag 10 oktober 2003 10:50
Posted To: Cocoon Dev List
Conversation: FYI: DocSynch as a collaborative editing tool?
Subject: Re: FYI: DocSynch as a collaborative editing tool?
Bertrand Delacretaz wrote:
Just found out about it at
http://placebo.hpi.uni-potsdam.de/~alexklim/#docsynch
and
http://trieloff.dyndns.org/archive/000427.html
It is a JEdit plugin and uses IRC (and DCC - what's this?)
to exchange
data, so we wouldn't need additional communications tech or service
registrations.
Wow, looks cool! And an Eclipse plugin is planned also!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
[OT] create thumbnails of html
I know this is slightly off-topic but does anyone on the list now of an open source component that can create an image thumbnail of a html page like the HTML2JPG blackbox component? http://www.html2jpg.com/ I thought about doing some weird stuff with pipelines in cocoon to achieve this but it seems to much of a hassle. /Regards Mats
Apache Newsletter - volunteers?
I think the deadline for http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/ Issue2 is soon, don't have time to write ATM but it might be good if someone could write about the GT. -Bertrand
Re: [RT] Finishing the first phase of block design
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
I have updated the block design documents on the wiki. Changes were:
...
A few things are left to decide:
1) the block metadata information in the block.xml file
see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
2) how blocks expose classloading to other blocks
- o -
Descriptive Block metadata
--
The descriptive block metadata that we currently include is:
name***/name
description href=...***/description
license href=.../***/license
author href=...***/author
+1
Andreas suggested version number which is really handled already in
the block id and release date. I think a date though may be a useful
additional piece of info.
Good point.
IMHO, I would try first a solution, which doesn't introduce a new
descriptor. In a know german XML magazin, Cocoon was descriped a
configuration hell, and as a anti pattern using XML as
configuration format.
So my proposal would be to start small, and if there isn't a way
to come forward with the current possibilities, then
we could introduce a new descriptor file beside
cocoon.xconf/sitemap.xmap/web.xml etc.
Exposing classes
Stephen proposed to separate the classes to expose in a different jar
and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I
propose to extend the block FS layout so that we have
for individual classes and resources:
/classes
/classes/public
/classes/private
for jars:
/lib
/lib/public
/lib/private
Hmmm. That is quite different than what one would expect from the WAR
paradigm, no? Would
COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or
COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?
Could you please explain, why we need to separate the classes and lib into
private and public. For the developers POV, it will make the development
more complicated, and doesn't see any benefit.
Exposing Resources
--
I'm adding this because my brain is still a little unsure about this.
So far, we've said that file resources (an xsl for example)
1) need to be exposed via a sitemap pipeline, even if only by a reader
2) are not anywhere declared explicitly (except in the pipeline of
course)
3) are not distinguised from resources meant to be private by any
formal semantics, though this information could be conveyed
human-to-human in any block docs (blocs? blockumentation? ;) ).
Here are my oustanding questions:
- Will we regret requiring the overhead of pipeline setup (runtime I
mean) for blocks which expose a great deal of otherwise static
resources?
could be. remember though that the block: protocol will be caching
friendly, so we might even gain performance.
- Not found resources will have to go through every pipeline to
determine that it's not found. With fallback behavior due to
polymorphism this gets worse.
I fail to see this, can you explain why you think this is the case?
- Will not explicitly declaring which resources are meant to be public
cause trouble for block implementors and extenders?
?? well, in the sitemap I can be very precise on what I want to expose.
and everything else is not exposed. the sitemap is like a virtual file
system description, powerful enough to describe all possible systems.
If you have
pipeline block-access=public
match pattern=**
read src=public/{1}/
/match
/pipeline
than the contract moves at the file system level, but that's up to you
to decide and a block extender can do
pipeline block-access=public
match pattern=stylesheet/layout2page.xslt
generate type=sql src=layout.xml/
transform src=layout2stylesheet.xslt/
serialize type=xml/
/match
/pipeline
to provide extension that is procedural (but without exposing, for
example layout.xml and layout2stylesheet.xslt which are just used
internally)
Yes, I like that. This is the solution, which comes first in my mind.
Stephan.
Re: [RT] Virtual components and JXTemplate
On Thu, 9 Oct 2003, Sylvain Wallez wrote: Stephan Michels wrote: On Tue, 7 Oct 2003, Sylvain Wallez wrote: AFAIU, the use of JXTemplate as a generator allows the template to be pre-analyzed and stored into the cache, thus allowing a greater performance. This cannot be achieved with the transformer. There are use cases where templates are dynamically computed. In these cases, you can either use the JXTemplate transformer or use the generator with a cocoon: source. In that latter case, you also benefit of the fact that the cocoon: source may be cached as well. Yes, but the problem is that the output of the JXTemplate is high dynamic, and isn't cachable, so I make most of transformations before like i18n and some other. That's why I was suggesting to use a cocoon: source as the input of JXTemplateGenerator: this allows the template to be cached. The other solution is to use CachingPointPipeline. Hmm, yes will be a solution, but like the following case more map:generate type=file map:transform type=i18n map:transform type=xsl src=.. map:transform type=xsl src=.. map:transform type=jx map:transform type=xsl src=.. map:serialze instead of map:generate type=file map:transform type=i18n map:transform type=xsl src=.. map:transform type=xsl src=.. map:serialze type=xml map:generate type=jx src=cocoon:/whatever map:transform type=xsl src=.. map:serialze There is also some other thing, the newest jvm are optimized to dispatch great numbers of small classes, like the classes, which be used to store the events. Sorry, what do you mean by dispatch great number of small classes ? Is it that about the handling of small short-lived objects ? Yes, so caching these event classes gives more problems than benefits. That why sometimes pool of objects are slower than the instantiation. But just a thought, Stephan.
Re: [RT] Separation of Blocks and Avalon
On Friday, Oct 10, 2003, at 10:44 Europe/Rome, Ryan Hoegg wrote: Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? do you have a list of things that worry you most? BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. -- Stefano.
RE: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? do you have a list of things that worry you most? BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. Amen :) Carsten
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. -- Stefano. This sounds like a good idea, since we seem to have a much more mature idea of what the blocks implementation entails than the container change. One reason we might consider a new container first is that it might simplify the block design. One thread that is still active talks about how to expose classes to other blocks. This requirement might go away completely if blocks can access java in other blocks only through the avalon container, and we decide that any java code the block wants to provide must be packaged using a standard format. The risk is that the container upgrade is very complex and time consuming, causing all the good ideas about blocks to be put on hold. Of course ultimately the people doing the work will make the decision :) -- Ryan Hoegg
[newbie] UrlExistsSelector
Greetings developers,
as a newbie to the wonderful world of Cocoon sitemaps I was struggling
with the problem of using a selector to determine if an external HTTP
URL was available.
* Problem description:
A pipeline matcher with the following steps is triggered:
1. XSP generation
2. cinclude transformation
3. XSLT transformation
4. HTML serialization
The cinclude in step 2 triggers another cocoon pipeline. XSP snippet:
ci:include src=cocoon:/(name of pipeline #2)
xmlns:ci=http://apache.org/cocoon/include/1.0/
Pipeline #2:
1. (what I wanted) map:select and generation based on status of external
HTTP URL
2. XSLT transformation
3. XML serialization
* My soloution:
I was first trying the map:select with the
org.apache.cocoon.selection.ResourceExistsSelector until I found out
that this was only for content within the current servlet context.
I then wrote the attached (trivial) UrlExistsSelector and used this one
for step 1 in pipeline #2.
This works, but might have som implications in security/performance (no
timeout handling) etc. etc. that I just don't see because I'm new to Cocoon.
Any comments? Other soloutions?
TIA,
Martin
--
Martin Kalén
Curalia AB Web: http://www.curalia.se
Orrspelsvägen 2BMail: [EMAIL PROTECTED]
SE-182 79 StocksundTel: +46-8-410 064 40
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.thread.ThreadSafe;
import org.apache.cocoon.selection.Selector;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.util.Map;
/**
* Selects the first of a set of URLs that can be connected to.
*
* Like [EMAIL PROTECTED] org.apache.cocoon.selection.ResourceExistsSelector},
* but works with java.net.URL instead of using the servlet
* containter's context resolving.
*
* @author Martin Kaln
* @version CVS $Id: UrlExistsSelector.java,v 1.1 2003/10/10 09:08:47 martin Exp $
*/
public class UrlExistsSelector extends AbstractLogEnabled
implements ThreadSafe, Selector {
public boolean select(String _expression_,
Map objectModel,
Parameters parameters) {
try {
URL url = "" URL(_expression_);
URLConnection connection = url.openConnection();
connection.connect();
return true;
} catch (MalformedURLException e) {
StringBuffer message = new StringBuffer();
message.append("Selector _expression_ '");
message.append(_expression_);
message.append("' is not a valid URL");
getLogger().warn(message.toString());
return false;
} catch (Exception e) {
return false;
}
}
}
Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
On Thu, 9 Oct 2003, Jeff Turner wrote: JIRA open source licenses do not expire (nor do the commercial ones). (Just to be clear, that's a JIRA license for open source projects not a JIRA open source license ;-) No, but the only way I know I'll be able to use the software in perpetuity is if I have the source code for it on my computer. Companies come and go. If I have the code I can continue working with the software. Don't suppose I can convince you to open the source? Wouldn't you love all the cocoon developers submitting patches and helping you push your product forward? Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 Orixo alliance: http://www.orixo.com/ Web:www.luminas.co.uk
[RT] Changing the mime type setting of a reader
Hi, during our bug hunting session we came across bug 10277 that contains a discussion about the mime type handling of a reader. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10277 The suggestion is to change the behaviour to (or the order to determine the mime type): - MIME type declared on the reader instance - Ask the Reader for a MIME type. A *.doc reader could peek into the file and return either text/plain or application/vnd.msword. - MIME type declared for the reader component - MIME type declared in WEB-INF/web.xml or by the server. Because, *if* I set a mime type for the reader instance I will overide the information with this. For more info you can have a look at bugzilla. Now, we can either agree on the above, come to a different solution or leave it as is. Either way, I want to close this bug :) Carsten
Problem using SVG serialializer after a transformation
Hi,
I run into the following problem when serializing to svg after a xsl
transformation:
Start with a sitemap including something like this
map:match pattern=*.png
map:generate src={1}.svg/
map:transform src=xsl/{1}.xsl type=xslt/
map:serialize type=svg2png/
/map:match
Turn the debug on and check for the SVGSerializer logging.
You see that serialization of the xsl transformation output produces the
massage:
setDocumentLocator was not called, will use http://localhost/ as base URI.
This means that if i have a href in my svg to a css for instance, it won't
be located and the serialization will fail!
I fixed it (somehow) by:
1.introducing a base-url attribute in the SVGSerializer configuration:
map:serializer logger=sitemap.serializer.svg2png
name=svg2png
src=fr.cegetel.dsco.gi.svg.serialization.SVGSerializer
mime-type=image/png
base-url=context://sample/batik/
3.using the sourceresolver to find out the uri to set in the document
locator.
2.making the SVGBuilder no more Recyclable.
Charles
DO NOT REPLY [Bug 23714] - Bug in SessionAttributeGenerator, double startDoc/endDoc SAX events generated
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=23714. 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=23714 Bug in SessionAttributeGenerator, double startDoc/endDoc SAX events generated --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 10:34 --- A bit confused: wasn't it you who posted the exact same problem a couple of days ago on the mailing list? I fixed it and replied to your mail asking to test it, but maybe you missed my reply. In any case, it should be fixed in current CVS, could you give it a try?
Question about the compileScript method in the JavaScriptInterpreter
The compileScript method in the JavaScriptInterpreter looks like this:
public Script compileScript(Context cx,
Environment environment,
String fileName) throws Exception {
Source src = environment.resolveURI(fileName);
I'm wondering why here the environment is needed for resolving the source.
A usual source resolver should do the trick as well, no?
If we would use the source resolver we could release the source
cleanly and we avoid the hacky dependency that the environment
accidentally implements source resolver as well.
What do you think?
Carsten
Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf
On Thu, 2003-10-09 at 23:50, Antonio Gallardo wrote: Stefano Mazzocchi dijo: On Thursday, Oct 9, 2003, at 22:30 Europe/Rome, Antonio Gallardo wrote: antonio 2003/10/09 13:12:35 Modified:src/webapp/WEB-INF cocoon.xconf Log: Fixing bug related to woody form handling posted by Carlos Chávez. Bruno Dumon suggested the fix and it works back again. Revision ChangesPath 1.31 +1 -1 cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf Index: cocoon.xconf === RCS file: /home/cvs//cocoon-2.1/src/webapp/WEB-INF/cocoon.xconf,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- cocoon.xconf6 Oct 2003 16:10:55 - 1.30 +++ cocoon.xconf9 Oct 2003 20:12:35 - 1.31 -parameter name=reuse-parsers value=true/ +parameter name=reuse-parsers value=false/ Next time we need to be more carefully :) i don't get it. if the above breaks woody, this is a hack, not a fix. we need to really fix the bug, not to route around it. any info on where the problem is? This problem does not breaks woody. It breaks Flow, continuations, woody and maybe other areas that I am not using. Maybe someone else can post other related problems. Well it has nothing to do with any of those. What I noticed is that if reuse-parsers is set to true, I got a SAX comment event of a comment that appeared in an XSL stylesheet which turned up in the SAX pipeline. I checked the javadoc of the XMLReader class (which is the thing being reused) and it mentions Once a parse is complete, an application may reuse the same XMLReader object, possibly with a different input source. So the XMLReader can be reused. What's likely the problem (but I can't spend time on this right now) is that the JaxpParser component only sets the lexicalhandler property on the parser if it has one. If the parser is being reused, and no lexicalhandler is being provided, the previous lexicalhandler will remain used. This can probably be solved by setting it explicitely to null. So until someone has time to try this out and update the excalibur-xmlutil package, we're stuck with reuse-parsers set to false. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
HSSFSerializer problem with gnumeric-formats
Hi all, I am using HSSFSerializer to create a native Excel file from Cocoon. Works great ! But some of the elements in my gnumeric-xml-format that I pass to the serializer seem NOT to be recognized. E.g. Attributes SheetLayout Summary ( The original gnumeric spreadsheet program does recognize them ) I am using Cocoon 2.0.4 Is there something like a list or plan of which gnumeric-xml-elements are supported by which version of Cocoon/HSSFSerializer? Any help is much appreciated. Thanks Achim Reiners - The information contained in this message is proprietary of Amdocs, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -
Re: [RT] Using modifiers within Cocoon components
On Friday, Oct 10, 2003, at 10:47 Europe/Rome, Stephan Michels wrote: map:pipeline access=protected - Accessible by all blocks, but not outside of Cocoon this is useless and/or harmful. only dependent blocks can have access to the pipeline. scope is already limited by design. BTW, shouldn't the 'root' block decide which resources are public and which are private?! So that everything is protected, except the 'root' block exposes them. no, this level of level protection is done by the dependencies. -- Stefano.
Re: [RT] Finishing the first phase of block design
On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote: On Thu, 9 Oct 2003, Stefano Mazzocchi wrote: On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote: Stefano Mazzocchi wrote: I have updated the block design documents on the wiki. Changes were: ... A few things are left to decide: 1) the block metadata information in the block.xml file see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob 2) how blocks expose classloading to other blocks - o - Descriptive Block metadata -- The descriptive block metadata that we currently include is: name***/name description href=...***/description license href=.../***/license author href=...***/author +1 Andreas suggested version number which is really handled already in the block id and release date. I think a date though may be a useful additional piece of info. Good point. IMHO, I would try first a solution, which doesn't introduce a new descriptor. like what? In a know german XML magazin, Cocoon was descriped a configuration hell, and as a anti pattern using XML as configuration format. yeah, we agree about the configuration hell, but this is because we expose too much of things that people should never touch. So my proposal would be to start small, and if there isn't a way to come forward with the current possibilities, then we could introduce a new descriptor file beside cocoon.xconf/sitemap.xmap/web.xml etc. you didn't get it: the is the *block* descriptor. each block needs one. I see no way to go without one. Exposing classes Stephen proposed to separate the classes to expose in a different jar and expose that. I like this. It's simple and effective. But instead of declaring classloaders or classpaths in the blocks, I propose to extend the block FS layout so that we have for individual classes and resources: /classes /classes/public /classes/private for jars: /lib /lib/public /lib/private Hmmm. That is quite different than what one would expect from the WAR paradigm, no? Would COB-INF/[classes|lib] COB-INF/public/[classes|lib] or COB-INF/private/[classes|lib] COB-INF/public/[classes|lib] be any better? Could you please explain, why we need to separate the classes and lib into private and public. For the developers POV, it will make the development more complicated, and doesn't see any benefit. to better isolate classloader and the contracts that are exposed by the block. make development more complicated but forces people to think of application contracts that can be later reused as global behaviors. think of it as a generalization of a collection of interfaces and data structures that are passed around. like JAXP+Xerces jaxp is public, xerces should not be, otherwise the public methods of the xerces classes can be hooked up and later broken if a new implementation of JAXP comes around. also reduces the potential problems with hot deployment for classloading dependencies -- Stefano.
[RT] Component manager, classloader and blocks
Hi,
Since some days I thought about how implement blocks with smallest
amount of work. (small ist beautiful)
Most of the work is already finished, if we look into the 'unreal'
block in the CVS repository. We have
a classes, libs, a sitemap, a xconf file and some custom files.
We could easily pack them into a zip file.
What need:
For every block we need
* a block URI, which identifies it.
* statements about dependecies to other blocks.
* Component manager, for a separate cocoon.xconf
* Sitemap proccessor for the root sitemap of the block
* A classloader for each block, which were exchange if the
the block has changed.
The simplest form to include the information about the block
URI and the dependencies is to use the sitemap for it, for example
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:block uri=http://apache.org/cocoon/block/myblock/1.0;
map:import block=basic uri=http://apache.org/cocoon/block/basic/1.0/
/map:block
For the sitemap components we need two component manager for
handling the 'public' and 'private' components.
+---++---+
| myblock || basic |
| +---+ | lookup | +---+ |
| | public cm |-++| public cm | |
| +---+ || +---+ |
| ^|| ^|
| | lookup || | lookup |
| ||| ||
| +---+ || +---+ |
| | private cm| || | private cm| |
| +---+ || +---+ |
| ^|| ^|
| | lookup || | lookup |
| ||| ||
| +--+ || +---+ |
| | sitemap | || | sitemap | |
| +--+ || +---+ |
| || |
+---++---+
Another difficult part is about the dependecies of the CMs between
subsitemaps (I doesn't have a solution). I think subsitemaps
are a contrary solution to blocks, perhaps we should rethink the
subsitemaps.
To prevent component name collisions within, we could use prefixes like
match type=basic:wildcard pattern=*.html
map:generate type=basic:file src={1}.xml/
map:transform type=basic:xsl src=mystyles.xsl/
map:transform type=mytransformer/
map:serialze type=basic:html/
If there is no name collision, you can leave out the prefix.
The problem is that the current CM model doesn't support
such a kind of prefix, but it doesn't need to, because
the sitemap processor can resolve the prefix, and know
which CM to ask for.
For the classes and libs itself, I think separate them into public
and private isn't necessary for the first step.
A cheap solution is use following FS within a zip file:
myblock.zip
/COB_INF/classes
/COB-INF/lib
/COB-INF/componts.xconf
/sitemap.xmap
/[whatever]
Every block get his own classloader, and if the block has changes
the classloader will be exchanged. Each depending block has
a parent classloader, which will be consulted if the current
classloader doesn't know the class.
My unsorted braindump, Stephan.
cat /dev/brain | grep blocks | mail [EMAIL PROTECTED]
___
Stephan Michels EMail: [EMAIL PROTECTED]
ICQ: 115535699Tel: +49-030-314-21583
+|+|+|+|+|+|+|-|
Re: [RT] Finishing the first phase of block design
On Fri, 10 Oct 2003, Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote: Exposing classes Stephen proposed to separate the classes to expose in a different jar and expose that. I like this. It's simple and effective. But instead of declaring classloaders or classpaths in the blocks, I propose to extend the block FS layout so that we have for individual classes and resources: /classes /classes/public /classes/private for jars: /lib /lib/public /lib/private Hmmm. That is quite different than what one would expect from the WAR paradigm, no? Would COB-INF/[classes|lib] COB-INF/public/[classes|lib] or COB-INF/private/[classes|lib] COB-INF/public/[classes|lib] be any better? Could you please explain, why we need to separate the classes and lib into private and public. For the developers POV, it will make the development more complicated, and doesn't see any benefit. to better isolate classloader and the contracts that are exposed by the block. make development more complicated but forces people to think of application contracts that can be later reused as global behaviors. Your intentions are good, but do you really want to force them. And how do you realize this. Do you what to cut the whole source path into two separate branches, or using javadoc statement. think of it as a generalization of a collection of interfaces and data structures that are passed around. like JAXP+Xerces jaxp is public, xerces should not be, otherwise the public methods of the xerces classes can be hooked up and later broken if a new implementation of JAXP comes around. I doesn't think that a separation between private and public classes is quite easy. also reduces the potential problems with hot deployment for classloading dependencies You will have the same problem, if you separates them into public and private. The classes, which are used by initiated objects, can't exchanged. Stephan Michels.
RE: [RT] Finishing the first phase of block design
to better isolate classloader and the contracts that are exposed by the block. make development more complicated but forces people to think of application contracts that can be later reused as global behaviors. think of it as a generalization of a collection of interfaces and data structures that are passed around. like JAXP+Xerces jaxp is public, xerces should not be, otherwise the public methods of the xerces classes can be hooked up and later broken if a new implementation of JAXP comes around. I posted the text below to the XSL list a few weeks ago (can't find it in the archives). Mike Kay responded saying the JAXP working group was reviewing these issues now and would perhaps come up with clearer specificiations. Cocoon, specifically, might be interested in the Xalan/XSLTC part below. the post I want to report my findings with regard to standard implementations of how the method setURIReolver works in the popular Open Source java xsl processors. From what I understand from past discussions is that the spec is not clear on the issue. I was wondering if processor developers could get together and decide either one way to implement the setURIResolver or do it the way Saxon does by doing both (hopefully explained below). According to most API's you can set the URIResolver on the TransformerFactory and on the Transformer. Generally, the resolver set on the TransformerFactory resolves xsl:includes and xsl:imports. If set on the Tranformer it resolves document() function calls. - Saxon allows you to set the resolver on the TransformerFactory to resolve both includes/imports and document(). It also lets you set one for the factory and one for the transformer. When this is done the factory resolves include/import and the transformer resolves document(). This is the best way, IMHO. - jd.xslt only uses the TransformerFactory to be used for xsl:include/xsl:import and document() resolution. Strangely, the standard xalan and it's xsltc implementation do two different things. - standard xalan requires you to use the TransformerFactory for xsl:include and xsl:import and the Transformer for document() - xsltc xalan uses the TransformerFactory for both xsl:include/xsl:import and document() -- not the Transformer for document(), like the standard xalan. Any chance of standardizing on one way? :) /the post Best, -Rob also reduces the potential problems with hot deployment for classloading dependencies -- Stefano.
Antwort: HSSFSerializer problem with gnumeric-formats
Hi Achim, Have a look at http://cocoon.apache.org/2.0/userdocs/serializers/xls-serializer.html That´s fine for 2.0.4 regards Manfred [EMAIL PROTECTED] am 10.10.2003 13:00:10 Bitte antworten an [EMAIL PROTECTED]@inet An: [EMAIL PROTECTED] Kopie: Thema: HSSFSerializer problem with gnumeric-formats Hi all, I am using HSSFSerializer to create a native Excel file from Cocoon. Works great ! But some of the elements in my gnumeric-xml-format that I pass to the serializer seem NOT to be recognized. E.g. Attributes SheetLayout Summary ( The original gnumeric spreadsheet program does recognize them ) I am using Cocoon 2.0.4 Is there something like a list or plan of which gnumeric-xml-elements are supported by which version of Cocoon/HSSFSerializer? Any help is much appreciated. Thanks Achim Reiners - The information contained in this message is proprietary of Amdocs, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -
Re: SourceResolver does not send parameters?
On Wed, 2003-10-08 at 17:07, Nico Verwer wrote: Hello Cocoon developers, snip/ The problem is that the remote server does not get the 'query' parameter. I tested this by substituting a URL on my own server for the remoteserver URL: snip/ actionSource = resolver.resolveURI(source, null, Parameters.toProperties(params)); The parameters you supply here as third argument to the resolveURI method aren't added to the request URI. Instead, the Map you supply should contain a key SourceResolver.URI_PARAMETERS with as value an instance of org.apache.excalibur.source.SourceParameters. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Finishing the first phase of block design
On Friday, Oct 10, 2003, at 13:42 Europe/Rome, Stephan Michels wrote: On Fri, 10 Oct 2003, Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote: Exposing classes Stephen proposed to separate the classes to expose in a different jar and expose that. I like this. It's simple and effective. But instead of declaring classloaders or classpaths in the blocks, I propose to extend the block FS layout so that we have for individual classes and resources: /classes /classes/public /classes/private for jars: /lib /lib/public /lib/private Hmmm. That is quite different than what one would expect from the WAR paradigm, no? Would COB-INF/[classes|lib] COB-INF/public/[classes|lib] or COB-INF/private/[classes|lib] COB-INF/public/[classes|lib] be any better? Could you please explain, why we need to separate the classes and lib into private and public. For the developers POV, it will make the development more complicated, and doesn't see any benefit. to better isolate classloader and the contracts that are exposed by the block. make development more complicated but forces people to think of application contracts that can be later reused as global behaviors. Your intentions are good, but do you really want to force them. yes And how do you realize this. Do you what to cut the whole source path into two separate branches, or using javadoc statement. it's just a matter of packaging the classes after having compiled them. not such a big deal and, after all, a detail that each block developer can take care of itself. if he doensn't like peparation, he can stick everything into the public part and forget about it... but shouldn't later come complianing if he exposes public methods that were not really meant to be public. think of it as a generalization of a collection of interfaces and data structures that are passed around. like JAXP+Xerces jaxp is public, xerces should not be, otherwise the public methods of the xerces classes can be hooked up and later broken if a new implementation of JAXP comes around. I doesn't think that a separation between private and public classes is quite easy. Exactly. It forces to design your contracts. That's a good thing. also reduces the potential problems with hot deployment for classloading dependencies You will have the same problem, if you separates them into public and private. The classes, which are used by initiated objects, can't exchanged. True, but the public zone will be done with mostly interfaces and data models, the functional classes that are likely to change are polymorphically managed by the component manager, you shouldn't be calling new object() anyway, this is just done to expose the classes that are created by the components. remember that we are still forcing the people to use the basic avalon component model of polymorphic delegation. -- Stefano.
DO NOT REPLY [Bug 23648] - HTMLGenerator produces NullPointerException on HML-docs with XML-Declaration
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=23648. 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=23648 HTMLGenerator produces NullPointerException on HML-docs with XML-Declaration [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 12:12 --- The problem is that the HTMLGenerator recognizes the XML declaration as a processing instruction (with target 'null'). I fixed it as you indicated. Please check and close this bug.
Re: Problem using SVG serialializer after a transformation
BORGES Charles wrote:
Hi,
I run into the following problem when serializing to svg after a xsl
transformation:
Start with a sitemap including something like this
map:match pattern=*.png
map:generate src={1}.svg/
map:transform src=xsl/{1}.xsl type=xslt/
map:serialize type=svg2png/
/map:match
Turn the debug on and check for the SVGSerializer logging.
You see that serialization of the xsl transformation output produces the
massage:
setDocumentLocator was not called, will use http://localhost/ as base URI.
This means that if i have a href in my svg to a css for instance, it won't
be located and the serialization will fail!
I fixed it (somehow) by:
1.introducing a base-url attribute in the SVGSerializer configuration:
map:serializer logger=sitemap.serializer.svg2png
name=svg2png
src=fr.cegetel.dsco.gi.svg.serialization.SVGSerializer
mime-type=image/png
base-url=context://sample/batik/
Be careful: the convention in configurations is that attributes are
container-related data. Component-related data should be better located
as child elements. So the following should be better:
map:serializer
base-urlcontext://sample/batik/base-url
/map:serializer
3.using the sourceresolver to find out the uri to set in the document locator.
So do you really need the base-url? Isn't the uri of
SourceResolver.resolveURI() just what you need? Or at least it can be
a fallback if base-url is not present.
2.making the SVGBuilder no more Recyclable.
Why can it no more be Recyclable?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
DO NOT REPLY [Bug 23725] New: - In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension.
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=23725.
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=23725
In offline generation mode, when I start Cocoon with a Uris list file, the argument
confirm extensions (-e) is not used, and the created files are forced with the default
mime type extension.
Summary: In offline generation mode, when I start Cocoon with a
Uris list file, the argument confirm extensions (-e) is
not used, and the created files are forced with the
default mime type extension.
Product: Cocoon 2
Version: 2.1.2
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In offline generation mode, when I start Cocoon with a Uris list file, the
argument confirm extensions (-e) is not used, and the created files are forced
with the default mime type extension.
Cause of the problem : URIs are parsed during analysis of the –f argument, and
this argument is analysed before the confirm extensions argument (-e). The
consequence is that the confirm extensions is not taken into account. This
occur in the main method of the ora.apache.cocoon.Main class.
See the code below :
if (line.hasOption(URI_FILE_OPT)) {
// URIs file is parsed
cocoon.addTargets(processURIFile(line.getOptionValue
(URI_FILE_OPT)), destDir);
}
if (line.hasOption(FOLLOW_LINKS_OPT)) {
cocoon.setFollowLinks(yesno(line.getOptionValue(FOLLOW_LINKS_OPT)));
}
if (line.hasOption(CONFIRM_EXTENSIONS_OPT)) {
// Confirm extensions property is set
cocoon.setConfirmExtensions(yesno(line.getOptionValue
(CONFIRM_EXTENSIONS_OPT, yes)));
}
if (line.hasOption(LOAD_CLASS_OPT)){
cocoon.addLoadedClasses(Arrays.asList(line.getOptionValues
(LOAD_CLASS_OPT)));
}
cocoon.addTargets(line.getArgList(), destDir);
The following changes correct the problem :
if (line.hasOption(FOLLOW_LINKS_OPT)) {
cocoon.setFollowLinks(yesno(line.getOptionValue(FOLLOW_LINKS_OPT)));
}
if (line.hasOption(CONFIRM_EXTENSIONS_OPT)) {
// Confirm extensions property is set
cocoon.setConfirmExtensions(yesno(line.getOptionValue
(CONFIRM_EXTENSIONS_OPT, yes)));
}
if (line.hasOption(LOAD_CLASS_OPT)){
cocoon.addLoadedClasses(Arrays.asList(line.getOptionValues
(LOAD_CLASS_OPT)));
}
if (line.hasOption(URI_FILE_OPT)) {
// URIs file is parsed when all arguments have been analysed
cocoon.addTargets(processURIFile(line.getOptionValue
(URI_FILE_OPT)), destDir);
}
Vincent.
RE: [RT] Separation of Blocks and Avalon
On Fri, 10 Oct 2003, Reinhard Poetz wrote: From: Ryan Hoegg Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? -1 we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we would ship alpha code and I think people building their applications upon 2.1 wouldn't be very happy with this. That's one reason why CVS has branches. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
DO NOT REPLY [Bug 23725] - In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension.
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=23725. 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=23725 In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 14:21 --- Thanks. I've committed your change to CVS. Can you test it and close this bug? Upayavira
DO NOT REPLY [Bug 23615] - xsltc doesn't work with nodeset functions
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=23615. 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=23615 xsltc doesn't work with nodeset functions --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 14:22 --- Maybe Xalan Dev can tell us the reason?
RE: [RT] Separation of Blocks and Avalon
From: [EMAIL PROTECTED] In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? -1 we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we would ship alpha code and I think people building their applications upon 2.1 wouldn't be very happy with this. That's one reason why CVS has branches. a new branch or a new repository? IIRC we decided *not* to create any branches but to create new repositories instead. Reinhard
multiple XML file input
Hi there - has anyone experience with writing a sitemap that takes multiple XML files as input for XSLT? Thanks! Scott Malec
Re: mounting blocks question
Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 04:43 Europe/Rome, Geoff Howard wrote: We decided that wiring.xml would have entries like: mount/mail//mount How would this work for using hostname based mounting? no. this concerns applies to the servlet hosting environment, there is nothing we can do from this side of the Servlet API fence to trigger virtual host configuration. Use case: http://mail.mydomain.com http://www.mydomain.com Two different applications, same cocoon instance. (mail block) mount host=mail.mydomain.com//mount ?? (main site block) mount host=www.mydomain.com//mount ... (authentication block) mount/login/mount (defaults to all hosts) single sign-on, right? yeah, thought about it extensively but no, we can't do it from this side, unless we hook to a particular servlet container and we modify its configuration files directly and not thru the servlet API. and in a two-tier environment (think apache+tomcat), this is not even enough, since the virtual hosts are configured in httpd.conf. Is it possible to achieve the same functionality? yeah, you bet, with a little tuning of httpd.conf, a few aliases and/or mod_rewrite URI rewriting. Huh? I'm doing it now with Cocoon. It's just a host matcher in the root sitemap and each mounts a sub-sitemap. I know that in order to get those vhosts pointing to the cocoon webapp I have to configure some other front end, but I'm talking about supporting them once they arrive. Geoff
DO NOT REPLY [Bug 23615] - xsltc doesn't work with nodeset functions
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=23615. 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=23615 xsltc doesn't work with nodeset functions --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 14:31 --- The sample should work with XSLTC in Xalan 2.5. It is likely that you are using an older xalan version packaged in JDK 1.4. Please read this FAQ (http://xml.apache.org/xalan-j/faq.html#faq-N100CB) for information. If you are not sure which xalan version is being used, you can use EnvironmentCheck (http://xml.apache.org/xalan-j/faq.html#faq-N1005C) to find it out.
Re: multiple XML file input
Scott A Malec wrote: Hi there - has anyone experience with writing a sitemap that takes multiple XML files as input for XSLT? Thanks! Scott Malec This should be asked on the user list. Look into map:aggregate Regards, Upayavira
RE: getxml in XSP throws NPE if @path is invalid
Thanks Carsten, I'll try it out... How can I update my Cocoon installation (2.1.2), with this patch? Which jar do I need to update and how? (Haven't done this before) :| BTW, The build seems to be broken right now... -Tuomo On Thu, 9 Oct 2003, Carsten Ziegeler wrote: Hi, I just checked in a patch that should fix this problem. Could you please test it? Thanks Carsten -Original Message- From: Tuomo L [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:26 PM To: [EMAIL PROTECTED] Subject: getxml in XSP throws NPE if @path is invalid Hi, This gives me a nasty NPE in XSP: String foo = xsp-session-fw:getxml context=authentication path=/authentication/data/bar/; This does not: String foo = xsp-session-fw:getxml context=authentication path=/authentication/ID/; Shouldn't it return null, if the given path is not available? It seems that there's a bug. Could someone please fix this? I didn't find the cause to this by looking at the code. Using Cocoon-2.1.2. Thanks, Tuomo
Antwort: multiple XML file input
Hi Scott! Yes we have! Use the map:aggregate Have a look at http://www.cocooncenter.de/articles/stylefree.html good luck! regards Manfred [EMAIL PROTECTED] am 10.10.2003 16:10:49 Bitte antworten an [EMAIL PROTECTED]@inet An: [EMAIL PROTECTED] Kopie: Thema: multiple XML file input Hi there - has anyone experience with writing a sitemap that takes multiple XML files as input for XSLT? Thanks! Scott Malec
Re: [site docs] build failing
Carsten Ziegeler wrote: Building the docs failed because plan/changes.rss could not be generated (no pipeline found). I just checked in a hack to the doc sitemap, so this pipeline is now found and building the docs, especially the site docs works again. Does anyone know where plan/changes.rss is used and why? Changes.rss is created from changes.xml by Forrest to give an RSS feed from the changes. It's included in the changes.xml page as a link. See this as an example: http://xml.apache.org/forrest/changes.html It's strange, is there no sitemap that does this in your forrest? wierd... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: Question about the compileScript method in the JavaScriptInterpreter
Sylvain Wallez wrote: Actually, the whole flow stuff abuses the use or Environment, when it simply needs the object model. On my todo list is some refactoring to remove all uses of environment in the flow, unless someone else volunteers for it. In the meantime, we can simply replace uses of the Environment by the real SourceResolver where needed. Ok. BTW, regarding the forthcoming refactoring of Environment: is this accidental implementation of SourceResolver really needed? No, not anymore. It was in 2.0.x but starting with 2.1 I think it's only for compatibility. Carsten
RE: [RT] Separation of Blocks and Avalon
Giacomo Pati wrote: We extend the ECM with our CocoonComponentManager, you can have a look at that class. All the features (hacks?) in there have to be somehow available using fortress, merlin or whatever. We have another lifecycle type, the request lifecycle component. This is an extension to poolable and means that per request only one instance of this component is used. So if two other components lookup this request lifecycle component, they get the same instance. The implementation of this extension is a little bit difficult as we have sub requests that run in the same thread but have a different set of request lifecycle components. In addition it's possible to process on request multi threaded which makes this even more difficult. IIRC Fortress can handle this with a special Handler we have to supply (instead of subclassing the hole Container class). Remeber that in Fortress Object handling is separated into meta data instead of additional marker interfaces. There is no Poolable, ThreadSafe, etc. any more but ThreadSafeComponentHandler, PoolableComponentHandler instead. Yes, I know - and I saw the handlers of fortress and it should work. There are some other important extensions like the environment handling for the source resolver and the sitemap configurable components. They use more or less the same technique used for the request lifecycle components. I'm sure there is a way for this also and with the help of a Handler it can be made with IOC in mind. I'm not sure for the source resolver part. The other things should work, yes. Yes, but the world is still spinning and there are alot of other Component out there that don't follow the ECM style because it's deprecaded for long time now and every time we want to use such a component we have to extend the working interface to make it a 'Component' for ECM and extend the implementation to have our interface implemented (do you remember the Cornerstone Scheduler?). That's ugly! Definitly. Ok, that's a point. As a side note: I got the impression (and that supprises me alot) there is too little knowledge around here what Avalon is doing and where it is moving in the so central Component Container discipline. This IMHO led to this 'we think Avalon cannot supply what we want' situation and so we are ignoring the helping hand Avalon people put forth several times now. At least for me it's not the 'we think Avalon cannot supply what we want' that I fear of. It's more a can the Avalon community support the version for us and for how long. Carsten
RE: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we would ship alpha code and I think people building their applications upon 2.1 wouldn't be very happy with this. That's one reason why CVS has branches. a new branch or a new repository? IIRC we decided *not* to create any branches but to create new repositories instead. PLEASE, don't start this discussion over and over again. We have (after a long painful discussion period) decided (or better reassured) that we create a new repository for 2.2. And Stefano wanted to contact infrastructure to create the 2.2 one. Carsten
RE: getxml in XSP throws NPE if @path is invalid
Hi, you have to update the session jar. Carsten -Original Message- From: Tuomo L [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 4:46 PM To: [EMAIL PROTECTED] Subject: RE: getxml in XSP throws NPE if @path is invalid Thanks Carsten, I'll try it out... How can I update my Cocoon installation (2.1.2), with this patch? Which jar do I need to update and how? (Haven't done this before) :| BTW, The build seems to be broken right now... -Tuomo On Thu, 9 Oct 2003, Carsten Ziegeler wrote: Hi, I just checked in a patch that should fix this problem. Could you please test it? Thanks Carsten -Original Message- From: Tuomo L [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 10:26 PM To: [EMAIL PROTECTED] Subject: getxml in XSP throws NPE if @path is invalid Hi, This gives me a nasty NPE in XSP: String foo = xsp-session-fw:getxml context=authentication path=/authentication/data/bar/; This does not: String foo = xsp-session-fw:getxml context=authentication path=/authentication/ID/; Shouldn't it return null, if the given path is not available? It seems that there's a bug. Could someone please fix this? I didn't find the cause to this by looking at the code. Using Cocoon-2.1.2. Thanks, Tuomo
DO NOT REPLY [Bug 23725] - In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension.
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=23725. 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=23725 In offline generation mode, when I start Cocoon with a Uris list file, the argument confirm extensions (-e) is not used, and the created files are forced with the default mime type extension. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: [RT] Separation of Blocks and Avalon
Giacomo Pati wrote: On Fri, 10 Oct 2003, Geoff Howard wrote: How about this proposal: If Berin feels the migration can be quick (1 week?) we start a 2.2 repo, I would give him even 2 weeks ;-) :) Clarification: - We give _it_ x amount of time not him. I think we ought to be as involved as possible. - 1 week was really tossed out as a question to the one(s) who are in a position to guess what it will take and to start to define what quick would mean. 6 months of hard work is not quick. 1 day is quick. In-between is a judgement call we'll have to make and that's where I'd expect it to be. Geoff
Re: [RT] Finishing the first phase of block design
Stefano Mazzocchi wrote:
On Friday, Oct 10, 2003, at 04:01 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
...
Exposing classes
Stephen proposed to separate the classes to expose in a different
jar and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks,
I propose to extend the block FS layout so that we have
for individual classes and resources:
/classes
/classes/public
/classes/private
for jars:
/lib
/lib/public
/lib/private
Hmmm. That is quite different than what one would expect from the
WAR paradigm, no? Would
COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or
COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?
This might suggest the concept that private is the location of all
the things that are private so
private/lib
means I have libraries in the private section, so maybe I can put
something else as well to have it protected? while
lib/private
means these are the private libraries... but doesn't say anything
about non-lib things. I still like this approach better, even if it
moves away from the WAR paradigm (which is not a big deal, IMO,
since blocks are different enough already)
Ok, that's a good point. I have a parallel concern that something like
COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
or
package public.com.myconfused.package
public Class StillNotFound {...
will pop up regularly on the users list.
hmmm, don't think so, don't see many users actually adding their own
single classes to those blocks and then deploy. I think they will put
their prepackaged jars in there. but hey, you might be right.
One more idea to try to avert potential confusion.
COB-INF/private-lib/
COB-INF/private-classes/
COB-INF/public-lib/
COB-INF/public-classes/
?
I'm -0 on this, don't see the need, but I see your point.
Ok, if no one else sees the need I'm fine to move forward as is. As a
final wild idea, the Avalon meta-info project might help here.
...
3) Explicit resource uri's
Should exposed resource (pipeline) uri's be declared explicitly?
This is where I still have some reservations as begun above in the
not-found/fallback example.
map:match pattern=stylesheets/*.xslt
map:read src=styles/{1}.xslt/
/map:match
Is convenient to write, but may be inconvenient to use for block
users, extenders, implementers, and the BlockManager (code). Perhaps
the first can be taken care of with human readable documentation
(though I fear what the cocoon blocks will have in this respect).
Perhaps the second is unfounded. I'm not convinced of either of
those and think it merits further thinking.
A possible solution:
Rather than disallowing wildcards, perhaps a part of block.xml could be
resources
uri/stylesheets/news2html.xslt/uri
...
/resources
Maybe that'd be a pain but it'd leave no guessing. Maybe:
...
extends block=http://yetanothercompany.com/skins/fancy/1.2.2;
uri/stylesheets/news2html.xslt/uri
/extends
...
Would be better? It would get rid of the fallback problem.
I don't think we have a fallback problem if we stick to the concept
that matching simply follows the sitemap rules and nothing else. If it
works today and nobody complains I don't see why it should work there
as well.
Ok, I see that. This will be another thing that should be clear in the
idiots guide to authoring blocks (blocks for blockheads?). Be
careful to match only what you intend to override by extension.
Geoff
Re: Testing serviceable components
Ugo Cei wrote: The problem is that Woody components (like for instance AbstractDatatypeWidgetDefinition) are Serviceable, but ExcaliburTestCase provides only a (deprecated) ComponentManager instead of a ServiceManager. I don't know if this will help you, but I've been experimenting with using the CocoonBean in my test cases. You could create a subclass of the CocoonBean class that will expose the getComponentManager() method to your test case. You could then use that method to create and test the component. cheers, -steve
DO NOT REPLY [Bug 23694] - [PATCH] TraversableSourceDescriptionGenerator
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=23694. 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=23694 [PATCH] TraversableSourceDescriptionGenerator [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
Re: Track feature requests in bugzilla?
Stefano Mazzocchi wrote: nono, you missed my point: bugzilla forces discussion to happen over the issue comments. wiki, since it's hard to do communication overthere (as you suggest), forces you to write comments on email, like it should be. And what's so bad about communication on bugzilla? Every mail is sent to the lists. The issues can also be discussed on the list by simply replying to an email. The only missing point is the real sender of a mail for bugzilla comments, isn't it? yes, and the ability to sort messages in threads since every bugzilla email is detached. Ah, ok. Mozilla does this for me by comparing the subject - but if the bug is reported, so the mail has an additional new in the subject, or if the bug summary changes, Mozilla fails of course. Joerg
DO NOT REPLY [Bug 23694] - [PATCH] TraversableSourceDescriptionGenerator
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=23694. 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=23694 [PATCH] TraversableSourceDescriptionGenerator [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-10 17:57 --- Patch applied, thanks! Please test.
Re: Renaming Woody to Cocoon Forms ?
Bertrand Delacretaz wrote: I think there was agreement on Monday about this, do we need a vote, or am I mistaken about the agreement? Naming it Cocoon Forms is a nice parallel to Cocoon Flow, and shows that we're betting the farm on it, which I like. My late +1 for Cocoon Forms We can probably keep Woody as the block name though, in homage to the great sandwiches delivered to the great original authors of Cocoon Forms ;-) -Bertrand Regards, tony
Re: Track feature requests in bugzilla?
Torsten Curdt wrote: snip; any project that has already been going down that road? maybe we could borrow scripts etc... what are the php guys using anyway? IIRC I liked that interface more than bugzilla The PHP bug report page is located at http://bugs.php.net/. It looks like they are using something they wrote themselves. Torsten Regards, Tony
Re: FYI: DocSynch as a collaborative editing tool?
On Friday, Oct 10, 2003, at 18:15 Europe/Rome, Arje Cahn wrote: Argh.. That's not the same as SubEthaEdit! It allows only one person to edit the document at a time! ...which makes it a little useless, me thinks. -- Stefano.
Re: Testing serviceable components
Steve K wrote:
I don't know if this will help you, but I've been experimenting with
using the CocoonBean in my test cases. You could create a subclass of
the CocoonBean class that will expose the getComponentManager() method
to your test case. You could then use that method to create and test
the component.
Thank you, but I already have a ComponentManager provided by
ExcaliburTestCase, however what I need is a ServiceManager.
Anyway, after some thinking I came to the conclusion that the class I
want to test (o.a.c.woody.datatype.DynamicSelectionList) does not need
either a ComponentManager or a ServiceManager. Its generateSaxFragment
method should be passed a Source and should not get one from a
SourceResolver that in turn it gets from a ServiceManager:
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale, Source source) throws ProcessingException, SAXException,
IOException {
SelectionListHandler handler = new SelectionListHandler(locale);
handler.setContentHandler(contentHandler);
SourceUtil.toSAX(source, handler);
}
Why? Well, because, according to the Law of Demeter ([1]), any method of
an object should call only methods belonging to:
- itself
- any parameters that were passed in to the method
- any objects it created
- any directly held component objects.
The current implementation of generateSaxFragment violates this law by
calling a method on an object (Source) returned by a method called on an
object (SourceResolver) returned by a method called on a directly held
object (ServiceManager): two levels of indirection more than necessary.
This creates a tight and unnecessary coupling between
DynamicSelectionList, SourceResolver and ServiceManager.
By refactoring the way I plan to, we get the added benefit that we can
get a Source from wherever we like, be it a ComponentManager or a
ServiceManager or maybe some mock implementation, easing testability.
What do you people think?
Ugo
[1]: http://www.ccs.neu.edu/home/lieber/LoD.html
Re: [RT] Updating the website
Carsten Ziegeler wrote: Due to my nice(?) rearranging of the docs we are not able to update our website without breaking some external links. And this is (to say it friendly) very bad. But we have updated/new docs that should be published asap. So how can we manage this? Stefano had an impressing (wild) idea at the GT which sounds very cool, but will unlikely not happen today or tomorrow. I personally wanted to update the site asap, at least with the next release for 2.1.3 - our great bug fix release. Hmm, what was Stefano suggesting? I'd be interested to know what he's got turning in those gears in his brain :) I wanted to start this RT to discuss some possibilities, so here are some: a) I revert the structural changes (cause in the end it's my fault) +1 for reverting for now. b) We update and don't care about external links c) We update and care a little bit about external links and redirect a 404 to let's say the start page Thoughts? I think we need to make a giant list of all of our docs/pages, what they do, and their current place in the docs structure. There's a lot of stuff out of place, one thing I always notice is the page talking about DELI being switched off. For some odd reason, it just seems like this page does not belong there. We might need to get away from the developer vs user notion, because depending on how much about Cocoon you already know, you might have to hack out a new generator (which would seem to imply information in the developer section) while you are really a user. IMHO, the line between developer and user is blurred, and I think the docs need to reflect this somehow. Touching back to the idea of getting a giant list of all the docs, something I might try is to get a bunch of notecards, and write down each doc on them. If there's a line of documents, connect them all together, and shuffle them as a unit. Post-It notes might also work well. This way it's easy to move things around logically without disturbing the file system structure until we have everything sorted out. From the sounds of it, we're almost at a critical point with the docs. We NEED to make it easy to find things. I've always been of the opinion that the best site docs in the open-source world exist on www.php.net. They combine the official docs -- organized very well and logically -- with user-submitted comments, which is sometimes worth more than the real docs. This is something we need to explore for future versions of the site docs, I think, but it may not happen until we have Cocoon serving its own docs. Carsten Regards, Tony
Re: XSP logicsheet with a recursive call template stops server
Hello Georg,
you seem to mix XSP and XSL. They are different techniques: With XSP Sax
events are *generate*d, XSL is used for *transform*ation. To get the
reason of your problem you should show us your sitemap, remove the XSL
stuff into an XSL and don't mix the document (generated by XSP) and the
XSL stylesheet.
Joerg
PS: In general such questions should be asked on Cocoon users list, you
won't have to wait so long for an answer there, while Cocoon developers
incline to ignore such mails.
[EMAIL PROTECTED] wrote:
Hi,
I use Cocoon 2.0.4.
I want to build a tree structure with nested tree elements, but I don't
know how much elements I get from a stack, I've destinated before.
If a recursive call of the called template is made in the logicsheet (
xsl:template name=nextBelow
xsp:element name=SELECT
xsp:attribute name=name
xsp:expreftix.myChildName()/xsp:expr
/xsp:attribute
xsp:attribute name=file
xsp:expreftix.myChildFileAttr()/xsp:expr
/xsp:attribute
xsp:attribute name=navfile
xsp:expreftix.myChildNavFileAttr()/xsp:expr
/xsp:attribute
xsp:attribute name=category
xsp:expreftix.amILast()/xsp:expr
/xsp:attribute
xsl:variable name=test
xsp:logic
xsp:expreftix.amILast()/xsp:expr
/xsp:logic
/xsl:variable
Geo
xsl:value-of select=$test /
/Geo
if(eftix.getNextFromStack())
{
xsl:call-template name=nextBelow /
}
!-- --
/xsp:element
/xsl:template
),
the transformation of the xsp-file to a java-file fails and the server is
stopped.
It seems there is produced an endless loop by this transformation.
It is necessary for me that the elements are nested.
Is there any other possibility to produce a nested tree with unlimited
elements with XSP and logicsheets?
I hope anybody can help me!
wbr
Georg
Re: [GT2003] Thank you
At the end and after passing the Sun Java Programmer Certification I will also join the thanking people. It was my first event related to software development and it was so impressive. The town, the meals, the Outerthought support (thanks, Steven, for the link and Bruno for the plan of Gent - by the way: what's the difference between Gent and Ghent?), the lectures, the discussions and talks and especially the people/community. So many similar experiences other people also had when using and escpecially when not using Cocoon! I appreciated this event very much and am looking forward for the next one. I can only recommend everybody to attend the next GetTogether. Joerg
RE: [RT] Separation of Blocks and Avalon
From: Carsten Ziegeler Reinhard Poetz wrote: we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we would ship alpha code and I think people building their applications upon 2.1 wouldn't be very happy with this. That's one reason why CVS has branches. a new branch or a new repository? IIRC we decided *not* to create any branches but to create new repositories instead. PLEASE, don't start this discussion over and over again. We have (after a long painful discussion period) decided (or better reassured) that we create a new repository for 2.2. And Stefano wanted to contact infrastructure to create the 2.2 one. I hope my comment wasn't misleading. I support fully the community decision to create new repositories instead of branches and I'm not interested in leading this discussion again and again. Reinhard
Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf
On Friday, Oct 10, 2003, at 12:51 Europe/Rome, Bruno Dumon wrote: So until someone has time to try this out and update the excalibur-xmlutil package, we're stuck with reuse-parsers set to false. Sylvain? ;-) -- Stefano, with gentle voice and french accent
Re: [RT] what cocoon forms lack
On Friday, Oct 10, 2003, at 10:26 Europe/Rome, Sylvain Wallez wrote: Stefano Mazzocchi wrote: Thanks to the great energy that Sylvain is able to put into things, we now have a community consensus on making woody the official cocoon form framework. On the trip back from the GT, I spent some time talking to David Nuescheler. A while ago, I suggested him to take a look at linotype and he liked the concept and told his guys to use it. On the train, he told me: you know, the idea of making linotype a woody widget is not so far off as it seems, we did our own form framework and editing framework and came up with nothing that could distinguish the two, so we are making an effort to merge the two. This triggered an incredible amount of thinking... during the hours that took me to get back and thanks to sylvain's handouts, I was able to have a solid reference for my thinking. - o - There are two widgets that cforms are missing: - editor - uploader Hey, you know what, some of the people that went to me after my talk proposed just the same ;-) great I see two potential types of editor: - plain text - stuctured text Rich text is one of the potential structured text. I dislike textarea as a style if an string input field. it doesn't feel right: a textarea is the style of an editor. Mmmh... What I understand above is that you distinguish two types of string inputs: - single line inputs that go through a regular input - multi-line strings or structured documents that go through an editor widget of which textarea is a particular representation (styling, in the current terminology). Am I right? yes This also calls for an additional built-in field datatype: xml, that would automatically parse the input string upon submit. We can also have specialized validators for this datatype that check that the document is valid according to some kind of schema. I'm thinking that naming a widget based on what it creates is a bad pattern. I think we should name the widget on what it does. editor in structure text mode, will generate XML i see no reason for a structure text mode to return something else. I also see two potential types of uploaders: - active - passive Passive uploaders are the usual ones, the ones with a input field and a browse button. (normally native widgets that are not CSS modifiable) Active uploaders are the one that react on the content being uploaded and show it (like the image uplaoder in linotype). Active upload is really cool. yep An associated need for upload, along with drag'n dropping images in an editor, is for generic binary attachements to a document (in the general meaning of document). Graphically, this could be a drop zone associated to the (growing) list of file names. uploader mode=list/? The idea is the following: both widgets make available to the controller (after having been processed), an object model that contains the content. The template generators should be able to process the object model of a structured text and crawl it transparently to generate SAX events. This calls again for the xml datatype, with an associated set of converters (xml/wiki/slop parsers). no, again, I think that both you and Bertrand tend to look at this from a server side perspective. - o - Note, however that these widgets don't resolve the need for a semi-structured editing capabilities of the page (a-la contentEditable), but they go a pretty long way to provide capabilities. Another interesting feature would be providing different modes for the editor, just like different tab panes that react on the content. In linotype you have Wysiwig and markup, introducing a wiki mode is in my todo list. I would love to have linotype as a cform widget with pluggable editing modes that share content: so that you can write your wiki text, then click on the wysiwig tag and edit content like that, back and forward, you can cut/paste stuff in and out. Implementation-wise, having multiple simultaneous formats client-side may be require tricky javascript development. don't think so. it's basically parsing a string, you'd not be using any browser needs, just pure javascript regular expressions. Since we must have the parsers for these formats server-side why? we can use the submit-on-change feature so that clicking on a format tab does a round-trip to the server to convert the format. that would be orders of magnitude slower and much more subjective to failure! I would love to reduce roundtrips (even for groups BTW, I think they should be handled client side) now, what do you think? I think: kewl ;-) all right, so, how do we move on? -- Stefano.
[OT] Digital Video Amarcord
I started processing the GT video tapes. Each talk is about 50/60 minutes long, DV compression is about 10Gb/hour. Means that I have to process 60Gb of stuff. I have everything on tape, luckily enough, because I have only 20Gb of disk left (only 20gb of disk, can you believe that I thought that? god) I'm encoding using iMovie, pretty cool, very simple to use and very efficient. Final Cut Pro or AVID Digital Studio are another planet, but hey, cutting and post-production here is *really* simple ;-) I'm encoding with DivX 5.1 beta, shaky and slow as hell, but it seems to be portable across all systems. It needs 8 hours per hour on my G4 1Ghz (at max processing quality). This means that it would take me 1.5 CPU days to encode the GT, plus another few days to upload it. hope my CPU doesn't melt down. I encoded at video at single pass, constant rate, 320x240, 100kbps and audio at mp3 16bit 22Khz 64kbps mono. Video artifacts are terrible when there is some motion (divx is really poor at small bitrate) but audio is pretty good. Interesting enough, encoding video at 200Kbp didn't change the picture much (artifacts were reduced, but still not good enough to see anything, so I left them like that). Expected size per presentation is around 50Mb/60Mb, which isn't bad at all. In case you have suggestions, yell now because each mistake is 8 hours of processing :-( I'll make the first talk available tomorrow, after merlino (my laptop) finishes crunching it to night. and then I'll wait for comment before moving on. time to go to bed now. -- Stefano.
windows vs. file protocol paths
map:match pattern=jh/** map:mount check-reload=yes src=file:///D:/xml/sitemap.xmap uri-prefix=jh/ /map:match finds the sitemap and searches for referenced stylesheets in this sitemap relative to *D:/xml* and so *finds* the stylesheets. map:match pattern=jh/** map:mount check-reload=yes src=D:\xml\sitemap.xmap uri-prefix=jh/ /map:match finds the sitemap and searches for referenced stylesheets in this sitemap relative to *webapp's context* and *does not find* them. I don't know if this is a new feature, but at least the behaviour should be consistent: either Windows paths are allowed (and do work) or not. I guess somebody knows where to fix it? Joerg
Re: windows vs. file protocol paths
Joerg Heinicke wrote: map:match pattern=jh/** map:mount check-reload=yes src=file:///D:/xml/sitemap.xmap uri-prefix=jh/ /map:match finds the sitemap and searches for referenced stylesheets in this sitemap relative to *D:/xml* and so *finds* the stylesheets. map:match pattern=jh/** map:mount check-reload=yes src=D:\xml\sitemap.xmap uri-prefix=jh/ /map:match finds the sitemap and searches for referenced stylesheets in this sitemap relative to *webapp's context* and *does not find* them. I don't know if this is a new feature, but at least the behaviour should be consistent: either Windows paths are allowed (and do work) or not. I guess somebody knows where to fix it? Joerg Nothing new, it has always been like that - you must use file:// URLs See explanation here: http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#File%3A+URLs --David
Re: [RT] Updating the website
Bertrand Delacretaz wrote: Carsten Ziegeler a écrit : ... c) We update and care a little bit about external links and redirect a 404 to let's say the start page +0.5 (meaning ok but cannot help ATM) but maybe to an explanations page (we're remodeling) instead of the start page -Bertrand No matter which option that we choose, i think that this redirect to explanation page is a good thing. --David
Re: [OT] Digital Video Amarcord
Great job Stefano! I hope soon we will be able to download it from the Apache website! ;) Best Regards, Antonio Gallardo
Re: [OT] Digital Video Amarcord
Stefano Mazzocchi wrote: I started processing the GT video tapes. Each talk is about 50/60 minutes long, DV compression is about 10Gb/hour. Means that I have to process 60Gb of stuff. ... It needs 8 hours per hour on my G4 1Ghz (at max processing quality). This means that it would take me 1.5 CPU days to encode the GT, plus another few days to upload it. hope my CPU doesn't melt down. Do you have a dvd burner? Maybe it'd be better use of bandwidth to just burn it and mail it to the servers (they're here in the states, right?). Geoff
Re: [gt2003] thank YOU !
On Thu, 9 Oct 2003, Steven Noels wrote: rehearsing Bach with soaked pants I should point out that's because of the torrential rain that morning on the way to the event location, and not because David was nervous ;-) Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 Orixo alliance: http://www.orixo.com/ Web:www.luminas.co.uk
