Sylvain Wallez wrote:
>
> I'm more and more thinking we should standardize the use of
> "cocoon:*"
> request parameters for "cocoon:" urls. We already talked
> about "cocoon:handle-errors=true|false", and here comes
> "cocoon:attribute-scope=local|global".
>
> This is a simple (and IMO eleg
Sylvain Wallez wrote:
> >>
> >>
> >Yes, something like that. I would like to have some dynamics
> in the listener concept, so I can add at run time a listener.
> This would solve the problem as well.
> >
> >
>
> What do you mean by "dynamics"? Isn't it dynamic enough if
> any component in
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned
up or not. This could be done by either testing for the
Hunsberger, Peter wrote:
Colin Paul Adams <[EMAIL PROTECTED]> writes:
flow listener discussion,/snip>
I've just read this thread, because I have been trying to
work out how to implement pessimistic locking within cocoon.
A problem is how to close a database transaction if the user
simply walk
Colin Paul Adams <[EMAIL PROTECTED]> asks:
>
> > "Peter" == Hunsberger, Peter
> <[EMAIL PROTECTED]> writes:
>
> Peter> I believe you should be able define the timeout at the DB
> Peter> (JDBC/ODBC?) connection pool level when you define the
> Peter> connection for the applicatio
Colin Paul Adams <[EMAIL PROTECTED]> writes:
> > "Peter" == Hunsberger, Peter
> <[EMAIL PROTECTED]> writes:
>
>
> Peter> If all you've got is statement timeout a wrapper around the
> Peter> execute/executeQuery should work?
>
> I don't see how it can possibly work.
> The scenario:
> "Peter" == Hunsberger, Peter <[EMAIL PROTECTED]> writes:
Peter> I believe you should be able define the timeout at the DB
Peter> (JDBC/ODBC?) connection pool level when you define the
Peter> connection for the application, not?
I don't know. Where would this be done? Within coc
> "Peter" == Hunsberger, Peter <[EMAIL PROTECTED]> writes:
Peter> If all you've got is statement timeout a wrapper around the
Peter> execute/executeQuery should work?
I don't see how it can possibly work.
The scenario:
Read data, starting a transaction and bind to a CForms.
Wait for
Colin Paul Adams <[EMAIL PROTECTED]> writes:
> In fact, checking the documentation for postgresql, it
> doesn't have transaction timeout, only statement timeout,
> which certainly isn't adequate.
I've never had to worry about it at the DB level, we use JBoss and
manage it at the container level
> "Colin" == Colin Paul Adams <[EMAIL PROTECTED]> writes:
Peter> Maybe I'm missing something, but why aren't you setting
Peter> your database transaction timeout limit to something just a
Peter> bit larger than the session timeout?
Colin> Well, I guess this is fine for a datab
Colin Paul Adams <[EMAIL PROTECTED]> writes:
>
> > "Peter" == Hunsberger, Peter
> <[EMAIL PROTECTED]> writes:
>
> Peter> Colin Paul Adams <[EMAIL PROTECTED]> writes:
> Peter> flow listener discussion,/snip>
> >> I've just read this thread, because I have been trying to work
>
> "Peter" == Hunsberger, Peter <[EMAIL PROTECTED]> writes:
Peter> Colin Paul Adams <[EMAIL PROTECTED]> writes:
Peter> flow listener discussion,/snip>
>> I've just read this thread, because I have been trying to work
>> out how to implement pessimistic locking within cocoon. A
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable, Re
Colin Paul Adams <[EMAIL PROTECTED]> writes:
flow listener discussion,/snip>
>
> I've just read this thread, because I have been trying to
> work out how to implement pessimistic locking within cocoon.
> A problem is how to close a database transaction if the user
> simply walks away from the
> "Sylvain" == Sylvain Wallez <[EMAIL PROTECTED]> writes:
>> I think those listeners are not only for flowscript, but more
>> generic approach. Btw, sendPageAndWait also has a provision for
>> clean up function. Problem is it does not work each time [1].
Sylvain> Yep. We coul
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned
up or not. This could be done by either testing for the usual
suspects from
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable, Re
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable, Recyclable) or by defi
Unico Hommes wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used "prefix" everywhere else.
Ok, I like your suggestion more.
What about adding a l
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used "prefix" everywhere else.
Ok, I like your suggestion more.
Cool.
I was recently looking at flowscript
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used "prefix" everywhere else.
Ok, I like your suggestion more.
What about adding a list of ProcessingL
Sylvain Wallez wrote:
>
> Big +1 , but what about naming it getSitemapPath() to mimic
> HttpServletRequest.getServletPath()?
>
Hm, sounds better to me, but we have used "prefix" everywhere else.
Ok, I like your suggestion more.
> >Attributes
> >--
> >
> >We have a similar problem with
Carsten Ziegeler wrote:
Our request object is modelled after the request object of
the servlet spec. Now this approach is not bad, but Cocoon
has something which the servlet spec does not have: internal
requests. Unfortunately, our api does not take this into
account.
URIs
The request has curr
Our request object is modelled after the request object of
the servlet spec. Now this approach is not bad, but Cocoon
has something which the servlet spec does not have: internal
requests. Unfortunately, our api does not take this into
account.
URIs
The request has currently two methods for t
25 matches
Mail list logo
