ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 November 08:10 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-11 08:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy]
Re: Problem with ReloadingClassLoader
I have a nasty error that I can't track down. I'm using the ReloadingClassloader of trunk and include it with following code: map:classloader class-dir src=../blah/ /map:classloader I declare a couple of components like generators and actions. Using an action works as it has been doing for months but since an upgrade to the latest SVN I get following error when declaring a custom generator: You can reproduce it all the time only with generators?? The HTTP response is: HTTP ERROR: 500 my.CustomGenerator (Bad index in constant pool.) At the console following stacktrace appears: java.lang.ClassFormatError: my.CustomGenerator (Bad ind ex in constant pool.) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.lang.ClassLoader.defineClass(ClassLoader.java:448) at org.apache.cocoon.components.classloader.ReloadingClassLoaderFactory$ DefaultClassLoader.fastFindClass(ReloadingClassLoaderFactory.java:182) Now that's interesting :-/ ...with a basic class-dir there should be no rewriting that could possibly cause this. BTW, currently ReloadingClassLoaderFactory doesn't work out of the box as it isn't declared in any xconf ...but it's declared in the cocoon.roles - that should work fine cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: Problem with ReloadingClassLoader
Torsten Curdt wrote:
I have a nasty error that I can't track down. I'm using the
ReloadingClassloader of trunk and include it with following code:
map:classloader
class-dir src=../blah/
/map:classloader
I declare a couple of components like generators and actions. Using
an action works as it has been doing for months but since an upgrade
to the latest SVN I get following error when declaring a custom
generator:
You can reproduce it all the time only with generators??
yep, I'm using Eclipse 3.1 and the class-dir points to the porject's output
directory.
The HTTP response is:
HTTP ERROR: 500 my.CustomGenerator (Bad index in constant pool.)
At the console following stacktrace appears:
java.lang.ClassFormatError: my.CustomGenerator (Bad ind
ex in constant pool.)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.lang.ClassLoader.defineClass(ClassLoader.java:448)
at
org.apache.cocoon.components.classloader.ReloadingClassLoaderFactory$
DefaultClassLoader.fastFindClass(ReloadingClassLoaderFactory.java:182)
Now that's interesting :-/ ...with a basic class-dir there should
be no rewriting that could possibly cause this.
BTW, currently ReloadingClassLoaderFactory doesn't work out of the
box as it isn't declared in any xconf
...but it's declared in the cocoon.roles - that should work fine
you mean
http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/cocoon.roles?
Can't find it there. Only the DefaultClassLoaderFactory is declared.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/ org/apache/cocoon/forms/generation/JXMacrosHelper.java
On Thu, 10 Nov 2005, Joerg Heinicke wrote: The widgets in the repeater rows need to be displayed wrt some properties of a single object (let's say its a 'state of completness'). Now from MVC POV it's the viewer (template) that knows how to display the properties of the business model and thus needs a way to instruct the technology used (CForm) to respect that. Sorry, but I absolutely don't follow you here. MVC is for decoupling model, view and controller, i.e. to have as few as possible dependencies between the three aspects. There are three you need: the controller changing the model, the controller selecting the view and the view accessing the properties of the model. But the latter one must be a read-only process, otherwise the view does not only depend on the model, but also the model on the view, as the view would not be interchangeable. I thought I've said eactly this: The View knows how to display the Model (where do you read in my mail that the View changes the Model?) You didn't write that directly. I guess the difference is just if editable or not is a property of the model or the view. In your sample a property of the model (viewable or not, editable or not) shall be changed by the view, what is plain wrong IMO. It is the task of the controller to take care of it. That (editable = property of the model) is what I wanted to express with this paragraph. Jörg -- Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
Re: Problem with ReloadingClassLoader
On 11.11.2005, at 09:45, Reinhard Poetz wrote: Torsten Curdt wrote: I have a nasty error that I can't track down. I'm using the ReloadingClassloader of trunk and include it with following code: map:classloader class-dir src=../blah/ /map:classloader I declare a couple of components like generators and actions. Using an action works as it has been doing for months but since an upgrade to the latest SVN I get following error when declaring a custom generator: You can reproduce it all the time only with generators?? yep, I'm using Eclipse 3.1 and the class-dir points to the porject's output directory. And reloading actions still works? The HTTP response is: HTTP ERROR: 500 my.CustomGenerator (Bad index in constant pool.) At the console following stacktrace appears: java.lang.ClassFormatError: my.CustomGenerator (Bad ind ex in constant pool.) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.lang.ClassLoader.defineClass(ClassLoader.java:448) at org.apache.cocoon.components.classloader.ReloadingClassLoaderFactory $ DefaultClassLoader.fastFindClass(ReloadingClassLoaderFactory.java: 182) Now that's interesting :-/ ...with a basic class-dir there should be no rewriting that could possibly cause this. BTW, currently ReloadingClassLoaderFactory doesn't work out of the box as it isn't declared in any xconf ...but it's declared in the cocoon.roles - that should work fine you mean http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/ apache/cocoon/cocoon.roles? Can't find it there. Only the DefaultClassLoaderFactory is declared. Doh! ...no - I did not want to change the default behavior. So I did override it in the xconf component class=org.apache.cocoon.components.classloader.ReloadingClassLoaderFact ory role=org.apache.cocoon.components.classloader.ClassLoaderFactory/ ReloadingClassLoaderFactory/ In order to debug this I'd suggest to print out the size of the clazzBytes byte[] and then compare what's on the disk. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: Problem with ReloadingClassLoader
Torsten Curdt wrote:
BTW, currently ReloadingClassLoaderFactory doesn't work out of the
box as it isn't declared in any xconf
...but it's declared in the cocoon.roles - that should work fine
you mean http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/
apache/cocoon/cocoon.roles? Can't find it there. Only the
DefaultClassLoaderFactory is declared.
Doh! ...no - I did not want to change the default behavior.
So I did override it in the xconf
In which one?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: AJAX and upload widget
Antonio Gallardo wrote:
Upayavira wrote:
Antonio Gallardo wrote:
Hi:
I was playing around AJAX and the upload widget. Why the upload widget
is not supported by AJAX?
I started working on an AJAX progress bar for the upload widget during
the GetTogether.
Great!
I can explain where I got to if you want to look into
finishing it.
Yes, please! :-D
I've attached two patches, one for o.a.c.servlet.multipart, and one for
the forms block. This code is by no means finished, but may give you
ideas. It is based upon this demo:
http://sean.treadway.info/demo/upload
I stopped at the point at which I realised that I needed to switch from
using the Prototype periodic updater to using Cocoon's own implementation.
The basic idea behind this is that when the user clicks submit, an AJAX
periodic updater is started that reloads a bit of the screen every 2
seconds. This is the progress bar. Then it submits the form into a
hidden iframe to start the upload. The upload is handled by the
MultiPart code within Cocoon, which stores vital info (e.g. total file
size, size so far) in the session, so that when the periodic updater
requests a page, the progress bar can be built based upon how much has
been uploaded so far.
Now, if you don't get a chance to look at this, either myself or a
colleague might within the next week or so.
Regards, Upayavira
Index: java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
===
--- java/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 307124)
+++ java/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy)
@@ -459,25 +459,38 @@
| fi:upload
+--
xsl:template match=fi:upload
-span id=[EMAIL PROTECTED] title={fi:hint}
- xsl:choose
-xsl:when test=fi:value
- !-- Has a value (filename): display it with a change button --
-xsl:text[/xsl:text
-xsl:value-of select=fi:value/
-xsl:text] /xsl:text
-input type=button id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] value=... onclick=forms_submitForm(this)/
-/xsl:when
-xsl:otherwise
- input type=file id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]
-xsl:apply-templates select=. mode=styling/
- /input
-/xsl:otherwise
- /xsl:choose
- xsl:apply-templates select=. mode=common/
-/span
+ div id=[EMAIL PROTECTED] title={fi:hint} style=border: 2px solid black
+xsl:choose
+ xsl:when test=fi:value
+!-- Has a value (filename): display it with a change button --
+ xsl:text[/xsl:text
+ xsl:value-of select=fi:value/
+ xsl:text] /xsl:text
+ input type=button id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] value=... onclick=forms_submitForm(this)/
+ /xsl:when
+ xsl:otherwise
+input type=file id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]
+ xsl:apply-templates select=. mode=styling/
+/input
+ /xsl:otherwise
+/xsl:choose
+input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED] type=button value=upload onclick=return Cocoon.CForms.submitUpload($('[EMAIL PROTECTED]'), '[EMAIL PROTECTED]')/
+xsl:apply-templates select=. mode=common/
+div id=[EMAIL PROTECTED] style=display: none; border: 1px solid black
+ !-- NB: keep the following all on one line - makes the js easier: --
+ div class=forms-upload-progress-bar id=[EMAIL PROTECTED] style=border: 2px solid bluediv class=forms-upload-borderdiv id=[EMAIL PROTECTED] class=forms-upload-background style=width: {fi:[EMAIL PROTECTED]'progress-bar]/@width}%div class=forms-upload-foregrounda/div/div/div/div
+ div class=forms-upload-status id=[EMAIL PROTECTED] xmlns:bu=http://apache.org/cocoon/browser-update/1.0;
+xsl:if test=/bu:document
+ xsl:apply-templates select=fi:[EMAIL PROTECTED]'progress-bar']/*|fi:[EMAIL PROTECTED]'progress-bar']/text()/
+/xsl:if
+ /div
+/div
+ /div
+ iframe id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] src= style=width:300px;height:100px;border:2px solid black/iframe
/xsl:template
+ xsl:template match=fi:[EMAIL PROTECTED]'progress-bar']/
+
!--+
| fi:upload, output state
+--
Index: java/org/apache/cocoon/forms/resources/css/forms.css
===
--- java/org/apache/cocoon/forms/resources/css/forms.css (revision 307124)
+++ java/org/apache/cocoon/forms/resources/css/forms.css (working copy)
@@ -73,3 +73,25 @@
.forms-doubleList input {
width: 40px;
}
+
+.forms-upload-status {
+ margin: 5px;
+}
+
+.forms-upload-progress-bar {
+ margin: 5px;
+}
+
+.forms-upload-progress-bar .forms-upload-border {
+
Re: generating the 2.1 Changes page (Was: [Vote] Releasing 2.1.8 tomorrow)
Bertrand Delacretaz wrote: Le 11 nov. 05, à 04:26, David Crossley a écrit : ...The top-level docs are now building the changes page by getting the status.xml file from the 2.1 branch svn. Not ideal, but it works Great! http://forrest.zones.apache.org/ft/build/cocoon-site/changes.html The problem is that that page will not be added to the 2.1 docs package, but at least we can update it on the website... Yes, this is a l;imitation of the quick hack solution I had to do for the URL space solution, there is a workaround for now (see below). It will be fixed shortly. However... You mean, the page will not be in the distribution? Not necessarily, add a match into the daisy-to-docs sitemap.xmap and we can have it generated by Forrest alongside the daisy docs. Ross
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 11 November 11:10 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2005-11-11 11:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-cocoon: [copy] Warning: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf not found. configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] .. [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [get] Getting: http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip [get] . [get] last modified = Thu Nov 10 12:07:13 GMT+00:00 2005 final-check: [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install fetchplugin: unpack-plugin: extract-plugin: [unzip] Expanding: /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip into /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins install-plugin: configure-cocoon: [copy]
Re: Searching for a cool portal layout
Carsten Ziegeler wrote: I'm searching for a cool/nice layout for the portal engine in 2.2(trunk). I converted the html from tables and inline styling to div elements with css, but obviously the result does not look very nice... :) is this currently visible on cocoon.zones? if so, I agree it does look ugly ;-) I'll see what I can do. but more important: there are some s1 tags left in the resulting HTML code and a cinclude namespace. Bye, Helma
Re: [DOCS] Building for release - update round 2
hepabolu wrote: Ross Gardler wrote: Note, somehow only the menu is up on forrest.zones, all linked pages are gone. I suspect this is due to the split in the navigation doc in Daisy and should be fixed when Ross adjusts the appropriate files in Forrest. I'm not seeing this. I see the full contents of the site, all looking lovely, with the corect URLspace. Are you still seeing this problem? Just checked: no everything seems fine. There are three broken links in the site build now, I'll look at those tomorrow morning (UTC), if someone else wants to have a go at it the broken links are shown on: http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml IIUC there are four broken links, but I have no clue how to fix it, sorry. Yes, there were four. The first (2.1/index.html) didn't appear anywhere in the Daisy nav menu so Forrest had no way of knowing how to find it. I just added index to the About section. (NOTE there was a link to the index page used on daisy, but that is not the index page for the site so I removed that, you still see the daisy index when you go to the legacy docs on daisy itself). Two of the others had the same problem: 2.1/forms/binding.html and 2.1/forms/xmlbinding.html. The problem here is the fact that daisy does not allow grouping of documents without adding something to the path. There are only two files in this section of the navigation, so I don't think it is worth creating a separate nav document for them like we did with the higher level nodes, although that would solve the problem. I propose we either accept these as changed URLs and we add .htaccess rules for these two files. They are now at 2.1/forms/binding/binding.html and 2.1/forms/binding/xmlbinding.html If that is not acceptagble then someone needs to do as Helma did and create an import node for these two docs. The last one 2.1/userdocs/sitemap-components/transformers/core/i18n-transformer.html is a problem with Forrest. It uses a pattern of **i18n-*.html internally for some of its internationalisation stuff. This is obviously not good, I've raised an issue in Forrest, but it is too big a job fix now. I've therefore renamed this file to i18nTransformer as a workaround. But of course, this creates another change URL. I just did a test build and there are now no broken links. So, if our work has worked (next forrestbot build will confirm/deny this) we should be down to just three (or even one) changed URLs, quite manageable with an .htaccess file I think. Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. For the future: Bruno has suggested a change (on the Daisy list) to Daisy that will allow us to Group items without affecting the urlspace. So we can fix this problem in future releases (there is another Daisy user needs this too, so hopefully one of us will implement it). We'll also fix the i18n- urlspace limitation in Forrest. Ross
Re: Searching for a cool portal layout
hepabolu wrote: Carsten Ziegeler wrote: I'm searching for a cool/nice layout for the portal engine in 2.2(trunk). I converted the html from tables and inline styling to div elements with css, but obviously the result does not look very nice... :) is this currently visible on cocoon.zones? Yes. if so, I agree it does look ugly ;-) :) I'll see what I can do. Great! but more important: there are some s1 tags left in the resulting HTML code and a cinclude namespace. Oh, ok, I'll take care of this. Thanks! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [DOCS] Building for release - update round 2
Ross Gardler wrote: Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. Cool stuff. Send me result of find . -name *.html from http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/ and I'll compare with old url space (i don't have access to forrest.zones). Vadim
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Ross Gardler wrote: Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. Cool stuff. Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... Vadim
Re: Searching for a cool portal layout
So, if someone is interested in providing a new layout (css and perhaps images), that would be really cool. I think especially the tabs need some improvements. So anyone interested? I haven't seen yours yet but some time ago I made a div+css layout for the portal. If I remember well, it works with all browsers (it took me a long time to find something that works on ie!). It was designed to be easily adapted to every graphical style (it has some additional divs). The graphical layout is ugly but i think the html structure works. If interested, I'll try to find it in my backup, fix it up a bit and post it in the weekend.
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Vadim Gritsenko wrote: Ross Gardler wrote: Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. Cool stuff. Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). Ross
Re: [DOCS] Building for release - update round 2
Ross Gardler wrote: Vadim Gritsenko wrote: Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). I am in remove it completely camp... Vadim
Re: [DOCS] Building for release - update round 2
hepabolu wrote: Ross Gardler wrote: Two of the others had the same problem: 2.1/forms/binding.html and 2.1/forms/xmlbinding.html. Since this concerns only 2 files, just remove the grouping in Daisy so the url space matches. They both have binding in their label, so it should stand out in the menu. That solves the url change as well as the link problem. That makes sense, I did that, next build will show the change. The last one 2.1/userdocs/sitemap-components/transformers/core/i18n-transformer.html is a problem with Forrest. It uses a pattern of **i18n-*.html internally for some of its internationalisation stuff. This is obviously not good, I've raised an issue in Forrest, but it is too big a job fix now. I've therefore renamed this file to i18nTransformer as a workaround. But of course, this creates another change URL. so an .htaccess then? Yes, I think so. Ross
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Ross Gardler wrote: Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. Cool stuff. Send me result of find . -name *.html I just sent it offlist, but I sent it from the zone, not sure if mail is set up correctly there. If you don't recieive it you can get it at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt (note this is not regenerated when the site is rebuilt) The two files forms/binding/binding.html and forms/binding/xmlbinding.html will become the correct files. The only other known problem at this stage is i18n-transformer is now i18nTransformer (see earlier mail) Ross
Re: [DOCS] Building for release - update round 2
Ross Gardler wrote: I just sent it offlist, but I sent it from the zone, not sure if mail is set up correctly there. If you don't recieive it you can get it at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt Got the mail ok. (note this is not regenerated when the site is rebuilt) The two files forms/binding/binding.html and forms/binding/xmlbinding.html will become the correct files. The only other known problem at this stage is i18n-transformer is now i18nTransformer (see earlier mail) Hm, why some files are there twice? Example: /developing/concepts/avalon.html /documentation/developing/concepts/avalon.html Diff attached. Lots of differences, I'll sum up some of them here: * Duplicates: See example above. Was it simply because output directory was not cleared up between forrest runs? * Extra URI segments: /about /concepts (under /developing) /gettingstarted (under /faq) /sitemap(under /faq) /using (under /faq) /cocoon (under /howto) /contribution (under /howto) /documentation (under /howto) /testing(under /installing) /documentation (under /plan) /otherplanning (under /plan) /overview (under /plan) /api(under /userdocs/forms) /basics (under /userdocs/forms) /binding(under /userdocs/forms) /publishing (under /userdocs/forms) /widgetconcepts (under /userdocs/forms) /widgets(under /userdocs/forms) /sitemap-components (under /userdocs) /core (under /userdocs/sitemap-components/generators) /optional (under /userdocs/sitemap-components/generators) /core (under /userdocs/sitemap-components/matchers) /optional (under /userdocs/sitemap-components/matchers) /core (under /userdocs/sitemap-components/readers) /optional (under /userdocs/sitemap-components/readers) /scratchpad (under /userdocs/sitemap-components/readers) /core (under /userdocs/sitemap-components/selectors) /scratchpad (under /userdocs/sitemap-components/selectors) /core (under /userdocs/sitemap-components/serializers) /optional (under /userdocs/sitemap-components/serializers) /core (under /userdocs/sitemap-components/transformers) /optional (under /userdocs/sitemap-components/transformers) /logicsheets(under /userdocs/xsp) * Different URI segments: /snippets vs. /snippet Vadim --- docs-2.1-uris.txt 2005-11-11 09:53:45.542481600 -0500 +++ docs-new-uris.txt 2005-11-11 09:53:48.286427200 -0500 @@ -1,85 +1,381 @@ +/about/features.html +/about/license.html /bylaws-addendum.html -/catalog-test.html -/changes.html -/developing/avalon.html -/developing/datasources.html -/developing/deli.html -/developing/deliquick.html -/developing/extending.html -/developing/httprequest.html +/community/695.html +/community/697.html +/community/698.html +/community/699.html +/community/700.html +/community/701.html +/community/702.html +/community/703.html +/community/704.html +/community/705.html +/community/706.html +/community/bylaws-addendum.html +/community/who.html +/developing/concepts/avalon.html +/developing/concepts/datasources.html +/developing/concepts/deli.html +/developing/concepts/deliquick.html +/developing/concepts/extending.html +/developing/concepts/httprequest.html +/developing/concepts/parent-component-manager.html +/developing/concepts/source.html +/developing/concepts/stores.html /developing/index.html -/developing/parent-component-manager.html -/developing/portal/basket.html +/developing/portal/authentication.html /developing/portal/coplets.html +/developing/portal/coplets/cachinguricoplet.html +/developing/portal/coplets/uricoplet.html /developing/portal/events.html -/developing/portal/forms.html /developing/portal/index.html +/developing/portal/layout_skins.html /developing/portal/portal-block.html /developing/portal/profiles.html -/developing/source.html -/developing/stores.html +/developing/portal/samples/basket.html +/developing/portal/samples/forms.html +/developing/portal/wsrp.html /developing/web3.html /developing/webapps/authentication.html +/developing/webapps/authentication/application_management.html +/developing/webapps/authentication/authenticating_user.html +/developing/webapps/authentication/authentication-handler.html +/developing/webapps/authentication/module_management.html +/developing/webapps/authentication/pipeline_patterns.html +/developing/webapps/authentication/summary.html +/developing/webapps/authentication/user_administration.html +/developing/webapps/authentication/user_management.html /developing/webapps/contexts.html /developing/webapps/forms.html /developing/webapps/index.html /developing/webapps/portal.html /developing/webapps/session.html
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Ross Gardler wrote: Vadim Gritsenko wrote: Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). I am in remove it completely camp... I definitely don't like the ToC embedded in the left-hand menu. The top-of-page ToC is good though, e.g. see http://cocoon.apache.org/2.1/performancetips.html Though one day it would be good to utilise that whitespace. The ToC needs to be configured to less levels perhaps just one or maybe two levels. Otherwise some pages get confusing. -David
TOCs in documentation (Re: [DOCS] Building for release - update round 2)
Vadim Gritsenko wrote: Ross Gardler wrote: Vadim Gritsenko wrote: Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... It was moved there as a test, come people like it in the body, come in the page menu, some not at all. It is easy to move/remove (a setting in skinconf.xml in the daisy-to-docs module) - the question is where do we want it (or do we want to remove it). I am in remove it completely camp... On the Cocoon site, I am too, lets leave it for a while with the new subject line and see if anyone objects to us removing it completely. Ross
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Hm, why some files are there twice? Example: /developing/concepts/avalon.html /documentation/developing/concepts/avalon.html I know why. It is because the forrestbot didn't clean out its workspace on the server. So the old generated documents are still included. I will go do that Next run will be the actual set. -David
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Ross Gardler wrote: I just sent it offlist, but I sent it from the zone, not sure if mail is set up correctly there. If you don't recieive it you can get it at http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt Got the mail ok. (note this is not regenerated when the site is rebuilt) .. Diff attached. Lots of differences, I'll sum up some of them here: Thanks for this Vadim, saves us lots of time - sorry it wasn't as encouraging as I thought. * Duplicates: See example above. Was it simply because output directory was not cleared up between forrest runs? Yes, that is the problem, as David identified. I'm discussing with David as to whether the Forrestbot should always clear out its build directory on a new run (I thought it did). * Extra URI segments: Some of these are a result of the lack of a clean build space (i.e. about/), but others are the same problem with the daisy navigation, for example, the extra dirs under /userdocs/forms/ Helma did warns us that there were other places the URLspace had been changed in Daisy, I was hoping it would be less widespread than this though :-( I'm looking into it. Ross
Re: Searching for a cool portal layout
Paolo Ambrosio wrote: So, if someone is interested in providing a new layout (css and perhaps images), that would be really cool. I think especially the tabs need some improvements. So anyone interested? I haven't seen yours yet but some time ago I made a div+css layout for the portal. If I remember well, it works with all browsers (it took me a long time to find something that works on ie!). It was designed to be easily adapted to every graphical style (it has some additional divs). The graphical layout is ugly but i think the html structure works. If interested, I'll try to find it in my backup, fix it up a bit and post it in the weekend. Please do, I'm always interested in seeing what others make of it. BTW Carsten: if you want your tabs to have images to mimic real tabs, you need to add an a href=#/a to the selected tab, otherwise it is not possible to add a left side AND a right side of the tab image to the item. That means that the selected tab is also a link that leads to a refresh of the page. Do you have any objections to that? Bye, Helma
Re: [DOCS] Building for release - update round 2
Vadim Gritsenko wrote: Vadim Gritsenko wrote: Ross Gardler wrote: Perhaps Vadim can create a diff for us again to check this status, once the build has completed in around 3 hours. Cool stuff. Forgot to add... Can we loose page toc which now appears within left navigation bar? I'm not sure we should have it there, it certainly looks strange... Vadim :-) it was moved there because it looks odd/old fashioned at the top of the page. Personally I don't mind if it's removed all together. Bye, Helma
Re: Searching for a cool portal layout
hepabolu wrote: Paolo Ambrosio wrote: So, if someone is interested in providing a new layout (css and perhaps images), that would be really cool. I think especially the tabs need some improvements. So anyone interested? I haven't seen yours yet but some time ago I made a div+css layout for the portal. If I remember well, it works with all browsers (it took me a long time to find something that works on ie!). It was designed to be easily adapted to every graphical style (it has some additional divs). The graphical layout is ugly but i think the html structure works. If interested, I'll try to find it in my backup, fix it up a bit and post it in the weekend. Please do, I'm always interested in seeing what others make of it. Yepp, me, too. BTW Carsten: if you want your tabs to have images to mimic real tabs, you need to add an a href=#/a to the selected tab, otherwise it is not possible to add a left side AND a right side of the tab image to the item. That means that the selected tab is also a link that leads to a refresh of the page. Do you have any objections to that? No, I'm fine with that. I'm happy for any improvement wrt to layout and usability. Obviously html and css are not my core domain... :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1683) Allow configuration of expiry in EHDefaultStore
Allow configuration of expiry in EHDefaultStore --- Key: COCOON-1683 URL: http://issues.apache.org/jira/browse/COCOON-1683 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.7 Reporter: Johan Stuyts Attachments: cocoon-ehdefaultstore-configurable-expiry.patch EHDefaultStore initializes the cache to never expire entries. This means that the cache will grow indefinitely (on disk). This patch allows you to set the expiry of entries in the configuration so that stale entries will be removed. It simply adds three parameters to the component which are passed to EHCache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1683) Allow configuration of expiry in EHDefaultStore
[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ] Arjé Cahn closed COCOON-1683: - Resolution: Fixed Applied patch Thanks Johan! :-) Allow configuration of expiry in EHDefaultStore --- Key: COCOON-1683 URL: http://issues.apache.org/jira/browse/COCOON-1683 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.7 Reporter: Johan Stuyts Attachments: cocoon-ehdefaultstore-configurable-expiry.patch EHDefaultStore initializes the cache to never expire entries. This means that the cache will grow indefinitely (on disk). This patch allows you to set the expiry of entries in the configuration so that stale entries will be removed. It simply adds three parameters to the component which are passed to EHCache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r332608 - /cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
[EMAIL PROTECTED] wrote:
Author: arje
Date: Fri Nov 11 09:17:23 2005
New Revision: 332608
URL: http://svn.apache.org/viewcvs?rev=332608view=rev
Log:
Applied patch for issue 1683: Allow configuration of expiry in EHDefaultStore
http://issues.apache.org/jira/browse/COCOON-1683
+ Changed the copyright notice to 2004, 2005
Please let me know if I did it wrong 8-%
Do you doing very well! :-)
2 small points:
A. Use 2004-2005 instead
B. Patch also 2.1.8. ;-)
Best Regards,
Antonio Gallardo.
Modified:
cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
Modified:
cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
URL:
http://svn.apache.org/viewcvs/cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java?rev=332608r1=332607r2=332608view=diff
==
---
cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
(original)
+++
cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
Fri Nov 11 09:17:23 2005
@@ -1,5 +1,5 @@
/*
- * Copyright 2004,2004 The Apache Software Foundation.
+ * Copyright 2004, 2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -70,6 +70,9 @@
// configuration options
private int maxObjects;
private boolean overflowToDisk;
+private boolean eternal;
+private long timeToLiveSeconds;
+private long timeToIdleSeconds;
/** The service manager */
private ServiceManager manager;
@@ -109,6 +112,15 @@
* licodemaxobjects/code (1) - The maximum number of in-memory
objects./li
* licodeoverflow-to-disk/code (true) - Whether to spool elements to
disk after
* maxobjects has been exceeded./li
+ * licodeeternal/code (true) - whether or not entries expire. When
set to
+ * codefalse/code the codetimeToLiveSeconds/code and
+ * codetimeToIdleSeconds/code parameters are used to determine when an
+ * item expires./li
+ * licodetimeToLiveSeconds/code (0) - how long an entry may live in
the cache
+ * before it is removed. The entry will be removed no matter how frequently it
is retrieved./li
+ * licodetimeToIdleSeconds/code (0) - the maximum time between
retrievals
+ * of an entry. If the entry is not retrieved for this period, it is
removed from the
+ * cache./li
* licodeuse-cache-directory/code (false) - If true the
icache-directory/i
* context entry will be used as the location of the disk store.
* Within the servlet environment this is set in web.xml./li
@@ -117,11 +129,50 @@
* Within the servlet environment this is set in web.xml./li
* licodedirectory/code - Specify an alternative location of the
disk store.
* /ul
+ *
+ * p
+ * Setting codeeternal/code to codefalse/code but not setting
+ * codetimeToLiveSeconds/code and/or codetimeToIdleSeconds/code,
has the
+ * same effect as setting codeeternal/code to codetrue/code.
+ * /p
+ *
+ * p
+ * Here is an example to clarify the purpose of the
codetimeToLiveSeconds/code and
+ * codetimeToIdleSeconds/code parameters:
+ * /p
+ * ul
+ * litimeToLiveSeconds = 86400 (1 day)/li
+ * litimeToIdleSeconds = 10800 (3 hours)/li
+ * /ul
+ *
+ * p
+ * With these settings the entry will be removed from the cache after 24
hours. If within
+ * that 24-hour period the entry is not retrieved within 3 hours after the
last retrieval, it will
+ * also be removed from the cache.
+ * /p
+ *
+ * p
+ * By setting codetimeToLiveSeconds/code to code0/code, an item
can stay in
+ * the cache as long as it is retrieved within
codetimeToIdleSeconds/code after the
+ * last retrieval.
+ * /p
+ *
+ * p
+ * By setting codetimeToIdleSeconds/code to code0/code, an item
will stay in
+ * the cache for exactly codetimeToLiveSeconds/code.
+ * /p
*/
public void parameterize(Parameters parameters) throws ParameterException {
this.maxObjects = parameters.getParameterAsInteger(maxobjects, 1);
this.overflowToDisk =
parameters.getParameterAsBoolean(overflow-to-disk, true);
+
+this.eternal = parameters.getParameterAsBoolean(eternal, true);
+if (!this.eternal)
+{
+this.timeToLiveSeconds =
parameters.getParameterAsLong(timeToLiveSeconds, 0L);
+this.timeToIdleSeconds =
parameters.getParameterAsLong(timeToIdleSeconds, 0L);
+}
try {
if (parameters.getParameterAsBoolean(use-cache-directory, false))
{
@@ -211,7 +262,8 @@
public void initialize() throws Exception {
URL configFileURL =
Thread.currentThread().getContextClassLoader().getResource(CONFIG_FILE);
RE: svn commit: r332608 - /cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
2 small points: A. Use 2004-2005 instead B. Patch also 2.1.8. ;-) Thanks, Antonio, I will fix this! Arje
Re: svn commit: r332608 - /cocoon/trunk/src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
On 11.11.2005 18:57, Arje Cahn wrote: 2 small points: A. Use 2004-2005 instead B. Patch also 2.1.8. ;-) Thanks, Antonio, I will fix this! Code freeze? Jörg
HTTP POST with XML body
Hi all, I'm sure this has been discussed before, but since I didn't find a solution, I've built my own. My problem is, that I need to POST XML-documents somewhere out of Cocoon and receive the resulting document (e.g. for takling to an eXist database because there are currently known bugs with their Cocoon integration and for integrating an XML-RPC based ERP system on the other hand). None of the Cocoon generators/transformers seemed to do the job (even CInclude has known bugs concerning POST), so I took the WebServiceProxyGenerator (which sounds like a good starting point :) and added the following parameters: - postbody - any valid Cocoon source URI. The resulting document is sent as the body of the POST request. - postbodyenc - the encoding used to serialize the postbody. UTF-8 by default. - username and password - used for basic authentication. - dropparams - if set to true the params from the present request are not passed to the target system (my ERP system was confused by params it didn't expect). I attached a diff against the 2.1.7 version of WebServiceProxyGenerator. I tested a couple of cases and it seems to solve at least my problems (for now). Any opinions on integrating this into the source tree? Best regards, Daniel WebServiceProxyGenerator_postxml.diff.gz Description: application/gzip
Re: Ajax bug:update textarea wrong.
roy huang wrote:
Hi,all:
In
sample:http://localhost:/samples/blocks/forms/do-datasourceChooser.flow
Change ft:widget id=name/ to ft:widget id=namefi:styling
type=textarea rows=5 cols=65/fi:styling
/ft:widget
and don't enter datasource name,click OK:
the textarea appear :
a class=forms-validation-message href=# onclick=alert('此域是必须的'); return
false; ! /aspan class=forms-field-required * /span/span
Obviously this message update before /textarea tag ,I think the js
believe empty textarea all render as textarea/
Can this be fixed before release?
Sorry, but I can't reproduce this: I did the change and clicked ok,
and the textarea was displayed correctly...
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Searching for a cool portal layout
Carsten Ziegeler wrote: No, I'm fine with that. I'm happy for any improvement wrt to layout and usability. Obviously html and css are not my core domain... :) Carsten, could you go over the portal sample once again? There are still some namespaces left in the resulting html (e.g. xmlns:java xmlns:cl etc.). I'm not sure if that has any influence on the CSS, but it prevents valid HTML and since we strive to adhere to standards, we might as well try to get to valid HTML as far as possible. I also noted an extra 'coplet' attribute added here and there. Not sure if it's necessary for the workings of the portlet, but if you can loose it, please do. If I run into other quirks I'll post them. Bye, Helma
