Re: Passing request params to a flowscript thru a resource?
Geoff Howard wrote:
Stephan Coboos wrote:
Hello,
because I've got no answer for my question postet in the users list
before, I will try it on the dev list...
I have the following sitemap fragment:
...
map:resources
map:resource name=main
map:call function=main/
/map:resource
/map:resources
map:flow language=javascript
map:script src=flows/myScript.js/
/map:flow
map:pipelines
map:pipeline
map:match pattern=
map:call resource=main/
/map:match
/map:pipeline
/map:pipelines
...
In the match section I'm calling the resource 'main' which is calling
a flowscript function itself. But if I do that this way I don't have
access to the request params in the flowscript because
cocoon.request... returns nothing! How do I activate passing request
parameters thru resources to a flowscript?
Can you explain why you would need to do this? The example you've
given above is pointless AFAICS.
Geoff
Hello Geoff,
yes, I can explain it for you. I'm writing a simple cms. In this cms it
is possible to surf arround the entire websites and when the customer
wants to edit a page he has to click the edit button situated on top on
the page if he is logged in. The whole cms is organized by only one
central flowscript which checks for login, recievies the values from the
database via components and makes other things. The status of the
flowscript must be valid during the user is logged. So I have written
two simple actions: The first sets the actual continuation id to the
session and the second one extracts the continuation id from the
session. At this way, no need is necessary to change the url's on the
webpage to forward the continuation id. But to call the two actions I
need to call resource every time before the flowscript is called and
before the response is sent to the client:
...
!-- Sets the continuation-id into the session --
map:resource name=setContinuation
map:act type=setCont/
map:serialize type=html/
/map:resources
!-- Extracts the cont-id from the session and loads the continuation
If no continuation-id exists, the function cms will be called --
map:resource name=getContinuation
map:act type=getCont
!-- param continuation-id comes from the action --
map:call continuation={continuation-id}/
/map:act
map:call function=cms/
/map:resource
...
All works fine! Only the request returns everytime null when I'm calling
the function cms this way. If I call the function directly in the
match block, the request works and returns the correkt values!
Regards
Stephan
Re: CocoonForms server sizing?
On Tue, Dec 02, 2003 at 10:52:38PM +0100, Bruno Dumon wrote: On Tue, 2003-12-02 at 01:51, Alex Kovacs wrote: Hi Tim, I am working on a big project using woody (oops CocoonForms) with around 1600 forms. We will probably run some benchmarks to get the sizing info and I will let you know once we get them done. We however do not know enough about tunning cocoon, apart from using resource pooling for components set in the sitemap. Is there other pertinent information that we should know? yes, enable stylesheet caching (use-store=true in the cocoon.xconf) why isn't this a default setting ? lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: frustration with cocoon [please help]
Geoff Howard wrote: Michael Wolf wrote: Now the act method doesn't work anymore. In the documentation it is still recommended to use the modular database actions from the flow, but nowhere is explained how it is done. Last time I checked it appeared that all support code is still there. But then I didn't test it. Then I've found mails where someone states that there is no need for the legacy script and one should be able to use the actions via the getComponent method. But, of course, nowhere in the documentation is explained how to do it. After posting in this mailing-list I got a hint how to access the action using the getComponent method. Probably because this touches basic Avalon knowledge and the Avalon site is the best place to find that. AFAIK using action without the support boils down to the following problems: - it's a multi step process instead of just calling act(): getComponent, call component, release component - visibility: if the action is declared in a sub sitemap, it will not be visible to flow. This can be circumvented by declaring it in root sitemap or even cocoon.xconf. - parameters for act() signature: - Redirector does not make much sense from flow. However, a new instance can easily be created. - Parameters need some conversion to easily set them from ECMA script or the use of a little bit more JAVA types. Remember that you can create instances of any JAVA type in ECMS script. There are still conversion methods contained in the Cocoon object BTW. - src is hardly used, mainly for actions written in other languages than JAVA. - objectModel is a little more difficult since here start the area where we have cut down the FOM to make bad things harder in flow :-| I believe it should be obtainable by ContextHelper.getObjectModel(cocoon.getContext()) or the like. - SourceResolver is probably hardest. It has been discussed to make this available through the component manager. In that case it could be obtained by cocoon.getComponent(SourceResolver.ROLE). If this is not the case -- well, then it's an open issue that will be closed when someone finds the time for it Now, your particular case is really about out of the box database components accessible in flow - the fact that this historically was only available in actions is coincidence. There are a lot of different opinions here about what Cocoon should provide. There is a lot of movement toward providing easy integration with O/R projects like OJB. I personally feel it will also be important to have something like the modular database actions (perhaps even keeping much of its code) as standard components accessible from the flow. I don't have time to work on that, and don't know if others have the same view, but I see it as a need. Well, it's on my schedule. But then I belive a O/R mapping is much more elegant and the actions are just what I like to call a poor man's O/R bridge. Plus the interest in this seems to be quite limited But now there is the act method of the action with its parameters. Again, there is no information how to do this. Now, about calling the act method - you should be able to come up with all the objects it needs and call it right from flow. In fact, you may be able to pass in null as some of the objects if you're sure it the mod-db actions don't use them. Come to think of it, a quick and dirty way to find out what they (the actions) need is to pass in all parameters as null and fix each specific problem as it arises. It won't get you a PhD in Computer Science but it's crazy enough that it just may work. SourceResolver is needed to load the description files, objectModel needs to be passed to the modules for obtaining e.g. request parameters. Parameters contain configuration of the action. Most (all?) can be set when declaring the action. For two weeks I tried to get the modular database actions running from the flowscript as it is recommended in the modular database action sample shipped with the 2.1.2 cocoon version. I've not seen that recommendation personally - as discussed many would not recommend it. Your other options are Me neither. really to - refactor the actions to run as standalone components, - write your own jdbc code in components, - totally switch your design to work with the (still experimental?) ojb block - don't use flow in that part of your project. Given those options, I'd say you'll probably have the best luck with the path you've been trying but that's just my quick opinion. Another hint is to look at the GT2003 presentation on database integration with Cocoon. It doesn't tell you everything but has an overview on your options. Chris.
RE: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Let's roll back (Xerces of course) :) Carsten -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 3:42 AM To: [EMAIL PROTECTED] Subject: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall) Geoff Howard wrote: Bruno Dumon wrote: On Wed, 2003-11-26 at 17:47, Timothy Larson wrote: --- Geoff Howard [EMAIL PROTECTED] wrote: Can someone try rolling back Xerces to prior version to make sure that's the issue? Of course, you'll have to unplug from the network before building or you won't notice the issue. I looked briefly at Xerces' site last night and didn't find any clues this was intentionally changed in the latest release but there were some bugfix descriptions which could point to an accidental new problem. ... If I unplug my network connection, I also get the UnkownHostException. I reverted to xercesImpl-2.5.0.jar, left the rest the same, and now it works for me. So seems like a bug in Xerces to me. I attempted directly using the DOMParser class directly as they recommend in the FAQ with mixed results. I've filed a bug with more details at Xerces bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25043 I wasn't able to spend more time digging around or coming up with an isolated test case for them - any takers? The bugzilla entry and this discussion: http://thread.gmane.org/gmane.text.xml.xerces-j.devel/475 indicate that this is now fixed in xerces cvs. I tried the solution they suggested as a workaround for 2.6 with no luck (though it may be that I don't know my way around XNI). So, do we 1) Ignore the bug until a later version of xerces is released? (the bug is that the build fails without an internet connection due to the dtd resolving in web.xml) 2) Roll back to 2.5? (I assume this would unfix other bugs?) 3) Use a dated version of xerces from cvs until their next release. WDYT? Geoff
Re: Slide repository
On 2 Dec 2003, at 12:35, Unico Hommes wrote: I'm looking into the Slide block ATM and want to rename the package from o.a.c.components.repository to o.a.c.components.slide in order to avoid collision with the repository block. Any objections? I'm also renaming Repository.java to SlideRepository.java and adding the two public methods the service is to expose in order to fix http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24964 . +1, if not already you might want to mark the block as alpha -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Converging the repository concept in cocoon
On 1 Dec 2003, at 13:04, Mats Norén wrote: Things that could prove useful: 6) observation - add listeners to specific events in the repository based on both the type of event and on the location in the repository. yes, this is *very* useful. But I'm not sure how we could handle this ATM so I would leave it out for now. 7) visitable nodes in the tree - do batch processing on nodes in the repository, etc. For example to set specific properties on nodes in a specific branch. no branching for now, Slide doesn't support it (yet). From a flow (or more correctly from a rhino) perspective I´ve been thinking about some kind of scriptable node to make it possible to script certain tasks against the repository. This could of course be used from the flow-layer as well. Anyone else out there that´s been experimenting with this idea? I´m aware of the fact that these functionality requirements are not the first to consider when converging the repository concept in Cocoon, but I still think they can be useful. :) Definately, and JCR addresses all of these issues. But don't hold your breath to have these implemented soon. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
On 03.12.2003 03:42, Geoff Howard wrote: The bugzilla entry and this discussion: http://thread.gmane.org/gmane.text.xml.xerces-j.devel/475 indicate that this is now fixed in xerces cvs. I tried the solution they suggested as a workaround for 2.6 with no luck (though it may be that I don't know my way around XNI). So, do we 1) Ignore the bug until a later version of xerces is released? (the bug is that the build fails without an internet connection due to the dtd resolving in web.xml) 2) Roll back to 2.5? (I assume this would unfix other bugs?) 3) Use a dated version of xerces from cvs until their next release. WDYT? I tend for 2) as there was no particular need to update to 2.6. BTW there is also a similar situation for Xalan: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24457. What to do here? Joerg
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
On 03.12.2003 05:28, Andrew Savory wrote: I committed the changes. Note that I haven't verified all the samples and I was already getting some weird caching errors. Logging in should now work, I'll see what I can do about the other issues in the following days. It seems cocoon no longer runs with the recent slide changes (at least, that's the only thing I can pinpoint as being different in my cvs update). I get the following exception. The only thing in cocoon using javax.transaction appears to be slide. I'll keep digging and try and find out the cause, but if someone wants to get there before me, feel free ;-) Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at Loader.invokeMain(Unknown Source) at Loader.run(Unknown Source) at Loader.main(Unknown Source) Caused by: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction When does this happen? At compile time there is a mock class, furthermore you have a NoClassDefFoundError, that means as much as the class was there, but is no longer. At Cocoon deploy/start time? This would be really bad. It would be the second block not working by default. Or at runtime? Then it's up to you. The jta.jar is missing. There is also a note in the slide samples. Joerg
Re: Slide repository
On 02.12.2003 17:46, Stefano Mazzocchi wrote: I'm looking into the Slide block ATM and want to rename the package from o.a.c.components.repository to o.a.c.components.slide in order to avoid collision with the repository block. Any objections? I'm also renaming Repository.java to SlideRepository.java and adding the two public methods the service is to expose in order to fix http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24964 . +1, if not already you might want to mark the block as alpha Indeed Slide block is already marked as unstable. Joerg
Re: [RT] Converging the repository concept in cocoon
Stefano Mazzocchi wrote: [...] Well, yeah. I thought JCR was supposed to be this Repository.java? Why not just use that? Do we really need another layer? I think so, yes. JCR is incredibly powerful, but exactly because of this power, it feels a little low level. JCR is sort of a virtual hypergranular file system with multidimensions. Think of it as a persistent DOM with enhanced serializing and query functionalities. I think you will always need a sort of application oriented API on top of JCR... just like you need business objects on top of a relational database. On lenya-dev there are some discussions about switching from java.io repository access to an abstract repository API. We considered JCR, but if there will be another application-oriented API for Cocoon above JCR in any case, this would certainly make things easier. From the Lenya point of view, I think it would look like +-+ | Complex Lenya CMS operations| +-+ | Lenya CMS API | +-+ | Cocoon repository API | +-+ | Whatever repository (e.g., JCR) | +-+ Do you think it would make sense to consider Lenya interests when designing this application-oriented API? -- Andreas
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
Shoot, I'll have a better look later. Jta shouldn't have to be present until actually using the slide repository. The reason for the CNFE at startup now is because of the dynamic proxying that ECM does at initialization. Regards, Unico -Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 5:28 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Hi, On 2 Dec 2003, at 21:39, Unico Hommes wrote: I committed the changes. Note that I haven't verified all the samples and I was already getting some weird caching errors. Logging in should now work, I'll see what I can do about the other issues in the following days. It seems cocoon no longer runs with the recent slide changes (at least, that's the only thing I can pinpoint as being different in my cvs update). I get the following exception. The only thing in cocoon using javax.transaction appears to be slide. I'll keep digging and try and find out the cause, but if someone wants to get there before me, feel free ;-) Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at Loader.invokeMain(Unknown Source) at Loader.run(Unknown Source) at Loader.main(Unknown Source) Caused by: java.lang.NoClassDefFoundError: javax/transaction/UserTransaction at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader. java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:250) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:198) at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:171) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1627) at java.lang.Class.privateGetPublicMethods(Class.java:1655) at java.lang.Class.getMethods(Class.java:815) at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:173) at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:74) at java.lang.reflect.Proxy.getProxyClass(Proxy.java:472) at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:552) at org.apache.avalon.excalibur.component.ComponentProxyGenerator. getCompati bleProxy(ComponentProxyGenerator.java:135) at org.apache.avalon.excalibur.component.DefaultComponentFactory. newInstanc e(DefaultComponentFactory.java:334) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandl er.initial ize(ThreadSafeComponentHandler.java:143) at org.apache.avalon.excalibur.component.ExcaliburComponentManage r.initiali ze(ExcaliburComponentManager.java:556) at org.apache.cocoon.components.CocoonComponentManager.initialize (CocoonCom ponentManager.java:547) at org.apache.avalon.framework.container.ContainerUtil.initialize (Container Util.java:282) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:340) at org.apache.avalon.framework.container.ContainerUtil.initialize (Container Util.java:282) at org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonSer vlet.java: 1369) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:514) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:219) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(Se rvletHandl er.java:445) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServ lets(WebAp plicationHandler.java:150) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebAppli cationCont ext.java:449) at org.mortbay.http.HttpServer.start(HttpServer.java:663) at org.mortbay.jetty.Server.main(Server.java:429) ... 7 more Cheers, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance:
Re: CocoonForms server sizing?
On 03.12.2003 10:01, Leszek Gawron wrote: Hi Tim, I am working on a big project using woody (oops CocoonForms) with around 1600 forms. We will probably run some benchmarks to get the sizing info and I will let you know once we get them done. We however do not know enough about tunning cocoon, apart from using resource pooling for components set in the sitemap. Is there other pertinent information that we should know? yes, enable stylesheet caching (use-store=true in the cocoon.xconf) why isn't this a default setting ? Because a long time ago there was a memory leak with this option in Xalan. In the meantime Xalan became much more stable, but no one had the time to test the feature in real life again. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
Hi, On 3 Dec 2003, at 11:18, Joerg Heinicke wrote: When does this happen? At compile time there is a mock class, furthermore you have a NoClassDefFoundError, that means as much as the class was there, but is no longer. At Cocoon deploy/start time? This would be really bad. It would be the second block not working by default. Or at runtime? Then it's up to you. The jta.jar is missing. There is also a note in the slide samples. It's at startup. Basically, Cocoon and Jetty fail to start. I've disabled slide in local.blocks.properties and Cocoon starts again. I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar - is this something that should be added to the slide lib directory in CVS? Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 12:26 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Hi, On 3 Dec 2003, at 11:18, Joerg Heinicke wrote: When does this happen? At compile time there is a mock class, furthermore you have a NoClassDefFoundError, that means as much as the class was there, but is no longer. At Cocoon deploy/start time? This would be really bad. It would be the second block not working by default. Or at runtime? Then it's up to you. The jta.jar is missing. There is also a note in the slide samples. It's at startup. Basically, Cocoon and Jetty fail to start. I've disabled slide in local.blocks.properties and Cocoon starts again. I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar - is this something that should be added to the slide lib directory in CVS? Well we can't for legal reasons. Maybe we should just copy the mock classes to the webapp classpath. Anybody know if that is legal? Unico
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
OK, I found a simpler solution. I let SlideRepository simply implement Component so that ECM won't generate a proxy for it. This would probably also have fixed the previous bug. Cocoon should startup normally now. Unico -Original Message- From: Unico Hommes Sent: woensdag 3 december 2003 12:30 To: [EMAIL PROTECTED] Subject: RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java -Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 12:26 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Hi, On 3 Dec 2003, at 11:18, Joerg Heinicke wrote: When does this happen? At compile time there is a mock class, furthermore you have a NoClassDefFoundError, that means as much as the class was there, but is no longer. At Cocoon deploy/start time? This would be really bad. It would be the second block not working by default. Or at runtime? Then it's up to you. The jta.jar is missing. There is also a note in the slide samples. It's at startup. Basically, Cocoon and Jetty fail to start. I've disabled slide in local.blocks.properties and Cocoon starts again. I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar - is this something that should be added to the slide lib directory in CVS? Well we can't for legal reasons. Maybe we should just copy the mock classes to the webapp classpath. Anybody know if that is legal? Unico
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
On Wed, 3 Dec 2003, Unico Hommes wrote: -Original Message- From: Andrew Savory [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 12:26 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Hi, On 3 Dec 2003, at 11:18, Joerg Heinicke wrote: When does this happen? At compile time there is a mock class, furthermore you have a NoClassDefFoundError, that means as much as the class was there, but is no longer. At Cocoon deploy/start time? This would be really bad. It would be the second block not working by default. Or at runtime? Then it's up to you. The jta.jar is missing. There is also a note in the slide samples. It's at startup. Basically, Cocoon and Jetty fail to start. I've disabled slide in local.blocks.properties and Cocoon starts again. I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar i have found a jta.jar in tomcat\common\lib tomcat 4.1.24 btw in slide samples usernames and passwords for test are invalide? --stavro - is this something that should be added to the slide lib directory in CVS? Well we can't for legal reasons. Maybe we should just copy the mock classes to the webapp classpath. Anybody know if that is legal? Unico
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 13:10 To: [EMAIL PROTECTED] Subject: RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java ... I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar i have found a jta.jar in tomcat\common\lib tomcat 4.1.24 btw in slide samples usernames and passwords for test are invalide? No, root/root and john/john should work. Unico
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
Joerg Heinicke wrote: ... This would be really bad. It would be the second block not working by default. What's the other? Geoff
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 13:35 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Joerg Heinicke wrote: ... This would be really bad. It would be the second block not working by default. What's the other? I am thinking JDO. What's the reason for this? Unico
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
Unico Hommes wrote: I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar - is this something that should be added to the slide lib directory in CVS? Well we can't for legal reasons. Maybe we should just copy the mock classes to the webapp classpath. Anybody know if that is legal? Well, how is Tomcat doing. IIRC its distribution comes with a jta.jar inside. Can't we use that? Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: Unico Hommes Sent: woensdag 3 december 2003 13:37 To: [EMAIL PROTECTED] Subject: RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 13:35 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java Joerg Heinicke wrote: ... This would be really bad. It would be the second block not working by default. What's the other? I am thinking JDO. What's the reason for this? Never mind I found it. This one seems unavoidable. Still I don't like the fact that it is excluded by default. It means that I need to edit the blocks.properties in order to include ojb block. I think we need a way to overide excludes (by explicit includes in local.blocks.properties) WDYT? Unico
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
On 03.12.2003 13:10, [EMAIL PROTECTED] wrote: I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar i have found a jta.jar in tomcat\common\lib tomcat 4.1.24 My Tomcat 4.1.24 does not include a jta-***.jar. But if it's only a jta-spec.jar I guess it's similar to the servlet.jar, which we can include too. Joerg
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
On 03.12.2003 13:54, Unico Hommes wrote: I am thinking JDO. What's the reason for this? Never mind I found it. This one seems unavoidable. Still I don't like the fact that it is excluded by default. It means that I need to edit the blocks.properties in order to include ojb block. I think we need a way to overide excludes (by explicit includes in local.blocks.properties) WDYT? I'm not that familiar with Java or the Avalon lifecycles, but here is my analysis from http://wiki.cocoondev.org/Wiki.jsp?page=FirstFridayDecember2003: Make it possible to include also the OJB block by default without breaking Cocoon. This is a really important issue as it breaks our suggested build system workflow using local.blocks.properties! You can not include blocks when they are excluded in blocks.properties. AFAIU the reason for the problem is factory = new OjbStorePMF(); in the initialize() method in JdoPMFImpl.java. Isn't it possible to do lazy initializing when accessing factory the first time? I guess this has to be done in getPersistenceManager(). Is the lazy initializing doable? Joerg
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 14:13 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java On 03.12.2003 13:54, Unico Hommes wrote: I am thinking JDO. What's the reason for this? Never mind I found it. This one seems unavoidable. Still I don't like the fact that it is excluded by default. It means that I need to edit the blocks.properties in order to include ojb block. I think we need a way to overide excludes (by explicit includes in local.blocks.properties) WDYT? I'm not that familiar with Java or the Avalon lifecycles, but here is my analysis from http://wiki.cocoondev.org/Wiki.jsp?page=FirstFridayDecember2003: Make it possible to include also the OJB block by default without breaking Cocoon. This is a really important issue as it breaks our suggested build system workflow using local.blocks.properties! You can not include blocks when they are excluded in blocks.properties. AFAIU the reason for the problem is factory = new OjbStorePMF(); in the initialize() method in JdoPMFImpl.java. Isn't it possible to do lazy initializing when accessing factory the first time? I guess this has to be done in getPersistenceManager(). Yes, you are right. I got it working now. I had to change the factory instance variable's type to Object but it works. I hope this will also work for other JVM's than the one I tested it on. Should I commit it? Unico
Re: cvs commit: cocoon-2.1/lib jars.xml
On 03.12.2003 15:38, [EMAIL PROTECTED] wrote: unico 2003/12/03 06:38:47 Modified:lib jars.xml Log: Grrr! typo -libslide/lib/jdom-b10-dev-20031322.jar/lib +libslide/lib/jdom-b10-dev-20030322.jar/lib Unfortunately not only in jars.xml, but also at the JARs name itself. Joerg
Re: Linotype and RealPathModule
On 02.12.2003 12:17, Stefano Mazzocchi wrote: From a logical view the new behaviour of Jetty makes sense, at least for consistency: / D:\cocoon-2.1\build\webapp /images D:\cocoon-2.1\build\webapp\images /WEB-INFD:\cocoon-2.1\build\webapp\WEB-INF while it was D:\cocoon-2.1\build\webapp\ until now. that's probably why they fixed it. Shall we remove all trailing path separators? what is the behavior of tomcat? that is considered the reference implementation. Unfortunately D:\cocoon-2.1\build\webapp\. So it's more a simple root + accessor: root = D:\cocoon-2.1\build\webapp accessorvalue / D:\cocoon-2.1\build\webapp\ /imagesD:\cocoon-2.1\build\webapp\images /WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF Hmm, also not that illogical. I suggest to always remove the trailing path separator in the RealPathModule. Any comments? Joerg
Re: cvs commit: cocoon-2.1/src/blocks/slide/lib jdom-b10-dev-20030322.jar
On 03.12.2003 15:38, [EMAIL PROTECTED] wrote: Added: src/blocks/slide/lib jdom-b10-dev-20030322.jar Log: Grrr! typo It needed some warm-ups, but thanks for solving the issue ;-) Joerg
Re: CocoonForms simple-repeater binding sample?
--- Timothy Larson [EMAIL PROTECTED] wrote: Does anybody have a working sample of a simple-repeater binding? I am trying to adapt the binding to work with (you guessed it) class, new, struct, and union, but I am having trouble getting the simple-repeater binding working. More information: The regular repeater binding works for me, but the simple-repeater throws an exception about the factory not being set on the jxpath context. !-- Regular repeater binding: works -- wb:repeater id=contacts parent-path=contacts row-path=contact unique-row-id=id unique-path=@id wb:on-bind wb:value id=sample path=name/ /wb:on-bind /wb:repeater !-- Simple repeater binding: does not work -- wb:simple-repeater id=contacts parent-path=contacts row-path=contact wb:value id=sample path=name/ /wb:simple-repeater Exception: cause: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1]; Factory is not set on the JXPathContext - cannot create path: /wd:form[1]/wd:widgets[1]/contacts[1] --- Interesting part of exception chain stacktrace: Original Exception: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1]; Factory is not set on the JXPathContext - cannot create path: /wd:form[1]/wd:widgets[1]/contacts[1] at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420) at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397) at org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149) at org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108) at org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107) at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119) at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) --- Interesting part of stacktrace: Caused by: org.apache.commons.jxpath.JXPathException: Exception trying to create xpath contact[1]; Factory is not set on the JXPathContext - cannot create path: /wd:form[1]/wd:widgets[1]/contacts[1] at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:420) at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.createPath(JXPathContextReferenceImpl.java:397) at org.apache.cocoon.woody.binding.SimpleRepeaterJXPathBinding.saveFormToModel(SimpleRepeaterJXPathBinding.java:149) at org.apache.cocoon.woody.binding.ComposedJXPathBindingBase.saveFormToModel(ComposedJXPathBindingBase.java:108) at org.apache.cocoon.woody.binding.ContextJXPathBinding.saveFormToModel(ContextJXPathBinding.java:107) at org.apache.cocoon.woody.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:119) at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) --Tim Larson __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
On 03.12.2003 14:48, Unico Hommes wrote: I am thinking JDO. What's the reason for this? I'm not that familiar with Java or the Avalon lifecycles, but here is my analysis from http://wiki.cocoondev.org/Wiki.jsp?page=FirstFridayDecember2003: Make it possible to include also the OJB block by default without breaking Cocoon. This is a really important issue as it breaks our suggested build system workflow using local.blocks.properties! You can not include blocks when they are excluded in blocks.properties. AFAIU the reason for the problem is factory = new OjbStorePMF(); in the initialize() method in JdoPMFImpl.java. Isn't it possible to do lazy initializing when accessing factory the first time? I guess this has to be done in getPersistenceManager(). Yes, you are right. I got it working now. I had to change the factory instance variable's type to Object but it works. I hope this will also work for other JVM's than the one I tested it on. Should I commit it? Why is the change to Object needed? Is this class instantiated on start up even if it's not Initializable? Everything that's better than now should be committed. What are the potential issues with other JVMs? Do you cast the Object to the PMFactory? What do the other people think? Joerg
RE: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/source/impl SlideSourceFactory.java
-Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 16:21 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/ source/impl SlideSourceFactory.java On 03.12.2003 14:48, Unico Hommes wrote: I am thinking JDO. What's the reason for this? I'm not that familiar with Java or the Avalon lifecycles, but here is my analysis from http://wiki.cocoondev.org/Wiki.jsp?page=FirstFridayDecember2003: Make it possible to include also the OJB block by default without breaking Cocoon. This is a really important issue as it breaks our suggested build system workflow using local.blocks.properties! You can not include blocks when they are excluded in blocks.properties. AFAIU the reason for the problem is factory = new OjbStorePMF(); in the initialize() method in JdoPMFImpl.java. Isn't it possible to do lazy initializing when accessing factory the first time? I guess this has to be done in getPersistenceManager(). Yes, you are right. I got it working now. I had to change the factory instance variable's type to Object but it works. I hope this will also work for other JVM's than the one I tested it on. Should I commit it? Why is the change to Object needed? Is this class instantiated on start up even if it's not Initializable? Yes, that's ECM creating an instance and going through the static lifecycle stages. Everything that's better than now should be committed. What are the potential issues with other JVMs? I was concerned about the method codePersistentManager getPersistenceManager();/code. If JVM's are allowed to resolve all of class's symbolic references during the linking process, this might result in an exception. I looked at the JVM specification with a collegue and found the following (http://java.sun.com/docs/books/vmspec/html/Concepts.doc.html#19042): Resolution is the process of checking symbolic references from Terminator to other classes and interfaces, by loading the other classes and interfaces that are mentioned and checking that the references are correct. The resolution step is optional at the time of initial linkage. An implementation may resolve a symbolic reference from a class or interface that is being linked very early, even to the point of resolving all symbolic references from the classes and interfaces that are further referenced, recursively. (This resolution may result in errors from further loading and linking steps.) This implementation choice represents one extreme and is similar to the kind of static linkage that has been done for many years in simple implementations of the C language. An implementation may instead choose to resolve a symbolic reference only when it is actively used; consistent use of this strategy for all symbolic references would represent the laziest form of resolution. In this case, if Terminator had several symbolic references to another class, the references might be resolved one at a time-perhaps not at all, if these references were never used during execution of the program. The only requirement on when resolution is performed is that any errors detected during resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error. In the static example implementation choice described earlier, loading and linking errors could occur before the program is executed if they involved a class or interface mentioned in the class Terminator or any of the further, recursively referenced classes and interfaces. In a system that implemented the laziest resolution, these errors would be thrown only when a symbolic reference is actively used. So I think this says that a JVM is allowed to raise an error upon codenew JdoPMFImpl();/code :-( Of course we could just comment out the JdoPMF component xconf declaration and require users to uncomment it when they want to use JDO :-) WDYT? Unico
RE: cvs commit: cocoon-2.1/src/blocks/slide/lib jdom-b10-dev-20030322.jar
-Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: woensdag 3 december 2003 16:16 To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/lib jdom-b10-dev-20030322.jar On 03.12.2003 15:38, [EMAIL PROTECTED] wrote: Added: src/blocks/slide/lib jdom-b10-dev-20030322.jar Log: Grrr! typo It needed some warm-ups, but thanks for solving the issue ;-) It did and thanks for your efforts on this as well ;-) Unico
[announce] cocoon graphic goodies
After receiving *7* private email for people asking me permissions to reuse the graphics in my GT2003 presentation, I decided to do a little effort myself and to make them available online. Find them, along with all my other whitepapers (including the AC2003 ones), at http://www.betaversion.org/~stefano/papers/ and, more specifically http://www.betaversion.org/~stefano/papers/gt2003/ where /pictures/ contain the high-res pictures /drawings/ contain the drawings, both in PDF format and .graffle format, to be used with OmniGraffle (the drawing tool that comes with MacOSX... yes, another *big* reason to switch: OmniGraffle is the best graph drawing tool ever). If you use those things, please, give back some credit. That's the only thing I ask. If you want to consider including them into the cocoon documentation *PLEASE DO*, you don't need to give me credits for that in that case. - o - For those OmniGraffle lovers, I created a stencil for cocoon sitemap drawing. Find it at http://www.betaversion.org/~stefano/software/cocoon/Sitemap.graffle download and double-click, this will open up a stancil pane for you to drag-drop into your drawings. It works with both 2.2 (the one that comes with osx) and 3.0.x (the latest release). Enjoy. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Converging the repository concept in cocoon
On 3 Dec 2003, at 12:14, Andreas Hartmann wrote: Stefano Mazzocchi wrote: [...] Well, yeah. I thought JCR was supposed to be this Repository.java? Why not just use that? Do we really need another layer? I think so, yes. JCR is incredibly powerful, but exactly because of this power, it feels a little low level. JCR is sort of a virtual hypergranular file system with multidimensions. Think of it as a persistent DOM with enhanced serializing and query functionalities. I think you will always need a sort of application oriented API on top of JCR... just like you need business objects on top of a relational database. On lenya-dev there are some discussions about switching from java.io repository access to an abstract repository API. We considered JCR, but if there will be another application-oriented API for Cocoon above JCR in any case, this would certainly make things easier. From the Lenya point of view, I think it would look like +-+ | Complex Lenya CMS operations| +-+ | Lenya CMS API | +-+ | Cocoon repository API | +-+ | Whatever repository (e.g., JCR) | +-+ Do you think it would make sense to consider Lenya interests when designing this application-oriented API? Most definately. It would solve me some issues with Doco as well. Can you list the functionality you need? don't write code, just things you need, then we'll get a bunch of them together and we'll write the easiest interfaces that meet those needs. Ok? - Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Tim Larson as Cocoon committer
On 3 Dec 2003, at 16:51, Timothy Larson wrote: My account is not setup yet, but I cannot wait any longer to say Thank You to everyone for voting me in and for the warm welcome. I enjoy working with all of you, so this should be a very positive development. I suppose a little introduction is in order. I am married and have three daughters. My main computer interest is in programming language research and design, which I have been doing in all of my spare time for the last 14 or so of my 29 years. My official training includes a bachelors degree in Computer Science with a Mathematics minor. I am currently employed as an analyst/programmer for the Auditor's Office of the City of Canton, Ohio, USA. My first project as a committer will be to develop CocoonForms into a full gui design tool for forms and reports. I expect this to progress much faster now that I am a commiter. Thank you again, Welcome to the party! :-) -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Tim Larson as Cocoon committer
On Wed, 2003-12-03 at 16:51, Timothy Larson wrote: My account is not setup yet, I just sent a message to jim to check about that CLA. but I cannot wait any longer to say Thank You to everyone for voting me in and for the warm welcome. I enjoy working with all of you, so this should be a very positive development. I suppose a little introduction is in order. I am married and have three daughters. My main computer interest is in programming language research and design, which I have been doing in all of my spare time for the last 14 or so of my 29 years. My official training includes a bachelors degree in Computer Science with a Mathematics minor. I am currently employed as an analyst/programmer for the Auditor's Office of the City of Canton, Ohio, USA. My first project as a committer will be to develop CocoonForms into a full gui design tool for forms and reports. I expect this to progress much faster now that I am a commiter. And yet another warm welcome. Hope I'll be able to keep up with all Woody developments ;-) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Load Balancing web applications with mod_proxy...
Pier Fumagalli wrote: snip what=awesome writeup/ Tomorrow we're going to talk about auto-failover! Thanks for listening... Pier (this page needs to be WikiFied, one day) Done and Done: http://wiki.cocoondev.org/Wiki.jsp?page=LoadBalancingWithModProxy Tony
Re: Load Balancing web applications with mod_proxy...
On 3/12/03 22:59, Tony Collen [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: snip what=awesome writeup/ Tomorrow we're going to talk about auto-failover! Thanks for listening... Pier (this page needs to be WikiFied, one day) Done and Done: http://wiki.cocoondev.org/Wiki.jsp?page=LoadBalancingWithModProxy There was a reason why I posted it here, even if slightly off-topic :-) Thanks Tony, really appreciated... Pier
Re: Load Balancing web applications with mod_proxy...
Pier Fumagalli wrote: On 3/12/03 22:59, Tony Collen [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: snip what=awesome writeup/ Tomorrow we're going to talk about auto-failover! Thanks for listening... Pier (this page needs to be WikiFied, one day) Done and Done: http://wiki.cocoondev.org/Wiki.jsp?page=LoadBalancingWithModProxy There was a reason why I posted it here, even if slightly off-topic :-) No way, it's totally on-topic.. as a matter of fact, the original ApacheModProxy article got me linking Jetty and Apache together in the first place... I even have a nice solution for hosting virtualhosts from the same instance of Cocoon, using subsitemaps. Thanks Tony, really appreciated... Pier Regards, Tony
Re: Load Balancing web applications with mod_proxy...
On 4/12/03 0:31, Tony Collen [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: On 3/12/03 22:59, Tony Collen [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: snip what=awesome writeup/ Tomorrow we're going to talk about auto-failover! Thanks for listening... Pier (this page needs to be WikiFied, one day) Done and Done: http://wiki.cocoondev.org/Wiki.jsp?page=LoadBalancingWithModProxy There was a reason why I posted it here, even if slightly off-topic :-) No way, it's totally on-topic.. as a matter of fact, the original ApacheModProxy article got me linking Jetty and Apache together in the first place... I even have a nice solution for hosting virtualhosts from the same instance of Cocoon, using subsitemaps. Dude, I need that badly! :-) At VNU we're building an app requiring skinning on a per-virtualhost basis, but I want to share the caches between all the different virtualhosts. Basically, all that changes between the different virtual hosts are the different stylesheets, but the source documents are the same, and I cannot force every virtual host to use a some-sort of uniqueness in the URIs. If you can provide a snippet of that sub-sitemaps system, I'll be grateful! Pier
Re: Load Balancing web applications with mod_proxy...
Pier Fumagalli wrote: Dude, I need that badly! :-) At VNU we're building an app requiring skinning on a per-virtualhost basis, but I want to share the caches between all the different virtualhosts. Basically, all that changes between the different virtual hosts are the different stylesheets, but the source documents are the same, and I cannot force every virtual host to use a some-sort of uniqueness in the URIs. If you can provide a snippet of that sub-sitemaps system, I'll be grateful! It's easy: for each vhost, create whatever subsitemaps you want in Cocoon, then in each vhost config in httpd.conf, do something like: --- VirtualHost 111.222.333.444 ServerNameexample.com ServerAlias www.example.com ServerAdmin [EMAIL PROTECTED] DocumentRoot /usr/local/vhosts/example.com ProxyPass /static/ ! ProxyPass / http://localhost:/cocoon/example/ ProxyPassReverse / http://localhost:/cocoon/example/ /VirtualHost --- I'm using this on openWeather.com and it works perfectly. My dream is to have all of my virtualhosts hosted this way, but that might never happen :^) Pier Regards, Tony, pondering httpd.conf's fake XML
Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms simple-repeater binding sample?)
--- Marc Portier [EMAIL PROTECTED] wrote: Timothy, the rudimentary dox (see wiki) on the simple-repeater-binding are explaining this: It is currently only supporting binding back to XML (so I suspect that you were testing versus a java beans backend model here?) I was attempting and failing to bind to an XML document. The load worked, but the save gave the exception. we briefly discussed this recently (and I was getting into doing it, but am caught up on a local conference here the next few days) see this thread: http://marc.theaimsgroup.com/?t=10697645531r=1w=2 the idea would be to have a similar entry for on-insert-row nested in the simple-repeater-binding as borrowed from the classic repeater-binding? While waiting for a response about the simple repeater binding, I modified the main repeater binding to support binding without a unique id. You just leave off the unique-row-id and unique-path attributes, and it acts like a simple repeater binding but with the on-* elements added. Is this near what you are thinking? If it is, I will post it when I get back to work tomorrow. in fact I started thinking about this some more first (also based on some private mails with Jeremy who was so kind to let me in on some more hibernate details and issues in his current project) some (random order) observations/suggestions on repeater binding as is now: - repeater-bindings have no @readonly to shut down the save() operation like the field-binding has it. - in fact it also struck me that the @readonly concept only allows us to choose between two modes of operation : 1/ do load AND save 2/ do only load. Maybe we should provide a generic attribute on all bindings that looks like @direction and can hold load|save|both (probably even implement this at the level of the abstract base class?) +1 I was thinking this also. - confusion between simple and classic repeater binding... I understand that we have two strategies that both have their special uses cases, but I would like to have a more syntactic similarities between both to lower the usage confusion (and switching effort) ... in fact maybe we should even go for a single wb: element-name for both and switch between both by using some @strategy, @flavour or @type Please see the repeater modification mentioned above. - in any case we should remove the XML only limitation from the simple repeater, since it's somewhat fighting with the principle of least surprise, no? +1 I do not have a use case myself yet, but I faintly remember someone else may have presented one? oh, I also thought some about this: http://marc.theaimsgroup.com/?t=10703520012r=1w=2 and currently have a patch on HD that is introducing an extra attribute row-path-insert for the classic (not-simple) repeater-binding that is used for depicting where the rows to be inserted should go in... (in stead of just reusing the @row-path for that purpose) Not sure I understand this yet. Would you expand on this? Explain it in different words and I might catch the idea. but maybe we should take a more holistic view on things and maybe first discuss a broader binding-syntax redo starting from above suggestions? (by the way: any suggestions from users having a more usability opinion is welcome, maybe I was (we are) a tad too much focussed on processing the thing when we defined the original semantics of the file?) in any case I hope we can synchronize our updating efforts here? wdot? I think so. PS: sorry for lagging behind on your new widget-types, but wouldn't they require separate and specific binding-types rather then fixing the repeater-binding to work on them as well? I *am* creating new specific binding types, but I also have some repeater needs that are not satified yet when using the new binding types to create the form design gui's binding. I need the repeater to load and save items that are not wrapped in a commonly named element. The current repeater binding can deal with this: contacts contact nameJohn Doe/name /contact contact nameJohn Doe's twin/name /contact /contacts But it cannot handle this: wt:repeater-widget wt:widget-label id=sample-field/ wt:widget id=sample-field/ /wt:repeater-widget because the row elements wt:widget-label and wt:widget differ and are not each wrapped in a commonly named row element like contact in the first example. I tried to continue my modifications to the repeater binding to support this, but it is difficult due to the semantics of the path and context calls in jxpath. Loading works now, but if you have any ideas how to do the saving without invasive changes to the existing bindings I would jump for joy. I just want each bound vidget to be appended as the last child of the containing element. I almost have a very inefficent method working. Thanks for your consideration, --Tim Larson
Re: Load Balancing web applications with mod_proxy...
Le Mercredi, 3 déc 2003, à 23:47 Europe/Zurich, Pier Fumagalli a écrit : ...Simple, and easy... Great stuff! Thanks for sharing this. -Bertrand
