[jira] Commented: (COCOON-2040) Union widget does not work with booleanfield set as case widget
[ https://issues.apache.org/jira/browse/COCOON-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487440 ] Grzegorz Kossakowski commented on COCOON-2040: -- No, it can't be fixed that easy. Current situation is broken because as case value we always have string, but as case widget we can set booleanfield for example. Test for value's equality is done in various places (processing of union widget, binding, rendering etc.). In order to avoid fixing conversion between Boolean and String in many places we could perform it in Union#getValue() method but then information about actual type would be lost forever. Now, I think that it's cleaner way of fixing it. How we should treat null values? Should we convert them into empty strings or keep them null? I could write a test case if I know how... :) (never done it, so any tips would be appreciated) Union widget does not work with booleanfield set as case widget --- Key: COCOON-2040 URL: https://issues.apache.org/jira/browse/COCOON-2040 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-forms-impl-union.patch Union widget compares values without performing conversion. Booleanfield returns Boolean object, so result of comparison is always false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Parameters in request get lost when using servlet: protocol
Alexander Klimetschek skrev: Rice Yeh schrieb: Thank you for your solution. But I still feel weird for a brand new request being created for a called block (servlet), at least for a super block (servlet). Having a look at the source code, each new brand request and response are supposed to be stored in its call frame (actually, this feature is not implemented yet, but api for retrieving these two objects are provided). If such design is intended, why not just treat request and response as part of servlet (block) context. And a way for passing a request's attributes or parameters must be provided. My real opinion is that request should be pass through all servlets invoked, instead of creating a new one. You are right, as far Cocoon's internal blocks with Sitemap servlets are involved. In that case one can optimize the calls and provide the original context (request, sitemap parameters etc.) to the callee. The only problem you have is how to handle the different parameter levels you have: you might want to have global but sometimes only local parameters, eg. when setting some value in a called block, you don't want it to override a parameter with the same name in the calling block. Exactly, Alexander and I had a discussion about this some time ago http://marc.info/?t=11641235741r=1w=2. My idea with the current implementation was that it is better to implement something minimal and extend it based on peoples need than to implement a faulty behavior that needs to be deprecated later. Anyway, a better parameter passing method is obviously needed. I implemented a special Spring call scope (see http://marc.info/?l=xml-cocoon-devm=116593632301167w=2) for being able to store call frame information in a way that works well with Spring. While it worked it depended on dynamically compiled proxies, so I decided to turn it of as the dynamic proxies didn't work that well together with our Maven build. I also saw that the Spring team worked on a alternative implementation that used ordinary Java proxies. This work is finished in the version of Spring that we currently use. So we could start to use the call scope and implement some reasonable parameter passing scheme in terms of that. /Daniel
Re: Servlet Services + Shielding
Alexander Klimetschek skrev: Hi Servlet Hackers, I am switching from our old block servlet config to the current servlet services in trunk and have problems with the configuration. I have two problems: 1) Seem to be handled later in the thread. 2) How to configure the ShieldingServletService (my little baby...)? Since you no longer explicitly define the wrapper class for the servlet, I don't see a way to use the ShieldingServletService instead of the standard one. You are supposed to be able to use the ShieldingServletService, http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/shielding/ShieldingServletService.java, with a ordinary Spring configuration, similar to the one you used before. But of course it would be a better idea to integrate it tighter with the rest of the servlet services and maybe use an extension of the custom XML-scheme for the configuration. As I don't know the details about the shielding stuff I thought it was a better idea to wait with the work until you moved to the servlet services. I also had some idea that the shielding stuff seem to be rather orthogonal to the servlet service stuff. So maybe it would be better to reimplement it as an interceptor that is applied before the servlet service proxy. I think those questions and the answers should be documented. As long as the docs are not finished (and public and searchable...), I'd like to put all important information in the Wiki: http://wiki.apache.org/cocoon/ServletService You could probably get write access to the Daisy documentation if you ask for it. But the important thing is that we have the documentation somewhere. /Daniel
[jira] Commented: (COCOON-2038) Implement true Object Oriented approach for handling super calls
[ https://issues.apache.org/jira/browse/COCOON-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487442 ] Daniel Fagerstrom commented on COCOON-2038: --- The explicit super call is because I didn't find any good way to call sitemaps in a call through way long time ago when I implemented the first version of the blocks fw. But of course it would be neater to not need to use an explicit super call. As the servlet service fw is supposed to work with any servlet the implicit super call mechanism need to use general servlet mechanisms. One way would be to call the base servlet and check for the status code of the http response object. If it is 200 OK and possibly some other responses in the 2xx (and maybe 3xx) series, the response is just returned. If the response is 404 Not Found (and maybe for some response codes in the 4xx and 5xx series) the super servlet is called. Otherwise the error response code is just returned. The mechanism should probably be implemented somewhere in the ServletServiceContext as most of the rest of the OO stuff is implemented there. Implement true Object Oriented approach for handling super calls Key: COCOON-2038 URL: https://issues.apache.org/jira/browse/COCOON-2038 Project: Cocoon Issue Type: Task Components: - Servlet service framework Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) As discussed here: http://thread.gmane.org/gmane.text.xml.cocoon.devel/72317 implementation of super calls should be changed to make it more OO-like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Servlets, Sitemaps, and Spring in trunk
Hi everyone, I've been looking at trunk to find out how things work these days and it looks great, but I am a bit confused. It seems like the blocks can register their own servlet to handle requests, is that true? There is a suspicious xml file in META-INF/cocoon/spring in each sample. But how does spring, or is it avalon, know that this servlet should be used at all? Through DispatcherServlet? It doesn't seem to work right now though, at least not if I use the cocoon-webapp. Is there an easy way to make it work? I'm trying to do some json stuff, so a detour through cocoon would not be so great. Thanks for the help! Bye, Max
Re: Servlets, Sitemaps, and Spring in trunk
Max Pfingsthorn napisał(a): Hi everyone, I've been looking at trunk to find out how things work these days and it looks great, but I am a bit confused. It seems like the blocks can register their own servlet to handle requests, is that true? There is a suspicious xml file in META-INF/cocoon/spring in each sample. But how does spring, or is it avalon, know that this servlet should be used at all? Through DispatcherServlet? It doesn't seem to work right now though, at least not if I use the cocoon-webapp. Is there an easy way to make it work? I'm trying to do some json stuff, so a detour through cocoon would not be so great. Yes, it's already great and will be even more appealing. :-) First of all, forgot about Avalon, all new stuff is Spring-based. Configuration at META-INF/cocoon/spring contains mount-path property which is the most important at the beginning. It tells DispatcherServlet the prefix on which servlet is registered. For example, if mount path is /cocoon-forms-sample all request that would be matched by /cocoon-forms-sample/** will get dispatched to the registered servlet. Next important thing is making connections to other blocks (servlets). It is needed if you want to call pipelines in other block. They can provide access for static resources (no more use of resource:// protocol!) and dynamic ones. This configuration snippet: servlet:connections entry key=ajax value-ref=org.apache.cocoon.ajax.impl.servlet/ /servlet:connections tells that we want to reference ajax servlet under short 'ajax' identifier. Now you can do something like this: map:generate src=servlet:ajax:/some/resource.xml/ and request for /some/resource.xml will be processed by ajax servlet. I think it's enough to start playing. If you want example of heavy usage of servlet-service-fw stuff take a look on refactored forms and ajax blocks in whiteboard. You have to make a svn switch and rebuild them. Ahh, and you can try it with cocoon-webapp but you have to use following pattern for your url: /blocks-test/[mount-path]/[rest-of-url] /blocks-test part is location where DispatcherServlet is mounted (take a look on web.xml in cocoon-webapp). Don't hesitate to ask more questions and make a promise to tell us success story not only about servlet-service-fw ;-) -- Grzegorz Kossakowski
Re: Servlets, Sitemaps, and Spring in trunk
Grzegorz Kossakowski napisał(a): I think it's enough to start playing. If you want example of heavy usage of servlet-service-fw stuff take a look on refactored forms and ajax blocks in whiteboard. You have to make a svn switch and rebuild them. One more thing. If you need to know what actually happened and why take a journey through jira issue starting from this one: https://issues.apache.org/jira/browse/COCOON-1991 -- Grzegorz Kossakowski
[jira] Created: (COCOON-2041) WebDAV Returns improper status on PUT
WebDAV Returns improper status on PUT
-
Key: COCOON-2041
URL: https://issues.apache.org/jira/browse/COCOON-2041
Project: Cocoon
Issue Type: Bug
Components: Blocks: WebDAV
Affects Versions: 2.1.11-dev (Current SVN)
Reporter: Edward Riede
on PUT, server returns the status 200 OK, when the proper response seems to
204 No Content
int the put method in webdav.js::: this:
try {
var status = repository.save(src,dest);
sendStatus(status);
}
can be changed to this:
try {
var status = repository.save(src,dest);
if(status == 200 ) status = 204;
sendStatus(status);
}
This fixed the issue in my application. However this seems a little hackish
and I haven't tested it well.
The org.apache.cocoon.components.repository.SourceRepository object might be
changed instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
