Re: Upload widget for Woody: how to handle form redisplay?
Sylvain Wallez wrote: A solution is to keep the uploaded content in a temp area until the form is valid. But what if the user leaves and never re-submits the form? Should we rely on the garbage collector to finalize() the upload widget to clean the temp area? How about catching the expiration of the continuation and removing the temp file from there? Ugo
Re: DO NOT REPLY [Bug 24305] - [PATCH] - esql:get-xml ; wraping result with root element in a namespace
Joerg Heinicke wrote:
Chris, please add [EMAIL PROTECTED] to CC if you assign a bug to
your self. Otherwise the list won't get informed about any comments or
status changes.
Joerg, did you add the CC or did it appear by default? ('cause I didn't
since I believe it used to be that dev is always CC'ed).
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: DO NOT REPLY [Bug 24305] - [PATCH] - esql:get-xml ; wraping result with root element in a namespace
On 09.11.2003 09:48, Christian Haul wrote:
Joerg Heinicke wrote:
Chris, please add [EMAIL PROTECTED] to CC if you assign a bug to
your self. Otherwise the list won't get informed about any comments or
status changes.
Joerg, did you add the CC or did it appear by default? ('cause I didn't
since I believe it used to be that dev is always CC'ed).
Chris.
I did it. And it's not done by default as Bertrand tested on Friday
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24489. I don't know if
there is an option to set by the admin that dev is always CCed on Cocoon
related bugs. At least at the moment we must do it by hand.
Joerg
Re: DO NOT REPLY [Bug 24305] - [PATCH] - esql:get-xml ; wraping result with root element in a namespace
Joerg Heinicke wrote:
On 09.11.2003 09:48, Christian Haul wrote:
Joerg Heinicke wrote:
Chris, please add [EMAIL PROTECTED] to CC if you assign a bug to
your self. Otherwise the list won't get informed about any comments
or status changes.
Joerg, did you add the CC or did it appear by default? ('cause I didn't
since I believe it used to be that dev is always CC'ed).
I did it. And it's not done by default as Bertrand tested on Friday
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24489. I don't know if
there is an option to set by the admin that dev is always CCed on Cocoon
related bugs. At least at the moment we must do it by hand.
OK, will do so in the future.
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: portal engine / design
Christian Haul wrote: Subscribers register themselves with the EventManager. However, in order to do this, they need to live in the same component manager space as the portal. This prevents e.g. startable + threadsafe components to subscribe. As a consequence, the DefaultChangeAspectDataEventSubscriber is hardcoded into the DefaultEventManager. No, this is not true :) The DefaultChangeAspectDataEventSubscriber is actually a hack as it was the fastest way of getting it done. A better way would have been to make the EventManager configurable with default subscribers or to place the DefaultChangeAspectDataEventSubscriber somewhere elsed and let it subscribe by itself. Each component can subscribe, regardless in which CM it is defined (at least in theory). SNIP/ Now, I would like to do the following: Upgrade the pub/sub system with persistent delivery. IOW events from the current request will be delivered to every new subscriber. This way DefaultChangeAspectDataEventSubscriber can be discarded and e.g. Layouts can subscribe themselves. Obviously, persistence would end at the end of the request. Hmm, not sure if this is a good idea - have to think about it. But anyway, you can change this by choosing a different implementation (your persistent one) for the EventManager without changing the current portal behaviour. It's an add-on then. Another effect would be, that change events would be able to target any layout that fills a specific role (the ID). Have EventManager use SoftReferences (- JCC) to register subscribers. Add a name attribute to events and permit a subscriber to select only events of a particular class AND a matching prefix for the name. IMO the class resembles a JMS topic and the prefix would resemble the JMS select. Putting this into the EventManager allows for optimizations there and saves subscribers from implementing this logic. Require events to be able to convert themselves to / from String. This is already implemented I think somehow, but you can't require it for every event. Think of inter-coplet communication where one coplet sends an event to other coplets with a whole bunch of information. Carsten
Re: portal engine / design
Carsten Ziegeler wrote: Christian Haul wrote: Subscribers register themselves with the EventManager. However, in order to do this, they need to live in the same component manager space as the portal. This prevents e.g. startable + threadsafe components to subscribe. As a consequence, the DefaultChangeAspectDataEventSubscriber is hardcoded into the DefaultEventManager. No, this is not true :) The DefaultChangeAspectDataEventSubscriber is actually a hack as it was the fastest way of getting it done. A better way would have been to make the EventManager configurable with default subscribers or to place the DefaultChangeAspectDataEventSubscriber somewhere elsed and let it subscribe by itself. Each component can subscribe, regardless in which CM it is defined (at least in theory). Still, DefaultChangeAspectDataEventSubscriber is a hack since components should subscribe themselves instead of this proxy. SNIP/ So you agree with the assessment on pulling in layouts and event targets? Now, I would like to do the following: Upgrade the pub/sub system with persistent delivery. IOW events from the current request will be delivered to every new subscriber. This way DefaultChangeAspectDataEventSubscriber can be discarded and e.g. Layouts can subscribe themselves. Obviously, persistence would end at the end of the request. Hmm, not sure if this is a good idea - have to think about it. But anyway, you can change this by choosing a different implementation (your persistent one) for the EventManager without changing the current portal behaviour. It's an add-on then. Well, yes. But since it removes the need for the DefaultChangeAspectDataEventSubscriber band-aid, I would want to change the behaviour of eg layouts to subscribe themselves. And the bahaviour of renderers to emit events that don't carry object references. This would lead to duplication of large sections of the current portal engine if done as add-on. Another effect would be, that change events would be able to target any layout that fills a specific role (the ID). Have EventManager use SoftReferences (- JCC) to register subscribers. Add a name attribute to events and permit a subscriber to select only events of a particular class AND a matching prefix for the name. IMO the class resembles a JMS topic and the prefix would resemble the JMS select. Putting this into the EventManager allows for optimizations there and saves subscribers from implementing this logic. Require events to be able to convert themselves to / from String. This is already implemented I think somehow, but you can't require I believe you are talking about EventConverter-s. These are a bit difficult to do since they would need knowledge of event internals in order to convert them to / from strings for example. It really should be the task of an event to convert itself. it for every event. Think of inter-coplet communication where one coplet sends an event to other coplets with a whole bunch of information. Ah, I see. There might be events that are never send to the client but stay on server-side. They are created and consumed during the portal setup phase. IMO it would be sensible to introduce two classes of events, then. event-is-attachable-to-link and server-side-event. The former must be able to convert to/from string and the latter need not. However, I don't think any event should be targeted at a specific subscriber instance. This is not the business of an event publisher (see ChangeAspectDataEvent, IMHO this is bad). 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: cvs commit: cocoon-2.1/src/webapp/samples/text-wrap welcome.html
On 8 Nov 2003, at 23:21, David Crossley wrote: joerg wrote: Modified:src/webapp/samples/text-wrap welcome.html Log: fixed typo we have a HTML file in our CVS ;-) LOL. I am ashamed to say that i sometimes find it easier to knock up a simple html cover page to drive a sample, especially when you need some introductory text to explain the sample. I am not alone ... find src/blocks src/webapp -name *.html | wc -l 10 Same here. Keep in mind that xhtml *IS* xml. actually a very nice markup, polished over the years. What's bad is non-well-formed HTML. *that* is evil and should be in our repository, but xhtml is cool and wanted. -- Stefano.
Re: Upload widget for Woody: how to handle form redisplay?
On 9 Nov 2003, at 00:06, Sylvain Wallez wrote: Hi all, I'm attacking the problem of uploads in Woody. Upayavira started to work on this some time ago but hadn't the time to finish, so I asked him to send me the baby for it to continue growing. But upload is a difficult problem when the nice form framework you use redisplays pages when a validation occurs. Let's consider a simple form with a name field (required) and a file upload widget. What happens if the user selects a file but gives no name? The form is redisplayed, because the name is required, but the upload occurs! Should we discard the upload because the validation failed? A solution is to keep the uploaded content in a temp area until the form is valid. But what if the user leaves and never re-submits the form? Should we rely on the garbage collector to finalize() the upload widget to clean the temp area? Any idea or advice appreciated... I see two potential solutions: 1) client side validation: you don't send if there is no name (the javascript for this is really easy and really portable, btw) 2) disabling: if the upload is done, but there is an error in the form, the 'upload widget' is replaced with the file name (or anything that identifies that the upload has been already done) In any case, you *have* to visually identify the fact that the upload was already performed. The best usability solution would be to have some DHTML that says the upload was already done. Click here to resend and turns into the upload widget if clicked (again, pretty easy and portable stuff to do). Then, if no upload takes place, you pick up the temporary upload and use that. [you can store the temp upload in the continuation anyway] Note that if you want to do in-place uploads (linotype style), but you have errors in the form, the server side needs to change the URI of the uploaded image to point to the temporary uploaded image... this might require some synch between the form handling and the sitemap. The ideal (REST-ish) solution would be to send back the image encoded inside the XHTML page. I think it's possible with embed, but I've never tried it. HTH -- Stefano.
Re: Upload widget for Woody: how to handle form redisplay?
Stefano Mazzocchi wrote:
On 9 Nov 2003, at 00:06, Sylvain Wallez wrote:
Hi all,
I'm attacking the problem of uploads in Woody. Upayavira started to
work on this some time ago but hadn't the time to finish, so I asked
him to send me the baby for it to continue growing.
But upload is a difficult problem when the nice form framework you
use redisplays pages when a validation occurs. Let's consider a
simple form with a name field (required) and a file upload widget.
What happens if the user selects a file but gives no name? The form
is redisplayed, because the name is required, but the upload occurs!
Should we discard the upload because the validation failed?
A solution is to keep the uploaded content in a temp area until the
form is valid. But what if the user leaves and never re-submits the
form? Should we rely on the garbage collector to finalize() the
upload widget to clean the temp area?
Any idea or advice appreciated...
I see two potential solutions:
1) client side validation: you don't send if there is no name (the
javascript for this is really easy and really portable, btw)
2) disabling: if the upload is done, but there is an error in the
form, the 'upload widget' is replaced with the file name (or anything
that identifies that the upload has been already done)
In any case, you *have* to visually identify the fact that the upload
was already performed. The best usability solution would be to have
some DHTML that says the upload was already done. Click here to
resend and turns into the upload widget if clicked (again, pretty
easy and portable stuff to do). Then, if no upload takes place, you
pick up the temporary upload and use that. [you can store the temp
upload in the continuation anyway]
I think I wasn't clear: my fears were about the fact that potentially
large temporary data has to be kept on the server waiting for the user
to finish interaction with the form (it can even go away and never
finish it). But looking at the problem from any angle, I don't see how
we can avoid this.
Now about the presentation stuff, I was also thinking to something along
these lines.
Note that if you want to do in-place uploads (linotype style), but
you have errors in the form, the server side needs to change the URI
of the uploaded image to point to the temporary uploaded image... this
might require some synch between the form handling and the sitemap.
The ideal (REST-ish) solution would be to send back the image
encoded inside the XHTML page. I think it's possible with embed,
but I've never tried it.
Do you mean embed the image inside the HTML as e.g. base-64 data?
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: portal engine / design
Christian Haul wrote: Carsten Ziegeler wrote: Christian Haul wrote: Subscribers register themselves with the EventManager. However, in order to do this, they need to live in the same component manager space as the portal. This prevents e.g. startable + threadsafe components to subscribe. As a consequence, the DefaultChangeAspectDataEventSubscriber is hardcoded into the DefaultEventManager. No, this is not true :) The DefaultChangeAspectDataEventSubscriber is actually a hack as it was the fastest way of getting it done. A better way would have been to make the EventManager configurable with default subscribers or to place the DefaultChangeAspectDataEventSubscriber somewhere elsed and let it subscribe by itself. Each component can subscribe, regardless in which CM it is defined (at least in theory). Still, DefaultChangeAspectDataEventSubscriber is a hack since components should subscribe themselves instead of this proxy. Yes, it's a hack and yes components should subscribe themselves, but data objects are not components and therefore shouldn't subscribe! E.g., layouts, coplet data etc. are only data objects and not components and therefore imho they shouldn't subscribe. You can send an event to a managing component but not to the data itself. SNIP/ So you agree with the assessment on pulling in layouts and event targets? No :) Now, I would like to do the following: Upgrade the pub/sub system with persistent delivery. IOW events from the current request will be delivered to every new subscriber. This way DefaultChangeAspectDataEventSubscriber can be discarded and e.g. Layouts can subscribe themselves. Obviously, persistence would end at the end of the request. Hmm, not sure if this is a good idea - have to think about it. But anyway, you can change this by choosing a different implementation (your persistent one) for the EventManager without changing the current portal behaviour. It's an add-on then. Well, yes. But since it removes the need for the DefaultChangeAspectDataEventSubscriber band-aid, I would want to change the behaviour of eg layouts to subscribe themselves. And the bahaviour of renderers to emit events that don't carry object references. This would lead to duplication of large sections of the current portal engine if done as add-on. As I said above, I'm absolutely against adding logic to the data objects, like the layout. Another effect would be, that change events would be able to target any layout that fills a specific role (the ID). Have EventManager use SoftReferences (- JCC) to register subscribers. Add a name attribute to events and permit a subscriber to select only events of a particular class AND a matching prefix for the name. IMO the class resembles a JMS topic and the prefix would resemble the JMS select. Putting this into the EventManager allows for optimizations there and saves subscribers from implementing this logic. Require events to be able to convert themselves to / from String. This is already implemented I think somehow, but you can't require I believe you are talking about EventConverter-s. These are a bit difficult to do since they would need knowledge of event internals in order to convert them to / from strings for example. It really should be the task of an event to convert itself. An event is only data (= message). We discussed this topic in length during the design phase and honestly I can'T remember why we choose this way :) Have to think about it... it for every event. Think of inter-coplet communication where one coplet sends an event to other coplets with a whole bunch of information. Ah, I see. There might be events that are never send to the client but stay on server-side. They are created and consumed during the portal setup phase. IMO it would be sensible to introduce two classes of events, then. event-is-attachable-to-link and server-side-event. The former must be able to convert to/from string and the latter need not. Personally, I don't like all this conversions. The current approach avoids costly serialization and is independent from the events. However, I don't think any event should be targeted at a specific subscriber instance. This is not the business of an event publisher (see ChangeAspectDataEvent, IMHO this is bad). The event is not targetted at the aspect data, but at a component that is able to do something meaningful with this event which is in this case change some data. Carsten
Bug report for Cocoon 2 [2003/11/09]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 5978|Ass|Nor|2002-01-23|Java SecurityManager java.lang.RuntimePermission c| | 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing | | 9916|New|Enh|2002-06-17|javax.xml.transform.Transformer accepts object par| |10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu| |10827|New|Nor|2002-07-15|ESQL get-xml/ doesn't support namespaces| |11716|New|Nor|2002-08-15|util:include-expr is formatting sensitive | |13479|New|Maj|2002-10-10|Cocoon fails to compile sitemap and XSP in JBoss 3| |13904|New|Nor|2002-10-23|FilterTransformer: ArrayIndexOutOfBounds exception| |14074|New|Nor|2002-10-29|Previously reported tar bug - isn't (well, it is b| |14327|New|Nor|2002-11-07|JSPReader: make the output encoding configurable. | |15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu| |15316|Opn|Nor|2002-12-12|FOP does not resolve relative paths | |15614|Opn|Min|2002-12-22|Some documentation is inaccurate by version | |15841|New|Nor|2003-01-07|xsp:attribute handled incorrectly | |16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 | |16545|New|Min|2003-01-29|Logicsheet embedded in used-defined logicsheet doe| |16710|New|Maj|2003-02-03|SQLTransformer.Query.serializeRow forces lower cas| |17594|New|Nor|2003-03-03|WebSphere redirect bug| |17771|New|Nor|2003-03-07|[PATCH] new logging category never set when using | |17924|New|Nor|2003-03-12|Cached resources don't have Expires-Header| |17984|New|Enh|2003-03-14|SQLTransformer only handles nested or sequential q| |18003|New|Nor|2003-03-14|JSPReader JSPGenerator: NPE when adding context-| |18116|New|Min|2003-03-18|VelocityGenerator property child elements don't | |19138|New|Enh|2003-04-18|[Contrib]/[Patch] Made SQLTransformer paginatable.| |19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane | |20190|New|Maj|2003-05-23|JSPs in external subsite fail | |20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer | |20631|New|Nor|2003-06-10|[PATCH] Support for transactions in SQLTransformer| |20640|New|Maj|2003-06-10|Pages keep reloading with Cocoon 2.04 | |20736|New|Maj|2003-06-13|JXForms validator rejects null value for numeric f| |21107|New|Maj|2003-06-26|possible sitemap reload locking issue | |21177|New|Nor|2003-06-30|a crash in the name() function of the xslt, when u| |21301|New|Maj|2003-07-03|esql:get-xml error: Could not find Component (role| |21536|Opn|Enh|2003-07-12|[PATCH] 2 new generators: MultiPartPosted XML and | |22132|New|Nor|2003-08-05|Cannot use redirect-to after submit jxform| |22400|New|Enh|2003-08-13|SQLTransformer to optionally preserve case of colu| |22842|New|Nor|2003-08-30|flow: importPackage/importClass problems creating | |23002|New|Nor|2003-09-08|HSSF Serializer does not process gmr:PrintInforma| |23118|New|Nor|2003-09-11|SearchGenerator incorrectly counts previous-index | |23269|New|Maj|2003-09-19|ServletException in JSPReader.generate() | |23283|Unc|Nor|2003-09-19|WebServiceProxy doesn't re-encode request paramete| |23285|Ass|Min|2003-09-20|WebServiceProxy sends a request parameter named n| |23328|New|Nor|2003-09-22|XSP ESQL logicsheet example fails if Oracle 8i dat| |23452|New|Maj|2003-09-27|JXforms xf:select bug when unselecting all items | |23481|New|Nor|2003-09-29|HSSFSerializer: ambigious style definition leads t| |23542|Opn|Maj|2003-10-01|[PATCH] Fix Bug: Better handling of CLOB in esql (| |23585|New|Nor|2003-10-03|Localton of ev_cache.ser file in DefaultEventRegis| |23615|Opn|Nor|2003-10-06|xsltc doesn't work with nodeset functions | |23796|New|Nor|2003-10-14|[PATCH] docs pages containing source are sometim| |23901|New|Nor|2003-10-17|[PATCH] [woody], adding wd:on-phase and moving l| |23921|New|Enh|2003-10-19|[PATCH] New ReadDOMTransformer/WriteDOMTransformer|
DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions
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=24463. 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=24463 [PATCH] Petstore sample: bug fixes + completions --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 15:19 --- David, I'm sorry, I was a bit in a hurry when I packed the files (I wanted to finish it before FirstFriday and the code freeze). I'll do a re-re-format + diff + comments soon. /Leo
Re: portal engine / design
Carsten Ziegeler wrote: Christian Haul wrote: Still, DefaultChangeAspectDataEventSubscriber is a hack since components should subscribe themselves instead of this proxy. Yes, it's a hack and yes components should subscribe themselves, but data objects are not components and therefore shouldn't subscribe! E.g., layouts, coplet data etc. are only data objects and not components and therefore imho they shouldn't subscribe. You can send an event to a managing component but not to the data itself. OK. What would be the managing component for a layout? The layout factory? Or the profile manager? But then the factory (at least the default factory) would need to (a) keep a reference to all layouts which it doesn't and (b) know how a layout behaves which it doesn't. Actually, the renderers know that. So, renderers should subscribe? They don't have a link to the layouts they render, the look up works the other way around. Mmmh, they could store the event until a layout comes by that matches this event. :-| SNIP/ So you agree with the assessment on pulling in layouts and event targets? No :) Then I would really like some comments on this. You know, without docs it's not really easy to understand the ideas behind it. As I said above, I'm absolutely against adding logic to the data objects, like the layout. So it's the renderer, then? Require events to be able to convert themselves to / from String. This is already implemented I think somehow, but you can't require I believe you are talking about EventConverter-s. These are a bit difficult to do since they would need knowledge of event internals in order to convert them to / from strings for example. It really should be the task of an event to convert itself. An event is only data (= message). We discussed this topic in length during the design phase and honestly I can'T remember why we choose this way :) Have to think about it... This works fine for intra-request messages. Inter-request is different. it for every event. Think of inter-coplet communication where one coplet sends an event to other coplets with a whole bunch of information. Ah, I see. There might be events that are never send to the client but stay on server-side. They are created and consumed during the portal setup phase. IMO it would be sensible to introduce two classes of events, then. event-is-attachable-to-link and server-side-event. The former must be able to convert to/from string and the latter need not. Personally, I don't like all this conversions. The current approach avoids costly serialization and is independent from the events. It's the only way I see to have bookmarks or even think of going static. However, I don't think any event should be targeted at a specific subscriber instance. This is not the business of an event publisher (see ChangeAspectDataEvent, IMHO this is bad). The event is not targetted at the aspect data, but at a component that is able to do something meaningful with this event which is in this case change some data. Granted. Still, I don't like the object references in a ChangeAspectDataEvent. This is hackish. Big time hackish. 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: [PATCH] docs pages containing source are sometimes too wide
First I want to say thanks to David for putting the text-wrap sample together. --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 01:58 --- Sorry for being destructive, but I do not see a real problem. Or better said this problem resulting from trying to handle all types of using source is to complex and I would not do it. Agree. I had no look on the code, only on the samples, where David shows the possible use cases - and these are really extreme samples :-) there-are-some-funny-examples-there-alright-no-doubt-about-it/ It's almost not possible to handle both indenting and line length for every type of source. Absolutely true. We just need XSLT templates to handle specific types of source. I don't think it's too hard for a type-specific template to recognise it's own flavour of source, and the actually existing source template can handle anything else. The DTD says that source is normally displayed in a fixed-width font, so in general I think authors have the right to expect pre. But for sitemap snippets etc. this is really not good, because there are long class-names like org.apache.cocoon.generation.WebServiceProxyGenerator and attributes like xmlns:dir=http://apache.org/cocoon/directory/2.0; and in a fixed-width font these are much wider than they need to be. The wrap2para.xsl which I wrote was originally for Cocoon's docs in which the source elements almost always contain representations of XML markup. I think it does a reasonable job of that, though it could of course be improved. But it turned out that source has a wider applicability than I realised. My suggestion is clearly no good for the ascii-art example of a file-system hierarchy. That kind of source requires a fixed-width font, and the current templates are fine for that. So I plug for the sniff content option, and 1) for source which is xml/html/dtd use wrap2para.xsl 2) for everything else use the actually existing stylesheet (i.e. pre) I don't think there's much need for split.xsl, but it could be used for (2) where I guess it would usually produce the same output, and would occasionally have to split a long line. Potential enhancements would be: For XML: Allow browser to wrap lines only in the whitespace inside element tags. Syntax highlighting of elements and attributes. For Java: Prevent line-wrapping in //-style comments. Syntax highlighting for string literals, operators, comments, etc. NB the same long lines are in the PDF version of the docs too, see http://cocoon.apache.org/2.1/userdocs/concepts/modules.pdf
[IMP] Code Freeze
starts tonight - release is (hopefully) on thursday. Regards Carsten
Re: Upload widget for Woody: how to handle form redisplay?
Sylvain Wallez wrote: Ugo Cei wrote: Sylvain Wallez wrote: A solution is to keep the uploaded content in a temp area until the form is valid. But what if the user leaves and never re-submits the form? Should we rely on the garbage collector to finalize() the upload widget to clean the temp area? How about catching the expiration of the continuation and removing the temp file from there? Good idea. For this, we'll need some kind of ContinuationExpirationListener. But Maybe you can use the ContinuationsDisposer for this? I added this during the making of 'Apples' to dispose resources (looked up components) your Apple might be holding they'll have to be registered in the continuation that _will_ be created at the next sendPageAndWait, as the latest continuation represents a past state, and may not exist if we just started the flowscript. Hm, of course for apples it was slightly different, since there the use-case controller is one object-instance (and not multiple ones) but maybe we can find a way to register this kind of clean-up stuff on the level of the complete use-case... or in flowscript lingo on the level of the continuations-tree (so it only gets executed if the last node in the tree is expired, and not upon clearing each node) I think we must also use the cleanup on finalize() for cases where forms are used outside of flowscript (i.e. with actions). 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]
DO NOT REPLY [Bug 24498] - Need to be able to use cinclude or xinclude to manage sitemap fragments
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=24498. 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=24498 Need to be able to use cinclude or xinclude to manage sitemap fragments --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 20:54 --- Yes Say you have a file called resources.xml: map:resources !-- A bunch of resources I want to share in several sitemaps -- /map:resources And here is my sitemap: map:sitemap !-- Somewhere I want to do something like this: -- cinclude:include src=resources.xml / /map:sitemap
Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon 2.2 ... )
Sylvain Wallez wrote: Ryan Hoegg wrote: peter royal wrote: Anyone: Any thoughts about using Jelly as the builder for the sitemap? Its usage can be completely hidden, but as a tag processor, it might work very well. We could use it to construct a bean-graph to model the sitemap. -pete Sounds sensible. Is jelly in use anywhere else in Cocoon? It sounds like a great fit. Jelly is not currently used in Cocoon. The idea is interesting, but it also means a rewrite of a large part of the sitemap engine, and doesn't give an immediate answer to the mixing between components and container outlined by Berin. Note that I don't state this to protect the current treeprocessor, but to minimize the work required to move to Fortress. Now I recognize I don't know Jelly and thus how hard this would be. I agree with this. Tonight I have been looking at the treeprocessor code and think it would be quite straightforward to move things to Fortress if we hold on to the idea of nodes as components. Proper components that is, as opposed to what has been previously dubbed 'pseudo components'. For this ProcessingNode and ProcessingNodeBuilder should be merged. The only thing that was not immediately clear to me was how to build the component graph structure. It seems that from a container POV the sitemap node elements perform two seperate functions. Consider the following snippet: pipeline match pattern=... ... /match /pipeline Here the match element both represents a component declaration of a MatchNode to the container _and_ a configuration element representing a child node to the PipelineNode. This means that from a container POV the sitemap is a more human readable view on the 'actual' container configuration which looks more like: pipeline id=p1 childnode id-ref=m1 / /pipeline match id=m1 pattern=... ... /match Where the 'childnode' element now is a proper configuration element and match is a proper component declaration. Sitemap container configuration is then a transformation of the sitemap to a default container configuration. ParentProcessingNodes obtain their children by reading the reference id's to their child nodes during configuration phase and a simple lookup on the service manager during the service phase. I think we can use this approach nicely with view and resource lookups and sitemap component lookups as well: sitemap components generators generator name=file / ... pipelines ... generate type=file / becomes: sitemap generator id=file-generator / ... generate ref-id=file-generator / ... /sitemap WDYT? Unico
DO NOT REPLY [Bug 24529] - [PATCH] file upload component for usage with flowscript
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=24529. 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=24529 [PATCH] file upload component for usage with flowscript [EMAIL PROTECTED] changed: What|Removed |Added Summary|file upload with flowscript |[PATCH] file upload |: a basic upload component |component for usage with |source code |flowscript
DO NOT REPLY [Bug 24500] - Need to be able to use non-sitemap namespaces in the sitemap
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=24500. 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=24500 Need to be able to use non-sitemap namespaces in the sitemap --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 22:54 --- So, was it ever implemented or not ? The reason I think it is related to bug 24498 is because cinclude and xslt leave out xmlns attributes which cause sitemap processor to throw an exception.
DO NOT REPLY [Bug 24498] - Need to be able to use cinclude or xinclude to manage sitemap fragments
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=24498. 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=24498 Need to be able to use cinclude or xinclude to manage sitemap fragments --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 23:08 --- Sounds reasonable, but I guess it won't be implemented. This means using a Cocoon transformer on the sitemap itself. *ouch* Furthermore real blocks, which are still some time away of course, will make all this useless. Recent Xerces versions have xinclude functionality when parsing the file, maybe you get Xerces running in the correct mode inside Cocoon. And the least option is to use entities and file include.
DO NOT REPLY [Bug 24500] - Need to be able to use non-sitemap namespaces in the sitemap
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=24500. 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=24500 Need to be able to use non-sitemap namespaces in the sitemap --- Additional Comments From [EMAIL PROTECTED] 2003-11-09 23:10 --- No, it is not implemented. Namespace declaration would be the least arguments. If the tree processor stumbles over namespace declarations, then it is buggy IMO.
Newbie flow question: calling a delete() method
Quick and nasty one... me feels a bit stupid now. Since in javascript delete is a reserved keyword, how do I call a delete() function of a java object? I know there must be a quick 'n easy solution out there, but it's escaping my mind ATM. Suggestions? -- Gianugo Rabellino (preparing his dumbass hat) 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 24463] - [PATCH] Petstore sample: bug fixes + completions
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=24463. 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=24463 [PATCH] Petstore sample: bug fixes + completions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 00:38 --- Ah yes, i tried to get it done as part of FirstFriday. Oh well, we missed it, but we should get this in ASAP to keep up with Woody development. I found the issue with the license headers - they have silly double-spaces and your text editor must have converted them to double-double-spaces. I see that there are indenting changes too, e.g. you have tidied the sitemap. That is fine. For the future, it is better to do that in a separate patch when there are also lots of code changes. That would make review a lot easier. Leo, do not bother to re-prepare the patch. I will sort it out at this end and be ready to commit it when the code freeze is over. Would someone with Flow experience (i.e. not me) please address Leo's concerns. --David
RE: Newbie flow question: calling a delete() method
Me felt stupid too once ;-) http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106500375605928w=2 -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: maandag 10 november 2003 1:26 To: [EMAIL PROTECTED] Subject: Newbie flow question: calling a delete() method Quick and nasty one... me feels a bit stupid now. Since in javascript delete is a reserved keyword, how do I call a delete() function of a java object? I know there must be a quick 'n easy solution out there, but it's escaping my mind ATM. Suggestions? -- Gianugo Rabellino (preparing his dumbass hat) 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/)
Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!
That's why I'm suggesting an action of type flowscript that would call a function defined in the script files listed in map:flow and thus be able to share the session-global variables with map:call statements. Think of this action as a secondary controller in a MVC model (they fine-tune the view but don't change it radically), the map:call being the primary controller (it chooses the pipeline URI that fully defines the view). So long as you clearly document the new way of doing this, and leave the old way in place for at least one release cycle! Mind you, given the state of Cocoon docs, that is a lot to ask, non? ;-) Keep in mind that my application will be used by over 10K users at a huge brokerage firmso breaking the current behaviour (even if it was not intended) would not be a good thing for Cocoon's reputation in the industry. Thanks. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com
DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions
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=24463. 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=24463 [PATCH] Petstore sample: bug fixes + completions --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 04:38 --- please wait a moment, David, I'm almost done with repreparing the patch, this was a good exercise anyway, I found several inaccuracies I like to clean out before you apply it. /Leo
whitespace cleanup and efficiency drive
It might sound pedantic, but it is about efficiency. I have wasted a lot of time during my committer life with confusing patches that contain mainly whitespace changes. Not to criticise the patcher or their tools, but today was a classic. With some manual tweaks to whitespace, i managed to bring one diff down from 450 lines to 120 lines. What caused this grief? Well the files in cvs had inconsistent whitespace, most indentations were 4-space, some were 3-space, some line of text had two spaces between words rather than one, and other spurious issues. Now when the developer edited that file, their text editor must have tried to fix the whitespace, but in many cases made it worse. Therefore the diff was full of clutter. If i had committed it then no-one would have been able to review the changes. It would look like almost every line had changed. Also the cvs files would have been in a worse state and then perpetuate it. I suppose that it is a dream, but does anybody know about a tool that would automatically apply say 4-space indentation and whitespace clean up? We could apply that to our whole cvs say once per month. --David
DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions
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=24463. 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=24463 [PATCH] Petstore sample: bug fixes + completions --- Additional Comments From [EMAIL PROTECTED] 2003-11-10 05:01 --- Okay. did you see my message to cocoon-dev about Whitespace and my commit of cleanups to the main files: sitemap.xmap and *.js ? I hope that does not make it harder for you, but it ceratinly makes it easier for us. Just send the whole files again if you prefer. I had to make similar whitespace tweaks to your main files. I will do it again if it is easier to do it at this end. (No need to send images/*) --David
Re: whitespace cleanup and efficiency drive
David Crossley wrote: It might sound pedantic, but it is about efficiency. I have wasted a lot of time during my committer life with confusing patches that contain mainly whitespace changes. Not to criticise the patcher or their tools, but today was a classic. With some manual tweaks to whitespace, i managed to bring one diff down from 450 lines to 120 lines. What caused this grief? Well the files in cvs had inconsistent whitespace, most indentations were 4-space, some were 3-space, some line of text had two spaces between words rather than one, and other spurious issues. Now when the developer edited that file, their text editor must have tried to fix the whitespace, but in many cases made it worse. Perhaps we need a Guide to Not Letting Your Editor Mess Up The Code(tm). I know things like Textpad can really goof up source automatically. *guilty nervous cough* Therefore the diff was full of clutter. If i had committed it then no-one would have been able to review the changes. It would look like almost every line had changed. Also the cvs files would have been in a worse state and then perpetuate it. I had this problem briefly where my editor was removing extra whitespace from the end of lines automatically on save, and then the diffs were showing up with changed lines where it wasn't apparent there was a change at all. I suppose that it is a dream, but does anybody know about a tool that would automatically apply say 4-space indentation and whitespace clean up? We could apply that to our whole cvs say once per month. Jalopy? http://jalopy.sourceforge.net/ Never used it, just Google'd it. I'm +1 for making our source easier to read. Maybe we should also instate a policy that incoming patches from non-committers should either be submitted properly formatted, or we won't take it. --David Regards, Tony
Re: Newbie flow question: calling a delete() method
Gianugo Rabellino wrote: Quick and nasty one... me feels a bit stupid now. Since in javascript delete is a reserved keyword, how do I call a delete() function of a java object? I know there must be a quick 'n easy solution out there, but it's escaping my mind ATM. javaObject[delete] -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
