Re: RFC: CForms Roadmap
Hi, Since namespace is employed now. Widgets' naming might start not to include namespace-purpose prefix. For example, CFormsSuggest is better to be just named Suggest. Rice On 1/7/07, Jeremy Quinn [EMAIL PROTECTED] wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. I hope the main outcomes of this will be : Leaner: only the resources that are used will be loaded by cforms Richer: more interactive widgets with wider x-platform support Cleaner: eliminate most of the messy script tags scattered through our forms Simpler: use more html templates to simplify our xslt (and simpler to adapt the widgets) Here is a list of specific goals I would love us to achieve for the next release. I hope to be working on this stuff, you would be very welcome if you'd like to join in If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. Help validation popups: replace MattKruse stuff with a new Dojo implementation. Tabs: replace with Dojo Tabs RichText: replace htmlarea with Dojo Editor, using a new fi:styling, so htmlarea can still be used MultiValue Editor: re-implement as a Dojo widget MultiList (OptionTransfer) Selector: replace with a new Dojo widget Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) Possible Additions : Easy graphically rich buttons, dialogs, menus etc. Charts to plot user data Colour picker Re-sizable textarea Sliders: graphical selector for number ranges etc. Spinner: adjust values up and down with ± buttons Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. We are probably going to have issues with i18n and l10n. Dojo is only just starting to deal with this area, while CForms has always delt with it. Dojo, performs i18n on the client instead of on the server as cforms does. Very few of Dojo's widgets are i18n enabled yet. Dojo uses a different format of i18n message dictionary than we do (all of this is kind of obvious). Most of the work above will involve either extending existing dojo widgets or making new ones. We ought to be adding i18n/l10n as we go along. We need to decide whether we want to keep our message dictionary format (transforming it on the fly for dojo) or start using Dojo's format (for widget internals). What did I miss out ? I hope this whets your appetite ! Let's get on with the replacements first !! WDYT ? regards Jeremy
Re: RFC: CForms Roadmap
Hi Jeremy, On Sun, 2007-01-07 at 13:01 +, Jeremy Quinn wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. snip/ Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. I'm going to need this in the next couple of weeks, so it's very likely I'll work on this. Help validation popups: replace MattKruse stuff with a new Dojo implementation. I've got something like this in Daisy already, it seems to work quite well, so I could move it into CForms. MultiValue Editor: re-implement as a Dojo widget This is also one I'm motivated to work on, since I wrote it originally. I still need to get up-to-date with dojo 0.4 and the current cforms, but if all goes well I hope to be able to do something about these 3. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Created: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load -- Key: COCOON-1979 URL: https://issues.apache.org/jira/browse/COCOON-1979 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Rob Berens When a script is loaded via cocoon.load the refresh parameter for CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In 2.1.8 this parameter was incorrectly ignored, when checking the compile time against the last modified time in CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 or 2.1.10. The side effect however is that scripts loaded via cocoon.load are never checked for modification, as FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the getScript method with refresh = false. In the supplied patched (patch-1.txt and patch-2.txt) the compileScript method now sets the refresh indicator dependent on the reload-script and check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Berens updated COCOON-1979: --- Attachment: patch-2.txt [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load -- Key: COCOON-1979 URL: https://issues.apache.org/jira/browse/COCOON-1979 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Rob Berens Attachments: patch-1.txt, patch-2.txt When a script is loaded via cocoon.load the refresh parameter for CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In 2.1.8 this parameter was incorrectly ignored, when checking the compile time against the last modified time in CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 or 2.1.10. The side effect however is that scripts loaded via cocoon.load are never checked for modification, as FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the getScript method with refresh = false. In the supplied patched (patch-1.txt and patch-2.txt) the compileScript method now sets the refresh indicator dependent on the reload-script and check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1979) [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load
[ https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Berens updated COCOON-1979: --- Attachment: patch-1.txt [PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via cocoon.load -- Key: COCOON-1979 URL: https://issues.apache.org/jira/browse/COCOON-1979 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Rob Berens Attachments: patch-1.txt, patch-2.txt When a script is loaded via cocoon.load the refresh parameter for CompilingInterpreter.ScripSourceEntry.getScript is always set to false. In 2.1.8 this parameter was incorrectly ignored, when checking the compile time against the last modified time in CompilingInterpreter.ScripSourceEntry.getScript. This was corrected in 2.19 or 2.1.10. The side effect however is that scripts loaded via cocoon.load are never checked for modification, as FOM_JavaScriptInterpreter.compileScript(Context, String) always calls the getScript method with refresh = false. In the supplied patched (patch-1.txt and patch-2.txt) the compileScript method now sets the refresh indicator dependent on the reload-script and check-time parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to add docs to our doc system?
Bertrand Delacretaz schrieb: On 1/8/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I'm stuck as I don't know the password for the daisy user in our zone (I have access to the zone itself). Where can I find this? If you have sudo access you can do sudo su - daisy and enter *your own* password when prompted by sudo. That's how I do it, I don't know the daisy user password. -Bertrand Thanks Bertrand, that works Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: CForms Roadmap
Hi Jeremy! First of all thx for the great job you did on the modernization of CForms, I didn't have the proper time to investigate it or better to use it (hopefully I will do that this or the next week), but reading from ML threads seems to be quite cool stuff! On 1/7/07, Jeremy Quinn [EMAIL PROTECTED] wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. snip/ I hope to be working on this stuff, you would be very welcome if you'd like to join in I think I can be active on many of the improvements you mentioned, but first I have to investigate a bit more, as I was saying, the dojo 0.4integration with CForms. Maybe you can pin-point me ( again ;-) ) to a particular thread or some docs, or even a crucial code fragment you wrote, to ease the understanding. Or better I have just to dig into code... If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. snip/ Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) I've been recently working quite hard with GMaps and Dojo, I can surely help in this task, and I'm pretty motivated to work on that. Expect me coming with questions as soon as I studied your code. Possible Additions : snip/ Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones This is also very interesting, and there's been interest in the community on that in the past. I may be able to contribute also on this point. But as you correctly say, let's go for the replacements first. Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. +1000 In addition to being pretty configurable in the layout, I would really see CForms solve another tedious problem I have to face while working especially in government projects with high requirements of accessibility: some design is still table-based in the forms styling xsl, as well as propietary attribute are sometimes coming out in the html (say ajax = true, or dojoType = CFormsForm, maybe the latter is changed), preventing any site to be: 1. completely W3C compliant 2. completely accessible (WCAG 1.0 and 2.0) and easily customizable (tables are somewhere used for design purposes, and the absence of div in those place limits the customization power of CSS, and prevents from having a highly configurable default using this [1]) . See, I'm not looking at CForms deeply since a 2/3 months, so maybe everything is already changed, but, according to me, a key point in the success of CForms would to have a sensible default behaviour that automagically assing CSS (multiple) classes so that the forms-styling.xsl can be almost ignored during development, and widget Id's can be used as the only, ultimate, contract between developers and designers. WDYT? Can it be a valid improvement in this refurbishment roadmap? snip/ I hope this whets your appetite ! Sure it does ;-) Let's get on with the replacements first !! Yep, hopefully I can come again with more appropriate questions of proposals in a 10 days time. regards Jeremy Ciao, Gab [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200605.mbox/[EMAIL PROTECTED] - Eng. Gabriele Columbro Consultant at Sourcesense Italy - work: [EMAIL PROTECTED] private: [EMAIL PROTECTED] mobile: (0039)3201612846 yahoo: g.columbro gtalk: [EMAIL PROTECTED] AIM: gabrielecolumbro - Keyboard not found. Press F1 to continue -
Re: RFC: CForms Roadmap
Hi Bruno Thanks for the heads-up. On 9 Jan 2007, at 09:06, Bruno Dumon wrote: Hi Jeremy, On Sun, 2007-01-07 at 13:01 +, Jeremy Quinn wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. snip/ Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. I'm going to need this in the next couple of weeks, so it's very likely I'll work on this. Excellent. I hacked one up recently . not well enough to commit . one possible issue could be problems with l10n of the dates output by the widget. It was outputting US-style dates, I was probably doing something wrong. Help validation popups: replace MattKruse stuff with a new Dojo implementation. I've got something like this in Daisy already, it seems to work quite well, so I could move it into CForms. Great ! I was thinking of using a Dialog class as this would let users turn on cool lightbox effects etc. MultiValue Editor: re-implement as a Dojo widget This is also one I'm motivated to work on, since I wrote it originally. Cool again ;) I still need to get up-to-date with dojo 0.4 and the current cforms, but if all goes well I hope to be able to do something about these 3. Great news! I went through all of the implementations of the Cocoon-supplied Dojo Widgets, trying to clean up their usage of the Widget API. So hopefully they provide a reasonably set of clean examples for you. Have fun ;) regards jeremy smime.p7s Description: S/MIME cryptographic signature
Cocoon-2.1.10 deployed jars on ibiblio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all For all former cocoon version there the 'block' jars are existing on ibiblio (http://www.ibiblio.org/maven/cocoon/jars/) as well as on p.a.o (http://people.apache.org/repo/m1-ibiblio-rsync-repository/cocoon/jars/). Are they intentionally not published any more or are they just not yet publish? Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo4BE2lZVCB08qHERAkCZAKDoTKu28DuysZTvwgamc7zy1WTQUwCcDCYy R5Xl79fyoMo3t5d1iahiLto= =A4HN -END PGP SIGNATURE-
Re: Cocoon-2.1.10 deployed jars on ibiblio
Felix Knecht wrote: Dear all For all former cocoon version there the 'block' jars are existing on ibiblio (http://www.ibiblio.org/maven/cocoon/jars/) as well as on p.a.o (http://people.apache.org/repo/m1-ibiblio-rsync-repository/cocoon/jars/). Are they intentionally not published any more or are they just not yet publish? They are not published yet... Perhaps someone could start the script and upload the jars? Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[continuum] BUILD FAILURE: Cocoon Thread Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/73/buildId/1610 Build statistics: State: Failed Previous State: Ok Started at: Tue, 9 Jan 2007 12:36:19 + Finished at: Tue, 9 Jan 2007 12:36:30 + Total time: 10s Build Trigger: Schedule Exit code: 1 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes cziegeler Start removing dependencies to Avalon /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/DefaultRunnableManager.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/DefaultThreadPool.java cziegeler Adopt to our general coding style /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/DefaultThreadPool.java cziegeler Migrate thread impl to pojo /cocoon/trunk/core/cocoon-core/src/main/resources/org/apache/cocoon/cocoon.roles /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/pom.xml /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/components/thread/DefaultRunnableManager.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/resources/META-INF/cocoon/avalon /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/main/resources/META-INF/cocoon/spring/cocoon-thread-impl.xml /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread/AbstractTestCase.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread/DefaultRunnableManagerTestCase.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread/DefaultThreadFactoryTestCase.java /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java Output: [INFO] Scanning for projects... [INFO] [INFO] Building Cocoon Thread Implementation [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/maven/continuum-data/working-directory/73/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] [compiler:compile] Compiling 7 source files to /home/maven/continuum-data/working-directory/73/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 4 source files to /home/maven/continuum-data/working-directory/73/target/test-classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/maven/continuum-data/working-directory/73/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java:[19,42] package org.apache.avalon.framework.logger does not exist /home/maven/continuum-data/working-directory/73/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java:[112,22] cannot resolve symbol symbol: class ConsoleLogger final ConsoleLogger logger = new ConsoleLogger( ConsoleLogger.LEVEL_DEBUG ); /home/maven/continuum-data/working-directory/73/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java:[112,49] cannot resolve symbol symbol: class ConsoleLogger final ConsoleLogger logger = new ConsoleLogger( ConsoleLogger.LEVEL_DEBUG ); /home/maven/continuum-data/working-directory/73/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java:[112,64] cannot resolve symbol symbol: variable ConsoleLogger final ConsoleLogger logger = new ConsoleLogger( ConsoleLogger.LEVEL_DEBUG ); [INFO] [INFO] For more information, run Maven with the -e switch [INFO]
Re: svn commit: r494368 - in /cocoon/trunk/core: cocoon-core/src/main/resources/org/apache/cocoon/ cocoon-thread/cocoon-thread-impl/ cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/co
[EMAIL PROTECTED] skrev: Author: cziegeler Date: Tue Jan 9 02:49:43 2007 New Revision: 494368 URL: http://svn.apache.org/viewvc?view=revrev=494368 Log: Migrate thread impl to pojo Great, I started to look at POJOfying the thread module yesterday, but you saved me the work. What components are next on you todo list, so that we don't POJOfy the same components? My goal is to POJOfy enough components to make http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java possible to run without using the sitemap-modules (not the wildcard matcher, I will use the helper class instead). /Daniel
Re: svn commit: r494368 - in /cocoon/trunk/core: cocoon-core/src/main/resources/org/apache/cocoon/ cocoon-thread/cocoon-thread-impl/ cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/co
Daniel Fagerstrom wrote: Great, I started to look at POJOfying the thread module yesterday, but you saved me the work. What components are next on you todo list, so that we don't POJOfy the same components? My goal is to POJOfy enough components to make http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java possible to run without using the sitemap-modules (not the wildcard matcher, I will use the helper class instead). My todo list is empty :) So, you can pick up any component you want without stepping on my toes :) My goal is to get the hsqldb server running without any Avalon dependencies. This should be possible now, but I haven't tested yet. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r494368 - in /cocoon/trunk/core: cocoon-core/src/main/resources/org/apache/cocoon/ cocoon-thread/cocoon-thread-impl/ cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/co
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Great, I started to look at POJOfying the thread module yesterday, but you saved me the work. What components are next on you todo list, so that we don't POJOfy the same components? My goal is to POJOfy enough components to make http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java possible to run without using the sitemap-modules (not the wildcard matcher, I will use the helper class instead). My todo list is empty :) So, you can pick up any component you want without stepping on my toes :) Not the answer that I wanted to hear ;) Anyway, I'll try to POJOfy: the store implementations, XSLTProcessor, TraxTransformer, some sources, a source resolver (here there are some complications as CocoonSourceResolver depend on sitemap specific stuff), and some of the pipeline implementations. /Daniel
Re: svn commit: r494368 - in /cocoon/trunk/core: cocoon-core/src/main/resources/org/apache/cocoon/ cocoon-thread/cocoon-thread-impl/ cocoon-thread/cocoon-thread-impl/src/main/java/org/apache/cocoon/co
Daniel Fagerstrom wrote: My todo list is empty :) So, you can pick up any component you want without stepping on my toes :) Not the answer that I wanted to hear ;) :) I'm trying to get the docs for the configurator complete in the meantime... Anyway, I'll try to POJOfy: the store implementations, XSLTProcessor, TraxTransformer, some sources, a source resolver (here there are some complications as CocoonSourceResolver depend on sitemap specific stuff), and some of the pipeline implementations. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: CForms Roadmap
Hi everyone, This is very interesting! I would love to help, but I have like 5 projects going on in the university and otherwise... However, two of them are geared at the web, so this might be interesting to investigate. By the way, has anything improved authentication-wise in Cocoon? I haven't quite followed the development in the last few months, but with the real blocks and so on, it's getting more interesting for the kind of web application I have in mind. (for which I would use struts2 otherwise *shiver*) Anyway, I can't commit much time right now, but I'll definitely have a look when I get home! Bye, and take care! max Jeremy Quinn wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. I hope the main outcomes of this will be : Leaner: only the resources that are used will be loaded by cforms Richer: more interactive widgets with wider x-platform support Cleaner: eliminate most of the messy script tags scattered through our forms Simpler: use more html templates to simplify our xslt (and simpler to adapt the widgets) Here is a list of specific goals I would love us to achieve for the next release. I hope to be working on this stuff, you would be very welcome if you'd like to join in If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. Help validation popups: replace MattKruse stuff with a new Dojo implementation. Tabs: replace with Dojo Tabs RichText: replace htmlarea with Dojo Editor, using a new fi:styling, so htmlarea can still be used MultiValue Editor: re-implement as a Dojo widget MultiList (OptionTransfer) Selector: replace with a new Dojo widget Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) Possible Additions : Easy graphically rich buttons, dialogs, menus etc. Charts to plot user data Colour picker Re-sizable textarea Sliders: graphical selector for number ranges etc. Spinner: adjust values up and down with ± buttons Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. We are probably going to have issues with i18n and l10n. Dojo is only just starting to deal with this area, while CForms has always delt with it. Dojo, performs i18n on the client instead of on the server as cforms does. Very few of Dojo's widgets are i18n enabled yet. Dojo uses a different format of i18n message dictionary than we do (all of this is kind of obvious). Most of the work above will involve either extending existing dojo widgets or making new ones. We ought to be adding i18n/l10n as we go along. We need to decide whether we want to keep our message dictionary format (transforming it on the fly for dojo) or start using Dojo's format (for widget internals). What did I miss out ? I hope this whets your appetite ! Let's get on with the replacements first !! WDYT ? regards Jeremy
Bean overriding.
One would like to provide a totally new implementation of core component (i.e. store, continuations manager etc.). The current version of the component will be loaded anyways (the bean definition resides somewhere in cocoon-core.jar/META-INF/cocoon/spring/*.xml). Defining a new bean of the same name will throw a nasty exception. What should the user do? -- Leszek GawronCTO at MobileBox Ltd.
Re: Bean overriding.
Leszek Gawron wrote: One would like to provide a totally new implementation of core component (i.e. store, continuations manager etc.). The current version of the component will be loaded anyways (the bean definition resides somewhere in cocoon-core.jar/META-INF/cocoon/spring/*.xml). Defining a new bean of the same name will throw a nasty exception. What should the user do? As far as I know, you'll not get an exception and the last definition is used. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Bean overriding.
Carsten Ziegeler wrote: Leszek Gawron wrote: One would like to provide a totally new implementation of core component (i.e. store, continuations manager etc.). The current version of the component will be loaded anyways (the bean definition resides somewhere in cocoon-core.jar/META-INF/cocoon/spring/*.xml). Defining a new bean of the same name will throw a nasty exception. What should the user do? As far as I know, you'll not get an exception and the last definition is used. What is the 100% reliable way to make the definition I want the last one? -- Leszek GawronCTO at MobileBox Ltd.
Re: Bean overriding.
Leszek Gawron wrote: Carsten Ziegeler wrote: Leszek Gawron wrote: One would like to provide a totally new implementation of core component (i.e. store, continuations manager etc.). The current version of the component will be loaded anyways (the bean definition resides somewhere in cocoon-core.jar/META-INF/cocoon/spring/*.xml). Defining a new bean of the same name will throw a nasty exception. What should the user do? As far as I know, you'll not get an exception and the last definition is used. What is the 100% reliable way to make the definition I want the last one? The configuration files are applied in alphabetical order, so the name of your configuration file should be after the name of the provided configuration. In addition, all configuration files from /WEB-INF/classes/META-INF/cocoon are applied after all configuration files from jars. So putting something here is the safest way! Btw, we should use a naming schema for our configuration files to provide a naming contract people can rely on when trying to override configurations (the contract could be as simple as to require that all file names start with cocoon-. So anything after c can overwrite. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: CForms Roadmap
Jeremy Quinn said the following on 9/1/07 13:12: The next level of complexity, is all of the groups and layout stuff in the cforms xslt. In hindsight, it seems this could have been done cleaner in a separate namespace, but we do not have that option now, unless we want to force everyone to completely re-work their form templates etc. However, I do find lots of inconsistencies with the layouting code . for instance, I have not found a way to combine the layouting tags with stuff like repeaters and as you say, there is possibly too much usage of tables. I would love to see more of the layout structure use divs and css, but this was not done originally I suspect as these types of layouts are more difficult to achieve. I once started (way back when 2.1.7 or 2.1.8 was released) to convert the XSLT to divs and CSS, replacing the tables. I ran into problems with the autoformat settings like columns and rows, because there is no way to get that flexibly working without tables when you have no clue what type of widget it is and how long the label is. Also: fieldset is rendered differently in different browsers, that would mean you have to apply CSS hacks for all possible browsers thus moving the complication from XSLT to CSS. Just my 2ct. Although I'd love to tinker with this some more. Bye, Helma
viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
On 1/4/2007 11:49 PM, Mark Lundquist wrote (on users@cocoon.apache.org): Next step is to figure out how to use this to trace data flow through the sitemap. You might take a look here: http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html I've been looking into the profiler, and indeed have used it before for profiling (finding out how long various pipelines take). What I don't see is how to view the XML that passes from one component to another. http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html says you can do this but doesn't tell how. Ah, wait... I get it. By clicking on 422ms (how intuitive!), or xslt (testpage.xsl) (better), you get the XML output. Then you dig through the sample code, and discover that the profile generator takes URL parameters (not sitemap parameters) result and component that tell it to emit information about a particular output of a particular component. E.g. http://localhost/samples/blocks/profiler/profile.html?key=-9147137934425539743result=0component=1cocoon-view=content I guess the profile2.html view makes this a little more obvious, but only after you discover that the 0 under Last is a link, and that it might be something worthwhile to click on! http://cocoon.apache.org/2.1/userdocs/profile-generator.html has some of this information; it would be good to have a link from http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html to the latter. I've added a comment to that page in Daisy (does anybody read those comments?) It would also be helpful to put an explanatory note about that on the sample page: http://localhost/samples/blocks/profiler/profile.html?key=-9147137934425539743 could say at the top, Click on a time to view the relevant XML result from that component. I agree, this is very useful functionality, but not very easy to discover. Hence its value for newcomers, who need it most, is greatly diminished. I think I would like to rework this sample to be more illuminating, and submit it for committing. I would also be happy to work on improving the documentation pages. Can somebody tell me the process for getting changes approved and committed? I'm familiar with SVN, just don't know who to talk to in the Cocoon project. Lars
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
Hi Lars, On Jan 9, 2007, at 9:49 AM, Lars Huttar wrote: Ah, wait... I get it. By clicking on 422ms (how intuitive!), or xslt (testpage.xsl) (better), you get the XML output. Then you dig through the sample code, and discover that the profile generator takes URL parameters (not sitemap parameters) result and component that tell it to emit information about a particular output of a particular component. E.g. http://localhost/samples/blocks/profiler/profile.html?key= -9147137934425539743result=0component=1cocoon-view=content I guess the profile2.html view makes this a little more obvious, but only after you discover that the 0 under Last is a link, and that it might be something worthwhile to click on! If you want to improve the profiler web interface and you have the time to do it, please do it and drop a patch on JIRA (see below)... http://cocoon.apache.org/2.1/userdocs/profile-generator.html has some of this information; it would be good to have a link from http://cocoon.apache.org/2.1/userdocs/concepts/profiler.html to the latter. I've added a comment to that page in Daisy (does anybody read those comments?) Not sure... :-/ It would also be helpful to put an explanatory note about that on the sample page: http://localhost/samples/blocks/profiler/profile.html?key= -9147137934425539743 could say at the top, Click on a time to view the relevant XML result from that component. I agree, this is very useful functionality, but not very easy to discover. Hence its value for newcomers, who need it most, is greatly diminished. I think I would like to rework this sample to be more illuminating, and submit it for committing. I think ideally if you could make the profiler page itself more intuitive and/or add some explanatory text there (maybe)... then if more is needed on the sample page, it could be added. In other words, if the profiler page sucks, let's not just leave it that way and rely on the sample page to explain it, instead let's improve it as much as possible and if it still isn't self-explanatory, enhance the sample to bridge the gap. I would also be happy to work on improving the documentation pages. That would be great, too. You'll need to spend a little time in the docs area at cocoon.zones.apache.org to orient yourself, and Helma or Reinhard or somebody can hook you up with a Diasy login with doc-editor privileges, then you are set. Can somebody tell me the process for getting changes approved and committed? Right here: http://cocoon.apache.org/2.1/1177.html As for getting them approved, it seems like it's more of a do first approach in this community. You'll have to show them what you've got, in the form of a patch... and then, hopefully someday the patch will be accepted. You don't need any pre-approval to submit a patch, but neither is there any guarantee it'll be accepted. Sometimes further discussion is warranted, or the patch will be accepted w/ some modifications. I have a few patches in limbo on JIRA that I'd very much like to see accepted, so maybe it's time I made some noise :-) In any case, you're to be commended for wanting to improve both the code and the docs together :-) :-) :-) best regards, —ml—
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
On Jan 9, 2007, at 2:22 PM, Mark Lundquist wrote: [...] You'll need to spend a little time in the docs area at cocoon.zones.apache.org to orient yourself, and Helma or Reinhard or somebody can hook you up with a Diasy login with doc-editor privileges, then you are set. I think, to initially set up the account you select Register from the User: menubar item and create up your own account. (Maybe you've done that already, if you've submitted comments... I think having a registered user id is what enables you to comment? Not sure...) Anyway, once you're registered, then you just give a shout to the list, hey, I need the doc-editors role. cheers, —ml—
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
On 1/9/2007 4:34 PM, Mark Lundquist wrote: On Jan 9, 2007, at 2:22 PM, Mark Lundquist wrote: [...] You'll need to spend a little time in the docs area at cocoon.zones.apache.org to orient yourself, and Helma or Reinhard or somebody can hook you up with a Diasy login with doc-editor privileges, then you are set. I think, to initially set up the account you select Register from the User: menubar item and create up your own account. (Maybe you've done that already, if you've submitted comments... I think having a registered user id is what enables you to comment? Not sure...) Anyway, once you're registered, then you just give a shout to the list, hey, I need the doc-editors role. cheers, —ml— OK... I've registered, as you surmised, and I guess I need the doc-editors role. Unless somebody would rather I wrote it up and submitted it to a doc-editor. Whatever. Lars
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
Lars Huttar wrote:
OK... I've registered, as you surmised, and I guess I need the
doc-editors role.
done
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[continuum] BUILD SUCCESSFUL: Cocoon Thread Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/73/buildId/1620 Build statistics: State: Ok Previous State: Failed Started at: Wed, 10 Jan 2007 00:35:28 + Finished at: Wed, 10 Jan 2007 00:35:45 + Total time: 16s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes cziegeler Fix build /cocoon/trunk/core/cocoon-thread/cocoon-thread-impl/src/test/java/org/apache/cocoon/components/thread/DefaultThreadPoolTestCase.java Output: [INFO] Scanning for projects... [INFO] [INFO] Building Cocoon Thread Implementation [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/maven/continuum-data/working-directory/73/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-thread-api:1.0.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] [compiler:compile] Compiling 7 source files to /home/maven/continuum-data/working-directory/73/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 4 source files to /home/maven/continuum-data/working-directory/73/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/maven/continuum-data/working-directory/73/target/surefire-reports Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable runs Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable runs Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPool shutdown WARNING: running commands have not terminated within 100ms. Will shut them down by interruption Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable has been interrupted Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable terminated Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable has been interrupted Jan 10, 2007 12:35:42 AM org.apache.cocoon.components.thread.DefaultThreadPoolTestCase$1 run INFO: runnable terminated --- T E S T S --- Running org.apache.cocoon.components.thread.DefaultThreadPoolTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.995 sec Running org.apache.cocoon.components.thread.DefaultThreadFactoryTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec Results : Tests run: 19, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] Building jar: /home/maven/continuum-data/working-directory/73/target/cocoon-thread-impl-1.0.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing /home/maven/continuum-data/working-directory/73/target/cocoon-thread-impl-1.0.0-SNAPSHOT.jar to /home/maven/.m2/repository/org/apache/cocoon/cocoon-thread-impl/1.0.0-SNAPSHOT/cocoon-thread-impl-1.0.0-SNAPSHOT.jar [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 15 seconds [INFO] Finished at: Wed Jan 10 00:35:44 GMT 2007 [INFO] Final Memory: 6M/13M [INFO]
Re: viewing intermediate XML with profiler (was Re: Running Cocoon in debugger)
On 1/9/2007 5:36 PM, Reinhard Poetz wrote: Lars Huttar wrote: OK... I've registered, as you surmised, and I guess I need the doc-editors role. done Thanks. I've edited the page http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/concepts/profiler.html My edited version is at http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/concepts/profiler/version/3 Comments are welcome. Anything else I need to do? It does say warning This document belongs to the legacy documentation. I hope I was right to edit this document and not some other. I couldn't find an equivalent in the new Cocoon docs. I saw the instructions somewhere about logging in via SSH and rebuilding the documentation on cocoon.apache.org, but hopefully I can leave that to someone else. I'm not in that big of a hurry to see my changes. Thanks for the opportunity to improve this! Lars
