RE: eclipse classpath
Joerg Heinicke wrote:
You start your servlet container from inside Eclipse? I start it from
command line and only attach for remote debugging.
Yes, sure; it's the fastest approach for me. You actually don't need
the command line anymore (except for building the webapp the first
time).
I have set the eclipse output to WEB-INF/classes, so that changes aren't
lost after servlet container restart. So I only need to restore the
patched roles file. What about
!-- Prepares the webapp to make it directly usable with the eclipse
project --
target name=eclipse-webapp-prepare depends=prepare,
eclipse-webapp-delete-jars, eclipse-webapp-restore-roles
description=Prepares the webapp directory to make it usable
within Eclipse/
target name=eclipse-webapp-restore-roles
copy file=${build.dest}/org/apache/cocoon/cocoon.roles
tofile=${build.webapp}/WEB-INF/classes/org/apache/cocoon/cocoon.roles
overwrite=yes/
/target
target name=eclipse-webapp-delete-jars
!-- delete all jars, they are already included in the project --
delete
fileset dir=${build.webapp}/WEB-INF/lib includes=*.jar/
/delete
/target
Yes, ok, works for me.
Carsten
RE: [Vote] Controller/Sitemap integration
From: Joerg Heinicke
Because of this upcomming naming discussion I guess the vote
started to
early.
Unfortunatly you are right. After the balkanization discussion I
thought that the people here are satisfied with Marc's/Sylvain's
proposal. In the meantime I'm really tired of waiting for the 2.1
release (yes, I want to use it in production -- I don't have problems
with CVS versions but many customers have!) ... therefore my try with
the vote ...
This was also the reason why I voted +0. Those changes would have been
possible for a later release and the migration would have been very
easy.
First all alternatives should be known. But the
additions Stephan
provided make sense (see inline).
Stephan Michels wrote:
[A] The Cocoon Advanced Control Flow provides a
controller that is
linked into the sitemap (as **child element** of map:sitemap
.../:
map:flow type=[yourEngine]
[configuration]
/map:flow
This reflects that the flow is not a *usual* sitemap
resource but
something else.
The point, which irritates me, is that you don't have a
identifier to
address the script/whatever.
So my favorite choise will be
map:flows
map:flow name=js type=javascript
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
/map:flows
So this will be coherent with the other objects.
Which leads the sentence This reflects that the flow is not
a *usual*
sitemap resource but something else. ad absurdum :)
I'm -0 on this changes to my proposal (see Jörg's argument)
[B] The controller is called by:
map:call flow=[yourFlow]
map:parameter name=x value=y/
/map:call
Seems fine, an alternative will be
map:initiate flow=js call=[Javascript function]
map:parameter
name=x value=y/ /map:initiate
map:initiate type=java call=[Java method] map:parameter
name=x value=y/ /map:call
map:initiate type=fsm call=[Name of state] map:parameter
name=x value=y/ /map:initiate
I like the combination of initiate/continue
initiate/continue is ok, but what about keeping syntax of all sitemap
objects using @type and @src:
map:initiate type=java src=[Java method]/
Or is it to far away from the sense or even misleading?
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Same like above, so I prefer @src.
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
flow-engine default=[yourController] logger=[yourLogger]
...
/flow-engine
+1, except the name, see next.
[E] Changes in the current Javascript implementation:
- rename Interpreter to FlowEngine,
Again, to be coherent my favorite is
flow-processor like xslt-processor and xpath-processor, or
treeprocessor.
flow-engine vs. flow-processor - I don't know ...
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Here I prefer the States for the reasons Marc provided, so +1 here.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is
accurate. But
'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
If not states, but continuations at least remove 'Web' = +1
Conal Tuohy wrote:
What about map:continue from=.../
Hmm, I don't really like it. We don't need an English sentence :)
Otherwise you could also change to map:generate from=foo.xml/,
map:transform with=bar.xsl/ and map:serialize as=html/. @type
and @src is a good abstraction IMO.
Joerg
Re: [Vote] Controller/Sitemap integration
On Thu, 17 Jul 2003, Joerg Heinicke wrote:
Stephan Michels wrote:
map:flows
map:flow name=js type=javascript
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
/map:flows
So this will be coherent with the other objects.
Which leads the sentence This reflects that the flow is not a *usual*
sitemap resource but something else. ad absurdum :)
Okay, but how should a different implemenation look like?
[B] The controller is called by:
map:call flow=[yourFlow]
map:parameter name=x value=y/
/map:call
Seems fine, an alternative will be
map:initiate flow=js call=[Javascript function]
map:parameter name=x value=y/
/map:initiate
map:initiate type=java call=[Java method]
map:parameter name=x value=y/
/map:call
map:initiate type=fsm call=[Name of state]
map:parameter name=x value=y/
/map:initiate
I like the combination of initiate/continue
initiate/continue is ok, but what about keeping syntax of all sitemap
objects using @type and @src:
map:initiate type=java src=[Java method]/
Or is it to far away from the sense or even misleading?
+1
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Same like above, so I prefer @src.
+1
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Here I prefer the States for the reasons Marc provided, so +1 here.
+0
Conal Tuohy wrote:
What about map:continue from=.../
Hmm, I don't really like it. We don't need an English sentence :)
Otherwise you could also change to map:generate from=foo.xml/,
map:transform with=bar.xsl/ and map:serialize as=html/. @type
and @src is a good abstraction IMO.
I think in the same direction, @src and @type are more intuitive.
Stephan.
Re: [RT] Less is More, Finite State Machines and Balkanization
Christopher Oliver wrote:
Sylvain,
I can see from your response that this discussion has become
adversarial , and I regret that. I remember, after Ovidiu, you were
the first person to welcome me to Cocoon, and you have always seemed
to have a good and positive attitude.
You're right on both points. I've been present on Cocoon lists for a bit
less than three years, and the number of times I came to this kind of
speech can be counted on less than the fingers of a single hand. And I
also welcomed you because I was (and am still) very supportive to
Ovidiu's ideas and work, and helped him integrate the flow layer in the
sitemap.
I don't like the tone of our recent messages, and I'd like to change
it. Is that possible? My objections to the proposal you and Marc made
were simply based on the fact that I feel like Cocoon is (finally) on
the verge of realizing the vision Ovidiu introduced to it two years ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=100715975517943w=2
That vision was indeed based on continuations and programming
languages as (later) reflected in the names of the sitemap elements.
Maybe it's a small point but to me it seemed unnecessary to change
that right now.
This may be subjective, but for me, the vision remains regardless of
what programming language is used to depict the page flow. In
Christian Queinnec's original work it was Scheme, now, in Cocoon, it's
JavaScript. If we were to implement Brakes-based Java continuations it
could be Java or Jython, etc.
However, I felt something was lost from that vision, for me anyway,
with the proposed abstraction. That is why I objected to it.
Nevertheless, as you point out, other visions of page flow are
possible, and I certainly don't want to discourage anyone from
pursuing them.
As I stated, I've been very supportive to the ideas and philosophy
behind the flow, and quickly grasped what continuations brought to the
picture (refer to my numerous posts answering questions about it). BTW,
I learned Lisp when I was 16 or 17 with a book written by the same
Christian Queinnec that proposed to use continuations for webapps flow.
Now we've come to a time where the flow is no more purely internal to
Cocoon, and has to be explained, teached and more generally advocated to
the vast world of people that are not Cocoon developpers nor hard-core
programmers. And this is where I realized that many people are not yet
ready for that and don't want to abandon what they use everyday, even if
these are ugly goto's.
Because of that, Cocoon must be able to host page flow technologies
other than continuations, perhaps until continuations become mainstream
and widely used. Once again, continuation-based flow must be the
officially endorsed implementation, but we must allow other
implementations, even if we don't officially promote their usage. And if
code location is important for that, these alternate implementations can
be hosted elsewhere.
I'm happy also to see you're not firmly attached to JS. Although a
scripting languages take more and more importance, many people also are
reluctant to using something else than Java server-side. And this is why
I firmly believe in a pure Java solution as Brakes can help us to build.
This is what led me to consider that JS+continuations, although
mind-blowingly powerful, could not be imposed to all because it _is_
mind-blowingly powerful and not everybody is able to understand nor
master its power yet. Minds will have to evolve for that.
Now I'd like to apologize if I misinterpreted your posts. I don't like
personal frictions, as they're often based on some initial
misunderstanding that keeps unresolved. I love this community which I
consider as my home (but not my property) and don't want long-term bad
feelings that can only do harm.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] the value of being wrong
Stefano Mazzocchi wrote:
I have taken a step back and reconsidered the whole discussion about
flow and how to implement it.
snip/
Stefano,
I will not answer in detail to this RT (computer time is scarce during
holidays), but let me say that I'm happy to see your balkanization
paranoia going down. As you say, this community has something special,
and I think it has already proven several times its health. The recent
XMLForm story is a good example of that : a block gets damaged because
its main (if not only) contributor decides to leave. And we see better
reimplementations emerge (JXForm, thanks to Chris). I'm confident that
for the particular problem of flow abstractions, the community and
Darwin will do their job as usual. And if not, the few people involved
in today's discussions will take care of it ;-)
snip/
4) if the line of fair discussion is crossed, people have a chance to
learn, understand and apologize. This gives a human touch that goes
past work collaboration and creates deeper relationships, that
normally reflects in real life (read: friendship. I'm writing this
from a friend's house met thru cocoon residing on the other side of
the world from my hometown. And other people are mixing vacation time
with real-life meeting with cocoon people right as we speak. I think
this is another thing that makes this community special)
To all : I am the other people. I visited Bertrand on tuesday, and
this was not only a meeting between Cocoon people, since both families
were involved [1]. This was really great.
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/61.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [Vote] Controller/Sitemap integration
As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration After the discussion and all your opinions I would prefer: Integrating the flow processor/engine: -- map:flows map:flow name=js type=javascript script src=flow/PetStoreImpl.js/ script src=flow/petstore.js/ /map:flow map:flow name=java type=atct class src=org.apache.cocoon/ /map:flow map:flow name=fsm type=fsm blabla src=descriptors/fsm.xml/ /map:flow /map:flows ... in order to be coherent. Please note that the flow element only has name and type. All other things are IMO part of the configuration (... someone proposed to have a class attribute -- that's useless for e.g. the JavaScript implementation) Call a flow the first time: --- map:call flow=[yourFlow] type=js map:parameter name=x value=y/ /map:call I prefer call because this makes the most sense for me. But I'm +0.5 with initialize. And I like the word flow otherwise it is totally obscured that it is part of the flow implementation. Please note again that we need a type attribute again. ... and I don't like src because src means something different everywhere in Cocoon (something that can be called using the SoureResolver ...) Continue a flow: map:continue id=... type=js map:parameter name=x value=y/ /map:continue Again, I don't like src (see reasons above) and we need the type attribute. Component declaration: -- I'm indifferent on this ... And here a completly new alternatvie (at least for this discussion:) map:flow call= type=js map:parameter name=x value=y/ /map:flow and map:flow continue= type=java map:parameter name=x value=y/ /map:flow This makes for me the greatest sense because you still know that you deal with flow and this is not obscured by call, continue, initialize or whatever. Perhaps, this would make a renaming of the declaration in map:flows.../map:flows necessary. What do you think? Cheers, Reinhard
cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSourceFactory.java
gianugo 2003/07/17 05:24:53
Modified:.status.xml
src/blocks/webdav/java/org/apache/cocoon/components/source/impl
WebDAVSourceFactory.java
Log:
Added URL encoding of user/password in the WebDAV source
(webdav://user:[EMAIL PROTECTED]/path)
Revision ChangesPath
1.92 +5 -1 cocoon-2.1/status.xml
Index: status.xml
===
RCS file: /home/cvs/cocoon-2.1/status.xml,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- status.xml13 Jul 2003 17:16:54 - 1.91
+++ status.xml17 Jul 2003 12:24:52 - 1.92
@@ -184,6 +184,10 @@
changes
release version=@version@ date=@date@
+ action dev=GR type=update
+Added URL encoding of user/password in the WebDAV source
+(webdav://user:[EMAIL PROTECTED]/path)
+ /action
action dev=VG type=update
Decouple core XSP logicsheet from database classes to allow XSP deployment
without excalibur datasource JAR file. If your XSP pages use datasources
1.3 +15 -26
cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl/WebDAVSourceFactory.java
Index: WebDAVSourceFactory.java
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl/WebDAVSourceFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- WebDAVSourceFactory.java 13 Jul 2003 01:25:43 - 1.2
+++ WebDAVSourceFactory.java 17 Jul 2003 12:24:52 - 1.3
@@ -58,6 +58,7 @@
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.thread.ThreadSafe;
+import org.apache.commons.httpclient.HttpURL;
import org.apache.excalibur.source.Source;
import org.apache.excalibur.source.SourceException;
import org.apache.excalibur.source.SourceFactory;
@@ -98,33 +99,21 @@
}
final String protocol = location.substring(0, location.indexOf(':'));
-int position = location.indexOf(://);
-if (position = 0)
-position += 3;
-else
-position = 0;
-
-// create the queryString (if available)
-String queryString = null;
-SourceParameters locationParameters = null;
-int queryStringPos = location.indexOf('?');
-if (queryStringPos != -1) {
-queryString = location.substring(queryStringPos + 1);
-location = location.substring(position, queryStringPos);
-locationParameters = new SourceParameters(queryString);
-
-} else if (position 0) {
-location = location.substring(position);
-locationParameters = new SourceParameters();
-}
-String repository = locationParameters.getParameter(repository, null);
-String namespace = locationParameters.getParameter(namespace, null);
-String principal = locationParameters.getParameter(principal, null);
-String password = locationParameters.getParameter(password, null);
-String revision = locationParameters.getParameter(revision, null);
+ HttpURL url = new HttpURL(http://; +
location.substring(location.indexOf(':')+3));
+ String principal = url.getUser();
+ String password = url.getPassword();
+ location = url.getHost() + : + url.getPort();
+ if(url.getPathQuery() != null) location += url.getPathQuery();
+
+if(principal == null || password == null) {
+ String queryString = url.getQuery();
+ SourceParameters locationParameters = new
SourceParameters(queryString);
+ principal = locationParameters.getParameter(principal,
principal);
+ password = locationParameters.getParameter(password,
password);
+}
-WebDAVSource source =
+WebDAVSource source =
WebDAVSource.newWebDAVSource(location, principal, password, protocol);
return source;
Re: [Vote] Controller/Sitemap integration
Stephan Michels wrote:
...
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
...
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on this naming
using continuation. I thought I was hearing in Sylvain's original RT
that continuations may not be the only implementation. I don't have a
problem with any of the new names suggested which is why I'm not really
adding anything to the discussion at this point, but I don't want to
have the discussion miss this point.
Could someone who resonates with the vision for these other potential
(non javascript-with-continuations) implementations of flow comment on
this quickly? If it satisfies you, I have no personal objection.
Geoff
Re: [RT] Adaptive Caching
Stefano Mazzocchi wrote: The functions as defined by your initial algorithm used the sum notation, which means we needed to maintain a list of samples for the resource. I.e. the cost functions identified were a function of the resource and time of request. The more samples maintained, the less efficient the cache evaluation became. yes, I see your point. I think it's entirely possible to use a windowed version of the sum without degrading much the results (but this is, again, a wild guess, this should have to be tested). that means, just sum the last n terms, not more. Which comes to the conclusion I came up with last night. In the wonderful world of audio, average loudness is measured by a meter that reports the RMS of a particular period. RMS (Root Mean Square) is used because dB is a logarithmic function of sound intensity--it matches the problem space better. The set of samples used depends on how quickly we want the meter to adjust to the signal. For example, a 100ms window will always evaluate the last 4,410 samples with CD quality audio. This seems to provide a nice balance for seeing the immediate intensity of the audio, and still not being thrown off by the peaks. However when you are level matching, you want your meters to adjust more slowly, so extending the window to 3s provides a much slower changing average which allows you to more accurately match the levels. Taking this further, it is important to know the peaks so that we can make sure that we are not overloading the system, so modern professional digital meters have a peak hold function as well as an overload indicator. It is important to note that the overload detection can be adjusted. For example, one sample reaching maximum amplitude does not necessarily indicate an overload. Even two samples are not an authoritative measure. Three or more samples at maximum amplitude are a certain metric that we are overloading our A/D converters. You will never hear the clipping of three samples, but audio engineers interested in the best quality music they can produce will set the overload indicator function so that they know when they absolutely have to do a retake. Considering that overloading is important, the raw measure of the amplitude (i.e. peak metering) is far less useful. Trying to match the audio intensity using peak meters will give you a false sense of the match. You might be able to get the peaks to match, but your ears will tell you that one is still louder than the other. The concept translates over to the adaptive cache approach at almost 1:1. The actual individual cost sample is not important. It is the windowed average that is important. For our cache a simple mean would best suit our problem space. The size of the window for our samples will control how responsive our cache control algorithm is. This would affect your cache prediction algorithm as the value k is no longer needed to control responsiveness. The value k can be set at 0, 1, or 0.5 depending on how you want to affect the slope. IMO, the window size should be the determining factor at how the average cost for a resource will converge toward the optimal point. Large window sizes provide slower response, while a smaller window provides faster response. I'm thinking about implementing the cache separately from cocoon to see if the math behind it works or not. If you have code to share, that would be wonderful (you can place it in the scratchpad if you want) Ok. Let me package this later today. I have a meeting for the next 3 hours. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [Vote] Controller/Sitemap integration
On Thu, 17 Jul 2003, Geoff Howard wrote:
Stephan Michels wrote:
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on this naming
using continuation. I thought I was hearing in Sylvain's original RT
that continuations may not be the only implementation. I don't have a
problem with any of the new names suggested which is why I'm not really
adding anything to the discussion at this point, but I don't want to
have the discussion miss this point.
Could someone who resonates with the vision for these other potential
(non javascript-with-continuations) implementations of flow comment on
this quickly? If it satisfies you, I have no personal objection.
A little example:
function myFunc()
{
x = bla;
sendPageAndWait(first)
if (answer = sucess)
y = blub;
sendPageAndWait(choice)
else
y = yagh;
sendPageAndWait(choice)
sendPageAndWait(last)
}
Here you have four different states:
state 0:
x = bla;
sendPage(first)
state 1:
y = blub;
sendPage(choice)
state 2:
y = yagh;
sendPage(choice)
state 3:
sendPage(last)
And several transitions:
state 0 - state 1 if answer = sucess
state 0 - state 2 otherwise
state 1 - state 3
state 2 - state 3
So, here we have a DFA.
The 'continuation' means to freeze the current state of the execution.
The benefit of the continuations are that you have a history
of the states, which you had traversed. And like a backtracking
algorithm, you can go back to a previous state and follow another
route.
So, the answer is, it is sufficient to have the 'history of states'
to take a new name like 'continuation' instead of simple 'state'?
I think yes.
Stephan.
DO NOT REPLY [Bug 21671] - [woody] initial binding framework
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=21671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21671 [woody] initial binding framework --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 13:42 --- Created an attachment (id=7347) update of previous patch (previous one missed out the ...woody.binding.*.java classes and had the relative paths wrong)
DO NOT REPLY [Bug 20308] - Stylesheet includes not working with XSLTC
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=20308. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308 Stylesheet includes not working with XSLTC --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 13:48 --- Yes, but I'm using xsl:include in my transformations. In fact, I don't know what is the connection with simpleform and I don't care anymore 'cos I'm using XForms now, but I can still see the connection between cinclude and xsl:include cos it doesn't work when xsl transforamtion is before cinclude transformation. I don't exactly remember what was wrong with simpleform. It was something with error tag which was corrected in M1.
RE: [Vote] Controller/Sitemap integration
From: Stephan Michels
On Thu, 17 Jul 2003, Geoff Howard wrote:
Stephan Michels wrote:
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is
accurate. But
'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on
this naming
using continuation. I thought I was hearing in Sylvain's
original
RT that continuations may not be the only implementation. I don't
have a problem with any of the new names suggested which is why I'm
not really adding anything to the discussion at this point, but I
don't want to have the discussion miss this point.
Could someone who resonates with the vision for these other
potential
(non javascript-with-continuations) implementations of flow
comment on
this quickly? If it satisfies you, I have no personal objection.
A little example:
function myFunc()
{
x = bla;
sendPageAndWait(first)
if (answer = sucess)
y = blub;
sendPageAndWait(choice)
else
y = yagh;
sendPageAndWait(choice)
sendPageAndWait(last)
}
Here you have four different states:
state 0:
x = bla;
sendPage(first)
state 1:
y = blub;
sendPage(choice)
state 2:
y = yagh;
sendPage(choice)
state 3:
sendPage(last)
And several transitions:
state 0 - state 1 if answer = sucess
state 0 - state 2 otherwise
state 1 - state 3
state 2 - state 3
So, here we have a DFA.
The 'continuation' means to freeze the current state of the
execution. The benefit of the continuations are that you have
a history of the states, which you had traversed. And like a
backtracking algorithm, you can go back to a previous state
and follow another route.
So, the answer is, it is sufficient to have the 'history of
states' to take a new name like 'continuation' instead of
simple 'state'? I think yes.
Sorry, I don't think so. I'm not a specialist in Scheme but I think
there is a concept behind continuations and the general use for all
controllers in Cocoon would be misleading.
Reinhard
RE: [Vote] Controller/Sitemap integration
IMHO: I think the verb 'continue' catches a broader consensus: interactions or use cases are indeed just started(initiated) or continued, and this also captures the relation the sitemap has to this. The noun 'continuation' has gotten a ring of being tied to a interpreted-language implementation. The inflected confusion from the history of the 'noun' adds up to some case against using it IMHO. +1 Reinhard
RE: [Vote] Controller/Sitemap integration
So, here we have a DFA. The 'continuation' means to freeze the current state of the execution. The benefit of the continuations are that you have a history of the states, which you had traversed. And like a backtracking algorithm, you can go back to a previous state and follow another route. So, the answer is, it is sufficient to have the 'history of states' to take a new name like 'continuation' instead of simple 'state'? I think yes. Sorry, I don't think so. I'm not a specialist in Scheme but I think there is a concept behind continuations and the general use for all controllers in Cocoon would be misleading. Okay, to be sure I googled around, and found: http://www.cs.utexas.edu/users/wilson/schintro/schintro_141.html call-with-current-continuation call-with-current-continuation is a very powerful control construct, which can be used to create more conventional control constructs, like catch and throw in Lisp (or setjmp and longjmp in C), or coroutines, and many more. It is extremely powerful because it allows a program to manipulate its own control stack so that procedure calls and returns needn't follow the normal depth-first textual call ordering. Recall that we said [ WHERE? ] that Scheme's equivalent of an activation stack is really a chain of partial continuations (suspension records), and this chain is known as a full continuation. And since continuations are immutable, they usually form a tree reflecting the call graph (actually, only the non-tail calls). Normally, the parts of this tree that are not in the current continuation chain are garbage, and can be garbage collected. If you take a pointer to the current continuation, and put it in a live variable or data structure, however, then that continuation chain will remain live and not be garbage collected. That is, you can capture the current state of the stack. It is not exactly what I want, but the core statement is 'A continuation is chain of partial continuations, or captured states of the stack' I think :) But maybe I'm wrong?! It's funny, but the whole continuation concept reminds me of the Tomita algorithm for simulating a GLR parser, which I currently working on ;-) http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps Stephan.
Patch to Problems with double click in coplet
Hi at all, we have found the problem of the double click bug and fixed them
...
so and here is the code snippet of the double click bug in class sunSpot
, method private showProtal(..) :
The problem was, that all threads are working on the same list of
sunletContens. That is not pretty good, because one thread has modify the
list and another is working on that modified list?. You can imaging about
the consequence!
Our solution is to make an local copy of that list , so that every thread
is working on his own list.
The old implementation:
sunletContents = (List[])
context.getAttribute(Constants.ATTRIBUTE_SUNLET_REPOSITORY);
? and the new one:
List[] temp = (List[])
context.getAttribute(Constants.ATTRIBUTE_SUNLET_REPOSITORY);
if (temp == null) {
sunletContents = null;
} else {
sunletContents = new List[temp.length];
for (int i = 0; i temp.length; i++) {
if (temp[i] == null) {
sunletContents[i] = null;
} else {
sunletContents[i] = new ArrayList(temp[i]);
}
}
}
BASF IT Services GmbH
EC-TP - RAT17
Hartmut Zimmermann
Tel.: +49 621 60-58632
Re: Using built-in stylesheets tags in other built-in stylesheets
Hi Adrian, I didn't saw that the xsl:template match=@*|*|text()|processing-instruction() priority=-2 xsl:copy xsl:apply-templates select=@*|*|text()|processing-instruction()/ /xsl:copy /xsl:template missed the xsl:copy... (damned) Thank a lot ! -- Olivier Billard [EMAIL PROTECTED] wrote: Hi Oliver, For a logicsheet to work properly, you must a) provide a default transformation for elements not handled by your XSL eg. xsl:template match=@*|*|text()|processing-instruction() priority=-2 xsl:copy xsl:apply-templates select=@*|*|text()|processing-instruction()/ /xsl:copy /xsl:template and b) you must have a root xsp:page/ handler, to kick the whole thing off: xsl:template match=xsp:page xsp:page xsl:apply-templates select=@*|*/ /xsp:page /xsl:template Then, all you need to do is call xsl:apply-templates/ in the spots in your logic where you want the nested logic-tags to be evaluated. HTH /Adrian -Original Message- From: Olivier Billard [mailto:[EMAIL PROTECTED] Sent: Thursday 17 July 2003 17:03 To: [EMAIL PROTECTED] Subject: Re: Using built-in stylesheets tags in other built-in stylesheets Hi Tim, Thanks for your answer. I've tried xsp esql mystylesheet and xsp mystylesheet esql and none worked... It seems that order in namespace declaration is no longer taken into consideration... Any other idea ? -- Olivier BILLARD Tim Myers wrote: The stylesheets get chained together in a pipeline one after the other. The only issue of one stylesheet using another is order in the pipeline. Your xsp must be transformed by any logicsheet that uses another logicsheet before it is transformed by that other logicsheet. xsp.xsl is the least dependent, most depended logicsheet. esql uses it. Here's the part i'm not sure about: Which ever order they are declared in cocoon.xconf is the order you should declare your logicsheet in: yourlogicsheet esql xsp or xsp esql yourlogicsheet. There was once a time when processing order was determined by the order the namespaces appear on the root element. I don't think that is any longer the case. Tim On Thu, Jul 17, 2003 at 04:23:38PM +0200, Olivier Billard wrote: Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with xsl:import or xsl:include ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.
RE: [Vote] Controller/Sitemap integration
From: Marc Portier [mailto:[EMAIL PROTECTED] Hi Mark, Good remarks! My list then becomes: Integrating the flow processor/engine: - V2 : flows/flow/(@type,@name)/* +1 Call a flow the first time: - V2 : initialize/(@flow,@type)/paramaters +1 Continue a flow: (just added the option) - V7 : continue/(@flow,@type)/paramaters +1 Component declaration: (indifferent on the engine-processor) +0 Renamings: - V1 : FlowState(and -Manager) I would leave the names as they are because as you (I think it was you) pointed out that this belongs to the implementation and not the interface. So I'm -0 on a renaming. Reinhard
Blob protocol... missing BlobSource logger declaration
Hi all ! I'm trying to use the blob protocol. It uses the BlobSourceFactory, defined in the cocoon.xconf. The factory uses BlobSource class, which is AbstractLogEnabled. But where is the logger defined for this component ? The BlobSource isn't defined anywhere ?!? So when I use the blob protocol, BlobSource throws a NullPointerException, because it doesn't find the logger via getLogger(). Any tip ? -- Olivier BILLARD
Re: Using built-in stylesheets tags in other built-in stylesheets
Just an FYI: I've sometimes gotten a NullPointer exception when trying to apply-templates select=@*/ where the current node wasn't an element. As a result, I split my pass-through templates into two templates: xsl:template match=* priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template xsl:template match=@*|text()|processing-instruction()|comment() priority=-1 xsl:copy xsl:apply-templates select=node()/ /xsl:copy /xsl:template I might have seen this done elsewhere when I first encountered the problem but I don't remember exactly. /S --- Olivier Billard [EMAIL PROTECTED] wrote: Hi Adrian, I didn't saw that the xsl:template match=@*|*|text()|processing-instruction() priority=-2 xsl:copy xsl:apply-templates select=@*|*|text()|processing-instruction()/ /xsl:copy /xsl:template missed the xsl:copy... (damned) Thank a lot ! -- Olivier Billard [EMAIL PROTECTED] wrote: Hi Oliver, For a logicsheet to work properly, you must a) provide a default transformation for elements not handled by your XSL eg. xsl:template match=@*|*|text()|processing-instruction() priority=-2 xsl:copy xsl:apply-templates select=@*|*|text()|processing-instruction()/ /xsl:copy /xsl:template and b) you must have a root xsp:page/ handler, to kick the whole thing off: xsl:template match=xsp:page xsp:page xsl:apply-templates select=@*|*/ /xsp:page /xsl:template Then, all you need to do is call xsl:apply-templates/ in the spots in your logic where you want the nested logic-tags to be evaluated. HTH /Adrian -Original Message- From: Olivier Billard [mailto:[EMAIL PROTECTED] Sent: Thursday 17 July 2003 17:03 To: [EMAIL PROTECTED] Subject: Re: Using built-in stylesheets tags in other built-in stylesheets Hi Tim, Thanks for your answer. I've tried xsp esql mystylesheet and xsp mystylesheet esql and none worked... It seems that order in namespace declaration is no longer taken into consideration... Any other idea ? -- Olivier BILLARD Tim Myers wrote: The stylesheets get chained together in a pipeline one after the other. The only issue of one stylesheet using another is order in the pipeline. Your xsp must be transformed by any logicsheet that uses another logicsheet before it is transformed by that other logicsheet. xsp.xsl is the least dependent, most depended logicsheet. esql uses it. Here's the part i'm not sure about: Which ever order they are declared in cocoon.xconf is the order you should declare your logicsheet in: yourlogicsheet esql xsp or xsp esql yourlogicsheet. There was once a time when processing order was determined by the order the namespaces appear on the root element. I don't think that is any longer the case. Tim On Thu, Jul 17, 2003 at 04:23:38PM +0200, Olivier Billard wrote: Hi all ! I've already asked this question on the users list, but the dev-ers may be more able to answer... :) I would like to know if there is any issue in using tablibs from built-in stylesheets (like esql) in user-custom built-in stylesheets. For me, no Java code is generated... Isn't it possible ? How does Cocoon deal with all these built-in stylesheets ? A global stylesheet with xsl:import or xsl:include ? Is there a requiered order of declaration in cocoon.xconf to be able to cross-use taglibs ? Thanks in advance ! -- Olivier BILLARD Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: [flow] session creation
Vadim,
Your observations are correct.
However, I just checked in a change to FOM_JavaScriptInterpreter that
causes it to only create a session if you actually modify global
variables. (Note: global constants do not cause a session to be
created). For example, if you modify the calculator sample to not use
global variables, i.e. like this:
function calculator()
{
var a, b, op;
var comp;
a = getNumber(a);
...
}
instead of this:
var a, b, op;
var comp;
function calculator()
{
a = getNumber(a);
...
}
then no session is created for it.
I think this is the best solution to this problem. Do you agree?
Regards,
Chris
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
I am using global variables in two situations
1. Static Variables
stuff like could easily be in the Application or Request Context:
I found out in Cocoon.idl (is it up to date?) that (IIUC) you have
access already to cocoon.context. So you write something like:
cocoon.context.Beans =
{
COVERAGE: org.iniva.archive.Coverage,
PERSON: org.iniva.archive.Person,
PROJECT: org.iniva.archive.Project,
RESOURCE: org.iniva.archive.Resource,
TYPE: org.iniva.archive.Type,
URL: org.iniva.archive.Url,
USER: org.iniva.archive.User
}
(Beans will be context attribute). This should provide fallback in
case flow context variables get rejected (Christopher already -1'd it).
If there are going to be ways of externally configuring how Global
Variables are stored, I think we need to take into account a possible
need to store different variable sets in different ways.
That would be terrific.
I do not believe that a global setting in Cocoon.xconf would be a
good idea though, I will have multiple FlowApps in one Cocoon
Instance, they by no means would want to share the same settings.
Agreed, cocoon.xconf is not a good place.
Vadim
Re: [RT] Adaptive Caching
Berin Loritsch wrote: The concept translates over to the adaptive cache approach at almost 1:1. The actual individual cost sample is not important. It is the windowed average that is important. For our cache a simple mean would best suit our problem space. The size of the window for our samples will control how responsive our cache control algorithm is. This would affect your cache prediction algorithm as the value k is no longer needed to control responsiveness. The value k can be set at 0, 1, or 0.5 depending on how you want to affect the slope. IMO, the window size should be the determining factor at how the average cost for a resource will converge toward the optimal point. Large window sizes provide slower response, while a smaller window provides faster response. BTW. If we use 0 for the value of k, then the cache prediction algorithm as is defined by your discriminate caching sequence would be a purely random result. The c(eff) function would solve down to the constant 0.5, and since we discriminate based on a randomly generated number being less than the result of the function, we have a 50/50 chance (theoretically) that the random number would be greater than 0.5. I say theoretcially because not all random number generators are truly random, or even mostly random. If we use 1 for the value of k, then the prediction algorithm follows the efficiency value much better. There is a higher chance of having a higher number for the cache prediction, which means we will be evaluating more entries. In fact, as the value for eff reaches +/-38, we will always be caching because the result of the equation will always be 1. If we use 0.5 for the value of k, then the prediction algorithm still follows the efficiency value, but our range is now to +/-76. The question then is, where statistically will this efficiency algorithm be all the time? I'm thinking about implementing the cache separately from cocoon to see if the math behind it works or not. If you have code to share, that would be wonderful (you can place it in the scratchpad if you want) Ok. Let me package this later today. I have a meeting for the next 3 hours. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
RE: [RT] Adaptive Caching
Stefano Mazzocchi [EMAIL PROTECTED] writes (and writes, and writes, and writes): small snip/ WARNING: this RT is long! and very dense, so I suggest you to turn on your printer. I don't have time to go through this in detail yet, but I've had a couple of fundamental questions that it might be useful to raise. I think the answer to some of these questions is maybe more of a Cocoon 3.0 type of solution than anything that would happen short term, but none-the-less it might be possible to consider some of them at the moment (and I may never get around to writing it later) small snip/ Final note: we are discussing resources which are produced using a cacheable pipeline *ONLY*. If the pipeline is not cacheable (means: it's not entirely composed of cache-aware components) caching never takes place. Strange as it may seem I think this statement might actually be questionable! This raises the question of what we mean by caching in the first place? You touch on this later, but let me suggest a couple of possible answers here: - client caching, 304 headers... - proxied caching - server caching - what the RT is mostly all about? Within server caching we can still dredge up more detail. In particular, with Cocoon we need to analyze the very mechanics of why caching is an issue at all: 1 ) Cocoon allows the production of various serialized outputs from dynamic inputs. If nothing is dynamic, no caching is needed (go direct to the source). Or alternately, think of the source as being the cache! 2) Within Cocoon, dynamic production (ignoring Readers for the moment) is done via the creation and later serialization of SAX events. To put it another way, within Cocoon caching is needed to optimize the production and serialization of the SAX events. The fact is, for some moment in time the SAX events are persisted within Cocoon and ultimately the serialized results are also persisted and hopefully cached. (With partial caching pipelines the serialized results cannot be cached.) As I skim through reading it, most of this paper seems to deal with the issue of how to determine in an efficient manner whether it is more efficient to retain these cached resources for some duration less than their normal ergodic period or regenerate them from scratch? This immediately creates the question of how to determine the ergodic period of an item. At first it would seem that if there is no way to determine the ergodic period of a fragment there is no reason to cache it! However, there is an alternative method of using the cache (which Geoff Howard has been working on) which is to have an event invalidated cache. In this model cache validity is determined by some event external to the production of the cached fragment and the cached fragment has no natural ergodic period. Such fragments still fit mostly within the model given here: although we do not know when the external event may transpire we can still determine that it is more efficient to regenerate the fragment from scratch than retain it in cache. If a cache invalidating event transpires then, for such fragments, it may also make sense to push the new version of the fragment into the cache at that time. Common use cases might be CMSs where authoring or editing events are expensive and rare (eg. regen Javadoc). In our case, we have a large set of metadata that is expensive to generate but rarely updated. This metadata is global across all users and if there are resources available we want it in the cache. This points out that in order to push something into cache one wants to make the same calculation as the cache manager would make to expire it from cache; is it more efficient to push a new version of this now? If not there may eventually be a pull request at which point the normal cache evaluation will determine how long to keep the new fragment cached. snip on the introductory math The first result of the above model is that site administrators cannot decide whether or not a particular resource needs to be cached since they don't have a way to measure the efficiency of the cache on that particular resource: they don't have all the necessary information. So: +--+ | Result #1: | | | | To obtain optimal caching efficiency, the system must be | | totally adaptive on all cacheable resources. | | | | which means (in Cocoon terms)| | | | The sitemap should *NOT* contain caching information | | since the caching concern and discrimintation doesn't| | belong to any individual's concern area. |
RE: [RT] Adaptive Caching
Jason Foster [EMAIL PROTECTED] asks: Unfortunately even with constant cost savings this is a variant of the Knapsack problem, which means it's NP-complete. Stefano's cache would then be a packing heuristic :) I think you're correct for a fully loaded system (which is when the algorithm matters). Of course that might be the reason for introducing randomness: Monte Carlo simulation can do a pretty effective job of getting an accurate approximation
Re: [flow] session creation
Christopher Oliver wrote: Vadim, Your observations are correct. However, I just checked in a change to FOM_JavaScriptInterpreter that causes it to only create a session if you actually modify global variables. (Note: global constants do not cause a session to be created). For example, if you modify the calculator sample to not use global variables, i.e. like this: ... then no session is created for it. I think this is the best solution to this problem. Do you agree? Yes! Thanks much Vadim
RE: [RT] Adaptive Caching
Berin Loritsch [EMAIL PROTECTED] writes: snip/ For this reason, providing a generic cache that works on whole resources is a much more efficient use of time. For example, it would make my site run much more efficiently if I could use a cache for my database bound objects instead of creating a call to the database to re-read the same information over and over. Allowing the cache to have hooks for a persistence mechanism will allow it to handle write-back style caching for user objects. Write-back caches will asynchronously write the information to the persistence mechanism while the critical computation path is minimally affected. Ahh, good point. In the intermediate results cache (DTM like database) that I envision that would definitely be something I'd expect (but forgot all about)...
Re: Blob protocol... missing BlobSource logger declaration
Olivier Billard wrote:
Hi all !
I'm trying to use the blob protocol. It uses the BlobSourceFactory,
defined in the cocoon.xconf. The factory uses BlobSource class, which
is AbstractLogEnabled. But where is the logger defined for this
component ? The BlobSource isn't defined anywhere ?!?
So when I use the blob protocol, BlobSource throws a
NullPointerException, because it doesn't find the logger via getLogger().
Any tip ?
Fixed : setupLogger(blob) was missing in BlobSourceFactory.getSource().
Thanks for reporting, please cross-check !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
cvs commit: cocoon-2.1/src/targets ide-build.xml
joerg 2003/07/17 12:01:42
Modified:src/targets ide-build.xml
Log:
splitted the eclipse-webapp-prepare target for usage with external started servlet
containers in combination with WEB-INF/classes as eclipse output folder
Revision ChangesPath
1.10 +10 -4 cocoon-2.1/src/targets/ide-build.xml
Index: ide-build.xml
===
RCS file: /home/cvs/cocoon-2.1/src/targets/ide-build.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ide-build.xml 12 Jul 2003 19:40:44 - 1.9
+++ ide-build.xml 17 Jul 2003 19:01:41 - 1.10
@@ -120,12 +120,18 @@
/target
!-- Prepares the webapp to make it directly usable with the eclipse project --
- target name=eclipse-prepare-webapp depends=prepare description=Prepares the
webapp directory to make it usable within Eclipse
+ target name=eclipse-webapp-prepare depends=prepare,
eclipse-webapp-delete-jars, eclipse-webapp-restore-roles
+ description=Prepares the webapp directory to make it usable within
Eclipse/
+
+ target name=eclipse-webapp-restore-roles
+ copy file=${build.dest}/org/apache/cocoon/cocoon.roles
+tofile=${build.webapp}/WEB-INF/classes/org/apache/cocoon/cocoon.roles
+overwrite=yes/
+ /target
+
+ target name=eclipse-webapp-delete-jars
!-- delete all jars, they are already included in the project --
delete
fileset dir=${build.webapp}/WEB-INF/lib includes=*.jar/
/delete
- copy file=${build.dest}/org/apache/cocoon/cocoon.roles
-tofile=${build.webapp}/WEB-INF/classes/org/apache/cocoon/cocoon.roles
-overwrite=yes/
/target
cvs commit: cocoon-2.1 .cvsignore
joerg 2003/07/17 12:03:11 Modified:..cvsignore Log: IDEA project files Revision ChangesPath 1.4 +2 -0 cocoon-2.1/.cvsignore Index: .cvsignore === RCS file: /home/cvs/cocoon-2.1/.cvsignore,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- .cvsignore11 Jul 2003 10:31:39 - 1.3 +++ .cvsignore17 Jul 2003 19:03:11 - 1.4 @@ -8,4 +8,6 @@ local.blocks.properties cocoon.sampledata .DS_Store +*.ipr +*.iws
Re: [Vote] Controller/Sitemap integration
Reinhard Pötz wrote: As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration Cool summary, really helps a lot. And here the cool voting matrix :) | A | B | C | D | E | |---|---|---|---|---| | | | | | | V1 | -1 | +0 | +0 | +.5 | +1 | | | | | | | V2 | +1 | -1 | -0 | +.5 | -1 | | | | | | | V3 | ?? | +.5 | -1 | \ | \ | | | | | | | V4 | \ | -1 | -0 | \ | \ | | | | | | | V5 | \ | +1 | +.5 | \ | \ | | | | | | | V6 | \ | \ | -1 | \ | \ | | | | | | | V7 | \ | \ | +1 | \ | \ | | | | | | | |---|---|---|---|---| What is the difference between A V1 and A V2? Only the map:flows/? And what does it mean? B V5 was missing. From Marc's answer I guess he meant this, but chooses V1. Joerg
DO NOT REPLY [Bug 20084] - Serious problem with TraxTransformer
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=20084. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20084 Serious problem with TraxTransformer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 19:37 --- Marked as duplicate after Sebastian Gil words at bug 20308. *** This bug has been marked as a duplicate of 20308 ***
DO NOT REPLY [Bug 20308] - Stylesheet includes not working with XSLTC
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=20308. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308 Stylesheet includes not working with XSLTC --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 19:39 --- We depend on XSLTC here. If you want to have it fixed, you have to vote for bug 20537 I guess.
DO NOT REPLY [Bug 20736] - JXForms validator rejects null value for numeric field
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=20736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20736 JXForms validator rejects null value for numeric field --- Additional Comments From [EMAIL PROTECTED] 2003-07-17 19:50 --- The same is true of xmlform. Should another bug be opened for this or should the summary of this one be changed to include it (now that they'll apparently be merged into woody).
[mock] Adaptive Caching
I have thrown together something that will at least help evaluate and fine-tune the thoughts on adaptive caching. I adapted the looped pseudo code (~ on page 5 if you printed it out). You will find that the actual value of the cost plays a *huge* difference in how this thing works. In fact it plays so much of a difference, we really need to define what an acceptable range is. What is the overall range for the cost function? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin cacheTest.zip Description: Zip compressed data
Re: [Vote] Controller/Sitemap integration
Reinhard Pötz wrote: From: Marc Portier [mailto:[EMAIL PROTECTED] Hi Mark, Good remarks! thx. snip / Renamings: - V1 : FlowState(and -Manager) I would leave the names as they are because as you (I think it was you) pointed out that this belongs to the implementation and not the interface. So I'm -0 on a renaming. Well, this in fact touches the very topic of why I think the map:continue flow=.. / could loose the need for a @type indication... if all the flow implementations would have their continuing stateful beasts implement the same interface (FlowState) then we get to have a higher level of reuse... (and more common stuff between different implementation, and more cross polination between their teams, and...) so what I really meant is that WebContinuation could continue to exist but then by implementing FlowState and as such be managed by the BasicFlowStateManager (the same Manager would then manage the stateful objects that can continue flows initiated by any engine/processor) also: implementing a FlowStateManager is IMHO about other concerns then how you instantiate them in their very nature (which is the job of the Engine/Processor) -- I'm planning some RT on those concerns in the near future, think to date I couldn't achieve a lot more then chaotic ramblings so the sepecific execution context these managed FlowState's need to perform their 'continue' action should be enclosed in the implementation (and thus hidden behind the interface) [NOTE: I'm using in aparent self-confident-mode a verb like 'should' but I reall am very much in dream-out-loud mode still, comments and feedback welcome, is this making sense?] Coming back on the vote: the issue here is not really about renaming these classes, but about introducing this FlowState abstraction layer. Your remark rightfully makes me see I was starting to overlook the subtle nuance. all in all, I have the feeling this is not really part of the public interface we want to nail down here and now ? (meaning that I believe the introduction of this layer could be done whithout much effect on applications that just use an certain flow implementation, of course the flowprocessor impl's themselves would have some refactoring ahead) the same remark probably goes for the FlowEngine/Processor and might explain our lesser natural connection to these issues on the table? Reinhard what do others think? -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Adaptive Caching
On Thursday, Jul 17, 2003, at 08:03 America/Guayaquil, Berin Loritsch wrote: [skipping nice parallel in digital audio] The concept translates over to the adaptive cache approach at almost 1:1. The actual individual cost sample is not important. It is the windowed average that is important. Well, on second thought, I think you misinterpreted my pseudocode. There is only *one* value of efficiency per resource. This is updated as we go, incresing or decreasing depending on the sampled efficiency but we don't need to keep the history of it, just the final sum of all the terms. for this reason we don't need a window, nor the system will slow down later on. -- Stefano.
Re: [RT] Adaptive Caching
Stefano Mazzocchi wrote: On Thursday, Jul 17, 2003, at 08:03 America/Guayaquil, Berin Loritsch wrote: [skipping nice parallel in digital audio] The concept translates over to the adaptive cache approach at almost 1:1. The actual individual cost sample is not important. It is the windowed average that is important. Well, on second thought, I think you misinterpreted my pseudocode. There is only *one* value of efficiency per resource. This is updated as we go, incresing or decreasing depending on the sampled efficiency but we don't need to keep the history of it, just the final sum of all the terms. for this reason we don't need a window, nor the system will slow down later on. The window is not for the efficiency, but for the history of the cost calculations. See the [mock] Adaptive Caching code and you will see how I interpreted things. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: Woody and user help....
Hi: Will be included the wd:help tag into Woody? Need it a votation? Best Regards, Antonio Gallardo. Antonio Gallardo dijo: Tony Collen dijo: Antonio Gallardo wrote: Tony Collen dijo: Well, call me a luddite but I'm not a huge fan of the DHTML... what's wrong with slapping help info in an alt tag? It depends, DHTML with Javascript helps to make some validations for users before send the page back to the server. DHTML allow to add some nice features like interactives drop down menus and popup contextual help. This kind of interaction is what a user has in a traditional fat client. I think there is no way back. Of course if we dont want, we can not use DHTML at all. But this is up to us. Blocking a feature is not the answer. In that case a wd:help tag must exist for every field and maybe at form level. Contextual help in a web application is a MUST. This is why I think woody must have a optional tag help. If you want to use it or not ot depedends of the user. The form how we will render it in HTML or WML depends of us. I would suggest to add wd:help. Also JXForms already has it. erp, what I meant to say was misunderstood. No, I already uderstand you. :) What I tried to explain is what you resumed below. I'm all for a help tag, I'm just not for hardcoding how it ends up appearing (DHTML). The last transformation woody2html depend of us. This can be easily modificable. Best Regards, Antonio Gallardo.
Re: [RT] Adaptive Caching
On Thursday, Jul 17, 2003, at 13:29 America/Guayaquil, Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes (and writes, and writes, and writes): LOL! small snip/ WARNING: this RT is long! and very dense, so I suggest you to turn on your printer. I don't have time to go through this in detail yet, but I've had a couple of fundamental questions that it might be useful to raise. I think the answer to some of these questions is maybe more of a Cocoon 3.0 type of solution than anything that would happen short term, but none-the-less it might be possible to consider some of them at the moment (and I may never get around to writing it later) small snip/ Final note: we are discussing resources which are produced using a cacheable pipeline *ONLY*. If the pipeline is not cacheable (means: it's not entirely composed of cache-aware components) caching never takes place. Strange as it may seem I think this statement might actually be questionable! This raises the question of what we mean by caching in the first place? You touch on this later, but let me suggest a couple of possible answers here: - client caching, 304 headers... - proxied caching - server caching - what the RT is mostly all about? all caching generates from the server. even proxy/client caching is done only after some metadata is attached to the response by the server. I agree that cocoon should be as proxy/client cache friendly as possible: that means, if the caching logic of the pipeline components can yield an ergodic period, we signal it to the proxy/client. if not, we can trigger the resource validity estimation and return an empty HTTP response with the proper code (I don't remember the number) to signify that the proxied/client-cached data is still valid and we don't have to regenerated, look it up and resend it. everything else is the internal cache concern. Within server caching we can still dredge up more detail. In particular, with Cocoon we need to analyze the very mechanics of why caching is an issue at all: 1 ) Cocoon allows the production of various serialized outputs from dynamic inputs. If nothing is dynamic, no caching is needed (go direct to the source). Or alternately, think of the source as being the cache! 2) Within Cocoon, dynamic production (ignoring Readers for the moment) is done via the creation and later serialization of SAX events. To put it another way, within Cocoon caching is needed to optimize the production and serialization of the SAX events. The fact is, for some moment in time the SAX events are persisted within Cocoon and ultimately the serialized results are also persisted and hopefully cached. (With partial caching pipelines the serialized results cannot be cached.) As I skim through reading it, most of this paper seems to deal with the issue of how to determine in an efficient manner whether it is more efficient to retain these cached resources for some duration less than their normal ergodic period or regenerate them from scratch? This immediately creates the question of how to determine the ergodic period of an item. Yep, that's a big concern. At first it would seem that if there is no way to determine the ergodic period of a fragment there is no reason to cache it! However, there is an alternative method of using the cache (which Geoff Howard has been working on) which is to have an event invalidated cache. In this model cache validity is determined by some event external to the production of the cached fragment and the cached fragment has no natural ergodic period. Such fragments still fit mostly within the model given here: although we do not know when the external event may transpire we can still determine that it is more efficient to regenerate the fragment from scratch than retain it in cache. I agree. Also let me point out that the logic of cache invalidation of fragments is totally orthogonal to the adaptive algorithms described. If a cache invalidating event transpires then, for such fragments, it may also make sense to push the new version of the fragment into the cache at that time. Common use cases might be CMSs where authoring or editing events are expensive and rare (eg. regen Javadoc). In our case, we have a large set of metadata that is expensive to generate but rarely updated. This metadata is global across all users and if there are resources available we want it in the cache. This points out that in order to push something into cache one wants to make the same calculation as the cache manager would make to expire it from cache; is it more efficient to push a new version of this now? If not there may eventually be a pull request at which point the normal cache evaluation will determine how long to keep the new fragment cached. Hmmm, very interesting point. Didn't think about this I'll let it percolate thru my synapses a little before replying...hmmm... snip on the introductory math The first result of the above model is
Re: [MVC] OJB+Woody+Flow
On Fri, 2003-07-18 at 00:07, Antonio Gallardo wrote: [...] View - Woody recieves a bean from the controller. Make form validation and return the bean to the controller. Just to make sure that you got it right: you can't just give a bean to Woody. Woody builds its own form-datastructure that will be used to collect user-entered data. The actual initial population of this datastructure with your bean's data, and afterwards putting the form's data back in bean, is up to you. Fortunately, this is where's Marc's binding stuff comes to help, which allows to do this by specifying a mapping between the two (in an XML file). -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [MVC] OJB+Woody+Flow
Bruno Dumon dijo: On Fri, 2003-07-18 at 00:07, Antonio Gallardo wrote: [...] View - Woody recieves a bean from the controller. Make form validation and return the bean to the controller. Just to make sure that you got it right: you can't just give a bean to Woody. Woody builds its own form-datastructure that will be used to collect user-entered data. The actual initial population of this datastructure with your bean's data, and afterwards putting the form's data back in bean, is up to you. Yes, I know I was trying to be the more simplistic to allow see all the mountain without going into the details. There are many details to be solved. This is what I am trying to do. :) Fortunately, this is where's Marc's binding stuff comes to help, which allows to do this by specifying a mapping between the two (in an XML file). Cool! Yes, I was thinking in this. There must be some kind of mapping or a encapsulation of the bean, since there are some other data not related to the real object. For example, error messages from the database or from the bussiness logic to be showed, error messages from the form, query values from the user to search find a list or a particular object, etc. There must be a interface to allow pass all this stuff to the form All in all, I think together we can build a great database driven web applications framework into Cocoon! This will be a killer app. I promise you :) Best Regards, Antonio Gallardo
cvs commit: cocoon-site/src/documentation/content/xdocs/link livesites.xml
joerg 2003/07/17 16:06:42 Modified:src/documentation/content/xdocs/link livesites.xml Log: Douglas Mawson Institute of Technology (http://www.dmit.sa.edu.au/cocoon/dmit/home.xml) Forestland Adventure Travel (http://www.forestland.gr/) Bildung für Afghanistan e.V. (http://www.bildung-fuer-afghanistan.de/) Revision ChangesPath 1.4 +8 -0 cocoon-site/src/documentation/content/xdocs/link/livesites.xml Index: livesites.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/link/livesites.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- livesites.xml 8 Jul 2003 13:19:07 - 1.3 +++ livesites.xml 17 Jul 2003 23:06:42 - 1.4 @@ -16,6 +16,12 @@ Here are some web sites that are proudly powered by Cocoon 2.1 (only ordered by Cocoon version): /p + s2 title=Cocoon 2.1rc1-dev +ul + lilink href=http://www.bildung-fuer-afghanistan.de/;Bildung für Afghanistan e.V./link + - NGO for funding and operating of grammar schools for girls in rural areas in Afghanistan/li +/ul + /s2 s2 title=Cocoon 2.1m3-dev ul lilink href=http://www.adolos.com/;Adolos/link/li @@ -59,6 +65,7 @@ lilink href=http://www.standardlifeinvestments.com;Standard Life Investments/link/li lilink href=http://www.megabag.gr;MegaBag S.A./link - Industrial and trading company of specialized polymer materials/li lilink href=http://www.ctg.albany.edu;Center for Technology in Government/link/li + lilink href=http://www.forestland.gr/;Forestland/link - Adventure Travel and Ecotourism/li /ul /s2 s2 title=Cocoon 2.0.3 @@ -73,6 +80,7 @@ li!-- only the articles, the rest is FrontPage -- link href=http://www.americanartists.org;The American Center for Artists/link/li lilink href=http://www.software-express.de/;Software Express/link - Software Competence Center for business and standard software/li + lilink href=http://www.dmit.sa.edu.au/cocoon/dmit/home.xml;Douglas Mawson Institute of Technology/link - Adelaide, South Australia/li /ul /s2 s2 title=Cocoon 2.0.2
[Woody] New tag wd:hotkey - Re: Woody and user help....
Bruno Dumon dijo: On Fri, 2003-07-18 at 00:09, Antonio Gallardo wrote: Hi: Will be included the wd:help tag into Woody? Oops, sorry for ignoring your previous mail about the topic... actually I have been pondering a while about whether the wd:label tag in the form definition makes any sense at all (and if it shouldn't simply be something that is part of the view template or xsl), and that's what got me distracted. But now I think it does make sense, and thus so does wd:help. I'll try to implement it when I have some time. Thanks. By the way, I think the wd:label tag is important too. But it must be optional. Sometimes we dont like to show any label for a widget. wd:help must be also a optional tag. There is missing another tag the wd:hot-key or wd:access-key tag. Maybe this can be an attribute of the wd:label tag. The implementation of this tag also can be a problem with the i18n. For example: In a text box: LanguagelabelHotkey english surname s spanish apellidos a. Of course other languages vary. This is a problem that also must be solved. Also note that not always the first char is the hotkey. The hot key must be unique for every widget in the form. Example: If we have on the same form text boxes labeled surname, source the hot key can be s for surname and o for source. I know this things are basics, but not for that we can forget it :) I just tried to scratchpad this little problem. To show some enhancements we can do in the great form machinery called woody. Of course is up to the implementator is he will implement in the view wd:help, wd:label and wd:hotkey. Best Regards, Antonio Gallardo.
Re: [flow] session creation
Geoff Howard wrote:
Thank you for this solution! Can you explain to my poor pea brain the
difference between a global variable and a global constant in this
context? IOW, if I want to use global contants how do I create and
access them in such a way as to avoid a session?
Geoff
If you assign a global variable outside of a function but never assign
it inside a function then no session will be created, as in your earlier
example, reproduced here:
So (can't test this now) does that mean that even currently, if
instead of:
var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
function cacheEvent() { ...
I do:
function cacheEvent() {
var role = Packages.org.apache.cocoon.caching.Cache.ROLE;
...
I skip the session?
As long as you don't assign to role inside a function, the session
will be skipped in both cases..
This solution isn't perfect though. If you create a global object and
modify its properties, those changes will not be preserved unless you
create a session:
1 var myObj = new MyObject();
2 myObj.prop = 3;
3
4 function page1() {
5 myObj.prop = 1;
6 sendPage(page1.html);
7 }
8
9 function page2() {
10 print(myObj.prop); // prints 3 if no session, but 1 if you
have a session
11 sendPage(page2.html);
12 }
With no session, the assignments on lines 1-2 will be executed each time
the script is called. If you have a session, they will only be executed
the first time the script is called.
Chris
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/bean CocoonBean.java
joerg 2003/07/17 22:00:08
Modified:src/java/org/apache/cocoon/bean CocoonBean.java
Log:
fixed NPE: logger was used before it is initialized
Revision ChangesPath
1.14 +2 -2 cocoon-2.1/src/java/org/apache/cocoon/bean/CocoonBean.java
Index: CocoonBean.java
===
RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/bean/CocoonBean.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- CocoonBean.java 27 Jun 2003 13:50:38 - 1.13
+++ CocoonBean.java 18 Jul 2003 05:00:06 - 1.14
@@ -158,6 +158,7 @@
public void initialize() throws Exception {
// @todo@ when does the logger get initialised? uv
// @todo@ these should log then throw exceptions back to the caller, not
use system.exit()
+setLogLevel(ERROR);
if (contextDir.equals()) {
String error =
@@ -178,7 +179,6 @@
log.fatalError(error);
throw new ProcessingException(error);
}
-setLogLevel(ERROR);
this.context = getDir(this.contextDir, context);
this.work = getDir(workDir, working);
