RE: [RT] Versions
Hi, yes, you're right - it's my fault this time, I used the terms in a different meaning. So, if you read this thread and replace minor with patch and major with minor, we use the general meaning :) Sorry! BTW, I'm currently working on a first draft of the guide. Carsten -Original Message- From: Andreas Hochsteger [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 10:51 PM To: [EMAIL PROTECTED] Subject: Re: [RT] Versions I'm a bit confused about the naming of version number parts. I always thought, that version numbers are constructed like this: MAJOR.MINOR.PATCH I did some quick google search and found the following pages which seem to confirm that: http://apr.apache.org/versioning.html#strategy http://www.linuxcertified.com/e-learning/linuxplus/html/1_9.html http://www.elego-software-solutions.com/man/committing-and-rel easing.html http://edocs.bea.com/wles/docs41/javadocs/JavaAPI/com/bea/secu rity/ServiceVersion.html http://protodesign-inc.com/doc/SansGUI/class_schema_version_contro.htm http://www-unix.mcs.anl.gov/~gawor/jglobus-nightly/doc/org/glo bus/common/Version.html In the last discussion about version numbers (it was before the introduction of the cocoon-2.2 repository) there were the same misunderstandings as I already pointed out here: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105959008920632w=2 Sorry to be that picky again, but it's hard to follow the discussions if different people mean different things by using the same words. A versioning guide - like Marc already suggests - would be really helpful to make these things clear. Andreas. Reinhard Poetz schrieb: Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: snip/ My opinion is that we should remove deprecated classes (some of them) in our 2.1.x branch *now* in order to create a smooth transition and to build a better basis for the future development. To indicate this, we should update the version number to 2.2 *now* in the cocoon-2.1 repository. This would mean that the next Cocoon version would be 2.2. If the need for a 2.1.5 arises we could still make a branch. We clearly indicate that although we have a major version change, there are only minor incompatibilities that shouldn't affect users. Who is affected by those changes? What does an upgrade mean for the user? Good question, thanks Reinhard, I forgot to tell that :) If we remove deprecated classes, users that have developed their application for Cocoon 2.0.x are affected if they are still using the deprecated classes. If your app is developed for Cocoon 2.1.x, you are not affected. Following this, why do we need a version change to 2.2 if 'only' 2.0 users, who want to upgrade, are affected. The change from 2.0 to 2.1 was a major version change which _can_ cause some minor incombatibilites. An upgrade for a user means that she just has to replace the use of the deprecated class with a newer one. So it comes down to using a different interface name and a different method name in some rare cases. The two areas affected here are caching and source resolving. In both cases, using the new interfaces provides improved features but also improved performance and stability anyway. Another area are the RequestLifeCycle components. They have been introduced in Cocoon 2.0.4 (I think) and we have voted to remove them in 2.2 again. So if you are using them, you have to use one of the alternatives which is using Contextualizable to get the object model or the RequestDataStore to store infos. But I guess that not many are using these interfaces anyway. I would add of course documents on how to update for each area. Same as above. IMO we can move on with 2.1.x and remove the depracated classes if this is necessary. WDYT?
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Tim Larson wrote: On Wed, Apr 21, 2004 at 12:29:26AM +0200, Marc Portier wrote: [EMAIL PROTECTED] wrote: 1/ should getWidget(id) be removed from Widget? It is already on ContainerWidget (which is the true context that makes sense IMHO) +1 remove it. It is historical from before we had the Container* code. ok 2/ should getNamespace() exist at all, it seems to return the same thing as getFullQualifiedId()? Maybe a historical idea waiting to get thrown out? +1 historical, just make sure getFullyQualifiedId() does not break. yep 3/ can getId() ever return null or on a widget instance? Can't we carefully asume programming error and allow for the accidental NPE to be thrown +1 after we fix the top-level form widget to not return null or . (I don't remember which, but it returns one of those two values). Anyway, we somehow need to supply the form widget with an id to resolve widget naming conflicts when there is more than one form on a page. I think it should come from somewhere other than the form definition, because it is the page designer's role to prevent form id conflicts, not the role of the form designer. For example, imagine a page containing two instances of the same form definition, tied to separate data. The page designer knows there is a conflict, but the form designer has no way to prevent it. Maybe there is a way to auto-generate the id's? thx for explaining. I think we should go for returning null today then, and see how it turns out in future 4/ same question on getDefinition() There once was talk about the possibility of widgets without definitions: http://marc.theaimsgroup.com/?t=10716524511r=1w=2 Does this have any relevance to your question? yep related, and the same solution should do now too: starting from AbstractWidget down the hierarchy it should be there, and provided by the getDefinition() people overloading AbstractWidget.getDefinition() to return null (or setting it during construction with super(null) should be made aware to also overload getLocation() and generateDisplayData() (which was the reason for me asking now) (although they should probably not use that base class then, since it explicitely asks for a definition in its constructor, maybe throwing IllegalArgument makes sense on the constructor) 5/ should we rename ContainerDelegate to simply WidgetList (and the ContainerDefintionDelegate to WidgetDefinitionList) +1 to something like that. thx 6/ union seems to generate fi:field in stead of fi:union this surprised me a bit, is that the goal? Yes, I was trying to surprise you ;) No, really I just noticed that this part of the union widget acted just like a field as far as the template layer was concerned, so I used the same name to prevent having to copy-and-paste support code in the template handling. A better route might be to change both field and union to use something more generic like fi:value in the templating layer. thx for explaining, adding a comment would take away the surprise 7/ should validation stop as soon as possible or continue to allow all validation errors to be set? Don't know which is best. *If* we cannot decide (due to different needs in different usecases) then we will need to add an attribute to let the form designer control the behaviour. hm, we should at least be consistent 8/ setParent() on abstractWidget should be write-once IMHO, possibly yielding RTE (IllegalState?) when someone tries to reset it See: http://wiki.cocoondev.org/Wiki.jsp?page=ImmutableWidgetDefinitions The widget-definition repositories will allow widget-definitions to have multiple parents, so imho we should remove setParent() completely. Please see the Walker solution on that wiki page for more details. have to come back on that later (need to run now) 9/ should not all generateSAXFragments include the getDefinition.generateDisplayData() by default +1 if my memory of the issues serves me right. coolio -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [VOTE] Move to SVN
What are the current problems we have with CVS that you want to solve with such a move? Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi Sent: Wednesday, April 21, 2004 8:47 AM To: [EMAIL PROTECTED] Subject: [VOTE] Move to SVN Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] Move to SVN
Le 21 avr. 04, à 08:46, Nicola Ken Barozzi a écrit : Since we are working a lot with branches... Are we really? I thought branches were unwelcome around here (although I never really understood why). ...I propose that we move Cocoon to use SVN... I'm +1 basically (or more precisely +0.5, cannot help ATM). But we might want to discuss about the right time to do this. It might be easier right after the next release, otherwise we risk delaying the release until everybody is fine with SVN. -Bertrand
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Marc Portier wrote:
3/ can getId() ever return null or on a widget instance? Can't we
carefully asume programming error and allow for the accidental NPE to be
thrown
if (id == null || id.equals()) {
throw new FormsConfigurationException(Widget id cannot be null.);
}
where FormsConfigurationException extends RuntimeException, of course ;-).
7/ should validation stop as soon as possible or continue to allow all
validation errors to be set?
If you can't make it optional, allow it to continue.
Ugo
Re: [VOTE] Move to SVN
Carsten Ziegeler wrote: What are the current problems we have with CVS that you want to solve with such a move? For example keeping everything in one big repository and using branches? The reason why we don't use branches (IIRC) is because, with a repository the size of ours, CVS slows right down. I believe SVN does not have this problem. Regards, Upayavira Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi Sent: Wednesday, April 21, 2004 8:47 AM To: [EMAIL PROTECTED] Subject: [VOTE] Move to SVN Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] Move to SVN
Le 21 avr. 04, à 10:29, Upayavira a écrit : Carsten Ziegeler wrote: What are the current problems we have with CVS that you want to solve with such a move? For example keeping everything in one big repository and using branches? would be a very good reason for me. The reason why we don't use branches (IIRC) is because, with a repository the size of ours, CVS slows right down ok, thanks for the info. -Bertrand
Re: [VOTE] Move to SVN
Upayavira wrote: Carsten Ziegeler wrote: What are the current problems we have with CVS that you want to solve with such a move? For example keeping everything in one big repository and using branches? The reason why we don't use branches (IIRC) is because, with a repository the size of ours, CVS slows right down. I believe SVN does not have this problem. I believe Nicola Ken is willing to propose it because Forrest is now using SVN. I also believe that there is an SVN sandbox somewhere that people can play with. I've asked for details of it at infrastructure@ and will let you know. Upayavira, who seems to believe lots of things
Re: [VOTE] Move to SVN
Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 Enthousiastic +1000 here. I'm totally in love with subversion, and I think it would help development immensely, not only because of branching but also because of network-friendliness of HTTP (gosh, no more firewall issues), WebDAV support (want to download the latest code? mount a webdav share, no need to install anything). Oh, don't forget directory shuffling and renaming - with history being preserved. Ciao, -- Gianugo
Re: [VOTE] Move to SVN
Nicola Ken Barozzi wrote: Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 +1 /Daniel
Re: [VOTE] Move to SVN
Andreas Kuckartz wrote: Users of Eclipse and Linux will have problems. From the subclipse FAQ: Why does Subclipse only support Windows? A linux version is planned. http://subclipse.tigris.org/ But: subclipse builds for eclipse 3.0 stream. supports win32, linux and osX http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240 Since I'm using Linux and OSX exclusively, I might revert my +1 to a -0.5 if I cannot have support inside Eclipse :(. Ugo
Re: [VOTE] Move to SVN
There was a suggestion on the lenya-dev list about a week ago to switch to Subversion after the release of Lenya 1.2. Due to the dubious current situation regarding the use of Subclipse/Eclipse on Linux that plan is currently stalled. Andreas - Original Message - From: Ugo Cei [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 11:07 AM Subject: Re: [VOTE] Move to SVN Andreas Kuckartz wrote: Users of Eclipse and Linux will have problems. From the subclipse FAQ: Why does Subclipse only support Windows? A linux version is planned. http://subclipse.tigris.org/ But: subclipse builds for eclipse 3.0 stream. supports win32, linux and osX http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240 Since I'm using Linux and OSX exclusively, I might revert my +1 to a -0.5 if I cannot have support inside Eclipse :(. Ugo
Re: [VOTE] Move to SVN
Nicola Ken Barozzi wrote: Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 If you guys tell me that it works well IRL, I don't have a problem either. So +0.5 (can't help you with this ATM). This also gives us the chance to solve the naming problem (see the [RT] Versions thread) by finding better, more version independed names, doesn't it? -- Reinhard
Re: Proposal: release management guide (was Re: [RT] Versions)
Carsten Ziegeler wrote: Marc Portier wrote: I currently don't think we have a release scheme that supports one or the other: i.e. reality seems pretty much like what Carsten is saying: we just have 1,2,... 1004 (based on some gut feeling we seem to be distributing those numbers over tripplets) I thought about this topic a little bit and I can only say we never followed any compatibility rules! For example we changed the sitemap in an incompatible way not only from 2.0.x to 2.1, but also from 2.1.3 to 2.1.4. And we removed deprecated API/changed interfaces/methods between patch releases. So following this logic, we could just follow this road and do whatever we think is appropriate or establish some general and simple rules to make the live of the users easier. I have written a first draft of such a guide (well I copied some things from here and there and added my two cents). So, let's start another flame war and tell me what you think about this. (PS: I think this one of the longest mails I ever wrote) ;-) The Cocoon Versioning Manifest (CVM) This document covers how the Cocoon project is versioned. Since Cocoon is a framework, it is very important to define a stable API for users and developers. However, we also need to move Cocoon forward, technologically. To balance these two needs, a strict policy of versioning is required, which users can rely upon to understand the limitations, restrictions, and the changes that can occur from one release to the next. Basics -- Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain usage and extension compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards. +1 Following the main design principle of Cocoon, the pyramid of contracts, we distinguish between users and developers of Cocoon. A very rough distinction between them is that a user writes the application using Cocoon without coding Java. There is one exception to this rule: flow script - the java script is also written by the user. A developer codes Java and provides additional functionality for the user, so a developer extends Cocoon. Therefore we distinguish between usage compatibility and extension compatibility. +1 Both compatibility levels cover some kind of source compatibility. Cocoon does not provide binary compatibility. But as Cocoon is distributed as a source release that you have to compile anyway, it's saver to compile your own application code (if any) using the version of Cocoon that your application runs on. +1 we should make a clear recommendation that recompiling is the better way Usage Compatibility --- 'Usage' compatibility guarantees that an application written by a Cocoon user is compatible. All files developed by a typical Cocoon user like xml files, sitemaps, stylesheets (elements and namespace declarations) keep on being picked up by the machinery and are dealt with correctly (sitemap semantics, generator/transformer-picked up elements, config file entries...). In fact this should cover everything (including flow script) but except own Java code. Applications that write against a particular version will remain usage compatible against later versions, until the major number changes. Writing an application against a version means that this application does not use any deprecated API of that version. Therefore minor version changes are only usage compatible from one minor version to the direct following one. For example 2.2 is usage compatible to 2.1. But 2.3 is not necessary usage compatible to 2.1, although it is usage compatible to 2.2. As long as you don't use deprecated API, your application is usage compatible across all minor versions. Example: - a feature is introduced in 2.0 and used by the application. - it is deprecated in 2.2. - it will be removed in 2.3. However, if an application uses an API which has become available in a particular minor version, it (obviously) will no longer operate against previous minor versions. +1 Extension Compatibility --- 'extension' compatibility guarantees that own extensions to what Cocoon provides (own Java classes that interface directly with API in the Cocoon distribution) compile and operate. Applications that write against a particular version will remain extension compatible against later versions until the major or the minor number changes (Please note the difference to the usage compatibility). However, the Cocoon developers take care that even if the minor number changes, most of the own code still works and operates properly. Incompatible changes between minor versions are kept to a minimum. Frequent new releases of Cocoon ensure that developers have a smooth transition path. If an
Re: Proposal: release management guide (was Re: [RT] Versions)
Carsten, Reads very well, I say. All we need to do is decide if that is how we actually want to (and can) work! One addition is to mention our policy on blocks and block status: Blocks and Block Stability -- Cocoon currently allows optional functionality to be included or excluded using a simple system called blocks, in which the functionality is included or excluded at compile time. [NB. This is a precursor to a more complete block system which is currently under development.] A block can have one of three statuses: unstable, stable or deprecated. An unstable block has an API that can change without notice. A stable block is subject to the same versioning process as described in this document. Similarly, when the entire functionality of a block is deprecated, it will be handled in the same way as any other deprecated code within Cocoon. = Does this seem reasonable? Upayavira Carsten Ziegeler wrote: Marc Portier wrote: I currently don't think we have a release scheme that supports one or the other: i.e. reality seems pretty much like what Carsten is saying: we just have 1,2,... 1004 (based on some gut feeling we seem to be distributing those numbers over tripplets) I thought about this topic a little bit and I can only say we never followed any compatibility rules! For example we changed the sitemap in an incompatible way not only from 2.0.x to 2.1, but also from 2.1.3 to 2.1.4. And we removed deprecated API/changed interfaces/methods between patch releases. So following this logic, we could just follow this road and do whatever we think is appropriate or establish some general and simple rules to make the live of the users easier. I have written a first draft of such a guide (well I copied some things from here and there and added my two cents). So, let's start another flame war and tell me what you think about this. (PS: I think this one of the longest mails I ever wrote) The Cocoon Versioning Manifest (CVM) This document covers how the Cocoon project is versioned. Since Cocoon is a framework, it is very important to define a stable API for users and developers. However, we also need to move Cocoon forward, technologically. To balance these two needs, a strict policy of versioning is required, which users can rely upon to understand the limitations, restrictions, and the changes that can occur from one release to the next. Basics -- Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain usage and extension compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards. Following the main design principle of Cocoon, the pyramid of contracts, we distinguish between users and developers of Cocoon. A very rough distinction between them is that a user writes the application using Cocoon without coding Java. There is one exception to this rule: flow script - the java script is also written by the user. A developer codes Java and provides additional functionality for the user, so a developer extends Cocoon. Therefore we distinguish between usage compatibility and extension compatibility. Both compatibility levels cover some kind of source compatibility. Cocoon does not provide binary compatibility. But as Cocoon is distributed as a source release that you have to compile anyway, it's saver to compile your own application code (if any) using the version of Cocoon that your application runs on. Usage Compatibility --- 'Usage' compatibility guarantees that an application written by a Cocoon user is compatible. All files developed by a typical Cocoon user like xml files, sitemaps, stylesheets (elements and namespace declarations) keep on being picked up by the machinery and are dealt with correctly (sitemap semantics, generator/transformer-picked up elements, config file entries...). In fact this should cover everything (including flow script) but except own Java code. Applications that write against a particular version will remain usage compatible against later versions, until the major number changes. Writing an application against a version means that this application does not use any deprecated API of that version. Therefore minor version changes are only usage compatible from one minor version to the direct following one. For example 2.2 is usage compatible to 2.1. But 2.3 is not necessary usage compatible to 2.1, although it is usage compatible to 2.2. As long as you don't use deprecated API, your application is usage compatible across all minor versions. Example: - a feature is introduced in 2.0 and used by the application. - it is deprecated in 2.2. - it will be removed in 2.3. However, if an application uses an API which has become available in a
Re: [VOTE] Move to SVN
Nicola Ken Barozzi wrote: Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 from me. And i don't think that we can be held up by lack of support from various tools. There is capable command-line client already. I too think that timing is vital. We need to carefully consider whether we should get 2.1.5 out first. --David
RE: Proposal: release management guide (was Re: [RT] Versions)
Upayavira wrote: Reads very well, I say. All we need to do is decide if that is how we actually want to (and can) work! Great! I think we could wait one more day and see if there is some interesting feedback and then we can vote on it. One addition is to mention our policy on blocks and block status: Blocks and Block Stability -- Cocoon currently allows optional functionality to be included or excluded using a simple system called blocks, in which the functionality is included or excluded at compile time. [NB. This is a precursor to a more complete block system which is currently under development.] A block can have one of three statuses: unstable, stable or deprecated. An unstable block has an API that can change without notice. A stable block is subject to the same versioning process as described in this document. Similarly, when the entire functionality of a block is deprecated, it will be handled in the same way as any other deprecated code within Cocoon. = Does this seem reasonable? Yes, absolutely. Great! Carsten
Re: Proposal: release management guide (was Re: [RT] Versions)
+1 - one extra: when the external lib mismatch can occur, then we should provide that knowledge in the update docs and add a warning -marc= (being glad he posted that arp link :-)) snip what=the historical long mail from one eloquent Sir C. Ziegler / -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Proposal: release management guide (was Re: [RT] Versions)
Reinhard Poetz wrote: Carsten Ziegeler wrote: snip type=large / Examples Here are some examples to demonstrate the compatibility: Original VersionNew VersionUsage CompatibleExtension Compatible 2.2.3 2.2.4 Yes Yes 2.2.3 2.3.1 Yes No 2.2.3 3.0.0 No No Note: while some of the cells say no, it is possible that the versions may be compatible, depending very precisely upon the particular APIs used by the application. I think we will need *a lot* of testcases to guarentee the compatibility. I agree, however on the sort-term and more pragmatic side of things: all users out there are a very large test-cases-base, since we're up to publishing this versioning contract to them we should at least promptly react when people notice we've not lived up to it. (which should be: re-introduce promised backwards compat and/or change the version number) -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Marc Portier wrote: Tim Larson wrote: On Wed, Apr 21, 2004 at 12:29:26AM +0200, Marc Portier wrote: snip / 2/ should getNamespace() exist at all, it seems to return the same thing as getFullQualifiedId()? Maybe a historical idea waiting to get thrown out? +1 historical, just make sure getFullyQualifiedId() does not break. yep working on this, getting there, and makes me wonder about parent relations again... (see further) 3/ can getId() ever return null or on a widget instance? Can't we carefully asume programming error and allow for the accidental NPE to be thrown +1 after we fix the top-level form widget to not return null or . (I don't remember which, but it returns one of those two values). Anyway, we somehow need to supply the form widget with an id to resolve widget naming conflicts when there is more than one form on a page. I think it should come from somewhere other than the form definition, because it is the page designer's role to prevent form id conflicts, not the role of the form designer. For example, imagine a page containing two instances of the same form definition, tied to separate data. The page designer knows there is a conflict, but the form designer has no way to prevent it. Maybe there is a way to auto-generate the id's? thx for explaining. I think we should go for returning null today then, and see how it turns out in future 2nd thought: we should assign specific semantic meaning to both null and - return null: not allowed for widget, 'this is abstract' for widget-definition (see also http://wiki.cocoondev.org/Wiki.jsp?page=WoodyRefactoring) - return : this widget is top-level even if we get into forms with named id's, then there will be still use for 'anonymous' top-level I suppose so I'm going for getId on form to return (which it was) and removing getId() == null checks since I favour the NPE here plus updating javadoc @return to clarify these semantics. 4/ same question on getDefinition() There once was talk about the possibility of widgets without definitions: http://marc.theaimsgroup.com/?t=10716524511r=1w=2 Does this have any relevance to your question? yep related, and the same solution should do now too: starting from AbstractWidget down the hierarchy it should be there, and provided by the getDefinition() people overloading AbstractWidget.getDefinition() to return null (or setting it during construction with super(null) should be made aware to also overload getLocation() and generateDisplayData() (which was the reason for me asking now) (although they should probably not use that base class then, since it explicitely asks for a definition in its constructor, maybe throwing IllegalArgument makes sense on the constructor) apart from this last statement (which is so untrue it should be ignored) I'm going for this 5/ should we rename ContainerDelegate to simply WidgetList (and the ContainerDefintionDelegate to WidgetDefinitionList) +1 to something like that. thx 6/ union seems to generate fi:field in stead of fi:union this surprised me a bit, is that the goal? Yes, I was trying to surprise you ;) No, really I just noticed that this part of the union widget acted just like a field as far as the template layer was concerned, so I used the same name to prevent having to copy-and-paste support code in the template handling. A better route might be to change both field and union to use something more generic like fi:value in the templating layer. thx for explaining, adding a comment would take away the surprise 7/ should validation stop as soon as possible or continue to allow all validation errors to be set? Don't know which is best. *If* we cannot decide (due to different needs in different usecases) then we will need to add an attribute to let the form designer control the behaviour. hm, we should at least be consistent clarifying a bit more: we seem to have two distinct cases: widgets with child-widgets - i've seen code that doesn't evaluate the parent if one of the kids is invalid - but all kids seem to be evaluated even if a previous brother failed widgets with validation on definition and widget level - widget level rules stop evaulation if the definition level was not ok, and as soon as one of the widget-level validations fails I haven't given it much thought yet, if there are clear positions out there I'm quite happy to just enforce code wise (and add some javadocs removing any possible future surprise) so comments welcome 8/ setParent() on abstractWidget should be write-once IMHO, possibly yielding RTE (IllegalState?) when someone tries to reset it See: http://wiki.cocoondev.org/Wiki.jsp?page=ImmutableWidgetDefinitions The widget-definition repositories will allow widget-definitions to have multiple parents, so imho we should remove setParent() completely. Please see the Walker solution on that wiki page for more details. have to come back on that later (need to run now) (ah, the pleasure of being
cocoon.xml please give me a hint
Hi all, please can someone give me a hint of using the right class. I have a generated SVG DOM in a transformer and want to include it at the sax stream. I have tried 1. org.apache.cocoon.xml.IncludeXMLConsumer and 2. org.apache.cocoon.xml.dom.DOMStreamer the 2. worked well but the 1. worked only when I direct serialize as xml if a use a transformer it delete the node name I am now a little bit confused. I have seen the 1. used at ReadDOMSessionTransformer the only diff is that my extend the AbstractSAXTransformer Klaus
Re: Proposal: release management guide (was Re: [RT] Versions)
Marc Portier wrote: Upayavira wrote: Carsten, Reads very well, I say. All we need to do is decide if that is how we actually want to (and can) work! One addition is to mention our policy on blocks and block status: Blocks and Block Stability -- Cocoon currently allows optional functionality to be included or excluded using a simple system called blocks, in which the functionality is included or excluded at compile time. [NB. This is a precursor to a more complete block system which is currently under development.] A block can have one of three statuses: unstable, stable or deprecated. An unstable block has an API that can change without notice. A stable block is subject to the same versioning process as described in this document. Similarly, when the entire functionality of a block is deprecated, it will be handled in the same way as any other deprecated code within Cocoon. = Does this seem reasonable? very, I would even suggest (already) that blocks in state 'stable' would maintain an own release numbering scheme which complies to these rules. I thought about this. But, given that they will be released as a part of Cocoon, I cannot see how that would work. Unless they are released as separate packages that happen independently, they'll need to follow Cocoon's versioning system, IMO. Regards, Upayavira
Re: Proposal: release management guide (was Re: [RT] Versions)
Carsten Ziegeler wrote: snip type=lots of good stuff/ Deprecation and Exceptions -- To continue the Cocoon development and to keep up with the innovations, parts of Cocoon might get deprecated; this includes parts of the user API and also parts of the developer API. For my understanding, what exactly do these terms mean (i.e. 'user API' and 'developer API') ? Are they paralel to the concepts of 'usage compatibility' and 'extension compatibility' or are they part of a separate classification? If a part of the user API is deprecated, this will be flagged through run-time warnings that appear in the logs but remain supported. This indicates that an upcoming minor (or major) release will no longer support this. If a part of the developer API is deprecated it will be removed with the next major, minor or patch release. Don't you mean .. removed with the next major or minor release ? For developers there is one exception to this rule: private API. Cocoon has some internal classes and interfaces that are not meant to be used by a Cocoon developer (someone extending Cocoon). These pieces of Java code are clearly marked in the Javadocs and should not be used. They might change even between a patch version change in an incompatible way without providing a workaround! snip type=more good stuff/ As part of the effort of establishing versioning rules and consequently the separation of different areas of our code base (public, private, etc) we could review some of the related proposals that have been discussed in the past. Perhaps we could tackle these concerns as part of this effort. Especially I am thinking of the proposals towards modularisation of the code base into functional modules (API, SPI, etc.) and javadoc extensions for signalling private or public API membership. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105766229504616w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106424060330963w=2 -- Unico
Re: Remove Ant Task from Scratchpad
On 19 Apr 2004, at 09:50, Upayavira wrote: I would like to propose that we remove the Ant task from the scratchpad. +1 Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Continue Development of 2.1.x
Hi, On 19 Apr 2004, at 09:08, Carsten Ziegeler wrote: I have counted +1 from Stefano, Antonio, Reinhard, Ralph and Gianugo (and myself of course :) ) And we have the concerns from Ugo and Joerg? What do you two think, now after I could convince Ralph :) ? belated +1 Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
RE: Proposal: release management guide (was Re: [RT] Versions)
On Wed, 2004-04-21 at 09:33, Carsten Ziegeler wrote: snip/ External Libraries -- Cocoon uses a set of external libraries (like for example Avalon, Xalan or Xerces). Inbetween any release, even patch releases, the versions of the external libraries might be updated to any version. If between patch releases we want to keep everything as compatible as possible, then we shouldn't upgrade external libraries either (except if known to be completely safe). Otherwise, all the effort we put into keeping our own stuff compatible could be lost because of that. Therefore if your application is written against a special API of an external library it might be that this API of the external library changes inbetween two Cocoon versions and therefore your application does not work properly anymore (or even does not compile anymore). Unfortunately, this issue is out of the scope of Cocoon. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Serializers issues...
Hi, On 20 Apr 2004, at 15:41, Pier Fumagalli wrote: I'd like to commit this as a cocoon-2.1 block if noone objects, as a serializers block... It comes with full encoding/charsets/i18n support, and i'd like to mark it (for now) as unstable... Sounds good to me (though I would love to see Xalan fixed, I've got no free time so I'm happy with your solution!). Cheers, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [VOTE] Move to SVN
Hi, Nicola Ken Barozzi wrote: Since we are working a lot with branches, and there will be even more moving stuff around when the blocks will hit the street, I propose that we move Cocoon to use SVN. It works very well and we will be pushed to use it in any case in the near future. +1 for moving to SVN (though I disagree with your reason, I agree for all the other benefits SVN brings!) On 21 Apr 2004, at 12:01, David Crossley wrote: I too think that timing is vital. We need to carefully consider whether we should get 2.1.5 out first. Yes. I'd be -1 on moving to SVN before the next release - though I guess now is the time to start experimenting, to make sure we have a smooth transition. Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
RE: [VOTE] Move to SVN
SVN works over http or https so I have been able to use it from behind my corporate firewall. Right now I can't use cvs to apache. Ralph -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Move to SVN What are the current problems we have with CVS that you want to solve with such a move? Carsten
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Ugo Cei wrote:
Marc Portier wrote:
3/ can getId() ever return null or on a widget instance? Can't we
carefully asume programming error and allow for the accidental NPE to
be thrown
if (id == null || id.equals()) {
throw new FormsConfigurationException(Widget id cannot be null.);
}
where FormsConfigurationException extends RuntimeException, of course ;-).
yeah, but this is something that never needs to be catched it really is
a programming error, so I find the test for null unesessary and the
possible resulting NPE as more then RTE enough to commincate the coding
error.
in any case (see other message) there seems to be room for some
semantical meaning to and null
7/ should validation stop as soon as possible or continue to allow all
validation errors to be set?
If you can't make it optional, allow it to continue.
again see other message for the actual various conditions to consider
currently I have the same feeling that by default we should continue,
and actually am not so far to see a real need for making it optional.
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Serializers issues...
Pier Fumagalli pier at betaversion.org writes: Me and Jerm (who's working right beside me ATM) have found some problems with the serializers shipped with XALAN, as outlined in those messages that randomly hit the mailing list... Did I miss them? Which messages and which problems? Why are the serializers not fixed in Xalan? I'm totally unable to create correct SCRIPT LINK and TEXTAREA HTML tags with Xalan... Ah, yes, I remember. Dunno, maybe it's my config, but with the garbage serializer, I'm able to validate my pages at the W3C validator service, with the default one, I'm not... HTML or XHTML? Snippet from my Woody/CForms application: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; ... link href=cforms/resources/woody.css type=text/css rel=stylesheet script type=text/javascript src=cforms/resources/mattkruse-lib/OptionTransfer.js/script ... textarea title= name=longCause id=longCause type=textarea/textarea ... or in XHTML: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; ... link href=cforms/resources/woody.css type=text/css rel=stylesheet /script type=text/javascript src=cforms/resources/mattkruse-lib/OptionTransfer.js / ... textarea title= name=longCause id=longCause type=textarea / Are they wrong in your understanding? Wasn't the issue reports about missing spaces before closing the tag? Nothing against your serializers, I'm only curious. And it's scary that in our welcome XSLT we specify a META tag with a charset and content type... Means that (probably) someone found that bug beforehands and patched it with the XSLT... But isn't this only due to insufficient browser capabilities? IMO it's ok if an XHTML does not add the meta tag. Only those stupid browsers that ignore the xml declaration! Why they're not fixed in there? Because I'm not smart enough to look into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in the first place anyway (and that's what XALAN is relying on)... You mean the output options should not be under control of the stylesheet? Maybe we can simply fix it by setting the encoding in the response header: http://issues.apache.org/bugzilla/show_bug.cgi?id=26997. As recent browsers look first there before relying on the meta tag information. AFAIK your serializers already add the encoding to the header, don't they? Joerg
Re: Proposal: release management guide (was Re: [RT] Versions)
On Wed, Apr 21, 2004 at 09:33:14AM +0200, Carsten Ziegeler wrote: The Cocoon Versioning Manifest (CVM) This document covers how the Cocoon project is versioned. Since Cocoon is a framework, it is very important to define a stable API for users and developers. However, we also need to move Cocoon forward, technologically. To balance these two needs, a strict policy of versioning is required, which users can rely upon to understand the limitations, restrictions, and the changes that can occur from one release to the next. I am *so* happy to see this policy being worked on :) When I earlier proposed we write a document like this the interest seemed minimal, so I did not push very hard. Glad to see it is gathering steam now. Applications that write against a particular version will remain usage compatible against later versions, until the major number changes. Writing an application against a version means that this application does not use any deprecated API of that version. Therefore minor version changes are only usage compatible from one minor version to the direct following one. For example 2.2 is usage compatible to 2.1. But 2.3 is not necessary usage compatible to 2.1, although it is usage compatible to 2.2. As long as you don't use deprecated API, your application is usage compatible across all minor versions. Example: - a feature is introduced in 2.0 and used by the application. - it is deprecated in 2.2. - it will be removed in 2.3. If it happens that 2.3 comes very soon after 2.2, then the deprecated code in effect was just deleted and not put through a normal deprecation cycle. Perhaps we need to also set a minimum length of time that deprecated features will live, to ensure that deprecation is a meaningful process and not just a formality. Also, we should define what deprecation means, such as whether simple but severe security issues will receive updates, even though more ongoing or complex updates will not happen to deprecated code. External Libraries -- Cocoon uses a set of external libraries (like for example Avalon, Xalan or Xerces). Inbetween any release, even patch releases, the versions of the external libraries might be updated to any version. Therefore if your application is written against a special API of an external library it might be that this API of the external library changes inbetween two Cocoon versions and therefore your application does not work properly anymore (or even does not compile anymore). Unfortunately, this issue is out of the scope of Cocoon. I echo Bruno's concern here. If we do an incompatible update of a library, and then cocoon starts to rely on the new features, then a user cannot just revert the library update to get a system as compatible as our versioning scheme would indicate we are shipping. To our users and developers it would feel like we broke our own versioning rules. Since *we* are the ones bundling the libraries I think this issue is in the scope of Cocoon. If a user were pulling in external libraries on their own, then that is what would be out of our scope. --Tim Larson
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Marc Portier wrote: yeah, but this is something that never needs to be catched it really is a programming error, so I find the test for null unesessary and the possible resulting NPE as more then RTE enough to commincate the coding error. The problem with the NPE is that you'd need to look at the stacktrace to find what the exception is about, as you get no meaningful message, and the exception might be thrown when you try to dereference the null pointer, which could be far from where getId() is called. What I propose is to throw a RTE when the widget is built. Fail early, if you can. Admittedly, this is just a convenience for the developer. Ugo
Re: Proposal: release management guide (was Re: [RT] Versions)
Upayavira wrote: Marc Portier wrote: Upayavira wrote: Carsten, Reads very well, I say. All we need to do is decide if that is how we actually want to (and can) work! One addition is to mention our policy on blocks and block status: Blocks and Block Stability -- Cocoon currently allows optional functionality to be included or excluded using a simple system called blocks, in which the functionality is included or excluded at compile time. [NB. This is a precursor to a more complete block system which is currently under development.] A block can have one of three statuses: unstable, stable or deprecated. An unstable block has an API that can change without notice. A stable block is subject to the same versioning process as described in this document. Similarly, when the entire functionality of a block is deprecated, it will be handled in the same way as any other deprecated code within Cocoon. = Does this seem reasonable? very, I would even suggest (already) that blocks in state 'stable' would maintain an own release numbering scheme which complies to these rules. I thought about this. But, given that they will be released as a part of Cocoon, I cannot see how that would work. Unless they are released as separate packages that happen independently, they'll need to follow Cocoon's versioning system, IMO. Regards, Upayavira I think so too and IIRC this was also the conclusion of a discussion about the lifecylce of _real_ blocks. -- Reinhard
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On 21.04.2004 15:34, Ugo Cei wrote:
Marc Portier wrote:
yeah, but this is something that never needs to be catched it really
is a programming error, so I find the test for null unesessary and the
possible resulting NPE as more then RTE enough to commincate the
coding error.
The problem with the NPE is that you'd need to look at the stacktrace to
find what the exception is about, as you get no meaningful message, and
the exception might be thrown when you try to dereference the null
pointer, which could be far from where getId() is called. What I propose
is to throw a RTE when the widget is built. Fail early, if you can.
Admittedly, this is just a convenience for the developer.
NPE is really bad - not only here - for the two mentioned reasons. But
if you insist on your NPE you can change Ugo's proposal to
if (id == null) {
throw new NPE(id must not be null);
}
So we have NPE, which is RuntimeE, meaningful message and early failure :)
Joerg
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On 21.04.2004 13:53, Marc Portier wrote: so I'm going for getId on form to return (which it was) and removing getId() == null checks since I favour the NPE here Please not waiting for the NPE somewhere latter in the code for the reasons Ugo pointed out. 7/ should validation stop as soon as possible or continue to allow all validation errors to be set? Don't know which is best. *If* we cannot decide (due to different needs in different usecases) then we will need to add an attribute to let the form designer control the behaviour. hm, we should at least be consistent clarifying a bit more: we seem to have two distinct cases: widgets with child-widgets - i've seen code that doesn't evaluate the parent if one of the kids is invalid - but all kids seem to be evaluated even if a previous brother failed widgets with validation on definition and widget level - widget level rules stop evaulation if the definition level was not ok, and as soon as one of the widget-level validations fails I haven't given it much thought yet, if there are clear positions out there I'm quite happy to just enforce code wise (and add some javadocs removing any possible future surprise) so comments welcome IMO validation should always run on all widgets as it must be possible for the user to get a whole form fixed in one step: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107962387820282w=4 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107963156530885w=4 Joerg
Re: Proposal: release management guide (was Re: [RT] Versions)
On 21.04.2004 09:33, Carsten Ziegeler wrote: Usage Compatibility --- 'Usage' compatibility guarantees that an application written by a Cocoon user is compatible. All files developed by a typical Cocoon user like xml files, sitemaps, stylesheets (elements and namespace declarations) keep on being picked up by the machinery and are dealt with correctly (sitemap semantics, generator/transformer-picked up elements, config file entries...). In fact this should cover everything (including flow script) but except own Java code. Applications that write against a particular version will remain usage compatible against later versions, until the major number changes. Writing an application against a version means that this application does not use any deprecated API of that version. Therefore minor version changes are only usage compatible from one minor version to the direct following one. For example 2.2 is usage compatible to 2.1. But 2.3 is not necessary usage compatible to 2.1, although it is usage compatible to 2.2. As long as you don't use deprecated API, your application is usage compatible across all minor versions. Somewhat inaccurate. IMO it must read As long as you don't use deprecated API and the API you rely on does not get deprecated, your application is usage compatible across all minor versions. Example: - a feature is introduced in 2.0 and used by the application. - it is deprecated in 2.2. - it will be removed in 2.3. Otherwise this would oppose to this example. External Libraries -- Cocoon uses a set of external libraries (like for example Avalon, Xalan or Xerces). Inbetween any release, even patch releases, the versions of the external libraries might be updated to any version. Therefore if your application is written against a special API of an external library it might be that this API of the external library changes inbetween two Cocoon versions and therefore your application does not work properly anymore (or even does not compile anymore). Unfortunately, this issue is out of the scope of Cocoon. Let's restrict this to updates of libraries without the need for touching Cocoon code. This means the user must be able to revert the update for his local cocoon installation. This high innovention has - at least in theory - the price of maintaining innovation + invention = innovention ;-) Joerg
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Ugo Cei wrote: Marc Portier wrote: yeah, but this is something that never needs to be catched it really is a programming error, so I find the test for null unesessary and the possible resulting NPE as more then RTE enough to commincate the coding error. The problem with the NPE is that you'd need to look at the stacktrace to find what the exception is about, as you get no meaningful message, and the exception might be thrown when you try to dereference the null pointer, which could be far from where getId() is called. What I propose is to throw a RTE when the widget is built. Fail early, if you can. yep that is the idea completely id should become a final member of the definition as such it needs to be provided during build it could still be set to null, but would result in a state 'abstract' of the definition meaning it is an a state that will make the createInstance() on it to throw a RTE (IllegalState IMO) (see wiki page WoodyRefactoring) this will result in instances that can only point back to definitions that have an id set != null so getId() on instance level will effectively lead to always returning a non-null unless we have made a programming error in setting up this chain, this is not a circumstance IMO that requires additional RT checking to generate specific RTE's Admittedly, this is just a convenience for the developer. more then needed, no? it seems odd to me to do a runtime check to generate a log message saying: The developer of this code couldn't correctly implement his own design vision, please let him be excused and thank him for the fact that he could at least log this nicely? ah true open source! we could actually even provide the patch in the error-message and encourage users to send it to bugzilla :-) -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On 21.04.2004 20:03, Marc Portier wrote: yeah, but this is something that never needs to be catched it really is a programming error, so I find the test for null unesessary and the possible resulting NPE as more then RTE enough to commincate the coding error. The problem with the NPE is that you'd need to look at the stacktrace to find what the exception is about, as you get no meaningful message, and the exception might be thrown when you try to dereference the null pointer, which could be far from where getId() is called. What I propose is to throw a RTE when the widget is built. Fail early, if you can. yep that is the idea completely id should become a final member of the definition as such it needs to be provided during build it could still be set to null, but would result in a state 'abstract' of the definition meaning it is an a state that will make the createInstance() on it to throw a RTE (IllegalState IMO) (see wiki page WoodyRefactoring) this will result in instances that can only point back to definitions that have an id set != null so getId() on instance level will effectively lead to always returning a non-null unless we have made a programming error in setting up this chain, this is not a circumstance IMO that requires additional RT checking to generate specific RTE's +1 sounds ok. Joerg
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Joerg Heinicke wrote:
On 21.04.2004 15:34, Ugo Cei wrote:
Marc Portier wrote:
NPE is really bad - not only here - for the two mentioned reasons. But
if you insist on your NPE you can change Ugo's proposal to
if (id == null) {
throw new NPE(id must not be null);
}
So we have NPE, which is RuntimeE, meaningful message and early failure :)
Sorry guys, be honest: you can't expect every deref in Java to be
proceeded by this kind of test?
I admit NPE's are bad, but they indicate programming errors
this one will surely come up during development test (believe me:
getId() is not something that will happen only in rare cases, I think
every sweap through any widget lifecycle is bound to call it at least
twice IMO)
by the way: we should be discussing this in the light of getDefinition()
not in the light of getId():
it will not even be used for .equals() IIRC, reconsidering this I think
the returned string will only be used as an argument to
addCDATAAttribute, hm never tried that, does that yield an NPE?
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Versions
On 20.04.2004 12:28, Carsten Ziegeler wrote: On the other hand I didn't get the feeling that there were many problems when upgrading from 2.0 to 2.1. This might be due to not upgrading at all of course. Probably users start a project with a specific Cocoon version/the latest release at this time. During the project they do only the minor upgrades. When starting the next project they use the latest available version at that time again. So upgrade problems might be only rarely reported. There were many complains from users that upgrading from 2.0.x to 2.1 wasn't that easy. Really? I never got this impression. On the list or from your customers? Not that this will have any impact on the result of this discussion ... just curious. Yes, a clear matching is required. We would have the clear matching of Any cocoon version = 2.1 is in the cocoon-2.1 repository :) *prust* really good. Renaming it without any impact should even possible with CVS. Otherwise we can wait til the move to SVN. Ok, but we don't need to make a repository just because we change the version number. It only makes sense if we continue the development. We end up in to many repositories that are actually unused. I don't see any problem with branching a previous version if the need arises. Ok, convinced - and this lazy branching is much better than the eager branching we have at the moment. Joerg
Re: Serializers issues...
On 21.04.2004 15:27, Joerg Heinicke wrote: I'm totally unable to create correct SCRIPT LINK and TEXTAREA HTML tags with Xalan... Dunno, maybe it's my config, but with the garbage serializer, I'm able to validate my pages at the W3C validator service, with the default one, I'm not... Don't know if you saw my commit to the cforms stylesheets, but I got my form both XHTML 1.0 and HTML 4.01 strict valid with the default Xalan serializers including script, link and textarea in the page. Could it be you have an old Xalan being loaded instead of the Cocoon one (aka endorsed libs)? Joerg
Re: Serializers issues...
On 21 Apr 2004, at 14:27, Joerg Heinicke wrote: Pier Fumagalli pier at betaversion.org writes: Dunno, maybe it's my config, but with the garbage serializer, I'm able to validate my pages at the W3C validator service, with the default one, I'm not... HTML or XHTML? Snippet from my Woody/CForms application: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; ... link href=cforms/resources/woody.css type=text/css rel=stylesheet script type=text/javascript src=cforms/resources/mattkruse-lib/OptionTransfer.js/script ... textarea title= name=longCause id=longCause type=textarea/textarea ... or in XHTML: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; ... link href=cforms/resources/woody.css type=text/css rel=stylesheet /script type=text/javascript src=cforms/resources/mattkruse-lib/OptionTransfer.js / ... textarea title= name=longCause id=longCause type=textarea / Are they wrong in your understanding? Wasn't the issue reports about missing spaces before closing the tag? Nothing against your serializers, I'm only curious. We were looking at it monday morning with Jeremy, and we have ben unable to get to the point where you were (took us roughly 2 hours round and round the configs)... Took me 30 minutes to patch up the Garbage serializers, and another hour to put it into a nice block, making sure it built and so on... The problem was that when we fixed something somewhere (on some browser) it broke on another, and so on and so forth... With the Garbage serializer that doesn't happen, and we can go on with the development. If someone has better suggestions, please let us know! :-P And it's scary that in our welcome XSLT we specify a META tag with a charset and content type... Means that (probably) someone found that bug beforehands and patched it with the XSLT... But isn't this only due to insufficient browser capabilities? IMO it's ok if an XHTML does not add the meta tag. Only those stupid browsers that ignore the xml declaration! ? I'm talking about this tag found in the XSLT for the home page of our distro (welcome.xslt): meta http-equiv=Content-Type content=text/xhtml; charset=UTF-8/ If I change the serializer configuration (for example, change encoding to ISO-8859-1, I don't like UTF-8) that tag will be copied across to the output, and the browser will panic. That meta tag MUST be written by the HTML serializer (or XHTML serializer), and must NOT be encoded in an XSLT in a pipeline, as pipelines use char(s) and not byte(s). Why they're not fixed in there? Because I'm not smart enough to look into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in the first place anyway (and that's what XALAN is relying on)... You mean the output options should not be under control of the stylesheet? Absolutely not... Cocoon internally is 100% unaware of any whatsoever encoding of characters... For instance it doesn't even know whether a character such as (C) [the copyright character] can be encoded in the output (imagine that I use an US-ASCII encoding). It _must_ not know it, that's the realm of the serializer. Maybe we can simply fix it by setting the encoding in the response header: http://issues.apache.org/bugzilla/show_bug.cgi?id=26997. As recent browsers look first there before relying on the meta tag information. AFAIK your serializers already add the encoding to the header, don't they? The Garbage serializers add a META tag if and only if they can do it (they know the HTML/XHTML DTDs, they know where to output those tags), but in XML (for example) it doesn't and it uses the ?xml encoding=...? prolog pseudo-processing instruction... And in addition, it prepares the correct header, with full content-type AND charset... That serializer simply plays on the safe side... It tries to fix all the bugs and incoherences in the different browsers by not only taking care of outputting (or not) close tags, but also to prepare a compatible content-type header so that most (trivial) problems can be avoided... Just in case (just in case) it also converts all the different cases of HTML tags to upper and of attributes to lower (both lower cases in XHTML) as outlined in the spec... It basically does all those boring jobs that makes the page safe, and (to do that) it's EXTREMELY slow (well, not that much) :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On 21.04.2004 20:14, Marc Portier wrote:
NPE is really bad - not only here - for the two mentioned reasons. But
if you insist on your NPE you can change Ugo's proposal to
if (id == null) {
throw new NPE(id must not be null);
}
So we have NPE, which is RuntimeE, meaningful message and early
failure :)
Sorry guys, be honest: you can't expect every deref in Java to be
proceeded by this kind of test?
I admit NPE's are bad, but they indicate programming errors
this one will surely come up during development test (believe me:
getId() is not something that will happen only in rare cases, I think
every sweap through any widget lifecycle is bound to call it at least
twice IMO)
But you can not give the form developer a NPE IMO as it happened for the
bindings:
widget = getWidget(nonExistingId);
widget.aFunction();
If this won't be the case for your proposal I'm ok with it.
Joerg
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Il giorno 21/apr/04, alle 20:14, Marc Portier ha scritto:
Joerg Heinicke wrote:
On 21.04.2004 15:34, Ugo Cei wrote:
Marc Portier wrote:
NPE is really bad - not only here - for the two mentioned reasons.
But if you insist on your NPE you can change Ugo's proposal to
if (id == null) {
throw new NPE(id must not be null);
}
So we have NPE, which is RuntimeE, meaningful message and early
failure :)
Sorry guys, be honest: you can't expect every deref in Java to be
proceeded by this kind of test?
No, but since you brought up the issue and asked for an input ...
anyway, your latest proposal looks fine to me.
Ugo
Re: Serializers issues...
On 21.04.2004 20:44, Pier Fumagalli wrote: We were looking at it monday morning with Jeremy, and we have ben unable to get to the point where you were (took us roughly 2 hours round and round the configs)... Took me 30 minutes to patch up the Garbage serializers, and another hour to put it into a nice block, making sure it built and so on... The problem was that when we fixed something somewhere (on some browser) it broke on another, and so on and so forth... With the Garbage serializer that doesn't happen, and we can go on with the development. The pragmatic programmer :) What I have indeed *not* done was testing it in every browser. You seemed to focus on the validness, so I have looked only for this. And it's scary that in our welcome XSLT we specify a META tag with a charset and content type... Means that (probably) someone found that bug beforehands and patched it with the XSLT... But isn't this only due to insufficient browser capabilities? IMO it's ok if an XHTML does not add the meta tag. Only those stupid browsers that ignore the xml declaration! ? I'm talking about this tag found in the XSLT for the home page of our distro (welcome.xslt): meta http-equiv=Content-Type content=text/xhtml; charset=UTF-8/ Yes, I know. And I refered to the comment written above it. What I meant was if the encoding is given through the XML declaration there is no further need for the meta tag. But the spec states that both xml declaration and meta tag must be included while the xml declaration takes precedence (http://www.w3.org/TR/xhtml1/#C_9). If I change the serializer configuration (for example, change encoding to ISO-8859-1, I don't like UTF-8) that tag will be copied across to the output, and the browser will panic. That meta tag MUST be written by the HTML serializer (or XHTML serializer), and must NOT be encoded in an XSLT in a pipeline, as pipelines use char(s) and not byte(s). Of course, the possible araised problems are obvious. Why they're not fixed in there? Because I'm not smart enough to look into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in the first place anyway (and that's what XALAN is relying on)... You mean the output options should not be under control of the stylesheet? Absolutely not... Cocoon internally is 100% unaware of any whatsoever encoding of characters... For instance it doesn't even know whether a character such as (C) [the copyright character] can be encoded in the output (imagine that I use an US-ASCII encoding). It _must_ not know it, that's the realm of the serializer. Yes, also obvious. I only did not know if that was the point of your statement. Joerg
Handling Iterators in JXTG
Am I wrong or there is no way to handle iterators in JXTG? One can use forEach
for collections but I sometimes would like to pass and iterator to a view to
process larger result sets.
In Hibernate you can:
var list = session.createQuery(from LargeTable).list() which creates a whole
collection at once but you can also do:
var iterator = session.createQuery(from LargeTable).iterate() which makes
generating view much less memory consuming.
Maybe something like:
jx:while test=${it.hasNext()}
jx:set car=current value=${it.next()}/
${current.value}br/
/jx:while
The syntax is ugly I know but after a little tuning it would be very useful.
lg
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: Handling Iterators in JXTG
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use forEach
for collections but I sometimes would like to pass and iterator to a view to
process larger result sets.
In Hibernate you can:
var list = session.createQuery(from LargeTable).list() which creates a whole
collection at once but you can also do:
var iterator = session.createQuery(from LargeTable).iterate() which makes
generating view much less memory consuming.
Maybe something like:
jx:while test=${it.hasNext()}
jx:set car=current value=${it.next()}/
${current.value}br/
/jx:while
The syntax is ugly I know but after a little tuning it would be very useful.
lg
jx:forEach should work on Iterators (as well Enumerations):
sendPage(page.html, {iteration: session.createQuery(from
LargeTable).iterate()});
jx:forEach var=current items=${iteration}
${current.value}/br
/jx:forEach
Chris
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Ugo Cei wrote:
Il giorno 21/apr/04, alle 20:14, Marc Portier ha scritto:
Joerg Heinicke wrote:
Marc Portier wrote:
NPE is really bad - not only here - for the two mentioned reasons.
But if you insist on your NPE you can change Ugo's proposal to
if (id == null) {
throw new NPE(id must not be null);
}
So we have NPE, which is RuntimeE, meaningful message and early
failure :)
Sorry guys, be honest: you can't expect every deref in Java to be
proceeded by this kind of test?
No, but since you brought up the issue and asked for an input ...
anyway, your latest proposal looks fine to me.
yeah, sorry for assuming too much context upfront
thx for acking
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Joerg Heinicke wrote: But you can not give the form developer a NPE IMO as it happened for the bindings: widget = getWidget(nonExistingId); widget.aFunction(); If this won't be the case for your proposal I'm ok with it. nope, this is entirely different by the way is what you mention above fixed now? I've no recollection on it. (ah this short memory is a bliss most of the time, thx for keeping up with it, ... euh what was your name again?) Joerg (ah yes, thank you!) -marc= (in an odd and silly state of mind, specially after reading Steven's latest blog entry and finding myself in community discussions, I'ld better get to some more coding :-)) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Modular database component
On 20.04.2004 07:49, Reinhard Poetz wrote: Following this I don't see the need for a. calling DB from within Flowscripts You mean direct JDBC? Hmm.. I don't like the idea, but here Groovy can take the role a lot better than Javascript. Note, Groovy has built in SQL support and that is good. From Antonio's comment I guess he just misread your comment. To restate it: Reinhard does not want flow scripts calling DB. Yes, I don't like the idea too. It's good for prototyping but I wouldn't write my applications with direct DB calls from within the flow layer. I don't want direct DB calls from within Groovy as Flow language *also* because this mixes concerns!!! Same here. DB should not be called from flow script - neither JavaScript nor Groovy nor XYZ. The thing is about page flow. b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP I will use this combination for (2) it is more powerful than the proposed. Also note, JXTG is useful in combination with CForms. It allow you to easy make a dynamic listbox or show a simple list report for users. It is really useful have JXTG at hand. I really like JXTG but for now it has *no* direct DB access. You have to pass the objects to the pipeline within cocoon.sendPage*() and this is good! Same here again. I wonder why templating languages shall be featured up with db access. What I want to tell all users clearly is that they should avoid writing SQL-statements. Integrating SQL in applications is the start of a maintainence nightmare and IMHO we should clearly warn them using XSP, Groovy or any other templating system requiring you to write SQL *into* the code. Once again, I really like e.g. JXTG but it should *never* contain SQL statements. IMO the same is true for Groovy scripts. +1 (to avoid writing same here again :) ) Joerg
Re: Serializers issues...
On 21 Apr 2004, at 19:41, Joerg Heinicke wrote: On 21.04.2004 15:27, Joerg Heinicke wrote: I'm totally unable to create correct SCRIPT LINK and TEXTAREA HTML tags with Xalan... Dunno, maybe it's my config, but with the garbage serializer, I'm able to validate my pages at the W3C validator service, with the default one, I'm not... Don't know if you saw my commit to the cforms stylesheets, but I got my form both XHTML 1.0 and HTML 4.01 strict valid with the default Xalan serializers including script, link and textarea in the page. Could it be you have an old Xalan being loaded instead of the Cocoon one (aka endorsed libs)? Err.. No! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On 21.04.2004 22:01, Marc Portier wrote: by the way is what you mention above fixed now? I've no recollection on it. There was no general fix. I only added the null check to all bindings classes I got a NPE from when having an error in my binding files. Joerg
Re: Serializers issues...
On 21 Apr 2004, at 20:22, Joerg Heinicke wrote: On 21.04.2004 20:44, Pier Fumagalli wrote: We were looking at it monday morning with Jeremy, and we have ben unable to get to the point where you were (took us roughly 2 hours round and round the configs)... Took me 30 minutes to patch up the Garbage serializers, and another hour to put it into a nice block, making sure it built and so on... The problem was that when we fixed something somewhere (on some browser) it broke on another, and so on and so forth... With the Garbage serializer that doesn't happen, and we can go on with the development. The pragmatic programmer :) What I have indeed *not* done was testing it in every browser. You seemed to focus on the validness, so I have looked only for this. Frankly, we're a publication company... At this point in time we could totally care less about conformance, all we care about is that 99% of our customers can see the pages nicely as our designers planned them (and there's a HECK of CSS and JavaScript in them). For us differences in browsers are killers (and given that we ain't have enough time ATM, we can't adapt pipelines individually: one must work for all). And it's scary that in our welcome XSLT we specify a META tag with a charset and content type... Means that (probably) someone found that bug beforehands and patched it with the XSLT... But isn't this only due to insufficient browser capabilities? IMO it's ok if an XHTML does not add the meta tag. Only those stupid browsers that ignore the xml declaration! ? I'm talking about this tag found in the XSLT for the home page of our distro (welcome.xslt): meta http-equiv=Content-Type content=text/xhtml; charset=UTF-8/ Yes, I know. And I refered to the comment written above it. What I meant was if the encoding is given through the XML declaration there is no further need for the meta tag. But the spec states that both xml declaration and meta tag must be included while the xml declaration takes precedence (http://www.w3.org/TR/xhtml1/#C_9). Kewl, but then, does the XALAN XHTML serializer put it in there? If I change the serializer configuration (for example, change encoding to ISO-8859-1, I don't like UTF-8) that tag will be copied across to the output, and the browser will panic. That meta tag MUST be written by the HTML serializer (or XHTML serializer), and must NOT be encoded in an XSLT in a pipeline, as pipelines use char(s) and not byte(s). Of course, the possible araised problems are obvious. Why they're not fixed in there? Because I'm not smart enough to look into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in the first place anyway (and that's what XALAN is relying on)... You mean the output options should not be under control of the stylesheet? Absolutely not... Cocoon internally is 100% unaware of any whatsoever encoding of characters... For instance it doesn't even know whether a character such as (C) [the copyright character] can be encoded in the output (imagine that I use an US-ASCII encoding). It _must_ not know it, that's the realm of the serializer. Yes, also obvious. I only did not know if that was the point of your statement. One of ! :-) Pier smime.p7s Description: S/MIME cryptographic signature
Re: Handling Iterators in JXTG
On Wed, Apr 21, 2004 at 12:45:46PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use
forEach
for collections but I sometimes would like to pass and iterator to a view
to
process larger result sets.
In Hibernate you can:
var list = session.createQuery(from LargeTable).list() which creates a
whole
collection at once but you can also do:
var iterator = session.createQuery(from LargeTable).iterate() which makes
generating view much less memory consuming.
Maybe something like:
jx:while test=${it.hasNext()}
jx:set car=current value=${it.next()}/
${current.value}br/
/jx:while
The syntax is ugly I know but after a little tuning it would be very
useful.
lg
jx:forEach should work on Iterators (as well Enumerations):
sendPage(page.html, {iteration: session.createQuery(from
LargeTable).iterate()});
jx:forEach var=current items=${iteration}
${current.value}/br
/jx:forEach
Chris
I am afraid this does not work. The one with .list() does. the one with
iterate() gives this exception:
Original Exception: java.lang.NullPointerException
at
org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator.java:3328)
at
org.apache.cocoon.generation.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:2952)
at
org.apache.cocoon.generation.JXTemplateGenerator.generate(JXTemplateGenerator.java:2943)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:546)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:173)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:490)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:382)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.access$000(TreeProcessor.java:66)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor$TreeProcessorRedirector.cocoonRedirect(TreeProcessor.java:543)
at
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:58)
at
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:176)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:812)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:1479)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:266)
at inv10.invoke()
at org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:523)
at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:438)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:686)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
DO NOT REPLY [Bug 28522] New: - fd:aggregatefield and fd:split pattern
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28522.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28522
fd:aggregatefield and fd:split pattern
Summary: fd:aggregatefield and fd:split pattern
Product: Cocoon 2
Version: Current CVS 2.1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: CocoonForms
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Let me show my beautiful example :)
fd:aggregatefield id=nip required=false
fd:labelNIP:/fd:label
fd:datatype base=string
fd:validation
fd:nip
fd:failmessageInvalid NIP number./fd:failmessage
/fd:nip
/fd:validation
/fd:datatype
fd:split pattern=([0-9]{3})-([0-9]{2,3})-([0-9]{2})-([0-9]{2,3})
fd:map group=1 field=part1/
fd:map group=2 field=part2/
fd:map group=3 field=part3/
fd:map group=4 field=part4/
fd:failmessageNot a valid 10-digit NIP number./fd:failmessage
/fd:split
fd:combine expression='Concat(part1, -, part2, -, part3, -, part4)
'/
fd:widgets
fd:field id=part1
fd:labelNIP:/fd:label
fd:datatype base=string/
/fd:field
fd:field id=part2
fd:label-/fd:label
fd:datatype base=string/
/fd:field
fd:field id=part3
fd:label-/fd:label
fd:datatype base=string/
/fd:field
fd:field id=part4
fd:label-/fd:label
fd:datatype base=string/
/fd:field
/fd:widgets
/fd:aggregatefield
NIP is a polish rate payer identificator. I've written validator for it
and then I've encountered following problem. fd:split pattern doesn't work
correctly. For example. If I'll fill just single field then I get a message Not
a valid 10-digit NIP number.. That's correct. If I fill all fields with
integers I get Invalid NIP number.. That's correct and not correct :) In fact
it is an invalid NIP, but I can provide value 1-1-1-1 which not match the
pattern and I should get Not a valid 10-digit NIP number.. Moreover if I will
fill all fields but some of it will be a text instead of number I will get an
exception from my NIP validator :) because of course it'll be validated against
NIP rule not pattern. I've tried to change data types for parts to integer but
in this case it doesn't validate at all and always returns Not a valid 10-digit
NIP number..
Re: Serializers issues...
On 21.04.2004 22:46, Pier Fumagalli wrote: Yes, I know. And I refered to the comment written above it. What I meant was if the encoding is given through the XML declaration there is no further need for the meta tag. But the spec states that both xml declaration and meta tag must be included while the xml declaration takes precedence (http://www.w3.org/TR/xhtml1/#C_9). Kewl, but then, does the XALAN XHTML serializer put it in there? Try to guess it: no, it does not. Even the HTML serializer does it not if the elements are in the XHTML namespace. The XHTML serializer does it neither when the elements are not in XHTML namespace. Hey, this thing is hacky as hell :) And the validator is probably not testing every detail. I simply switched from html to xhtml when testing the validness. I think I'm not using XHTML namespace. Joerg
Re: Handling Iterators in JXTG
Ive just committed a fix for this.
Regards,
Chris
Leszek Gawron wrote:
On Wed, Apr 21, 2004 at 12:45:46PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use
forEach
for collections but I sometimes would like to pass and iterator to a view
to
process larger result sets.
In Hibernate you can:
var list = session.createQuery(from LargeTable).list() which creates a
whole
collection at once but you can also do:
var iterator = session.createQuery(from LargeTable).iterate() which makes
generating view much less memory consuming.
Maybe something like:
jx:while test=${it.hasNext()}
jx:set car=current value=${it.next()}/
${current.value}br/
/jx:while
The syntax is ugly I know but after a little tuning it would be very
useful.
lg
jx:forEach should work on Iterators (as well Enumerations):
sendPage(page.html, {iteration: session.createQuery(from
LargeTable).iterate()});
jx:forEach var=current items=${iteration}
${current.value}/br
/jx:forEach
Chris
I am afraid this does not work. The one with .list() does. the one with
iterate() gives this exception:
Original Exception: java.lang.NullPointerException
at
org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator.java:3328)
at
org.apache.cocoon.generation.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:2952)
at
org.apache.cocoon.generation.JXTemplateGenerator.generate(JXTemplateGenerator.java:2943)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:546)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:173)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:490)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:126)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:72)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:101)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:336)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:382)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.access$000(TreeProcessor.java:66)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor$TreeProcessorRedirector.cocoonRedirect(TreeProcessor.java:543)
at
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:58)
at
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:176)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:812)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:1479)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:266)
at inv10.invoke()
at org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:523)
at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:438)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:686)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:49)
Re: Handling Iterators in JXTG
On Wed, Apr 21, 2004 at 02:36:31PM -0700, Christopher Oliver wrote: Ive just committed a fix for this. Lovely, thank you. lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
[BUG] Serializers produce broken document type declaration
At least with the HTMLSerializer (i have not checked the others). The document type declaration is emitted with no space between the PublicIdentifier and the SystemIdentifier. Not sure when this behaviour started happening, but it is now with current 2.1 HEAD. I am seeing this with http://localhost:/samples/hello-world/hello.html --David
Re: Allowing redirects in handle-errors
On 20.04.2004, at 18:28, peter royal wrote: On Apr 20, 2004, at 12:22 PM, Tony Collen wrote: If a URL with an invalid continuation ID is invoked, I would like to take the user to the start of the process rather than displaying an error page. AFAIK, this needs a redirect-to in the handle-errors block. I can think of several ways of working around this block, but I was curious as to what others do in this situation, and if might warrant a revote on the change :) -pete Hmm. Could generate a page that has a manual redirect, e.g.: meta http-equiv=refresh content=0;url:http://foo/ ? yea, that's one of the ways of working around it, but seems hacky :) i could also create a custom Action since that gets a handle to a Redirector. -pete and what about calling a function map:when test=invalid-continuation map:call function=restart ... /map:call /map:when or a saved continuation ? /leo
