Il giorno 09/apr/04, alle 16:11, Marc Portier ha scritto:
Ugo Cei wrote:
Il giorno 09/apr/04, alle 14:16, Marc Portier ha scritto:
more?
Write tests, maybe? ;-)
agree, in fact I'm just looking at most of the samples being broken
ATM (hoping it's only local)
do you have any suggestions
Il giorno 09/apr/04, alle 14:16, Marc Portier ha scritto:
more?
Write tests, maybe? ;-)
Ugo
Il giorno 09/apr/04, alle 18:07, Rolf Kulemann ha scritto:
Hello,
it would be great if we could update the webdavlib, since a lot of bugs
have been fixed in this rc1.
For example one important issue which also affects the newly designed
Repository interface and its WebDAV implementation
Il giorno 08/apr/04, alle 01:34, Joerg Heinicke ha scritto:
What exactly does it do? The generate() is not that complex. Just an
XML structure of the current date?
It generates an XML representation of any given month. If you're
familiar with the old Unix cal program, it does just that. I'm now
[EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=25110
[Roadmap] CocoonForms - release 1.0
This bug depends on bug 24900, which changed state:
What|Old Value |New Value
Excuse me if this is a FAQ, but what is a generator implementing the
o.a.c.caching.CacheableProcessingComponent interface expected to return
as the value of the getValidity method, in case the generated content
never changes?
TIA,
Ugo
Il giorno 08/apr/04, alle 00:18, Upayavira ha scritto:
Ugo Cei wrote:
Excuse me if this is a FAQ, but what is a generator implementing the
o.a.c.caching.CacheableProcessingComponent interface expected to
return as the value of the getValidity method, in case the
generated content never
Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
Is / . that much more harder than arrow down x ?
The coommand for findiing the next match is n not /.
Ugo
Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:
Ugo Cei wrote:
Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
Is / . that much more harder than arrow down x ?
The coommand for findiing the next match is n not /.
Actually, it's /-enter (a blank search - it's an old habit
Il giorno 05/apr/04, alle 13:43, [EMAIL PROTECTED] ha scritto:
Log:
committed linotype 1.2. Note: it's not working properly but I don't
want to stop others from contributing.
Can you give us a brief overview of your changes and what's not working?
Ugo
[ ] exclude.block.blockname=true|false
[X] include.block.blockname=true|false
Ugo
Il giorno 01/apr/04, alle 21:16, Vadim Gritsenko ha scritto:
PS I'm -0.95 on excluding unstable blocks, and +0.74 for excluding
deprecated blocks.
I'm exactly -1/sqrt(2) on excluding unstable blocks and +1/e for
excluding deprecated blocks.
Now don't tell me I'm being irrational! ;-)))
Ugo
Il giorno 01/apr/04, alle 21:54, Marc Portier ha scritto:
I'm +1 on excluding deprecated as well as the unstable ones
some argumentation:
snip/
- more importantly I think trimming down cocoon will prepare our
userbase for what is to come with the real blocks. Obliging them
already today to
Gianugo Rabellino wrote:
I've seen in the new API that in a number of places there are contracts
that return null if something isn't found: since these are all perfect
candidates for nasty NPEs, how about switching to NullObject pattern or
throw Exceptions instead?
I think it all depends on
Stefano Mazzocchi wrote:
I'm all for a better authentication strategy but if this doesn't work
with our way of doing stuff, well, it's not going to help anybody.
I'm not going to repeat here all the arguments that Gianugo has put
forward in his reply, but just say that I agree 100% with what he
Il giorno 31/mar/04, alle 19:23, Stefano Mazzocchi ha scritto:
Ugo Cei wrote:
Atom and RSS are more or less isomorphic to the current markup, so
it's not really important to switch right now. I'll try to fix what's
broken with what we have and we'll decide later.
Wait, I have already done
Torsten Curdt wrote:
Well, actually my point is about user awareness. Today you just
download Cocoon, read the docs, type ./build.sh and see some
fast-scrolling messages muttering about unstable stuff, and that's it.
I'm thinking of something more specific that forces the user to know
what
Torsten Curdt wrote:
as already announce on the PMC list we now
have another flow implementation for java!
Great!
[ ] jflow
[X] javaflow
[ ]
[ ] nah... put it somewhere else
Ugo
Stephan Michels wrote:
[ ] Move it into scratchpad
[X] Leave it where it is
[ ] Rename it to ___
Ugo
Gianugo Rabellino wrote:
Ugo Cei wrote:
Atom (and I think also RSS 2.0) can be extended with elements from
other namespaces, indeed. And we could also ask for changes to the
Atom spec, since it's still in draft stage. Anyway, what do you
suggest that we use as an alternative?
I'm a bit
Torsten Curdt wrote:
Ugo Cei wrote:
1. remove the ad-hoc authentication system and use container-based
authentication;
Hm... you'd have to configure the container
for authentication :-/ don't know
Yes, I already did it. Now I just need to remove all the code dealing
with authentication from
Guido Casper wrote:
Concerning the repository ... I just committed another repository
interface :-) that tries to be a best effort in consolidating all the
different approaches and accommodating all concerns in a flexible way
(by having opional helpers for property management, versoning and
Torsten Curdt wrote:
In general I agree but it makes the deployment more
complicated because the authentication differs from
container to container.
The container-specific part of the configuration varies, but it's
usually not that complicated. And everyone who has ever deployed a J2EE
webapp
Stefano Mazzocchi wrote:
There is a configuration you have to modify in slide to make osx to work
well. it's a known macosx bug (even apple knows it) and slide has a
workaround, but you have to turn it on. search slide-dev for macosx or
webdavfs.
OK, so I set lockdiscoveryIncludesPrincipalURL
Guido Casper wrote:
If mod_dav (only supporting basic WebDAV) suits your functional needs it
certainly is your best bet.
Well, no, I don't know if mod_dav suits all my needs, I don't even know
what my needs will be, ATM ;-).
However since Slide has much more to offer and has matured a lot
Gianugo Rabellino wrote:
Yup, problem is that you can't generate a form definition this way,
since the woody.js call expects a pipeline (as in new
Form(something)), and doesn't accept a bizData object. Too bad.
I'm not sure I'm following you here. Can't you do form.showForm(uri,
bizData)? Or do
Stefano Mazzocchi wrote:
There is a configuration you have to modify in slide to make osx to work
well. it's a known macosx bug (even apple knows it) and slide has a
workaround, but you have to turn it on. search slide-dev for macosx or
webdavfs.
I did and could at least *mount* the WebDAV
Carsten Ziegeler wrote:
Our 2.2 release is not about using the best container available,
the release is about implementing blocks. This implementation
is container independent, so it shouldn't play a role what container
we use for blocks. In addition 2.2 is now independent of the
container
Unico Hommes wrote:
Johann Romefort wrote on 17-3-2004 12:04:
I m about to choose a WebDAV server in the next days, because of
strong needs in ACL / Versionning/ Locking
on document. So here is my question : what is the current status of
WebDAV in Cocoon? Also what is the status
of the Slide
Unico Hommes wrote:
I was thinking specifically regarding the choice between Cocoon and
Slide as a WebDAV server, but I think Slide is the better choice over
mod_dav/catacomb as well. Simply because it supports more WebDAV (DACL,
Binding) in a more flexible way. It has an interception mechanism
Reinhard Pötz wrote:
And instead of investing to much time in all those things we should make
CocoonBlocks become reality ASAP because they will solve those
dependencies very elgantly.
I'd say *most* of those dependencies, but not all of them. Flowscript is
part of the core, for instance.
Ugo
Joerg Heinicke wrote:
Ok, let me clarify. I think I do nothing unusual. Yes, I have a form
with a simple dynamic selection list. And I do the binding against a bean.
This is what I do all the time.
There are two known ways to set the selection list dynamically:
setSelectionList(String uri) and
Joerg Heinicke wrote:
Do you have a solution for the 'non-value' entry in the items collection? I use
the selection list as filter for the list pages. And I want to provide an option
to do no filtering by this selection list.
I usually do the following:
var collection =
Leszek Gawron wrote:
Is there possibility to get access to the getClass() method in flow ? I am
trying to do some tests with Hibernate and this method is not accessible and
while Hibernate makes a heavy use on reflection I have to wrap everything in
some faade (getUser( id ), getRole( id ) instead
Joerg Heinicke wrote:
Hello,
below you will find the mail I wanted to send first, but after having written it
I found the solution myself:
I thought about the correct event instead of on-value-changed, I came to on-bind
and in the binding docu I found wb:javascript and came to following code that
Joerg Heinicke wrote:
Thanks for your answer, Ugo, I only do not get your point.
My problem was about binding and I solved it with the above wb:javascript code
and it works for the moment. But I could imagine that I'm not the only one
binding selection lists to a collection, so maybe adding an
Reinhard Pötz wrote:
As you may saw I've reverted the removal of Woody. IMO just for now and
it should be removed ASAP. So let's vote on this:
variant B: remove Woody after 2.1.6 release
+1
Ugo
Antonio Gallardo wrote:
This mean another official forking of the Rhino engine. That also mean
users of BEA and IBM AS will have 2 flowscript engine there, right? The
current deployed with org.mozilla.* and our one org.cocoondev.*
This can be easily traduced in more memory usage, etc. Is this
Marco Rolappe wrote:
I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937
thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
I've been using EHCache in production with
Marc Portier wrote:
another +1 to 'cforms' over 'forms'
Doesn't the c stand for Cocoon? If it does, I find it somewhat
redundant, especially in a package name: org.apache.cocoon.forms ==
org.apache.cocoon.cocoon.forms?
And what if someday we develop a new forms framework, do we call it
dforms?
Martin Holz wrote:
does Sun regex offer any significant advantages over ORO or jakarta
regexp ? Just curious.
Probably just the fact that we'd ship one less JAR file.
Ugo
Alan wrote:
* Ugo Cei [EMAIL PROTECTED] [2004-03-03 08:15]:
Probably just the fact that we'd ship one less JAR file.
That was my point.
(Though a change would break sitemaps depending on ORO specific patterns,
if there is such a thing.)
At the cost of breaking some sitemaps, and since
Vadim Gritsenko wrote:
IIRC, ORO is not used by sitemap. Rather, CForms has direct dependecies
on ORO.
Might be worthwile checking if 1.4 regexps are good enough for the task.
PS I heard that 1.4.0 regexp was not good:
http://marc.theaimsgroup.com/?l=jakarta-regexp-userm=106588023307749w=2
Oh,
Steven Noels wrote:
On 03 Mar 2004, at 17:19, Vadim Gritsenko wrote:
See http://www.themorningnews.org/archives/how_to/the_nonexpert_lift.php
BOB REFRESHING HIS EMAIL INBOX
ROFL - subscribed.
/Steven
Subscribed? Where's the RSS feed?
Ugo
Well, I know this is silly, but why not?
http://www.manageability.org/polls/what-is-the-best-java-web-framework
Ugo
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using it
exclusively for quite a long time, I still think there are many
environments where people are forced
Unico Hommes wrote:
I think that as a software product that is known for its innovative
nature it is *very* important in the interest of Cocoon to refuse being
impaired by the immobility of bureaucracratic organisations. We are
having a small crisis on our hands ATM regarding our persistent
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Since we don't have a NIO-based implementation of the persistent
store, yet, why upgrade now? When we have it, I'll be more than
willing to vote +1.
Ugo,
this is chicken-egg problem: nobody is going to implement something on
1.4-only API
I know this is slightly offtopic, but since there have been talks on
this list and off-list about using Subversion both as a replacement for
CVS and as a WebDAV-enabled repository, here it is:
http://developers.slashdot.org/developers/04/02/22/2344228.shtml
Ugo
Sylvain Wallez wrote:
Yep: I guess you added init-param to the Cocoon *servlet* and not to
the *context* ;-)
Ah, I see. So how do you access a servlet parameter from flowscript or,
more generally, what would be the best way to access runtime
configuration parameters, without implementing a
Carsten Ziegeler wrote:
What about JCS?
http://jakarta.apache.org/turbine/jcs/index.html
Carsten
I know that Hibernate moved away from JCS because of some bugs, but I
cannot recall exactly what problems it had.
Another candidate might be OSCache [1].
Ugo
[1]:
Carsten Ziegeler wrote:
In the scratchpad is the portlet environment which allows Cocoon
to act as a JSR-168 producer.
The portal block contains the JSR-168 consumer implementation.
I propose to move the producer part from the scratchpad into
the block combining both and maintaining everything
I did some tests with Woody and I can confirm that everything behaves as
advertised. Local variables held by continuations become
garbage-collectable when the continuation returned by showForm is
invalidated and also when it expires.
(I still think I have a memory leak if I end the script with
Dear friends,
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store a
reference to local variables, and the memory leak does not manifest
itself if I don't create any continuation, I'm starting to suspect that
my
Christopher Oliver wrote:
Ugo Cei wrote:
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store a
reference to local variables, and the memory leak does not manifest
itself if I don't create any continuation, I'm
Christopher Oliver wrote:
Do you have global variables in your scripts?
Not at all.
Ugo
Christopher Oliver wrote:
Look at Optimizeit and see if there are any instances of
org.mozilla.javascript.cotinuations.Continuation or
org.apache.cocoon.components.flow.WebContinuation still around after this.
OK. This leaks a java.awt.Rectangle (plus a WebContinuation and a
Continuation) each
Andreas Hochsteger wrote:
how can I use a string which can be edited by the HTMLArea widget in an
XML binding?
I'm afraid you'll have to do parsing/serialization by hand in your code.
An HTMLArea is just a textarea with some DHTML and there is no support
in CForms, AFAIK, for binding an XML
Stefano Mazzocchi wrote:
Yeah, well, that doesn't help me because I have the namespace
declarations already there in the document I want to process and it
appears that xsl:copy copies over the namespace declarations everytime
and it's not influenced by exclude-result-prefixes.
!--
-
Antonio Gallardo wrote:
Hi:
The new HTMLArea looks great, a nice new feature for Woody! I have a
problem: All the dialogs (choose color, etc.) are open behind the main
browser window while using HTMLArea.
I am using Mozilla 1.4 on Linux Fedora Core 1.
Best Regards,
Antonio Gallardo.
There is a
Carsten Ziegeler wrote:
WDYAT?
+1
Ugo
Leszek Gawron wrote:
Hello,
Is there a way to test the cocoon component without the need to do HTTP
requests?
Of course. Look into src/test and specifically
o.a.c.SitemapComponentTestCase.
Ugo
Scott Simpson wrote:
Thanks, I'll give it a try with JDK 1.4.2_03 Standard Edition now. Are you using Enterprise Edition or Standard?
Standard.
Ugo
Scott Simpson wrote:
Thanks! It works now. It looks like their might be a dependency on JDK 1.4 now. From my test today, it seems as if it happened
early December, but I'm not certain.
I checked out the latest CVS HEAD and did a fresh build with JDK 1.4 2_03 Standard
Edition and woody now
Vadim Gritsenko wrote:
Better yet, let's start VOTE thread. Please cast your vote on following:
1) Remove woody.js
[+1]
2) Remove JSCocoon, JSWebContinuation, JSLog, JavaScriptInterpreter,
JavaScriptFlow, JSGlobal, system.js
[-0]
3) Move JSCocoon, JSWebContinuation, JSLog,
Scott Simpson wrote:
Can anyone tell me what the latest cocoon dev release is that has a working woody block? I've had trouble with the nightly
distributions for the past several days.
I did a CVS update this morning (CET+1), updated a couple of
applications we're currently developing with the
Scott Simpson wrote:
Do you know if there are any new external library dependencies? Maybe there is
something in your (and other's) java library
directory that I don't have. I simply have JDK1.3.1 Standard Edition (and whatever
libraries come with it)
Could you try it with JDK 1.4? Maybe a
Christopher Oliver wrote:
The problem is that x is a JavaScript wrapper of a HashSet. Jexl's
special size() function only support collections and arrays. Perhaps
that can be fixed by unwrapping NativeJavaObject's before adding them to
the Jexl context.
If this solves the problem, I'm +1 for it.
Stefano Mazzocchi wrote:
I'm joining the MIT Libraries faculty for a two years research position
working full time on the SIMILE project (http://web.mit.edu/simile/)
which goal is to show that semantic web technology works (or doesn't!)
in the real of metadata interoperability, with a focus on
Vadim Gritsenko wrote:
Ok, here is simple one. Forms wizard for editing any XML/bean containing
repeating information, with back/forward navigation, and navigation bar
to jump to any previous page. For a concrete example of the usecase,
let's look at editing family information, and information
Vadim Gritsenko wrote:
Found couple of issues with jxpath template generator:
* #{0 != ''} evaluates to false
* #{0 gt; 1} is not evaluated, as well as #{0 lt; 1}
There's another issue I have just discovered:
var x = new java.util.HashSet();
cocoon.sendPage(view, { x : x });
...
${x.size()}
[EMAIL PROTECTED] wrote:
upayavira2004/01/13 00:44:05
Modified:src/blocks/xmldb/java/org/apache/cocoon/components/source/impl
XMLDBSource.java
Log:
Making XMLDBSource modifiable. Should be useful with Woody binding infrastructure,
and can use
It looks like we might have a problem. I copied the loadDocument
function from woody's binding_example.js and passed it an xmldb: URI.
This is the exception I get when I call
var is = new Packages.org.xml.sax.InputSource(source.getInputStream());
org.apache.cocoon.CascadingIOException: Could
Guido Casper wrote:
I have no idea what the reason might be but maybe you want to try:
org.apache.cocoon.components.source.SourceUtil.toDOM(source);
I already found a workaround:
var domBuilder = new Packages.org.apache.cocoon.xml.dom.DOMBuilder();
source.toSAX(domBuilder);
return
Guido Casper wrote:
SourceUtil.toDOM() uses the same code, but calls source.toSAX() only if
it exists (i.e. the source implements XMLizable). If not, SourceUtil
falls back to using the XMLizer (which in turn calls
source.getInputStream again). So SourceUtil works with any kind of
source while your
Antonio Gallardo wrote:
Is woody fast enough to manage the 160 fields in a form? I will be glad to
hear about that. Sometimes I feel Woody is a little bit slow.
I haven't done any measurements, but with 160 fields it's surely the
client that slows down. Rendering that form with Mozilla sends the
[EMAIL PROTECTED] wrote:
have you ever thought about a combination of woody and the portal-engine ?
No, never. I've never even used the portal engine.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E
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, mate!
haven't looked deeply into this.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
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
Sylvain Wallez wrote:
I don't agree with you here: you cannot seriously convince people to use
Woody if it doesn't provide the minimal fancy features that every
other form framework provides. You won't convince anybody with flat
inputs. We need tooltips, help popups, calendars, etc. But I also
ANT_OPTS
Probably the latter is not enough, sincerely I don't know.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
Upayavira wrote:
Still a hassle to switch to another window, shut it down, wait.,
restart, then connect your debugger to the waiting instance, then
request a page from Cocoon and wait...:-(
Then you don't have a fast enough machine ;-), And if you wrote more
tests, you wouldn't need a
[EMAIL PROTECTED] wrote:
Update jetty to 4.2.14
Did you test this with Java 1.3? If I'm not mistaken, the current binary
version of Jetty works with Java 1.4 only.
Ugo
Antonio Gallardo wrote:
I got it from Forrest CVS. I think forrest needs to work with 1.3 too:
http://xml.apache.org/forrest/primer.html#System+requirements
If this does not work, my appologies and I will revert the changes.
I cannot test it now, I only have 1.4 on this machine, but I remember
this harms Cocoon more than it helps. So please come up with
usecases which make it really necessary to go this way!
Amen brother ;-).
... but maybe I'm the only one with these thoughts ...
We are at least two.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del
Tim Olson wrote:
map:match pattern=view
map:generate src=cocoon://generate/
map:transform src=homePage.xsl/
map:serialize/
/map:match
i thought the original intention was to make the flow clearer? now we have
three blocks of code to follow instead of one...
Well, almost, you can reuse
. (As the
Woody Samples do with OtherMessages).
By the way, would it be possible to read the default catalog from a
resource (i.e. from cocoon-woody-block.jar) instead of copying them from
the samples?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2
David Crossley wrote:
Looks interesting and worth a try. Now we need one for xml too.
jEdit with the XSL-T plugin.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
Sylvain Wallez wrote:
Do you want to enforce the fact that flowscript calls (either function
or continuation) *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a ProcessingException be
raised?
[ ] no, let the sitemap execution continue after
Sylvain Wallez wrote:
A solution is to keep the uploaded content in a temp area until the form
is valid. But what if the user leaves and never re-submits the form?
Should we rely on the garbage collector to finalize() the upload widget
to clean the temp area?
How about catching the expiration
Hugo Burm wrote:
1) I have my own little Avalon component defined in cocoon.xconf. It is a
factory component that should generate Hibernate sessions. When Cocoon is
started by Tomcat, my component starts Hibernate. Hibernate tries to read
its configuration files. These files are XML files.
Upayavira wrote:
Can someone recommend a decent Windows IRC client? I'd at least like to
watch what's going on, even if I can't participate much.
Upayavira
Try XChat http://xchat.org/.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia
Carsten Ziegeler wrote:
Tomorrows is our first FirstFriday
(http://wiki.cocoondev.org/Wiki.jsp?page=FirstFriday)
Did we agree on a whiteboarding system, at last?
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone
be impossible or problematic when dealing with existing
classes. However, I haven't really thought about the implementation, yet.
WDYT?
Ugo
[1]:
http://developer.java.sun.com/developer/Books/shiftintojava/page1.html#replaceenums
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le
Ugo Cei wrote:
I'd like to add an enum basetype and enum convertor to Woody. Those
would work with types implementing Joshua Bloch's typesafe enum
pattern [1].
OK, since I had a little time on my hands, I went ahead and committed a
first implementation. Basically, it works, but relies
Jeremy Quinn wrote:
They both work for me too, so does :
catch (return) {
// the page has finished rendering
}
Would anybody mind summarizing the various uses of catch on the Wiki?
I have a feeling that sooner or later I'm going to use this stuff.
TIA,
Ugo
Marc Portier wrote:
don't fully understand what you are saying here, but if you have
investigated more and have more detail to present the issue I'll do a
best effort to get into it
(next week I'll have limited online time though, so be patient)
No, I haven't investigated it fully. I will
[I'm crossposting to dev, since this might stimulate some comments from
the Flowscript gurus over there.]
Oleg Dulin wrote:
Dear Fellow Cocoon Users:
I just read the forwarded message on xml-dev mailing list and realized
that Groovy makes a perfect language for business logic intermixed with
Antonio Gallardo wrote:
Hunsberger, Peter dijo:
For us, last update wins, we're not update intensive, but I'm waiting
for the day when someone forces us to wade through the audit log to
determine why there update didn't take.
The last update wins is the most used approaching in this cases. You can
501 - 600 of 663 matches
Mail list logo
