Re: [RT] Releases
Niclas Hedhman wrote: Cocoon community is IMHO too focused of NOT releasing something BAD, instead of focusing on releasing the new and good stuff. If releases came out on a bi-weekly basis, who would be worried that a bug or two sneaked in. Patch and it will be fixed in days. And with so many community members having sites deployed off the HEAD, I doubt that much regression would occur in reality, and committer sensibility is another 'safety net'. My two cents. Is this your perception of just Cocoon or all open source development. What you are suggesting is unacceptable for use in a production environment. When I release my product I don't want to have update the framework every two weeks. And if there is a bug, the next release probably won't be any better. Sure the bug might have been fixed, but now will just have new ones because of all the new stuff. When you deploy your production application on Tomcat or JBoss just how often are you updating your container? We do it only when we have a new release of our product coming out. We expect the frameworks we use to be stable. And Cocoon is just another container just like Tomcat or JBoss. I, for one don't deploy from head. I pick a stable release and use that and then apply any patches I need to it after extensively testing. By trying to minimize(!) the number of new features in each 2.x.0 release, the users have less learning to cope with, when 'inhaling' a new feature release. Going from 2.0 to 2.1 or 2.1 to 2.2 is overwhelming, especially if you have not followed the dev-list. This is a problem because the Cocoon core (i.e. - practically everthing) is too big. Real blocks are the answer, not changes to release management. Further down the road, breaking codebase system apart, allowing individual release cycles for core vs each block should also help in shortening the cycle. Here I absolutely agree. But until this is accomplished I am not in favor of creating an unstable codebase. Ok to release? yeah, yeah, yeah. I'll do it! ./release.sh 2.5.1[enter] done. Cheers Niclas Ralph
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Sylvain Wallez wrote: Uh? What are these features? Would you mind sharing this with us? Sure; I already mentioned this months ago and even asked on this list for help; but noone was interested :( Actually, I was and am interested. I just can't get my boss to let me spend any time on it. Anyways, I'm thinking of adding a JMX interface, so you can monitor your Cocoon instance using JMX. I'm not sure which values you can monitor, but I'm thinking about monitoring the container (pool sizes etc.) and some configuration values for the first version. The second part - which is much more difficult - would be to allow to change some values during runtime. But this cause a lot of problems and I wanted to write an RT in the next days about it. Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. Carsten Ralph
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote:
Actually, OSGi is a key point in the performance improvements in the
upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were
still written on the previous kernel API, and the more plugins move to
the OSGi API, the more startup time increases and memory used decreases,
by allowing on-demand loading of plugins.
See also:
-
http://download.eclipse.org/eclipse/downloads/drops/S-3.1M7-200505131415/eclipse-news-all-M7.html
(second item)
- http://www.eclipse.org/eclipse/development/performance/index.html (the
performance bloopers page is a very interesting read)
the performance boost is incredible! Eclipse is up and running within about 5
seconds! That's great!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Micro kernel use cases?
Bertrand Delacretaz wrote: Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit : ...It would require quite a lot of work to give a fair overview of what we have discussed about this in the last three or so years. You find some info in http://wiki.apache.org/cocoon/Blocks... Would it be possible to come up with a (small) set of blocks-oriented use cases to re-sync our collective vision of what a micro-kernel Cocoon would bring? I'm thinking of use cases like start the Cocoon kernel, load a block at startup, locate and download a block after startup, debug my block during development, use a block service from my own code, etc. 1. Start Cocoon kernel. 2. Load Portal Application which causes: 2a. Load Portal block dependencies. 2b. Load Portal block. 3. Configure portal application which causes: 3a. Load Internal Portlet block dependencies. 3b. Load Internal Portlet blocks. 3c. Configure Internal portlets. If this can be made to work along with reloading portlets I would be ecstatic Hmm. This also makes me wonder if the PortalManagers couldn't be modified to take advantage of this now without modifiying the Cocoon core, at least with respect to portlets. I don't know if the granularity is right, but having a set of use-cases (not more than about two A4-pages?) might make it easier to agree on concrete ideas. -Bertrand
Re: [RT] Micro kernel based Cocoon
Ralph Goers wrote: Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. And what happens after you updated a value. Changing pool sizes or something like that is easy. But what about changing some core settings like the working directory (this is just an example, I don't say/know if that makes sense)? Several components use the working directory, so either you have to reinstantiate them or notify them or something like that. But neither option is really nice. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Releasing 2.2
Ralph Goers wrote: I doubt many will switch until 2.2 is stable - i.e we've had a few releases of it. I would recommend that we continue doing maintenance on 2.1 until at least a stable 2.2.0 is released and possibly a release or two later. That doesn't mean that new features need to be backported to 2.1 though. Exactly. It took a long time until the majority updated from 2.0 to 2.1; and still there are many installations out there using 2.0.x. So we have to maintain 2.1.x for a long time. But as soon as 2.2 is final we don't have to sync the branches anymore, just for bugfixes. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Ralph Goers wrote: Why is updating more difficult. We have MBeans that do both. Creating an operation that updates isn't that hard. The hard part is figuring out what you want to manage. And what happens after you updated a value. Changing pool sizes or something like that is easy. But what about changing some core settings like the working directory (this is just an example, I don't say/know if that makes sense)? Several components use the working directory, so either you have to reinstantiate them or notify them or something like that. But neither option is really nice. Carsten Sorry. I got the wrong impression from your earlier message. I thought you were implying that writing the MBeans to change things was somehow harder. Yes, some operations will be harder to perform than others. And in some cases an operation might be deemed too difficult to do, at least at first. However, I wouldn't go looking for operations to perform just because you can. I would start by identifying the operations you would find valuable and then prioritize them by need and difficulty to implement. Would your hypotheical of changing the working directory even make that list? Ralph
Re: [RT] Releases
On Monday 23 May 2005 14:18, Ralph Goers wrote: Is this your perception of just Cocoon or all open source development. I would say all software development. IMHO, frequent smaller changes is by far a much more effective way to progress a codebase. The longer the cycle, the more important your points below becomes. When I release my product I don't want to have update the framework every two weeks. And if there is a bug, the next release probably won't be any better. Sure the bug might have been fixed, but now will just have new ones because of all the new stuff. This is the typical argument against frequent releases. I happen to disagree that next release won't be any better, because of new bugs. If it is worse, then the people behind the product is careless. New bugs have a strong tendency to appear in new code (refactorings included), mostly not because smaller fixes of found problems. But until this is accomplished I am not in favor of creating an unstable codebase. Of course noone is in favour of creating a unstable codebase _of_what_is_being_used_. Take Ant as an example of fairly good release management (cycles slightly longer than I would like, esp 1.6.2 - 1.6.3, but still...) The 1.6 branch has had 5 releases in ~ a year and half. In those releases, the 1.7 features are added along side with bug fixes. The 1.7 features have had quite a lot of bugs (relatively speaking). Does that make Ant 1.6 unstable?? IMO, not at all. Do you have a problem using the latest Ant, without extensive internal testing? I don't think you have a problem. What is expected to work, works. The new stuff is somewhat shaky. Typical for software evolution. Cocoon is strange, since so called 2.2 features were 'back ported' to 2.1, to a point where even some experts here is not sure what 2.2 is actually offering over 2.1. Doesn't this make 2.1 unstable as well, then? Suggestion; Try it. If it doesn't work, you can always go back. And if it makes you feel better, put some large disclaimers on the parts that you think is unstable. Listen to the founding fathers of this project, who declared (and lived by it in the 1.x days) Release Early, Release Often. Everyone here talks about it, but doesn't live by it. Cheers Niclas
Re: [RT] Releases
Niclas Hedhman wrote: Listen to the founding fathers of this project, who declared (and lived by it in the 1.x days) Release Early, Release Often. Everyone here talks about it, but doesn't live by it. I have no problem with release early, release often. I just have a problem with code instability. I believe that 2.1.6 and 2.1.7 are more stable, in general, than the earliest 2.1.x releases, despite some new features being added. However, that is a far cry from where we'd be if some of the things that are in 2.2 had been added to 2.1 in a maintenance release. Cheers Niclas
DO NOT REPLY [Bug 35018] New: - [Link] Le Renard
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35018. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35018 Summary: [Link] Le Renard Product: Cocoon 2 Version: Current SVN 2.2 Platform: All URL: http://cyriaque.Dupoirieux.free.fr/accueil.html OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] URL of the LiveSite : http://cyriaque.Dupoirieux.free.fr/accueil.html Title : A mon avis vous faites erreur ... Cocoon version : Cocoon SVN 2.2 Short Summary : Familly site How can we verify this site is actually built with Cocoon? This site is generated with Forrest dev-0.7 (SVN) How much time did it take to build the site from design to publication? Several month to write the content, few minutes to generate the whole site in HTML and pdf. How many people were involved in the project? Just me. How much traffic does the site handle? Arround 10 per day at the moment... What made you choose Cocoon to build the site? The ability to easily generate in HTML and pdf. Can you provide a contact email address if people want further information? I have a contact page in the site. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [RT] Micro kernel based Cocoon
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: All current blocks, the core and libraries that are used by several bundles are packaged as bundles. These are deployed in a OSGi kernel. During development the Cocoon bundles can be deployed within the OSGi kernel of Eclipse together with various Cocoon develpment plugins (bundles). And during deployment the Cocoon bundles are deployed in a standalone kernel that either is started from within an servlet or at top level and contains a http server. The OSGi kernel is like an OS kernel. It takes care about starting and stoping bundles and to resolve dependencies between bundles and gives them a parent classloader containing their dependencies. The above means that we can get a much higher level of isolation beween different parts of core and between blocks. As the bundles don't need to expose all classes to everyone anymore. This is something that we allready need quite badly IMO, and a must if we wish to make it possible for external communities to develp Cocoon blocks. Ok, so far so good - now, what do I have to do if I'm developing my own application and want to use let's say the cron block: I want to add my own scheduled task? Currently I have to know a little bit about Avalon: using the service manager to lookup the component. Or to put it in other words, I have to know what the service locator concept is. And that's all. How does this look like with OSGi? And in this context, if I'm developing an own application, does this have to be an OSGi bundle as well? Read the subsections The main sitemap and The Cocoon service in the first post in this thread http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=111659636932761w=2. The application need to be a bundle, but that only means that there need to be a manifest file in it. Also the dependency information that we now handle in a rather implicit compile time way in blocks.properties, will need to be declared within the sitemap bundle. Everything else will be as before, you use the service manager for lookup as always. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=11164826501r=1w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=11182531907w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow? Is there anythimg more? sitemap listeners, VPCs, I'm waiting for community involvement. If we follow Vadim's suggestion http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111331073205551w=2, nothing in core need to depend on vpc code and the vpc code could be moc´ved to an own (unstable) block. third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto no release policy will continue. /Daniel
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? /Daniel
Re: Releasing 2.2
Le 23 mai 05, à 08:06, Ralph Goers a écrit : ...I doubt many will switch until 2.2 is stable - i.e we've had a few releases of it. I would recommend that we continue doing maintenance on 2.1 until at least a stable 2.2.0 is released and possibly a release or two later. That doesn't mean that new features need to be backported to 2.1 though... And that's the big difference IMHO. Once we can say that 2.1 is strictly in maintenance mode, with new features being added to 2.2 only, the syncing work would be much less. But this means getting at least an alpha release of 2.2 out of the door, I think. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Ralph Goers wrote: However, I wouldn't go looking for operations to perform just because you can. I would start by identifying the operations you would find valuable and then prioritize them by need and difficulty to implement. Would your hypotheical of changing the working directory even make that list? I honestly don't know :) - I tend to not include it. I started separating the available settings into not changeable and dynamic ones (see the interfaces BaseSettings and DynamicSettings in the core package). But that was just an initial random selection. Perhaps we end up with only a few dynamic settings. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Releasing 2.2
As a matter of fact, Leszek provided a fix last week for what seems to me to be a pretty serious bug in flow and this alone should warrant a 2.1.8 release. Hi Ralph, We are about to go to production with an application built on 2.1.7 that uses flow heavily. Could you point me in the direction of this bug that Leszek has fixed so i can work out whether we are affected. Regards, Paul.
Re: Releasing 2.2
Carsten Ziegeler wrote: Ralph Goers wrote: I doubt many will switch until 2.2 is stable - i.e we've had a few releases of it. I would recommend that we continue doing maintenance on 2.1 until at least a stable 2.2.0 is released and possibly a release or two later. That doesn't mean that new features need to be backported to 2.1 though. Exactly. It took a long time until the majority updated from 2.0 to 2.1; and still there are many installations out there using 2.0.x. So we have to maintain 2.1.x for a long time. But as soon as 2.2 is final we don't have to sync the branches anymore, just for bugfixes. I think you are mixing cause and effect: 2.1 and now 2.2 become unstable because we *let* them become unstable. We removed them from extensive user testing and feedback by marking them usstable. And user testing and feedback is the only thing that creates *real* stability. As developer your testing is always limited to your own prejudices about what the feature should be used for. By marking the 2.1 and 2.2 unstable we also created the impression that it is ok to add new features without discussions and tests and that someone else will take care of the problems later. Also it creates discontinuity, people avoid going 2.0-2.1 and 2.1-2.2 because so many changes has been allowed to add up during the years between the minor releases, so that it will require a lot of work to port. As we have let this happen for 2.2 we must of course maintain 2.1 for a while and go through an alpha-beta-stable cycle for 2.2. But I really think we should avoid this mess in the future. --- o0o --- So lets evaluate what we have gained by spliting in a 2.1 and 2.2 branch. It was supposed to be necessary for developing real blocks, I don't see that it has helped us and I fail to see why it should be necessary. And as being active in this area I should know at least somthing about it. If we take a look on what is new in 2.2, we copied the ECM to the Cocoon repository and changed the package names. I don't think that introcuced any instabillity. After that there have been various refactorings of ECM. If these have introduced back incompabilities, there should have been votes about it, if there hasn't been votes it rather shows that it is dangerous to have a playground branch. I don't think that the introduction of includes in cocoon.xconf, lazy loading of components, local classpath for sitemaps, or hosting of other IoC containers (see http://www.anyware-tech.com/blogs/sylvain/archives/000171.html) should have caused any incompability or instability for those not using it. For those things I have been involved in: JXTG refactoring was done without disturbing uses of the original one until the community felt confident with switching. The same process could have been followed in a stable branch. And we probably would have got more testing as the ablity to use it without flow is a feature that several users have asked for. VPCs have not affected existing functionality, they could actually even have been developed in an own block. My work on Sitemap blocks haven't affected any existing functionality either and can be moved to a block if we want. --- o0o --- Probably I'm missing important aspects, but I fail to see what the split into trunk and stable have bought us, except for less testing, disruption and possibly sloopier coding as the branch is supposed to be unstable anyway. /Daniel
Re: [RT] Releases
Reinhard Poetz wrote: Daniel Fagerstrom wrote: Don't know. Reinhard and maybe Sylvain at least seem to use it for customer systems maybe there are more. Yes, it's my plan to use trunk for my current customer application because I want to use the new jxtemplate implementation and the per-sitemap-classloader that makes development so much easier. As my application will be used in a high-traffic application, expect some stress tests in the next weeks. From my recent jxtemplate tests I have the sense that trunk performs very well. Would you have time to compare old and new JXTG implementation? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.2
Daniel Fagerstrom wrote: --- o0o --- Probably I'm missing important aspects, but I fail to see what the split into trunk and stable have bought us, except for less testing, disruption and possibly sloopier coding as the branch is supposed to be unstable anyway. One of the main reasons for creating 2.2 are incompatible changes. We removed some deprecated api and stuff like that in 2.2; so it's not that easy to just run an application for 2.1.x using 2.2 - you might be affected by the changes. So we provide compatibility with 2.1.x. We give the users the guaranty that they can safely update from 2.1.x to 2.1.x+1 (ok, there are exceptions to this rule). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
On 15.03.2005 23:33, Sylvain Wallez wrote: Again and again, there is no such readonly attribute. You can set the state of a widget to disabled which leads to something similar to what you describe: the input is readonly, and the calendar icon is still visible but disabled. There is, but it's pure HTML. It has nothing to do with CForms. Unknown attributes on fi:styling are just copied to the output, e.g. @class and also @readonly. I did not have a look at CForms since the adding of the states, so I don't know how much in the meantime is handled automatically and no longer in the template. Joerg
Re: Sitemap problem... help! :-)
On 30.01.2005 21:32, Mark Lundquist wrote: It can be argued that it should be possible to match any continuation resource in any context and have it resumed correctly. The rationale is the intuition that the sitemap context is part of the control thread being resumed. I agree. Isn't it possible to handle a wrong interpreter like a not matching matcher and resume searching for another handler of the continuation? We also don't throw an exception when the first matcher does not match ... Joerg
Re: Releasing 2.2
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: --- o0o --- Probably I'm missing important aspects, but I fail to see what the split into trunk and stable have bought us, except for less testing, disruption and possibly sloopier coding as the branch is supposed to be unstable anyway. One of the main reasons for creating 2.2 are incompatible changes. We removed some deprecated api and stuff like that in 2.2; That is a reason for increasing minor version, but not for maintaining parallell branches for years. /Daniel
Re: [VOTE] Alfred Nathaniel as committer
On 09.04.2005 12:10, Bertrand Delacretaz wrote: So, I'm pleased to propose Alfred, should he accept the nomination, as a committer. Of course, my secret hope is that he will contribute many additional automated tests, but the committment is to the project, not to a particular task! Back to an internet connection finally my +1. Joerg
Re: Releasing 2.2
Daniel Fagerstrom wrote: That is a reason for increasing minor version, but not for maintaining parallell branches for years. If we don't maintain the old 2.1.x branch, what about all its users? Do you want to force them to migrate to 2.2? That's simply not realistic. We should be able to provide bug fixes for all those out there using our project. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
OK; I was unaware of the meaning of the flags in bugzilla. I have a second patch for the trunk branch, but have not inserted it into Bugzilla yet. Will do so this afternoon... As for committing, I cannot as I am no Cocoon regular developer. Could someone else do so? James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sun 22/05/2005 22:41 To: James Bates Subject: DO NOT REPLY [Bug 34906] -[Patch] User-Agent is PARAMETER, not HEADER in Command-line interface DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34906 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|User-Agent is PARAMETER, not|[Patch] User-Agent is |HEADER in Command-line |PARAMETER, not HEADER in |interface |Command-line interface --- Additional Comments From [EMAIL PROTECTED] 2005-05-22 22:41 --- AFAICS this patch has not been committed yet, so it is better to not set the bug to fixed. Otherwise the patch won't be applied. Joerg -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter.
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
2005/5/23, Bertrand Delacretaz [EMAIL PROTECTED]: Hi Sebastien, ...I've just published four new ideas on my blog.. About Typo3-like documentation matrix - I've been thinking for a while that a matrix of our *samples* would be a big help: having all samples listed on a single page (and possibly categorized or folksonomized) would make it much easier to find which sample demonstrates a given problem. I haven't found time to implement this yet, but it shouldn't be too hard given that the samples table of contents page is generated out of individual .xsamples documents. You're totally right and you remember me that samples should be part of Cocoon documentation as well as any other document. Maybe we could integrate that in Planet Cocoon range. WDYT ? Would you like to help us in that matter ? -- Sébastien Arbogast
NullPointerException building cocoon for forrest
Hi, Since this version: http://svn.apache.org/viewcvs.cgi?rev=164112view=rev I am getting a null pointer exception when runnig forrest: Exception in thread main java.lang.NullPointerException at org.apache.cocoon.Cocoon.initialize(Cocoon.java:177) at org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283) at org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:175) at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98) at org.apache.cocoon.Main.main(Main.java:320) Can someone put some light on how to fix it? Cheers, cheche
Comparing jxtemplate formsTransformer implementations
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Don't know. Reinhard and maybe Sylvain at least seem to use it for
customer systems maybe there are more.
Yes, it's my plan to use trunk for my current customer application
because I want to use the new jxtemplate implementation and the
per-sitemap-classloader that makes development so much easier.
As my application will be used in a high-traffic application, expect
some stress tests in the next weeks. From my recent jxtemplate tests I
have the sense that trunk performs very well.
Would you have time to compare old and new JXTG implementation?
It's on my todo-list to compare jxtemplate (old and refactored one) and
formsTransformer (before and after the changes by IIRC Vadim) implementations in
the next days and the next weeks as I will have to test-drive my current
customer application.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Releasing 2.2
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: That is a reason for increasing minor version, but not for maintaining parallell branches for years. If we don't maintain the old 2.1.x branch, what about all its users? Do you want to force them to migrate to 2.2? That's simply not realistic. We should be able to provide bug fixes for all those out there using our project. Have never disputed that we have to maintain 2.1 for some while and that we must go the alpha-beta-stable cycle for 2.2. My message is that I fail to see that we gained anything from creating an unstable development branch and that we should avoid doing that mistake in the future. If we want to remove deprecated code, we have a routine for that: wait long enough time, so that everyone have had the chance to do anything, vote about it, remove the code and step up the minor number. If we at that point feel that we still need to maintain the previous version, it means that we removed the deprecated code to early and the we probably should readd it and schedule the removal to the next minor release. Mainteining two versions because of to early removal of deprecated code seem like a bad idea. For API changes the situation is obviously more complicated, so we must really know what we are doing and if possible make it possible to use the new and the old in parallell for some while. If this can't be done, we need to maintain an old branch for a period. But in this case we should try to decide for how long time we maintain it and remove it afterwards. And it should IMO be marked as a compability branch rather than the stable one. IMO we should really try to let trunk contain the stable branch in the future. The idea of an unstable development doesn't seem to fit well with our *actual* community dynamics. And it doesn't fit well with agile development methods either. And it is IMO highly questionable if it has done anything good for us since 1.0-2.0. To me it rather seem to hurt us. /Daniel
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Ok, so far so good - now, what do I have to do if I'm developing my own
application and want to use let's say the cron block: I want to add my
own scheduled task? Currently I have to know a little bit about Avalon:
using the service manager to lookup the component. Or to put it in other
words, I have to know what the service locator concept is. And that's
all. How does this look like with OSGi?
And in this context, if I'm developing an own application, does this
have to be an OSGi bundle as well?
Read the subsections The main sitemap and The Cocoon service in the
first post in this thread
http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=111659636932761w=2.
The application need to be a bundle, but that only means that there need
to be a manifest file in it. Also the dependency information that we now
handle in a rather implicit compile time way in blocks.properties, will
need to be declared within the sitemap bundle. Everything else will be
as before, you use the service manager for lookup as always.
I had a look at OSGi manifest files and I think we can generate out of our block
descriptors (block.xml) with the result that somebody who is writing a Cocoon
block doesn't even has to know that Cocoon is based on OSGi.
BTW, for all German speakers who have access to German magazins: Currently OSGi
seems to be a hot topic: In the current issues of Eclipse Magazin (05/03) and
Java Spektrum (05/02) there are articles about OSGi. The Eclipse Magazin
describes OSGi in Eclipse (of course) and the Java Spektrum article shows how to
use Oscar.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: NullPointerException building cocoon for forrest
Juan Jose Pablos wrote: Hi, Since this version: http://svn.apache.org/viewcvs.cgi?rev=164112view=rev I am getting a null pointer exception when runnig forrest: Exception in thread main java.lang.NullPointerException at org.apache.cocoon.Cocoon.initialize(Cocoon.java:177) at org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:283) at org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:175) at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98) at org.apache.cocoon.Main.main(Main.java:320) Can someone put some light on how to fix it? You're using trunk? Great :) Now, the CLI is (obviously) not working atm. The creation of an environment (like cli, servlet etc) has been simplified (or rewritten...) and only the servlet environment uses the new mechanism. So the solution is to change the CocoonBean and let it use the new CoreUtil class (like the servlet class already does). So, the CocoonWrapper class should use the CoreUtil - this should reduce the code there as well. Rewriting this is on my agenda for the next days. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
DO NOT REPLY [Bug 34590] - JSTL support broken in Cocoon 2.1.7
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34590 --- Additional Comments From [EMAIL PROTECTED] 2005-05-23 14:05 --- Upgrading web.xml from web-app_2_3.dtd to web-app_2_4.xsd should solve the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Server-side image map in CForms ?
Folks, I need a server-side image map with Cocoon Forms. AFAIK there's no such a widget in Cocoon 2.1.7... hence, my question: is there someone already working on it or should I start from scratch ? Regards, P.S. I will contribute the results of my efforts... provided they're good enough, of course. Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Luca Morandini wrote:
Folks,
I need a server-side image map with Cocoon Forms. AFAIK there's no such
a widget in Cocoon 2.1.7... hence, my question: is there someone already
working on it
not that I know of
or should I start from scratch ?
Regards,
P.S.
I will contribute the results of my efforts... provided they're good
enough, of course.
Fine!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
DO NOT REPLY [Bug 34906] - [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34906 --- Additional Comments From [EMAIL PROTECTED] 2005-05-23 14:41 --- Created an attachment (id=15131) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15131action=view) patch against trunk (2.2.X) branch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
RE: [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
DONE -Original Message- From: James Bates [mailto:[EMAIL PROTECTED] Sent: 23 May 2005 11:53 To: [EMAIL PROTECTED] Subject: Re: [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface OK; I was unaware of the meaning of the flags in bugzilla. I have a second patch for the trunk branch, but have not inserted it into Bugzilla yet. Will do so this afternoon... As for committing, I cannot as I am no Cocoon regular developer. Could someone else do so? James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sun 22/05/2005 22:41 To: James Bates Subject: DO NOT REPLY [Bug 34906] -[Patch] User-Agent is PARAMETER, not HEADER in Command-line interface DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34906. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34906 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|User-Agent is PARAMETER, not|[Patch] User-Agent is |HEADER in Command-line |PARAMETER, not HEADER in |interface |Command-line interface --- Additional Comments From [EMAIL PROTECTED] 2005-05-22 22:41 --- AFAICS this patch has not been committed yet, so it is better to not set the bug to fixed. Otherwise the patch won't be applied. Joerg -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter.
Re: Server-side image map in CForms ?
Hi Luca, What is your server-side image map supposed to do ? Thanks Jorg Luca Morandini wrote: Folks, I need a server-side image map with Cocoon Forms. AFAIK there's no such a widget in Cocoon 2.1.7... hence, my question: is there someone already working on it or should I start from scratch ? Regards, P.S. I will contribute the results of my efforts... provided they're good enough, of course. Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Luca Morandini wrote: Folks, I need a server-side image map with Cocoon Forms. AFAIK there's no such a widget in Cocoon 2.1.7... hence, my question: is there someone already working on it or should I start from scratch ? Can you elaborate on server-side image map? Does this mean the areas would be computed on the server? I will contribute the results of my efforts... provided they're good enough, of course. Great! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.2
I believe it is the bug you reported. Paul Crabtree wrote: As a matter of fact, Leszek provided a fix last week for what seems to me to be a pretty serious bug in flow and this alone should warrant a 2.1.8 release. Hi Ralph, We are about to go to production with an application built on 2.1.7 that uses flow heavily. Could you point me in the direction of this bug that Leszek has fixed so i can work out whether we are affected. Regards, Paul.
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Vadim Gritsenko wrote: [...mostly off topic...] You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Well, is it really? So which point do you want to argue, that it won't be easier integration, or isn't an advantage? The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Actually, OSGi is a key point in the performance improvements in the upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were still written on the previous kernel API, and the more plugins move to the OSGi API, the more startup time increases I could care less of startup time: I'm one of those who starts up IDE once in a month (after patching M$ windows ;-)). and memory used decreases, by allowing on-demand loading of plugins. On-demand loading means more sluggish UI, right? Once you click on something, you have to wait till it loads :-) Vadim
Re: Server-side image map in CForms ?
Sylvain Wallez wrote: Can you elaborate on server-side image map? Does this mean the areas would be computed on the server? Hmm... it surely makes sense, but I don't need this feature; hence, I'd rather pass only the relevant mouse coordinates to the event handler. BTW, I guess an output field with picture styling type (I've already seen a post with some code) could be another nice addition to Forms... nothing to do with server-side images though, just an output field that happens to have a graphic content: your take ? Regards, Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Jorg Heymans wrote: What is your server-side image map supposed to do ? Very simple stuff: 1) An user clicks on the image. 2) The form is sent to the server together with mouse coordinates. 3) The relevant action is called (mouse coordinates should be sent to the action somehow). Hmm... I think this image-map widget should be a kind of action widget, since the form is sent to the server when widget is clicked upon. Regards, Luca Morandini www.lucamorandini.it
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, Here the main problem is that JXTG and flow have some differences in behaviour, see http://marc2.theaimsgroup.com/?t=11164826501r=1w=2 and http://marc2.theaimsgroup.com/?l=xml-cocoon-devm=11182531907w=2 for description and possible solutions. We need to decide: should we keep trhe direct access of request params as properties of cocoon.request and session/context attributes as properties of cocoon.[session|context] or not. Should we support the direct usage of org.*, javax.* and com.* whithout needing the Packages. prefix in flow? On that point, I proposed to write a new implementation of the flowscript implementation. This is certainly not a total rewrite, but a refactoring of the existing code to have an overally consistent object model, and also introduce a flow object that would separate the flow-specific operations out of the cocoon object that should be the common base for the object model, and therefore be identical in all places (flow, templates, form event listeners, etc). Is there anythimg more? sitemap listeners, VPCs, I'm waiting for community involvement. If we follow Vadim's suggestion http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111331073205551w=2, nothing in core need to depend on vpc code and the vpc code could be moc´ved to an own (unstable) block. Sounds good. third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. As discussed in the relases thread I don't think it is realistic to stop adding features, we need a way to let rock stable core functionality coexist with new features. Otherwise the defacto no release policy will continue. Agree. That this rock solid core state that I'm currently not sure about, as many changes have occured there. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Server-side image map in CForms ?
Luca Morandini wrote: Jorg Heymans wrote: What is your server-side image map supposed to do ? Very simple stuff: 1) An user clicks on the image. 2) The form is sent to the server together with mouse coordinates. 3) The relevant action is called (mouse coordinates should be sent to the action somehow). Hmm... I think this image-map widget should be a kind of action widget, since the form is sent to the server when widget is clicked upon. I have been doing waaay too much GIS stuff ... I saw something about map and straight away thought you meant geo-map :-) I can't comment much on your image map idea though, it seems like a useful addition so just go for it ! Jorg
Re: [RT] Releases
Daniel Fagerstrom wrote: For our current situation I think we could release a 2.2.0 right away. JFYI, seems like 2.2 is largely unusable / unstable ATM: WARN (2005-05-19) 13:16.31:159 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.31:450 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.32:441 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.32:842 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.33:092 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.33:262 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.39:061 [core.manager] (/) PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.39:592 [core.manager] (/) PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:16.46:512 [core.manager] (/samples/blocks/) PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM during lookup. WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo] WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo] WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo] WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo] WARN (2005-05-19) 13:18.09:551 [core.manager] (Unknown-URI) Unknown-Thread/AbstractFactoryHandler: Error decommissioning component: org.apache.cocoon.components.store.impl.EHDefaultStore WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.expression.ExpressionManager] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.excalibur.source.SourceResolver] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.classloader.ClassLoaderManager] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.datatype.DatatypeManager] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.CacheManager] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.validation.WidgetValidatorBuilderSelector] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.event.WidgetListenerBuilderSelector] WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI) Unknown-Thread/CoreServiceManager: disposing of handler for unreleased component. role [org.apache.cocoon.forms.FormManager] Vadim
Re: [RT] Micro kernel based Cocoon
Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ We should also consider if blocks should be _similar_ to Eclipse plugins, of if they should _be_ such plugins, which would remove us a log of work, both for code, docs and support. I have read some Eclipse docu, but it is not obvious to me what Eclipse plugins will help us more specifically with. Care to flesh out some more details? The extension point system can be of great value: a plugin declares an extension point (e.g. the core can declare a source-factory extension point), and plugins can provide contributions to this extension point (e.g. the JCR block will contribute a jcr: source factory). The source resolver can then know all protocols that are provided by plugins somewhere in the system. AFAIU the plugin management stuff (download, update, etc) is specific, even if built on top of OSGi. Version management also. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: jsf-cocoon improvements
Fab Psycho wrote: Hi, I'd like to contribute to jsf on Cocoon.Where can I find a todo list for this and should I work against 2.1 or 2.2 branch ? There is no TODO list for it. See if there are any TODO comments in the code. See also if there are any bugzilla entries. Work at the moment should be done against both 2.1 branch and trunk simultaneously. One thing you might take a look is whether localization in Cocoon Faces works correctly - I had not spent much time on this aspect. Vadim
Re: Server-side image map in CForms ?
Jorg Heymans wrote: I have been doing waaay too much GIS stuff ... I saw something about map and straight away thought you meant geo-map :-) Well, sort of... I need this widget for GIS stuff. A recent law in Italy forces web-sites belonging to state agencies (ministries, local government offices, state-owned companies, etc.), to allow impaired people accessing their contents. The guidelines are very strict (not to say narrow-minded): no JavaScript, no frames, only strict-XHTML, etc. Hence, I'd like to meet this challenge with our beloved Cocoon (and learn something about CForms along the way). Anyway, this stuff won't fit well into Geoid, since server-side images may be useful for other application domains as well. Regards, Luca Morandini www.lucamorandini.it
Re: Releasing 2.2 (was: [RT] Micro kernel based Cocoon)
On 5/23/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le 23 mai 05, à 07:13, Reinhard Poetz a écrit : ...Let's release Cocoon 2.2 alpha1 as soon as possible. When the contracts are stable we use the beta postfix. This will increase the number of people who use and test the release and finally we can release Cocoon 2.2.0 final... Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in sync, which is a pain IMHO. But are there enough visible incentives in 2.2 for people to make the switch? Do we have cool, exciting samples of the new features? I'm not sure, and if we haven't, people might just keep on using 2.1, and the risk is having too much pressure to maintain 2.1 instead of being able to move on. We tend to trail at least one release behind so that we can determine if any major bugs show up in a new release and what it means for us to migrate. On occasion that means we skip a release if something is broken that we depend on (rare) or if we get too far behind. More frequent release of Cocoon would just mean we skip more release... We do tend to use new features of Cocoon when we have a project underway that results in new code on our side. For instance, with our next major release of our code (currently in development, with 2 other releases in the testing pipeline in the mean time) we should finally have everything switched over to flow (no more actions for flow control). It wouldn't make a huge difference to us if a final 2.2.0 was released. If the reports where that it was somewhat stable, then sooner or later we'd get around to testing it and determining the impact on our application. Once we'd could evaluate that we'd fit the migration into our schedule. (If it's a big change, that might mean 6 months to a year before it hits production.) Personally, I'd say JFDI; build a 2.2 alpha, only put new features in 2.2 and plan on keeping on doing bug fixes on the 2.1 branch through at least a 2.1.9. -- Peter Hunsberger
Re: [RT] Micro kernel based Cocoon
Sylvain Wallez wrote: Reinhard Poetz wrote: AFAIU only some work on cForms is missing (flowscript API and repeater binding) That's far from the only work to do IMO, as there are a lot of semi-finished core features. Some that come to mind: refactored object model, sitemap listeners, VPCs, third-party containers, etc. Not that these features don't work, but they lack (at least that's my impression) some more use cases and demos to be strong enough for a stable release. Sure, we can make an alpha release to give people a sign that we are doing some progress, but this should be for us the sign that no more features should be added in that branch. I'm +1 for milestone release - 2.2m1 - especially since we have a history of those. Not sure it has to indicate end of new feature additions. Vadim
DO NOT REPLY [Bug 32491] - [Patch] POST method in cinclude:includexml is broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32491 [EMAIL PROTECTED] changed: What|Removed |Added Summary|POST method in |[Patch] POST method in |cinclude:includexml is |cinclude:includexml is |broken |broken -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Streaming strings in JXTemplate
Leszek Gawron wrote:
Vadim Gritsenko wrote:
The main reason for using DOM in some cases (chosen by user at
runtime) is the ability to avoid SAXException. SaxBuffer does not
offer such functionality as it just stores sax bits and does not
check if xml is well formed.
And neither does DOM. So can you explain your point or give an example?
I'd like to implement something like:
jx:out value=${str} xmlize=true lenient=true/
If @lenient=true:
1. cache SAX events from parsed ${str}
2. validate SAX stream somehow for well formedness (that is why I
proposed DOM)
3. play SAX events into the main stream only if no SAXException occured
previously.
Right now parsing a not well formed xml fragment into view's SAX stream
will destroy the view completely.
So you can use SAXBuffer. Parse into it, parser will check wellformedness (see
samples/errorhandling/error-giving-page.xml).
Vadim
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
There is, but it's pure HTML. It has nothing to do with CForms. Unknown attributes on fi:styling are just copied to the output, e.g. @class and also @readonly. This is still true. I had a look at the stylesheets when this topic was on. Bye, Helma
Re: Server-side image map in CForms ?
Luca Morandini wrote: Jorg Heymans wrote: I have been doing waaay too much GIS stuff ... I saw something about map and straight away thought you meant geo-map :-) Well, sort of... I need this widget for GIS stuff. A recent law in Italy forces web-sites belonging to state agencies (ministries, local government offices, state-owned companies, etc.), to allow impaired people accessing their contents. The guidelines are very strict (not to say narrow-minded): no JavaScript, no frames, only strict-XHTML, etc. Hmm... can't multi-channelling techniques apply here also? e.g. if the browser is a voice browser for visually impaired, use a special dedicated stylesheet. Hence, I'd like to meet this challenge with our beloved Cocoon (and learn something about CForms along the way). Anyway, this stuff won't fit well into Geoid, since server-side images may be useful for other application domains as well. Definitely! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Server-side image map in CForms ?
Luca Morandini wrote:
Jorg Heymans wrote:
What is your server-side image map supposed to do ?
Very simple stuff:
1) An user clicks on the image.
2) The form is sent to the server together with mouse coordinates.
3) The relevant action is called (mouse coordinates should be sent to
the action somehow).
Hmm... I think this image-map widget should be a kind of action
widget, since the form is sent to the server when widget is clicked upon.
You already have it :-)
Use an action with styling type=image. When the image is clicked,
the action's event listeners are triggered, and you can read the click
coordinates using the {action-name}.x and {action-name}.y request
parameters.
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
Le 23 mai 05, à 13:28, Sebastien Arbogast a écrit : ...You're totally right and you remember me that samples should be part of Cocoon documentation as well as any other document. Maybe we could integrate that in Planet Cocoon range. WDYT ? Would you like to help us in that matter ? Not on planetcocoon, sorry. I'm struggling to do something useful here already, due to lack of Copious Free Time and/or Customers Financing Cool Documentation Projects ;-) So if I ever get to implement this samples matrix it will be right here in the Cocoon codebase. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Micro kernel based Cocoon
Vadim Gritsenko wrote: Sylvain Wallez wrote: Vadim Gritsenko wrote: [...mostly off topic...] You forgot that since GBeans used in Geronimo, basing Cocoon on GBeans means easier integration with/into Geronimo, which is significant advantage. Well, is it really? So which point do you want to argue, that it won't be easier integration, or isn't an advantage? Don't know. I just would like to know what advantages it can bring us, considering that not everybody will deploy Cocoon on Geronimo. The fact that Eclipse is based on OSGi, does it mean Cocoon will be doggish slow if it is also based on OSGi, as Eclipse already is? It might be FUD as I've not seen OSGi, but I've seen Eclipse. Actually, OSGi is a key point in the performance improvements in the upcoming Eclipse 3.1. It was introduced in 3.0 but many plugins were still written on the previous kernel API, and the more plugins move to the OSGi API, the more startup time increases I could care less of startup time: I'm one of those who starts up IDE once in a month (after patching M$ windows ;-)). Windoze running for one month? Wow, this is a magic patch :-) and memory used decreases, by allowing on-demand loading of plugins. On-demand loading means more sluggish UI, right? Once you click on something, you have to wait till it loads :-) Good point :-) But it also means things you don't need will never be loaded. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [IMP] synchronization on session object in Cocoon
On 16.05.2005 06:39, Ralph Goers wrote: Yes, there was considerable discussion about this. Yes, the version in svn is wrong. I was hoping it would get fixed after our discussion, but that hasn't happened, so I'll try to commit something tonight (it is still Sunday night here in California). Thanks for fixing all the bugs I introduced by my fast commit without thinking :-( Sorry for any inconveniences. Joerg
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
2005/5/23, Bertrand Delacretaz [EMAIL PROTECTED]: Le 23 mai 05, à 13:28, Sebastien Arbogast a écrit : ...You're totally right and you remember me that samples should be part of Cocoon documentation as well as any other document. Maybe we could integrate that in Planet Cocoon range. WDYT ? Would you like to help us in that matter ? Not on planetcocoon, sorry. I'm struggling to do something useful here already, due to lack of Copious Free Time and/or Customers Financing Cool Documentation Projects ;-) So if I ever get to implement this samples matrix it will be right here in the Cocoon codebase. So be it ! Anyway I discussed that with Mark and finally it appears it's not as interesting as I thought at the beginning because current samples are code only whereas we think code-illustrated documentation is what we need most. So... good cheer for your matrix :-) -- Sebastien ARBOGAST
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
Le 23 mai 05, à 20:33, Sebastien Arbogast a écrit : ...finally it appears it's not as interesting as I thought at the beginning because current samples are code only whereas we think code-illustrated documentation is what we need most... Sure. Note that I just applied a patch to both the 2.1 branch and the trunk, which allows you to add annotation to sitemaps, like: map:match pattern=news.pdf n:explainGet news in XML from server/n:explain map:generate src=http://newsserver/somestuff.xml/ n:explainConvert to xsl-fo/n:explain map:transform src=news-to-fo.xsl/ n:explain And let a href=http://xml.apache.org/fop;FOP/a generate PDF /n:explain map:serialize type=fo2pdf/ /map:match This could be very useful to create self-describing samples. There's also stuff in the tour block that could be reused to extract code excerpts from sitemaps, xml and text files. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java)
On 13.05.2005 11:37, Nathaniel Alfred wrote: I think synchronized(session) should never be used as vehicle to coordinate concurrent requests because there is no convincing guarantee that it is always working as expected. Joerg, if you want to do it in your usercode, I don't mind, but please don't use it in common Cocoon code. My propesed alternative of synchronized(session.getId().intern()) may look obscure but at least it is guaranteed to work. I think we don't get a final answer to whether synchronized(session) is supposed to work or not. Your main concern seems to be complex environments like clusters. But how is session.getId().intern() supposed to work? Have the cluster nodes running by different JVMs and it does neither work. Or am I wrong? Joerg
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
Sure. Note that I just applied a patch to both the 2.1 branch and the trunk, which allows you to add annotation to sitemaps, like: map:match pattern=news.pdf n:explainGet news in XML from server/n:explain map:generate src=http://newsserver/somestuff.xml/ n:explainConvert to xsl-fo/n:explain map:transform src=news-to-fo.xsl/ n:explain And let a href=http://xml.apache.org/fop;FOP/a generate PDF /n:explain map:serialize type=fo2pdf/ /map:match This could be very useful to create self-describing samples. This is definitely interesting. There's also stuff in the tour block that could be reused to extract code excerpts from sitemaps, xml and text files. We'll study that very carefully because we began to talk about this documentation-code integration feature and it seems to be a tricky thing. So any other trial to get to that kind of thing would help up to start. Thx for that. -- Sebastien ARBOGAST
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
Hmm... I think this image-map widget should be a kind of action
widget, since the form is sent to the server when widget is clicked upon.
You already have it :-)
Use an action with styling type=image. When the image is clicked,
the action's event listeners are triggered, and you can read the click
coordinates using the {action-name}.x and {action-name}.y request
parameters.
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
That is possible (via the setValue method) in output widgets, but you
can't trigger an action with this kind of widget... or did I miss
something ?
Regards,
Luca Morandini
www.lucamorandini.it
Re: Server-side image map in CForms ?
Sylvain Wallez wrote: Luca Morandini wrote: Jorg Heymans wrote: Hmm... can't multi-channelling techniques apply here also? e.g. if the browser is a voice browser for visually impaired, use a special dedicated stylesheet. Ahem... have you ever tried to describe a geographic map using VoiceXML ;) ? Seriosuly now, I'll heavily use the multi-channel capability of Cocoon for textual pages... but maps are different. For maps I'm not (obviously) targeting blind people, rather, I'm targeting people with *some* coordination problems and *some* sighting problems, like the old folks (hmm... I'm pushing 40 this year, I should be careful with this old label). Yes, according to an Eurostat estimate (see [1]) some 17% of people over 55 are Internet users, and their numbers will steadily increase: making maps easily accessibile to them is a sensible move, marketing-wise. The map-viewing platform I envisage will be very simple and work even with very big fonts and buttons, and it should do this without JavaScript, frames and mouse (I mean, mouse is considered an optional, useful, but not necessary). Regards, [1] http://epp.eurostat.cec.eu.int/cache/ITY_OFFPUB/KS-NP-05-018/EN/KS-NP-05-018-EN.PDF Luca Morandini www.lucamorandini.it
Re: Server-side image map in CForms ?
Luca Morandini wrote:
Sylvain Wallez wrote:
Luca Morandini wrote:
Hmm... I think this image-map widget should be a kind of action
widget, since the form is sent to the server when widget is clicked
upon.
You already have it :-)
Use an action with styling type=image. When the image is clicked,
the action's event listeners are triggered, and you can read the
click coordinates using the {action-name}.x and {action-name}.y
request parameters.
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
Yes you can, as the image src is in the form template. Of course you
have to use a dynamic template (e.g. JXTG):
ft:action id=map
fi:styling type=image src=images/${image_name}.jpg/
/ft:action
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
RE: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java)
To quote Servlet spec SRV.7.7.3 Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time. I read that as Concurrent requests must be dispatched to the same JVM - otherwise all bets are off. So any upstream load balancing in a cluster must use some sort of session affinity, and in the same JVM the internalized session id is guaranteed to be unique. Cheers, Alfred. -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Montag, 23. Mai 2005 20:45 To: dev@cocoon.apache.org Subject: Re: Synchronization on session object (was svn commit: r169856 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/htt p/HttpRequest.java) On 13.05.2005 11:37, Nathaniel Alfred wrote: I think synchronized(session) should never be used as vehicle to coordinate concurrent requests because there is no convincing guarantee that it is always working as expected. Joerg, if you want to do it in your usercode, I don't mind, but please don't use it in common Cocoon code. My propesed alternative of synchronized(session.getId().intern()) may look obscure but at least it is guaranteed to work. I think we don't get a final answer to whether synchronized(session) is supposed to work or not. Your main concern seems to be complex environments like clusters. But how is session.getId().intern() supposed to work? Have the cluster nodes running by different JVMs and it does neither work. Or am I wrong? Joerg This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
Yes you can, as the image src is in the form template. Of course you
have to use a dynamic template (e.g. JXTG):
ft:action id=map
fi:styling type=image src=images/${image_name}.jpg/
/ft:action
Sure, but I'd rather avoid using dynamic templates for otherwise static
forms... morever, setting the image source from a action-handler flow
script would be more elegant.
Regards,
Luca Morandini
www.lucamorandini.it
Re: Server-side image map in CForms ?
Luca Morandini wrote:
Sylvain Wallez wrote:
Luca Morandini wrote:
Well, but I should be able to change the image's src attribute
dynamically, wich is not allowed in action widget... right ?
Yes you can, as the image src is in the form template. Of course you
have to use a dynamic template (e.g. JXTG):
ft:action id=map
fi:styling type=image src=images/${image_name}.jpg/
/ft:action
Sure, but I'd rather avoid using dynamic templates for otherwise
static forms...
I see. However, I'm not sure that executing a template composed of
near-static compiled SAX events is that much slower than a regular XML
parser.
There's also the solution of a custom cforms styling stylesheet that
could set this src attribute from a sitemap parameter.
morever, setting the image source from a action-handler flow script
would be more elegant.
That's exactly what the ${image_name} is, e.g.:
form.showForm(my-form-pipeline, {image_name : map- + areaId});
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Server-side image map in CForms ?
Sylvain Wallez wrote:
Luca Morandini wrote:
morever, setting the image source from a action-handler flow script
would be more elegant.
That's exactly what the ${image_name} is, e.g.:
form.showForm(my-form-pipeline, {image_name : map- + areaId});
Sure, you set the value and pass that parameter from within flow, but to
understand its use you should take a look at the form template as
well... while the setValue() is completely understandable from the flow
code.
I mean, nothing really substantial here... only I'd like it to be done
in more straightforward way: suppose there's a developer willing to add
a dynamic image using CForms, which way he would find easier to understand ?
Regards,
Luca Morandini
www.lucamorandini.it
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
Hi Sebastien, Sebastien Arbogast wrote: I've just published four new ideas on my blog (http://www.planetcocoon.com/taxonomy/term/60) to implement features of other successful OSS documentation platforms. [...] great ideas :-) *thumbsup* But something completely different: What fonts are you using? In my environment (Firefox 1.04, WinXP Pro) my eyes get hurt (same for Opera and IE) :/ Well, it is very difficult to read for me and I would suggest a different font (or is it my system?). It looks like some font- aliasing goes wrong and your text is shown extremely blurred. Gerald
Re: [PlanetCocoon] 4 new ideas to discuss on Planet Cocoon
2005/5/23, Gerald Aichholzer [EMAIL PROTECTED]: Hi Sebastien, Sebastien Arbogast wrote: I've just published four new ideas on my blog (http://www.planetcocoon.com/taxonomy/term/60) to implement features of other successful OSS documentation platforms. [...] great ideas :-) *thumbsup* But something completely different: What fonts are you using? In my environment (Firefox 1.04, WinXP Pro) my eyes get hurt (same for Opera and IE) :/ Well, it is very difficult to read for me and I would suggest a different font (or is it my system?). It looks like some font- aliasing goes wrong and your text is shown extremely blurred. This is exactly the kind of feedback we need (among other kinds :-P) Because in my firefox, maxthon or opera I perfectly see it, even if the main font is not installed (Bitstream Vera Sans ! I didn't even know of it... thx Mark ;-)) I can read Verdana (the second one in the CSS list). Could you please send me a screenshot of what you can see so that I can identify where the problem is ? -- Sebastien ARBOGAST
Planet Cocoon license and reuse of docs
I can't find any copyright or license information on the planetcocoon site. Can you please point me at the relevant page. I'm concerned as much of the documentation content appears to be direct duplicates of materials in Cocoons official documentation or mailing lists but I cannot find the required acknowledgement to Apache Software Foundation. I know you are working closely with the Cocoon community so I am sure this is only an oversight (possibly on my part). In addition, can you tell me if Drupal is able to serve nodes as unprocessed content. That is, can I retrieve a version of a node that has only the content, no navigation or other such decoration. If it is possible to do this, what license will your own original matrials be released under? My reason for asking both questins is that I'd like to consider adding an input plugin to Forrest in order to assist in your stated objective of Every effort will be made to ensure that information generated on Planet Cocoon will end up in the official documentation (quote from your home page). Ross
Re: Planet Cocoon license and reuse of docs
2005/5/23, Ross Gardler [EMAIL PROTECTED]: I can't find any copyright or license information on the planetcocoon site. Can you please point me at the relevant page. Actually so far there is no such thing. As it is said in our disclaimer, Planet Cocoon is an unofficial experiment in online developer community, not endorsed in any way by the Cocoon PMC so there is currently no license or copyright of any sort BUT... you point out something very interesting because there is some original content there and we should begin to worry about some license. I'm concerned as much of the documentation content appears to be direct duplicates of materials in Cocoons official documentation or mailing lists but I cannot find the required acknowledgement to Apache Software Foundation. I know you are working closely with the Cocoon community so I am sure this is only an oversight (possibly on my part). There is absolutely no duplicate of original documentation (not that I know of at least... Mrk !!! You duplicated ??? Bad boy !). The only thing we duplicate for now is the content of mailing lists but there are several archives doing that, especially a blog fashioned one I can't remember the address. Anyway for now you're right, there is no official written acknowledgement from the Apache Foundation or Cocoon PMC. But as you say, we are working closely with PMC members to keep things right and for example, the disclaimer was added following one of their requests. In addition, can you tell me if Drupal is able to serve nodes as unprocessed content. That is, can I retrieve a version of a node that has only the content, no navigation or other such decoration. That I don't know. Mark is the Drupal master ! If it is possible to do this, what license will your own original matrials be released under? Planet Cocoon is barely a few weeks old and it's still experimental, but this licensing question should definitely be part of the future discussions with PMC members. BTW if Bertrand, or Sylvain, or Stefano or any other PMC member wants to intervene, feel free to do so guys. My reason for asking both questins is that I'd like to consider adding an input plugin to Forrest in order to assist in your stated objective of Every effort will be made to ensure that information generated on Planet Cocoon will end up in the official documentation (quote from your home page). It's very kind of you but we have just begun discussing the storage format we will choose for our documents in order to suit all the wonderful features we want to integrate, while keeping docs compatible with Forrest formats. So it's far from being determined yet. It should be in the next few weeks or so. Thank you very much for your interest. We'll remember your offer and keep you in touch as soon as we have something more concrete. -- Sebastien ARBOGAST
Cascading the cinclude transformer
Hello everyone, I'm currently working on a project that being able to process cascaded cincludes would be helpful. They would then be processed from the deepest depth to the lowest. Here is a generic example: ?xml version=1.0? page xmlns:cinclude=http://apache.org/cocoon/include/1.0; cinclude:includexml cinclude:srccocoon:/firstOne.xml/cinclude:src cinclude:configuration cinclude:parameter cinclude:namemethod/cinclude:name cinclude:valuePOST/cinclude:value /cinclude:parameter /cinclude:configuration cinclude:parameters cinclude:parameter cinclude:nametest/cinclude:name cinclude:value !-- ### A Nested cinclude -- cinclude:includexml cinclude:srccocoon:/secondOne.xml/cinclude:src cinclude:configuration cinclude:parameter cinclude:namemethod/cinclude:name cinclude:valuePOST/cinclude:value /cinclude:parameter /cinclude:configuration cinclude:parameters cinclude:parameter cinclude:nametest/cinclude:name cinclude:value namematti/nameage36/age /cinclude:value /cinclude:parameter /cinclude:parameters /cinclude:includexml !-- ### -- /cinclude:value /cinclude:parameter /cinclude:parameters /cinclude:includexml /page So in the nested cinclude should be processed and then parent one. This way the result from the first can be used as parameters for the parent. Is there a way to do this already? If not, how would everybody suggest I proceed. My first thought was extending or modifying the current cinclude. Regards, Michael Schlotfeldt
Re: Cascading the cinclude transformer
Michael Schlotfeldt wrote: snip/ So in the nested cinclude should be processed and then parent one. This way the result from the first can be used as parameters for the parent. Is there a way to do this already? If not, how would everybody suggest I proceed. My first thought was extending or modifying the current cinclude. My suggestion is to use sitemap instead: ... map:transform type=secondOne/ map:transform type=firstOne/ ... It is not hard to match on some specific node and transform namematti/name age36/age into whatever format is necessary using transformer(s) - custom or XSLT - instead of cascading lots of includes. As a bonus, result should be easier to read and understand. Vadim
Re: Server-side image map in CForms ?
Luca Morandini wrote:
Sylvain Wallez wrote:
Luca Morandini wrote:
morever, setting the image source from a action-handler flow script
would be more elegant.
That's exactly what the ${image_name} is, e.g.:
form.showForm(my-form-pipeline, {image_name : map- + areaId});
Sure, you set the value and pass that parameter from within flow, but
to understand its use you should take a look at the form template as
well... while the setValue() is completely understandable from the
flow code.
I mean, nothing really substantial here... only I'd like it to be done
in more straightforward way: suppose there's a developer willing to
add a dynamic image using CForms, which way he would find easier to
understand ?
You may be right. I don't want to refrain you from writing a special
widget, but just want to outline the possible options we have today! Now
if you feel the itch, just scratch it ;-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
