Re: [cforms] New ProcessingPhases added a repeater bug?
On Jun 14, 2006, at 11:06 PM, Antonio Gallardo wrote: Hi folks, Carlos and I suspect we hit a recently introduced bug. Steps to reproduce == 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/ blocks/forms/form2bean.flow 2. Change birthday date to a valid date (just changing the year to 2000 is enough). 3. Delete the unique contact in the repeater. 4. Now press Add contact. 6. Fill the firstname (an a is enough). 7. Save the form (press send button). Comments We suspect the error was introduced in revision 410241 [1]. Can anyone reproduce the bug and confirm the issue? Yes, I can. The Task Tree sample is another Cocoon sample to reproduce the problem: 3-Steps-Way to reproduce 1. Open http://cocoon.zones.apache.org/demos/21branch/samples/blocks/ forms/do-taskTree.flow 2. Fill the 'Project name' (an a is enough). 3. Save the form (press OK button). /Leo = java.lang.IllegalStateException: Cannot save model in phase ProcessingPhase[Save model=3] org.apache.cocoon.ProcessingException: Error calling continuation at resource://org/apache/cocoon/forms/flow/javascript/Form.js:256:-1 at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/ samples/blocks/forms/flow/forms_flow_example.js:172:-1 at map:call - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/blocks/forms/sitemap.xmap:180:38 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/blocks/sitemap.xmap:66:68 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/samples/sitemap.xmap:201:65 at map:mount - file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/ webapp/sitemap.xmap:1017:92 at org.apache.cocoon.ProcessingException.throwLocated (ProcessingException.java:144) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.ge tException(LocationTrackingDebugger.java:131) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpret er.handleContinuation(FOM_JavaScriptInterpreter.java:840) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo ke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:252) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:142) at
Re: JCR samples added
On Jul 15, 2005, at 6:04 PM, Carsten Ziegeler wrote: Michael Wechner wrote: Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/ samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. Carsten With current build I still get an Initialization Problem when accessing to the server: java.io.FileNotFoundException: /home/leo/BRANCH_2_1_X/build/webapp/ samples/repository.xml (No such file or directory) org.apache.avalon.framework.configuration.ConfigurationException: Cannot access configuration information at file:/home/leo/ BRANCH_2_1_X/build/webapp/WEB-INF/cocoon.xconf:2076:106 at org.apache.cocoon.jcr.JackrabbitRepository.configure (JackrabbitRepository.java:93) at org.apache.avalon.framework.container.ContainerUtil.configure (ContainerUtil.java:240) So, the sync isn't all done already, or is it? /Leo
Build fails with latest checkout of BRANCH_2_1_X
Hi, Build fails with latest checkout of BRANCH_2_1_X, using j2sdk1.4.2_07 on Debian Sarge /L. compile-core: Copying 18 files to /home/leo/BRANCH_2_1_X/build/cocoon-2.1.8-dev/classes Copied 60 empty directories to 33 empty directories under /home/leo/BRANCH_2_1_X/build/cocoon-2.1.8-dev/classes Compiling 559 source files to /home/leo/BRANCH_2_1_X/build/cocoon-2.1.8-dev/classes /home/leo/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/sitemap/FlowNodeBuilder.java:38: cannot resolve symbol symbol : class ConfigurationException location: class org.apache.cocoon.components.treeprocessor.sitemap.FlowNodeBuilder throw new ConfigurationException(Only one flow node per sitemap allowed.); ^ 1 error BUILD FAILED /home/leo/BRANCH_2_1_X/tools/targets/compile-build.xml:61: Compile failed; see the compiler error output for details.
typo in BRANCH_2_1_X/gump.xml (Line 1135)
Someone should correct this typo in BRANCH_2_1_X/gump.xml (Line 1135) packageorg.apache.c/ocoon/package ^^^ /Leo
Re: [VOTE] new Cocoon PMC chair
+1 for Vadim Gritsenko /leo
Re: [VOTE] Release on monday
On 19.05.2004, at 14:52, Vadim Gritsenko wrote: I'm +1 on release, if and only if, we note these above bugs in the known issues list. Vadim Please give me that list!!! I updated a server hosting a bunch of XSPs to current CVS. Using the default cocoon.xconf settings, first everything is fine, but after about an hour under medium load it is getting slower and slower and is starving while heap is growing to ~240M (-Xmx260m). can anybody confirm that these settings do work? /leo transient-store logger=core.store.transient parameter name=maxobjects value=1000/ /transient-store store logger=core.store parameter name=maxobjects value=1000/ parameter name=use-cache-directory value=true/ /store store-janitor logger=core.store.janitor parameter name=freememory value=500/ parameter name=heapsize value=19600/ parameter name=cleanupthreadinterval value=10/ parameter name=adaptivethreadinterval value=true/ parameter name=threadpriority value=5/ parameter name=percent_to_free value=10/ parameter name=invokegc value=false/ /store-janitor
Re: invalid content length
On 18.05.2004, at 23:56, Joerg Heinicke wrote: Can anybody tell me what can cause the invalid content length? The first one is html serializer, the latter ones text serializer. Joerg another one is http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17370 /leo
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_JavaScriptInterpreter.java
Could this commit be the cause of
http://issues.apache.org/bugzilla/show_bug.cgi?id=29008
(and possibly of
http://issues.apache.org/bugzilla/show_bug.cgi?id=29009 , too?)
/leo
On 05.05.2004, at 19:08, [EMAIL PROTECTED] wrote:
vgritsenko2004/05/05 10:08:05
Modified:
src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Log:
Check for valid session. Fixes exception running in Tomcat:
ERROR (2004-05-05) 12:06.15:469 [sitemap.handled-errors]
(/cc/samples/blocks/slide/logout.do) http8080-Processor5/PipelineNode:
Cannot create a session after the response has been committed
java.lang.IllegalStateException: Cannot create a session after the
response has been committed
at
org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.java
:2281)
Revision ChangesPath
1.29 +13 -9
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java
Index: FOM_JavaScriptInterpreter.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/
javascript/fom/FOM_JavaScriptInterpreter.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- FOM_JavaScriptInterpreter.java 5 May 2004 16:00:11 - 1.28
+++ FOM_JavaScriptInterpreter.java 5 May 2004 17:08:05 - 1.29
@@ -376,16 +376,20 @@
*/
private Scriptable setSessionScope(Scriptable scope) throws
Exception {
Request request =
ContextHelper.getRequest(this.avalonContext);
-Session session = request.getSession(true);
-HashMap userScopes =
(HashMap)session.getAttribute(USER_GLOBAL_SCOPE);
-if (userScopes == null) {
-userScopes = new HashMap();
-session.setAttribute(USER_GLOBAL_SCOPE, userScopes);
-}
+// Check that session is available (avoids
IllegalStateException)
+if (request.isRequestedSessionIdValid()) {
+Session session = request.getSession(true);
+
+HashMap userScopes =
(HashMap)session.getAttribute(USER_GLOBAL_SCOPE);
+if (userScopes == null) {
+userScopes = new HashMap();
+session.setAttribute(USER_GLOBAL_SCOPE, userScopes);
+}
-// Attach the scope to the current context
-userScopes.put(getSitemapPath(), scope);
+// Attach the scope to the current context
+userScopes.put(getSitemapPath(), scope);
+}
return scope;
}
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_JavaScriptInterpreter.java
On 17.05.2004, at 18:12, Vadim Gritsenko wrote:
Do those bugs disappear after patch is reverted?
Yep. I can't actually test the petstore and linotype samples, cause I
don't have CVS here, but I fixed some of my projects that have been
suffering from the same symptoms by simply reverting your patch. Fixing
it in any way before the release would be nice :)
/leo
Instead of request.isRequestedSessionIdValid() I can put a try/catch
block; but behavior in this case will be different in Tomcat and
Jetty.
Vadim
leo leonid wrote:
Could this commit be the cause of
http://issues.apache.org/bugzilla/show_bug.cgi?id=29008
(and possibly of
http://issues.apache.org/bugzilla/show_bug.cgi?id=29009 , too?)
/leo
On 05.05.2004, at 19:08, [EMAIL PROTECTED] wrote:
vgritsenko2004/05/05 10:08:05
Modified:
src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_JavaScriptInterpreter.java
Log:
Check for valid session. Fixes exception running in Tomcat:
ERROR (2004-05-05) 12:06.15:469 [sitemap.handled-errors]
(/cc/samples/blocks/slide/logout.do)
http8080-Processor5/PipelineNode: Cannot create a session after the
response has been committed
java.lang.IllegalStateException: Cannot create a session after the
response has been committed
at
org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.ja
va :2281)
Revision ChangesPath
1.29 +13 -9
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/
fom/ FOM_JavaScriptInterpreter.java
Index: FOM_JavaScriptInterpreter.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/
javascript/fom/FOM_JavaScriptInterpreter.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- FOM_JavaScriptInterpreter.java5 May 2004 16:00:11 -
1.28
+++ FOM_JavaScriptInterpreter.java5 May 2004 17:08:05 -
1.29
@@ -376,16 +376,20 @@
*/
private Scriptable setSessionScope(Scriptable scope) throws
Exception {
Request request =
ContextHelper.getRequest(this.avalonContext);
-Session session = request.getSession(true);
-HashMap userScopes =
(HashMap)session.getAttribute(USER_GLOBAL_SCOPE);
-if (userScopes == null) {
-userScopes = new HashMap();
-session.setAttribute(USER_GLOBAL_SCOPE, userScopes);
-}
+// Check that session is available (avoids
IllegalStateException)
+if (request.isRequestedSessionIdValid()) {
+Session session = request.getSession(true);
+
+HashMap userScopes =
(HashMap)session.getAttribute(USER_GLOBAL_SCOPE);
+if (userScopes == null) {
+userScopes = new HashMap();
+session.setAttribute(USER_GLOBAL_SCOPE,
userScopes);
+}
-// Attach the scope to the current context
-userScopes.put(getSitemapPath(), scope);
+// Attach the scope to the current context
+userScopes.put(getSitemapPath(), scope);
+}
return scope;
}
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_JavaScriptInterpreter.java
On 17.05.2004, at 20:52, Vadim Gritsenko wrote: leo leonid wrote: On 17.05.2004, at 18:12, Vadim Gritsenko wrote: Do those bugs disappear after patch is reverted? Yep. I can't actually test the petstore and linotype samples, cause I don't have CVS here, but I fixed some of my projects that have been suffering from the same symptoms by simply reverting your patch. Fixing it in any way before the release would be nice :) Ok, I made an attempt. But this code is still not clear to me anyway. At least those bugs seem to be fixed now (Petstore tested with Jetty). thanks /leo Vadim
Re: [QVote] Release 2.1.5 on May 14th (Cform API Convergence scheduled 2.1.6?)
Hi, Not that I'm strictly against a release, but I thought, that the new 2.1.5 release should mean something like officially launching CForms, after it's stabilization, in respect of the 'final' API. Actually we have two APIs, one widely deprecated, the other is looked at as an aging prototype. Bruno seems to be the only one concerned about the current situation, I'm still wondering why his v3 proposal didn't find any resonance? /leo On 03.05.2004, at 14:02, Carsten Ziegeler wrote: As suggested last week, I'm planning to do the 2.1.5 release on friday, 14th of May. So we can use the first friday (May, 7th) for any open issues and start with the code freeze on saturday. This is a quick vote, so please vote only if you're against it :) Thanks Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/
Re: Supersonic block has landed (Power Trio tutorial/example app)
On 04.05.2004, at 19:35, Bertrand Delacretaz wrote: I've just committed the new supersonic block, a tutorial/example app called Supersonic Tour of Apache Cocoon, focused on Pipelines, Flow, Forms (aka the Power Trio). I think, this a successful work, neither a dry HelloWorld, nor a complex beast, so you still get the essentials quickly. And it seems extensible, possibly a chance to demonstrate some O/R practices with our lovely web glue... There are probably a few typos here and there, and I'm no Forms guru (yet..) so As a Forms guru, I noticed you're using a deprecated syntax at some places in your Form Model, fd:validation shouldn't be nested within fd:datatype anymore. /leo enhancements are certainly possible (for example: why does this Calendar link show up next to the date entry fields ;-) Enjoy, and as always feedback and contributions are very welcome! -Bertrand
Re: Allowing redirects in handle-errors
On 20.04.2004, at 18:28, peter royal wrote: On Apr 20, 2004, at 12:22 PM, Tony Collen wrote: If a URL with an invalid continuation ID is invoked, I would like to take the user to the start of the process rather than displaying an error page. AFAIK, this needs a redirect-to in the handle-errors block. I can think of several ways of working around this block, but I was curious as to what others do in this situation, and if might warrant a revote on the change :) -pete Hmm. Could generate a page that has a manual redirect, e.g.: meta http-equiv=refresh content=0;url:http://foo/ ? yea, that's one of the ways of working around it, but seems hacky :) i could also create a custom Action since that gets a handle to a Redirector. -pete and what about calling a function map:when test=invalid-continuation map:call function=restart ... /map:call /map:when or a saved continuation ? /leo
Re: Modular database component
On Apr 19, 2004, at 4:49 PM, Reinhard Poetz wrote: leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo Basically it sounds interessting. But before we add support for another alternative accessing DBs in Cocoon we should discuss which alternatives *we* recommend and which not. (more on this you can find in the Modular database component thread) -- Reinhard some of *you* (developers [correct me if I misinterpret your *we*) seems to underestimate the users. Referring to Geoff's last post, you can assume, that people coming from the LAMP World (like me, with P=Perl) have already good reasons to do this effort. Your major concern seems to be that flow could be 'abused', precluding that a user could realize a misuse by himself. Since I use flow, I wrote more java classes than ever before. Whereas it may be unrealistic to expect a new users to start with writing new generators, transformers or actions, it is very likely that he starts scripting, but very soon sees the need of a more typesave model, and thereupon voluntarily starts refactoring his overcharged scripts, writing simple java beans, which he can address in almost the same way as his former javascript objects. It is an incremental process, where best practice advices are more valuable than exclusion of 'abuse'. Back to my original concern, I didn't want promote just another O/R tool. As I stated before, it is the only one I'm experienced with, and I'm just curious how it compares with others. It is obvious that cocoon lacks a solution here, but maybe this thread brings us a step nearer in such a way. /leo
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: To me, hibernate is overkill and yet another thing to manage. The advantage of esql is that it is simple, and has a single layer access to the database. Hibernate is more complicated to set up, and then has to be maintained. If you use plain SQL, only the queries have to be maintained. If you use hibernate, it also has to be maintained. For plain old statements like select * from foo where bla=xsp:request.../ it's just overkill to me. I do think hibernate is very good - for advanced usage. I think it is a shame that people are forced to either use xsp or use plain java.sql access to the database in flowscript. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
On Apr 19, 2004, at 4:42 PM, Leon Widdershoven wrote: Just curious (also:), how much work is it to set up for a given database? Leon I've been playing with those tools for about a week, then I was ready to start redesigning/refaktoring my old webapps, replacing former ESQL- and ScriptableConnection solutions with OR Mapping. OK, admitted, this seems not to be a very fast start, but you must consider that I'm rather a graphic designer than a programmer, and I'm not just new to DB stuff, I'm new to almost every technology involved, even new to java. The documentation and samples provided with that framework are useful, describing various kinds of connections and scenarios. /leo leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: To me, hibernate is overkill and yet another thing to manage. The advantage of esql is that it is simple, and has a single layer access to the database. Hibernate is more complicated to set up, and then has to be maintained. If you use plain SQL, only the queries have to be maintained. If you use hibernate, it also has to be maintained. For plain old statements like select * from foo where bla=xsp:request.../ it's just overkill to me. I do think hibernate is very good - for advanced usage. I think it is a shame that people are forced to either use xsp or use plain java.sql access to the database in flowscript. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: [cforms] widget values: set, get, validate, readfromrequest, parse, fireEvents,... generateSAXEvent
On Apr 8, 2004, at 8:54 AM, Marc Portier wrote: Hi there, just found a small glitch in the aggregate-binding which is somewhat related to a broader discussion IMHO (yeah, I know its related to the bug we closed only yesterday, just that I found out a nicer test after that) [just an apetizer] The context under which I found the issue: - definition holds an aggregate-widget (stolen from the aggregate binding sample from Vadim) the thing has: Thanks for pointing this out. I ran into the same problems, but lacking the proof, I assumed the problem must be my limited understanding of cforms, as it is usual the case, and potentially with this one, too: Well, apart from those datatype conversion issues, I'm malcontent with current aggregatefield and its widgets. Strictly speaking its the ft:aggregate-widget/ that is IMHO insufficient conclusive. Since there was aggregatefield widget, used to edit the value of multiple fields through one textbox [wiki], I never considered it not complete without it's complementary widget. Then the aggregate-widget have been introduced, and even though it's misleading name, I expected it to fill the gap, say, it could be used to edit the value of one textbox through multiple fields. Partly it does it, but to notice some of it's shortcomings, consider the following use case: you need way to input for a 16 digit credit card number that needs to be validated in multiple respects (required, number, mod10), very similar to the one in the form1 sample, but different in the way you present the form to the user. Cause you want to ease correctly composing such a long number by splitting it up to 4 fields, 4 digits each, that then gets reassembled and validated. But where I expected to get the validation errors assembled in a way as well, they just get lost, due to the widget replacement (of ft:aggregate-widget id=visa), hmmm, unsatisfying. (or do I get the whole thing totally wrong?) /leo
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript Form.js
On Apr 3, 2004, at 9:35 PM, Sylvain Wallez wrote: leo leonid wrote: On Apr 3, 2004, at 5:55 PM, Joerg Heinicke wrote: On 02.04.2004 19:42, leo leonid wrote: I can't confirm that wd:submit validate=false/ functionality is restored. It's OK in Revision 1.2 though. Or did the syntax change? Try CForms aggregate sample, switch button - it was broke before, now works. It still doesn't work in general. The problem is, that you only cancel standard validation. But you get stuck if you have a additional custom validation step. This means you have set a validator on the flow script level, i.e. this.validator = aFunction; ?? yep, inspired by Bruno's custom validation sample... If so, this feature is more or less deprecated though there was no official decision made about this until now, but Sylvain mentioned it as he added the possibility of adding validators to every widget. The flow script validator was more or less a hack, Hey, I'm happy with it, it was a feature, *now* we have a bug. now you have something official. If it is as useful and funny, OK! I mean, if you say its a wontfix I immediately stop patching my Form.js, willing to follow your official way. Could you give me a pointer to this. (Or a replacement of the then deprecated custom validation sample would be great ;) I don't have much time to follow up on this, but yes, the flow-level validator *was* useful when we did not have validators-on-every-widget. But now I am +1 to remove that feature from flow.js since we can directly add it to the Form object. Sylvain OK, I'm a switcher. OT: Stepping through the source of v2/ScriptableWidget - though without understanding that much - by now I can say: it was worth it! a visual treasure, that is not code formatting anymore, but fine arts. (e.g. lines 661-673) /leo
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript Form.js
I can't confirm that wd:submit validate=false/ functionality is
restored.
It's OK in Revision 1.2 though. Or did the syntax change?
/Leo
On Mar 31, 2004, at 11:06 PM, [EMAIL PROTECTED] wrote:
vgritsenko2004/03/31 13:06:59
Modified:
src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
Form.js
Log:
Regression: restoring wd:submit validate=false/ functionality.
Revision ChangesPath
1.5 +2 -2
cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/flow/
javascript/Form.js
Index: Form.js
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/
flow/javascript/Form.js,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Form.js 18 Mar 2004 21:04:40 - 1.4
+++ Form.js 31 Mar 2004 21:06:59 - 1.5
@@ -118,8 +118,8 @@
this.isValid = this.form.isValid();
} else {
this.isValid = this.form.isValid()
this.validator(this.form, bizData);
+finished = this.isValid;
}
-finished = this.isValid;
}
// FIXME: Theoretically, we should clone the form widget
(this.form) to ensure it keeps its
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript Form.js
On Apr 2, 2004, at 5:17 PM, Vadim Gritsenko wrote:
leo leonid wrote:
I can't confirm that wd:submit validate=false/ functionality is
restored.
It's OK in Revision 1.2 though. Or did the syntax change?
Try CForms aggregate sample, switch button - it was broke before,
now works.
True, but only because you specially handle it in your flowscript
if (form.submitId == switch) {
...
}
It still doesn't work in general.
/Leo
Vadim
/Leo
On Mar 31, 2004, at 11:06 PM, [EMAIL PROTECTED] wrote:
vgritsenko2004/03/31 13:06:59
Modified:
src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
Form.js
Log:
Regression: restoring wd:submit validate=false/ functionality.
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript Form.js
On Apr 2, 2004, at 7:23 PM, leo leonid wrote:
On Apr 2, 2004, at 5:17 PM, Vadim Gritsenko wrote:
leo leonid wrote:
I can't confirm that wd:submit validate=false/ functionality is
restored.
It's OK in Revision 1.2 though. Or did the syntax change?
Try CForms aggregate sample, switch button - it was broke before,
now works.
ignore
True, but only because you specially handle it in your flowscript
if (form.submitId == switch) {
...
}
/ignore
It still doesn't work in general.
The problem is, that you only cancel standard validation. But you get
stuck if you have a additional custom validation step.
/Leo
/Leo
Vadim
/Leo
On Mar 31, 2004, at 11:06 PM, [EMAIL PROTECTED] wrote:
vgritsenko2004/03/31 13:06:59
Modified:
src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript
Form.js
Log:
Regression: restoring wd:submit validate=false/ functionality.
Re: current CVS: XSP broken
On Mar 24, 2004, at 3:54 AM, Joerg Heinicke wrote: On 20.03.2004 21:42, leo leonid wrote: Exactly, nobody, neither I did, that was not my concern. Please take a moment and try to see it from my perspective. I did not expect that you or anybody specific answers on this temporary problem, but *that* anybody answers. I use the CVS version for developing, and I'm aware of the implications, that things can change or even break by the ongoing development process. May be it is just a coincidence, or it may be due to the fact that you are one of the most active committers - anyhow - your last commits put my projects in a fine mess. Sorry for that. no need, I was *not* complaining, as you see... Well, this happens, it's not the point, absolutely no problem, in general. Whereas I do have some objections, but these only concern the avoidable parts of the mess. That's when you _see_ your patch isn't mature at all and it breaks core parts of cocoon, This was the reason that I sent a mail to the list. Subject:AbstractXMLProducer patch consequences I assume that people living from CVS also read the developers list. I do. But IMO you can't assume your mail (with that subject) could get the needed visibility. Therefore I would not update my Cocoon if I knew that something is broken. Of course we avoid non-working as far as possible, but there also must be some time to discuss about things. If something is broken this highers the need for discussion while maybe somebody would not answer if it's not broken (lazy ass syndrom, let it as it is). I think I see your point, but I ask you to keep proportions in mind. /leo (the following seems to be a misunderstanding, probably due to my bad english skills, sorry!) or spoils users project directories (as with bug 27600) Huh? Sorry, but here I feel innocently accused. *I* added the behaviour that the source directory is not touched at all until you choose otherwise after the complete update worked. Furthermore this helper target was only a few days old, it's not something that breaks anything (i.e. is needed at run time) and was easily changeable by the developer using the target by putting the xslt part into comments. Here the need to revert was very much lower than for the above XSP problem IMO. and you still don't consider to revert it. Why? Are you still not satisfied with the current solution making the xslt part optional? (You wrote the above two days after I added this.) Anyway, glad to hear you fixed it. Thanks. No problem. Joerg
Re: current CVS: XSP broken
On Mar 20, 2004, at 4:14 PM, Joerg Heinicke wrote: On 19.03.2004 17:52, leo leonid wrote: all my xsp stopped working after updating to the current CVS. What happend? http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107964359715995w=4 Unfortunately there is no response until now. Joerg hmmm, probably I'm the only one who still uses XSP, but I'd clearly opt to revert that patch. Hey, nobody said that it won't be fixed! The question was only in which way. It's now working in CVS. Joerg Exactly, nobody, neither I did, that was not my concern. Please take a moment and try to see it from my perspective. I use the CVS version for developing, and I'm aware of the implications, that things can change or even break by the ongoing development process. May be it is just a coincidence, or it may be due to the fact that you are one of the most active committers - anyhow - your last commits put my projects in a fine mess. Well, this happens, it's not the point, absolutely no problem, in general. Whereas I do have some objections, but these only concern the avoidable parts of the mess. That's when you _see_ your patch isn't mature at all and it breaks core parts of cocoon, or spoils users project directories (as with bug 27600) and you still don't consider to revert it. Anyway, glad to hear you fixed it. Thanks. /leo
current CVS: XSP broken
Hi, all my xsp stopped working after updating to the current CVS (today 16:30 GMT-1). All xsp-samples shipped with cocoon don't work either. What happend? /leo
Re: current CVS: XSP broken
On Mar 19, 2004, at 5:25 PM, Joerg Heinicke wrote: leo leonid tek at leonid.de writes: all my xsp stopped working after updating to the current CVS. What happend? http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107964359715995w=4 Unfortunately there is no response until now. Joerg hmmm, probably I'm the only one who still uses XSP, but I'd clearly opt to revert that patch. /leo
Re: XSP block status
Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). Unfortunately now most of my projects are broken anyhow, because they use XSP (ESQL), and I was not aware of the XSP refactoring going on :( Was it just a bad moment for CVS-update or does the move of XSP to its own block affect existing projects? Where do I have to pay attention? thanks. /leo On Mar 10, 2004, at 7:24 PM, Unico Hommes wrote: There remain a few issues that need resolving. - InputModuleAction had to move along with xsp because it has a dependency on some xsp helper class. This is unfortunate and maybe unnecessary. Perhaps someone with more knowledge about this class could take a look and see if they can solve this? - Source samples. Some use xsp's. Move these to xsp block or remove them altogether? - I18n samples. Needs volunteer. - simpleform samples. Needs volunteer. - session-fw patches are executed before xsp patches but depend on them. Move xsp specific stuff from session-fw to xsp. - some blocks have dependencies on xsp. These need to be declared. Stephan, does that about cover it? -- Unico
Re: XSP block status
On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only improvement tips from my side: - make it accepting paths to project directory without trailing slashes as well - make it covering the change forms.datatype.ValidationError to forms.validation.ValidationError, too. to answer my original question: Was it just a bad moment for CVS-update or does the move of XSP to its own block affect existing projects? in deed, it was a bad moment for CVS-update. I did a clean build and everything looks fine so far :) /leo -- Reinhard
Re: XSP block status
On Mar 11, 2004, at 8:35 PM, Reinhard Pötz wrote: leo leonid wrote: On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote: leo leonid wrote: Hi, I just updated my projects from woody to cocoon forms (absolutely painless, BTW). How did you do the upgrade? I used your ant task ($COCOON_HOME/build.sh woody2CocoonForms-renaming). It did the job quite perfectly. Only improvement tips from my side: - make it accepting paths to project directory without trailing slashes as well Should work ... what did you try? Hmmm... you're right! Can't reproduce it, probably I got the ... directory doesn't exist error due to an empty space following the paths. - make it covering the change forms.datatype.ValidationError to forms.validation.ValidationError, too. Thanks, added in CVS. Cool! /leo -- Reinhard
Re: [Woody] woody.js (show) woody2.js (showForm) et al
On Oct 17, 2003, at 12:39 PM, Antonio Gallardo wrote: Sylvain Wallez dijo: Yep. And posts like Barzilai's one make me wonder if we should stop development in the 2.1 repo and move it over to 2.2 into a new cforms (Cocoon forms) block. Note that this doesn't prevent to backport this block to 2.1 before an official 2.2 release if we consider that it has reached some level of stability (including docs). -1. I think woody need to get improved even faster than the current trend in the current release too. 2.2 is far away and since it will be at a stable level this would slowdown the development of woody. :-( I totaly agree with the above.. O.K., Cocoon evolves and is in permanent state of flux, which is quite natural, but it mustn't turn into a permanent teleology, I feel more and more discouraged to use these new features of the long awaited v.2.1. When 2.0 was out and 2.1 just started everyone was looking forward to have a xml-form framework. Now we have 3 of it, but only few people use it, because there is too much hope again - for v.2.2. /leo
Re: fixing/completing petstore sample for 2.1.1
Christopher Oliver writes: Hi Leo, Please do. Thanks, Chris Hi Chris, I successfully added such functionality to an application that derived from the petstore. But I had problems to do it the same way with the original sample. The problem with my (maybe completely wrong) approach is, that once you successfully edited your account information, you can never sign on again :-/ , even if you didn't change anything. Anyway, I attached the files I changed or created. It's a bit late now to get this solved before the release ... hm /leo -Original Message- From: leo leonid [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:57 AM To: [EMAIL PROTECTED] Subject: fixing/completing petstore sample for 2.1.1 hi, in the current version of the petstore sample the jxform part does not work. If you signed in ad want to change your account informations get errors. This can easily be fixed by removing action=petstore attribute from xf:form in the following files: petstore/view/jxforms/EditUserInformation.xml petstore/view/jxforms/EditAccountInformation.xml petstore/view/jxforms/EditProfileInformation.xml Further the form can't acces the address fields. To fix this you have to rename address1 and address2 to addr1 and addr2 in the following files petstore/view/jxforms/EditAccountInformation.xml petstore/flow/PetStoreImpl.js Other parts of the application are still pending, like the registration of new users. If there is an interest I can try to implement this. /leo petstore.tar.gz Description: GNU Zip compressed data
fixing/completing petstore sample for 2.1.1
hi, in the current version of the petstore sample the jxform part does not work. If you signed in ad want to change your account informations get errors. This can easily be fixed by removing action=petstore attribute from xf:form in the following files: petstore/view/jxforms/EditUserInformation.xml petstore/view/jxforms/EditAccountInformation.xml petstore/view/jxforms/EditProfileInformation.xml Further the form can't acces the address fields. To fix this you have to rename address1 and address2 to addr1 and addr2 in the following files petstore/view/jxforms/EditAccountInformation.xml petstore/flow/PetStoreImpl.js Other parts of the application are still pending, like the registration of new users. If there is an interest I can try to implement this. /leo
Re: [RT] Improving Views
On Mittwoch, August 20, 2003, at 09:07 Uhr, Carsten Ziegeler wrote: It's seems we have RT Time :) With views we have a nice sitemap feature that imho can be improved as well: One major disadvantage currently is that views are not inherited to subsitemaps, so I: Views should be inherited and can be extended/overwritten in subsitemaps like any other component. Views are used for different scenarios; they provide a different ending of your pipeline. This is e.g. useful for debugging. Now by default the content view is enabled (for the main sitemap), and most times this view is not disabled when the application goes in production, so a user can invoke this view on deployed applications and see the output of the generator. But, this might contain sensitive data which is not intended to be seen by the average user. So it makes sense to have a way to turn off views. But at the same time you might need views in different areas of your application, so: Views can have a default state: enabled or disabled that can be set in the sitemap: map:views default=enabled (or disabled) This default can be overwritten on a map:pipeline base: map:pipeline views=disabled (or enabled) In addition, you can allow only some views, like: map:pipeline allow-views=x,z And now you :) I think it is not sufficient to have views that can be enabled/disabled. Sometimes other components depend on certain views (like the Lucene indexer) and so you can't disable. Maybe we need a sort of access restriction mechanism. /Leo Carsten Carsten Ziegeler Open Source Group, SN AG http://radio.weblogs.com/0107211/
