Re: Dynamic table generation
On 05/01/10 08:12, anandhthiyagarajan wrote: Is there anyway in xsl:fo to create dynamic columns in a table. Yes, but it has nothing to do specifically with XSL:FO, it is just XSLT/XPath. Any help would be appreciated. You'd better search the XSL-list archives at mulberrytech (http://www.mulberrytech.com/xsl/xsl-list/), there should be some XSLT fragments you may find useful. Regards, Luca Morandini www.lucamorandini.it
Re: Exporting graphs to PDF
On 31/12/09 13:55, Sylvain Wallez wrote: Be careful: Fins uses JFreeChart, which is LGPL and a such cannot be added to the Apache source tree (http://www.jfree.org/jfreechart/). Well, I know it's an old quarrel of ours, but... since Cocoon is mavenized, JFreeChart doesn't have to be integrated in the source: the actual download is left to the end user, which could be warned beforehand. Happy new year to you as well, Sylvain ! Luca Morandini www.lucamorandini.it
Re: Exporting graphs to PDF
On 30/12/09 16:38, anandhthiyagarajan wrote: The source file is only xml which may contain some input values. If you want something to generate charts out of XML in various format (PNG, SVG, JPEG, GIF) for later inclusion in POF, you may take a look at Fins (http://www.lucamorandini.it/fins/index.html). Regards, Luca Morandini www.lucamorandini.it
Re: Spring Configurator Docs
David Legg wrote: I have to agree that the current documentation system is a bit of a nightmare. As I see it there are too many hurdles that have to be passed through before documents become visible to the general public. I had a go at updating a few pages using the Daisy system. Editing an existing document is easy enough but I never had the time to learn how to drive the navigation sytem... and I suspect nobody else did either ;-) This is why moving between docs is so difficult. Well, Daisy has a rather flexible way of grouping documents by using collections (one document may belong to more than one collection); I understand this is different from the strictly hierarchical way of, say, Confluence... but it is easier to maintain too. Also it might have seemed like a brilliant idea to extract documentation directly out of the code but that actually adds a further barrier to getting it done as you are then faced with updating the code when all you wanted to do was write about it. One has to choose the lesser of two evils: steeper learning curve vs probable de-synchronization of docs from the actual code... I'd say the former is the less harmful. The final hurdle is that even after you have edited the page and made it active it still isn't visible on the main Cocoon site until some arcane command line incantations are performed. I think having a staging docbase is not bad at all, it lets you revise stuff before being published, not to mention the better performance of the published site. Bring back the wiki I say! I beg to differ ;) Regards, Luca Morandini www.lucamorandini.it
Re: Documentation System [was: Spring Configurator Docs]
David Legg wrote: I still cringe about the number of empty pages. I must continue to put more content in... I believe it is killing the project at the moment. Me too... actually, I suggested to delay the release of 2.2 in order to move all the applicable 2.1 docs into the 2.2 sub-site, but that suggestion was turned down. I did some documentation port myself, but I have to admit it is not that easy, since something *may* indeed have changed in the passage... bottom line: you have to know a component's behaviour in both 2.1 and 2.2 before safely porting its doc. Ok... you win! That's refreshing... I'm used to lose most (all ?) arguments ;) Regards, Luca Morandini www.lucamorandini.it
Re: Documentation System [was: Spring Configurator Docs]
Benjamin Boksa wrote: As there is no official cocoon blog as far as I know I think such a blog would be a good way (in addition to the existing documentation) to Once upon a time there was planetcocoon.com... with blog and all sorts of cocoon-related stuff, but it is now gone. Regards, Luca Morandini www.lucamorandini.it
Re: Documentation System [was: Spring Configurator Docs]
hepabolu wrote: Luca Morandini said the following on 12/2/09 20:27: Once upon a time there was planetcocoon.com... with blog and all sorts of cocoon-related stuff, but it is now gone. But there was no new content in that. It was merely an aggregation of various sources. Nice to see everything in one place but not much in a way of documentation. Hmm... I recall a feature like Cocoon highlight of the week or some sort of blog: am I wrong ? Regards, Luca Morandini www.lucamorandini.it
Re: Cluster Cocoon 2.1.9 Applications
Merico Raffaele wrote: In order to get a perfect failover situation we would like to setup a cluster. Tomcat is not a must and could be replaced with Jboss, since Jboss seems to support clustering. But we don’t have the experience if Cocoon 2.1.9 applications can be run with Jboss!? Yes, we (Sourcesense) have run Cocoon 2.1.x in a Jboss cluster environment since early 2007 . Regards, Luca Morandini www.lucamorandini.it
Re: Find a new name for Corona
Bertrand Delacretaz wrote: If that's the plan (and I like it), why not keep the project Corona name for now? That would be just a project name, not a product name, so we don't need to care about conflicts, the full name would be Apache Cocoon - project Corona. In my, very humble, opinion, this makes a lot of sense. Moreover, I like the Corona name: it was the codename for the first family of spy satellites (actually, it was spelled project CORONA, in uppercase)... quite an endeavor at the time [1]. Regards, [1] http://en.wikipedia.org/wiki/Corona_(satellite) Luca Morandini www.lucamorandini.it
Re: [vote] Luca Morandini as new Cocoon committer
Vadim Gritsenko wrote: On Jul 29, 2008, at 1:33 PM, Luca Morandini wrote: Besides, I've heard Apache committers have special discounts on the entire Mercedes-Benz range of models... what ? That was just a joke ? Oh my... :( You do get a discount on ApacheCon... It's not *exactly* the same thing :| See you in New Orleans? Hmm... enticing, but I'm inclined to answer in the negative: in November I will be utterly busy renovating my new home... moreover, Washington-New Orleans it's 4cm, while Rome-New Orleans it's an eye-popping 18cm... measured on my kids's globe, that is ;) Regards, Luca Morandini www.lucamorandini.it
Re: [vote] Luca Morandini as new Cocoon committer
Vadim Gritsenko wrote: On Jul 29, 2008, at 1:29 AM, David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. +1. I wonder how he managed to avoid becoming a committer for so long! ;-) Actually, I refused once... but this time David was more clever and didn't ask me first. Anyway, tough it looks suspiciously like a press gang [1] of Royal Navy notoriety, I accept the great honor that has been bestowed on me ;) Besides, I've heard Apache committers have special discounts on the entire Mercedes-Benz range of models... what ? That was just a joke ? Oh my... :( Regards, [1] http://en.wikipedia.org/wiki/Impressment Luca Morandini www.lucamorandini.it
Cocoon zones down !
Initialization Problem Message: null Description: No details available. Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet cause Could not find component (key [daisy-repository-manager]) request-uri /daisy/cdocs/491 Luca Morandini www.lucamorandini.it
asMap and asList in Form.js ?
Folks, while writing down a, very draft, page on the Javascript API for Cocoon it came to my mind the idea of adding the asMap ans asList functions (contained in the Forms SQL sample) in said API, since I think they would be rather useful, hence: what about adding them to Form.js ? Regards, P.S. What about adding the import of WidgetState class in Form.js as well ? Luca Morandini www.lucamorandini.it
[jira] Created: (COCOON-2193) XPathTraversableGenerator with / as XPath expression causes subsequent XSLT transformation stages to fail
XPathTraversableGenerator with / as XPath expression causes subsequent XSLT transformation stages to fail --- Key: COCOON-2193 URL: https://issues.apache.org/jira/browse/COCOON-2193 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Reporter: Luca Morandini Priority: Minor After a XPathTraversableGenerator stage with / as xpath expression, no XSLT trasnformation is possible (a runtime error is raised). In other words, this works: map:match pattern=menu.jx map:generate type=xpathtraversable src=blockcontext:/ map:parameter name=depth value=4/ map:parameter name=include value=^gs|resource$|pages$|menu.xml$/ map:parameter name=exclude value=gsmain/ map:parameter name=xpath value=/page/*/ /map:generate map:transform src=xslt/menu.xsl/ map:serialize type=xml/ /map:match /map:pipeline This doesn't (look at the xpath expression of the generator): map:match pattern=menu.jx map:generate type=xpathtraversable src=blockcontext:/ map:parameter name=depth value=4/ map:parameter name=include value=^gs|resource$|pages$|menu.xml$/ map:parameter name=exclude value=gsmain/ map:parameter name=xpath value=// /map:generate map:transform src=xslt/menu.xsl/ map:serialize type=xml/ /map:match /map:pipeline NOTE: This issue was raised as well in 2006: http://mail-archives.apache.org/mod_mbox/forrest-dev/200601.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: It would be great to have better docs, but honestly who is going to write them? Some (most ?) of it has been already written, it's just a matter of copying it from Javadoc (or 2.1 docs pages) to the 2.2 ones, and check its currentness, of course. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? As I see it, this release has the potential of attracting new users to a leaner, meaner Cocoon, but then we should be able to greet them appropriately. As for old users: I can talk only for myself, but I think 2.2 is great for new projects only, since it doesn't pay to Springify and Mavenize old ones. So, we got two distinct classes of users: 1) Old ones, which will use 2.2 as new projects come in, hence allowing for a rather long transition period. 2) New ones, which will be very sensible to good docs and samples and will try 2.2 right after its release. The current state of docs is good enough for the old users, not for the new ones, I think. Hence, 2.2 faces the fate of being caught between old users adopting it very slowly and new users not adopting it in great numbers... not an exciting prospect. Regards, Luca Morandini www.lucamorandini.it
Re: [vote] Release Cocoon 2.2-final
Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? Just my 2€c. Regards, Luca Morandini www.lucamorandini.it
Re: [vote] Release Cocoon 2.2-final
Reinhard Poetz wrote: Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? What's your plan? Well, let's wargame the thing: 1) The community releases 2.2. 2) Hopefully, a lot of people would download it and try the tutorials, (which are good) and people would find it easy to get into Cocoon. 3) A few people would venture deeper, looking at the components' doc and trying things not covered by the tutorials (like I did). 4) They would find that many components have no doc available (though most are unchanged from 2.1) and some doc is outdated (for instance, I had to fix the CForms sample, otherwise it would not have worked in 2.2). 5) Some of them would find the answers they need in the Javadoc, or send messages to the list, or look into the source code. 6) Some of them, regretfully, would simply find Cocoon too hard to learn and drop it. Now, I'd try to avoid people doing 6 by combing the doc and setting it on a par with the 2.1 doc. Actually, since it took so long in the making, I suspect people expect a polished product, in both code and doc. On a more general note, it would be nice to send this message: Cocoon 2.2 is a major rewrite: now the old dog is highly modular, Spring-ified, Mavenized, but still more flexible than Struts 2 or Webflow and far more powerful and clean than Wicket or JSF... but we need better doc for this, I presume. Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Joerg Heinicke wrote: On 13.03.2008 16:20, Luca Morandini wrote: Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I don't think Forms used to work without Javascript. I beg to differ: disable your javascript, go to http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no Javascript there (at least for the widget types we used). Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. I don't quite agree with it, Javascript does not necessarily prevent accessibility. I'm not too familiar with all the accessibility requirements but for example the tabs we have in Forms should be fine, aren't they? Javascript is fine as long as the page gives the same functionality with Javascript disabled Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.. This for WCAG 1.0, which is the one our current legislation is based on, as for WCAG 2.0, WAI-ARIA and the like, well, I bet the Italian law will adopt it circa 2022 :( For the rest, I agree wholeheartedly with your comments. Regards, [1] http://www.w3.org/TR/WCAG10/ Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Joerg Heinicke wrote: On 18.03.2008 03:46, Luca Morandini wrote: I beg to differ: disable your javascript, go to http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no Javascript there (at least for the widget types we used). With JavaScript *enabled* I'm stuck at the front page saying Tutela del mare - Loading... and Ottimizzato per Mozilla Firefox 2.0 e Microsoft Internet Explorer 7. Additionally it shows a dolphin and a spinning circle. ;-) Duh ! Well, it works on my computer ;) Seriously: does it lament any Javascript error ? Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Joerg Heinicke wrote: On 18.03.2008 08:15, Luca Morandini wrote: Seriously: does it lament any Javascript error ? I'm using latest Mozilla SeaMonkey. It does not show any error in the Error Console. I have certain JavaScript functions disabled though: - Move or resize existing windows - Raise or lower windows - Hide the status bar - Change status bar text - Disable or replace context menus I don't know what exactly happens in case some page wants to try the one or the other (complete stop of JavaScript processing or just ignoring that particular function?). Usually these functions should really not be used - and I don't think that's the source of the problem. Well, we (me Gabriele Maurizio) developed only the map page, the rest was done by another company: no idea of what they did. PS: We might better do this off-list if you have more questions. May you try with Javascript off ? That should show you a javascript-free CForms form (the map is contained in an iframe, hence you have to click inside said iframe to view the source of the correct web page. Another option is going directly to the map page link: http://www.tutelamare.it/cocoon/tm/app/it/index.html Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] A simple CForms example doesn't work...
Grzegorz Kossakowski wrote: Luca Morandini pisze: Done: do you mind checking it and, in case, put it LIVE ? I've checked your changes and had to add some more because you missed some resource:// replacements with servlet:/. It's been put live now. It is only me, or the page has not been updated yet (cache issue ?) ? http://cocoon.apache.org/2.2/blocks/forms/1.0/478_1_1.html Reagrds, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote: Luca Morandini wrote: Do you mind terribly showing me an example of the use of this API ? Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); Yes, something like that. But add in the mix the often discussed content-aware selection I remember that one, it was one of my first gripes with Cocoon, circa 2001... gee, that's 7 years ago ! I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? I don't think we're talking about monoculture here, but about avoiding the clumsyness of a reinventing a real programming language in XML. Point taken, though having a single place to look at in order to understand the URI routing has its merits. Moreover, since the introduction of Flowscript, the tricky things can be done in it, leaving the sitemap declarative syntax to what it does best. About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] A simple CForms example doesn't work...
Grzegorz Kossakowski wrote: Luca Morandini pisze: ...so I suppose an upgrade of the doc is in order: I may volunteer in absence of anyone taking care of it him/herself. I think it would be the best if you could take care of updating the docs because it was you who suffered recently of not up-to-date docs. I'll be happy to provide comments and advice whenever needed. Done: do you mind checking it and, in case, put it LIVE ? Thank you for your involvement! You're welcome. Regards, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Sylvain Wallez wrote: So we can take a different approach, and consider that we can use plain programming languages rather than grow our own pseudo-languages. A well-defined Java API and its Javascript binding would make people way more productive than an XML-based language like the sitemap. Do you mind terribly showing me an example of the use of this API ? Something like: CocooonStream stream= new CocoonStream(file, documents/mydoc.xml); stream.transform(xslt, xsl/doc2html.xsl); return stream.serialize(html); ? I understand the usefulness of having a programmatic API and this approach plays well with the Java monoculture, but, there aren't libraries already doing that ? Regards, Luca Morandini www.lucamorandini.it
[2.2] A simple CForms example doesn't work...
...so I suppose an upgrade of the doc is in order: I may volunteer in absence of anyone taking care of it him/herself. Regards, Luca Morandini www.lucamorandini.it
[2.2] Forms dependency on Ajax block
I must admit I am a bit uneasy about this dependency, which adds considerably to the JAR-tonnage of Cocoon even when the user is not interested in Ajax forms. Is this inevitable or there is a way to disentangle the two blocks ? As far as I understand one has to change forms-field-styling.xsl to avoid loading DoJo widgets if not needed, but I ignore whether there are other links to sever. Regards, P.S. By the way, I don't know whether this dependency has been discussed (a search on the archives didn't help), so, if the community has already decided to keep it, please disregard my plea. Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: Dojo is used to only handle Ajax mode of Forms but to handle advanced field styling of Forms widgets as well that has nothing to do with Ajax. Yes, I've looked into the code and discovered that ;) This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. Which is a departure from 2.1.9, which, IIRC, worked even with Javascript disabled on the browser. I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. Why I'm making such a plea ? Well, the use of non-Javascript forms is a requirement for making websites accessible, which is a mandatory for governmental websites in Italy. Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: I presume that a way to disentangle forms and ajax blocks would be to make two different forms-field-styling.xsl (one with Javascript and/or Ajax, the other without Javascript), loaded conditionally on ajax=true by forms-samples-styling.xsl. That would be quite difficult because there is no easy way to conditionally load XSL templates. Gee... yes, that's one of the things XSLT is not supposed to do. What about making inclusion of JS libraries in generated HTML forms conditional? It would only require tweaking existing templates. Dropping libraries is easy, what's not so easy is the dropping of the Javascript code poping up here and there. Another solution would be to make every template dual: xsl:template match=fi:validation-message xsl:choose xsl:when test=$ajax-mode='true' span dojoType=forms:infopopup ... /span /xsl:when xsl:otherwise span style=display:none ... /span /xsl:otherwise /xsl:choose /xsl:template Come to think of it, there should be three modes, not teo: ajax, javascript, no-javascript. Hence, ajax='true' should be changed too, maybe to client='static|dynamic|ajax'... hmm... the matter is getting hairy. Regards, Luca Morandini www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
Come to think of it, there should be three modes, not teo: ajax,
javascript, no-javascript.
Hence, ajax='true' should be changed too, maybe to
client='static|dynamic|ajax'... hmm... the matter is getting hairy.
Ah, right. Not sure what's the best solution for this. Have you done some
research on how others
avoid using JS for things like pop-up windows? I hope you can come up with
something general that
won't increase complexity of existing XSLT templates.
Well, you can use hidden DIVs, to be displayed when an on hover event
is triggered.
Off the top of my head:
...
style type=text/css
.errmsg div {
display:none;
}
.errmsg:hover div {
display:block;
position:absolute;
top:inherit;
left:inherit;
z-index:10;
width:50%;
background-color:red;
color:white;
font-size:1.3em;
}
/style
...
div class=errmsg
Error
div
img
src=http://cocoon.apache.org/2.2/blocks/forms/1.0/images/errors.gif/
This is a rather annoying error message
/div
/div
I'm sure a web designer coudl come up with something better.
If it's not possible I would recommend creation of your own forms-customized
block that will inherit
from original Cocoon block and override necessary templates. Thanks to SSF
capabilities there are
very clean ways to customize such things.
That's absolutely true: I'm starting to appreciate what SSF can do.
Regards,
Luca Morandini
www.lucamorandini.it
Re: [2.2] Forms dependency on Ajax block
Grzegorz Kossakowski wrote: Luca Morandini pisze: Well, you can use hidden DIVs, to be displayed when an on hover event is triggered. ... Ah, right. Is this technique considered as accessible? Yep: it doesn't use Javascript and it dosn't break the linearity of the page. Regards, Luca Morandini www.lucamorandini.it
[jira] Created: (COCOON-2171) The settings object is not available in the JXTemplate generator.
The settings object is not available in the JXTemplate generator. - Key: COCOON-2171 URL: https://issues.apache.org/jira/browse/COCOON-2171 Project: Cocoon Issue Type: Bug Components: Blocks: Templating Affects Versions: 2.2-dev (Current SVN) Reporter: Luca Morandini It seems that settings are passed to the CocoonEntryObjectModelProvider class, but not put into the cocoonMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANN]: Fins 1.0.0-SNAPSHOT released
Folks, the news of Fins project's death were greatly exaggerated: the thing is back, with more features and ready for Cocoon 2.2 and Maven. Before releasing it though, we would like people to check that everything works as advertised, so, if you can spare half an hour, pay a visit to: http://www.lucamorandini.it/fins/index.html and install it (the use of my own website to host the snapshot is transient). Actually, beside Cocoon 2.2, we think it should work on Cocoon 2.1 as well, but we would like you to try this yourself. Thanks in advance, Luca Morandini www.lucamorandini.it
Re: [GT2007] Request for papers
Andrew Savory wrote: Hmm, the list of ideas somehow got eaten by the mail daemons, so here's the suggestions from last year. Anyone care to add anything? Since the scenario has changed a bit since 2006, I'd rather like to hear something on these topics: 1) 2.2: what's in it for me ? 2) Shall we move Cocoon from service-oriented to resource-oriented to better support RIA/Ajax/Web 2.0/insert your own bizzwords ? 3) CForms vs Apache-Wicket 4) Some success stories on TDD (and the best tools for the job). Regards, Luca Morandini www.lucamorandini.it
Re: Configuration handling in 2.2 (properties etc.)
Carsten Ziegeler wrote: In the last months we changed the handling of properties and configurations files several times. The current implementation is a clean solution which reads configuration files from the classpath. While this is a very nice solution, especially for distributing components, it has the drawback that currently users have to put their own global configuration either into a jar file or into WEB-INF/classes/META-INF/cocoon. (I recently updated this mechanism to give properties from WEB-INF/classes precedence over jar files). Meaning they are loaded *after* the properties in JARs, right ? Regards, Luca Morandini www.lucamorandini.it
Re: Configuration handling in 2.2 (properties etc.)
Reinhard Poetz wrote: Carsten Ziegeler wrote: Some raised the concern on this list that this is not very intuitiv and they would like to include WEB-INF/cocoon/* to be read by default as well. Adding support for this is very easy, it's just one more line of code, so this is not the deal. The question is if we want to provide this extra location or not? I'm in the not camp. Starting with 2.2 there shouldn't be any Cocoon applications anymore that are not developed as blocks. The only exception from this rule of decentralization is Spring properties in WEB-INF/cocoon/spring as there should be a way to set them globally. Let me simulate a scenario: suppose I have a generators block out of Cocoon distro, with some default configuration (size of pools, etc.), now suppose I want those properties to change for my application: I presume I have to set those properties in my application's JAR (provided, of course, it is deployed as a block), right ? And what if my application's JAR is read before the generators block JAR (as it may well happen, since they're in alphabetic order) ? Hence the need for a separate properties file, a file of last resort to set application-wide properties, possibly properties used by many blocks. But, come to think of it, a sysadmin may want to tailor pools size according to each server my application runs on, hence system-wide properties may come in handy. If such system-wide properties are under classes/META-INF/... they are subject to the same alphabetic order rules of JARs' properties, and this could, just possibly, lead to some anomalies if other blocks are added afterwards. Therefore, I think using WEB-INF/cocoon to store system-wide properties, properties assured to be read after *all* the properties in classes/META-INF/..., may still make sense. So, according to this line of thought, the loading order would be: 1) Properties in JARs (blocks, actually) to be read from classes/META-INF/... 2) Properties *not* in JARs to be read from classes/META-INF/... and to overwrite the ones in JARs (as Carsten just did). 3) Properties in WEB-INF/cocoon to overwrite the ones in 1 an 2. Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Ralph Goers wrote: Luca Morandini wrote: So, the chain you propose is (sorted by order of loading): 1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff). 2) WEB-INF/classes/cocoon/properties (project-wide stuf). In truth, I don't find the use of classes for configuration stuff done outside JARs particularly intuitive... I'd rather stick with WEB-INF/cocoon/properties. One more level is needed which is already in the 2.1 branch (and I thought 2.2). The system property org.apache.cocoon.settings points to the directory where properties can be found. In our environment we never touch stuff inside war or ear files, especially since they might not be exploded. If you take a look at the comments in SettingsBeanFactoryPostProcessor source code, you'll find that plenty of configuration options are provided, and I think Cocoon should stick to that plan rather than dropping the WEB-INF/classes/cocoon/properties option. Regards, Luca Morandini www.lucamorandini.it
Order of properties files loading in 2.2 (yes, again !)
I inherited from a legacy project a file named core.proprties, which I put into .../classes/META-INF/... but, to my surprise, it didn't work as it was supposed to... a quick debug session revealed that the loading order was: 1) URL [jar:file:/C:/projects/analytics/blocks/cocoon-trunk/build/webapp/WEB-INF/lib/cocoon-core-2.2.0-M3-SNAPSHOT.jar!/META-INF/cocoon/properties/cocoon-core-store.properties] 2) file [C:\projects\analytics\blocks\cocoon-trunk\build\webapp\WEB-INF\classes\META-INF\cocoon\properties\core.properties] 3) URL [jar:file:/C:/projects/analytics/blocks/cocoon-trunk/build/webapp/WEB-INF/lib/cocoon-core-2.2.0-M3-SNAPSHOT.jar!/META-INF/cocoon/properties/core.properties] As you may notice, the loading gives precedence to files over JARs, but taking *only the file name* into account (I expected JAR names to be part of the sort key as well). So, if two or more blocks (JARs) have the same properties file name, what happens ? Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Carsten Ziegeler wrote: Luca Morandini wrote: One issue, though: since the property loading mechanism uses classpath:° protocol, property files are read in alphabetical order, which means I might have my per-project properties ruined by the addition of a block, unless I call them .properties. This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the classpath:* chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Last ? Hmm... I'm not sure I got you point. Anyway, what I meant is that I'd like to have a way to load project-wide properties that cannot be overridden by block-wide ones. Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Giacomo Pati wrote: Carsten Ziegeler wrote: Luca Morandini wrote: This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the classpath:* chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Luca is absolutely right! WEB-INF/classes should be the last resort where one ultimatively can overwrite properties (same should be true for WEB-INF/classes/META-INF/cocoon/spring/.) Just to be absolutely clear: In my eyes WEB-INF/classes/META-INF/cocoon/properties should be used for block-wide property or cocoon defaults, and WEB-INF/cocoon/properties for project-wide properties. I suppose most users would just put their properties under WEB-INF/cocoon and update the *.properties under WEB-INF/classes/META-INF only at their peril (a block update, or the adding of a block that happens to have a properties file starting with a greater letter of the alphabet may ruin their day). By the way, let's suppose I use block fooblock, which has a nice META-INF/cocoon/properties/fooblock.properties file tucked under its JAR: is fooblock.properties unzipped by default under WEB-INF/classes/META-INF so I can modify its properties ? If so, what happens when there is another version of fooblock ? Is the properties file overwritten at installation (deploy) time ? Sorry if the last questions seem so silly, but... better safe than sorry ;) Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Carsten Ziegeler wrote: Luca Morandini schrieb: Carsten Ziegeler wrote: Luca Morandini wrote: This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the classpath:* chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Last ? Hmm... I'm not sure I got you point. Yepp, the properties system works in the way that the last definition wins. And this means that project-wide stuff has to be loaded last. So, the chain you propose is (sorted by order of loading): 1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff). 2) WEB-INF/classes/cocoon/properties (project-wide stuf). In truth, I don't find the use of classes for configuration stuff done outside JARs particularly intuitive... I'd rather stick with WEB-INF/cocoon/properties. Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Daniel Fagerstrom wrote: Luca Morandini skrev: Reinhard Poetz wrote: Daniel Fagerstrom wrote: Luca Morandini skrev: We have updated the deployment mechanism recently, and I got the same error message a short period before I updated the bean configuration in META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml for cocoon-core-main-sample. Luca (and others), delete your org/apache/cocoon directory from your local repo and build cocoon again. Maybe this helps ... Unfortunately it doesn't. So, I updated the SVN working copy, deleted the whole cocoon branch of the maven repo, executed a clean build and yet I cannot make Cocoon run... despiriting indeed. Sounds frustrating :/ I followed exactly the same steps as you have described in your mails, and for me it works. I assume that you get the same errors as before? In that case something is wrong with your Maven setup. The cocoon-webapp module doesn't depend on cocoon-core-main-sample anymore, so the fact that it shows in your stack trace means that it is not the poms from your newly updated Cocoon that is used. Probably some old poms and maybe also some old jars are downloaded during the build process. Also the error messages looks like problems that I and others have fixed some while ago. Which also is a reason to believe that some older versions of the jars are downloaded and executed. Dropped the Maven local repository and re-ran the build: no hope. Jorg wrote some while ago that there can be problems with some settings file pointing to mirrors with artifacts that are not synchronized properly http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116404436302770w=2. You could see if his suggestions help. Dropped settings.xml and svn-updated to recreate it: no joy. Otherwise you need to figure out why cocoon-core-main-sample becomes part of your cocoon-webapp during build. If you rebuild cocoon-webapp using the -X switch you will get a complete tree view of all the dependencies. So here we would need to know the dependency chain for the cocoon-core-main-sample jar. Dropped (again) the local maven repository, dropped the cocoon-2.2 checkout, did a fresh checkout... and Cocoon eventually worked. But I suppose is not meant to be this way... Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Daniel Fagerstrom wrote: Luca Morandini skrev: file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-deployer-plugin-classloading.jar, This is strange, I don't have this jar on my class path. It is probably a leftover from a build without the -Dmaven.war.shieldingclassloader=false switch. Try a mvn -Dmaven.war.shieldingclassloader=false clean install in the cocoon-webapp. I always do a clean install... I already had my fingers burnt a few times ;) Anyway, after an svn up and a clean install with shieeldingclassloader set to false, the error has changed, but an error it still is. I issued: cd core/cocoon-webapp/ mvn jetty:run -X -Dorg.apache.cocoon.mode=dev but... [DEBUG] classpath element: classes [DEBUG] classpath element: concurrent-1.3.4.jar [DEBUG] classpath element: aopalliance-1.0.jar [DEBUG] classpath element: jakarta-bcel-20040329.jar [DEBUG] classpath element: excalibur-logger-2.1.jar [DEBUG] classpath element: jakarta-regexp-1.4.jar [DEBUG] classpath element: commons-logging-1.0.4.jar [DEBUG] classpath element: spring-beans-2.0.1.jar [DEBUG] classpath element: cocoon-core-2.2.0-M2-SNAPSHOT.jar [DEBUG] classpath element: excalibur-sourceresolve-2.1.jar [DEBUG] classpath element: commons-lang-2.1.jar [DEBUG] classpath element: junit-3.8.jar [DEBUG] classpath element: avalon-framework-api-4.3.jar [DEBUG] classpath element: log4j-1.2.13.jar [DEBUG] classpath element: excalibur-xmlutil-2.1.jar [DEBUG] classpath element: commons-jxpath-1.2.jar [DEBUG] classpath element: commons-jexl-1.0.jar [DEBUG] classpath element: excalibur-store-2.1.jar [DEBUG] classpath element: commons-jci-core-1.0-SNAPSHOT.jar [DEBUG] classpath element: xml-apis-1.3.02.jar [DEBUG] classpath element: commons-jci-fam-1.0-SNAPSHOT.jar [DEBUG] classpath element: excalibur-pool-api-2.1.jar [DEBUG] classpath element: ehcache-1.2.jar [DEBUG] classpath element: avalon-framework-impl-4.3.jar [DEBUG] classpath element: xml-resolver-1.1.jar [DEBUG] classpath element: xalan-2.7.0.jar [DEBUG] classpath element: spring-web-2.0.1.jar [DEBUG] classpath element: excalibur-instrument-api-2.1.jar [DEBUG] classpath element: commons-collections-3.2.jar [DEBUG] classpath element: cocoon-blocks-fw-impl-1.0.0-SNAPSHOT.jar [DEBUG] classpath element: commons-logging-api-1.0.4.jar [DEBUG] classpath element: commons-io-1.2.jar [DEBUG] classpath element: spring-context-2.0.1.jar [DEBUG] classpath element: xercesImpl-2.8.0.jar [DEBUG] classpath element: spring-aop-2.0.1.jar [DEBUG] classpath element: spring-core-2.0.1.jar [INFO] Webapp directory = C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\cocoon-webapp [INFO] Starting jetty 6.0.0rc4 ... 2006-11-28 04:23:57.703::INFO: jetty-6.0.0rc4 [DEBUG] Setting up classpath ... ... [DEBUG] Started configuring web.xml, resource base=C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\cocoon-webapp 2006-11-28 04:23:58.343::INFO: Bound java:comp/env/greeting=Hello, World [DEBUG] Finished configuring web.xml log4j:WARN No appenders could be found for logger (org.springframework.web.context.ContextLoader). log4j:WARN Please initialize the log4j system properly. 2006-11-28 04:23:59.015:/:INFO: Loading Spring root WebApplicationContext 2006-11-28 04:24:00.390:/:INFO: Apache Cocoon 2.2.0-M2-SNAPSHOT is running in mode: dev 2006-11-28 04:24:01.437::WARN: failed [EMAIL PROTECTED]/,file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/} 2006-11-28 04:24:01.437::WARN: failed [EMAIL PROTECTED] 2006-11-28 04:24:01.437::WARN: failed [EMAIL PROTECTED] 2006-11-28 04:24:01.781::INFO: Started SelectChannelConnector @ 0.0.0.0: 2006-11-28 04:24:01.781::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: Error creating bean with name 'org.apache.cocoon.core.main.block' defined in URL [jar:file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-main-sample-1.0.0-SNAPSHOT.jar!/META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml]: Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not create configuration for TreeProcesoor; nested exception is java.io.IOException: Couldn't find the sitemap /sitemap.xmap [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458
Re: Trying to start Cocoon 2.2
Daniel Fagerstrom wrote: Luca Morandini skrev: Embedded error: Error creating bean with name 'org.apache.cocoon.core.main.block' defined in URL [jar:file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-main-sample-1.0.0-SNAPSHOT.jar!/META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml]: Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not create configuration for TreeProcesoor; nested exception is java.io.IOException: Couldn't find the sitemap /sitemap.xmap [INFO] There is still something strange in your setup. As you can see above, Cocoon (in o.a.c.core.deployment.DeploymentUtil I would assume) reads from the jar: cocoon-core-main-sample-1.0.0-SNAPSHOT.jar, which not should be on the dependency list from recent cocoon-webapp checkouts. Probably there is an old version of the jar in your cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/ directory. I zapped the contents of cocoon-webapp/target and rebuilt: no joy. We have updated the deployment mechanism recently, and I got the same error message a short period before I updated the bean configuration in META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml for cocoon-core-main-sample. To work the value of the property blockContextURL in the configuration file should be blockcontext:/cocoon-core-main-sample/ instead of a relative URL as it was before. So you probably either get an old version of the cocoon-core-main-sample or an old version of cocoon-core. Well, actually blocks\cocoon-core-sample\cocoon-core-main-sample\src\main\resources\META-INF\cocoon\spring\cocoon-core-main-sample-blockServlet.xml has the correct value of blockContextURL (I did an svn update, so this doesn't come as a surprise to me). ... The next question is of course why the shielding classloader doesn't work in some environments. It works for me (jdk1.5.0_06, Windows XP). It's the same environment for me as well. Then something else must differ. I don't know that much about the working of the shielding classloader. Maybe Carsten has some hypothesis. How can I be sure to have your exact configuration: dropping the maven repo and build everything from scratch (how painful !) ? Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Reinhard Poetz wrote: Daniel Fagerstrom wrote: Luca Morandini skrev: We have updated the deployment mechanism recently, and I got the same error message a short period before I updated the bean configuration in META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml for cocoon-core-main-sample. Luca (and others), delete your org/apache/cocoon directory from your local repo and build cocoon again. Maybe this helps ... Unfortunately it doesn't. So, I updated the SVN working copy, deleted the whole cocoon branch of the maven repo, executed a clean build and yet I cannot make Cocoon run... despiriting indeed. Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Patrick Refondini wrote: shouldn't it be : -Dmaven.war.shieldingclassloader=false Thanks for this bit of information, but Cocoon doesn't run yet. I did: mvn -Dmaven.test.skip=true -Dmaven.war.shieldingclassloader=false clean install cd core/cocoon-webapp mvn jetty:run-exploded -Dorg.apache.cocoon.mode=dev But... log4j:WARN No appenders could be found for logger (org.springframework.web.context.ContextLoader). log4j:WARN Please initialize the log4j system properly. 2006-11-27 15:36:32.609:/:INFO: Loading Spring root WebApplicationContext 2006-11-27 15:36:34.218:/:INFO: Apache Cocoon 2.2.0-M2-SNAPSHOT is running in mode: dev 2006-11-27 15:36:34.718::WARN: failed [EMAIL PROTECTED]/,file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/} 2006-11-27 15:36:34.718::WARN: failed [EMAIL PROTECTED] 2006-11-27 15:36:34.718::WARN: failed [EMAIL PROTECTED] 2006-11-27 15:36:34.781::INFO: Started SelectChannelConnector @ 0.0.0.0: 2006-11-27 15:36:34.781::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: Cannot invoke listener [EMAIL PROTECTED] Couldn't find the sitemap /sitemap.xmap (same error with ./start.sh, by the way). Any clue ? Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Daniel Fagerstrom wrote: Luca Morandini skrev: Patrick Refondini wrote: shouldn't it be : -Dmaven.war.shieldingclassloader=false Thanks for this bit of information, but Cocoon doesn't run yet. I did: mvn -Dmaven.test.skip=true -Dmaven.war.shieldingclassloader=false clean install cd core/cocoon-webapp mvn jetty:run-exploded -Dorg.apache.cocoon.mode=dev I have had problems lately with that an avalon-framework-4.0.jar (from 2002!) is included in target/cocoon-webapp/WEB-INF/lib. It shadows the Avalon framework 4.3 jars that Cocoon depends on and give a stack trace similar to yours. Remove the faulty jar and try to run Cocoon again. I don't think this is the issue, since I see only two Avalon JARs, both 4.3 (avalon-framework-api-4.3.jar, avalon-framework-impl-4.3.jar). Some other points: jetty:run-exploded seem to do some unnecessary extra work compared to jetty:run. Use the -e switch for jetty:run so that you get the whole stack trace. Otherwise it is very hard to see what is the problem. Here you are, Sir: [INFO] [jetty:run] [INFO] Configuring Jetty for project: Core Webapp [INFO] Webapp source directory = C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\cocoon-webapp [INFO] web.xml file = C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\cocoon-webapp\WEB-INF\web.xml [INFO] Classes directory C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\classes does not exist 2006-11-27 17:04:33.307::INFO: Logging to STDERR via org.mortbay.log.StdErrLog [INFO] Context path = / [INFO] Tmp directory = c:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\work [INFO] Web defaults = jetty default [INFO] Webapp directory = C:\apps\cocoon-2.2-dev\core\cocoon-webapp\target\cocoon-webapp [INFO] Starting jetty 6.0.0rc4 ... 2006-11-27 17:04:35.150::INFO: jetty-6.0.0rc4 [INFO] Classpath = [file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/classes/, file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-deployer-plugin-classloading.jar, file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/classes, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/concurrent/concurrent/1.3.4/concurrent-1.3.4.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/springframework/spring-core/2.0/spring-core-2.0.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/jakarta-bcel/jakarta-bcel/20040329/jakarta-bcel-20040329.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/excalibur/containerkit/logger/excalibur-logger/2.1/excalibur-logger-2.1.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/jakarta-regexp/jakarta-regexp/1.4/jakarta-regexp-1.4.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/springframework/spring-aop/2.0/spring-aop-2.0.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/cocoon/cocoon-core/2.2.0-M2-SNAPSHOT/cocoon-core-2.2.0-M2-SNAPSHOT.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/junit/junit/3.8/junit-3.8.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/avalon/framework/avalon-framework-api/4.3/avalon-framework-api-4.3.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/excalibur/components/sourceresolve/excalibur-sourceresolve/2.1/excalibur-sourceresolve-2.1.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/log4j/log4j/1.2.13/log4j-1.2.13.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/excalibur/components/xmlutil/excalibur-xmlutil/2.1/excalibur-xmlutil-2.1.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/commons-jexl/commons-jexl/1.0/commons-jexl-1.0.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/excalibur/components/store/excalibur-store/2.1/excalibur-store-2.1.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/springframework/spring-web/2.0/spring-web-2.0.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-core-1.0-SNAPSHOT.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/xml-apis/xml-apis/1.3.02/xml-apis-1.3.02.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-fam-1.0-SNAPSHOT.jar, file:/C:/Documents%20and%20Settings/morandil/.m2/repository/org/apache/excalibur/components/pool/excalibur-pool-api/2.1
Trying to start Cocoon 2.2
Could someone tell me what I'm missing ? svn update mvn -Dmaven.test.skip=true clean install cd core/cocoon-webapp mvn jetty:run-exploded -Dorg.apache.cocoon.mode=dev ... [INFO] Starting jetty 6.0.0rc4 ... 2006-11-26 15:51:04.296::INFO: jetty-6.0.0rc4 2006-11-26 15:51:05.640::WARN: failed [EMAIL PROTECTED]/,file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/} 2006-11-26 15:51:05.640::WARN: failed [EMAIL PROTECTED] 2006-11-26 15:51:05.640::WARN: failed [EMAIL PROTECTED] 2006-11-26 15:51:05.812::INFO: Started SelectChannelConnector @ 0.0.0.0: 2006-11-26 15:51:05.812::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError at java.util.jar.JarFile.getEntry(JarFile.java:200) at java.util.jar.JarFile.getJarEntry(JarFile.java:183) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:674) at sun.misc.URLClassPath.getResource(URLClassPath.java:161) at java.net.URLClassLoader$1.run(URLClassLoader.java:192) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.cocoon.maven.deployer.servlet.ShieldedClassLoader.getClass(ShieldedClassLoader.java:58) Regards, Luca Morandini www.lucamorandini.it
Re: Trying to start Cocoon 2.2
Mark Lundquist wrote: On Nov 26, 2006, at 1:07 PM, Luca Morandini wrote: Could someone tell me what I'm missing ? Per some other recent threads: try -Dshieldedclassloading=false in your mvn. I built Cocoon with: mvn -Dmaven.test.skip=true -Dshieldedclassloading=false clean install and run within the Jetty mvn plugin, but no joy. Is the name of this property correct ? Regards, Luca Morandini www.lucamorandini.it
Re: VNU Europe moves to Cocoon...
Pier Fumagalli wrote: It's quite some time since you heard new announcements from me, but I think this is quite important... We just finished launching the first of the EU countries here at VNU, powered by Cocoon: Italy. Despite much evidence to the contrary, UK is (still) an EU country ;) Regards, P.S. Well done guys :) Luca Morandini www.lucamorandini.it
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko wrote: rather than wait several more years for Cocoon Vista to appear on horizon. ^ Man, that's nasty ;) Luca Morandini www.lucamorandini.it
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko wrote: rather than wait several more years for Cocoon Vista to appear on horizon. And that's even nastier ;) Luca Morandini www.lucamorandini.it
Re: Using a Java Object from XSLT
Berin Loritsch wrote:
I have a Java object I am using to generate links. It would make my
life easier if I could use it directly in my XSLT--even though it is
created outside of the XSLT system. Is it as easy as passing it in as a
parameter? Or is there some extra leg work necessary?
It's not *that* easy, but Xalan offers various extension mechanism for
your XSLT (sometimes you have no other choice... apart waiting for XSLT
2.0, of course).
Here's an example using Java [1]:
The Java class:
---
Import java.util.*;
public class MyCounter {
Hashtable counters = new Hashtable ();
public MyCounter ()
{}
public void init
( org.apache.xalan.extensions.XSLProcessorContext context,
org.apache.xalan.templates.ElemExtensionCall extElem )
{
String name = extElem.getAttribute(name);
String value = extElem.getAttribute(value);
int val;
try
{
val = Integer.parseInt (value);
}
catch (NumberFormatException e)
{
e.printStackTrace ();
val = 0;
}
counters.put (name, new Integer (val));
}
public int read(String name)
{
Integer cval = (Integer) counters.get (name);
return (cval == null) ? 0 : cval.intValue ();
}
public void incr
( org.apache.xalan.extensions.XSLProcessorContext context,
org.apache.xalan.templates.ElemExtensionCall extElem)
{
String name = extElem.getAttribute(name);
Integer cval = (Integer) counters.get(name);
int nval = (cval == null) ? 0 : (cval.intValue () + 1);
counters.put (name, new Integer (nval));
}
}
The stylesheet:
---
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:xalan=http://xml.apache.org/xalan;
xmlns:counter=MyCounter
extension-element-prefixes=counter
version=1.0
xalan:component prefix=counter
elements=init incr functions=read
xalan:script lang=javaclass src=xalan://MyCounter/
/xalan:component
xsl:template match=/
HTML
H1Names in alphabetical order/H1
counter:init name=index value=1/
xsl:for-each select=doc/name
xsl:sort select=@last/
xsl:sort select=@first/
p
xsl:text[/xsl:text
xsl:value-of select=counter:read('index')/
xsl:text]. /xsl:text
xsl:value-of select=@last/
xsl:text, /xsl:text
xsl:value-of select=@first/
/p
counter:incr name=index/
/xsl:for-each
/HTML
/xsl:template
/xsl:stylesheet
Regards,
[1] http://xml.apache.org/xalan-j/extensions.html#ex-java
Luca Morandini
www.lucamorandini.it
Re: How to add documentation do ImageMap widget ?
Luca Morandini wrote: Folks (well, I suppose Helma), In 2.1.8 I noticed the doc for ImageMap widget is missing though I've submitted some along with the code; quite naturally, I pressed the view edit or comment on link, to be greeted by an error message... now, what can I do to fill in the doc ? Ok, now I can log on since the server is live again, but, as guest, I cannot alter the daisy pages: only committers are allowed to edit Cocoon doc on Daisy ? Should I go to Wiki ? Regards, Luca Morandini www.lucamorandini.it
How to add documentation do ImageMap widget ?
Folks (well, I suppose Helma), In 2.1.8 I noticed the doc for ImageMap widget is missing though I've submitted some along with the code; quite naturally, I pressed the view edit or comment on link, to be greeted by an error message... now, what can I do to fill in the doc ? Regards, Luca Morandini www.lucamorandini.it
Re: [RT][long] Cocoon 3.0: the necessary mutation
Stefano Mazzocchi wrote: Luca Morandini wrote: Nevertheless, it is easier to build a tool around a declarative language expressed as XML, than a procedural language expressed as... a procedural programming language. I'm sorry, Luca, but I think that's BS. cut/ For example, do you think that if the java classes were expressed as XML statements that *declarative* describe their methods and variables and inner classes it would be easier to write a tool like Eclipse? That I don't know, I've never seen the inner workings of Eclipse. Let's just say that when something is written in XML (say, an UML model expressed as XMI) I can fire up Xalan and beat the beast into submission easily, if the same mopel was expressed as a set of Java classes... hmmm... time for man yacc ? Maybe it's just that I've worked with XML for too long, but I still like the easy production/validation/transformation of vocabularies that comes with it, and I'm scared a bit by the other approach. Regards, Luca Morandini www.lucamorandini.it
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: Luca Morandini wrote: Generally speaking, in the procedural vs. declarative debate I drifts towards the latter. For example, I see the advantages in using something like Spring Web Flow, not the least of them being the easy development of tools (AndroMDA maybe ?). If you can roundtrip between a model and a procedural language, then tooling is not a problem. cut/ Granted. Nevertheless, it is easier to build a tool around a declarative language expressed as XML, than a procedural language expressed as... a procedural programming language. Regards, Luca Morandini www.lucamorandini.it
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: When we introduced flowscript, we decided that map:pipeline should be the central switchboard through which *all* request go, cut/ - the processing flow in a sitemap goes *first* in the controller if there is one, and *second* in the view. Going to a map:pipeline to call back a function should really be an exceptional case, or even forbidden. Hmm... my favorite selling proposition about Cocoon is look no further than the sitemap to know which component answers an URI, and this dynamic pipeline concept would shatter this. Generally speaking, in the procedural vs. declarative debate I drifts towards the latter. For example, I see the advantages in using something like Spring Web Flow, not the least of them being the easy development of tools (AndroMDA maybe ?). Regards, Luca Morandini www.lucamorandini.it
Re: [RT][long] Cocoon 3.0: the necessary mutation
Bertrand Delacretaz wrote: Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit : ...Dynamic pipelines IMHO, being able to use this stuff *outside* of Cocoon, without having to learn more than that, would make a big difference. A small facade with a clever class loader should make it possible to embed this PipelineEngine in most any java environment, not? Excuse me Bertrand, but I fail to see what's so special about this: I did this (and an aggregator too) in ASP about an year ago (I missed Cocoon very badly in that project) and I presume you can do the same in Java with no need for Cocoon, can't you ? Regards, Luca Morandini www.lucamorandini.it
Re: [RT][long] Cocoon 3.0: the necessary mutation
Bertrand Delacretaz wrote: Le 3 déc. 05, à 14:04, Luca Morandini a écrit : Excuse me Bertrand, but I fail to see what's so special about this: I did this (and an aggregator too) in ASP about an year ago (I missed Cocoon very badly in that project) and I presume you can do the same in Java with no need for Cocoon, can't you ? Of course you can build pipelines without Cocoon, but the idea is to be able to easily reuse our existing components, aggregators, transformers, serializers, etc. Hmm... some of them are already packaged as indipendent Java libraries (Batik, Xalan, etc.); moreover, it seems to me like eating the skin and discarding the pulp of Cocoon... but to a non-Cocoon sort of a guy it may look a sensible option. Regards, Luca Morandini www.lucamorandini.it
ImageMap sample is not working
In both 2.1.8-rc1 and 2.2-dev hosted on cocoon.zones, the logo doesn't appear. Regards, Luca Morandini www.lucamorandini.it
Re: Where are my spare ribs ?
Arje Cahn wrote: Whoops Let me correct that! I'll put it on the site. Thanks for pointing out... ...and maybe a reminder on both lists. Thanks, Luca Morandini www.lucamorandini.it
Re: Where are my spare ribs ?
Arje Cahn wrote:
Spareribs location [1]:
Restaurant Moeders Mooiste ('mum's prettiest')
Heinekenplein 5
Sorry to bother you again, but... at which time are we supposed to meet ?
Regards,
Luca Morandini
www.lucamorandini.it
Where are my spare ribs ?
Folks, it's probably only me missing the announcement... but I fail to see the 6th of Oct. meeting-point for the dinner on the GT website: could someone point it tp me ? Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Jorg Heymans wrote: Luca Morandini wrote: often discussed here, very true - as much as we hate (to admit) it ;) marketing type=idea Lets do a video like Rails [2], a picture says more than a thousand words, a video more than a thousand pictures! WDOT? Can something like this put us to shame or work in our advantage? /marketing FWIW, my comments: 1) Videos are great communication tools, and nothing prevent us from making them, I suppose. 2) This RoR video was good stuff, especially for people building simple, self-contained apps. 3) I liked the ActiveRecords part, which is something we have to wait for the Java community to respond to (as Sylvian noted earlier today). 4) I liked the Scaffold concept, which we may replicate: not just samples, but ready-made apps to help people hit the ground running when developing an app. I mean, we could have a reporting scaffold, or a multi-channel publishing scaffold, or a GIS scaffold (you expected that, didn't you ?). Stop the presses ! I've just seen the first 30s of Andrew's presentation... it looks great :) Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Jorg Heymans wrote: I'm also thinking about archetypes for popular framework combos, like CForms/hibernate, Cocoon/Spring, and often used block combos like portal/, fop/svg and ofcourse asciiart/midi ;) Hmm... I was thinking more in terms of user-visible functionalities rather than in terms of underlying technologies. Look, if one is going to use Spring, he won't be impressed by a canned app; on the contrary, such a canned app will make a splash on the average guy just thinking hmm... how could I publish that report in PDF and WML and HTML and Excel ?. Just imagine a wizard-like thing that guides you through the following: 1) Choose the page name. 2) Choose a view or table from your database of choice. 3) Choose the formats you'd like to include. 4) Voilà, The scaffold is generated ! 5) Enter the page URI and the report showing the database view/table appears: in PDF when the URI ends with .pdf, in Excel if the URI ends with .xls, etc. Not exactly exciting if someone knows Cocoon... but we're not preaching to the chorus here, are we ? ;) Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Sylvain Wallez wrote: I would (and actually do) use Mappy (http://www.mappy.com/), which has provided for ages a flash-based GUI that receives vector data from the server, and which is snappier than GMaps. Bitmaps suck when it comes to GIS! Up to a point, Sylvian... if you're talking about detailed maps, not just tourist ones, the rendering on the client is out of the question. Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Sylvain Wallez wrote: Luca Morandini wrote: Sylvain Wallez wrote: I would (and actually do) use Mappy (http://www.mappy.com/), which has provided for ages a flash-based GUI that receives vector data from the server, and which is snappier than GMaps. Bitmaps suck when it comes to GIS! Up to a point, Sylvian... Sylv*ai*n please :-) Sorry, I mistook you for the former Japan member [1] ;) if you're talking about detailed maps, not just tourist ones, the rendering on the client is out of the question. Ah, ok. But then I guess you need a lot of bandwidth anyway! My guess is different, even a 9.000 polygons maps is not such a load when processed on the server. Vector graphics is efficent form same maps and in-efficient for others, the same for bitmaps: there is no one-size-fits-all. Regards, [1] http://en.wikipedia.org/wiki/David_Sylvian Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Daniel Fagerstrom wrote: if we succeed in attracting a large user base, Are we ? Consider: 1) Declining cocoon-users activity. 2) Reduced attendance (so far) to GetTogether (and it shouldn't be, since Amsterdam is a more accessible, if less fascinating, location). 3) Struts being more and more popular. My 0.02 EUR: I think Cocoon will remain a niche framework, used for complex applications and/or by gifted developers. Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Is Cocoon Obsolete?
Daniel Fagerstrom wrote: Luca Morandini wrote: Daniel Fagerstrom wrote: if we succeed in attracting a large user base, Are we ? Consider: 1) Declining cocoon-users activity. 2) Reduced attendance (so far) to GetTogether (and it shouldn't be, since Amsterdam is a more accessible, if less fascinating, location). 3) Struts being more and more popular. It might be as you imply, the question is where we want to go. I agree. But, if a small team isn't winning it is losing... and I sense a loss of momentum since last year: why this is happening ? 1) Cocoon is not mature enough for making it self-sustaining. 2) Cocoon has become old hat for the early-adopters and they moved on to other, more exciting, things. 3) Both of the above, with Cocoon between the anvil and the hammer, failing to become as popular as, say, Struts and as exciting as Ruby on Rails (or whatever). Hence the dilemma: making it more mature or sexier ? My 0.02 EUR: I think Cocoon will remain a niche framework, used for complex applications and/or by gifted developers. Maybe, but I think we can increase the number of users by making ocoon less complex [...] That's why I can't wait for Torsten to deliver his RAD with Cocoon speech :) Regards, Luca Morandini www.lucamorandini.it
Re: SQLTransformer
Torsten Schlabach wrote: as if would allow for a generic XSLT which for example renders the rowset into an HTML table. WDYT? Not sure I understood you, but, if you want something like: table tr thfirstname/th thlastname/th /tr tr tdSchlabach/td tdTorsten/td /tr /table You can have it with both XML formats. It boils down to using local-name() instead of @name in the relevant XSLT, like: xsl:template match=rowset table xsl:apply-templates select=*/ /table /xsl:template xsl:template match=row xsl:if test=position()=1 tr xsl:for-each select=* thxsl:value-of select=local-name()//th /xsl:for-each /tr /xsl:if tr xsl:for-each select=* tdxsl:value-of select=.//td /xsl:for-each /tr /xsl:template On the other hand, the format you proposed is cleaner indeed. Regards, Luca Morandini www.lucamorandini.it
ImageMap: the donation
Folks,
The ImageMap widget is done. Doc about the widget is included in this
message, as it is the field styling changes, while the Java source can
be downloaded at http://www.lucamorandini.it/imagemap.zip
...enjoy :)
--
IMAGEMAP CONFIGURATION
--
This element has to be added to the forms-form.xconf:
widget name=imagemap
src=org.apache.cocoon.forms.formmodel.ImageMapDefinitionBuilder/
-
IMAGEMAP WIDGET REFERENCE
-
ImageMap widget
It is used to display a server-side image map and it triggers an
ImageMap event on the server side when clicked.
It behaves much as an Action widget, but you can bind the source URI of
the image using the binding framework fb:value element, set the image
at runtime using the setImageURI() method, and retrieve the mouse
coordinates with getX() and getY() methods.
A simple example follows:
Form definition document:
fd:imagemap id=map
fd:imageuritest.gif/fd:imageuri
fd:hintClick on this map to zoom-in/fd:hint
fd:on-action
javascriptonClickMap(event);/javascript
/fd:on-action
/fd:imagemap
Form binding document (you can set the image URI with binding as well):
fb:value id=map path=@src/
Form template:
ft:widget id=map
fi:styling
xmlns:fi=http://apache.org/cocoon/forms/1.0#instance;
border=2/
/ft:widget
Flow:
This is another way to set the image URI:
frm.getWidget().lookupWidget(map).setImageURI(test2.gif);
This is the handler of the imagemap event:
function onClickMap (event) {
var x= event.getX();
var y= event.getY();
var uri;
uri= map.zoomIn(new Rectangle(new Point(x, y), 1, 1));
if ( uri != map.zoominTooFar ) {
event.getSource().setImageURI(uri);
}
}
-
CHANGES TO FORM-FIELD-STYLING.XSL
-
!--+
| fi:imagemap
+--
xsl:template match=fi:imagemap
xsl:element name=input
xsl:attribute name=typeimage/xsl:attribute
xsl:attribute name=namexsl:value-of
select=@id//xsl:attribute
xsl:attribute name=srcxsl:value-of
select=@imageuri//xsl:attribute
xsl:attribute name=titlexsl:copy-of
select=fi:hint//xsl:attribute
xsl:attribute name=ismaptrue/xsl:attribute
xsl:apply-templates select=. mode=styling/
/xsl:element
/xsl:template
-
JAVA SOURCE FILES
-
Event package:
ImageMapEvent.java
FormModel package:
ImageMap.java
ImageMapDefinition.java
ImageMapDefinitionBuilder.java
Luca Morandini
www.lucamorandini.it
Re: ImageMap: the donation
Peter Hunsberger wrote: On 6/10/05, Luca Morandini [EMAIL PROTECTED] wrote: Note there is no need for the verbose XSLT element, attribute syntax here, you can just use something like: Sure, that was a leftover from various experiments I did and then forgot to streamline. Regards, Luca Morandini www.lucamorandini.it
ImageMap: is it still eww ! ?
The form definition:
fd:imagemap id=map
fd:sourcetest.gif/fd:source
fd:hint
i18n:textzoomInImage.hint.mapButton/i18n:text
/fd:hint
fd:on-action
javascriptonClickMap(event);/javascript
/fd:on-action
/fd:imagemap
The flow:
function onClickMap (event) {
var x= event.getX();
var y= event.getY();
var uri;
uri= map.zoomIn(new Rectangle(new Point(x, y), 1, 1));
if ( uri != map.zoominTooFar ) {
event.getSource().setImageURI(uri);
}
}
How about this, Vadim ? ;)
Regards,
Luca Morandini
www.lucamorandini.it
Re: ImageMap widget for CForms
oceatoon wrote: Fabulous, If the Map widgets is concidered as the map itself, then wouldn't it be usefull to pass the url of the image as attribute @url or fd:value, offcourse this could also be specified in the styling tag but you allready have the SetImageSource . Hmm... maybe an fd:image-source tag would do... I'll think about it. fd:datatype could also be an interesting piece of information to specify the type of map, image, SVG , GML ...other Wait, this is an *image map* widget (in the HTML sense), not a *map* widget. And a very usefull piece of definition would be fd:selection-list containing items, values, and labels, maybe urls or even GML... ??? WDYT? This might be a separate widget: again, don't forget this is not a map widget. This could be a very nice feature to connect to datasrc's for filling the map. It Could be similar to what the selection-list does , don't you think ? Don't forget this is not a a map widget, only an image map one. Regards, Luca Morandini www.lucamorandini.it
Re: ImageMap widget for CForms
Vadim Gritsenko wrote:
Luca Morandini wrote:
function onClickMap () {
var x= Number(cocoon.request.getParameter(map.x));
var y= Number(cocoon.request.getParameter(map.y));
Eww!
Ahem... what Eww!, exactly, means ?
var uri;
uri= zoomed map uri/;
frm.getWidget().lookupWidget(map).setImageSource(uri);
Widget is available through event.sourceWidget, IIRC.
Hmmm... yes, it would be better, I'll look into it.
BTW, I'd like mouse coordinates to be retrieved by querying the map
widget rather than the request object... anyone knows a simple way to
do this from within the widget class (subclass of AbstractWidget) ?
Just create your own MapEvent with x, y fields.
Thanks for the suggestion, I'll work on it.
Regards,
Luca Morandini
www.lucamorandini.it
Re: Server-side image map in CForms ?
oceatoon wrote: I am not at all from the GIS , and project Geoid seems to be just that, If I'm not mistaken it allows to plug into existing ArcIMS and others with Cocoon. I'm really looking to find a Map system I can integrate directly into my(and others) project. I really think a simple Mapping system has it's place within many websites especially connected with a data generation system like cocoon which seems to be the main idea behind GEOID, I will need to have an appropriate Graphic Map to associate to my connector, is there such a module? Well, let me clarify that geographic data are inherently big, you would most probably need a map-server to produce them for client consumption. Think of DBMSs: you need one but for the most trivial tabular data... for geographic data it's the same: you need a map-server (MapServer, GeoServer, ArcIMS, etc.) but for the most trivial geographic data. If nothing really exist I will be glad to start a vulgarised Map solution within Geoid. MapBuilder is quite a good solution, but 100% JS which I like but people don't allways have. do you know any other ones by any chance ? IIUC, you're thinking of a map client, aren't you ? At the moment I'm working on a generalized map client based on Cocoon, with three levels of functionality: 1) Base (most accessible, even for impaired people): server-side image maps with no JavaScript and no frames on the client. 2) Intermediate: server-side images with client-side JavaScript and frames. 3) Advanced: SVG. I've started by building some JavaScript classes (they can be used both on the client or on the server) and some CForms widgets... don't know wether my effort will go into Geoid though. BTW, MapBuilder works great, but you need WMS servers to make it work, don't forget it. If what you have to do is just position points, use DIVs live happy after that :) well yes that could a solution but quite limited. It would be good to go on adding functionalities once the mapping system is done, and div solutions will probably be blocking after that. Most web-based GIS apps don't need SVG: just some background data and clickable points (when clicked some data are shown) will do for most applications. Sure, SVG adds local pan/zoom and a lot of nice graphic effects, but carefully consider the potential problems with plugins before going for it. Don't get me wrong, I like SVG, but forcing user to install a plug-in would be an unpopular option. The idea would be to have clickable jpegs generated from svg and later when fully supported directly svg. Do you think GML is something to look into or is it a huge load and not necessary ? could it make my development easier ? Wait, there are map-servers that already generate SVG for you (i.e. MapViewer for Oracle) and established standard (SLD) for styling GML... don't re-invent the wheel ;) BTW, the SVG to JPEG rendering is pretty slow. Regards, P.S. Would you please start a thread on the Geoid list ? I think that would be the best place for talking about such issues. Luca Morandini www.lucamorandini.it
Re: ImageMap widget for CForms
Vadim Gritsenko wrote: Luca Morandini wrote: Thanks for the suggestion, I'll work on it. MapEvent will allow to use event.x, event.y or some such instead of 'cocoon.request.getParameter(map.y)', which is eww ;-) Understood: I'll amend the ImageMap widget early next week. Regards, Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
oceatoon wrote: We are having an intern work on this from tuesday so I'm setting up the guidelines, maybe we can cooperate on this? Sure we can. Shall I remember you our little Geoid project ( http://geoid.cocoondev.org/ ) ? I was thinking of doing this in SVG having dynamic positionning functionalities and easy graphic separation, and offcourse have points url-clickable on the map. If what you have to do is just position points, use DIVs live happy after that :) Don't get me wrong, I like SVG, but forcing user to install a plug-in would be an unpopular option. Regards, Luca Morandini www.lucamorandini.it
Re: [OT] Re: Server-side image map in CForms ?
Jorg Heymans wrote: Luca Morandini wrote: Don't get me wrong, I like SVG, but forcing user to install a plug-in would be an unpopular option. With Firefox nightlies having native SVG support, this option is not so unpopular anymore as it was say a few months ago. Yes, I know :) ... but IE still lacks it :( Well, rumors had that IE7 will sport native SVG support... but 'til that day I won't sacrifice 80% or so of my prospective users for SVG (on an Intranet it may be different though). Regards, Luca Morandini www.lucamorandini.it
ImageMap widget for CForms
Folks,
I made my first Cocoon widget :)
It isn't at all that hard, though I managed to waste time by trying to
subclass my widget from the Action class :(
Anyway, here's how to use it:
1) Definition document:
fd:imagemap id=map
fd:hint
i18n:textrefresh.hint.mapZoomin/i18n:text
/fd:hint
fd:on-action
javascriptonClickMap();/javascript
/fd:on-action
/fd:imagemap
2) Template document:
ft:widget id=map
fi:styling border=2/
/ft:widget
3) No binding required.
4) Flow:
function onClickMap () {
var x= Number(cocoon.request.getParameter(map.x));
var y= Number(cocoon.request.getParameter(map.y));
var uri;
uri= zoomed map uri/;
frm.getWidget().lookupWidget(map).setImageSource(uri);
}
So, the image map's URI is set by setImageSource(); when the user clicks
on it the onClickMap (or whatever is specified in on-action) flowscript
is called, which gets mouse coordinates from request parameters.
Simple, isn't it ?
If someone would like some features to be added, this is the right time
to speak... otherwise I'll make a zipball and donate the thing.
BTW, I'd like mouse coordinates to be retrieved by querying the map
widget rather than the request object... anyone knows a simple way to do
this from within the widget class (subclass of AbstractWidget) ?
Regards,
Luca Morandini
www.lucamorandini.it
Server-side image map in CForms ?
Folks, I need a server-side image map with Cocoon Forms. AFAIK there's no such a widget in Cocoon 2.1.7... hence, my question: is there someone already working on it or should I start from scratch ? Regards, P.S. I will contribute the results of my efforts... provided they're good enough, of course. Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote: Can you elaborate on server-side image map? Does this mean the areas would be computed on the server? Hmm... it surely makes sense, but I don't need this feature; hence, I'd rather pass only the relevant mouse coordinates to the event handler. BTW, I guess an output field with picture styling type (I've already seen a post with some code) could be another nice addition to Forms... nothing to do with server-side images though, just an output field that happens to have a graphic content: your take ? Regards, Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Jorg Heymans wrote: What is your server-side image map supposed to do ? Very simple stuff: 1) An user clicks on the image. 2) The form is sent to the server together with mouse coordinates. 3) The relevant action is called (mouse coordinates should be sent to the action somehow). Hmm... I think this image-map widget should be a kind of action widget, since the form is sent to the server when widget is clicked upon. Regards, Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Jorg Heymans wrote: I have been doing waaay too much GIS stuff ... I saw something about map and straight away thought you meant geo-map :-) Well, sort of... I need this widget for GIS stuff. A recent law in Italy forces web-sites belonging to state agencies (ministries, local government offices, state-owned companies, etc.), to allow impaired people accessing their contents. The guidelines are very strict (not to say narrow-minded): no JavaScript, no frames, only strict-XHTML, etc. Hence, I'd like to meet this challenge with our beloved Cocoon (and learn something about CForms along the way). Anyway, this stuff won't fit well into Geoid, since server-side images may be useful for other application domains as well. Regards, Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
Hmm... I think this image-map widget should be a kind of action
widget, since the form is sent to the server when widget is clicked upon.
You already have it :-)
Use an action with styling type=image. When the image is clicked,
the action's event listeners are triggered, and you can read the click
coordinates using the {action-name}.x and {action-name}.y request
parameters.
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
That is possible (via the setValue method) in output widgets, but you
can't trigger an action with this kind of widget... or did I miss
something ?
Regards,
Luca Morandini
www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote: Luca Morandini wrote: Jorg Heymans wrote: Hmm... can't multi-channelling techniques apply here also? e.g. if the browser is a voice browser for visually impaired, use a special dedicated stylesheet. Ahem... have you ever tried to describe a geographic map using VoiceXML ;) ? Seriosuly now, I'll heavily use the multi-channel capability of Cocoon for textual pages... but maps are different. For maps I'm not (obviously) targeting blind people, rather, I'm targeting people with *some* coordination problems and *some* sighting problems, like the old folks (hmm... I'm pushing 40 this year, I should be careful with this old label). Yes, according to an Eurostat estimate (see [1]) some 17% of people over 55 are Internet users, and their numbers will steadily increase: making maps easily accessibile to them is a sensible move, marketing-wise. The map-viewing platform I envisage will be very simple and work even with very big fonts and buttons, and it should do this without JavaScript, frames and mouse (I mean, mouse is considered an optional, useful, but not necessary). Regards, [1] http://epp.eurostat.cec.eu.int/cache/ITY_OFFPUB/KS-NP-05-018/EN/KS-NP-05-018-EN.PDF Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
Yes you can, as the image src is in the form template. Of course you
have to use a dynamic template (e.g. JXTG):
ft:action id=map
fi:styling type=image src=images/${image_name}.jpg/
/ft:action
Sure, but I'd rather avoid using dynamic templates for otherwise static
forms... morever, setting the image source from a action-handler flow
script would be more elegant.
Regards,
Luca Morandini
www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
morever, setting the image source from a action-handler flow script
would be more elegant.
That's exactly what the ${image_name} is, e.g.:
form.showForm(my-form-pipeline, {image_name : map- + areaId});
Sure, you set the value and pass that parameter from within flow, but to
understand its use you should take a look at the form template as
well... while the setValue() is completely understandable from the flow
code.
I mean, nothing really substantial here... only I'd like it to be done
in more straightforward way: suppose there's a developer willing to add
a dynamic image using CForms, which way he would find easier to understand ?
Regards,
Luca Morandini
www.lucamorandini.it
Endless loop in CForms when there's no submit widget: bug ?
Folks, I've made a form without a submit widget, which resulted (after a while) in a StackOverflowError... apparently the flow engine keep auto-submitting the form over and over: is this a bug or is accepted behaviour ? Regards, Luca Morandini www.lucamorandini.it
Re: Endless loop in CForms when there's no submit widget: bug ?
Luca Morandini wrote: I've made a form without a submit widget, which resulted (after a while) in a StackOverflowError... apparently the flow engine keep auto-submitting the form over and over: is this a bug or is accepted behaviour ? Hmm... seems the problem is more complex than just the absence of a submit widget, I should investigate the matter further. BTW, I'm using Cocoon 2.1.7 Regards, Luca Morandini www.lucamorandini.it
Re: Endless loop in CForms when there's no submit widget: bug ?
Sylvain Wallez wrote:
Hmm... strange. A number of form samples have no explicit submit widget
and (seem to) work correctly.
Ahem... ashamed to say my flowscript auto-loaded itself (I was
cuttingpasting way too fast to notice), resulting in a really weird
behaviour: by chance it worked when I added the submit widget and I
jumped to the wrong conclusion :(
Funny to notice sometimes it worked though :|
So, if you want see something really weird, try writing a flowscript
like this (name it main.js):
cocoon.load(resource://org/apache/cocoon/forms/flow/javascript/Form.js);
cocoon.load(flow/main.js); // It loads itself !
function showMap () {
var frm;
frm= new Form(cocoon:/fd-themes-legend.xml);
frm.showForm(form-themes-legend.html);
cocoon.sendPage(/message.html, null);
}
Sorry for wasting your time, Sylvian :(
Luca Morandini
www.lucamorandini.it
Re: CocoonForge?
Mark Leicester wrote: With the development of real blocks well underway, I was wondering if anyone had given any thought to a CocoonForge? Something along the lines of http://mamboforge.net/ perhaps? Well, the charming guys at CocoonDev [1] are already doing that, aren't they ? Regards, [1] http://www.cocoondev.org Luca Morandini www.lucamorandini.it
Re: [RT] Who may follow a retired Anteater?
Ugo Cei wrote: Il giorno 09/mar/05, alle 08:01, Bertrand Delacretaz ha scritto: Le 9 mars 05, à 00:11, Alfred Nathaniel a écrit : ...Does anybody have practical experience with Canoo WebTest which speaks for/against this product? Or any other product? Or is nobody testing?.. I used WebTest for a while, but in the end I found that writing tests in XML is way too verbose and clumsy. I had the same experience... later on I moved to HTMLUnit ([1]), which offers a lot: 1) Different browsers emulation. 2) Retrieving of XML pages as DOM Documents (org.w3c.dom.Document) for further processing by Java. 3) Being based on JUnit, the green bar works in Eclipse for HTMLUnit as well. 4) Calling of Javascript functions embedded in the HTLM page from the Java test driver. 5) Availability of Jelly ([2]) as scripting language (well, I opted for Java, so I cannot comment on this feature). But, best of all, it lets you re-create the whole browser environment within your Java test driver, which, IMO, is better suited for functional testing than the request/response paradigm of HTTPUnit. I was sceptical about using Java for testing, but the Java/JUnit environment in Eclipse gave me the quick feeling of a scripting language. Regards, [1] http://htmlunit.sourceforge.net/ [2] http://jakarta.apache.org/commons/jelly/ Luca Morandini www.lucamorandini.it
Re: review of sitemap component documentation
David Crossley wrote: Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html The next task is to review the table to ensure that all entries have been added for sitemap components. At a glance I can see that Ant generator from scratchpad is missing (org.apache.cocoon.ant.AntBuildGenerator). Regards, P.S. Thanks a lot, this is something that goes a long way towards narrowing the code/doc divide in Cocoon. --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
[FLOW] Sometimes variables initialization fails when they are declared and iniitialized in the same statement
in a (Javascript) flow function of mine, when I write: var parser; parser= cocoon.getComponent(DOMParser.ROLE); everything works fine all the time... but, when I write: var parser= cocoon.getComponent(DOMParser.ROLE); sometimes the parser variable is null ! This failed initialization of a variable happens when the same flow function is called many times in a short amount of time. Is it a known bug or am I missing something ? BTW, the same happens with other type of objects, like: var os= new java.io.ByteArrayOutputStream(); Regards, P.S. I'm using Cocoon 2.1.5 and, yes, I release parser after it has been used. --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Re: Flowscript bug???
Ralph Goers wrote: FWIW, we had trouble getting Flowscript to work with Weblogic because weblogic had its own version of Rhino. Ouch ! Did you succeed in the end ? Regards, --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Re: Flowscript bug???
Vadim Gritsenko wrote: Are you talking with me or with yourself? :) To myself, but loudly... so you could step in if I said something stupid ;) Regards, --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Re: Flowscript bug???
Vadim Gritsenko wrote: Problem is that currently Flow session scope is not serializable. WebLogic requires session attributes to be serializable (required for clustering). Vadim, could you please elaborate more on this ? I mean, is flow unusable on WebLogic ? Or just one has to switch the clustering off for the Cocoon webapp ? Regards, --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Re: Flowscript bug???
Vadim Gritsenko wrote: Luca Morandini wrote: Vadim Gritsenko wrote: Problem is that currently Flow session scope is not serializable. WebLogic requires session attributes to be serializable (required for clustering). I mean, is flow unusable on WebLogic ? Flow requires session scope only when you use global variables in the flow: In other words, global variables cannot be used in Flow when Cocoon runs within WebLogic, is that so ? On the other hand, session attributes can be stored and retrieved from Flow even under WebLogic, hence alleviating the need for global variables in Flow, right ? You'll have to hit weblogic docs to answer this one. Alternatively, you can provide a patch to make scope serializable :) Hmmm... doesn't look like a no-brainer, does it ? ;) BTW: thanks :) Best regards, --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Bug in 2.1.5 input modules ?
In 2.1.3, this used to work:
map:parameter name=image-path
value={global:app-path}\resources\images\/
While in 2.1.5 it gives:
Message: Failed to load sitemap from
file:/c:/web/noria/noriadev215/sitemap.xmap
Description: org.apache.cocoon.ProcessingException: Failed to load
sitemap from file:/c:/web/noria/noriadev215/sitemap.xmap:
org.apache.avalon.framework.configuration.ConfigurationException: Error
while creating node 'transform' at
file:/c:/web/noria/noriadev215/sitemap.xmap:628:49
...
cause
java.lang.StringIndexOutOfBoundsException: String index out of range: 18
request-uri
/cocoon215/noriadev/refresh-map-locate.pdf
full exception chain stacktrace
Original Exception:
org.apache.avalon.framework.configuration.ConfigurationException: Error
while creating node 'transform' at
file:/c:/web/noria/noriadev215/sitemap.xmap:628:49
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodesList(AbstractParentProcessingNodeBuilder.java:128)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNodeBuilder.buildChildNodes(AbstractParentProcessingNodeBuilder.java:136)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNodeBuilder.buildNode(MatchNodeBuilder.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.buildNode(PipelineNodeBuilder.java:113)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.buildNode(PipelinesNodeBuilder.java:65)
at
...
Shall I insert this in Bugzilla ?
Regards,
---
Luca Morandini
[EMAIL PROTECTED]
http://www.lucamorandini.it
--- -
