block
besides the HTMLGenerator. But it doesn't really make sense to have 2
RequestGenerators.
Hope this will be useful for others as well.
Guido
Guido Casper
-
SN AG, Open Source Competence Center
Tel.: +49-5251-1581-87
Gianugo Rabellino wrote:
Guido Casper wrote:
I want to extend RequestGenerator so that request parameters which
names start with html: are parsed (very much like it already
parses request parameters which names start with xml: see:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm
Gianugo Rabellino wrote:
Guido Casper wrote:
Besided, we have ready (uncommitted since it seemed to me not that
generally useful) an HTML transformer, getting content coming from a
generator as HTML excaped (lt;htmlgt;) and converting it to XHTML
using Tidy: we are using it for HTML taken
if the Cocoon community maintains the current growth rate.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
a WebDAV enabled
editor.
Tools like Webdrive
http://www.southrivertech.com/products/webdrive/index.html
allow you to mount WebDAV as disk drive. AFAIK WinXP does this natively
(please somebody correct me if I'm wrong).
Guido
--
Guido Casper
-
SN AG
be possible (and more maintainable in the long run?)
to build a webdavapp in a mostly declarative fashion.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL
Gianugo Rabellino wrote:
I want to propose Guido Casper ([EMAIL PROTECTED]) as a new Cocoon
committer.
Thanks Gianugo, I'm really honoured.
I'm extremely proud of being part of this great community (even without
having commit access), where I consider many of the committers real genius
(coding
Stephan Michels wrote:
I should mention that Stefan Michels provided an early draft in - I
think it
Stephan
was more than 1,5 years ago but unfortunately (IMO) decided to focus
on the SlideSource.
Hmm, yes, perhaps a bad idea ;-) I got too few response on that. My
experience with WebDAV
Stephan Michels wrote:
At least, we should agree on one name
SourceHierarchyGenerator - http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator - http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator - http://apache.org/cocoon/directory/1.0
or DirectoryGenerator.
gcasper 2003/08/07 12:50:04
Modified:src/blocks/webdav/samples/davmap sitemap.xmap
Log:
my first commit :-)
applying my own patch #21945
Actually I'm not sure wether this use of map:resources is intended
behaviour.
Having matchers in resources is fine, but why is the repo/
Gianugo Rabellino wrote:
I'm about to tackle WebDAV properties handling, and I was happy to
find that Guido has already provided something. :-)
I am however a bit uncomfortable with the current implementation and
I
wanted to see if it's just me not having the correct approach.
I'm
Guido Casper wrote:
Gianugo Rabellino wrote:
This is, however, the case of the current SourceProperty, a
contract
that, as of now, we might not want to break.
I think we have to. For example in:
public SourceProperty(Element property) {
this.namespace = property.getNamespaceURI
Gianugo Rabellino wrote:
Guido Casper wrote:
Maybe having getValueAsString() not skipping non-text elements
(although I might not understand what the rationale for this
behaviour is) would be enough to support sources without XMLized
properties.
Yes, probably. We'll need to discuss
Stephan Michels wrote:
On Tue, 26 Aug 2003, Gianugo Rabellino wrote:
Guido Casper wrote:
I'm however cautious about breaking SourceDescriptionGenerator,
more
so that I found that the slide block isn't marked unstable (Is it
too late to change this?).
I guess we should ask Stephen about
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Le Jeudi, 28 aoû 2003, à 10:11 Europe/Zurich, [EMAIL PROTECTED] a
écrit :
A first cut at a DASL query component. Needs tweaking, but it's
basically working.
Just curious, which DASL-enabled server are you using?
(I tested the DASL support in
Gianugo Rabellino [EMAIL PROTECTED] wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 28 aoû 2003, à 10:11 Europe/Zurich, [EMAIL PROTECTED] a
écrit :
A first cut at a DASL query component. Needs tweaking, but it's
basically working.
Just curious, which DASL-enabled server are you using?
(I
Gianugo Rabellino [EMAIL PROTECTED] wrote:
Bertrand Delacretaz wrote:
match type=request-method pattern=PUT
act type=syncmetadatadb
generate type=webdavproxy
parameter name=url value=http://whatever/dav/{../1}/
/generate
serialize/
/act
/match
I don't
Christopher Oliver [EMAIL PROTECTED] wrote:
Unfortunately I think 2.1.1 contains a Rhino regression I temporarily
introduced while trying to fix bug 22513 which will cause any scripts
with nested functions to fail. This includes some of the flow samples
like PetStore and JXForms.
IMO we are
Steven Noels [EMAIL PROTECTED] wrote:
3) Given the breakage in the Rhino stuff, and the lack of serious
testing on the 2.1.1 release, I would refrain from announcing 2.1.1
How about putting a hotfix on the dist site like Tomcat is doing
http://nagoya.apache.org/mirror/jakarta/tomcat-4/binaries/
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a
écrit
...Would it be enough to extend our Anteater scripts (see Guido's
mail) and
add Anteater to our codebase and include it automatically to our
build system? ...
certainly a
David Crossley [EMAIL PROTECTED] wrote:
I propose Antonio Gallardo and Tony Collen to be Cocoon committers.
+1 for both
Guido
Joerg Heinicke [EMAIL PROTECTED] wrote:
Carsten is in holidays for three weeks, but maybe one of the other SN
people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with
JDOM or the other way around?
I'm not familiar with the portal code and don't know of any planned
refactoring.
Carsten Ziegeler [EMAIL PROTECTED] wrote:
So please cast your vote for either:
a) Make a 2.1.2 release on October, 1th
+1
Guido
Steve K [EMAIL PROTECTED] wrote:
Guido --
What exactly led you to propose HTTPUnit but prevents you from using
Anteater for the very same purpose (just curious)?
I'm sorry if I gave that impression. Correct me if I'm wrong, but I
believe HTTPUnit and the anteater scripts both test in a
Hi Unico,
first let me say thank you for all you efforts in this area. I'm very
excited about that (I start wondering ...). I'm sorry I cannot help out
more currently.
Unico Hommes [EMAIL PROTECTED] wrote:
Hi,
This is to let you know I've just submitted a patch [1] to cocoon
bugzilla for
Steven Noels [EMAIL PROTECTED] wrote:
Nicola Ken Barozzi wrote:
Unico Hommes has been helping a lot on the Cocoon and Forrest
mailing lists, and I can see from that his knowledge of Cocoon is
well over par.
Furthermore, he has made this locationmap that he will concievable
want
.
This would remove the dependency of the webdav block and the scratchpad
block on the slide block but make them all (including Linotype) depend
on the repository block.
Guido
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
Unico Hommes [EMAIL PROTECTED] wrote:
One of the things I've
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
I would like to make the following changes to the 2.1 repo and will
go ahead if noone objects (as soon I find some time):
-Creating a repository block and moving there all source interfaces
not part of excalibur's sourceresolve
BTW, does somebody know why the slide samples are not working?
(and they are not working since quite some time now in case somebody
wants to ask :-)
Guido
[EMAIL PROTECTED] wrote:
gcasper 2003/10/22 12:28:08
Modified:.gump.xml
Log:
Marked the slide block unstable
Unico Hommes [EMAIL PROTECTED] wrote:
Hmm, I may have spoken too soon.
I am looking into moving
o.a.cocoon.component.source.(Modifiable)TraversableSource into
deprecated area. In order to accomplish this I need to migrate
SlideSource towards that as well.
And SourceDescriptionGenerator as
Unico Hommes [EMAIL PROTECTED] wrote:
-Adding a setSourceProperty() method to the
SourceInspector interface
Already have it on my local copy. :-)
Cool! So I leave this to you :-)
Actually I think it's better to define a subinterface named
SourceDescriptor that defines these methods. This
Unico Hommes [EMAIL PROTECTED] wrote:
A related change I need to make is described here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699 this will
not only improve performance of querying for a specific property
but is prerequisite for setting properties via the
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
No, I don't mean properties describing the access permissions
but rather the properties affected by access permissions. You
might be allowed to access a particular property on one
source but not on another.
Aha, now I get the acl
Unico Hommes [EMAIL PROTECTED] wrote:
OK, I think the confusion is due to the method name which may be
misleading in this case: getExposedPropertyTypes(). A better name
would be getHandledPropertyTypes() or boolean handlesProperty(String
ns, String name). It's meaning is confined to
Unico Hommes [EMAIL PROTECTED] wrote:
I am looking into extending SourcePropsWritingTransformer to also be
able to remove SourceProperties. One thing I need to decide is how to
access SourceProperties now that we have SourceDescriptor interface.
From SourceDescriptionGenerator I can see that
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
In my doco wandering, I tried to mount the cocoon DAV repository
(found in the 'davmap' directory of the webdav block) under macosx as
a disk, but fails. I tried with mod_dav on httpd 2.0.47 and it works.
Further inspection (with the good old
See also:
http://marc.theaimsgroup.com/?t=10631375302r=1w=2
Guido
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I'm still having fun with webdavapps and found something that looks
suspiciously close to a bug in the way the flow and sitemap work
together in case of an exception.
In the
Unico Hommes [EMAIL PROTECTED] wrote:
Guido Casper wrote:
snip/
I think this could be changed. However if we want the davmap to be a
widely interoperable WebDAV server, I think we should have something
like a compatibility test suite - similar to Slide's TProcessor or
litmus
http
Unico Hommes wrote:
I am +1 on the idea but would favor naming the method sendStatus
instead, and also have a way to set the status on the environment from
the flow without sending an empty response:
- cocoon.sendStatus(status)
- cocoon.sendStatus(status, message)
-
Stefano Mazzocchi wrote:
On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
wrote:
I agree with comments in this other thread that let's not introduce
nested components in map:call/. Instead, if needed,
Stefano Mazzocchi wrote:
On 7 Nov 2003, at 17:22, Guido Casper wrote:
Stefano Mazzocchi wrote:
On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
wrote:
I agree with comments in this other thread
Bruno Dumon wrote:
Tim has been hanging around on our mailing lists for quite some time,
and is actively contributing, both in discussions and code. Becoming a
committer can only motivate him to keep up the good work.
+1 from me.
+1
Guido
Antonio Gallardo wrote:
Reinhard Poetz dijo:
On 18/11 the 'Austrian Cocoon Day' took place
(http://cocoon.ifs.tuwien.ac.at).
Most of the speakers agreed to publish their presentations as PDFs.
You can either find them at the web site of our event or at
http://cocoon.apache.org/mirror.cgi
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
I think a much better approach would be to come up with a
Repository.java
interface and a few implementations that I can choose when I install
cocoon. This implementation would also implement Source.java and
provide its functionality thru
Stefano Mazzocchi wrote:
On 1 Dec 2003, at 10:35, Guido Casper wrote:
The challenge is to find the right balance.
That's *always* tough. On anything. ;-)
Very true.
This reminds me (again) of Rickard Öberg's second principle for making
software frameworks:
If you make a decision, be sure
Did anyone else also feel the need to have something like
processPipelineTo but getting a DOM or just an InputStream instead of
just streaming it directly to another OutputStream?
Guido
Geoff Howard wrote:
Upayavira wrote:
Maybe my last question was too specific.
I'm trying to parse the
Sylvain Wallez wrote:
Guido Casper wrote:
Did anyone else also feel the need to have something like
processPipelineTo but getting a DOM or just an InputStream instead
of just streaming it directly to another OutputStream?
Rather than extending the FOM, what we need is a helper JS library
of serialization/parsing which does not
take place with Sylvain's approach. I think I'm seeking for the best of
both, which might only be possible with an extra FOM method?.
Guido
Guido Casper wrote:
Did anyone else also feel the need to have something like
processPipelineTo but getting a DOM
Sylvain Wallez wrote:
One more new feature ;-)
Following the thread extending FOM about extending processPipelineTo
to SAX and DOM, I wrote a utility class that handles all this.
This class is totally decorrelated from the FOM and the cocoon
object and provides the processToDOM(),
Reinhard Poetz wrote:
I want to propose Daniel Fagerstrom as new Cocoon committer.
+1
Guido
Gianugo Rabellino wrote:
[EMAIL PROTECTED] wrote:
gcasper 2003/12/17 05:42:14
Modified:
src/blocks/webdav/java/org/apache/cocoon/components/source/impl
WebDAVSource.java Log: Interoperability with mod_dav
Why so? I think that the cleanest way is to solve this issue where it
Gianugo Rabellino wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
[EMAIL PROTECTED] wrote:
gcasper 2003/12/17 05:42:14
Modified:
src/blocks/webdav/java/org/apache/cocoon/components/source/impl
WebDAVSource.java Log: Interoperability with mod_dav
Why so? I think
Marc Portier wrote:
all,
I'm committing (just did) a new set of samples that should grow out to
become a sort of a step by step tutorial on Woody's Binding features.
Basically I started to loose the oversight myself, and wanted to
create some testbed that only focusses on distinct binding
Reinhard Poetz wrote:
From: Marc Portier [mailto:[EMAIL PROTECTED]
Christopher Oliver wrote:
You can release components after sendPage(). It doesn't block.
How about adding an additional function parameter to
sendPageAndWait()?
In the supplied function you can provide code that will
Upayavira wrote:
Marc Portier wrote:
now, in this case backendX is cocoon (modifiable) sources, so I would
guess some saveToSource/loadFromSource can be made quite generic and
might very well be candidates for natural extension of the woody2.js
Yup. You've confirmed what I suspected. What I
Upayavira wrote:
Upayavira wrote:
Guido Casper wrote:
Upayavira wrote:
Marc Portier wrote:
now, in this case backendX is cocoon (modifiable) sources, so I
would guess some saveToSource/loadFromSource can be made quite
generic and might very well be candidates for natural extension
Ugo Cei wrote:
It looks like we might have a problem. I copied the loadDocument
function from woody's binding_example.js and passed it an xmldb:
URI. This is the exception I get when I call
var is = new
Packages.org.xml.sax.InputSource(source.getInputStream());
Ugo Cei wrote:
Guido Casper wrote:
I have no idea what the reason might be but maybe you want to try:
org.apache.cocoon.components.source.SourceUtil.toDOM(source);
I already found a workaround:
var domBuilder = new Packages.org.apache.cocoon.xml.dom.DOMBuilder();
source.toSAX(domBuilder
Unico Hommes wrote:
Now there is some code there that has become obsolete. And I am
wondering what should be done with it.
ModifiableTraversableSource and TraversableSource both have been
deprecated. SourceDescriptionGenerator has been superseeded by
TraversableSourceDescriptionGenerator.
Marc Portier wrote:
also having the saveDocument and loadDocument you propose here
_outside_ the woody specific flowscript seems to make them more
widely re-useable in different areas!
with those in place I think my previous idea to 'extend' the Form
object from woody2.js is a nice (almost
Torsten Curdt wrote:
My idea is to come up with an unified syntax. Taking the
best out of the SQLTransformer and the ESQL logicsheet.
Then come up with an ESQL transformer and a logicsheet
using the same code base (as much as possible). For
an easy migration we could provide an ant task that
Joerg Heinicke wrote:
o 25285 - Processing pipelines from within flowscript and get various
results objects
What about cocoon.processPipelineTo()? I thought it already exists.
But anyway, it is an enhancement.
This is covered by PipelineUtil and it has been suggested to even
deprecate
Daniel Fagerstrom wrote:
Bruno Dumon wrote:
I don't think so. An attribute called id has no special meaning in
XML.
See http://www.w3.org/TR/2004/REC-xml-20040204/#id :
Validity constraint: ID
Values of type ID MUST match the Name production. A name MUST NOT appear
more than once in an XML
Carsten Ziegeler wrote:
In the scratchpad is the portlet environment which allows Cocoon
to act as a JSR-168 producer.
The portal block contains the JSR-168 consumer implementation.
I propose to move the producer part from the scratchpad into
the block combining both and maintaining everything
Jeremy Quinn wrote:
It is with much joy that I find @readonly is ignored by both Mozilla and
Safari (hoo-bloody-ray!! )
Try @disabled instead.
Guido
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow
Alan wrote:
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too
Alan wrote:
What do you mean by strongly typed? Are we discussiong form posts
here?
Yes, form posts being the use case at hand, but there are other ways
input may be provided. Quoting Daniel:
Besides using request parameters and structured request parameters as
user input. XML is used for
Steve Krulewitz wrote:
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
- http cookie
- user session
Gregor J. Rothfuss wrote:
hi,
the lenya community has developed a lightweight workflow that we thought
would make more sense as a cocoon block, especially given that other cms
built on cocoon have shown interest in using it (hi arje :). i split out
the generic part and made it into a
that anymore ...
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
(the
user actively triggers the workflow).
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me
Gianugo Rabellino wrote:
Guido Casper wrote:
Interesting. would you like to share that with us? I think it would
be avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of
a UML diagramm or a XML file. I
Guido Casper wrote:
The major drawback currently is that my AbstractState has to know
about all the other states (to prevent each State class having to
know about all the other states) and (when adding NewState) has to be
updated with: allowEnterNewState(doc, user) {return false;}
I have
Gianugo Rabellino wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
workflow-manager
state name=tobeprocessed class=TobeprocessedState
entering-action class=TobeprocessedAction/
/state
state name=beingprocessed class=BeingprocessedState
entering-action class=BeingprocessedAction
simple
to use from Cocoon for simple use cases, I would immediately use that.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http
.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
transparent; the first time I wrote GUI modeling tools
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Reinhard Pötz wrote:
...
Sorry for this. I thought there was no need for the old block but if
somebody needs it we can revert the removal.
Oh yes, *please*, *please*, because this instantly breaks all
applications that use woody and the latest
Torsten Curdt wrote:
Shouldn't one be able to keep the old block
and use 2.1.5-dev? ...as an interim solution?
Yes, I can live with that. But I think it's not a good sign for our
users. A user should have a chance to migrate while using a released
version.
Guido
Hunsberger, Peter wrote:
A good implementation of work flow handling for Cocoon could be the most
important piece of missing capability that can be added. For the most
part good work flow engines are expensive proprietary pieces of
software. If a generalized, open source, document handling
Hunsberger, Peter wrote:
You can call it whatever you want but a state in a FSM and a
continuation in a script are exactly the same thing, they need to
contain the same amount of data to be able to resort the execution.
The problems in replicating one across containers will be the same
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we
:-)
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
a major point, it gives you a very flexible
approach while allowing you to continue working with what you are
already familiar with.
WDYT?
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other
projects, but I'm
personally after very tight integration
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one
this would give us probably the remaining 20% for those who
need the whole thing?
/snip/
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100
, having done so, be prepared to throw it out
Yes. I take that as a precondition for any scratchpad code (if not for
any code within the Cocoon CVS). However there doesn't seem to be much
interest in that code anyway. So I rather wait for other suggestions.
Guido
--
Guido Casper
of a standard with
which a large percentage (definitely more than 80%. Having to resort to
another solution in one of four situations is not acceptable) of use
cases can be implemented.
--
Guido Casper
-
SN AG, Competence Center Open Source
going forever ;-)
The existing code base might not satisfy everybody, but at least it's
something
concrete to start with, even if it will be totally modified resp.
refactored in the end.
Michi
--
Guido Casper
-
SN AG, Competence Center Open Source
returns from vacation? :-)
Michi
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Rolf Kulemann wrote:
On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
Concerning the repository ... I just committed another repository
interface :-) that tries to be a best effort in consolidating all the
different approaches and accommodating all concerns in a flexible way
(by having opional
Rolf Kulemann wrote:
On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
-link management
What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
explain your idea in more detail.
I'm thinking of managing linking information within metadata/properties
in a bidirectional way so
.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Is everybody fine with moving FlowAttributeModule and
FlowContinuationModule from scratchpad to core? Is a vote needed? I
guess no.
If noone objects I go ahead tomorrow.
Guido
--
Guido Casper
-
SN AG, Competence Center Open Source
Rolf Kulemann wrote:
On Sun, 2004-04-04 at 17:00, Guido Casper wrote:
Rolf Kulemann wrote:
Hello (Guido),
I have done a small js file to test the functionalities of the new
WebDAVRepository[1] using the NEW Repository[2] interface.
I encountered a problem creating new reosurces.
It does
is version controlled and if that's the case undo the move
(to keep the old version history) and return false.
I don't know the details of how to check wether a resource is under
version control right now (would have to check the DeltaV spec).
Guido
--
Guido Casper
Rolf Kulemann wrote:
On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
Rolf Kulemann wrote:
I just changed the code a little bit. However it's now a little hacky
and needs completion as after the copy you should check wether the
destination is version controlled and if that's the case undo
1 - 100 of 156 matches
Mail list logo
