typo in daisy doc
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 message in context: http://www.nabble.com/typo-in-daisy-doc-tf4034226.html#a11460446 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: RT: map:call as generic non-redirecting controller code
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; currently I've implemented the old
method as just calling the new one: unless this API method is
really set in stone, it would seem to be better to re-factor the
signature of the existing method.
I wouldn't have any problem with such a small refactoring of the
API. But I have no expertise in API development policy. If anyone
have, please give your advice. At least some headup would be needed
before doing such s change, so that people that maybe don't follow
a detailed technical discussion like this one, can give their
feedback.
Yes, but I guess I can always submit a patch and people can vote on
it afterwards...
There is an alternative option I haven't previously mentioned;
simply returning values in the same way as 'bizData' is passed to
a sendPage*(), i.e. via the Flow context object. Thus (Grzegorz'
refactorings aside), the only change would be (for convenience) to
add a 'setReturnData()' JS method to call
FlowHelper.setContextObject() (Apples and JavaFlow would just use
FlowHelper) and write a very simple Action to call the flow
function. The flow-attr: module could then be used to access the
returned values in the normal way.
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 is clumsy, but easier/less disruptive to
implement, the latter is much more natural and what I was originally
aiming at.
Ok, I'll look out for further feedback, but otherwise submit a patch
using the direct return method for people to review.
Ellis.
Re: RT: map:call as generic non-redirecting controller code
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 is clumsy, but easier/less disruptive to implement,
the latter is much more natural and what I was originally aiming at.
Ok, I'll look out for further feedback, but otherwise submit a patch
using the direct return method for people to review.
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 returned by map:call will be available _outside_ map:call element. Now
it is important what is the scope where the data will be visible. Have you thought about it already?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: typo in daisy doc
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) Corrected, thanks! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: RT: map:call as generic non-redirecting controller code
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 returned by map:call will be available _outside_ map:call element. Now it is important what is the scope where the data will be visible. Have you thought about it already? 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 (IMO). Functions should only return (in the classical way) data to other functions calling them. Bye, Florian
Re: RT: map:call as generic non-redirecting controller code
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 (IMO). Functions should only return (in the classical way) data to other functions calling them. Florian, I'm not sure if I understand you correctly. What's the use to return data from function call if you can't process it later? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: feedback: starting examples in trunk
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. Do you feel that you would be able to help us fix some of them? After taking a quick look at your report I think that some would be quite easy to repair because only some paths are broken because of several refactorings. Could you fill bug reports for at least portion of your findings and preferably submit patch fixing the issue? Of course flood of issues will not help us that much but gradual informing should. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: RT: map:call as generic non-redirecting controller code
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 go (IMO). Functions should only return (in the classical way) data to other functions calling them. Florian, I'm not sure if I understand you correctly. What's the use to return data from function call if you can't process it later? I'm not against processing data, I want to avoid introducing a new protocol. And functions returning values the classical way (return myBestStuff;) will reduce readability of the pipeline. For few and/or small values I'd prefer variables, for many and/or big values one should think about introduce a generator or transformer weaving the data directly into the pipeline. Giving even void functions a sense: Doing something when a certain point in a pipeline is reached not directly touching data flowing through the pipe. Hope this was not even more obfuscating :-) Florian
Re: feedback: starting examples in trunk
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 fix some of them? After taking a quick look at your report I think that some would be quite easy to repair because only some paths are broken because of several refactorings. I would like to be able to fix them - but unfortunatly with my current Java and Cocoon knowledge I do not think that I am able beyond testing. If you can give me one solving sample what may be caused by a path problem and how to diag / fix this - then I think I will be able to apply on other cases on this kind of problem. I am still learning... Grzegorz Kossakowski-3 wrote: Could you fill bug reports for at least portion of your findings and preferably submit patch fixing the issue? Of course flood of issues will not help us that much but gradual informing should. Yes, putting that to a ticket system is possible for me. As I said in the report - I cannot assume (right now) which samples should run and which not (beacuse they are old stuff). Alex -- View this message in context: http://www.nabble.com/feedback%3A-starting-examples-in-trunk-tf3971847.html#a11462659 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: RT: map:call as generic non-redirecting controller code
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 returning values the classical way (return
myBestStuff;) will reduce readability of the pipeline. For few and/or
small values I'd prefer variables, for many and/or big values one should
think about introduce a generator or transformer weaving the data
directly into the pipeline.
By variables do you mean something like {someVar} construct in sitemap
and someVar can only contain string value?
Ok, you caught me red-handed. I still don't dream at night of the
various variable types in Cocoon. I meant a kind of business variable
cntaining Java objects.
Giving even void functions a sense: Doing something when a certain point
in a pipeline is reached not directly touching data flowing through the
pipe.
That's what I would be against to. Side effects is the last thing we
need in pipelines, IMHO. Personally I would like to see possibility to
call function only at the *beginning* of the pipeline and *before*
data is even processed. Exactly the same way actions are called today.
The point about implementing generator is valid only if you want to
implement something generic enough to call it component (generators
are components). Implementing use-it-once components is anti-pattern,
IMHO.
Yes, of course, implementing a use-it-once component is anti-pattern.
What about this:
map:call function=sayHelloToAuntBerta/
map:generate type=kissPrepare/
map:call function=sayNo/
map:transform type=kissApply/
map:serialize type=chubbyFacePincher/
map:call function=makeNoteNeverToTantalizeLittleChildrenWhenGrownUp/
... where the functions just print something to a file, let the computer
make weird noises, whatever, but NOT process those big humid kisses...
The concept of pipelines is creating sax event, modifying and
serializing sax events. Extensive use of functions injecting data would
open a new parallel kind of pipeline.
As Ellis Pritchard pointed out in his first post: It's about control
flow not processing data.
BTW: Will Actions be replaced by something more readable in future or
did I miss the discussion about?
Florian
Re: RT: map:call as generic non-redirecting controller code
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 calculateSomething();
}
Agreed, the former is clumsy, but easier/less disruptive to
implement, the latter is much more natural and what I was originally
aiming at.
Ok, I'll look out for further feedback, but otherwise submit a patch
using the direct return method for people to review.
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
I got the impression that Ellis leaned towards using a special flow
action instead.
Such construct introduces new semantics for sitemap because data
returned by map:call will be available _outside_ map:call element.
Now it is important what is the scope where the data will be visible.
Have you thought about it already?
When you call a pipeline within a flowscript the object model is
extended with the bizData. The business data is then available in
JXTemplate. I think we should use the same mechanism for flow actions.
The return value from the flow script is the business data. This should
then be inserted in the object model see
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/flow/AbstractInterpreter.java.
By doing that we can use a JXTemplateGenerator after the action and
extract the needed data.
Of course it should be possible to obtain data from some protocol as
well. But in many cases it is quite inconvenient to serialize business
beans to XML and the extract the needed fields with XSLT, it might be
easier to just access the fields directly with the expression language
in JXTemplate.
/Daniel
Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo
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 class=org.springframework.jdbc.datasource.DriverManagerDataSource property name=driverClassName value=org.hsqldb.jdbcDriver/ property name=url value=jdbc:hsql://localhost:9002/cocoondb/ /bean so the result is quite encouraging. My solution is totally transparent for users and very unobtrusive for Cocoon itself. I tried to check it with Forms SQL samples also but I have not managed to run it because we depend on JDBI that is not on Maven repository. The question is: what's now? Should I contact with developer and ask him politely to upload his work to Maven repository? Is it impossible with Maven to use a local library? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo
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: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html and here: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html. However, such a solution helps only if one checkouts sample from svn and does mvn install. We can't release a pom that depend on something that we install manually to local repository. It's quite easy and quick solution but only temporary, IMHO. Sylvain, I know that you use Ivy, how it works there? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: How to define database connection in C2.2?
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 has changed (e.g. forms). An c21 'block' will not run anyway just putting it into c22. Adaptions need to be done. It was quite easy to write such a bridge, see my commit r553872. I must admit that I wasn't able to test it thoroughly, though. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: RT: map:call as generic non-redirecting controller code
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 returned by map:call will be available _outside_ map:call element. Now it is important what is the scope where the data will be visible. Have you thought about it already? Actually, I have been thinking about this for a while as I have been toying about trying to figure out the best way to integrate Spring webflow with cocoon. One option was to use the Interpreter interface (which seemed very awkward, since this isn't really an interpreter) and use map:call. IIRC, it seemed that most (all?) of the flowscript usages I looked at don't follow the paradigm above. Rather, map:call is sort of an end point. It invokes other Cocoon pipelines to generate views but a pipeline doesn't follow it in the sitemap. I actually prefer this over the above. All this syntax does is provide a little bit more flexible action while still encouraging users to use the sitemap as the complete controller, even for business logic, which I hope we all know by now is a mistake. 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). Ralph
Re: RT: map:call as generic non-redirecting controller code
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 sitemap because data returned by map:call will be available _outside_ map:call element. Now it is important what is the scope where the data will be visible. Have you thought about it already? Actually, I have been thinking about this for a while as I have been toying about trying to figure out the best way to integrate Spring webflow with cocoon. One option was to use the Interpreter interface (which seemed very awkward, since this isn't really an interpreter) and use map:call. IIRC, it seemed that most (all?) of the flowscript usages I looked at don't follow the paradigm above. Rather, map:call is sort of an end point. It invokes other Cocoon pipelines to generate views but a pipeline doesn't follow it in the sitemap. I actually prefer this over the above. All this syntax does is provide a little bit more flexible action while still encouraging users to use the sitemap as the complete controller, even for business logic, which I hope we all know by now is a mistake. I understand your point and even share it. ;) I asked about that syntax because of deja vu effect (I have been reading some related discussions in archives to see what people said earlier). After re-reading Ellis'es original proposal I would say that I'm more than fine with it. Go ahead, Ellis! 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 Interpreter interface you need? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: RT: map:call as generic non-redirecting controller code
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 Interpreter interface you need?
Good question. Unfortunately, I haven't had a huge amount of time to see
what it would really take to invoke Spring webflow this way. However, it
certainly doesn't have continuations, so I doubt handleContinuation is
of much use. On the other hand, webflow does have event ids that need to
be passed in.
I also notice that (at least in 2.1) you have to declare
flow-interpreters default=javascript logger=flow
!-- FOM (Flow Object Model) --
component-instance
class=org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter
name=javascript
load-on-startupresource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js/load-on-startup
reload-scripts${javascript.reload-scripts}/reload-scripts
check-time${javascript.check-time}/check-time
!-- debuggerenabled/debugger -- !-- JavaScript Debugger
support --
/component-instance
/flow-interpreters
in cocoon.xconf and then add
map:flow language=javascript
map:script src=calc.js/
/map:flow
to your sitemap for this to work. webflow wouldn't have a script.
Instead it would have a flow configuration. This could be similar enough
that it would work, but it would feel weird to have to code
language=webflow.
Ralph
Re: How to update docs for 2.1?
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. We need to make that more clear at CocoonWebsiteUpdate wiki. It is already emphatic at http://apache.org/dev/#web http://apache.org/dev/project-site.html#edit -David Yes, that is correct. Edit the source for 2.1 docs via Daisy. Behind-the-scenes on forrest.zones.a.o, Forrest (calling the forrestbot from cron) is generating the final docs by extracting the content from Daisy and applying the website theme. However a human committer needs to commit the changes from time-to-time. I think that the wiki page describes all this. If you can point to any confusing areas, then i will try to fix it. It's all clear now, it was confusing why one have to commit anything if we store docs in Daisy and Forestbot generates pages automatically. I tweaked the paragraphs below the one that you refer to, to emphasise that committers should let forrestbot do the work and use the quick fix method of committing the final docs to cocoon/site/site/2.1/ SVN. Thanks! -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: RT: map:call as generic non-redirecting controller code
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
Re: Clarification on converter concept
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 he sugests MVCR
(Model-View-Controller-Renderer), where the renderer is responsible for
converting (Java) data types to displayable strings. The renderer can be
responsible for localization of numbers etc as well. The renderer is an
extra step between model and view.
The renderer applies very much to the original idea of PropertyEditor.
Displayable in the GUI programming might be a bit more complex. That's
why there is a method getCustomEditor() returning a java.awt.Component
for example. For web programming to and from string conversion should be
sufficient.
The simplest possible renderer is to just implement toString() in the
classes one is going to access in the view. But a better SoC is to have
a separate rendering component. In this case the object from the model
is first accessed by an expression in a suitable expression language and
then the object is rendered to a displayable string by the rendering
component and at last the displayable string is emited by the template
engine.
The externalized toString() describes quite perfectly what
PropertyEditor actually does.
How does it work (pseudo code and simplified):
BeanWrapper wrappedOM = new BeanWrapper(objectModel);
String displayString = wrappedOM.getProperty(aPath);
Internally BeanWrapper does:
Object value = getPropertyValue(objectModel, aPath);
Class valueType = getPropertyType(objectModel, aPath);
PropertyEditor editor =
PropertyEditorRegistry.findCustomEditor(valueType, aPath);
editor.setValue(value);
return editor.getAsText();
From purist's point of view it is really _bad_ idea to use interfaces
and classes for something that they were not invented for.
See above, it's not that far away. Unfortunately, Java started with GUI
programming before it founds its niche, the web programming. That's what
you still can find on this interface.
To be honest I'm not Spring specialist so I do not understand which
infrastructure exactly and how it helps. Even more confusing is that
something is going to be replaced by something else. I really don't know
what replaces what and what's for. Sorry.
I feared that my first collection of thoughts was too confusing. Will
focus on the important stuff now.
Do you want to state that you can define only one Converter for Foo
class? Or do you want to say that in Spring MVC you can register
converter for Foo class that is available by using particular epxression
(like xyz/bar/foo)?
The latter. If xyz/bar/foo would not be of type Foo it would not match.
What do you mean by registering? The idea for converters is that you
just create a bean (that implements necessary interface) and you are done.
Where does the template know from which converter to apply? For the
example ${myobj.startDate#short} short must actually be defined and
registered somewhere, doesn't it? How did you say: short date (whatever
it means) :-) That's defined by a particular converter which can be
looked up by the template in the registry.
I always found the JEXL/JXPath syntax rather counterintuitive.
What was counter-intuitive apart from switching between both that I do
not like either?
The ${} and #{}, the impedance mismatch between objects and xml model:
JXPath on beans does not behave like on xml.
How Spring syntax looks like and how it is better than JXPath/JEXL?
Bean property syntax which as used in other template languages like
Velocity and scripting languages as well: object1.object2.property.
3. Locale. PropertyEditors have no support for i18n/l10n. [..]
I had a look at Spring's CustomDateEditor [9]. It's set up with a
DateFormat. Since PropertyEditors should be prototypes anyway I
don't see a problem to inject the Locale into the editor on
registration as done via DateFormat for the CustomDateEditor.
That works without the PropertyEditors being locale-aware.
It all looks like plumbing and is counter-intuitive for my taste. It may
be that I miss the idea totally. If you could explain it and say way
such solution is better than proposed one it would be very helpful.
Ok, recently somebody posted the SimpleFormController Lifecycle Cheat
Sheet[2] in the Spring forum, which shows the request processing in the
controller. Don't try to understand it, I just want to show where we
are. One of the first things in the request processing is initBinder
which actually takes the request as parameter. That means you can
determine the locale in that method. You are supposed to register your
PropertyEditors in this method:
Binder.registerCustomEditor(Class, ProperyEditor);
So for the date converter:
Locale locale = // determine from request
DateFormat dateFormat =
