Re: [RT] Webdavapps with Cocoon
replying to both Gianugo and Marc in the same email for brevity. On Friday, Jul 25, 2003, at 17:08 Europe/Rome, Marc Portier wrote: Gianugo Rabellino wrote: Stefano Mazzocchi wrote: snip / Now Cocoon, in its present incarnation, is heavily biased by the read-only syndrome, and this makes IMO very hard to enter the WebDAV world. I see two serious areas where WebDAV support needs careful (re)thinking of core Cocoon patterns: I think this applies also to more classic file-upload schemes? Yes, it totally does. the way file-upload is handled today is just one aspect of a more general 'polishing outside-in flow of information' for cocoon. (note I used the term polishing not rethinking, see below why) 1) URI space decoupling being unreversable: while this is a *major* feature of Cocoon (and something that might help immensely when applied to a DAV environment: views on WebDAV would really kick ass, imagine presenting your XML files as virtual OpenOffice .sxw that are assembled /disassembled on the fly), the drawback is that, in most cases, it's impossible to work your way from the pipeline result to the single pieces that make that result happen. Even the simplest XSLT transformation can't be reversely applied, so now there is no way to understand how an resource should be treated in a symmetric way when requested or uploaded. Oh yes, you can hm, do we really need to look at it as symmetric? No, we don't. I've been thinking about this a lot and I think that symmetry is not only a holy grail, but it's the wrong grail to consider holy. Read on. I know we are tempted to do so, but is it a must? It is tempting, but symmetry-driven design is bad. we must understand what we want, why and what is limiting us. Is it imposed by current webdav enabled editors? It has been already said that webdav is the most under-hyped technology ever. Microsoft said in the helloween documents that they pushed for webdav to be a supercomplex specification so that opensource wouldn't be able to implement it. Greg Stein (the current ASF chairmain, BTW) finished mod_dav in a few days disturbed by those documents (if you ever meet Greg, as him, is a pretty funny story and he's very proud of having done that [he worked for microsoft before]) As a result of this, Microsoft moved away from webdav (probably they thought it was not complex enough) and into web services (will the SOAP/WSDL/UDDI/BPEL4WS stack will be hard enough for OSS to catch up? hopefully we'll be smarter and just keep going with good old HTTP style WS). As a result, webdav was (more or less) abandoned by the market. Subversion is the only use of webdav that goes behind saving a file on disk thru your web folder (which implementation sucks ass and I bet is not going to be better in the future, in favor of a SOAP-based document upload web service). Again, Greg Stein is behind the effort. WebDAV is a very generic protocol (just like HTTP is) but people are influenced by implementations more than by the protocol design themselves. For example, almost everybody on the web believes that http://blah.com and http://blah.com/ are the same URL just because all web clients will call HTTP/1.0 GET / on both requests. But they don't know that http://blah.com/news and http://blah.com/news/ are two different URL and it's the web server that (normally! but nobody ever specified this behavior anywhere!) translates the first into the second if the folder 'news' if found in the file system that mounts to that URL space. Note that on a real FS, everybody knows the difference between /home/blah/news and /home/blah/news/ because the OS enforces type checking on these (on a POSIX file system you cannot open a directory for writing as a file, for example). The above weakness of URL space handling is the first thing that severely hurt the WebDAV world. [note: a bug in microsoft web folders eliminates the trailing slash from URL before sending the HTTP request, go figure! means that nobody in microsoft ever thought about webdav-editing the root of a folder (which is normally its index, or default content in ISS terms)] Some say (ever Marc suggests) that the forcing of DAV to work all the actions on the same URL might be a reason for poor success, but I disagree because it doesn't take resource views into consideration. If I have a resource like http://blah.com/news/ and I want to edit, I could ask for http://blah.com:/news/ http://edit.blah.com/news/ http://blah.com/news/?view=edit; which are all 'orthogonal' ways of asking a different view of the same resource accessing it thru a parallel URL space (but with different behaviors) I normally prefer the virtual-host approach. something like this [frontend] - [repository] - [backend] http://blah.com http://edit.blah.com where frontend and backend are separated (frontend might even be a static representation of the saved content (say, created by a
Re: [flow] forwardTo()
On Tue, 2003-07-22 at 16:12, Marc Portier wrote:
Hi all,
Trying to understand some more flow internals...
I just checked the FOM_Cocoon.java on how it handles the redirects...
and this seems to be the relevant portion:
String redUri = uri;
if(! uri.startsWith( cocoon:// ) ) {
redUri = cocoon:// + this.environment.getURIPrefix() + uri;
}
actually that's how the forwardTo(uri, object, Continuation) method does
it.
forwardTo(uri, object, FOM_WebContinuation) always inserts cocoon:// +
getURIPrefix, regardless of whether the URI already starts with
cocoon://
1/ do we explicitely want to prohibit the usage of ANY valid uri
to redirect to?
I guess that http://whatever-uri should be able to work as well,
no? Maybe we should just be checking for the presence of a
'scheme' part in the URI?
Don't know. We got a redirectTo method for that.
(and even if we don't want to have client-side-redirect uri's
ripple through then we should at least check and warn accordingly?)
agreed
2/ when selecting a sitemap-pipeline do we explicitely want to
have everything resolved versus the top level sitemap?
if we would just append 'cocoon:/' (ONE slash) then the
flow-writer can control if he wants to select relative to the
current sitemap or relative to the root sitemap (by letting his
uri start with a '/' or not)
sendPageAndWait('localmap/uri-part');
-- cocoon:/localmap/uri-part
sendPageAndWait('/topmap/whatever);
-- cocoon://topmap/whatever
Makes sense. This could change existing behaviour if people already used
/ at the beginning of the path, but I think that will rarely be the case
and is a change we can still afford now.
3/ is this behaviour a general property of 'flow' or is it
specific to how the JSInterpreter handles things?
personally I think we can tackle this on the level of the
AbstractInterpreter so this line of thinking becomes available to
all flow implementations?
I agree.
if all 3 comments make sense the following could become the new
implementation of AbstractInterpreter.forwardTo() (and we could
offload the burdon from the current implementations)
import org.apache.excalibur.source.SourceUtil;
public void forwardTo(String uri, Object bizData,
WebContinuation continuation,
Environment environment)
throws Exception
{
if (SourceUtil.indexOfSchemeColon(uri) == -1) {
uri = cocoon:/ + uri;
}
Map objectModel = environment.getObjectModel();
FlowHelper.setContextObject(objectModel, bizData);
FlowHelper.setWebContinuation(objectModel, continuation);
PipelinesNode.getRedirector(environment)
.redirect(false, uri);
}
what do others think?
I would forbid the use of schemes completely (i.e. throw an exception if
the uri contains a scheme), and prepend cocoon:/ (one slash).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
DO NOT REPLY [Bug 21925] New: - FOM Request object does not provide access to all the request's values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925 FOM Request object does not provide access to all the request's values Summary: FOM Request object does not provide access to all the request's values Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following methods seem to be missing from FOM_Request: getServerName getScheme getServerPort getRemoteAddr
Re: Release on tuesday?
On Sunday, Jul 27, 2003, at 15:04 Europe/Rome, Andreas Kuckartz wrote: Carsten Ziegeler wrote: I want to make the 2.1rc1 release on tuesday. I haven't followed the list this week very closely, but it seems that there are no outstanding issues. Did I oversee something? No. The vote on the sitemap changes for the pluggable flow implementation is lagging behind, I think it's better if we freeze the contract now and change it later for Cocoon 2.2, right now it feels like there is too many issues on the table. I don't want to modify it now and then have to modify it yet again in the future. Bugzilla contains 117 unresolved issues. Point me to *one* project that releases only when there are no unresoved issues, Andreas. -- Stefano.
DO NOT REPLY [Bug 21931] New: - [PATCH] LDAPTransformer filter element as sitemap parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21931 [PATCH] LDAPTransformer filter element as sitemap parameter Summary: [PATCH] LDAPTransformer filter element as sitemap parameter Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Many elements of LDAPTransformer can already be specified as sitemap parameters. Not the filter element however. This patch adds that functionality.
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom FOM_Cocoon.java
bruno 2003/07/28 04:07:31
Modified:src/java/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
Log:
Added methods getServerName, getScheme, getServerPort, getRemoteAddr to FOM_Request
(Patch 21925 by Ugo Cei)
Revision ChangesPath
1.7 +17 -1
cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java
Index: FOM_Cocoon.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- FOM_Cocoon.java 21 Jul 2003 23:13:01 - 1.6
+++ FOM_Cocoon.java 28 Jul 2003 11:07:31 - 1.7
@@ -362,6 +362,22 @@
public String jsFunction_getProtocol() {
return request.getProtocol();
}
+
+public String jsFunction_getServerName() {
+return request.getServerName();
+}
+
+public String jsFunction_getRemoteAddr() {
+return request.getRemoteAddr();
+}
+
+public int jsFunction_getServerPort() {
+return request.getServerPort();
+}
+
+public String jsFunction_getScheme() {
+return request.getScheme();
+}
}
public static class FOM_Cookie extends ScriptableObject {
Re: cvs commit: cocoon-2.1 status.xml
[EMAIL PROTECTED] wrote:
gianugo 2003/07/28 04:28:22
Modified:src/java/org/apache/cocoon/transformation
SourceWritingTransformer.java
src/documentation/xdocs/userdocs/transformers
sourcewriting-transformer.xml
.status.xml
Log:
Added delete capabilities to the SourceWritingTransformer, while solving
a DOM bug(?) with new documents creation.
Revision ChangesPath
1.5 +77 -9 cocoon-2.1/src/java/org/apache/cocoon/transformation/SourceWritingTransformer.java
...
@@ -647,7 +706,7 @@
// import the fragment
Node importNode = resource.importNode(fragment, true);
if ( path.equals() ) { // this is allowed in write
-resource.appendChild(importNode);
+resource.appendChild(importNode.getFirstChild());
message = entire source overwritten;
Was this bit the DOM bug? Was it caused by whitespace outside root
node when overwriting the whole document? There was some discussion
about 9 months ago where some (at least one) thought that was mandatory
behavior and the responsibility of the fragment author (or pipeline) to
remove whitespace.
If you've changed that behavior I'm personally very +1 but it may be
worth a discussion.
Geoff
RE: Release on tuesday?
Andreas Kuckartz wrote: If Carsten decides that none of these open issues is severe enough to block the release that would be ok with me. It's not me who decides this, we all ( the community ) decide it. By sending mails like these I only remind everyone to see if there are blocking issues. If none pops up (= if noone says so), it means we (not only I) are not aware of any issues that really have to be solved before the release. But the great part of doing the releases is, when something goes wrong, everyone knows who to blame... ;) Carsten
Re: cvs commit: cocoon-2.1 status.xml
Geoff Howard wrote:
@@ -647,7 +706,7 @@
// import the fragment
Node importNode = resource.importNode(fragment, true);
if ( path.equals() ) { // this is allowed in write
-resource.appendChild(importNode);
+resource.appendChild(importNode.getFirstChild());
message = entire source overwritten;
Was this bit the DOM bug? Was it caused by whitespace outside root
node when overwriting the whole document? There was some discussion
about 9 months ago where some (at least one) thought that was mandatory
behavior and the responsibility of the fragment author (or pipeline) to
remove whitespace.
If you've changed that behavior I'm personally very +1 but it may be
worth a discussion.
I don't think it's a matter of whitespace. I'm not a DOM guru, but if
the firstChild is a whitespace node it should be returned by the
getFistChild() call as well. Actually, I am a bit puzzled too, since the
SWT wasn't working on my setup but it was on others (I suspect it has to
do with the latest JVM that I'm using), no matter what sample documents
I gave to him. With this one liner, everything was working OK, so I just
thought to change it. But I'm more than open to any discussion. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
[Vote] Ugo Cei and Marc Portier as Cocoon committers
Hi team,
I'd like to propose two people for Cocoon committership : Ugo Cei and
Marc Portier.
Ugo has been there for years (the archives show his first post back in
July 2000!), has been an early adopter of flowscript and wrote the first
Cocoon-based blogging tool.
Marc is working intensively on the binding and flowscript integrations
of Woody and cares a lot about Cocoon.
Please cast your votes.
Here are mines : +1 for both !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez dijo: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. +1 Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. +1 Antonio Gallardo
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez wrote: Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. +1 Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. +1 Joerg
Re: processing flow for map:call resource=/
Sylvain Wallez wrote: Joerg Heinicke wrote: snip / So we can consider resources as gosub and no more goto as stated in the doc. Moreover, since resources can be passed parameters, they are actually functions ! I can't remember if a formal vote occured on this, but people globally found this feature usefull. ^^ the man is so honest, there was actually a sigh of relieve throughout the entire galaxy :-) much of the viewed side-effects to be observed here: http://hubblesite.org/newscenter/archive/ Time to update the docs... I'm prepping up a rewrite of some the wiki pages as a doco patch (unless someone beats me to it) Sylvain -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Hi All,
+1 for both - Welcome Marc and Ugo! :)
Cheers,
Marcus
On Mon, Jul 28, 2003 at 03:46:49PM +0200, Sylvain Wallez wrote:
Hi team,
I'd like to propose two people for Cocoon committership : Ugo Cei and
Marc Portier.
Ugo has been there for years (the archives show his first post back in
July 2000!), has been an early adopter of flowscript and wrote the first
Cocoon-based blogging tool.
Marc is working intensively on the binding and flowscript integrations
of Woody and cares a lot about Cocoon.
Please cast your votes.
Here are mines : +1 for both !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
--
.
,,$, Marcus Crafter
;$' ':Computer Systems Engineer
$: : ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$,_/\ :' 60327 Frankfurt Germany
' /(
\_'
.
:
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
On Mon, 28 Jul 2003 15:46:49 +0200, Sylvain Wallez [EMAIL PROTECTED] said: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. Please cast your votes. Here are mines : +1 for both ! +1 to both (eee! My first vote!) Upayavira
RE: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez wrote: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. Please cast your votes. Here are mines : +1 for both ! Sylvain I didn't realise they weren't! +1 for both. Are there any other regular [PATCH]ers who deserve this? J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
On 28.Jul.2003 -- 03:46 PM, Sylvain Wallez wrote: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. +1 Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. +1 Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Here are mines : +1 for both ! +1 for both -- Torsten
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez wrote, On 28/07/2003 15.46: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. +1 Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [RT] Adaptive Caching
Stefano Mazzocchi [EMAIL PROTECTED] wrote: NOTE: this is a refactoring of an email I wrote 2 1/2 years ago. snip on entire contents/ Stefano, had a little more time to read this last week: Memphis got hit by some 85 mph winds, no power at our house for a week yet, but I have a printed copy... (See http://slideshow.gomemphis.com/slideshow.cfm?type=GOMEMPHISID=stormpics NUM=8 for an idea of what we got hit with; as of writing this slides 50, 51, 57 are from just down the block. We had one fence broken, some torn up screens, one air conditioner damaged, but amazingly no other damage to our house.) The little reading I fit in between moving tree branches off our property triggered more ancient memories on paging algorithms. Instead of trying to dig up my old notes and books I did a Goggle on paging algorithm and found lots of good references that I think may be of some use. In particular note: http://www.cs.duke.edu/~jsv/Papers/catalog/node93.html Essentially, you can treat Cocoon as having multiple applications (pipelines) producing working sets (SAX streams) and directly apply the tons of research done in this area. You do have to introduce the concept of page size, but this can be arbitrarily small or perhaps using some (average?) OS page size might be reasonable? If you do the Google search you'll notice the references to randomized paging algorithms. I didn't chase these very far other than to determine that at least one author shows that they can perform as good as conventional algorithms but not as good as the theoretical best.
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
+1 for both. Chris Sylvain Wallez wrote: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. Please cast your votes. Here are mines : +1 for both ! Sylvain
Re: CODE FREEZE for 2.1rc1
Carsten Ziegeler wrote:
Hi,
I will start with the release tomorrow morning around 10:00 european time, so please don't commit from that time on until I finished building the release.
PS: and put the champaigne into the fridge.
It's spelled champagne ! Wines are serious things in France ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez wrote: Hi team, Hi team again, many thanx for the welcoming votes, quite a honorable surprise I'll do my best to live up to the expectations and high standards Really short introduction on http://wiki.cocoondev.org/Wiki.jsp?page=MarcPortier and there really isn't that much to add (meaning: just ask if you'ld like to know) maybe some more personal remarks: - my last name looks french-sounding but has a flemish sounding variant to be used (no sound files available, but I'm largely custom to quite bad international versions anyway, so I will not mind... you might just want to consider the first name as a safe alternative though) - live together with the mother of my beautiful two kids (waiting for a family BBQ downstairs so I should hurry up) - 'learning' and his sharing counterpart: 'teaching' is what I like most in this life... it happened to get organized around java and xml at some point... almost at the moment I met Steven, then I met Bruno, then we started outerthought, and now this :-) As for my much hyped spelling (and general usage) of the English language, there is one quote I really like: http://www.brainyquote.com/quotes/quotes/a/q138608.html (A.A Milne should be known for Whiney The Poeh -- Winny the Pooh!) if it gets too messy, then start to think of it as a poem :-) thx again, -marc= I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. Please cast your votes. Here are mines : +1 for both ! Sylvain -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Webdavapps with Cocoon
Stefano Mazzocchi wrote: the single pieces that make that result happen. Even the simplest XSLT transformation can't be reversely applied, so now there is no way to understand how an resource should be treated in a symmetric way when requested or uploaded. Oh yes, you can hm, do we really need to look at it as symmetric? No, we don't. I've been thinking about this a lot and I think that symmetry is not only a holy grail, but it's the wrong grail to consider holy. Read on. I know we are tempted to do so, but is it a must? It is tempting, but symmetry-driven design is bad. we must understand what we want, why and what is limiting us. I knew that I would have triggered this comment. However, let me just state that not everything that contains simmetry in inherently bad: in most case I'm totally with you, but there are situations where you need simmetry, and WebDAV looks to me (potentially) as one of those. I see that you don't particularily like the web folders metaphore, and I'm with you when you say that this is just one of the possible DAV applications, yet it's quite an important one. However, thinking more about it, it might be cool to dd an SVG and see an XSL popping out: but the idea of exposing the wonderful world of Cocoon as a disk is too exciting to me to be left behind. :-) Note that on a real FS, everybody knows the difference between /home/blah/news and /home/blah/news/ because the OS enforces type checking on these (on a POSIX file system you cannot open a directory for writing as a file, for example). I don't see it. Actually /home/blah/news is a directory even if you don't put a trailing slash on it, and you can't have a file and a directory sharing the same name. But this is nitpicking. If I have a resource like http://blah.com/news/ and I want to edit, I could ask for http://blah.com:/news/ http://edit.blah.com/news/ http://blah.com/news/?view=edit; Well... yes and no: in a shared folders scenario this doesn't apply. And this is *exactly*, besides, where Cocoon might shine when compared to Zope: Zope supports WebDAV, but what you see from your shared folders are the bare zope components, with little or no way (AFAIK) to expose an aggregation or trasformation of both. Cocoon, instead, could offer a particular view to editors which is vitual and assembled on the fly for each particular request. The real problem is what's Nirvana for each of us: to me it would be just great to have a way of automatically expose a Cocoon pipeline both as an HTTP resource *and* as a DAV (editable) resource. Something like: map:pipeline dav=on This might implemented, as a default, in the Zope way (giving access to the bare resources) or, if overridden, in a custom way (filtering, aggregating and manipulating resources, as an example). But this requires simmetry to happen, so I guess it will remain just a dream. In your scenario, OTOH, there should be a particular sitemap configuration for each pipeline, which means that one will need to provide for every webdav exposed resource a particular configuration: see Guido's great example, it's really cool but it's also a PITA if you are to apply it in a more general way. I normally prefer the virtual-host approach. something like this [frontend] - [repository] - [backend] http://blah.com http://edit.blah.com where frontend and backend are separated (frontend might even be a static representation of the saved content (say, created by a cronned forrest every hour or so). The above setup removes you from the need from having to be symmetric. This is yet another approach: a different Cocoon with a different configuration. Feasible, but then again possibly unmaintainable since it requires to keep in sync two different pipeline *logics*. (they want to put back where they got I assume?) actually if you look at the combination of matchers/request-method-selector you wrote up it more looks like the request-method being part of the uri-request space almost? I dislike this. the action should not be encoded in the URI space. Definitely. 2) direction: Cocoon is clearly designed for an inside-out type of flow in mind, while WebDAV is fully bidirectional. this is not true anymore. with the ability to have pipeline dump their content on an outputstream if called from the flow, cocoon reached complete bydirectionality. I disagree here. Cocoon is bidirectional *if* flow is used, which is a serious limitation. Actually I've been struck by this lately, on a presentation engine we are building, and I see a possible solution (but it deserves an RT on its own). Design-wise it's difficult to adapt the G-T-S pattern to an incoming stream of data, I can't see why. Admittedly, there are generators who are hardly reusable in both in-out and out-in case (StreamGenerator or RequestGenerator, for example) but that is not a deficiency of the pipeline design, expecially now that the output stream
Re: [RT] Webdavapps with Cocoon
Stefano Mazzocchi wrote: Way cool, Guido ! But the bad thing about WebDAV on Windoze (aka webfolders) is that it's not a real filesystem : you cannot open the file directly from there, but only copy/paste it on a real filesystem. Or did I missed something ? no, you are right, webforlders sck! and they are as buggy as hell, expecially if you do webdav over https with digital certificates. forget it, you have to use a commercial application (don't remember its name). Could it be Xythos WebFile Client? Quick update about the CVSSource : I did a major rewrite for one of our projects (Gianugo : it's a CMS using dynamically-generated sxw files to edit content!), and it's now an Excalibur Source and supports crawling the version history (only on the main branch), tagging, cache validity, etc. I committed this new version this morning on cocoondev.org. OK, you made me drool. I'm updating it right away. :-) Since during this weekend I rewrote the repository part of Linotype for that, I want to see if it works on CVS too. And the next step is trying Guido's davmap example... it would be *extremely* cool! sure, but will be up to you do decide how to write your webdavapp. that's the point: cocoon should provide you the low level components and you compose them as you like. And please, think about not necessarily using flow. :-) But just as the aggregator is just a special generator, I was thinking of introducing the concept of an extractor which is just a generator but that expects serious payloads that contain inforamation that might be needed by the sitemap/flow to process the request (NOTE: both the sitemap and flow DO NOT have access to the pipeline content directly, and this should *NOT* change! this is the reason why we should introduce this 'extraction' concept) I'm starting to see some light. Care to come up with an example? In other words, streamed requests aren't so much different from regular requests : it's just that incoming data is more complex and that decoding is not handled transparently by the servlet engine. Once decoded, the processing model can be the same as usual. Hmmm, h, h, you are triggering second order thinking h... I need a whiteboard... I'll be back soon. Can't wait. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
DO NOT REPLY [Bug 21609] - [PATCH] NaN error in XSP version of the calc flow example
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21609. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21609 [PATCH] NaN error in XSP version of the calc flow example --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 17:23 --- Sorry my mistake. It doesn't look like this is still necessary. I misread the code. I believe cocoon.request.name doesn't work because 'name' is a variable not the name of a request parameter. So the patch should most likely be EITHER - return parseFloat(cocoon.request.name); + return parseFloat(cocoon.request.getParameter(name)); OR - return parseFloat(cocoon.request.name); + return parseFloat(eval(cocoon.request. + name));
cvs commit: cocoon-2.1/src/documentation/xdocs/userdocs index.xml
coliver 2003/07/28 10:41:58 Modified:src/documentation/xdocs/userdocs index.xml Log: added link to continuation page example Revision ChangesPath 1.4 +1 -1 cocoon-2.1/src/documentation/xdocs/userdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/userdocs/index.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.xml 27 Jul 2003 00:59:54 - 1.3 +++ index.xml 28 Jul 2003 17:41:58 - 1.4 @@ -25,7 +25,7 @@ p If you've been writing web applications with any other system you should also take a look at Cocoon link href=flow/index.htmlFlowscript/link, - which makes writing complex Web applications easy with Cocoon. Complex multi-page interactions can be described easily as blocking function calls. + which makes writing complex Web applications easy with Cocoon. Complex multi-page interactions can be link href=flow/continuations.htmldescribed/link easily as blocking function calls. /p p Come back often...this guide is being updated regularly.
Re: Cocoon and OJB with JDO.
Ok question: I have got lost in the OJB docs... I got your example working ok, but where can i get some documentation on how to code a structure like this: class contact: id name phone class client id accountName address class timeticket id hours desc client contact ie, have a lookup for contact and client (two separate tables) inside the timeticket class (its own table with the id values from the other two) I just dont see how to describe the timticket class in the .jdo file. JD - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 28, 2003 5:30 AM Subject: Cocoon and OJB with JDO. Hi Cocooners! I am currently working trying to use OJB with Cocoon. I already wrote a simple example and I invite you to see it at wiki. :=) http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO Please note this is a first attempt to use an alternative project to Hibernate. I choosed OJB because it is under the Apache umbrella. This simple fact will allow us to integrate it in Cocoon. The problem with Hibernate it the LPGL. :( My idea is that we can build a OJB block and make the life easier for people building database webapp. this block can be easily used with Flow. I am looking for it. The OJB can be used as the model of the MVC design paradigm. Currently we are working in the Controller, called Flow. An for the View we have 2 candidates Woody and JXForms. I will keep working on this stuff and post to the list the results of that. Of course, I am not too smart ;) I need to thanks to Ricardo Rocha for the advise: Forget XSP and check JDO Best Regards, Antonio Gallardo.
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor TreeProcessor.java
cziegeler2003/07/28 11:09:48
Modified:src/java/org/apache/cocoon/components/treeprocessor
TreeProcessor.java
Log:
It's that easy...removed unnecessary environment handling for internal calls and
finally fixed wrong sitemap manager
Revision ChangesPath
1.9 +2 -4
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java
Index: TreeProcessor.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/TreeProcessor.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- TreeProcessor.java28 Jul 2003 17:50:41 - 1.8
+++ TreeProcessor.java28 Jul 2003 18:09:48 - 1.9
@@ -323,7 +323,7 @@
}
// and now process
-CocoonComponentManager.enterEnvironment(environment, this.manager, this);
+CocoonComponentManager.enterEnvironment(environment,
this.sitemapComponentManager, this);
try {
return this.rootNode.invoke(environment, context);
} finally {
@@ -342,7 +342,6 @@
context.enableLogging(getLogger());
-CocoonComponentManager.enterEnvironment(environment, this.manager, this);
try {
if ( process(environment, context) ) {
return context.getProcessingPipeline();
@@ -350,7 +349,6 @@
return null;
}
} finally {
-CocoonComponentManager.leaveEnvironment();
context.dispose();
}
}
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components LifecycleHelper.java
cziegeler2003/07/28 11:26:01
Modified:src/java/org/apache/cocoon/components LifecycleHelper.java
Log:
Simple code formatting
Revision ChangesPath
1.4 +151 -163
cocoon-2.1/src/java/org/apache/cocoon/components/LifecycleHelper.java
Index: LifecycleHelper.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/LifecycleHelper.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- LifecycleHelper.java 24 Jul 2003 10:30:52 - 1.3
+++ LifecycleHelper.java 28 Jul 2003 18:26:01 - 1.4
@@ -84,35 +84,34 @@
// FIXME : need to handle also LogEnabled.
-public class LifecycleHelper
-{
+public class LifecycleHelper {
/** The Logger for the component
*/
-private Logger m_logger;
+final private Logger m_logger;
/** The Context for the component
*/
-private Context m_context;
+final private Context m_context;
/** The component manager for this component.
*/
-private ComponentManagerm_componentManager;
+final private ComponentManager m_componentManager;
/** The service manager for this component.
*/
-private ServiceManagerm_serviceManager;
+final private ServiceManager m_serviceManager;
/** The configuration for this component.
*/
-private Configuration m_configuration;
+final private Configuration m_configuration;
/** The RoleManager for child ComponentSelectors
*/
-private RoleManager m_roles;
+final private RoleManager m_roles;
/** The LogKitManager for child ComponentSelectors
*/
-private LogKitManager m_logkit;
+final private LogKitManager m_logkit;
/**
* Construct a new codeLifecycleHelper/code that can be used repeatedly to
@@ -127,34 +126,47 @@
* @param roles the codeRoleManager/code to pass to
codeDefaultComponentSelector/codes.
* @param configuration the codeConfiguration/code object to pass to new
instances.
*/
-public LifecycleHelper( final Logger logger,
-final Context context,
-final ComponentManager componentManager,
-final RoleManager roles,
-final LogKitManager logkit,
-final Configuration configuration )
-{
+public LifecycleHelper(final Logger logger,
+final Context context,
+final ComponentManager componentManager,
+final RoleManager roles,
+final LogKitManager logkit,
+final Configuration configuration) {
m_logger = logger;
m_context = context;
m_componentManager = componentManager;
m_roles = roles;
m_logkit = logkit;
m_configuration = configuration;
+m_serviceManager = null;
}
-public LifecycleHelper( final Logger logger,
-final Context context,
-final ServiceManager serviceManager,
-final RoleManager roles,
-final LogKitManager logkit,
-final Configuration configuration )
-{
+/**
+ * Construct a new codeLifecycleHelper/code that can be used repeatedly to
+ * setup several components. bNote/b : if a parameter is codenull/code,
+ * the corresponding method isn't called (e.g. if codeconfiguration/code is
+ * codenull/code, codeconfigure()/code isn't called).
+ *
+ * @param logger the codeLogger/code to pass to codeLogEnabled/codes,
unless there is
+ *a codeLogKitManager/code and the configuration specifies a logger
name.
+ * @param context the codeContext/code to pass to
codeContexutalizable/codes.
+ * @param serviceManager the service manager to pass to
codeServiceable/codes.
+ * @param roles the codeRoleManager/code to pass to
codeDefaultComponentSelector/codes.
+ * @param configuration the codeConfiguration/code object to pass to new
instances.
+ */
+public LifecycleHelper(final Logger logger,
+final Context context,
+final ServiceManager serviceManager,
+final RoleManager roles,
+final LogKitManager logkit,
+final Configuration configuration) {
m_logger = logger;
m_context = context;
m_serviceManager = serviceManager;
m_roles = roles;
m_logkit = logkit;
m_configuration = configuration;
+m_componentManager = null;
}
/**
@@
Re: [RT] Webdavapps with Cocoon
Sylvain Wallez wrote: But the bad thing about WebDAV on Windoze (aka webfolders) is that it's not a real filesystem : you cannot open the file directly from there, but only copy/paste it on a real filesystem. Or did I missed something ? No. To open a file from a MS webfolder you need to use 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, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
Re: [RT] Webdavapps with Cocoon
Gianugo Rabellino wrote: Stefano Mazzocchi wrote: snip/ this stuff sounds like flow integration on a separate section of the uri-request-space? I totally agree. i think it would be fairly easy to implement a full dav stack with flowscript and a few java components that wrap around a repository (could be as simple as a file system) Then again, you're not talking about integrating WebDAV into Cocoon, but just give some hooks (something that can be done pretty much now already) to make webdavapps using flow. Now, while flow surely rocks, I feel that WebDAV support, as an HTTP extension, should be reflected in the sitemap too. Please let me add that a major difference between a webapp and a webdavapp is that (as Stefano already pointed out) we don't control the client side. A webdavapp is always stateless on the server as the (fat) client manages the state. So it should 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 PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
RE: [PATCH] CocoonCrawler enhancements
Hi Upayavira,
I missed your email somehow. Yep this one is used by the Lucene block.
It depends on a link view being available in the sitemap and crawls
cocoon over http. I had started implementing a publisher block in the
same vein as the Lucene block because I couldn't really see how to
achieve it the way we discussed a few weeks back, i.e. within the VM,
without first changing a lot internals. This patch is a step toward
that.
I haven't had time to continue with it unfortunately. Also, the boss
decided on our current publisher - that depends on incompatible usage of
cocoon internals - as we already put some effort into that. But I can't
see how I could change the code easily so that it integrates with the
current cocoon. I hope to continue with the cocoon publisher block in
the fall. Sorry, I should have let you know what was happening before
especially because you showed so much interest before.
In a nutshell the idea I had for the Publisher interface:
interface Publisher extends SingleThreaded {
/**
* parametrize the publisher with the location where
* from where to start publishing and the depth to publish
* to.
*/
void publish(URL url, int depth);
/**
* after parametrizing the publisher as above, obtain a
* an iterator of Publications on the publish path.
*/
Iterator iterator();
}
This interface is inspired by the CocoonCrawler interface that I found
very elegantly allows client code control over it through the iterator.
The Iterator could hold Publication objects:
Interface Publication {
Long lastModifiedDate();
Long lastPublicationDate();
void publish();
}
The publisher could eventually also have an implementation that
processes directly on the Cocoon object instead of over http. That were
my initial ideas about that I haven't been able to continue yet. Off
course it could be implemented in a hundred other ways equally elegant
:)
Regards,
Unico
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: maandag 28 juli 2003 20:37
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] CocoonCrawler enhancements
Upayavira wrote:
Unico,
I've seen this crawler before, and wondered what it is used for. Can
you
tell me?
It is used to create a lucene search index. See lucene block,
SimpleLuceneCocoonIndexerImpl, and samples
Vadim
Re: Cocoon and OJB with JDO.
JD Daniels dijo: Ok question: I have got lost in the OJB docs... I got your example working ok, but where can i get some documentation on how to code a structure like this: class contact: id name phone class client id accountName address class timeticket id hours desc client contact ie, have a lookup for contact and client (two separate tables) inside the timeticket class (its own table with the id values from the other two) Hi: Thanks for take your time checking the example. :) I am currently working on another example integrating now with woody. For a nice introduction on JDO see (as usual) on IBM developers network. The tutorial is called: Hands on Java Data Objects http://www-106.ibm.com/developerworks/java/edu/j-dw-javajdo-i.html For OJB check the tutorial4: http://db.apache.org/ojb/tutorial4.html I just dont see how to describe the timticket class in the .jdo file. The answer is on the IBM tutorial linked above. ;) Best Regards, Antonio Gallardo
DO NOT REPLY [Bug 21945] New: - [PATCH] WebDAV sitemap sample
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945 [PATCH] WebDAV sitemap sample Summary: [PATCH] WebDAV sitemap sample Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A simplified sitemap using request input module instead of RequestMethodSelector
DO NOT REPLY [Bug 21945] - [PATCH] WebDAV sitemap sample
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21945 [PATCH] WebDAV sitemap sample --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 19:50 --- Created an attachment (id=7549) sitemap.xmap
cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl AbstractDatatypeBuilder.java
cziegeler2003/07/28 13:03:13 Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl AbstractDatatypeBuilder.java Log: Organizing imports Revision ChangesPath 1.8 +9 -10 cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java Index: AbstractDatatypeBuilder.java === RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl/AbstractDatatypeBuilder.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- AbstractDatatypeBuilder.java 28 Jul 2003 15:57:15 - 1.7 +++ AbstractDatatypeBuilder.java 28 Jul 2003 20:03:13 - 1.8 @@ -50,22 +50,21 @@ */ package org.apache.cocoon.woody.datatype.typeimpl; -import org.apache.cocoon.woody.datatype.*; -import org.apache.cocoon.woody.datatype.convertor.Convertor; -import org.apache.cocoon.woody.datatype.convertor.ConvertorBuilder; -import org.apache.cocoon.woody.util.DomHelper; -import org.apache.cocoon.woody.util.SimpleServiceSelector; -import org.apache.cocoon.woody.Constants; import org.apache.avalon.framework.configuration.Configurable; import org.apache.avalon.framework.configuration.Configuration; import org.apache.avalon.framework.configuration.ConfigurationException; import org.apache.avalon.framework.service.ServiceException; -import org.apache.avalon.framework.service.Serviceable; import org.apache.avalon.framework.service.ServiceManager; -import org.apache.excalibur.source.Source; -import org.apache.excalibur.source.SourceResolver; +import org.apache.avalon.framework.service.Serviceable; +import org.apache.cocoon.woody.Constants; +import org.apache.cocoon.woody.datatype.DatatypeBuilder; +import org.apache.cocoon.woody.datatype.DatatypeManager; +import org.apache.cocoon.woody.datatype.ValidationRule; +import org.apache.cocoon.woody.datatype.convertor.Convertor; +import org.apache.cocoon.woody.datatype.convertor.ConvertorBuilder; +import org.apache.cocoon.woody.util.DomHelper; +import org.apache.cocoon.woody.util.SimpleServiceSelector; import org.w3c.dom.Element; -import java.io.IOException; /** * Abstract base class for datatype builders, most concrete datatype builders
[RT] Revisiting Woody's form definition
Hi all, One week after my first RT about Woody, after having read Marc and Bruno's answers and after lots of background thinking high in the mountain, here comes some more about Woody. I have abandoned (for now?) my idea of form-defining template which seems not so intuitive nor realistic, and tackled the problem of reuse and distribution of the various concerns between the different configuraiton files. So let's go... From a developper point of view, two of the main usability differences between Woody and XMLForm are that : 1/ XMLForm doesn't require datatypes to be declared, since it relies on JXPath's (limited) parsing features to parse values. 2/ Woody requires forms to be defined separately from their usage (i.e. the form template) while XMLForm defines forms inline without requiring a separate file. These differences, implied by Woody's greater structuration and validation features introduces some usage heaviness (see my previous RT). Now isn't it possible to make Woody's more lightweight without sacrificing any of its features ? My opinion is yes, and this RT proposes some modifications towards this goal. Please read the whole thing before replying, since after the analysis come some more concrete proposals ! +---+ | Analysis of a Woody field | +---+ Let's split a Woody field into its various components (repeaters are a special case that will be considered separately) to find out how we can reorganize the form definition, template and binding. Considering all Woody files, a field is composed of : - a base datatype (string, integer, boolean, etc) and its constraints (range, regexp pattern, etc) - convertors (conversion between a typed value and its string representation) - a selection list of possible values - visual elements (label, hint, hotkey, etc) - styling data (foreing markup inside wt:widget in the form template) - a binding to application data Base type and its constraints - A field's datatype is defined by a base type (integer, date, boolean, etc) and some validation constraints (length, range, regexp pattern, etc). Such datatypes are very likely to belong to the application model domain, and a given datatype is very likely to be used by several fields and in several forms. We could thus clearly benefit of having some form-independent datatypes catalogues, ensuring overall consistency. Example (leaving out namespaces) : datatype id=email basetype=string validation email/ /validation /datatype We can then define a field using : field id=home-email datatype ref=email/ /field or even, if no additional elements are required inside the datatype field id=home-email datatype=email/ Separating the datatypes dictionary would also allow to use other type definition languages, such as XMLSchema datatype (i.e. simpleType declarations). When forms are used to edit XML documents, this can avoid the need to rewrite the existing schema into a Woody-speficic definition, with all the implied consistency and maintainability burdens. Of course, there will be some fields whose datatype will not be reused. For these, the current definition (datatype inside field) is still valid, and can be considered as an anonymous inline datatype. Furthermore, validations can be chained : a field can define constraints that augment those defined on a datatype. Let's consider the password example : Datatypes dictionary : datatype id=password basetype=string validation length min=6 valid-password/ !-- check the presence of non-alpha characters -- /validation /datatype Form definition : field id=password datatype ref=password validation assert test=password = confirmPassword failmessageThe passwords must be equal/failmessage /assert /validation /datatype /field field id=confirmPassword datatype=password/ Convertors -- Convertors (or should it be converters ?) define the locale-dependent conversions between a value and its string representation. This is where e.g. date formats are defined. Currently, Woody defines converters inside datatype which is inside field. But if we separate datatypes as suggested above, do converters belong to fields or to datatypes ? In my opinion, to neither and to both : - to neither, because just as datatypes are independent from fields, convertors act on a particular base type (double, date, etc) and have no relationships with the particular constraints defined by a datatype nor with any particular form field. So just as for datatypes, we can thus have a format catalogue reused by several forms and/or datatypes. - to both, because a datatype may have a default or preferred converter, but still leave room for a particular field to use a special custom format. The format catalogue could then be composed of formats as in the following example : format id=short-date basetype=date
[2.1cvs][flow] Properties files cannot be located?
Hello, Is it possible for javascript code in the flow engine to locate properties files that it might need. I have a JAXBContext that I'm trying to use from the javascript and i get javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package my.jaxb.package Any immediate ideas? TIA /S __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
On Mon, Jul 28, 2003 at 03:46:49PM +0200, Sylvain Wallez wrote:
Hi team,
I'd like to propose two people for Cocoon committership : Ugo Cei and
Marc Portier.
+1 and +1
--Jeff
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925 FOM Request object does not provide access to all the request's values --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 22:22 --- Created an attachment (id=7553) Rest of missing functions
DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925 FOM Request object does not provide access to all the request's values [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 22:23 --- I've attached a patch with the rest of the missing FOM_Request functions. Hope it's not too late for inclusion before tomorrow's code freeze.
DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925 FOM Request object does not provide access to all the request's values [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEW
Re: [2.1cvs][flow] Properties files cannot be located?
Steven Cummings wrote: Hello, Is it possible for javascript code in the flow engine to locate properties files that it might need. I have a JAXBContext that I'm trying to use from the javascript and i get javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package my.jaxb.package Any immediate ideas? TIA IIRC: Have your properties in WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader to locate properties. (OT?) Vadim
Re: [2.1cvs][flow] Properties files cannot be located?
--- Vadim Gritsenko [EMAIL PROTECTED] wrote: Steven Cummings wrote: Hello, Is it possible for javascript code in the flow engine to locate properties files that it might need. I have a JAXBContext that I'm trying to use from the javascript and i get javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package my.jaxb.package Any immediate ideas? TIA IIRC: Have your properties in WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader to locate properties. Actually I've tried both, unpacked in classes and in the original jar in lib. Neither works through flow. But my JAXB works otherwise, so I don't think it's as simple as that. (OT?) Off topic? I hope not, I started it! I just thought it would be more appropriate for the dev-list since it is still changing. Sorry if it's not! Vadim /S __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: [RT] Webdavapps with Cocoon
Stefano Mazzocchi wrote: On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote: ... In other words, streamed requests aren't so much different from regular requests : it's just that incoming data is more complex and that decoding is not handled transparently by the servlet engine. Once decoded, the processing model can be the same as usual. Hmmm, h, h, you are triggering second order thinking h... I need a whiteboard... I'll be back soon. Are you thinking in terms of MultipartParser, SOAPParser, ...? Vadim
Re: [2.1cvs][flow] Properties files cannot be located?
Steven Cummings wrote: --- Vadim Gritsenko [EMAIL PROTECTED] wrote: Steven Cummings wrote: Hello, Is it possible for javascript code in the flow engine to locate properties files that it might need. I have a JAXBContext that I'm trying to use from the javascript and i get javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package my.jaxb.package Any immediate ideas? TIA IIRC: Have your properties in WEB-INF/classes/my/jaxb/package/jaxb.properties. Jaxb uses classloader to locate properties. Actually I've tried both, unpacked in classes and in the original jar in lib. Neither works through flow. But my JAXB works otherwise, so I don't think it's as simple as that. Does not work through flow but works through, say, XSP? Then it might be some flow related issue. Vadim
cvs commit: cocoon-2.1/lib jars.xml
vgritsenko2003/07/28 19:07:32 Modified:.status.xml lib jars.xml Added: src/blocks/fop/lib fop-0.20.5.jar Removed: src/blocks/fop/lib fop-0.20.5rc3a.jar Log: Update FOP to the released version. Update todo list: remove some items. Revision ChangesPath 1.97 +11 -30cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.96 retrieving revision 1.97 diff -u -r1.96 -r1.97 --- status.xml28 Jul 2003 11:28:22 - 1.96 +++ status.xml29 Jul 2003 02:07:31 - 1.97 @@ -7,7 +7,7 @@ !-- CVS $Id$:-- status - developers + developers !-- in strict alphabetical order -- person name=Donald Ball email=[EMAIL PROTECTED] id=DB/ person name=Nicola Ken Barozzi email=[EMAIL PROTECTED] id=NKB/ @@ -51,7 +51,7 @@ person name=Sylvain Wallez email=[EMAIL PROTECTED] id=SW/ person name=Carsten Ziegeler email=[EMAIL PROTECTED] id=CZ/ person name=Volunteer needed email=[EMAIL PROTECTED] id=open/ - /developers + /developers todo actions priority=high @@ -70,13 +70,9 @@ /action action context=code assigned-to=open - For 2.1: use (only) released versions of excalibur (xml, source, store etc). - This requires a release of those components in excalibur. -/action - -action context=code assigned-to=open - Complete (means put everything we know of into even if it has to be - commented) the cocoon.xconf file and put descriptions into it + For 2.1: use (only) released versions of excalibur (collections, + concurrent, source, store, xmlutil). This requires a release of those + components in excalibur. /action action context=build assigned-to=open @@ -92,7 +88,7 @@ action context=code assigned-to=NKB For 2.1: Make comprehensive samples with the handle-errors sitemap and real world use cases. Add also specific Selector and a FaqBuilder to be used by the - as a NotifyingBuilder. + NotifyingBuilder. /action action context=code assigned-to=open @@ -112,18 +108,6 @@ /action action context=code assigned-to=open - Move complete Source implementation to Excalibur. -/action - -action context=code assigned-to=open - Documentation to be published by Forrest. - See the - link href=http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal;proposal/link - under development. (Note: the generation of the docs should be completely done by - Forrest. So we should remove the deprecated docs generation stuff within Cocoon.) -/action - -action context=code assigned-to=open Finish moving the scratchpad stuff in main trunk. /action @@ -145,7 +129,6 @@ a problem during the serialization of the transient store, if the servlet container were stopped. /action - /actions actions priority=medium @@ -167,13 +150,8 @@ /action action context=code -!-- FIXME: remove ... this already above -- - For 2.1: Make a guide on how to upgrade Cocoon, and see how this can be eased. -/action - -action context=code For 2.1: Redesign FragmentExtractorGenerator/Transformer so that it works on a clustered - server : store fragments in the session rather than in a local store. br/ + server: store fragments in the session rather than in a local store. br/ This couldn't work, because if you working with caching pipelines, you cannot be sure that the entries are in the session(Stephan). /action @@ -189,6 +167,9 @@ changes release version=@version@ date=@date@ + action dev=VG type=update +Updated FOP to the latest released version, 0.20.5. + /action action dev=GR type=add Added delete capabilities to the SourceWritingTransformer. /action 1.1 cocoon-2.1/src/blocks/fop/lib/fop-0.20.5.jar Binary file 1.71 +2 -2 cocoon-2.1/lib/jars.xml Index: jars.xml === RCS file: /home/cvs/cocoon-2.1/lib/jars.xml,v retrieving revision 1.70 retrieving revision 1.71 diff -u -r1.70 -r1.71 --- jars.xml 26 Jul 2003 13:26:47 - 1.70 +++ jars.xml 29 Jul 2003 02:07:32 - 1.71 @@ -430,7 +430,7 @@ the XSL recommendation and then turns it into a PDF document. /description used-byFOP serializer (fop block)/used-by - libfop/lib/fop-0.20.5rc3a.jar/lib + libfop/lib/fop-0.20.5.jar/lib homepagehttp://xml.apache.org/fop//homepage /file
cvs commit: cocoon-2.1/src/webapp/samples/i18n/translations menu.xml menu_de.xml menu_el.xml menu_en.xml menu_in.xml menu_ja.xml menu_ko.xml menu_ru.xml menu_zh_CN.xml menu_zh_TW.xml messages.xml messages_de.xml messages_el.xml messages_en.xml messages_es.xml messages_fr.xml messages_fr_CH.xml messages_hy.xml messages_in.xml messages_ja.xml messages_ko.xml messages_pl.xml messages_pt.xml messages_ru.xml messages_tr.xml messages_zh_CN.xml messages_zh_TW.xml
vgritsenko2003/07/28 19:36:31 Modified:src/webapp/samples/i18n/translations menu.xml menu_de.xml menu_el.xml menu_en.xml menu_in.xml menu_ja.xml menu_ko.xml menu_ru.xml menu_zh_CN.xml menu_zh_TW.xml messages.xml messages_de.xml messages_el.xml messages_en.xml messages_es.xml messages_fr.xml messages_fr_CH.xml messages_hy.xml messages_in.xml messages_ja.xml messages_ko.xml messages_pl.xml messages_pt.xml messages_ru.xml messages_tr.xml messages_zh_CN.xml messages_zh_TW.xml Log: Update japanese translation. Changed file headers to corporate standard while I was at it. Submitted by: Tetsuya Kitahata [EMAIL PROTECTED] Revision ChangesPath 1.2 +7 -2 cocoon-2.1/src/webapp/samples/i18n/translations/menu.xml Index: menu.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu.xml 9 Mar 2003 00:11:11 - 1.1 +++ menu.xml 29 Jul 2003 02:36:30 - 1.2 @@ -1,6 +1,11 @@ ?xml version=1.0 encoding=UTF-8? -!-- Default (English) message catalogue file for menu in Cocoon 2 i18n sample -- -!-- $Id$ -- + +!--+ +| Default (English) message catalogue file for menu in Cocoon 2 i18n sample +| +| CVS $Id$ ++-- + catalogue xml:lang=en message key=Apache Cocoon i18n SamplesApache Cocoon i18n Samples/message message key=SamplesSamples/message 1.2 +6 -2 cocoon-2.1/src/webapp/samples/i18n/translations/menu_de.xml Index: menu_de.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_de.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu_de.xml 26 Mar 2003 07:32:20 - 1.1 +++ menu_de.xml 29 Jul 2003 02:36:30 - 1.2 @@ -1,6 +1,10 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- German message catalogue file for menu in Cocoon 2 i18n sample -- -!-- $Id$ -- + +!--+ +| German message catalogue file for menu in Cocoon 2 i18n sample +| +| CVS $Id$ ++-- catalogue xml:lang=de message key=Apache Cocoon i18n SamplesApache Cocoon i18n Beispiele/message 1.2 +7 -3 cocoon-2.1/src/webapp/samples/i18n/translations/menu_el.xml Index: menu_el.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_el.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu_el.xml 9 Mar 2003 00:11:11 - 1.1 +++ menu_el.xml 29 Jul 2003 02:36:30 - 1.2 @@ -1,7 +1,11 @@ ?xml version=1.0 encoding=UTF-8? -!-- edited with XMLSPY v5 rel. 2 U (http://www.xmlspy.com) by Stavros Kounis (private) -- -!-- Greek message catalogue file for menu in Cocoon 2 i18n sample -- -!-- $Id$ -- + +!--+ +| Greek message catalogue file for menu in Cocoon 2 i18n sample +| +| CVS $Id$ ++-- + catalogue xml:lang=gr message key=Apache Cocoon i18n SamplesApache Cocoon i18n Παραδείγματα/message message key=SamplesΠαραδείγματα/message 1.2 +7 -2 cocoon-2.1/src/webapp/samples/i18n/translations/menu_en.xml Index: menu_en.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_en.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu_en.xml 9 Mar 2003 00:11:11 - 1.1 +++ menu_en.xml 29 Jul 2003 02:36:30 - 1.2 @@ -1,6 +1,11 @@ ?xml version=1.0 encoding=UTF-8? -!-- English message catalogue file for menu in Cocoon 2 i18n sample -- -!-- $Id$ -- + +!--+ +| English message catalogue file for menu in Cocoon 2 i18n sample +| +| CVS $Id$ ++-- + catalogue xml:lang=en message key=Apache Cocoon i18n SamplesApache Cocoon i18n Samples/message message key=SamplesSamples/message 1.2 +7 -2 cocoon-2.1/src/webapp/samples/i18n/translations/menu_in.xml Index: menu_in.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/i18n/translations/menu_in.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- menu_in.xml 26 Mar 2003 07:32:20 - 1.1 +++ menu_in.xml 29 Jul 2003 02:36:30 - 1.2 @@ -1,6 +1,11 @@ ?xml version=1.0 encoding=UTF-8? -!--
Re: [RT] Updating our marketing strategy
Stefano Mazzocchi wrote: Cocoon is glue and duct tape for your web needs. ... I propose to choose the humble one. I guess we are all agree with your RT. What's next -- what we are going to update? :) Vadim
cvs commit: cocoon-2.1/src/webapp/samples/xinclude sitemap.xmap
vgritsenko2003/07/28 20:15:48 Modified:src/blocks/authentication-fw/conf authentication-gen.xmap src/blocks/authentication-fw/samples sitemap.xmap src/blocks/batik/conf svg.generation.xmap src/blocks/batik/samples sitemap.xmap src/blocks/bsf/conf bsf.xmap src/blocks/databases/samples sitemap.xmap src/blocks/fop/samples sitemap.xmap src/blocks/html/conf tidy.xmap src/blocks/html/samples sitemap.xmap src/blocks/jsp/conf jsp.generator.xmap src/blocks/linotype/samples sitemap.source.xmap sitemap.xmap src/blocks/mail/samples sitemap.xmap src/blocks/petstore/samples sitemap.xmap src/blocks/php/conf php.xmap src/blocks/poi/samples sitemap.xmap src/blocks/portal-fw/conf portal-gen.xmap src/blocks/profiler/conf profiler.xmap src/blocks/profiler/samples sitemap.xmap src/blocks/proxy/conf proxy.xmap wsproxy.xmap src/blocks/slide/conf slide-generator.xmap src/blocks/slide/samples sitemap.xmap src/blocks/velocity/conf velocity.xmap src/blocks/web3/samples sitemap.xmap src/blocks/woody/samples sitemap.xmap src/blocks/xmldb/conf xmldb.deprecated.xmap src/webapp sitemap.xmap src/webapp/samples sitemap.xmap src/webapp/samples/hello-world sitemap.xmap src/webapp/samples/i18n sitemap.xmap src/webapp/samples/simpleform sitemap.xmap src/webapp/samples/sites sitemap.xmap src/webapp/samples/sources sitemap.xmap src/webapp/samples/stream sitemap.xmap src/webapp/samples/xinclude sitemap.xmap Log: Add views definitions to the samples sitemaps. Removed label data, it was almost identical to label content. data was used by content view, content was used by pretty-content (or was it the other way?). Now both views use same label which makes more sense. Revision ChangesPath 1.3 +1 -1 cocoon-2.1/src/blocks/authentication-fw/conf/authentication-gen.xmap Index: authentication-gen.xmap === RCS file: /home/cvs/cocoon-2.1/src/blocks/authentication-fw/conf/authentication-gen.xmap,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- authentication-gen.xmap 3 May 2003 16:12:23 - 1.2 +++ authentication-gen.xmap 29 Jul 2003 03:15:45 - 1.3 @@ -5,5 +5,5 @@ map:generator name=auth-conf src=org.apache.cocoon.webapps.authentication.generation.ConfigurationGenerator - label=content,data/ + label=content/ /xmap 1.5 +61 -72cocoon-2.1/src/blocks/authentication-fw/samples/sitemap.xmap Index: sitemap.xmap === RCS file: /home/cvs/cocoon-2.1/src/blocks/authentication-fw/samples/sitemap.xmap,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- sitemap.xmap 26 May 2003 07:54:09 - 1.4 +++ sitemap.xmap 29 Jul 2003 03:15:45 - 1.5 @@ -1,35 +1,27 @@ ?xml version=1.0? -map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0; -!-- === Components -- - - map:components - - map:generators default=file/ - map:transformers default=xslt/ - map:readers default=resource/ - map:serializers default=html/ - map:matchers default=wildcard/ - map:selectors default=browser/ - /map:components +!--+ +| Authentiction block samples sitemap. +| +| CVS $Id$ ++-- +map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0; !-- === Pipelines = -- + map:pipelines +map:component-configurations + authentication-manager +handlers + handler name=demohandler +redirect-to uri=cocoon:/login/ +authentication uri=cocoon:raw:/authenticate/ + /handler +/handlers + /authentication-manager +/map:component-configurations - map:pipelines - map:component-configurations - authentication-manager -handlers - handler name=demohandler - redirect-to uri=cocoon:/login/ - authentication uri=cocoon:raw:/authenticate/ - /handler - /handlers - /authentication-manager - /map:component-configurations - - map:pipeline - +map:pipeline map:match pattern= map:redirect-to uri=login/ /map:match @@ -39,13 +31,13 @@ !--
Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers
Sylvain Wallez wrote: Hi team, I'd like to propose two people for Cocoon committership : Ugo Cei and Marc Portier. Ugo has been there for years (the archives show his first post back in July 2000!), has been an early adopter of flowscript and wrote the first Cocoon-based blogging tool. +1 Marc is working intensively on the binding and flowscript integrations of Woody and cares a lot about Cocoon. +1 --David
RE: CODE FREEZE for 2.1rc1
Sylvain Wallez wrote: PS: and put the champaigne into the fridge. It's spelled champagne ! Wines are serious things in France ;-) Oh, what a faux pas - sorry for that one, Sylvain! Now, I guess the best thing in helping me to spell this one correctly in the future, is to offer me one or two bottles the next time we meet. I'm sure then, I will not do that again :) Carsten
