On 17.12.2004 15:44, [EMAIL PROTECTED] wrote:
that's what we decided in gent - see
http://wiki.apache.org/cocoon/22StabilizeCocoonForms
Oops, didn't look at that before. OTOH it might be me, but I cannot figure
out where it says that Form.js v1 is decided on.
I know I've seen a discussion once on
On 10.12.2004 15:13, Thomas Alexnat wrote:
I also think, that this behaviour is a bug. To me it renders the usage
of the cocoon view concept absolutely useless. My major point is, that
is, that I cannot use the cocoon views to view my current matcher in
XML. If I try to do that, everytime I
On 08.12.2004 15:58, [EMAIL PROTECTED] wrote:
Author: lgawron
Date: Wed Dec 8 06:58:35 2004
New Revision: 111272
URL: http://svn.apache.org/viewcvs?view=revrev=111272
Log:
implement 2 modes of work for continuations manager:
- standard, as it was up till now
- secure in which continuations are
On 08.12.2004 11:38, Sylvain Wallez wrote:
Ok, so cocoon:raw behaves exaclty as the regular cocoon: regarding
views.
QUESTION
What could be the best practice, if I want to look at the XML of a
certain pipeline, before its transformation is being called? All I
need is a good debugger
On 08.12.2004 21:18, Leszek Gawron wrote:
- continuations-manager logger=flow.manager time-to-live=360
+ continuations-manager logger=flow.manager
time-to-live=360 +
session-bound-continuations=false +
On 28.11.2004 10:55, [EMAIL PROTECTED] wrote:
Guys,
Is the version in the trunk supposed to be a fully working version? I
checked it out to do some checking on the HTMLarea sample but ran into some
errors. Net result: cocoon servlet stops with:
Caused by: java.lang.NoClassDefFoundError:
In our CForms Action.java [1] there is a comment about an IE bug with
appending 'x' and 'y' to the name of the input field when it is of type
image:
Special workaround an IE bug for input type=image name=foo :
in that case, IE only sends foo.x and foo.y and not foo whereas
standards-compliant
On 28.11.2004 15:59, Sylvain Wallez wrote:
In our CForms Action.java [1] there is a comment about an IE bug with
appending 'x' and 'y' to the name of the input field when it is of
type image:
Special workaround an IE bug for input type=image name=foo :
in that case, IE only sends foo.x and
On 28.11.2004 17:00, [EMAIL PROTECTED] wrote:
However, I did come across a compile error (see bugzilla #32412).
Makes at least more sense and is mostly easier to solve. Seems like a
missing dependency.
Joerg
On 22.11.2004 14:41, Sylvain Wallez wrote:
What you describe here comes again to an additional output state ...
and makes the output widget obsolete? We had this in mind since a long
time ... e.g. at http://marc.theaimsgroup.com/?t=10830131522r=1w=4.
Joerg
On 15.11.2004 13:50, Bart Molenkamp wrote:
I have a fd:output widget, with an enum as datatype. When showing the
widget, it doesn't place i18n:text tags around the enum value. When I
change the fd:output to fd:field, and add fi:styling
type=hidden/ it does surround the enum values with the
On 26.11.2004 14:00, Sylvain Wallez wrote:
What you describe here comes again to an additional output state ...
and makes the output widget obsolete? We had this in mind since a long
time ... e.g. at http://marc.theaimsgroup.com/?t=10830131522r=1w=4.
Mmmh... for sure that obsoletes the
On 23.11.2004 12:21, Jeremy Quinn wrote:
It looks like Joerg has already done this.
Yeah, the commit was exactly in the same minute you wrote the mail
promising the fix:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110113620718082w=4
On 23.11.2004 17:14, Vadim Gritsenko wrote:
IMHO, adding single line would be simplier:
if (uri == null) uri = ;
And it can not be null anyway, so logging a warning is an option.
-if ((uri == null || this.extractURI.equals(uri))
this.extractElement.equals(loc)) {
+if
On 17.11.2004 00:59, Antonio Gallardo wrote:
To me is not working the OO Impress sample:
http://localhost:/samples/hello-world/hello.sxi
I am using OOo version: 1.1.2 on Linux Fedora Core 3.
Can someone else confirm this?
http://issues.apache.org/bugzilla/show_bug.cgi?id=29480
Joerg
On 17.11.2004 17:29, Eirik Bjørsnøs wrote:
Is there any possibility for this to be included in 2.1.6? (It's just a
small fix, and shouldn't break existing code, but then again, smarter
people than me have said that before and got burned :-)
I don't think so as we are already in code freeze phase
On 17.11.2004 22:32, Carsten Ziegeler wrote:
Please cast your votes for releasing the current SVN of 2.1.x as
2.1.6. The vote will end on friday morning.
If this vote passes, I will assemble the new release on friday morning
based on the SVN of that date! So, please, only commit things that
I'm getting a ClassCastException when using the JXTemplateGenerator and passing
bizdata to it:
java.lang.ClassCastException
at org.apache.cocoon.components.flow.javascript.ScriptablePropertyHandler
.getPropertyNames(ScriptablePropertyHandler.java:77)
at
On 10.11.2004 12:15, Daniel Fagerstrom wrote:
AFAICS we don't need the formatCache in a convertion component, each
convertor will only be needed to be defined once. The
generateSaxFragment is also somewhat specific for my taste, I wonder if
that is part of the convertion concern. Furthermore it
On 11.11.2004 19:43, Daniel Fagerstrom wrote:
I also found http://wiki.apache.org/cocoon/XFormsInCocoon.
Read it and found following comment:
(Side note: The Web Service Proxy in Cocoon 2.1 depends on XMLForms, but
the samples for the proxy in 2.1.5.1 did not work for me. I don't know
if that is
On 12.11.2004 02:56, [EMAIL PROTECTED] wrote:
Author: vgritsenko
Date: Thu Nov 11 17:56:24 2004
New Revision: 57484
Modified:
cocoon/branches/BRANCH_2_1_X/lib/jars.xml
Log:
event is gone
vs.
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=110016446216689w=4
Is event impl needed or not?
Joerg
On 09.11.2004 16:07, Reinhard Poetz wrote:
I'm interested in it because I write my diploma thesis exactly about
this topic at the moment. I come to the conclusion that MVC more or
less can not work - and especially templates! I switched back to a
similar solution to the mentioned Lofex one
On 10.11.2004 17:09, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-11-10 16:09 ---
I'm in favour of:
2. Revert the jar and live with the bug in 2.1.x.
Because this bug was already present in 2.1.5, it can live in 2.1.6 as well.
Those who need this bug fixed
On 10.11.2004 17:09, Ralph Goers wrote:
Why are these blocks even in 2.2? They are excluded from the build
but
they are deprecated in 2.1 and have replacements.
Can they be removed?
I would probably leave them in in 2.1 series, but +1 for removing in 2.2.
Time
for a vote?
Sure.
I'm +1 for
On 10.11.2004 21:04, Antonio Gallardo wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-11-10 16:09
---
I'm in favour of:
2. Revert the jar and live with the bug in 2.1.x.
Because this bug was already present in 2.1.5, it can live in 2.1.6 as
well.
Those who need this bug fixed
On 09.11.2004 13:43, [EMAIL PROTECTED] wrote:
Modified:
cocoon/branches/BRANCH_2_1_X/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/context/RequestSessionContext.java
Log:
Quick workaround for request attributes whose name is not suitable for an XML
element name
@@ -281,9
On 09.11.2004 19:26, Sylvain Wallez wrote:
Log:
Quick workaround for request attributes whose name is not suitable
for an XML element name
...
+System.err.println(Cannot create XML element with
name ' + attrName + ' : + de.getMessage());
Yeah, I know, that's ugly. But
Author: antonio
Date: Mon Nov 8 01:54:09 2004
New Revision: 56914
Modified:
cocoon/branches/BRANCH_2_1_X/gump.xml
Log:
Define ojb block samples dependencies
Modified: cocoon/branches/BRANCH_2_1_X/gump.xml
==
---
On 08.11.2004 18:46, Ralph Goers wrote:
As for ojb, I seem to recall seeing a message saying that the jar that
block depends on requires jdk 1.4. I could be wrong though.
I can't remember that OJB itself needs 1.4. Maybe it was just compiled
with 1.4 and now fails running with 1.3?
Joerg
On 07.11.2004 22:22, Ralph Goers wrote:
That's the way we did it until now too. But all with only one view.
What's your experience when supporting your multiple views? An
additional needed field in one of your forms should result in editing
so many views or isn't it?
I'm not sure I understand
On 08.11.2004 14:10, Leszek Gawron wrote:
Imagine you have a bunch of java.util.Calendar properties all around
your JavaBeans. Now in most of the views you want to render them
according to a specific pattern.
Now there are some special cases when you want those dates to get
additional styling
On 08.11.2004 21:24, Ralph Goers wrote:
Sample: You have an object, that can be viewed and edited. This object
will be extended by adding a further required field when editing it and
would be of interest when viewing it. How much effort do you need to
update all the views that reference it? To
On 05.11.2004 11:19, Leszek Gawron wrote:
Terence Parr sugests that test like $bloodPressure120 in the view
should be performed in the model and tested in the view like
!$bloodPressureOk. He even says that:
Even simple tests that make negative values red should be
computed in the model; the
On 07.11.2004 17:21, Leszek Gawron wrote:
Still this is very inconvenient if the model is built for you i.e.
object graph built by hibernate. I would have to make controller
dependant on view view wants to show. Right now I just pass one
entity to view and do not care if view asks for entity
On 07.11.2004 18:23, Ralph Goers wrote:
For web applications:
- the model is the first to be agreed upon/designed/implemented
- the model is the core of the application and most weight is shifted
in that direction
- the model is strongly typed, has a lot of constraints. Almost whole
model
On 03.11.2004 09:06, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
Mmmh... not sure, although you can prevent a widget from reading its
value from the request by setting it's state do disabled. This bug is
more likely to be fixed by having
On 03.11.2004 11:56, Sylvain Wallez wrote:
The problem is not in CForms, but in HTML: each form element (input,
button, etc) is added as a property of the form it belongs to. Problem
is that these new properties hide those that may already exist with the
same name on the form.
And a form
On 03.11.2004 11:51, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
Mmmh... not sure, although you can prevent a widget from reading its
value from the request by setting it's state do disabled. This bug
is more likely to be fixed by having
On 19.10.2004 18:42, Jorg Heymans wrote:
Is there a reason why the model is not updated after nodes are
added/removed to a repeater?
I have 2 frames, one with a repeater, the other with an applet. The
applet gets its data from the model and is refreshed using an on-load
event on the repeater
On 03.11.2004 00:21, Sylvain Wallez wrote:
As I told before I am not sure. I really want to see what the other
people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
Yes, I'm +1. Or +10, +100 and even +1000 :-)
On 03.11.2004 18:49, Sylvain Wallez wrote:
Don't know, as action is an attribute.
Though this part is not translated into English yet, the JS api of the
forms object:
http://en.selfhtml.org/javascript/objekte/forms.htm
The French are somewhat faster:
On 01.11.2004 09:20, Sylvain Wallez wrote:
I'd like to know if a fd:case for the union widget is still planned to
give more flexibility than the fd:struct or if there is another way to
give a matching expression to the fd:struct.
There were discussions about this [1] which unfortunately have
On 29.10.2004 13:07, Carsten Ziegeler wrote:
It's their own decision. Now in the end you can't prevent users
from doing so
But that's exactly what the document is about: *enforcing* separation
instead of *encourage*. StringTemplate claims to provide that.
Joerg
On 28.10.2004 17:04, Torsten Curdt wrote:
Folks please cast your votes for:
[+1] Leszek
[+1] Ralph
as Apache Cocoon committers.
Welcome!
Joerg
extend URLClassLoader or to restore a
normal ClassLoader.
Joerg
On 26.10.2004 23:12, Garrick Dasbach wrote:
Joerg,
I just ran into this same issue. Have you, or anyone else, found any
solution/workaround to this problem, short of no includes in form pages?
Garrick
Joerg Heinicke wrote
On 26.10.2004 15:11, Antonio Gallardo wrote:
Let's deprecate the PHP block for the remainder of our 2.1.X releases
and then dump it in 2.2. If people want to use PHP with Cocoon, the
best solution is to just use a FileGenerator and an http:// URL.
Seems we are alredy voting on that. Here is
On 21.10.2004 20:23, [EMAIL PROTECTED] wrote:
Author: reinhard
(add dreamteam application by Helma van der Linden (issue 31813)
Added: cocoon/trunk/src/blocks/forms/samples/dreamteam/sitemap.xmap
==
--- (empty file)
+++
On 18.10.2004 18:20, e-|vira wrote:
Hello all!
the first, my english is very very bad so i'm sorry if i don't to
explain very well.
I have a portlet with his sitemap file, XML input file how
'map:generate cocoon' and XSL output file how 'map:transform
cocoon'.
My idea is in my XSL file i check a
On 20.10.2004 10:17, Bertrand Delacretaz wrote:
Seems like we forgot about this one too? ;-)
One more reason to build a (Cocoon) form based page where people can
enter
information about their Cocoon site with a request for adding the link...
People could also enter their requests to be listed in
On 20.10.2004 20:07, Carsten Ziegeler wrote:
IMHO it is simply wrong to continue a script in a
sitemap where it hasn't been declared - and as soon as the flow script tries
to address relative resources it won't work anyway.
But how should binding a continuation to the sitemap solve the problem?
On 21.10.2004 00:13, Vadim Gritsenko wrote:
IMHO it is simply wrong to continue a script in a sitemap where it
hasn't been declared - and as soon as the flow script tries
to address relative resources it won't work anyway.
But how should binding a continuation to the sitemap solve the
problem?
On 19.10.2004 20:51, Stephan Coboos wrote:
What happens on the first one (directly xml output) if the user stops
the transfer by closing the browser?
When the XML is not buffered, it is streamed directly to the client.
Closing the browser prevents the server to write the data to the socket
(an
On 16.10.2004 07:31, JD Daniels wrote:
1.) I have started using SVN in my own projects and I really like it.
but I am a little confused about about what version of cocoon supports
java 1.5, and if that suport is available. Where is the main development
going on? I see as my choices:
On 16.10.2004 12:00, Bertrand Delacretaz wrote:
I'd just like to share this with you guys here, as I think it has made a
big difference to the project, and applying it to other grey areas of
Cocoon might help as well (I'm not thinking of any such grey area ATM,
but others might see some).
On 14.10.2004 12:28, Vadim Gritsenko wrote:
Hi,fop block developers:
I have checked fop block src and fop own src.
In fop serializer configuration ,user can use relative path and protocol like :
user-configcontext://fontsconfig.xml/user-config
but in fontsconfig.xml the font path is like
On 13.10.2004 23:24, [EMAIL PROTECTED] wrote:
IIRC this has been fixed some weeks/months ago. At least the current versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
On 13.10.2004 08:31, [EMAIL PROTECTED] wrote:
i am new in using Cocoon and have to implement an application in using
Cocoon and Soap (get data - an xml file - from a web servcie).
Now i am looking for a full example (sitemap, xsp, etc.) herefor to learn
more in usining cocoon.
Welcome, Dirk.
Can
On 14.10.2004 00:44, David Crossley wrote:
IIRC this has been fixed some weeks/months ago. At least the current versions of
the 2.1 branch and the trunk are correct, aren't they?
http://svn.apache.org/repos/asf/cocoon/trunk/build.sh
On 04.10.2004 15:34, Björn Voigt wrote:
Moin,
i use an upload-widget (cocoon-2.1.5) in my cforms,
but I need it once more, but I cant set the value to
null to reset it for reuse.
setValue is not implemented and throws an exception.
It allready possible to reset it? If not, Is it possible
that you
On 04.10.2004 16:47, Björn Voigt wrote:
Moin,
i use an upload-widget (cocoon-2.1.5) in my cforms,
but I need it once more, but I cant set the value to
null to reset it for reuse.
setValue is not implemented and throws an exception.
It allready possible to reset it? If not, Is it possible
that you
On 02.09.2004 20:08, Stephan Coboos wrote:
why it is not possible to use fb:on-bind/ aso. within
fb:simple-repeater/?. I need this repeater because I want to remove
all entries from the list and replace them by new values from the form.
Or is this behavior also possible with fb:repeater/?
On 02.09.2004 20:31, Stephan Coboos wrote:
But in the meantime what can I do to use the
on-insert-row feature like in the fb:repeater/ and the remove and
readd? Is there a way?
Unfortunately I never used the simple repeater, so I can't answer your
question.
Joerg
On 25.08.2004 18:05, Pier Fumagalli wrote:
[X] +1 take them out
Jörg
On 26.08.2004 09:57, Carsten Ziegeler wrote:
a) mark portal-fw as deprecated
+1
b) mark portal as stable
+1
Jörg
Hmm.. deprecated mean Hey man, go change you portal as it
will be removed in the future is this you want to signal?
Yes :( The portal-fw is a nice portal framework, but the code
is very very ugly (I know it 'cause I wrote it). The new
portal block is (apart from tools) a 100% replacement which
is
Don't mix the old CVS repos 2.1 and 2.2 and the new SVN repo and its
branches! When you have committed the changes to old 2.1 the changes are
in the main trunk, but not in the 2.1 branch obviously as it has started
from 2.1.5 release. Changes to old 2.2 are in the kernel branch.
Joerg
On
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent data values
view cannot
On 05.08.2004 16:39, Hunsberger, Peter wrote:
I added this to my forms-field-styling.xsl in the template for
fi:form-template:
xsl:if test=descendant::node()/fi:upload
xsl:attribute
name=enctypemultipart/form-data/xsl:attribute
/xsl:if
Good idea,
On 05.08.2004 10:53, Sylvain Wallez wrote:
I'm not very fond of it, since this needs to scan the whole tree below
the form-template, which might be large (if it contains lots of widgets
or large selection lists), combined with the fact that most forms don't
use uploads anyway. Just IMHO of course.
On 05.08.2004 17:39, Hunsberger, Peter wrote:
I suppose it may depend on the XSLT processor, but if you didn't
have to use the descendant axes this could be ok. Not knowing the
structure of the Cforms templates I don't know if you can avoid
descendant, but if it maps to a regular XHTML form then
On 04.08.2004 19:04, Mark Lundquist wrote:
I added this to my forms-field-styling.xsl in the template for
fi:form-template:
xsl:if test=descendant::node()/fi:upload
xsl:attribute
name=enctypemultipart/form-data/xsl:attribute
/xsl:if
Good idea, or bad?
On 01.08.2004 15:03, Antonio Gallardo wrote:
I had downloaded the nightly build cocoon-2.1_20040731161331. But what I
got after compiling was cocoon-2.2.0dev? Heahh? Is the snapshot
algorithm wrong?
Nope. After 2.1.5 release the version number was changed to 2.2-dev. I
know this is confusing a
On 01.08.2004 15:20, Reinhard Poetz wrote:
In order to summarize:
- whiteboard
...
- branches
...
- scratchpad (block)
...
WDOT?
+1
On 28.07.2004 02:40, Peter Brant wrote:
Thanks. That does work. I'll close the bug.
Thanks for confirmation ;-)
However, it's rather a pain in the neck to have to a specify a converter
(excuse me, convertor) for all the non-string form fields. A patch to fix
that is attached (should I open
On 23.07.2004 08:49, Carsten Ziegeler wrote:
I just updated from CVS and it seems that tools\bin\appendcp.bat
is now missing which creates some error messages during build
(on windows of course).
Is this file missing or has the script to be updated?
Also create-repository-jars.sh has been deleted:
Joerg Heinicke joerg.heinicke at gmx.de writes:
A question, though: how have you found all this? Do you have special
settings on your IDE (Eclipse?)
Yes, Eclipse shows them and I can fix them easily mostly using Quick
Fix. I can post the useful compiler settings on Tuesday.
A bit later
On 17.07.2004 21:16, Sylvain Wallez wrote:
Log:
clean up after the tree processor refactoring
Thanks Jörg!
A question, though: how have you found all this? Do you have special
settings on your IDE (Eclipse?)
Yes, Eclipse shows them and I can fix them easily mostly using Quick
Fix. I can post
On 18.07.2004 09:06, Colin Paul Adams wrote:
Ralph == Ralph Goers [EMAIL PROTECTED] writes:
Colin So, shall I raise a bug then?
Ralph I certainly would.
OK.
But before I do, I'd better be certain which version from CVS I'm
running.
I checked out anonymously a few weeks ago. I thought it
I have a form where for legal and natural persons different widgets have to be
presented. I implemented it using a union widget and storing the persontype on a
field with datatype ineger, the value is bound to a bean. To make this value
usable in the union's case widget it must be transformed into
On 12.07.2004 15:50, Jorg Heymans wrote:
Now in 2.1.x this does not work anymore, more specifically the
componentselector is not returned anymore by the servicemanager.
After a bit of introspection i changed it to
WrapperServiceSelector selector =
(WrapperServiceSelector)
On 07.07.2004 19:51, Pier Fumagalli wrote:
I agree with Jim... Although rolling 2.1.6 might be non trivial given
that noone created a new branch/repo for 2.2 and _a_lot_ of changes (in
libraries and related) have been committed since.
We decided to do lazy branching. Where is the problem using
On 07.07.2004 18:01, Vilya Harvey wrote:
With the Cocoon 2.1.5 release, the binding framework throws a
ClassCastException if you use anything other than an fb:value in the
fb:identity part of a repeater binding. Is this intentional behaviour,
or a bug?
It's a known feature ;-)
On 05.07.2004 15:03, Matthias Stöckel wrote:
Hi,
I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few
issues about JDK 1.3.1 compatibility.
- jakarta-bcel-20040329.jar, NoSuchMethodError if used with JavaFlow [1].
Are you sure it's the quoted StringBuffer problem? It might also
On 04.07.2004 12:58, Bruno Dumon wrote:
Something that doesn't sit entirely right for me is that one would
'artificially' create a Part. While technically possible, the definition
of a Part is that it is a file parsed from a http post.
Yes, that's a bit strange, but for the moment it works. I have
On 04.07.2004 16:35, [EMAIL PROTECTED] wrote:
1.3 +7 -5 cocoon-2.1/src/blocks/forms/samples/messages/FormsMessages_zh_CN.xml
-?xml version=1.0 encoding=UTF-8?
+?xml version=1.0 encoding=UTF-8?
!--
Copyright 1999-2004 The Apache Software Foundation
@@ -19,12 +19,14
On 02.07.2004 17:01, Terry Brick wrote:
Weird problem. I have a small test JSP that I'm accessing using
JspGenerator. It works fine if I hit it straight from the
browser (with a URL that matches pipeline in my sitemap) but it
fails if I call the exact same thing from my flow script using
Starting with the question: Does it make sense to process all sub bindings of a
UnionBinding?
At the moment the UnionBinding behaves just like a ContextBinding, all sub
bindings are processed. While the processing of a UnionWidget depends on the
caseWidget the same is not true for the binding.
Tim Larson tim at keow.org writes:
At the moment the UnionBinding behaves just like a ContextBinding, all sub
bindings are processed.
I do not have time to dig in the code right now, but this looks like a bug
(oversight) that needs fixed. Only the current case should be processed.
Jason Johnston jason.johnston at Intrado.com writes:
Maybe I'm not understanding your example, but shouldn't all those
fb:structs be wrapped in fb:cases with the same id? If I understand
correctly it's actually the fb:case binding that does conditional
processing of its subbindings; the
On 01.07.2004 10:32, Colin Paul Adams wrote:
You are really nagging on this issue, aren't you? ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=108862151322458w=4
Drip. Drip. Drip.
Look - a hollow's appeared in that stone! (no hole yet, though)
:)
I checked out all the samples - since everyone
On 01.07.2004 16:32, Joerg Heinicke wrote:
Maybe I'm not understanding your example, but shouldn't all those
fb:structs be wrapped in fb:cases with the same id? If I understand
correctly it's actually the fb:case binding that does conditional
processing of its subbindings; the fb:union binding
On 01.07.2004 20:44, Tim Larson wrote:
But it has another drawback: The model binding is now also load only
conditionally. What I need is to load the whole model but to save only
the one selected. For this I had to add this binding twice: once with
direction=load as direct child of union
On 26.06.2004 10:48, Stephan Coboos wrote:
the problem is a ClassCastException because the code was changed to use a
ServiceSelector, but the configuration uses a
ExtendedComponentSelector. I
Hello Volker,
is it solved in the actualy nightly build?
Carsten committed the fix one week ago.
On 30.06.2004 09:24, Carsten Ziegeler wrote:
As requested by Joerg, let's vote if we move to servlet spec 2.3
as the base for Cocoon. I think all important servlet engines
support this version, so this shouldn't really be a problem.
So, please cast your votes:
+1
Joerg
On 30.06.2004 16:31, Colin Paul Adams wrote:
Since some time yesterday afternoon, I am no longer getting notified
about updates to bugzilla #29854 (my own, or others).
Is this supposed to be the case?
The bugzilla mail service seems to be out of service. Normally this list
also gets the mails.
On 29.06.2004 18:55, Bruno Dumon wrote:
On Tue, 2004-06-29 at 18:17, Colin Paul Adams wrote:
Bruno == Bruno Dumon [EMAIL PROTECTED] writes:
Bruno How will you do this, generate all elements with
Bruno xsl:element?
Yes.
At least, only those whose parent is not an html/xhtml element.
So the
On 29.06.2004 17:16, Stephan Michels wrote:
Can you revert this change,
Done.
I need this method time to time.
Sorry.
Thanks, Stephan.
Joerg
On 29.06.2004 14:14, Carsten Ziegeler wrote:
Currently we compile against the servlet spec 2.2, but also have
the 2.3 version in our set of jars for the scratchpad.
Now, we are 99% independent of the version and I guess that if
we compile against the 2.3 version we still would run in a 2.2
On 29.06.2004 22:03, Colin Paul Adams wrote:
Tomorrow, I'll revert to the HTML serializer, and see how the output
validates as HTML (it won't completely, because of the presence of
xmlns attributes for the xhtml namespace).
Exactly. This is what I did and I fixed some issues:
On 28.06.2004 10:32, Sylvain Wallez wrote:
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[X] keep sources in jar files
Joerg
701 - 800 of 1595 matches
Mail list logo
