Hi,
AFAIK HTMLarea stopped being developed and Xinha has taken over. It's
supposed to be backwards compatible but has an active community. Maybe
replacing HTMLarea with Xinha already solves your problem:
http://xinha.python-hosting.com/
HTH
Bye, Helma
Leszek Gawron wrote:
It looks like
hepabolu wrote:
Hi,
AFAIK HTMLarea stopped being developed and Xinha has taken over. It's
supposed to be backwards compatible but has an active community. Maybe
replacing HTMLarea with Xinha already solves your problem:
http://xinha.python-hosting.com/
I might have expressed myself
I am in a need of a following functionality, so if anybody could outline
me the possible solution I will do the implementation:
I have a large form with lots of read only data ( repeaters ). When I
say large I mean dynamic html up to 1 MB. The form is organized in
several tabs (one repeater
This question is probably directed to Sylvain: as you are rewriting ajax
support with dojo library is there a control to display some kind of
progress bar when performing ajax requests? In fact a simple hourglass
or Loading... floating div would suffice.
--
Leszek Gawron
Leszek Gawron wrote:
This question is probably directed to Sylvain: as you are rewriting
ajax support with dojo library is there a control to display some kind
of progress bar when performing ajax requests? In fact a simple
hourglass or Loading... floating div would suffice.
Currently, when
Leszek Gawron wrote:
I am in a need of a following functionality, so if anybody could
outline me the possible solution I will do the implementation:
I have a large form with lots of read only data ( repeaters ). When I
say large I mean dynamic html up to 1 MB. The form is organized in
Today I hacked the remaining parts of a spring based container and got
the tree processor running using this one instead of ECM++. There are a
few glitches to fix, but I think the spring container is working.
Some parts are currently hacked, they can be cleaned up as soon as we
switched from
Giacomo Pati schrieb:
Now, with Spring I would suggest the following approach:
Cocoon uses an own application context which can be compared (by
simplifying) with a service manager. So we have an application context
for the core of Cocoon (again simplified). Now you can define a root
Spring
I just received this message from Richard Hall. Seems like Felix just go
that bit closer to meeting our needs, which is great. Is there anything
else we specifically need in order to use Felix instead of Eclipse?
Upayavira
Original Message
Subject: Cocoon and Felix
Date: Sun,
We also need the ability to use unpacked bundles for fast prototyping
(available in Equinox). We need the possibility to embed the OSGi
framework in a servlet container
(http://www.eclipse.org/equinox/incubator/server/embedding_in_a_servlet_container.php).
And we need a framework that work
Thanks for this Daniel - Richard copied in so he sees your reply.
Regards, Upayavira
Daniel Fagerstrom wrote:
We also need the ability to use unpacked bundles for fast prototyping
(available in Equinox). We need the possibility to embed the OSGi
framework in a servlet container
Eight years after the invention of XML, DOM and SAX,
despite their respective issues, are still the mainstays of application
developers. So is it the end of road for XML parsing
innovation? The VTD-XML project team think not. We are proud to
announce the availability of both C and Java
Jimmy Zhang wrote:
Eight years after the invention of XML, DOM and SAX,
despite their respective issues, are still the mainstays
of application developers.
So is it the end of road for XML parsing innovation?
The VTD-XML project team think not. We are proud to
announce the availability of
I am answering so as to keep the thread alive,
not because i know anything about stores.
Would someone who does know, please help Tim.
Being a Forrest committer, when we get him over the
learning hump, he might be able to help fix various
Cocoon issues.
Tim Williams wrote:
In forrest we've got
14 matches
Mail list logo
