Grzegorz Kossakowski wrote:
Vadim, I remember that I have not responded to your e-mail regarding
services:
http://article.gmane.org/gmane.text.xml.cocoon.devel/73790
I knew that you are talking about REST-style services and I didn't know
much more than standard hype about REST design but I
hepabolu wrote:
Marc Portier said the following on 24/5/07 17:35:
we could start off by checking some more
1/ can jxpath in fact handle namespaces correctly as described above
( in https://issues.apache.org/jira/browse/COCOON-1671#action_12356396
the orginal reporter of the issue states
Grzegorz Kossakowski wrote:
Marc Portier pisze:
Yes. I did this way (I didn't touch paths, directory structure,
sitemap) because I didn't understand the stuff fully. There is only
one sample in Cocoon (in Forms) that uses this stuff but it does not
work up to date. I mentioned problem few
Carsten Ziegeler wrote:
hepabolu wrote:
Joerg Heinicke said the following on 23/5/07 20:03:
On 23.05.2007 13:07, hepabolu wrote:
+ I would comment (or even close-wontfix?) that bug with a
reference to the above conclusion from carsten. Just in case
somebody would want to apply the patch
Carsten Ziegeler wrote:
Marc Portier wrote:
But taking it one step further: IMHO DomBuilder will use SAXParser
down below somewheree to actually do the parsing. So just setting the
parameter namespace-prefix in the cocoon.xconf will ensure all
saxparsers in the pool to (correctly) have
hepabolu wrote:
Carsten Ziegeler said the following on 24/5/07 16:14:
Helma wrote
Yes. Source is:
oe:version xmlns:oe=openEHR/v1/Version
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:type=ORIGINAL_VERSION
So in fact I want the first line of the binding file to bind to
Carsten Ziegeler wrote:
Helma wrote:
That's what I'm slowly starting to realise. For proper XML validation
I do need it so I assumed the parser requires this too.
That would partially explain why the binding file (without a
namespaceURI for 'oe') still maps to the source (in the
Felix Knecht wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I want to customize the calendar gif from the
forms-calendar-styling.xsl. In former cocoons I could do this via my
own forms-sample-styling by overwriting the specific part in it (e.g.
the calendar icon).
It seems that for
Grzegorz Kossakowski wrote:
Marc Portier pisze:
Hi there,
I have a block that is dependant on cocoon-ajax-impl and wants to use
the JSON script in there:
before http://svn.apache.org/viewvc?view=revrevision=534148
the script was loaded via
cocoon.load(resource://org/apache/cocoon/ajax
Grzegorz Kossakowski wrote:
Marc Portier pisze:
hm,
looks like I'm stumbling over a partial answer:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/META-INF/cocoon/spring/cocoon-ajax-impl-blockServlet.xml?view=markup
I suppose the 2nd bean
Carsten Ziegeler wrote:
hepabolu wrote:
Joerg Heinicke said the following on 22/5/07 22:18:
On 22.05.2007 17:07, Helma van der Linden wrote:
// Create the SAX parser and set the features so it creates the
events we need
SAXParser parser =
yo,
the bundles are up here:
http://jira.codehaus.org/browse/MAVENUPLOAD-1563
I suppose I'll get notified when things are up on the repo, I'll forward
those here then...
regards,
-marc=
Jorg Heymans wrote:
Reinhard Poetz wrote:
to be clear on what needs to be done:
1. xreporter-svn
Hi there,
I have a block that is dependant on cocoon-ajax-impl and wants to use
the JSON script in there:
before http://svn.apache.org/viewvc?view=revrevision=534148
the script was loaded via
cocoon.load(resource://org/apache/cocoon/ajax/system/System.JSON.js);
today it seems we should be
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Please commit. Except from the archtetpyes and the
cocoon-maven-plugin, I created all release artifacts.
I created all release artifacts except the forms and the ajax block. The
missing thing is a release of the xreporter-expression and
Hi there,
I'm getting further into trying the 2.2 stuff out, and with two testing
blocks somewhat functional I was trying out deployment to webapp as
described in:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1362.html
the weird thing I'm seeing is that the dispatcher-servlet
=
Marc Portier wrote:
Hi there,
I have a block that is dependant on cocoon-ajax-impl and wants to use
the JSON script in there:
before http://svn.apache.org/viewvc?view=revrevision=534148
the script was loaded via
cocoon.load(resource://org/apache/cocoon/ajax/system/System.JSON.js);
today
Reinhard Poetz wrote:
Marc Portier wrote:
I get http://localhost:/block1/ and http://localhost:/block2/
both triggering the block1 sitemap!
anybody a clue where I should be looking?
If it's not a bug the only reason could be that you copied your
servlet-service configuration
Reinhard Poetz wrote:
After Helma's work on the skin, I have published a snapshot of our docs
at http://cocoon.zones.apache.org/dev-docs/.
jummy
I did spot a small glitch while clicking around though:
at: http://cocoon.zones.apache.org/dev-docs/2.2/core-modules/
the links to the
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
After Helma's work on the skin, I have published a snapshot of our
docs at http://cocoon.zones.apache.org/dev-docs/.
jummy
I did spot a small glitch while clicking around though:
at: http://cocoon.zones.apache.org/dev
Reinhard Poetz wrote:
hepabolu wrote:
I don't see a reason why we need the namespace in our published URLs
at all. The Daisy plugin could cut them off.
Sure, and I'm all for cutting it off, but in Daisy the namespace is
there so backlink from the published page should go to the namespaced
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML pipeline (publishing)
* Modularize Cocoon apps
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
Marc Portier wrote:
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML
Reinhard Poetz wrote:
Using Continuum is definitly a step forward in order to have a stable
build but it doesn't detect problems if dependencies can't be downloaded
anymore or if we remove a module from our build but forget to remove all
dependencies on it from other modules. In those cases
Reinhard Poetz wrote:
I've started to split up our tutorials into smaller pieces in order to
make them more comprehensible:
* Your first Cocoon application using Maven 2
* Your first XML pipeline (publishing)
* Modularize Cocoon apps (Using blocks)
* Deploying a Cocoon
Jorg Heymans wrote:
Alexander Klimetschek wrote:
Yup, works now. Is it possible that you provide a release version of
that jar? Doesn't have to be the full 1.3 release if it's not finished
yet, maybe a 1.3-alpha, but I'd be glad to have no maven snapshots in
all the transitive
Jorg Heymans wrote:
Marc Portier wrote:
after some digging I found
- this missing class is provided by excalibur-pool-instrumented
- which is a *provided* dependency from excalibur-datasources-2.2.1
(which is in turn required for our cocoon-databases-impl block)
...
for now I've
Jorg Heymans wrote:
Joerg Heinicke wrote:
Eeeeh, I hope not! I'd worry about the health of the overall
codebase if
no-one else is building allblocks! Is this why continuum is not failing
when it should be?
...
I can only agree with Andrew. The goal has to be that all blocks are
succeeding the mvn build the next step from the trunkREADME.txt is to
run the webapp in jetty.
pointing my browser to localhost: however I get:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
RequestURI=/
Powered by jetty://
and the console shows a stacktrace caused by NoClassFound on
Andrew Savory wrote:
Hi,
On 16 Apr 2007, at 12:05, Reinhard Poetz wrote:
In short, add the commons-jci dependency to the javaflow block only. I
don't know if the javaflow-interpreter works then (I guess not) but at
least it should fix your build problems.
Ok, I've added it there and
Marc Portier wrote:
now, to solve things I think we better
- ask jci peeps to publish non-snapshot releases on a public repo (this
includes RC-releases)
- or just add my patch to the pom, rather then yours, no?
oh, upon reread I think additional clarification is due:
our patches do
release (1.2.2) is in the works, but I'm not ready to give any
timing-assurance on that though.
wdyt?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo
for
the subdir hierarchy should be build up of stuff they can be normally
expected to know, eg
1- major/minor/patch
2- or the various artifact-names
(given those are causing this, I'ld go for option 2)
regards,
-marc=
--
Marc Portierhttp://outerthought.org
independent of the rest of the xreporter machinery
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED
Vadim Gritsenko wrote:
Marc Portier wrote:
1/ fd:output is ignoring fd:initial-value
this one is quite obvious I think: anybody adding a fd:initial-value to
a fd:output can wait for eternity for it to ever get applied.
Proposed fix: initialize() should do it like Field.java does.
+1
I
to null ?
any comments welcome,
I'm currently planning to investigate deeper into these in the nearby future
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12428388
]
Marc Portier commented on COCOON-1758:
--
Adding the svn-update references to ease tracking:
http://svn.apache.org/viewvc?view=revrevision=427436
http
Jean-Baptiste Quenot wrote:
* Marc Portier:
Anyways, this whole process of finding out what and how kind of
convinced me that we can in fact revert the change. (and not add
an attribute)
That is the simple way.
It's called an optimum: achieving the desired goal with the least cost
[
http://issues.apache.org/jira/browse/COCOON-1687?page=comments#action_12427215
]
Marc Portier commented on COCOON-1687:
--
Reverted this patch:
http://svn.apache.org/viewvc?view=revrevision=430378
This patch was shipped with the 2.1.9
Reinhard Poetz wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
+1
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence
Reinhard Poetz wrote:
I propose switching to servlet API 2.4 in *trunk*. This shouldn't cause
any problems as a stable version of Tomcat (5.0.16), the reference
implementation for servlet containers, is available since Dec, 4th 2003.
+1
-marc=
--
Marc Portier
Jean-Baptiste Quenot wrote:
* Marc Portier:
Coming back to that original date issue in fact I'm afraid
I don't get it yet completely? At which time is this
'org.w3c.util.DateParser' active? How does this become a
problem of the binding?
CForms was generating
Jean-Baptiste Quenot wrote:
* Marc Portier:
Jean-Baptiste Quenot wrote:
* Marc Portier:
Coming back to that original date issue in fact I'm afraid
I don't get it yet completely? At which time is this
'org.w3c.util.DateParser' active? How does this become
Jean-Baptiste Quenot wrote:
* Marc Portier:
The argumentation of the fix, namely to make the value-binding
remove an element upon 'save' seems, currently, to be that this
avoids after re-'load' some weird formatting result (from to
1/1/1970) in the i18n transformer caused by some
as 2.1.x is not supposed to evolve much).
+1,
and IMHO that includes Bertrand's side-note even without saying
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
to introduce some confusion when
binding to java-bean objects where this distinction is rather
artificial, no?
Any suggestions or remarks?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my
Bertrand Delacretaz wrote:
On 8/8/06, Marc Portier [EMAIL PROTECTED] wrote:
...since the mentioned fix however the effect of the 'null' in the 'text'
field is that the complete element gets removed (since that executes the
removePath() on .)...
Sounds like a bug to me, removing
completely? At which time is this 'org.w3c.util.DateParser'
active? How does this become a problem of the binding?
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog
[ http://issues.apache.org/jira/browse/COCOON-1687?page=all ]
Marc Portier reopened COCOON-1687:
--
The applied patch introduces an undesired side-effect:
suppose you have a binding that looks like
fb:context path=elem
fb:value id=x path=@x
be
removed?
kind regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
#dsy291_detachment ;)
(unfortunately, that is a suggestion we didn't receive a proposal for)
ah, but we did :-)
and a decent one too IMHO
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog
and more to discussions. It's time for him to be able to commit his
patches himself!
Please cast your votes.
+1
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
;) He has been and is
committer and active in several other Apache projects and have started
some OS projects outside Apache. He is also an expert member of JSR 291
(OSGi), and earlier JSR-78 (RMI Custom Remote References).
Please cast your votes.
+1
-marc=
--
Marc Portier
/artifact from your implementation?
is that a constraint that is hard to keep up with?
-marc= (only taking first steps in the maven/block work, so seeking no
more then understanding)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence
- this is an opportunity to
broaden the use of these cool things.
-Bertrand
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED
.
Please don't. Cocoon is the name.
+1, same opinion here
the brand is strong enough, and can cope with major release numbers that
indicate we had serious new insights
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence
('s higher layers)
if nothing else, it would probably make it easier to write unit
tests/docs for the lower layers...
regards,
-marc=
/Daniel
Marc Portier wrote:
catching up late on this thread, I can't help feeling Bertrand is right
on the spot here, so I'm left to wonder why so little
(lacking the time here) gets ready to go for
this can get the tarball extension directory I used and unpack that in
the $DAISY_HOME/daisywiki/webapp/daisy/sites/documentation/
http://cocoon.apache.org/news/
sounds like a page that could be put into daisy itself?
-marc=
--
Marc Portier
in the
architecture is even benefitial for this kind of applications. But it
just wouldn't be an 'option' any more, would it?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
this part is what I hinted at in my other post about
historically actions being something in-between
flowlike-decission-takers and custom input-modules...
so what we talk about here and now are probably not actions as we know
them ?
-marc=
--
Marc Portierhttp
is passivated
and activated.
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105732879827785w=2
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
Carsten Ziegeler wrote:
Marc Portier wrote:
SNIP/
./SerializeNodeBuilder.java: mime-type
./SerializeNodeBuilder.java: status-code
Hmm, either your script is not correct, or your statement above :) Can
mime-type use variables or not?
well, it's the silly script of course
the mime
surprise-glasses on?
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
to track occurances in our
docos as well
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED
Leicester and Glen Ezkovich to be
editors...
Although this doesn't require a vote IIUC:
+1, for Sebastien as well.
+1
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog
of annotations, and the resemblance of js to java: we could
require /** comments?
(which is not single line however, so stretches the first-line requirement)
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my
?
Best Regards,
Antonio Gallardo.
On Jue, 20 de Enero de 2005, 15:06, Marc Portier dijo:
coincidence: was on the exact same path yesterday :-)
(but about the related mail.jar)
however I also noticed something to be warned about:
I noticed the mock InternetAddress constructor forgets about declaring
,
and any reasonably recent servlet container already runs cocoon under
2.3 anyway.
For compatibility, Cocoon 2.1.x will remain at JDK 1.3 and Servlet 2.2.
Cocoon 2.2 will use JDK 1.4 and Servlet 2.3.
HTH
Ralph
--
Marc Portierhttp://outerthought.org/
Outerthought
feature is also available in the sitemap, but more work is
needed there as labels and mime-types are ignored in included files.
Enjoy,
Sylvain
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
way to go, mate!
just one question: from memory I recall the suggestion during the
discussion for doing the automagical xconf/*.xconf include
I'm guessing this is not in there as of now?
No, it's not there currently.
It could
Gianugo Rabellino wrote:
On Sep 2, 2004, at 5:43 PM, Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
If I'm binding an XML document to a form, is it possible to use
namespaces in the binding? (The bound data has namespaces)
After
! :)
Tony
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
, or else content discussions will be
fueled by this upfront decission)
all of which should at least ensure:
- that new blocks added do _not_ get automatically added to the build?
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML
Torsten Curdt wrote:
map:components roles-file=... config-file=...
..
/map:components
So, please cast your votes!
+1
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
equivalent to writing :
fd:choice id=foo
fd:widgets
fd:field id=baz/
/fd:widgets
fd:when case=bar
fd:widget ref=baz/
/fd:when
/fd:choice
That also means that child ids must be unique throughout the various cases.
WDYT?
I like it
-marc=
--
Marc Portierhttp
Folks please cast your votes for:
[ ] Leszek
[ ] Ralph
as Apache Cocoon committers.
+1 for both,
welcome Ralph and Leszek!
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog
help on
where to start, it could well be that I'm missing the most simple and
effective solution, but the idea of keeping in sync namespace scopes
in the binding file with JXPath looks quite scary at a first look.
Anyone willing to help out?
Ciao,
--
Marc Portierhttp
.
fd:field id=foo
fd:attribute name=bar value=baz/
.../...
/fd:field
The purpose is to use attributes as tags (or metadata) that can be
handled by some generic form handling code.
Any objection for this?
Sylvain
--
Marc Portierhttp://outerthought.org/
Outerthought - Open
Sylvain Wallez wrote:
Marc Portier wrote:
none,
just had one spontanuos thought:
maybe we can reduce typing somewhat if we add those attributes by
using a different namespace (rather then, the default one which seems
to be so commong for attributes)
(possibly reusing 'fd', or introducing 'fa
going bez-*$^*#-urk)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
I need to put it
in bugzilla (it's just a very very small patch)??
Bart.
-Original Message-
From: Bart Molenkamp
Sent: Tuesday, September 07, 2004 3:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [CForms] Change proposal in Custom bindings
-Original Message-
From: Marc Portier [mailto
small change I need. The class
JXPathBindingBuilderBase.CommonAttributes and the method
getCommonAttributes() needs public (or protected) scope. That way I can
create the builder in my own packages.
sure, makes sense!
-marc=
Bart.
-Original Message-
From: Marc Portier [mailto:[EMAIL PROTECTED
/bugzilla/show_bug.cgi?id=30693
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Carsten Ziegeler wrote:
If I'm binding an XML document to a form, is it possible
to use namespaces in the binding? (The bound data has
namespaces)
not yet, no
it's a long outstanding todo :-(
basically, it boils down to understanding if and how jxpath can do it.
-marc=
--
Marc Portier
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
If I'm binding an XML document to a form, is it possible to use
namespaces in the binding? (The bound data has namespaces)
The solution I've used successfully up to now is to bind to a
document
Pier Fumagalli wrote:
On 17 Aug 2004, at 16:20, Marc Portier wrote:
How about setting it up as the default behavior for Cocoon's
internal Jetty distro?
makes sense, but: (whishing all this brokenness wan't there but helas)
It's not really brokenness but more along the lines of an inversion
the URI (and the request
params using get vs post) as part of it or not
(talk about possible confusion when writing specs like this, yuk!)
regards,
-marc=
(sorry for just popping up the questions, lacking the time to
investigate deeper myself ATM)
--
Marc Portierhttp
), or a default of ISO-8859-1, before the string
is actually given to the sitemap.
Not having the sources at hand at the moment, I can't do a quick build
to put out some debugging instruction, but you get the idea.
Pier
--
Marc Portierhttp://outerthought.org/
Outerthought
://marc.theaimsgroup.com/?l=xml-cocoon-devm=109103885629692w=2
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL
with a
predictable nature of being? (ie what is lacking in resources)
as such I catched at a certain moment during the discussion that we
would deprecate resources as a whole but keep on supporting and start
promoting the switch to the more solid virtual-xxx thingies...
HTH
regards,
-marc=
--
Marc Portier
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
think so too, just needs more wild thinking and somebody doing :-)
Since I'm getting more and more bored with my daytime job, I ended up
doing something:
http://wiki.apache.org/cocoon
that extends TestCase)
In short: I see no reason why not to have both, the latter help document
typical configuration settings for the bean wiring
still have to get into your actual code sample though, by the way: could
we arrange having a cvs somewhere?
regards,
-marc=
--
Marc Portier
Ugo Cei wrote:
Il giorno 22/lug/04, alle 10:34, Marc Portier ha scritto:
still have to get into your actual code sample though, by the way:
could we arrange having a cvs somewhere?
How about cocoondev.org? Is the migration over? I asked Steven some time
ago about hosting the SpringPetstore
Ugo Cei wrote:
Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto:
think so too, just needs more wild thinking and somebody doing :-)
Since I'm getting more and more bored with my daytime job, I ended up
doing something:
http://wiki.apache.org/cocoon/ButterflyManifesto
Comments
in your
testcases to have them ran through some test-scenarios
those tests might be not true efull environment tests, but they'll
surely be able to spot a fair share of low level RTE's you should get
rid off
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought
;CocoonForms/link
/li
Vadim,
this http://cocoon.apache.org/2.1/userdocs/forms/index.html
might even be better, no?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip /
There were some mentions in the past, that a VSC can contain any
sitemap
component, so even actions, matchers and selectors are allowed
perspective as well: their contract
becomes more rigid, so you can more easily pass them down to users that
(potentially) don't have access to those internals
HTH,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support
that the resource contents follow the
rules for a virtual component.
I'm with Vadim here: resources v2 should be virtual-reads building up
complete pipes, I see no other use if VPC's are there
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java
Sylvain
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Ugo Cei wrote:
Dear Cocooners,
this is something more crazy than a Random Thought, something that
one can only think of on a Friday evening after a few hours of
boooring application development (doing infrastructure things is
much
1 - 100 of 374 matches
Mail list logo
