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 = DateFormat.getDateI
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: 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: Clarification on converter concept
On 05.07.2007 18:26, Grzegorz Kossakowski wrote: I had a feeling that there is much more besides Date/Number/Currency formatting but now I think that I was suffering from over-generalization problem. The converter concept is that simple how you describe it but it's not wrong because it solves very concrete problem. Hopefully it goes beyond simple date, number or currency formatting! With Spring's usage of PropertyEditors you can bind objects directly to a selection list. You don't care how it gets converted to string and back, the PropertyEditor does it. The CForms way is more complicated [1], you have to convert your collection to a org.apache.cocoon.forms.datatype.SelectionList. In my Spring MVC project I have written one (!) EntityPropertyEditor which is used for all domain entities in my application. Now in JSP using Spring's form taglib I just write: Which company do you want to work for? itemLabel="name"/> "user" is the object the form is bound to. "selectedCompany" is a property of the use and of type entity or company, not a entity id or something like that. "companies" is a collection of entities/companies, e.g. retrieved from RequestContext. "name" is a property of the entity/company, here used as label. That's all. No selection list generation. No caring about the key. The in the is correctly preselected if there was one set on the user. I get a company instance set on user.selectedCompany property. locale="${cocoon.request.locale}"> for each date. That is of course quite OK to write, but it clearly clutters the code, and it is not that obvious for a non developer. With converters it would be more like: ${myobj.startDate#short} Isn't that only a shorter syntax? The focus on template formatting is rather limiting. IMO it MUST be a two-way process or you can't write back to the object model. Selecting the converter in the template makes it just impossible. We might have a different focus in mind. But if we talk about a general converter concept we should not start with such a limitation. Joerg [1] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html
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 class="org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter" name="javascript"> resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js ${javascript.reload-scripts} ${javascript.check-time} in cocoon.xconf and then add 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: 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: <- some protocol to obtain the prepared data [...] Such construct introduces new semantics for sitemap because data returned by will be available _outside_ 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: Just to be sure, do you want to implement something like: <- some protocol to obtain the prepared data [...] Such construct introduces new semantics for sitemap because data returned by will be available _outside_ 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: 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: 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: 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: > >class="org.springframework.jdbc.datasource.DriverManagerDataSource"> > > > > > 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: 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: <- some protocol to obtain the prepared data [...] 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 will be available _outside_ 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: 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: ... 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: 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
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? 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? 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. Hope this was not even more obfuscating :-) No, it clears your position a little. :-) -- 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
xweber pisze: hi, here some feedback to current examples startet from trunk as guessed in README 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
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: RT: map:call as generic non-redirecting controller code
Grzegorz Kossakowski wrote: > Just to be sure, do you want to implement something like: > > ><- some protocol to obtain the prepared data > [...] > > > Such construct introduces new semantics for sitemap because data > returned by will be available _outside_ 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: 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
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: <- some protocol to obtain the prepared data [...] Such construct introduces new semantics for sitemap because data returned by will be available _outside_ 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: 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.
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.