hi a little typo in daisy doc
http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1303.html
xmlns:configurator=http://cocoon.apache.org/schame/configurator;
but should be
xmlns:configurator=http://cocoon.apache.org/schema/configurator;
(schame - schema)
Alex
--
View this
On 5 Jul 2007, at 22:33, Daniel Fagerstrom wrote:
Ellis Pritchard skrev:
Hi,
Ok, that looks interesting (head spin); presumably that's a 2.2.
thing with no plans to port back to cocoon 2.1.x?
Adding a new non-void method to Interpreter alongside the old one
does seem a bit pointless;
Ellis Pritchard pisze:
Do you mean that you would have flowscripts like:
myFlowAction() {
var result = calculateSomething();
setReturnData(result);
}
I would much prefer to just use the return value of the flowscript:
myFlowAction() {
return calculateSomething();
}
Agreed, the former
xweber pisze:
hi a little typo in daisy doc
http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1303.html
xmlns:configurator=http://cocoon.apache.org/schame/configurator;
but should be
xmlns:configurator=http://cocoon.apache.org/schema/configurator;
(schame - schema)
Grzegorz Kossakowski wrote:
Just to be sure, do you want to implement something like:
map:match pattern=sth
map:call function=prepareData/
map:generate src=.../ - some protocol to obtain the prepared data
[...]
/map:match
Such construct introduces new semantics for sitemap because
Dev at weitling pisze:
Time for my 2 cents, sorry:
To be able to put a function call anywhere in a pipeline would be great,
having access to all the variables defined up till then. To return data
to the pipeline for further processing via a special protocol doesn't
look like the best way to go
xweber pisze:
hi,
here some feedback to current examples startet from trunk as guessed in
README
snip what=detailed bug report/
Alex, thanks for your effort of reporting all the issues. Such a thorough testing is of course very valuable and informative but we have to
think what's to do now.
Grzegorz Kossakowski wrote:
Dev at weitling pisze:
To be able to put a function call anywhere in a pipeline would be great,
having access to all the variables defined up till then. To return data
to the pipeline for further processing via a special protocol doesn't
look like the best way to
Grzegorz Kossakowski-3 wrote:
Alex, thanks for your effort of reporting all the issues. Such a thorough
testing is of course very valuable and informative but we have to think
what's to do now.
no problem.
Grzegorz Kossakowski-3 wrote:
Do you feel that you would be able to help us
Grzegorz Kossakowski wrote:
Dev at weitling pisze:
I'm not against processing data, I want to avoid introducing a new
protocol.
I think that we already have such a protocol, are you aware of
xmodule:flow-attr combo?
Not, but it looks interesting. Will have a look on it.
And functions
Grzegorz Kossakowski skrev:
Ellis Pritchard pisze:
Do you mean that you would have flowscripts like:
myFlowAction() {
var result = calculateSomething();
setReturnData(result);
}
I would much prefer to just use the return value of the flowscript:
myFlowAction() {
return
Grzegorz Kossakowski wrote:
Hi,
I created the bridge that was discussed in thread[1] and first
impression is that it will work. I have successfully run Avalon
component with database connection defined that way:
bean name=personnel
Sylvain Wallez pisze:
Grzegorz Kossakowski wrote:
Is it impossible with Maven to use a local library?
I must admit I have not thought about this option, I guess I'm too accustomed
to the fact that everything is on Maven's repository.
There is a bit of information here:
Felix Knecht pisze:
Do you think its worth to write such a bridge? Avalon is dead
(http://avalon.apache.org/closed.html) and c22 is now spring based.
Wouldn't it be a better solution migrate the db-stuff to spring and
therefore force the user to migrate his own components as well? In c22 a
lot
Grzegorz Kossakowski wrote:
Just to be sure, do you want to implement something like:
map:match pattern=sth
map:call function=prepareData/
map:generate src=.../ - some protocol to obtain the prepared data
[...]
/map:match
Such construct introduces new semantics for sitemap because data
Ralph Goers pisze:
Grzegorz Kossakowski wrote:
Just to be sure, do you want to implement something like:
map:match pattern=sth
map:call function=prepareData/
map:generate src=.../ - some protocol to obtain the prepared data
[...]
/map:match
Such construct introduces new semantics for
Grzegorz Kossakowski wrote:
Instead, I would simply like to see map:call expanded so that the
target function can be a bit more generic than an Interpreter (i.e -
it is easier to implement things like the JSF block, which uses an
action or Spring webflow).
What more generic than
Grzegorz Kossakowski wrote:
David Crossley pisze:
No it is not. That is how the cocoon website is still managed.
The ASF Infrastructure asks that all websites be stored in SVN.
I would say that's crucial sentence that helps to understand whole setup.
Now the rest makes sense.
Good idea.
Daniel Fagerstrom wrote:
I would much prefer to just use the return value of the flowscript:
myFlowAction() {
return calculateSomething();
}
I don't think this will work with FOM_Cocoon.suicide()
Vadim
On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
As Daniel pointed out, it has been discussed but I must admit I'm not
completely sure that I feel the concept.
I like Daniel's post [1] a lot. It goes very much into the direction of
PropertyEditors. Quoting him:
As a solution to the problem
20 matches
Mail list logo
