On Nov 24, 2003, at 1:18 AM, Erik Bruchez wrote:
This being said, for those who judge techologies without reading the
specs (or who read them too fast), there is nothing in JavaServer
Faces that forces you to use JSP or that limits you to outputting a
character stream from a renderer.
Amen.
An
Leszek Gawron dijo:
Could you provide me with some link to OJB docs that describe handling
databases witch triggers modifying the DB content?
http://db.apache.org/ojb/how-to-work-with-stored-procedures.html
(Follow the document, they create some triggers for Oracle in the sample).
Best
I think that in cocoon 2.1.3 the sitemap parameters
are not available for serializers. They're always
set to empty parameters when the
SitemapModelComponent is a Serializer.
Is that correct?
It is correct that... you found a bug :-/
The sitemap engine wasn't updated to take into
On Sat, 2003-11-22 at 21:39, Timothy Larson wrote:
--- Bruno Dumon [EMAIL PROTECTED] wrote:
On Fri, 2003-11-21 at 14:37, Timothy Larson wrote:
I found the naming of the class/new widgets confusing. In fact, I think
it is confusing to call them widgets at all, even if they might be
On Mon, 2003-11-24 at 01:18, Erik Bruchez wrote:
I just laughed. It will be a very hard job for any JSF proponent to
convince multi-channel-intensive users to follow that renderkits road.
I don't envy them at all ;-)
They'll probably defend by saying you can write a renderkit that
Vadim Gritsenko wrote:
Hi all,
Currently I'm looking into i18n transformer... Couple of most irritating
problems I want to solve are:
* No reload of catalogues on change
This would be very cool!
* Crashes when message/ contains tag with attributes: messagebla a
href=bla bla /a bla /message
Hi:
It is OK the following libs changes in cocoon 2.2:
Add (from cocoon 2.1):
excalibur-event-api-1.0.4-dev.jar
excalibur-event-impl-1.0.4-dev.jar
excalibur-sourceresolve-1.0.2-dev.jar
excalibur-store-1.0-dev.jar
excalibur-xmlutil-1.0-dev.jar
Remove:
excalibur-event-20030904.jar
It should be. Just do it.
Unico
-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: maandag 24 november 2003 14:18
To: [EMAIL PROTECTED]
Hi:
It is OK the following libs changes in cocoon 2.2:
Add (from cocoon 2.1):
excalibur-event-api-1.0.4-dev.jar
Should be no problem, though it might be better to have real releases. Ralph
Goers on the users list mentioned that it is always a problem to grap the
sources of these packages from CVS. The below updated versions are no real
releases, but only recent tagged versions in the CVS. So there is no
On http://wiki.cocoondev.org/PageInfo.jsp?page=FirstFriday David
(Crossley) says it's going to be on the 12th, is that a typo or is
there a good reason?
-Bertrand
I'm copying the mail list. Thanks for notifying us. We'll solve the
issues you outline ASAP.
On 21 Nov 2003, at 00:23, Thomas J. Sebestyen wrote:
Dear Diana,
Dear Stefano,
Dear Greg,
I have just only two simple questions.
The first one is not really a question, it's related to the
Joerg Heinicke wrote:
Should be no problem, though it might be better to have real releases.
Ralph Goers on the users list mentioned that it is always a problem to
grap the sources of these packages from CVS. The below updated versions
are no real releases, but only recent tagged versions in
Hello,
As Wiki became more than 50% of written documentation I think it is crucial to
provide users with some kind of it's offline version. I have already found
myself stalled at some problem because I had no internet access at the moment.
I know I can fetch an offline version of the site but
On 22.11.2003 03:49, Vadim Gritsenko wrote:
Joerg Heinicke wrote:
(By the way, the simplification to
xsp:logic
if (somecondition()) {
true_tag/
} else {
false_tag/
}
/xsp:logic
is exactly what does not work at Cocoon and was the reason for
Hi,
I asked a question to the user list. However no-one was able to offer any assistance on that list.
We have spent a lot of time investigating options and haven't found any solutions yet.
We are having a lot of problems with caching and XSLT transformers. We are using deli, so our caches
Hi,
is there any special intension (configure component once, run many times
with less if's for performance issues?) to configure the extract-uri
and extract-element for the FragmentExtractorTransformer (batik
block) inside map:components instead of to to make them known via
map:parameters?
I
I have noticed that woody-field-styling.xsl uses a $uri variable to prefix all
resources but it is only used in xsl:template name=woody-field-head
while the part that renders calendar icon has the address hardcoded.
I think that this parameter should be top level for this stylesheet so it is
On 23 Nov 2003, at 21:16, Tony Collen wrote:
There's a few interesting posts going on over at [1] regarding the use
of continuations on web.
Continuations break the back button? bah.
I tried to set one of the people commenting straight on how it works
in Cocoon, but they seems to be convinced
On 23 Nov 2003, at 22:04, Bruno Dumon wrote:
OTOH, renderkits not only abstract the rendering but also the decoding
of request parameters, so that's a point where they are more flexibile
then Woody, where it is all hardcoded in the widgets (and assumes
HTML-like behaviour).
Do you see value in
Stefano Mazzocchi wrote:
On 23 Nov 2003, at 22:04, Bruno Dumon wrote:
OTOH, renderkits not only abstract the rendering but also the decoding
of request parameters, so that's a point where they are more flexibile
then Woody, where it is all hardcoded in the widgets (and assumes
HTML-like
On Mon, Nov 24, 2003 at 04:55:50PM +0100, Stefano Mazzocchi wrote:
On 23 Nov 2003, at 21:16, Tony Collen wrote:
There's a few interesting posts going on over at [1] regarding the use
of continuations on web.
Continuations break the back button? bah.
I have also a problem that maybe the
On 21 Nov 2003, at 00:23, Thomas J. Sebestyen wrote:
I have just only two simple questions.
The first one is not really a question, it's related to the
page/directory:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/
documentation/xdocs/faq/
probably no one from you is using the
Leszek Gawron wrote:
I have noticed that woody-field-styling.xsl uses a $uri variable to prefix all
resources but it is only used in xsl:template name=woody-field-head
while the part that renders calendar icon has the address hardcoded.
I think that this parameter should be top level for this
Stefano Mazzocchi wrote:
On 21 Nov 2003, at 09:45, Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
..
So I added a new method to cocoon that sets up an object just as
if it were an Avalon component by honoring the various lifecycle
interfaces.
Some useful lifecycle
Leszek Gawron wrote:
I have also a problem that maybe the same: How should one protect the
application from resubmitting the previous continuation? If user hits back
button and submits again the the form gets into inconsistent state (some
action gets called twice).
var kont =
Stefano Mazzocchi wrote:
On 23 Nov 2003, at 21:16, Tony Collen wrote:
There's a few interesting posts going on over at [1] regarding the use
of continuations on web.
Continuations break the back button? bah.
Yep, looks like some coins still need to fall.
On the other hand, invalidated
On 24.11.2003 17:44, Upayavira wrote:
Bertrand Delacretaz wrote:
On http://wiki.cocoondev.org/PageInfo.jsp?page=FirstFriday David
(Crossley) says it's going to be on the 12th, is that a typo or is
there a good reason?
-Bertrand
Well, 5th is the first Friday, and I don't see a reason why it
On 24.11.2003 18:40, [EMAIL PROTECTED] wrote:
reinhard2003/11/24 09:40:41
Modified:src/documentation/xdocs book.xml index.xml
Added: src/documentation/xdocs features.xml
Log:
- add features list from http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
to CVS
Cool. I
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
--
Bruno Dumon http://outerthought.org/
Outerthought -
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1. Apply your patches yourself ;-)
Sylvain
--
Sylvain Wallez
From: Joerg Heinicke
On 24.11.2003 18:40, [EMAIL PROTECTED] wrote:
reinhard2003/11/24 09:40:41
Modified:src/documentation/xdocs book.xml index.xml
Added: src/documentation/xdocs features.xml
Log:
- add features list from
http://wiki.cocoondev.org/Wiki.jsp?
From: Bruno Dumon
Tim has been hanging around on our mailing lists for quite
some time, and is actively contributing, both in discussions
and code. Becoming a committer can only motivate him to keep
up the good work.
+1 from me.
+1
--
Reinhard
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1 - welcome!
Geoff
On Mon, 2003-11-24 at 06:27, Timothy Larson wrote:
--- Bruno Dumon [EMAIL PROTECTED] wrote:
...slow operation on deeper nesting levels...
Don't have any either (damn that optimizeit thing is expensive), but
suddenly the thought crossed my mind that this might be caused by the
calls to
On 24.11.2003 15:36, Geoff Howard wrote:
Joerg Heinicke wrote:
Should be no problem, though it might be better to have real releases.
Ralph Goers on the users list mentioned that it is always a problem to
grap the sources of these packages from CVS. The below updated
versions are no real
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1... welcome aboard!
Tony
On 24 Nov 2003, at 17:06, Leszek Gawron wrote:
On Mon, Nov 24, 2003 at 04:55:50PM +0100, Stefano Mazzocchi wrote:
On 23 Nov 2003, at 21:16, Tony Collen wrote:
There's a few interesting posts going on over at [1] regarding the
use
of continuations on web.
Continuations break the back button?
On 24.11.2003 19:24, [EMAIL PROTECTED] wrote:
reinhard2003/11/24 10:24:54
Modified:site/2.1 index.html index.pdf
Added: site/2.1 features.html features.pdf
Log:
- add features list to our web site
Unfortunately you have to commit more than the above two HTML pages. You
On Nov 24, 2003, at 7:09 PM, Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
Ditto here: welcome, Timothy!
/Steven
On Nov 24, 2003, at 4:57 PM, Stefano Mazzocchi wrote:
I'll do it then.
Yep, saw that. Thanks!
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo Member
Read my weblog at
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1
Guido
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1
Matthew
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite
some time, and is actively contributing, both in discussions
and code. Becoming a committer can only motivate him to keep
up the good work.
+1 from me.
+1
how is marked that a wiki page is ready to move to CVS?
--stavros
On Mon, 24 Nov 2003, Joerg Heinicke wrote:
On 24.11.2003 18:40, [EMAIL PROTECTED] wrote:
reinhard2003/11/24 09:40:41
Modified:src/documentation/xdocs book.xml index.xml
Added:
[EMAIL PROTECTED] wrote:
how is marked that a wiki page is ready to move to CVS?
I think whenever someone decides it's ready :)
--stavros
Tony, soon to have time to devote to working on Cocoon again
On 24.11.2003 16:45, Sebastian Klamar wrote:
Hi,
is there any special intension (configure component once, run many times
with less if's for performance issues?) to configure the extract-uri
and extract-element for the FragmentExtractorTransformer (batik
block) inside map:components instead of
Joerg Heinicke wrote:
On 24.11.2003 15:36, Geoff Howard wrote:
Joerg Heinicke wrote:
Should be no problem, though it might be better to have real
releases. Ralph Goers on the users list mentioned that it is always a
problem to grap the sources of these packages from CVS. The below
updated
On 24.11.2003 20:27, [EMAIL PROTECTED] wrote:
how is marked that a wiki page is ready to move to CVS?
I guess almost every page has valuable content to be moved to the CVS.
The only question is: Who does the work? Reinhard simply started with
the maybe most wanted page for the official
so why not start to rate wiki pages so if anyone want to do something
start with most wanted pages ?
-- stavros
On Mon, 24 Nov 2003, Joerg Heinicke wrote:
On 24.11.2003 20:27, [EMAIL PROTECTED] wrote:
how is marked that a wiki page is ready to move to CVS?
I guess almost every page
Reinhard Poetz wrote:
From: Joerg Heinicke
On 24.11.2003 18:40, [EMAIL PROTECTED] wrote:
reinhard2003/11/24 09:40:41
Modified:src/documentation/xdocs book.xml index.xml
Added: src/documentation/xdocs features.xml
Log:
- add features list from
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite
some time, and is actively contributing, both in discussions
and code. Becoming a committer can only motivate him to keep
up the good work.
+1 from me.
+1
J.
Le Lundi, 24 nov 2003, à 19:09 Europe/Zurich, Bruno Dumon a écrit :
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1, welcome Tim!
-Bertrand
Sorry Antonio, but you absolutely missed my points. I don't want to
remove JavaScript or HTML, but I want to have good code - maintainable,
readable, understandable, extendible and so on. Especially having the
help popups based on the same bad code was one thing I didn't like.
I will answer to
Le Lundi, 24 nov 2003, à 19:22 Europe/Zurich, Reinhard Poetz a écrit :
..It's time for Doco because moving content from Wiki to CVS is a very,
very, very, very boring job. (Aren't there any tools which could
help?)...
If you're talking about format conversion, JSPWiki's HTML shouldn't be
hard to
On 22.11.2003 08:55, Antonio Gallardo wrote:
IMO Woody should re-focus on form processing. Yes, we should
provide a default view, but a simple one. If there must be used any JS
as I see it for the calendar or the help popups then it should
definitely be done the standard way (i.e. W3C DOM)
Bertrand Delacretaz wrote:
Le Lundi, 24 nov 2003, à 19:22 Europe/Zurich, Reinhard Poetz a écrit :
..It's time for Doco because moving content from Wiki to CVS is a very,
very, very, very boring job. (Aren't there any tools which could
help?)...
If you're talking about format conversion,
[EMAIL PROTECTED] wrote:
so why not start to rate wiki pages so if anyone want to do something
start with most wanted pages ?
It is simpler than that.
A page gets into the CVS when someone wants to put it there. So if you
think a page should be in the CVS, then suggest it here, and if it
BTW, when a page is moved, I think we should keep the page on the wiki, and perhaps keep a record of
when the last version was committed to CVS.
Blowing away docs (like the features list) isn't too useful, especially since I was going to point
to the version of the docs in the Wiki, and
On 22.11.2003 14:40, Sylvain Wallez wrote:
It's maybe to late in the night to start a rant, but I will do it.
Rants are more ranty late in the night ;-)
I hear your concerns an try to turn them into constructive criticism.
Thanks ...
See below:
The problem I have with Woody at the moment is,
Le Lundi, 24 nov 2003, à 21:05 Europe/Zurich, Upayavira a écrit :
...From looking at the BeanShell docs, the Java is definitely
'scripted' java, and lacks Java's object orientedness...
But what about this example from the BeanShell docs:
buttonHandler = new ActionListener() {
On 22.11.2003 18:30, Ugo Cei wrote:
I'm with you here. Let's face it, what people are and will be using
Woody for is mainly HTML forms, and there's no way you can make a decent
form-based application without *lots* of DHTML code.
But the current code is not DHTML, but document.write().
For
On 23.11.2003 20:21, Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
At the same time, all the style should happen in the XSLT thus the
HTML calendar strings worries me.
I think it can be easily addresses by inspecting with XPath if there is
a widget with Date datatype. In that way we can
I just wanted to take moment and thank the cocoon community.
Cocoon kicks butt.
I make small to medium small business / personal web applications.
Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP
I think)
After the initial learning curve (which seems to extend a bit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24950.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 24.11.2003 21:28, Tony Collen wrote:
BTW, when a page is moved, I think we should keep the page on the wiki,
and perhaps keep a record of when the last version was committed to CVS.
Blowing away docs (like the features list) isn't too useful, especially
since I was going to point to the
Joerg Heinicke wrote:
The problem I saw (and because of this I removed the list) are the
missing diffs (or the bad usability with it) after further additions to
the page are made. Imagine in a half year you want to update the page in
the CVS, in the meantime there were 10 changes in the wiki
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1
Warm welcome to an extra woody-man!
-marc=
--
Marc Portier
+1
Cheers,
Marcus
On Mon, Nov 24, 2003 at 07:09:57PM +0100, Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
On 24.11.2003 09:14, Ugo Cei wrote:
Stefano Mazzocchi wrote:
At the same time, all the style should happen in the XSLT thus the
HTML calendar strings worries me.
I am using another calendar with Woody:
http://dynarch.com/mishoo/calendar.epl. As the author says:
It works with Mozilla,
Tony Collen wrote:
BTW, when a page is moved, I think we should keep the page on the
wiki, and perhaps keep a record of when the last version was committed
to CVS.
Blowing away docs (like the features list) isn't too useful,
especially since I was going to point to the version of the docs in
JD Daniels wrote:
I just wanted to take moment and thank the cocoon community.
Cocoon kicks butt.
I make small to medium small business / personal web applications.
Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP
I think)
After the initial learning curve (which seems
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24950.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Le Lundi, 24 nov 2003, à 21:55 Europe/Zurich, Upayavira a écrit :
...I agree that blowing away docs is bad. However, just leaving them
is pretty bad too.
IMO, once a doc is moved to CVS, the original wiki page should be
replaced by a placeholder, which is where people can place comments
about
On 24.11.2003 21:55, Upayavira wrote:
Tony Collen wrote:
BTW, when a page is moved, I think we should keep the page on the
wiki, and perhaps keep a record of when the last version was committed
to CVS.
Blowing away docs (like the features list) isn't too useful,
especially since I was going
On 24.11.2003 21:58, Bertrand Delacretaz wrote:
...I agree that blowing away docs is bad. However, just leaving them
is pretty bad too.
IMO, once a doc is moved to CVS, the original wiki page should be
replaced by a placeholder, which is where people can place comments
about the related page
Bertrand Delacretaz wrote:
Le Lundi, 24 nov 2003, à 21:05 Europe/Zurich, Upayavira a écrit :
...From looking at the BeanShell docs, the Java is definitely
'scripted' java, and lacks Java's object orientedness...
But what about this example from the BeanShell docs:
buttonHandler = new
Le Lundi, 24 nov 2003, à 22:06 Europe/Zurich, Tony Collen a écrit :
...Would a centralized list of pages that were moved over (along with
the last date they were moved) be useful to maintain?
If all moved pages point to
http://wiki.cocoondev.org/Wiki.jsp?page=MovedToCvs then the Referenced
by
Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
...From that point of view my solution must be really good in your
opinion :-)
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
hmmm..maybe we should push a little more towards patches?
Instead of
If you want to add
On 24.11.2003 22:05, Bertrand Delacretaz wrote:
Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
...From that point of view my solution must be really good in your
opinion :-)
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
hmmm..maybe we should push a little
Tony Collen wrote:
Joerg Heinicke wrote:
The problem I saw (and because of this I removed the list) are the
missing diffs (or the bad usability with it) after further additions
to the page are made. Imagine in a half year you want to update the
page in the CVS, in the meantime there were 10
Bertrand Delacretaz wrote:
Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
...From that point of view my solution must be really good in your
opinion :-)
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
hmmm..maybe we should push a little more towards patches?
Le Lundi, 24 nov 2003, à 22:02 Europe/Zurich, Upayavira a écrit :
...Then I've effectively created a class. But it seems a bit around
the houses to me...
ok, see your point now, thanks.
Don't close the door on scripting stuff too soon though, there's a lot
happening with Groovy [1] (not to
Joerg Heinicke wrote:
snip/
Of course. But as I pointed out the current solution is not really
cross-browser, but only works for many browsers at the moment because
they are backwards compatible. I don't know if you heard of it, but at
the time Apple chose Konqueror as the base of Safari they
Joerg Heinicke wrote:
On 24.11.2003 21:55, Upayavira wrote:
Tony Collen wrote:
BTW, when a page is moved, I think we should keep the page on the
wiki, and perhaps keep a record of when the last version was
committed to CVS.
Blowing away docs (like the features list) isn't too useful,
Joerg Heinicke wrote:
I'm with you here and would even not add a simple stylesheet. People
adding simply a guestbook won't use Cocoon, so it's more or less useless
effort. Cocoon Forms has higher aims :-)
Sorry if I misunderstood you, but your sentence on focusing on server
side form processing
Welcome aboard, Tim! :-D
+1
Antonio Gallardo
Bruno Dumon dijo:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
On 24.11.2003 22:32, Ugo Cei wrote:
Joerg Heinicke wrote:
I'm with you here and would even not add a simple stylesheet. People
adding simply a guestbook won't use Cocoon, so it's more or less
useless effort. Cocoon Forms has higher aims :-)
Sorry if I misunderstood you, but your sentence on
On 19.11.2003 03:43, Antonio Gallardo wrote:
Hi:
I found this interesting article about the recent MS published schemas.
And I like to share it with the rest of the community:
http://www.theregister.co.uk/content/4/34045.html
What a frustrating point of view! But I fear to much will be true:
* Joerg Heinicke [2003-11-24 20:33 +0100] wrote:
The change would be really easy as you can see if you have a look at
other transformers that are map:parameterizable - something I could
even do ;-) But I don't have that much time at the moment.
I've done the changes locally. I could post a
On 24.11.2003 23:04, Sebastian Klamar wrote:
* Joerg Heinicke [2003-11-24 20:33 +0100] wrote:
The change would be really easy as you can see if you have a look at
other transformers that are map:parameterizable - something I could
even do ;-) But I don't have that much time at the moment.
Hi!
Is it ok to change 'add-below' to 'add-after' on the following Wiki doc
for the row-action widget?
http://wiki.cocoondev.org/Wiki.jsp?page=WoodyWidgetReference#ref-WoodyWidgetReference-9
You'll find it directly below the box.
Or do I miss here something ...
--
Andreas Hochsteger
JD Daniels wrote:
I just wanted to take moment and thank the cocoon community.
Cocoon kicks butt.
I make small to medium small business / personal web applications.
Nothing fancy, basically alot of xsp + xsl templates (These alone match PHP I think)
After the initial learning curve (which seems
Andreas Hochsteger wrote:
Hi!
Is it ok to change 'add-below' to 'add-after' on the following Wiki
doc for the row-action widget?
http://wiki.cocoondev.org/Wiki.jsp?page=WoodyWidgetReference#ref-WoodyWidgetReference-9
You'll find it directly below the box.
Or do I miss here something ...
Thanks, next time I'll try myself ;-)
--
Andreas Hochsteger
http://highstick.blogspot.com/
Sylvain Wallez wrote:
Andreas Hochsteger wrote:
Hi!
Is it ok to change 'add-below' to 'add-after' on the following Wiki
doc for the row-action widget?
Joerg Heinicke wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
On http://wiki.cocoondev.org/PageInfo.jsp?page=FirstFriday David
(Crossley) says it's going to be on the 12th, is that a typo or is
there a good reason?
Well, 5th is the first Friday, and I don't see a reason why
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24457.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I had further discussion with Thomas and we found out, that the reason
is the DTD handling of IE. If you view the XML (or HTML) documents in
render mode, IE searches for the linked DTD. These links point to the
old relative locations of the files, exactly where they were before we
switched to
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1
--David
Tony Collen wrote:
Bertrand Delacretaz wrote:
Reinhard Poetz a écrit :
..It's time for Doco because moving content from Wiki to CVS is a very,
very, very, very boring job. (Aren't there any tools which could
help?)...
If you're talking about format conversion, JSPWiki's HTML
Sebastian Klamar wrote:
Hi,
is there any special intension (configure component once, run many times
with less if's for performance issues?) to configure the extract-uri
and extract-element for the FragmentExtractorTransformer (batik
block) inside map:components instead of to to make them known
1 - 100 of 104 matches
Mail list logo
