Re: Not caching pages with continuations
Vadim Gritsenko wrote: Sylvain Wallez wrote: If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Not true :) You can easily have cached cforms pages if using stateless cforms with sendForm() and handleForm() js methods. Most popular use cases for stateless forms include search forms, login forms, contact forms which are part of high traffic (and for this reason, cached) pages. Good point! So no cache headers should be set in sendFormAndWait(), aka showForm() where a continuation is created, hence preventing caching. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Not caching pages with continuations (was:...where is 304?)
Ard Schrijvers wrote: snip/ This is actually almost the same hack we used, but instead of a transformer a selector, and if some value set in flowscript, an action to set headers. Because we are outsourcing/other parties using our best practices, and I did not want them to have to think about setting things in flowscript like sessions and values to indicate caching headers, I chose to put it in the black box transformer, which handles it. Of course, also kind of a hack, because users aren't really aware of it (certainly because i did not want another sax transformer, so I did add it to the StripNameSpaceTransformer which is by default used by us in front of the serializer. But it does more then its name suggests, and therefor, it is hacky ofcourse. But...at least nobody has to think about it :-) ). I wondered if there was a solid nonhacky solution to the issue If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Also, for other flowscripts there could be a parameter on the map:flow instruction stating the flowscript engine has to always set the no-cache headers. Sylvain -- Sylvain Wallez - http://bluxte.net
HTML mails (was Re: Building changes into the top level sitemap)
Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) snip/ Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages (and also increases the mail's size). Thanks, Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Improved matching selecting
Mark Lundquist wrote: Hi gang, snip/ So... WDYAT? +1. Lots of good ideas! I even think it may be implemented in a backwards compatible way, by switching between the two approaches depending on the existence of a pattern attribute, and thus go in a 2.2.x release. Sylvain -- Sylvain Wallez - http://bluxte.net
File upload widget on ajaxian.com
The file upload widget made it on Ajaxian.com, the main news portal of all things Ajax! http://ajaxian.com/archives/dojo-file-upload-progress-bar-widget Kudos to Jeremy! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Rhino (once more)
Jeremy Quinn wrote:
On 16 Nov 2006, at 09:40, Sylvain Wallez wrote:
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but source compatible (see LocationTrackingDebugger).
Loosing the LocationTrackingDebugger would be a real loss :-{}
Oh don't worry, it won't be lost, definitely not! It's just that
switching the Rhino version is not just about dropping the new jar, but
requires to recompile Cocoon's source code.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Rhino (once more)
Reinhard Poetz wrote: Carsten Ziegeler wrote: Nice, to avoid all legal problems - what would it take to use this version in 2.1.x? a vote ;-) IIRC Rhino 1.6 is binary compatible to the version we use in 2.1 Not totally. The exception and stacktrace handling code is a bit different, but source compatible (see LocationTrackingDebugger). I know that this might introduce some incompatibilities, but perhaps we can live with them? not sure, see http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109528520325331w=2 I remember some users using these features. AFAIK these features were never explicitely mentioned in our docs, so not official, and thus certainly not widely used. It may be worth it to be legally clean at the price of very few compatibility problems. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Rhino (once more)
Carsten Ziegeler wrote: Sylvain Wallez wrote: AFAIK these features were never explicitely mentioned in our docs, so not official, and thus certainly not widely used. It may be worth it to be legally clean at the price of very few compatibility problems. Yepp, I think being legally clean is more important here. If we don't go this way, we have to find a way to support the old version without *ever* going into legal problems (e.g. by separating flow from the core in 2.1.x and make it available separately etc.) This would cause pain to *all* Cocoon users. Exactly! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] Use latest rhino in 2.1.x
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that version in 2.1.x. Unfortunately this
creates minor incompatibilites and might infect people using specific
functions in flowscript. On the other hand, if we insist on using the
which are?
The special exception constructs to catch continuation suspend and
restore, that can be used to cleanup or restore non-suspendable resources.
try {
// code...
} catch(break) {
// continuation suspended
} catch(continue) {
// continuation restored
}
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [Vote] Use latest rhino in 2.1.x
Carsten Ziegeler wrote: Please cast your votes for using latest rhino in 2.1.x. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/coc
Jeremy Quinn wrote: On 12 Nov 2006, at 23:41, Antonio Gallardo wrote: Hi Jeremy, Nice work. Please look into the small issues below: snip/ We use 4 spaces for tabs. Ugh! I hate the 4 spaces rule ;) Encoding typo? Please review your subversion settings. I think it was a UTF-8 Byte Order Mark, removed . I had also forgotten to make the Upload Form sample use Ajax, doh ;) One thing I forgot to mention in my notes for these changes is the rendering pipeline . The pipeline for rendering JXMacro-based forms now has to adapt itself to whichever Dojo Transport is being used, as the BrowserUpdate response has to be different for each one : . . . map:select type=ajax-request map:when test=true map:select type=request-parameter map:parameter name=parameter-name value=dojo.transport/ map:when test=iframe map:transform src=resource://org/apache/cocoon/forms/resources/IframeTransport-bu-styling.xsl/ map:serialize type=xhtml/!-- this is REALLY important -- /map:when map:otherwise map:serialize type=xml/ /map:otherwise /map:select /map:when . . . If iFrameIOTransport is being used, then the BU response needs to be different XML and have a different serializer. Any suggestions for reducing this complexity ? Maybe the BrowserUpdateTransformer could differentiate depending on the Transport, to save having the extra XSLT Transformation? Sylvain suggested a BrowserUpdateSerializer, that could switch between XML and XHTML depending on the Transport. Yup, the idea of hard-coding it into a serializer is to avoid requiring people to copy/paste this (complex) snippet which is required plumbing they should normally neither modify nor care about. Or is there a way to define this as a system-provided virtual serializer? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/coc
Jeremy Quinn wrote: On 14 Nov 2006, at 12:46, Sylvain Wallez wrote: Jeremy Quinn wrote: snip/ Sylvain suggested a BrowserUpdateSerializer, that could switch between XML and XHTML depending on the Transport. Yup, the idea of hard-coding it into a serializer is to avoid requiring people to copy/paste this (complex) snippet which is required plumbing they should normally neither modify nor care about. Or is there a way to define this as a system-provided virtual serializer? Hi Sylvain :) Eh, I'm still there :-) Do we have virtual pipeline components yet ? I guess so in 2.2... I do not know much about them . AFAIU resources can only be called from the sitemap in which they exist . virtual pipeline components are a concept similar to resources ? Yes, with two main differences: - they are typed (resources can be either generator, transformer or generator) - they are visible in subsitemaps, as every other component, whereas resources are not. It looks like I will be adding a system-level sitemap for CForms, to handle stuff like upload progress status . my plan is to have it compiled into the CForms jar, but I have never tried running a sitemap from that type of source before . has anyone tried to mount a sitemap from (eg.) resource://org/apache/cocoon/forms/resources/system/sitemap.xmap before ? Yep! IIRC it works fine! The only issue is relative paths, which are of course resolved relatively to the location in the classpath. But that is actually useful is an entire sub-application is packaged in a jar. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/coc
Daniel Fagerstrom wrote We had virtual sitemap components one and a half year ago. But since then a lot have happened in the system so I find it hard to believe that they still work. If someone is interested enough I could help fixing them. But I lost interest in them as I think that the concept of virtual sitemap components is flawed. I wrote a little bit about what I would like instead in http://marc.theaimsgroup.com/?t=11617765091r=1w=2. That would be nice. It actually looks like the pipeline services we discussed 4 years ago [1]. Wow, time flies!!! Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103787313407324w=2 -- Sylvain Wallez - http://bluxte.net
Re: Release roadmap
Joerg Heinicke wrote: On 27.10.2006 20:57, Carsten Ziegeler wrote: We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind... +1. I understand people's desire to have 2.2 out (finally!) but the final user testing phase should not be neglected. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: CForms: Upload Repeater
Jeremy Quinn wrote: Hi All I am doing some work on CForms. I have now got AJAX-type submission via IframeIO in Dojo working for forms that have file-upload controls in them. I am aiming to get progress-bars working for Upload Widgets in Cocoon . (there is a ProgressBarWidget in the new Dojo 0.4.0 :-) ) But meanwhile, I am trying to get some sort of Upload Repeater working and I have several problems .. The usecase is that a user may add a number of file-upload controls to a repeater, select files for them, then submit them all in one go. One problem is, that if you have file-upload controls on a form, that have a file selected, they get submitted when you click on the repeater's add button, as these action-events submit the whole form. I would like to change this behaviour but do not know if this will break some other usecases. While working on the CForms Widget, to get IframeIO working, I switched to using Dojo's built-in form preparation code (instead of cocoon.forms.buildQueryString). Dojo has equivalent method that can take a filter function as an argument, meaning we could have a special filter to be used when submitting an action-event. Can you think of any usecases where sending only the minimal button-event would break existing CForms functionality ? IIRC Dojo's built-in function doesn't allow to specify what input triggered the form submit, which is absolutely needed for CForms to properly handle fd:submits and fd:actions. Now I haven't looked at Dojo for quite some time and it may allow it now. Sylvain -- Sylvain Wallez - http://bluxte.net
Cocoon on projects.apache.org
Hi all, Looking at http://projects.apache.org/indexes/pmc_cocoon.html people can see that Cocoon is about... databases!!! Seems like the projects website only consider the first category whereas Cocoon has many of them!! http://svn.apache.org/viewvc/cocoon/site/site/doap.rdf?revision=379260view=markup So, should we restrict ourselves to a single category (rather limiting for Cocoon), or fix project.a.o to allow multiple categories? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: AW: RFC: CForms + Dojo: the way forward
Lars Trieloff wrote: Hi Christopher, as the individual JS files are rather small, the most costly part is requesting them from the web server, not downloading them. With an aggregated file, there is only one single request. I agree that it does not make sense to create a JS file per form because that would result in redundant downloads, so the only possibility is to have it configured at build time. What about creating a src/main/js directory where all contained *.js files will be aggregated into a single $projectname.js file? That would create a central location for all JS files in the system, that would go against the modularization in blocks. What we actually need is a way for each block to expose its JS files (we already have that with the _cocoon/resources/*/** matcher) and a dojo dependency file. The aggregation of all these files actually makes the Dojo profile needed by the application [1] and can be directed to the Dojo compressor. This process can happen either at build-time (but requires an additional step for users) or at runtime with the DojoReader you suggested, whose first run would be quite costly but can aggressively cache its result. Sylvain [1] http://archive.dojotoolkit.org/nightly/buildscripts/profiles/ -- Sylvain Wallez - http://bluxte.net
Re: Resolving Cocoon Dependencies with Ivy
Joerg Heinicke wrote: If you are interested, I could add the Ivy build system into tools/build... As it's still experimental IIUC, I'd prefer to have it somewhere under http://svn.apache.org/repos/asf/cocoon/whiteboard/ So much I dislike Maven, shouldn't we be honest and say there is no real chance of switching back to an Ant-based build system? Jean-Baptiste can probably live luckily without it and does not need to put more effort in it. And it will avoid some frustrations at the end. +1 to everything. Better be honest than hypocritical. For people interested in it, everything is at http://svn.caraldi.com/trunk/share/cocoon-ivy-build/ Sylvain -- Sylvain Wallez - http://bluxte.net
[RT] User poll to find unused components
Hi all, Yesterday we had an interesting discussion at the hackathon about how to identify unused components so as to remove/deprecate them in order to cleanup the code base. We cannot consider the last commit date on a component as the measure of its usefulness, as many components are simply finished, i.e. just work and don't need more work, but are used daily by most users (e.g. the HTML serializer). So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution. WDYT? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] User poll to find unused components
Geert Josten wrote: +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. How about letting users classifying blocks as used: a) always, b) often (most of the time), c) rarely (only once or twice)? (and asking them how many webapps they have build using Cocoon) Sounds more informative to me than a top 5.. Sure. Defining the top 10 or top 5 is then the result of aggregating and compiling all information provided by users. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) snip/ So please cast your votes! +1 But Lars will have to pay a beer to all people voting +1... or drink a beer for each of them :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [2.2] Sitemap reloading
Carsten Ziegeler wrote: As some of you have noticed, by default the sitemap is not reloaded after a change. This is not a bug but a feature :) Cocoon is by default starting in mode prod which disables reloading. So you should specify the mode dev e.g. via a system property on startup: -Dorg.apache.cocoon.mode=dev Wow, although very small, this is probably the most important change in Cocoon's behaviour since 2.0 was out! IMO that requires a vote. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [2.2] Sitemap reloading
Carsten Ziegeler wrote: Sylvain Wallez wrote Wow, although very small, this is probably the most important change in Cocoon's behaviour since 2.0 was out! IMO that requires a vote. We already voted on that! Doh. Missed that :-( Ok then! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: CForms: on-action handling
Simone Gianni wrote: Hi Vadim, I can't remember, but without validating before executing it's possible to make buttons like Fill with default values or Use the same address for delivery which could not be possible if the form gets validated before performing the action. Wasn't there a validate=true|false attribute on actions? Yup, you're right. Actions can change the contents of the form, and thus validation occurs after actions are run. As for the validate=true|false, it is meant to allow actions that should exit form.show() without even trying to validate. This for actions such as cancel. Vadim Gritsenko wrote: Hi All, Just recently noticed that on-action events are fired before form is validated :) Can anybody recall the reason why this was done? Any reason why not do it after validation? Since most of the time actions will manipulate forms content, it makes sense to validate complete form first, or so it seems. WDYT? -- Sylvain Wallez - http://bluxte.net
Maven dictatorship and software parasitism (was Re: Maven info wanted)
Reinhard Poetz wrote: Sylvain Wallez wrote: Reinhard Poetz wrote: snip/ We have invested a lot of time into making trunk build with M2. And don't forget that it's much more than just compiling the thing. We have two archetypes, one deployment plugin, the documentation which is exported using Maven, a working integration build, reports and certainly much more. Also don't forget that releasing a Cocoon artifact has become very simple. And one last point: If you build Cocoon using some different build system I think that we cannot forbear providing Maven 2 metadata files (pom.xml) because many developers will ask for them. I'd like to react on that last point: a POM is just XML. And if there's a place where we know that XML is an interchange format, this is for sure here in Cocoon-land. And we know there are plenty of solutions to generate XML files in whatever format we want from whatever data source we have. There is a good thing in Maven: the repository, where people can pick up dependencies (well, when it works) rather than copying them in their own source control repository. This is not good for a large in-house project where you want to control and version everything, but a good way for OSS projects to lighten their development process. I can't follow your argumentation here. What are you missing? Sorry if this wasn't clear. I'm not missing anything, but in a large consumer project you need to carefully know and control what's used to build your software. Having artifacts downloaded from a remote public server doesn't allow for repeatable and controlled builds. Even more when the build/dependency management system itself self-updates from the remote repository. So although a remote repository is really convenient when you are developping (provided that the repository is available and that automatic updates of the build system don't get your team stuck for more that one day as happened to me), it's definitely not something good when a repeatable and mastered build is needed. Now the problem with Maven is that, because people are interested in that good thing, they feel obliged to use the tool where that repository and the associated file format was born. Why should that be a requirement? Why couldn't the POM be used/created by other tools as well? Who or what prevents you from doing so? Absolutely nothing! And that's the whole point: people are using Maven-the-Tool because of Maven-the-Repository. Granted, the repository would not have existed without the tool (and the effort of all repository maintainers). But although Maven-the-Repo alleviated some pains and brought some new features, Maven-the-Tool brought new pains. And since the repository is just data, there is room for other tools to use and feed it. I don't remember if alternatives existed when Cocoon's move to Maven started and don't want to rewrite history nor Cocoon's build system if people are happy with it, but the point is that there are alternatives now. With its POM and repository, Maven managed to create an amazing dictatorship on the entire OSS Java community. That buggy tool (because yes, it is buggy) with no clear documentation is becoming a vital part of many projects. So vital actually, that it has endangered and damaged some of them. If you're refering to Cocoon as a victim damaged by Maven, I'm not sure that this conclusion is fair. As Daniel pointed out, I think that we did a lot to damage ourselves by having too many dependencies across our code base. I disagree: this is not the main cause of damage. Although the current effort is more than welcome, the golden days of Cocoon where when we had myriads of dependencies and an XSL-generated Ant build file. There are many concurring factors, both internal and external, that can explain the project slowdown. A discussion for the Hackathon? snip/ Converting an Ant build to an Ant+Ivy build merely means writing an ivy.xml (or pom.xml) expressing the dependencies and changing the classpath instructions so that they're build from the dependencies artifacts that Ivy will download, rather than from e.g. lib/*.jar. And writing Ant tasks that mimic an artifact, deploy and release things are not rocket science. no, it's not but all those tedious things have to be done and I want to warn you not to underestimate the work. I won't stop any of you to fix what *you* consider as broken but don't expect that I will get excited about rewritting many things (poms, archetypes, deployer, documentation) or mimicing feautres that Maven provides out of the box or via its plugins (many reports, releasing artifacts, etc.). I'm not saying that Cocoon's build *should* be rewritten. Just that Maven, because it's a kitchen-sink that is meant to provide everything and even more actually turned into a dictatorship. Had it been flawless, we could have lived with it. Now it isn't, and the dictatorship actually sucked energy from the project. Makes
Re: Maven dictatorship and software parasitism (was Re: Maven info wanted)
Carsten Ziegeler wrote: We (and I know others as well) are using Cocoon 2.2 with Maven in development for several projects without any major problems. All the complicated build stuff is hidden, people just create a project with our web archetype and develop their stuff. Works perfectly. (And yes, we are using a company repository) Well, I will continue being the bad guy today... This is actually one of the areas where there are some similarities between Cocoon and Maven. Its developers know it by heart and know how to use it, what to use and what not to use. And they not always understand that people not actively developing the project aren't comfortable with its magic. Note that I'm not pointing fingers to anybody here, being myself a developer for Cocoon, but realizing this matter of fact by trying to be a Maven user! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Maven info wanted
hepabolu wrote: snip/ At the least: send me a list of your favorite URLs (and please hold off the link to the Maven homepage) and I'll compile a Daisy page with links. Hmm... not Cocoon-specific, but I'd like to suggest http://bluxte.net/blog/2006-09/17-52-51.html and all its sequels (related blog posts and comments) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Free for use: SaveFilesTransformer
Geert Josten wrote: Hi all, Available on wiki: http://wiki.apache.org/cocoon/SaveFilesTransformer It might be that someone else already wrote a Transformer like this one. It is derived from the SourceWritingTransformer (yet simplified) and has one important benefit over it: it can take a src attribute that can be used to capture also binary streams and save them to disk. Comments are welcome.. Er... why a brand new transformer when you could have provided a patch adding support for the src attribute in SourceWritingTransformer??? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GT2006] Already 50 attendees.. Early bird ends tomorrow!
Sylvain Wallez wrote: I promise a beer to whom can guess the smart algorithm behind head colors on the conference chairs picture that gave me green hairs [1] ;-) People that wrote or saw the code are not elegible for the beer! [1] http://bluxte.net/blog/2006-09/11-06-41.html The algorithm was changed overnight! Ard and Arjé now have green hair as well, and Maurizio has pigtails Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GT2006] Already 50 attendees.. Early bird ends tomorrow!
Jorg Heymans wrote: On 12 Sep 2006, at 14:56, Jasha Joachimsthal wrote: but but but IRL Ard is bald while Arje is not... what if you factor in the probability that Arjé IRL is wearing a wig ? Would it make things add up ? confused as well (no I still haven't looked at the code). My guess is that the hippo folks are having a laugh at all this and throw a dice every evening to see who will be the next colored head ! And I have a big laugh as well when reading all the assumptions, deductions and interrogation that started my self-questioning about my green hair :-D Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GT2006] Already 50 attendees.. Early bird ends tomorrow!
Arje Cahn wrote: Hi all, The Cocoon GetTogether has just hit it's 50th attendee! Be sure to get your seat before the EARLY BIRD registration ends tomorrow. Early bird fee is only 99 EUR and includes Hackaton fees! www.cocoongt.org That's it for now! I promise a beer to whom can guess the smart algorithm behind head colors on the conference chairs picture that gave me green hairs [1] ;-) People that wrote or saw the code are not elegible for the beer! Sylvain [1] http://bluxte.net/blog/2006-09/11-06-41.html -- Sylvain Wallez - http://bluxte.net
Re: [GT2006] Already 50 attendees.. Early bird ends tomorrow!
Andrew Stevens wrote: From: Sylvain Wallez [EMAIL PROTECTED] Date: Mon, 11 Sep 2006 17:01:42 +0200 I promise a beer to whom can guess the smart algorithm behind head colors on the conference chairs picture that gave me green hairs [1] ;-) People that wrote or saw the code are not elegible for the beer! Sylvain [1] http://bluxte.net/blog/2006-09/11-06-41.html -- Sylvain Wallez - http://bluxte.net Well, my first guess (without looking at the picture) would have been to XOR the ascii values of the letters in each person's name, and use the resulting value as a lookup into a table of web-safe colours. But having seen the picture I doubt that's the case as it'd give much more variation. So my next guess, given it makes a point of stating how many countries the attendees cover, was that the colour depended on the country corresponding to the domain in the email address they registered with. However, I think I count 9 or 10 distinct colours and it only says 8 countries. I suppose it could still be down to the top-level domain, though I'd have thought the ..com/.net/.org split would be enough in that case to not have such a large proportion of one colour. Doesn't work: JB (Jean-Baptiste), Vincent and I were all registered from the same PC. Along the same lines, perhaps it's determined by the language used to go through the paypal pages when registering? Ditto. Or, thinking a bit more technically rather than socially, perhaps it's determined by searching the mailing list archives and/or CVS logs to see how many posts/commits the person has made over the last year, and the more active they were the stronger the colour? Uh! That means Stefano is behind this system, with a crawler that spits RDF out of all the electronic datasources ;-) Or maybe it's determined by the number of pages returned by a google search of the person's name plus cocoon, as an estimation of their popularity/activity within the community? 168000 hits! Wow! But Carsten has 202000! It could be done randomly, though, just to give us something to wonder about - 80% get the default colour, the remaining 20% get the next colour from some other list. But probably it's none of these, though at least now you've got a few more ideas for next year's picture ;-) It can also be a combination of the information input in the registration screen (checkboxes checked, number of projects, etc). The more important question, however, is why didn't Matthias want to sit next to Judith? What did she do to offend him? Hmm... Or the other way around: is there a special attraction between here and JB? Hmm... we'll have to sort that out in Amsterdam!!! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Ajax-block: what's the purpose of node.xml?
Carsten Ziegeler wrote: The importNode() function in the insertion.js of our ajax block has a text for node.xml - what does this actually check? It checks a IE-specific feature that allows to get the representation of a node and its children as serialized XML document (as a String). Now, it seems that in some cases this check evaluates to true which results in buggy element nodes which are unusable in IE. That was precisely meant for IE. What version are you using? Can we remove this check? IIRC IE had some issues with namespaces in the importNode function, but I also see that this function has namespace-aware DOM function commented out. So I don't know... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] Java 5 as minimum JDK requirement
Joerg Heinicke wrote: On 17.08.2006 01:29, Torsten Curdt wrote: Is it appropriate to vote according to your employer's needs. IMO PMC members should vote in the best interest of the project - not in the best interest of their employers. I just want to point out that I did not vote according to [my] employer's needs, but what IMHO is better for the project. Though we do not yet use Java 5, there is probably no problem to switch to it. The example I made with the bank was with a former employer of mine. Folks, this discussion considers the problem from the wrong perspective. Large IT departments don't bother upgrading their environments unless there's a compelling reason to do that, and if we listen to them, we'll never move forward. Now being told the new version of the application needs the great things brought by the new Cocoon, but requires Java 1.5 can be such an incentive for them. Even if I don't think people frightened by the migration from Java 1.4 (or 1.3) to 1.5 will even consider migrating from Cocoon 2.1 to 2.2. It is IMO our role, as technology builders, to invite our users to progress towards more modern stuff. What's the purpose of Sun releasing a new JDK? What's the reason for Cocoon to release 2.2? What's the reason to upgrade to the latest Xalan? What's the reason for Struts to start with a blank page learning from the oldish Struts 1.x and Webwork? Providing more to users, providing something that works better, providing something that brings more development productivity. All this discussion makes me sad, as it gives the impression the overall Cocoon developer community doesn't want to move forward and is frightened by moves that would cause some disruption among _some_ users. Note also that the poll on the user list showed an evident interest in using JDK 1.5... My 0.02 euros... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Fwd: Flow concurrency (was Re: Action Vs Logicsheet)
Reinhard Poetz wrote:
Mark Lundquist wrote:
Hi,
I posted this on the users list a few days ago, but never got a
definitive answer (I did find out that this is *not* the case for
javaflow :-), but that's not really an answer... I want to know if it
*is* the case for flowscript).
cheers,
—ml—
Begin forwarded message:
From: Mark Lundquist [EMAIL PROTECTED]
On Aug 1, 2006, at 1:46 PM, [EMAIL PROTECTED] wrote:
You're saying that flow calls in concurrently received requests
within
a session are processed serially, not in parallel threads? Is that
right?
That's pretty much it in a nutshell, yes.
wow...
Is there a developer around who can confirm/refute the above?
I guess that's right, see the code of the FOM_JavascriptInterpreter
line 563 (in trunk):
ThreadScope thrScope = getSessionScope();
synchronized (thrScope) {
ClassLoader savedClassLoader =
Thread.currentThread().getContextClassLoader();
FOM_Cocoon cocoon = null;
try {
try {
setupContext(redirector, context, thrScope);
cocoon = (FOM_Cocoon) thrScope.get(cocoon, thrScope);
I remember that we had concurrency issues with Rhino a long time ago.
It might be that they have gone in the meantime with Rhino 1.6. If
concurrency is really an issue for you, experimenting with
synchronization is definitly worth a try.
But note that synchronization is done based on the thread scope
object. AFAIU every user has a thread scope per session _and_ per
sitemap. That means that only requests to the same sitemap and the
same session are blocking.
Exactly. A Rhino scope is not a threadsafe object, hence the need to
synchronize threads using the same scope, which is related to the
continuation.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz wrote: As Java 5 was released almost 2 years ago, I propose making it the minimum requirement for trunk and all artifacts released from there. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Antonio Gallardo wrote: Sylvain Wallez escribió: - in complex use cases the GUI logic, as Carsten's use case exemplifies, becomes spread all over the pipeline, and it becomes increasingly difficult to understand what happens where. Could you explain how can you do the Carsten need easily with Wicket? Sorry, no time to study this particular point. I'm expressing general feelings. - client/server communication with JSON makes it really easy to build Ajax apps, but is a pain to produce from Cocoon unless we directly send it from the controller, which actually makes Cocoon pipelines useless. Why everything needs to go through pipelines? That's precisely the point: do you really need Cocoon if you have no pipelines? DWR perfectly does the trick in that case. - Dojo widgets are a nice replacement for CForm's styling stylesheets, reduce the server load, and again make pipelines less useful. Here is a trade off dojo reduce the server load but increase the client load and bandwidth: http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=dojo+fatq=b I am not telling dojo is bad, I like it, but I see here is a trade off. Dojo usage is not a free lunch after all. ;-) You don't get my point. Dojo can be optimized and aggressively cached on the browser. Once cached in the browser, the concrete things the server has to do are reduced. - enhancing the CForms styling leads to a giant XSL (even if modularized) where every possible styling used in the application must be present. It's not my experience. xslt allows us to just overwrite the required pieces to enhance the styling. Sure, but this doesn't mean its readable nor maintainable when you have so many templates and need to use priorities. - since only CForms has Ajax integration, people are over-using it for presentation purposes (e.g. paginated repeater) I agree with you, mixing binding with form definition is not good. We want to keep it separated. However, I think it is a first implementation wich show us a way to implement a paginated repeater after all it is not released yet. It is a work in progress. Is not fair to blame to a first draft implementation. I don't blame any implementation, but think the concept is criticizable. Using a form object model and flowscript to paginate a result table seems overkill to me. Don't get me wrong: Cocoon is a killer for publication. But for webapps, other approaches, more Java-centric, are worth considering. My current choice is Wicket, which was just proposed for incubation. I took a fast look at wicket and I can see an analogy to building a form intensive application with XSP logicsheets. I already went this way and I can say it is not not easy to maintain the code. I mean it is the same code embedding concept with a new syntax sugar after all. Not at all. There's no code embedding. It's more like writing a Swing GUI that would be associated to an HTML template that defines its layout. Cocoon allows lots of non-Java people to build complicated stuff, and this is a major achievement. But I find it easier to write Java if you're fluent with it rather than finding workarounds in an XML-centric framework. I feel myself fluent in Java and I still prefer find faster to write a cform application using with cocoon. ;-) That's why there's no single silver bullet and one-size-fits-all framework! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote: Sylvain Wallez wrote Yes, now I see two solutions for this: we could just stream out the attributes of the definition (which are strings) or if we need all attributes, stream out attributes which can be streamed. I would go for the first solution, anything against this? Sounds hacky to me... Really? Why? You define something in the model which you want to access easily somewhere. Yeah, but the point is about the somewhere. Each element in a Cocoon pipeline is supposed to address a particular concern. Now over time, reasons emerge for everything to be useful everywhere, and we end up with a giant mix, where having different stages in a pipeline no more really make sense, and where each stage produces as much information as possible for the next one, for the occasional case where it may be useful, thus impacting the general performance just to handle these edge cases. Dumb question: why do you need these attributes in the XSL? Attributes were meant to allow additional information to be communicated between the application logic and the various event handlers and validators attached to widgets, whereas the XSLs are supposed to use the styling information for their job. Yes, but what if you need anything else apart from styling? For example required is passed from the model to the xsls. I want to pass on information like dependencies between fields, for example if field A has value 1, then field B is optional and if field A has value 2 field B is required. I need a generic mechanism here which just passes this information from the model to the xsls where I can generate some client javascript. Well, that looks like business logic to me, and can be handled by on-change events with Ajax. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote: Sylvain Wallez wrote: Yeah, but the point is about the somewhere. Each element in a Cocoon pipeline is supposed to address a particular concern. Now over time, reasons emerge for everything to be useful everywhere, and we end up with a giant mix, where having different stages in a pipeline no more really make sense, and where each stage produces as much information as possible for the next one, for the occasional case where it may be useful, thus impacting the general performance just to handle these edge cases. Ok, in general you're right; but I'm wondering why for example we added a special handling for suggestion lists which is rarely needed and seem to refuse to add a more general approach which helps others as well. Uh? Don't see what you mean here... Streaming out the attributes of the field definition should in no way change the performance as the attributes are empty in most cases anyway. Ok, if others are ok with it, then so be it. I'm sorry to say that over time, I found Cocoon to be more an obstactle for complex webapps pages (not talking about flow) than a real help, and that's why I'm moving away from it. So I don't care as much as I did... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
[resent -- seems to have been lost] Reinhard Poetz wrote: Sylvain Wallez wrote: I'm sorry to say that over time, I found Cocoon to be more an obstactle for complex webapps pages (not talking about flow) than a real help, and that's why I'm moving away from it. So I don't care as much as I did... Can you give conrete examples on what these obstacles are? Well, here are some: - in complex use cases the GUI logic, as Carsten's use case exemplifies, becomes spread all over the pipeline, and it becomes increasingly difficult to understand what happens where. - client/server communication with JSON makes it really easy to build Ajax apps, but is a pain to produce from Cocoon unless we directly send it from the controller, which actually makes Cocoon pipelines useless. - Dojo widgets are a nice replacement for CForm's styling stylesheets, reduce the server load, and again make pipelines less useful. - enhancing the CForms styling leads to a giant XSL (even if modularized) where every possible styling used in the application must be present. - since only CForms has Ajax integration, people are over-using it for presentation purposes (e.g. paginated repeater) Don't get me wrong: Cocoon is a killer for publication. But for webapps, other approaches, more Java-centric, are worth considering. My current choice is Wicket, which was just proposed for incubation. Cocoon allows lots of non-Java people to build complicated stuff, and this is a major achievement. But I find it easier to write Java if you're fluent with it rather than finding workarounds in an XML-centric framework. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote:
Hi,
I'm currently looking into a way of getting information for a widget in
my template that has been defined in the model. But it seems to me that
this is not possible right now.
Is anyone against streaming out all attributes of a widget in the
generateSaxFragment() method? As attributes are not used frequently I
think this shouldn't create problems.
This *will* create problems, as attributes can be of any type, and not
just Strings (although only Strings can be specified in the widget's
definition).
Now if you're using JXTemplate, you can directly access attribute values
with ${widget.getAttribute('foo')}.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Carsten Ziegeler wrote:
Sylvain Wallez schrieb:
Carsten Ziegeler wrote:
Hi,
I'm currently looking into a way of getting information for a widget in
my template that has been defined in the model. But it seems to me that
this is not possible right now.
Is anyone against streaming out all attributes of a widget in the
generateSaxFragment() method? As attributes are not used frequently I
think this shouldn't create problems.
This *will* create problems, as attributes can be of any type, and not
just Strings (although only Strings can be specified in the widget's
definition).
Yes, now I see two solutions for this: we could just stream out the
attributes of
the definition (which are strings) or if we need all attributes, stream
out attributes which can be streamed.
I would go for the first solution, anything against this?
Sounds hacky to me...
Now if you're using JXTemplate, you can directly access attribute values
with ${widget.getAttribute('foo')}.
Yes, I know but I can't *directly* access the attributes in an xsl
stylesheet. And unfortunately it's not possible to overwrite the
jxmacros and extend the streaming mechanism there.
Dumb question: why do you need these attributes in the XSL?
Attributes were meant to allow additional information to be communicated
between the application logic and the various event handlers and
validators attached to widgets, whereas the XSLs are supposed to use the
styling information for their job.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [Vote] Release 2.2M1
Carsten Ziegeler wrote: Please cast your votes on the release of 2.2M1 on monday, 31st of July. The release consists of the core together with the required parent modules and tools to the maven repository. In addition we will release a demo webapp for easy download with some samples. +0 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [continuum] BUILD FAILURE: xsp Block Implementation
-snapshot-repository) Downloading: http://svn.apache.org/repository/org.springframework/poms/spring-context-2.0-rc2.pom [WARNING] Unable to get resource from repository apache-cvs (http://svn.apache.org/repository) [INFO] snapshot org.apache.cocoon:cocoon-session-fw-impl:1.0.0-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-session-fw-impl:1.0.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-session-fw-impl:1.0.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-session-fw-impl:1.0.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-session-fw:1-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-session-fw:1-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-session-fw:1-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-session-fw:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] [compiler:compile] Compiling 78 source files to /home/maven/continuum-1.0.3/apps/continuum/working-directory/167/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/maven/continuum-1.0.3/apps/continuum/working-directory/167/src/main/java/org/apache/cocoon/components/language/generator/ProgramGeneratorImpl.java:[105,37] cannot access javax.servlet.ServletContext file javax/servlet/ServletContext.class not found String rootPath = ctx.getRealPath(/); Uh. Why does failing to download Spring from the repo leads do not finding ServletContext?? And, in the first place, why does the download fail? Sylvain, switching to AntIvy on his project... -- Sylvain Wallez - http://bluxte.net
Re: [2.2] New processor interface/approach
Carsten Ziegeler wrote: Some time ago we discussed very lengthy that our core interface, the Processor, is not the best interface we ever invented. The processor should be the main entrance to the Cocoon processing engine. snip/ So, WDYT? Interesting. However, a few remarks: - how is Processor different from Servlet? - SitemapProcessorFactory is pretty close to ServletContext.getRequestDipatcher() Also, I would avoid at all costs the Consumer inerface. In most cases where a LexicalHandler is present, it is the same object as the ContentHandler, but of course it doesn't implement the Cocoon-defined interface, thus requiring a wrapper to be used. IMO, we should always have a single ContentHandler object, and test if it's also instanceof LexicalHandler. And only in the rare occasions where we have two separate objects, then use a wrapper that implements both interfaces. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [2.2] New processor interface/approach
Daniel Fagerstrom wrote: Often you are going to need the servlet configuration and/or context and then you are back on the Servlet interface again. OTH, having a Servlet as a managed component is slightly complicated as one need to keep track on both its life cycle as a managed component and as a servlet. I guess we will see which way that is best to go when you have implemented a little bit more. IMO that should be servlets, which allow for many other things (and not only Cocoon) to be integrated in a container. Being able to manage servlets means we're able to manage anything and can also benefit from/share with other people's work in this domain. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [2.2] New processor interface/approach
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
However, a few remarks:
- how is Processor different from Servlet?
The interface is similar. The difference is configuration and who
manages the component. If a processor is a component we can use all nice
features of spring for that and I think the configuration is nicer.
Things like changing the configuration at runtime should be easier as
well as you don't have to modify the web.xml.
Servlet is just an interface, no one prevents you from managing a
component that implements Servlet in Spring. And as you rather often
is going to need a Servlet context or configuration within a
Processor, you end up pretty close to Servlet anyway.
The advantage to use the Servlet interface is that we give the users
greater flexibility in reusing the various controllers that we might
implement.
Just for the record, here's the Servlet.init() method I use to have
Spring dependency injection in servlets declared in web.xml. Works like
a charm!
public void init(ServletConfig servletConfig) throws ServletException {
super.init(servletConfig);
// Get the application context,
ApplicationContext ctx = (ApplicationContext)
getServletContext().getAttribute(
WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
// Create an autowire-capable factory
DefaultListableBeanFactory factory = new
DefaultListableBeanFactory(ctx);
factory.autowireBeanProperties(this,
AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, true);
}
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError in 2.1)
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers schrieb:
Were there test cases for the old wildcard matcher? Since this
matcher is almost certainly used in every Cocoon deployment we must
guarantee that it is 100% compatible with the old matcher in
BRANCH_2_1_X - unless, of course, there was some specific bug that
needed fixing.
There were only a few test cases for the old matcher; we have much more
for the new one. And the old one had specific bugs that we needed to fix
and as the old code is very ..ehm..historically grown...it is
unmaintainable.
Carsten
OK. But my question is really that if the old code didn't have unit
tests how do we know that the new unit tests are compatible with the
old matcher (i.e - that they get the same results)?
The best solution to ensure non-regression IMO is to have the same test
case operating on both implementations of the matcher, just differing
for the tests we know to fail in the old implementation (and that
justified the refactoring).
abstract class AbstractWildcardTest extends TestCase {
AbstractWildcardTest(Matcher matcher)...
public testSomethingOkInBothImplementations()...
public testBugInOldImplementation()...
}
public OldWildcardMatcherTestCase extends AbstractWildcardTest {
public OldWildcardMatcherTestCase() {
super(new OldWildcardMatcher()); // old code is kept in the test
source tree
}
public testBugInOldImplementation {
try {
super.testBugInOldImplementation();
} catch(Exception) {
return; // expected
}
fail(Should fail with old implementation);
}
public WildcardMatcherTestCase extends AbstractWildcardTest {
public WildcardMatcherTestCase() {
super(new WildcardMatcher()); // new implementation
}
}
Sylvain
--
Sylvain Wallez - http://bluxte.net
[Fwd: [Dojo-jobs] Dojo/cforms developer needed around Stuttgart/Germany]
FYI, this was posted on the dojo-jobs mailing list. I guess cforms is Cocoon Forms :-) Sylvain Original Message Subject:[Dojo-jobs] Dojo/cforms developer needed around Stuttgart/Germany Date: Thu, 06 Jul 2006 12:38:38 +0200 From: Knut Hertel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, we are looking for a cforms/dojo developer, who will be able to fix some dojo bugs, that occur with IE 6/7. Out company is located in Stuttgart, Germany. Please send inquiries to [EMAIL PROTECTED] Regards Knut ___ Dojo-jobs mailing list [EMAIL PROTECTED] http://dojotoolkit.org/mailman/listinfo/dojo-jobs
Re: [CForms] Load/Save model events never send?
Carsten Ziegeler wrote: Giacomo Pati wrote: Will this enable to try to store something like abc into a integer widget/model (which obviously would raise an Exception). If this would be possible I would certainly be against allowing unvalidated/invalid-state saves. I don't know :) I guess it depends, if your model is using an int, I guess you will get an exception. But if your form model is using an int datatype but your data model is using a string (for whatever reason) this might work. It also might work if you're binding to xml. But all these are just guesses. Now, we could argue that if someone explicitly calls save() he should have ensured beforehand that his data is valid. +1. CForms makes sure in all places that any data returned to the application to be valid, and returns null otherwise (with a validation error being set). This therefore completely shields the application from buggy data, which simplifies application development and avoids bugs and to some extend rogue data injection. However some people have some use cases where they want to be able to save a form in a draft state, even if it's invalid. In this context, saving should'nt considered IMO to be the same as the form's save operation, as the form data can be not only semantically invalid (i.e. validators fail), but also syntactically invalid (i.e. a abc for an integer). Invalid syntax means the form's binding more than likely to fail to save the form (invalid bean property types). Saving as draft therefore means saving the form values as plain text and restoring them as such, just as if they where read from the request. This is however not possible today because of the lack of the needed entry points in widgets. This can be solved though if people really needed with a couple of setStringValue()/getStringValue() methods. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Torsten Curdt wrote: Another point seems to be forgotten in this discussion so far - the legal aspects of distributing jars. Does the ASF want to re-distribute 3rd party jars? Plus: based on a chat Sylvain and me had with Cliff during ApacheCon it seems we could have blocks providing bridging code to LGPL ...as long as we do not provide the jar and the block is optional. (Sylvain, did I summarize that correctly?) Yes. What Cliff said (warning: nothing official here!) is that we may allow _optional_ dependencies of ASF software on LGPL code. This is legally possible if we consider the LGPL dependency to be part of the environment of our software, i.e. a prerequisite for users that want to use these optional features. This consideration about environment is what allows commercial software to be built on the GPL'ed Linux operating system. However, to be legally clean, this requires the build system to be able to handle these prerequisites by not automatically downloading them from a remote repository. In simple words, that will require people to manually place the LGPL'ed jars in the equivalent of lib/local in Cocoon 2.1. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Tim Williams wrote: On a side note, I use the Cocoon code to learn forrest internals and that task has even been increasingly more difficult since the directory restructoring, which seems random at best. As you proceed with this discussion, I hope you'll appreciate that there are indirect/non-cocooners who are effected by the decisions you make... Anyway, just another perspective... The feedback of people that aren't in everyday's action fire is *really* important. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RANT] This Maven thing is killing us....
Carsten Ziegeler wrote: Now, m2 is theoretically a very good tool :) Stefano principle: you need good ideas and bad code to grow a community. The application of this principle in Maven is different than usual, as it forces other projects (and not only its own developers) to endure the consequences of its bugs. And this actually endangers these other projects by forbidding their developers from concentrating on actual productive work. Cocoon with all its dependencies is certainly an extreme use case for Maven compared to all others, and broken builds led some of Cocoon's major contributors to not even try 2.2 for months. And now we're wondering if users will even be able to build Cocoon if they dare to download it. The project is in danger. I discussed with several people from other projects at ApacheCon and they all report the same kind of problems: non-repeatability of builds. It works one day, but not the day after without anything having changed. Maven has gained a lot of mindshare because everybody's talking about it. Does everybody talk about their Ant build system? No, because it just works. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] New committers
Joerg Heinicke wrote: Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. 1. Andreas Hochsteger 2. Peter Hunsberger 3. Jason Johnston +3. Welcome aboard guys! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Vote] Cowarp, auth-fw and session-fw in 2.2
Carsten Ziegeler wrote: As both, auth-fw and session-fw are really out dated and as cowarp is a better implementation of the auth-fw, I propose to: a) deprecate auth-fw and session-fw in 2.1.x b) remove auth-fw and session-fw in 2.2 c) add cowarp as an own block to 2.2 +0. I never used auth-fw nor cowarp and use a homegrown solution that provides in-application authentication and authorization while still allowing the use of the regular request.isUserInRole() and request.getUserPrincipal() using a request filter. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Please review changes to WildcardHelper
Bruno Dumon wrote: This won't be of much help, but I thought the wildcard matcher is significantly faster than regexpes. PS: I like the idea of moving it to commons-lang. I've used it on several occasions outside Cocoon. Ditto. I even have a refactored version that returns a String[] rather than a Map. It's faster and easier to use from Java code. Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON-1825) Ajax errror when an active state widget become invisible state widget
[
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12413991
]
Sylvain Wallez commented on COCOON-1825:
I don't see how surrounding the table with a span changes something. Or...
I remember of a bug in IE that doesn't like tables to be replaced in JavaScript
or something related.
Adding an element for fi:group and fi:struct is good, but I'm wondering if
this should be a div rather than a span.
fi:placeholder are used to mark the place of hidden widgets and should be
kept empty.
Ajax errror when an active state widget become invisible state widget
-
Key: COCOON-1825
URL: http://issues.apache.org/jira/browse/COCOON-1825
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.9
Reporter: vincent Demay
Assignee: Antonio Gallardo
Some widget (field with selection-list and styling=radio, group, etc...) can
not be hidden (state=invisible)in ajax mode.
I declare some widgets without state attribute in the form definition, my
form is in ajax mode, when I set the widget state to INVISIBLE, the ajax
response can not be applied to the form because span
id=widget-name.../span is not available in source code.
I think about 2 patches :
*putting a span/span in forms-field-styling.xsl where is not set
*or modifing abstractWidgetDefinition.java in ordre to generate a placeholder
around each widget (but patch seems to need a lot of modification in
forms-field-styling.xsl too)
Here is the patch for first
--- forms-field-styling.orig 2006-04-13 15:37:06.590221200 +0200
+++ forms-field-styling.xsl 2006-04-13 15:38:22.525291200 +0200
@@ -198,8 +198,9 @@
xsl:variable name=value select=fi:value/
xsl:variable name=vertical
select=string(fi:styling/@list-orientation) != 'horizontal'/
xsl:choose
- xsl:when test=$vertical
-table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
+ xsl:when test=$vertical
+ span id={$id}
+ table id={$id} cellpadding=0 cellspacing=0 border=0
title={fi:hint}
xsl:for-each select=fi:selection-list/fi:item
xsl:variable name=item-id select=concat($id, ':',
position())/
tr
@@ -224,6 +225,7 @@
/tr
/xsl:for-each
/table
+/span
/xsl:when
xsl:otherwise
span id={$id} title={fi:hint}
@@ -682,22 +684,24 @@
| know where to insert the widget if it becomes visible
+--
xsl:template match=fi:placeholder
-span id=[EMAIL PROTECTED]/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:struct - has no visual representation by default
+--
xsl:template match=fi:struct
-xsl:apply-templates/
+ span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
!--+
| fi:group - has no visual representation by default
+--
xsl:template match=fi:group
-xsl:apply-templates/
+span id=[EMAIL PROTECTED]xsl:apply-templates//span
/xsl:template
+
+
xsl:template match=@*|node() priority=-1
xsl:copy
Here for the second
--- AbstractWidget.orig 2006-04-13 15:31:07.851701200 +0200
+++ AbstractWidget.java 2006-04-13 15:30:31.446616200 +0200
@@ -483,6 +483,10 @@
public void generateSaxFragment(ContentHandler contentHandler, Locale
locale)
throws SAXException {
+ AttributesImpl placeHolderAttrs = new AttributesImpl();
+ placeHolderAttrs.addCDATAAttribute(id, getRequestParameterName());
+contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder,
placeHolderAttrs);
+
if (getCombinedState().isDisplayingValues()) {
// FIXME: we may want to strip out completely widgets that
aren't updated when in AJAX mode
String element = this.getXMLElementName();
@@ -497,15 +501,9 @@
generateItemSaxFragment(contentHandler, locale);
-contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element);
-
-} else {
-// Generate a placeholder that can be used later by AJAX updates
-AttributesImpl attrs = new AttributesImpl();
-attrs.addCDATAAttribute(id, getRequestParameterName());
-contentHandler.startElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder, attrs);
-contentHandler.endElement(FormsConstants.INSTANCE_NS,
placeholder, FormsConstants.INSTANCE_PREFIX_COLON + placeholder);
+contentHandler.endElement(FormsConstants.INSTANCE_NS, element,
FormsConstants.INSTANCE_PREFIX_COLON + element
Re: Spring - conf/applicationContext.xml | global bean definitions
Carsten Ziegeler wrote: I would prefer having some global mechanism, similar to WEB-INF/xconf for Spring beans. We could introduce something like WEB-INF/spring/ into which you can put as many bean definition files as you want. Oh, this already works! Just put a: include-beans dir=context://WEB-INF/spring pattern=*.xml/ in the cocoon.xconf. (Ok, to be honest, I haven't tested it yet, but it should work...). This side note makes me shudder. Does this mean you commit new features without even checking if they work? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Spring - conf/applicationContext.xml | global bean definitions
Carsten Ziegeler wrote: Sylvain Wallez wrote: This side note makes me shudder. Does this mean you commit new features without even checking if they work? Hmm, hmm, what do you think I'm doing? As we have a commit-then-review policy would this make a difference? Yes, it does make a big difference IMO. Even if other people can cross-check what you commit, testing before commit ensures you don't waste other people's time. Anyways, I tested this long time ago but in the meantime many changes have occured, so it might be that it's currently not working. And yes, just to give you a relief, usually I test what I commit including a full clean rebuild. Glad to hear that. You'll admit that's not the message your post was conveying! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: New XReporter expressions
Simone Gianni wrote: Hi all, I've made some modifications on XReporter to have a better expression syntax and to support some new functionalities i need for calculated fields (see http://issues.cocoondev.org/browse/XRP-113 ). I have an updated jar, already tested with cocoon. Can I simply commit it, or do I have to update other stuff (other than status.xml) ? Is there a modification of the XReporter expression engine itself, of new extensions for it? In the former case, it would be good to contribute it back to the XReporter project. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: New XReporter expressions
Simone Gianni wrote: Hi Sylvain, they have been contributed, accepted and already committed in XReporter. They are modifications in the engine, I'll give full details here on the list ASAP. Great! Just make sure that the jar name allows us to know what version of XReporter it is (either official release or svn revision). Sylvain -- Sylvain Wallez - http://bluxte.net
Flowscript in Spring
FYI: http://www.theserverside.com/news/thread.tss?thread_id=40522 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: How long for a full trunk build (was: ParnoidCocoonServlet)
Bertrand Delacretaz wrote:
On 5/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...I had similar problems with m2 and now I'm always doing a clean
install and most times remove my local repo as well...
Just curious, how much time do you need for a clean build of the
trunk, starting with an empty m2 repository?
I've had several occurences where the whole thing was not finished
after more than an hour, using an usually fast DSL or similar
connection. For some reason, the repository downloads seem to be very
slow here.
The main Maven repository has a severe outage (corrupted filesystem on a
raid diks), and was on the same machine as codehaus.org which is down also.
The main mirror is now (temporarily?) hosted at http://repo.mergere.com/
which may not have enough bandwitdth.
You should consider adding some mirrors to you
{maven-home}/conf/settings.xml from the list at
http://maven.apache.org/guides/mini/guide-mirror-settings.html
Also, AFAIU, http://www.ibiblio.org/maven2 is no more queried with the
default settings and should be added as a mirror as well.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Flowscript in Spring
Pier Fumagalli wrote: On 18 May 2006, at 13:04, Sylvain Wallez wrote: FYI: http://www.theserverside.com/news/thread.tss?thread_id=40522 ??? Isn't Spring supposed to be a container manager a-la Avalon ??? The component container is the original Spring, which has grown a lot to be more a galaxy of subprojects. Spring has the container, lots of components and helper classes (kindof Excalibur) and even a webapp MVC framework and a page-flow engine named webflow. This JS webflow doesn't seem to be part of the official Spring project, and is a reaction to the huge pile of XML that's needed to use webflow. The result is really Cocoon's flowscript adapted to a different environment [1], just like there's already has been Struts-flow [2]. Once again, our ideas are reused. We can be proud to have opened new ways in webapp development, but it would be better if our components rather than our ideas were reused, and unfortunately this really isn't easy because of the very specific APIs used in Cocoon's foundations, that once weere so useful but now seem like a ball and chain... Sylvain [1] http://rhinoinspring.sourceforge.net/webflow.html [2] http://struts.apache.org/struts-sandbox/struts-flow/ -- Sylvain Wallez - http://bluxte.net
Re: RAD with Cocoon 2.2
Reinhard Poetz wrote: Maven brings a lot of advantages to standardize the development process but also makes development of applications more difficult as you spread your applications over different artifacts. In the light of this I think we should revert our removal of the per-sitemap classloading (http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=114150323011155w=2). As the removal was part of a refactoring of the sitemap engine, could sombody give me a description of what needs to be done? The main idea is to create a classloader with what is defined by map:classpath in the sitemap, and use that classloader to create the container for components in map:components This is achieved by giving this classloader to the container (was possible with ECM, don't know with Spring) and setting it as the thread's default classloader before processing a request in the sitemap (and restoring the old one at the end). This allowed classes to be reloaded when the sitemap was reloaded. Torsten later added a file monitor that tracks changes to the contents of the classpath and triggers the sitemap reloading. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [2.2] Dojo resources are missing
Jorg Heymans wrote: Carsten Ziegeler wrote: It seems that the jar with the dojo resources is completly missing in 2.2. I have no clue how the jar is build for 2.1.x and how we can handle this in an easy way with m2? Any ideas? The dojo jar file is built using an Ant script [1] from a Dojo distribution. I haven't added this to 2.2 as trunk was moving a lot when I added Dojo support and I had no clue about where to put that Ant file. What if we just unpack the resources and add them to src/main/resources/dojo of the ajax block ? No: a nice thing with Dojo is that you can build a specific distribution leading to a single dojo.js file that contains all that is needed by your project and nothing more. This allows the browser to load only one JS file that is a small as possible and cache it, rather than loading JS files on-demand using XmlHttpRequest. That's why we should provide a Dojo distribution, but make it very easy for people to put their own custom distribution by just replacing a jar. Sure, we could build our distribution by importing the Dojo source code in the dojo block, but that doesn't bring much value IMO and makes it less easy to update the Dojo version that we distribute. Sylvain [1] http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/ajax/dojo/ -- Sylvain Wallez - http://bluxte.net
Re: [2.2] Dojo resources are missing
Reinhard Poetz wrote: What about having a dojo block that contains a dojo version that is enough for our needs. We add it to the ajax-block as a provided dependency. If people want to use it, they have to add an explicit dependency to their project - either inlcuding our dojo block or using their own. If provided dependency means that we provide our distribution as a jar file, then +1 (this is how it is in the 2.1 branch). But we should avoid to copy all the Dojo source code as individual files in our repository. BTW, Dojo 0.3 was just released, and it kicks ass :-) http://dojotoolkit.org/ Sylvain -- Sylvain Wallez - http://bluxte.net
Spring and OSGi
Hi all, Spring is about to provide OSGi support: http://opensource.atlassian.com/projects/spring/browse/SPR-1802 This is certainly interesting in the current 2.2/3.0 debate :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: CallFunctionNode problems in trunk
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz schrieb: Carsten Ziegeler wrote: Ok, so let's change the strategy and fix the standalone service selector... :) If svn works again I can do this on monday evening - if noone beats me to it. I didn't fix the StandaloneServiceSelector but replaced it with a factory. Basically the factory works for me and the code is very simple. Exception handling needs to be improved but that's the next step. Could somebody verify and review the attached patch? I'm not sure but I think your solution is the opposite of the current problem: you are always creating a new instance, so thread safe components are not handled correctly. Right, but that's easily fixed (see http://people.apache.org/~reinhard/ProcessingNodeBuilderFactory.java). I would prefer getting rid of the StandaloneServiceSelector as it is everything else than a simple class for a simple task and why do all those builders need to be components? I know there are historical reasons but do we need them to be components _now or in the future_? As the original culprit, let me expand on the historical reasons. The TreeProcessor was written during the winter of 2000/2001 at a time where we were discussing flowmaps. There was a need for an extensible pipeline language so that we could experiment new approaches. That's why the TreeProcessor was designed around ProcessingNodeBuilders as components. There are two different kinds of processing nodes: those that do not need to know any other node except their children, and those that need to be linked to other parts of the tree (making it actually a graph) to call resources and flow, and also to call views in pipeline statements. Two important concerns in the design were speed and strong separation between build-time and run-time structures. So linking isn't a concern of the node itself, but a concern of its builder. A linked node builder therefore has to keep a reference to the node it has created, and is therefore stateful, whereas other builders are completely stateless and are pure factories (create a node and forget about it). Using ThreadSafe ensures that only one instance of a stateless builders exists, therefore speeding up the sitemap creation process. Linked builders, being stateful, are not ThreadSafe so that one instance is created anew for each node. Since Avalon considers no lifestyle interface as being the same as SingleThreaded, the LinkedNodeBuilders had no particular marker interface, but SingleThreaded would have produced the exact same result. So, as a conclusion: - making NodeBuilders ThreadSafe is an optimization thing, - LinkedNodeBuilders are statefull and _must_ be created a new for each node, - all these builders are linked to a particular TreeBuilder (see setBuilder(TreeBuilder)). Anything else that could be a problem with my implementation? I basically looks good, except: - you should swap the test for Configurable and LogEnabled (this one should come first) - in 2.1 a AbstractProcessingNodeBuilder is Composable. In trunk, it gets the ServiceManager from the builder, which is good also (and BTW, why does Spring's bean factory appear here? It would be better to be in an Avalon-only world in this part). Sylvain -- Sylvain Wallez - http://bluxte.net
Re: ApacheCon Hackaton: focus on 2.2? - Documentation
Steven Noels wrote: On 12 May 2006, at 10:07, Carsten Ziegeler wrote: Now my biggest problem is offline editing? I asked this question some time ago but never got any helping answer. What is the best way to edit the docs offline? http://cocoondev.org/daisyscratchpad/g4/291.html#dsy291_detachment ;) (unfortunately, that is a suggestion we didn't receive a proposal for) You should also consider the recent and impressive progress that has been done in offline-aware webapps: http://ajaxian.com/archives/dojostorage-offline-access-and-permanent-client-side-storage Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Cocoon CRUD (was GSoC Proposals)
Simone Gianni wrote: Hi Jason, Jason Johnston wrote: Do you have a plan for where this development will occur? I'd like to be able to help out with code but I'm not a committer so somewhere outside the official repository would be easier for me ;) We have a CVS/SVN public server, and can easily setup other cooperation services, like an issue tracking and a wiki. I can then move the released code and documentation to the cocoon tree. I am strongly against hat! The way to become a committer is by contributing (remember how you became one?) So, even if a bit tedious, Jason has to provide patches that will be evaluated by the community up to a point where his contribution are considered good enough and frequent enough for him to be voted committer. Using other code repositories can only lead to community fragmentation and hiding valuable contributions of people that are hidden because they're proxied by someone else. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Cocoon CRUD (was GSoC Proposals)
Simone Gianni wrote: Hi Sylvain, you're right, I do agree with you. I was searching for a way to cooperate without having to make a couple of patches every day. Anyway, we can reduce the amount of patches (and thus the tedious part of them) by organizing wisely the developement effort, like assigning entire parts that can be developed in a rather independent way between me, Maurizio and Jason. That a good way to organize things and effectively avoids people to step on each other's toes! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GT2006] The 5th Cocoon GetTogether: call for ideas
Bertrand Delacretaz wrote: On 5/1/06, Arje Cahn [EMAIL PROTECTED] wrote: ...- Who is willing to organize this year's event?.. You guys did a great job last year, why not repeat it ;-) Yep! - Where? Amsterdam is very convenient in terms of flights from many places. Yep again! - When? October was good. Yep yep! - How long? Two days is fine IMHO, but I'd suggest a two-days Hackathon including talks, see below. - How big? Having just a Hackathon, with more or less improvised talks, might be cool and much easier to organize. People could sign up on site to give a talk while we're there, in an informal way. If I try to remember last year, for me the most information-rich time was the discussion of Cocoon internals at the Hackathon: a collaborative talk that didn't require much planning but where people could share their knowledge. The public talks day is also good, but such talks can also happen at ApacheCon and be received by wider audiences. Exactly. As ApacheCon Europe is going to be held every year, it makes sense to showcase and promote Cocoon there, reaching a more diverse audience. Also, the venue should stay open (including Internet connection ;-) much longer than last time, say from 9AM to 10PM so that we don't have to rush out just when people start waking up ...I'd be happy to host the event in Amsterdam again... +1 for Arje and the Hippo team! +1! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Finding a name for OSGi based Cocoon
Reinhard Poetz wrote: I slightly prefer Cocoon 3.0 as we/I have been using it for a long time for OSGi based Cocoon and Daniel and I are sure that OSGi-based Cocoon can be the platform to implement many ideas that were raised in Sylvain's Cocoon 3.0 thread. My ideas, which are progressing slowly because of the lack of time, are really diverging from the current code base. So, if they one day come to life, I doubt they will deserve the name Cocoon. So +1 for Cocoon 3.0. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Finding a name for OSGi based Cocoon
Reinhard Poetz wrote: Sylvain Wallez wrote: My ideas, which are progressing slowly because of the lack of time, are really diverging from the current code base. So, if they one day come to life, I doubt they will deserve the name Cocoon. I'm looking forward to hearing from your ideas. I think that the architectural changes of Cocoon 3.0 will make it much easier to experiment again in a safe way. I'm currently going more on the full-Java side of things rather than the declarative way with XML files. The use of JDK 1.5 annotations allows for very clean and powerful things examplified by Stripes [1]. For complex forms, Wicket [2] uses the same kind of component model as CForms, but in a pure Java way, and is very powerful. All this goes in a direction that's very different from Cocoon, which is about declarative programming and allows people that don't master Java to do great things. My current project has *no* XML configuration file: I wrote a small library to do sitemap-like URL matching and request dispatching, we use PicoContainer, pure servlets, Velocity and Wicket. There's no need for complex or multi-format presentation and therefore no need for pipelines yet. I guess the no-XML approach is a kind of overreaction to the all-XML that I've used for years, and that truth lies somewhere in the middle. It does work well, though... That being said, I'm more than happy to see the architecture of Cocoon evolving towards a less monolithic way based on servlets. This is one of the key changes that can allow Cocoon (or parts of it) to be integrated into other environments. Keep up the good work! Sylvain [1] http://stripes.mc4j.org/confluence/display/stripes/Home [2] http://wicket.sourceforge.net/ -- Sylvain Wallez - http://bluxte.net
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote: What I mean is that the tree processor currently get the path to the sitemap.xmap from the configuration file. If the tree processor stop being a managed component and just is setup in the SitemapServlet, it will still need to get the sitemap path from somewhere. IMO a servlet config init parameter would be a reasonable place to set the sitemap path. Ah, ok. Now, since this is about simplifying setup: is it even useful to have a configurable sitemap path? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Daniel Fagerstrom wrote: Take a look at http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106649931022515w=2 for a description on how the treeprocessor works. The function of the virtual sitemap components is described here http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111316710610638w=2. I don't know if the VPCs work anymore, haven't tested them for quite a while. For the understanding the resource handling (or other parts of the treeprocessor), it is a good idea to start looking at http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/treeprocessor-builtins.xml, which configure all the execution element of the sitemap. Where you can see that a resource definition is handled by a NamedContainerNodeBuilder, and that calling a resource is handled by a CallNodeBuilder. IIRC, there are a few subtle things involved in the resource handling code, so be prepared to that you might need to spend some time learning how it works ;) Views and resources are handled similarily as things that are purely internal to a sitemap. They are therefore looked up and hard-linked as part of the processing node tree building phase. Having inheritable resources means: 1 - they should be stored into a location that's visible from child sitemaps. Either the sitemap-specific service manager or Avalon context object should fine (I prefer the latter). 2 - they should not be looked up at build time but at execution time. However, that's probably not enough, as the URL resolution in inherited resources will be relative to the context of the sitemap that called the resource. Solving this, well, is very close to virtual sitemap components and is not trivial. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: AW: AW: Desparately seeking help with pipeline implementation
Stefan Pietschmann wrote:
Hi Sylvain (and others),
thank you for the quick response which finally helped me understand how the
pipeline is used at runtime.
Great! The main point about pipelines is that they are basically empty
shells that are filled with components by the sitemap engine, and
cleaned up after the pipeline has been executed.
They don't keep component between different requests, since the actual
components used and their parameters can change for every request, even
for the same URL.
The fact that pipelines are recyclable (i.e. poolable) is just here to
avoid having to go through the Avalon initialization stuff on each
request. Now there initialization is so simple that they actually could
be SingleThreaded rather than Recyclable and thus created anew at each
request rather than pooled.
What I do is to throw transformers out depending on their attributes (it's a
bit more complicated, but anyway..). Now that I see that the transformerlist
is built anew for every request I do not need to backup the original list
and load it everytime.
Right.
I thought it would be built only once at the beginning.
At the beginning of what? ;-)
So my choices now are to overload the addTransformer() method, only adding a
transformer under certain circumstances, or leave my current implementation
which goes through this.transformers, this.transformerSources and
this.transformerParams, checks the parameters and throws the transformers,
sources and parameters out of the lists.
The first way seems easier, but it means that I have to copy the whole
method from the super class to my pipeline and change it there - I don't
like that because you I have to check for changes with every Cocoon update.
With the second way I can simply outsource the code going through the lists
to my own method and call it at the beginning of setupPipeline().
Why would you have to copy the superclass source code? Just call
super.addTransformer() if you need to and that's all, isn't it?
public void addTransformer(String role, String source, Parameters param,
Parameters hintParam) {
if (keepTransformer(role, source, params, hintParam) {
super.addTransformer(role, source, params, hintParam);
}
}
Another option, if you need to do some complex computation on the
transformer list is to overload setSerializer(). When this method is
called, all transformers in the pipeline are there.
I do have one more question - to make it right this time. If I prevent a
transformer from being added to the list in addTransformer(), or if I kick
it out in my method, I see I have to release it.
Yes.
This is done by the following in AbstractProcessingPipeline:
int size = this.transformerSelectors.size();
for (int i = 0; i size; i++) {
final ComponentSelector selector = (ComponentSelector)
this.transformerSelectors.get(i);
selector.release((Component) this.transformers.get(i));
this.newManager.release(selector);
}
In my method it would look like:
Iterator transformerItt = this.transformers.iterator();
...
int i = 0;
while (transformerItt.hasNext()) {
Transformer trans = (Transformer) transformerItt.next();
...
// check if the transformer should be run
..
// kick it out
transformerItt.remove();
// release transformer
final ComponentSelector selector = (ComponentSelector)
this.transformerSelectors.get(i);
selector.release((Component) trans);
this.newManager.release(selector);
i++;
}
Right?
That's the idea, but you have some bugs here since when you remove a
transformer, you should also remove the corresponding selector and
parameters:
for (int i = 0; i this.transformers.size(); /* do not increment here */) {
if (trashTransformerAt(i)) {
// Release what needs to be
Transformer transf = (Transformer)this.transformers.get(i);
ComponentSelector selector =
(ComponentSelector)this.transformerSelectors.get(i);
selector.release(transf);
this.newManager.release(selector);
// Update lists
this.transformers.remove(i);
this.transformerSelectors.remove(i);
this.transformerParams.remove(i);
this.transformerSources.remove(i);
} else {
i++;
}
}
Be careful also that depending on the class you extend, there are a
couple of other lists to update as well:
- transformerRoles in AbstractCachingProcessingPipeline
- isCachePoint in CachingPointPipeline
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Desparately seeking help with pipeline implementation
Stefan Pietschmann wrote: Hi guys, for my thesis I have implemented a custom pipeline, which modifies the list of transformers to be run during pipeline setup. This is done with every request in setupPipeline(), so I need to reset to the original every time, before I modify again. Why do you need that? Can't it be done by overloading one of setGenerator/addTransformer/setSerializer? That's why I try to do a backup of the list, then reload it at the beginning. It has been working smoothly so far, but I just started testing deeply with JMeter, and when I use 10 Threads (my testcase is that 10 Threads are 10 times requesting a page for 10 times, so 1000 requests altogether), I'm running into problems. I get errors around the 150^th request… and they are getting more and more. They occur in several classes (the TraxTransformer, IntStack, SAX2DTM and so on), but I'm pretty sure that's not where the problem lies, because with the default pipeline there are no such problems. Can you please look into my implementation? I'm sure there must be some stupid mistake (I haven't worked in multithreading environments yet). This is really important since my deadline is very very near and this came totally surprising to me L I have simplified the pipeline as much as I could – you only need to adjust the package to where you put it and add it to your sitemap. When running a simple testcase with several threads, you will see the problems L Giving more details about the errors you obtain would be useful, but I guess this is more related to component pools than to multithreading. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: AW: Desparately seeking help with pipeline implementation
Stefan Pietschmann wrote: | -Ursprüngliche Nachricht- | Von: Sylvain Wallez [mailto:[EMAIL PROTECTED] | Gesendet: Sonntag, 30. April 2006 14:00 | An: dev@cocoon.apache.org | Betreff: Re: Desparately seeking help with pipeline implementation | | Stefan Pietschmann wrote: | | Hi guys, | | for my thesis I have implemented a custom pipeline, which modifies the | list of transformers to be run during pipeline setup. This is done | with every request in setupPipeline(), so I need to reset to the | original every time, before I modify again. | | | Why do you need that? Can't it be done by overloading one of | setGenerator/addTransformer/setSerializer? I adapt the pipeline with every request according to some external data. Isn't addTransformer() called only once when the pipeline is built? If it is, I couldn't use it, because this would mean I adapt the pipeline once, and all subsequent requests use the adapted one. However, if this.transformers (and the other ArrayLists with the sources and parameters) is built anew for every request, then this might be an easy way out. The contents of a pipeline is not reused across requests! All components are releases and cleared in recycle(), which occurs once the pipeline has been executed. The setGenerator/addTransformer/setSerializer are called by the sitemap engine when executing map:generate, map:transform and map:serialize respectively. This is probably a good place if you want to automatically add some components to the pipeline, particularly considering that pipeline cache key and validity computation happens after these methods. Now if you remove some of the components that were already in the pipeline, don't forget to release them or you may encounter some memory leaks in object pools (see the code in AbstractProcessingPipeline) | Giving more details about the errors you obtain would be useful, but I | guess this is more related to component pools than to multithreading. I can attach some stacktraces if that helps... Yes, it always helps. I only see that I only get problems when using multiple threads. The problem might be related to anything else - I don't seem to understand how a pipeline is used by multiple threads. I thought - since it's recycleable - that each thread gets its own pipeline object. Yes, pipelines are not shared among threads. But if you do some nasty things with the pipeline components, it may happen that the pipeline is not be correctly recycled and therefore components used by multiple threads... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Running Cocoon in OSGi mode
I followed the instructions: $ mvn c-eclipse:eclispe -o didn't work [ERROR] BUILD ERROR [INFO] The plugin 'org.apache.maven.plugins:maven-c-eclipse-plugin' does not exist or no valid version could be found Now it works for core/cocoon-core but still not for core, (which is needed for geting the blocks fw). After having started the OSGi framework I get a java.lang.NoClassDefFoundError: org/springframework/beans/factory/BeanFactory Works now. The test page also works. I get the error: Cannot nest output folder 'cocoon-blocks-fw-impl/target/classes/META-INF' inside output folder 'cocoon-blocks-fw-impl/target/classes'cocoon-blocks-fw-impl in Eclipse (3.2RC1). I see. I will try to find a solution for this and get in contact with the PDE devs as the problem is that our META-INF is not in src/main/resources but in the root directory because of PDE requirements. Guys, I don't know about you, but this discussion gives me the feeling that we're now totally out of control of our own code base. Being unable to run Cocoon and having to ask the PDE guys at Eclipse for this is frightening me... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Running Cocoon in OSGi mode
Reinhard Poetz wrote: Sylvain Wallez wrote: Guys, I don't know about you, but this discussion gives me the feeling that we're now totally out of control of our own code base. Being unable to run Cocoon and having to ask the PDE guys at Eclipse for this is frightening me... huu? What makes you think that you can't run trunk without Eclipse and that we are not in control of our own code? My description was only about having OSGi-based Cocoon run with PDE support which is a great thing if you want to develop OSGi bundles. If you had a look at the JIRA tasks you would see that it's one of our goals to build Cocoon without needing Eclipse (http://issues.apache.org/jira/browse/COCOON-1834) and another goal is getting a smooth integration with Eclipse PDE (http://issues.apache.org/jira/browse/COCOON-1836). I had to decide for one goal to start with and for me it's more important to enable others to get easier involved. Please also note that this doesn't affect the non OSGi based way of running Cocoon. - o - Ad the particular problem: The branched maven-eclipse-plugin has a bug and doesn't add the META-INF directory as a source directory (I guess from Daniel's description). I will have a look into this issue tommorrow. Ok. So that's just me that lost track about what's happening. Sorry for the noise... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: cocoon forms bandwidth
Philippe LAPLANCHE wrote: dojo.js filesize = 144 Kb Isn't Ajax supposed to save bandwidth Absolutely not. Ajax is meant to provide a better user experience, by allowing partial page updates. This saves some full-page reloads, but also implies more requests to the server, even if they return less data than a full page. What's the point using such a huge library ? Some of my application users won't have broadband connections. Does that implies that I can't use cocoon forms with ajax at all ? Some users will have broadband connections ... So what's the good solution ? See the discussion at http://marc.theaimsgroup.com/?t=11441367892 An important point is that dojo.js is loaded *once* and then cached by the browser. There is no mechanism to prevent the provided xsl stylesheets putting all the stuff that we don't need in head /head. If I understand the philosophy, I have to edit all the xsl files manually so that I get precisely what I want. Is that it ? Cocoon upgrades will be really hard then. Yes. The XSLs must be refactored to isolate the Ajax-related styling in a separate stylesheet. I will then be easy to remove the corresponding script tags. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Mini-Cocoon
Don Brown wrote: For the next generation of Struts Action Framework, we have merged with WebWork to build the new version on its solid foundation. One of its powerful features are its Interceptors, which act like Servlet filters allowing you to define the framework workflow for the Action on either a per-action or per-package basis. This lets you fully separate the concerns of your framework logic. I've been toying with the idea of bringing the Interceptor concept to the view layer, and with XHTML becoming more and more prevalent, I think it is ripe to bring the power of the Cocoon pipline to post-page processing. I'd like a user to be able to specify an interceptor stack (pipeline) on a per-action or per-package basis. This would be similar to the popular Sitemesh project, but more powerful has any page minipulation is possible. Anyways, I bring this up here because it would require a SAX-based XML pipeline implementation and I immedately think of Cocoon. However, the requirements for such a feature would be: - We only need transformers and serializers, the framework would handle the generation (implicitly a SAX parser generator would be used to process the response's outputstream) - Ideally no additional dependencies - The pipeline impl should be small, and focused - Very little to no additional configuration for the user. A set of transformers and serializers would be defined somewhere, and stacks, or statically defined pipelines. No selectors, matchers, or other sitemap capabilies would be needed. We could write our own, but part of the vision of Struts Action 2 is to bring some level of unification to the Java web development space, and I'd like to include Cocoon in the discussion. I have a Cocoon pipeline extract project, Simple XML Pipelines[1], we could use, but I'd rather use an official Cocoon artifact to strengthen the ties of the two projects and leverage the years of experience and knowledge of the Cocoon community. My pipelines project could be donated, if necessary, to seed the work. This new Struts Action 2 feature hasn't been discussed, much less accepted by the project, still in its infancy, but I wanted to first float the idea to see if the Cocoon community would be interested in developing such a mini-Cocoon. I've found several uses of my stripped down Pipeline project in areas like multi-versioned SOAP services support and portal URL-rewriting, so I think it would be of interest outside Struts. Look forward to the feedback, Splitting Cocoon in smaller pieces is something that absolutely must be done IMO if we want Cocoon to evolve. This has been discussed many times on this list and your deconstruction of Cocoon for use in Struts (flowscript and now pipelines) shows well that Cocoon will be copied rather than used if it stays the monolithic piece of code it is today. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Calculated fields
Simone Gianni wrote: Hi all, what about calculated fields? In a cocoon form I have a repeater, in the repeater there are some numeric fields, and i need to show the sum of values in these fields at the bottom of the page. This can be done with fd:value-changed and some javascript or custom classes, but actually since they are mentioned on Jira in the roadmap ( http://issues.apache.org/jira/browse/COCOON-941 ), I need them, and they are a good idea, I was wandering how to implement them. I tried prototyping something, and basically arrived to this : .. inside the repeater .. fd:field id=items required=true fd:labelItems/fd:label fd:datatype base=integer/ /fd:field fd:field id=price required=true fd:labelPrice/fd:label fd:datatype base=double/ /fd:field fd:calculatedfield id=subtotal required=true state=output fd:labelSub total/fd:label fd:datatype base=double fd:convertor type=formatting variant=currency/ /fd:datatype fd:algorithm type=arithmetic operation=multiplicate fd:triggersitems,price/fd:triggers /fd:algorithm /fd:calculatedfield outside the repeater ... fd:calculatedfield id=totalitems state=output required=true fd:labelTotal items/fd:label fd:datatype base=integer/ fd:algorithm type=arithmetic operation=sum fd:triggers/articles/*/items/fd:triggers /fd:algorithm /fd:calculatedfield fd:calculatedfield id=totalitemscost state=output required=true fd:labelTotal cost/fd:label fd:datatype base=double fd:convertor type=formatting variant=currency/ /fd:datatype fd:algorithm type=arithmetic operation=sum fd:triggers/articles/*/subtotal/fd:triggers /fd:algorithm /fd:calculatedfield CalculatedField is a subclass of Field, that gets an Algortihm. The Algorithm is a simple interface, responsible for calculating the value and return a list of triggers. Triggers are widgets that will trigger the re-calculation. Calculated fields add value change listeners on all triggers to know when a recalculation is needed, and also to make it update gracefully in ajax. Using triggers you don't have to disseminate the form with value changed listeners to trigger recalculations, and also for simple algorithms (like the arithmetic one I implemented) triggers are the operands on which it operates. This IMMO minimizes mistakes. My calculated field prototype calls algorithm.calculate() in readFromRequest(). Is there a better place? There's a problem to compute the initial value, as trigger widgets may not be initialized (or a calculated-field's initialize() can call initialize() on the widgets it depends on). From there on, you should only react to change events from trigger widgets. I'm also trying to make them editable (if editable=true specified in the definition), so that if the user wants to fine tune the result of a calculation he can modify the calculated value. Obviously, once the calculated field has been modified by the user it will behave like a common field, maybe until the user erases the value bringing the field back to it's calculated nature? Yikes! Heavy FS smell! I tried something to make them also client side, but I don't think it's a good idea. With such a good AJAX support, client side support is rarely useful. Also, it poses a lot of limitations and a lot more work on it : all algorithms should be able to generate a client side counterpart, triggers should be rendered as client side calls to calculateXXX functions. There is no tidy way to do this, and some algorithms would be very difficult to port client side. Also, on client side there is no way of apply proper field formatting, so every form using calculated fields with a format different from plain will end up being a mess. WDYT? This adds more complexity to CForms. But if people consider it useful, well, why not. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: Calculated fields
Simone Gianni wrote: Sylvain Wallez wrote: My calculated field prototype calls algorithm.calculate() in readFromRequest(). Is there a better place? There's a problem to compute the initial value, as trigger widgets may not be initialized (or a calculated-field's initialize() can call initialize() on the widgets it depends on). From there on, you should only react to change events from trigger widgets. Yep, I'm just afraid to perform calculations more than once in a single update. Since i already have a javascript algorithm, I'm afraid of the possible overhead. The trigger widgets currently set a recalculate flag, and in readFromRequest() i actually perform this : - Call super.readFromRequest(). - If super.readFromRequest() parses a typed value, then the field goes in user typed mode and does not perform any calculation. - Else checks if the recalculate flag is set. - In that case call the algorithm. Obviusly this poses the following problem : What if the readFromRequest() is called for the calculate field before the readFromRequest() has been called on triggers?. In that case the following could occurr : - The algorithm would either fail due to a null value or similar. - The algorithm would return a non update value. I tried a fallback for the first situation, when the algorithm cannot compute a value. In that case the algorithm is again called when a trigger notifies a value changed event, but this is untidy and also have no way to handle the second situation. That's why using event listeners is the way to go : the readFromRequest phase buffers all events and actually sends them only once all widgets have read their values from the request. This allows the form model to be globally consistent when event listeners are called. Maybe it would be easier to install a ProcessingPhaseListener, using it this way : - I receive value changed notifications from triggers, and set the flag. - In readFromRequest i only check if the user typed something or not. - When the form notifies it has finished parsing values (and validating them) : ... check if the recalculate flag is set ... in that case call the algorithm ... clear the recalculate flag - Also, since an algorithm may also need values from other calculated fields ... in getValue(), if the recalculate flag is set, call the algorithm. ... also use a calcualting flag, to report an error if a circular calculation is detected. Using the ProcessingPhaseListener is a better solution? WDYT? You need to set a flag when a trigger widget has changed, and do the actual recalculation when all events have been fired. I don't remember if there's an associated phase change event that could be used for that. There's a potential problem though if a trigger widget is itself calculated. Or calculated fields must explicitly call the calculate() methods of their trigger widgets that are calculated. I'm also trying to make them editable (if editable=true specified in the definition), so that if the user wants to fine tune the result of a calculation he can modify the calculated value. Obviously, once the calculated field has been modified by the user it will behave like a common field, maybe until the user erases the value bringing the field back to it's calculated nature? Yikes! Heavy FS smell! FS? Fun Stuff? Free Style? Fiancial Service? :) Flexibility Syndrome, i.e. over-design or YAGNI (you ain't gonna need it). I don't see the use case for it. I tried something to make them also client side, but I don't think it's a good idea. With such a good AJAX support, client side support is rarely useful. Also, it poses a lot of limitations and a lot more work on it : all algorithms should be able to generate a client side counterpart, triggers should be rendered as client side calls to calculateXXX functions. There is no tidy way to do this, and some algorithms would be very difficult to port client side. Also, on client side there is no way of apply proper field formatting, so every form using calculated fields with a format different from plain will end up being a mess. WDYT? This adds more complexity to CForms. But if people consider it useful, well, why not. -1 for client side. As i wrote, it brings A LOT of complexity, for formatting, double implementation of everything (algorithm must be wrote both for server side and for client side, both for us and for the user), a lot of untidy stuff needed to do it, and it's relatively useless with current great AJAX support. I think it was written in the Jira issue because at that time Ajax was still far. I wasn't speaking of the client side, but only about the increased complexity of the form definition. This adds a new widget type (not that much a problem) and more expression languages... Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [Vote] Release 2.1.9 tomorrow
Carsten Ziegeler wrote: Please cast your votes for releasing the current svn as 2.1.9 tomorrow. A late +0 (did not had time to test) Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: cvs.a.o dependency reduction
Jorg Heymans wrote: fyi, I've removed daisy-util, daisy-htmlcleaner and xreporter-expression from cvs.a.o as they are now on ibiblio. Note that the groupid has changed and that daisy-util is now transitively depended on through daisy-htmlcleaner. The whole process ([1], [2] and [3]) took about 10 days, which isn't that bad I guess. Well, considering the manual process required for this, yes. Now this leads to a question I haven't found an answer to: is it possible with M2 to have local dependencies, i.e. jars that are in _no_ repository, just like the lib directory in our 2.1 branch? That would avoid having to maintain a local repository as an interim place for the main one. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: The all embarassing presentation email :-)
Simone Gianni wrote: Hello everybody all and thanks to all of you for voting me as a committer. I'm so excited to become part of the ASF, expecially within the cocoon project who driven my web developing experience in the last 6 years. I wanted to let you know something about myself as per the Cocoon tradition: I assume you all know how embarassing it is to talk about oneself, so I'll just get on with some random notes. :) I'm 27 and I live in Rome, Italy. I started programming when i was about 7 with C64. It happened for a simple and completely random situation : i received a C64 and a game, inside the C64 box there were two manuals, a short one to run the game, and a big one teaching basic programming. A question: what language where these books written in: English or Italian? I'm always amazed to see kids learning to program right after learning to read. Computers weren't widespread when I was 7 (that was in 1974) and I only started at 13, having already some english background. I tried the small one, but since the game wasn't working i tried to read the big one and simply type what was written there, but it took time (and a lot of LOGO programming) to discovered why 10 print ciao 20 goto 10 caused a lot of ciao on my screen :) I decided not to attend university and started working as a freelance. Perl first and PHP/mysql then were the leading technologies back in 1997. For another incredibly random situation, I arrived in Milan in march 2000 to work for Bibop Research, which some of you might remember, where I had the incredible opportunity to work with Gianugo Rabellino, Ricardo Rocha and meet people like Stefano Mazzocchi and many other very skilled guys. I left Bibop a few months later, but this experience pushed me into Cocoon. Wow, Bibop again? Looks like Cocoon wouldn't have been there if Bibop had not existed :-) I currently own a small company, and we work mainly with Cocoon. In the last couple of years we've been collaborating a lot with Pronetics (and from now on with Sourcesense) on intranet applications heavily based on cocoon-forms (a corporate banking and an administration system for a university, a total of about 300 cocoon forms, being the leading projects), binding directly on backend beans, so actually my main area of interest is cocoon forms and more specifically it's interaction with beans and backend persistence (with a strong focus on Hibernate lately). Cool. I understand now your interest in CForms! But I'll not limit my work to this field, I look forward to help out consolidating, improving and expanding this great framework, and I'm thrilled to be part of this incredible community. Thanks again to everyone who voted me: I consider being over here a great accomplishment. Eh, welcome aboard Simone! Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: AJAX and web testing
Simone Gianni wrote:
Hi All,
we recently moved to ajax in our latest project. We use Selenium for
web tests. After the move we had a lot of problems with Selenium. This
is what happens :
- Selenium executes a SelectAndWait (or clickAndWait)
- It then waits for a page reload
- It detects a page reload using an onload on the test iframe.
- Obviously, ajax does not reload the page, so Selenium waits for ever.
The only relevant document i've found about this matter on the
internet (
http://www-128.ibm.com/developerworks/java/library/wa-selenium-ajax/index.html
) uses the worse solution : pauses 500 ms after a click.
We currently modified selenium to achieve a different behaviour : the
cocoon forms _handleBrowserUpdate and _continue are overridden at run
time with two custom functions that triggers Selenium page reloaded
event after a _handleBrowserUpdate unless a continue has been received.
This solution works correctly, but it's a hack. IMMO we should find a
better solution for executing webtests on a cocoon ajax enabled site
... just some random thoughts :
- Support and document how to use Dojo AOP to wrap a method around
cocoon ajax calls (I tried this one but didn't managed to make it work).
- Provide some classic javascript hooks inside the cocoon ajax code,
so that implementing some jsavascript functions a web test suite can
be notified when an ajax transaction is started and ended.
- If there is a way of doing this not touching the cocoon ajax code (i
was thinking about instrumenting/intercepting the
dojo.hostenv.getXmlhttpObject()) we should document it somewhere.
I've already opened a bug for this problem on Selenium Jira, and could
probably submit a solution if we find a way to make it dojo based
and not that cocoon specific as the one I used.
You can do it using Dojo's nice AOP features to intercept the method
that handles the browser update sent by Cocoon:
script
dojo.addOnLoad(function() {
dojo.require(cocoon.ajax.BUHandler);
dojo.event.connect(cocoon.ajax.BUHandler.prototype,
processResponse, function() {
alert(Page has been updated!)
})
});
/script
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: The all embarassing presentation email :-)
Simone Gianni wrote: Sylvain Wallez wrote: A question: what language where these books written in: English or Italian? I'm always amazed to see kids learning to program right after learning to read. Computers weren't widespread when I was 7 (that was in 1974) and I only started at 13, having already some english background. Surprisingly it was in Italian. Then when i started Logo (a suggestion from a friend of my father when i told him i was doing weird stuff with basic on C64), I asked my father to buy a book on logo, but he took me a book in english, since it was hard to understand it, I asked my father to go back to the bookshop and take a The same book on logo, but the italian version, and he took me a book about Logo in italian, but unfortunately for the Italian version of Logo, where all commands were translated ... FW was translated in AV, RT in DS etc .. :) Oh, I remember something similar on my Apple II: some people provided a translated version of the Basic keywords, and were calling this dialect Basicois. Totally ununderstandable if you already knew the original Basic, even without knowing english ;-) My personal suggestion is to try to go for english, since it would improve both english and technical skills at once, but since a foreign language is often hard to approach, maybe starting with something simple and child-friendly (like Logo was, today what?) in native language can give the child the right interest and movivation to try an english book later. I found some nice material in french for my kids for PHP and Python. But the oldest one (14) has switched for quite some time now to the english docs: the Python reference manual is currently on his night table! Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: cvs.a.o dependency reduction
Jorg Heymans wrote:
Sylvain Wallez wrote:
Well, considering the manual process required for this, yes.
Now this leads to a question I haven't found an answer to: is it
possible with M2 to have local dependencies, i.e. jars that are in _no_
repository, just like the lib directory in our 2.1 branch? That would
avoid having to maintain a local repository as an interim place for the
main one.
I think that the minimum requirement is to have the libs in a
repo-compliant directory structure.
It might however also be possible to define a repository using the file
protocol, like:
repository
idlocalfilerepo/id
namecustom repo/name
urlfile://my/repo/dir/url
/repository
Yeah, I used something similar to host a fake repo:
repository
idcom.example.project/id
urlfile://${basedir}/local-repo/url
/repository
but i haven't tried this yet. In any case, constructs like this defeat
the purpose of what maven is (should be) all about. The long term
solution lies in maven advocacy towards other projects, as frustrating
as this may sound.
Sure, but there are situations when you have either some jars that
cannot be deployed on a repository, either because they're highly
specific or proprietary.
Anyway, thanks for the confirmation.
Sylvain
--
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member
Re: Dojo too fat?
Antonio Gallardo wrote: Please see the report below. Comments? snip/ http://cocoon.zones.apache.org/demos/21branch/_cocoon/resources/dojo/dojo.js 145 kb Dojo is a highly modular toolkit, which can load new JS scripts on demand (using Ajax requests). However, loading individually each and every module leads to an important overhead in page load time. To solve this, Dojo provides a compressor [1] that assembles a set of modules (JS files) in an single dojo.js file and compresses it (removes whitespace and comments, shortens identifiers). Browsers will then cache this dojo.js file, so that only the first use is costly. The work of the compressor is driven by a profile where you describe what modules you want to integrate in that single file. For Cocoon, I used the widget profile which includes the base infrastructure and a number of widgets (see blocks/ajax/dojo/build.xml). The actual profile to be used in a production system should normally be adapted to the actual modules your application uses to achieve maximum performance. We cannot guess within Cocoon what this module set will be, but what we can do is define a profile containing only the Dojo features that are effectively used by what we provide (i.e. the widgets in the forms and ajax blocks). That may allow to have a smaller default dojo.js, while still leaving room for people to build their own version of dojo.jar with their own profile. BTW, Dojo's is very successful, and some CDNs are providing it [2], thus allowing applications to load the full dojo.js from a central location. One single cached JS files served by distributed servers for many unrelated web sites! [1] http://dojotoolkit.org/docs/compressor_system.html [2] http://blog.dojotoolkit.org/2006/01/30/dojo-iamalpha-and-cdns -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Upayavira wrote: Ah, I wasn't getting that subtle. I was simply saying that I can agree with using the servlet API for _all_ environments. The CLI becomes nothing more than a custom servlet container that uses a servlet to generate its pages. In fact, having said that, it becomes yet another tool that is actually independent of Cocoon - it could be used to crawl pages generated by _any_ servlet, not just the Cocoon one. Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Carsten Ziegeler wrote: Sylvain Wallez wrote: Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [CForms] Form id not propagated?
Carsten Ziegeler wrote: I'm setting the id on a form in the model and it seems that neither the cforms transformer nor the jx macros propagate this id to the resulting html, so a simple ft:form-template action=. method=POST is not enough. Currently I have to repeat the id, like: ft:form-template id=something action=. method=POST which should be imho unnecessary as the id is already specified in the model. Is this a bug or a mistake on my site? Looking at the code, the id attribute is not output when the form has no id, but should be produced otherwise... Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
[vote-results] Simone Gianni as a new Cocoon committer
Hi all, Simone Gianni has been elected for Cocoon committer ship with 25 +1 and no -1 (and a non-binding +1 from Gianugo). I asked Simone for his preferred user id in order to send the account creation request. Welcome on board Simone! Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [CForms] Form id not propagated?
Carsten Ziegeler wrote: Sylvain Wallez schrieb: Carsten Ziegeler wrote: I'm setting the id on a form in the model and it seems that neither the cforms transformer nor the jx macros propagate this id to the resulting html, so a simple ft:form-template action=. method=POST is not enough. Currently I have to repeat the id, like: ft:form-template id=something action=. method=POST which should be imho unnecessary as the id is already specified in the model. Is this a bug or a mistake on my site? Looking at the code, the id attribute is not output when the form has no id, but should be produced otherwise... So it should work? Can you point me to the source where this is done? It's in o.a.c.forms.formmodel.AbstractWidget.getXMLElementAttributes() Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [CForms] Form id not propagated?
Carsten Ziegeler wrote: Sylvain Wallez schrieb: It's in o.a.c.forms.formmodel.AbstractWidget.getXMLElementAttributes() Yes, but I think this one is never called in the case of a form. For example in the case of the jx macros, the startForm() method in the JXMacrosHelper class is used and I think the above method is never called from there. Doh! You're totally right. Neither JXMacrosHelper nor EffectWidgetReplacingPipe (the transformer) produce the attribute... Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: CForms and Portlets - making form ids dynamic
Carsten Ziegeler wrote: Sylvain Wallez schrieb: What about simply adding Form.setId(String formId)? Yes, that was my first thought as well - but I was wondering if it's a good idea to always allow to change the id. So I thought that if the id is dynamic, it should be part of the constructor - therefore the above changes. But of course just adding setId() works fine as well. It seems to me that the form writer should not have to care about setting a dynamic ID on the form, as it's more an integration concern (a form could run equally well standalone or within the portal). Is there a simple test that can be performed (without introducing a dependency on the portal block) that can allow us to detect that we're running as a coplet and then set a dynamic ID on the form? Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
