Re: Continue Development of 2.1.x
Il giorno 17/apr/04, alle 20:24, Ralph Goers ha scritto: Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Thanks Ralph. You have expressed exaclty what is also my opinion on the issue. Ugo
Re: flowscript bizData AOP
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
So you can set a Flowscript function as an attribute of a Session?
Well, I suppose it makes sense, since in the end it's just an Object,
but it would have never occurred to me.
Since both Flow script (cocoon.load()) and JXTemplateGenerator
(jx:import/) support including other files you can factor such code
into supporting library files and include them in your application
code.
That's true, but I suspect it's going to quickly become a FAQ unless we
do something to support it out-of-the-box. The number one FAQ related
to XSP is already How do I insert an XML fragment taken from whatever
source inside my output without having special characters escaped? or
a similar one.
Ugo
Re: Continue Development of 2.1.x
On 18.04.2004 10:14, Ugo Cei wrote: Il giorno 17/apr/04, alle 20:24, Ralph Goers ha scritto: Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Thanks Ralph. You have expressed exaclty what is also my opinion on the issue. Same here. Joerg
Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
On 17.04.2004 12:38, Nicola Ken Barozzi wrote: In any case, what I see is that Cocoon has gotten many contracts wrong. In particular it has been coded using generic Cocoonish exceptions that were meant to gobble up the source exceptions from the start. In fact we can say that what seems now as an error was deemed in the beginning as a feature, that was probably done to achieve that RuntimeExceptions do rather than to have what we have now. I would like to note BTW that my -1 is a vote, not a veto. It is based on the fact that I don't believe that using RuntimeExceptions will bring us that cleaness we need without unwanted consequences, but this is just MHO and I may well again be wrong, as it happens :-) Same here. The change to RuntimeExceptions only circumvents the inherent problem of Cocoon. Joerg
RE: Continue Development of 2.1.x
Ralph Goers dijo: It is highly unlikely that the project I am working on will use 2.2 as we have to be in production early next year and a significant amount of work has already been done. I am very much in favor of continuing to add new features to 2.1 (such as the patch I just submitted), especially when they are completely binary compatible. I believe 2.1 has a long life ahead of it. Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Same here. A question (just trying to understand): that means we can also drop the support for old avalon components in 3.0. Is this correct? Best Regards, Antonio Gallardo
RE: Continue Development of 2.1.x
Antoni Gallardo wrote: Ralph Goers dijo: It is highly unlikely that the project I am working on will use 2.2 as we have to be in production early next year and a significant amount of work has already been done. I am very much in favor of continuing to add new features to 2.1 (such as the patch I just submitted), especially when they are completely binary compatible. I believe 2.1 has a long life ahead of it. Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Same here. A question (just trying to understand): that means we can also drop the support for old avalon components in 3.0. Is this correct? We *could* do this, but I hope we will not :) Given the discussions about blocks here and the recent discussions over at Avalon I could imagine that we don't have to drop the support. But I think, we should simply try to support them and if it's not possible, well for a 3.0 we could drop it. Carsten
Re: [POLL] don't edit files just for style changes?
Antonio Gallardo agallardo at agssa.net writes: For an example see http://thread.gmane.org/gmane.text.xml.cocoon.cvs/11901. A replacement of hand-written code with commons lang code got completely lost in a huge list of style changes. I really don't understand things now. First was told me: Please don't commit in small chunks. Who said that? Now looks like it was ok. I will committ step by step if any. It's just separation of concerns: one commit per concern :) OK. I got the message. Please don't feel personally attacked. It was just a sample. Unfortunately I can not point to an annonymous commit. Somebody is always culprit ;-) Joerg
Re: Continue Development of 2.1.x
On 18.04.2004 11:21, Carsten Ziegeler wrote: A question (just trying to understand): that means we can also drop the support for old avalon components in 3.0. Is this correct? We *could* do this, but I hope we will not :) Given the discussions about blocks here and the recent discussions over at Avalon I could imagine that we don't have to drop the support. But I think, we should simply try to support them and if it's not possible, well for a 3.0 we could drop it. +1 Joerg
RE: Continue Development of 2.1.x
Ralph Goers wrote: It is highly unlikely that the project I am working on will use 2.2 as we have to be in production early next year and a significant amount of work has already been done. I am very much in favor of continuing to add new features to 2.1 (such as the patch I just submitted), especially when they are completely binary compatible. I believe 2.1 has a long life ahead of it. Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. Yes, this is true for blocks. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Yes, and we would have to need some restructuring of the cvs as it wouldn't make much sense to have our current blocks in the 2.1 repository while having 2.1, 2.2 and 3.0 repositories. Ah, and we still have of course the 2.0 one :) Now, I totally understand the binary compatibility reason, but if this is the only reason for having three repos (2.1, 2.2 and 3.0), than I'm against it. We don't have binary releases, so if you update to a new Cocoon version, you have to compile at least Cocoon anyway. In addition, you can never really be sure, that two 2.1.x versions are really binary compatible. We have too many dependencies to other projects that might have changed and sometimes we change something in an incompatible way without realizing it (this is very rarely but it happens). So, at least recompiling your own java code is imho strongly suggested (and you can use a never java compiler etc.) As I said, the incompatibilities I mentioned is a) only in the Java source code, nothing else is affected, and even these changes are internal ones, so noone should suffer from them. And of course, we document the incompatible changes clearly, so even if you are affected, you will know what you have to change. So in the end, I really would only have one repository for 2.1.x and one for the new blocks system (which is the current 2.2). WDYT? Carsten
RE: Continue Development of 2.1.x
Carsten Ziegeler dijo: Antoni Gallardo wrote: Ralph Goers dijo: It is highly unlikely that the project I am working on will use 2.2 as we have to be in production early next year and a significant amount of work has already been done. I am very much in favor of continuing to add new features to 2.1 (such as the patch I just submitted), especially when they are completely binary compatible. I believe 2.1 has a long life ahead of it. Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Same here. A question (just trying to understand): that means we can also drop the support for old avalon components in 3.0. Is this correct? We *could* do this, but I hope we will not :) Given the discussions about blocks here and the recent discussions over at Avalon I could imagine that we don't have to drop the support. But I think, we should simply try to support them and if it's not possible, well for a 3.0 we could drop it. Thanks for the answer. It is fair to me. Note, we don't use customized components at all. We try to use what is in Cocoon. No matter how dificult it is some times. We have bad experiences about customized code that don't work later because the rules changed. And refactoring start and... try to keep on... it is a well know story. Since I understand that. I will stand on the side of people trying to have the Avalon support as long as is posible. So, here is my vote to your answer: +1 Best Regards, Antonio Gallardo
Re: cvs commit: cocoon-2.1/src/blocks/forms/samples/messages FormsMessages_de.xml
- message key=datatype.conversion-failedKeine gültige {0}./message
+ message key=datatype.conversion-failedUnültige(s) {0}./message
Unültige ?!
Stephan.
Bug report for Cocoon 2 [2004/04/18]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 5978|Ass|Nor|2002-01-23|Java SecurityManager java.lang.RuntimePermission c|
| 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing |
| 9916|New|Enh|2002-06-17|javax.xml.transform.Transformer accepts object par|
|10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu|
|10827|New|Nor|2002-07-15|ESQL get-xml/ doesn't support namespaces|
|11716|New|Nor|2002-08-15|util:include-expr is formatting sensitive |
|13479|New|Maj|2002-10-10|Cocoon fails to compile sitemap and XSP in JBoss 3|
|15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu|
|15316|Opn|Nor|2002-12-12|FOP does not resolve relative paths |
|15614|Opn|Min|2002-12-22|Some documentation is inaccurate by version |
|16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 |
|16545|New|Min|2003-01-29|Logicsheet embedded in used-defined logicsheet doe|
|17594|New|Nor|2003-03-03|WebSphere redirect bug|
|17771|New|Nor|2003-03-07|[PATCH] new logging category never set when using |
|17924|New|Nor|2003-03-12|Cached resources don't have Expires-Header|
|17984|New|Enh|2003-03-14|SQLTransformer only handles nested or sequential q|
|19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable |
|19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane |
|20190|New|Maj|2003-05-23|JSPs in external subsite fail |
|20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer |
|20631|New|Enh|2003-06-10|[PATCH] Support for transactions in SQLTransformer|
|21107|New|Maj|2003-06-26|possible sitemap reload locking issue |
|21177|New|Nor|2003-06-30|a crash in the name() function of the xslt, when u|
|21301|New|Maj|2003-07-03|esql:get-xml error: Could not find Component (role|
|21536|Opn|Enh|2003-07-12|[PATCH] 2 new generators: MultiPartPosted XML and |
|22132|New|Nor|2003-08-05|Cannot use redirect-to after submit jxform|
|22842|New|Nor|2003-08-30|flow: importPackage/importClass problems creating |
|23002|New|Nor|2003-09-08|HSSF Serializer does not process gmr:PrintInforma|
|23118|New|Nor|2003-09-11|SearchGenerator incorrectly counts previous-index |
|23283|Unc|Nor|2003-09-19|WebServiceProxy doesn't re-encode request paramete|
|23328|New|Nor|2003-09-22|XSP ESQL logicsheet example fails if Oracle 8i dat|
|23481|New|Nor|2003-09-29|HSSFSerializer: ambigious style definition leads t|
|23542|Opn|Maj|2003-10-01|[PATCH] Fix Bug: Better handling of CLOB in esql (|
|23585|New|Nor|2003-10-03|Localton of ev_cache.ser file in DefaultEventRegis|
|23615|Opn|Nor|2003-10-06|XSLTC doesn't work with nodeset functions |
|23796|New|Nor|2003-10-14|[PATCH] docs pages containing source are sometim|
|23901|New|Nor|2003-10-17|[PATCH] adding wd:on-phase and moving load() and|
|23921|New|Enh|2003-10-19|[PATCH] New ReadDOMTransformer/WriteDOMTransformer|
|23939|New|Nor|2003-10-20|document('relative-URI') seems to resolve wrongly |
|24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values|
|24180|New|Enh|2003-10-28|Test the presence of all required fields in the te|
|24289|New|Nor|2003-10-31|MultipartParser cannot handle multibyte character |
|24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction|
|24390|New|Enh|2003-11-04|[PATCH] New StaticStringModule|
|24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers|
|24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer |
|24433|New|Nor|2003-11-05|JXTemplate generator does not handle format-number|
|24498|New|Nor|2003-11-07|Need to be able to use cinclude or xinclude to|
|24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows|
|24647|New|Nor|2003-11-12|content-length in ResourceReader |
|24741|New|Nor|2003-11-17|util:get-sitemap-parameter/ returns nothing when|
Re: #{//foo/bar} doesn't work within forEach!
Could it be that you are using both Jexl and XPath tags?
Stephan Coboos wrote:
Hello,
I've tried to retrieve an object within a JXTemplate:
#{//foo/bar}
This works fine outside any forEach. If I'am using it inner forEach,
nothing will be printed out:
jx:forEach var=something items=${myList}
#{//foo/bar}
/jx:forEach
Because // refers to the root, the value should be printed out within
this context, right? Whats wrong?
Thank you.
Regards
Stephan
RE: Continue Development of 2.1.x
In my opinion, when you go from one major release to the next you are free to completely rewrite the product if you choose. However, providing backward compatibility is always beneficial to your client base. Look at how long MS supported old DOS programs in Windows. At some point it isn't cost effective, but you do it as long as you can to keep your clients happy. Ralph -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Sunday, April 18, 2004 2:04 AM To: [EMAIL PROTECTED] Subject: RE: Continue Development of 2.1.x Same here. A question (just trying to understand): that means we can also drop the support for old avalon components in 3.0. Is this correct? Best Regards, Antonio Gallardo
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: ... I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap. I do understand this is radical and i'm open for constructive criticism, but please come up with examples to show me why you really need inputmodules. Look in Forrest, and especially at the locationmap module that has to be introduced in the next version. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Guido Casper wrote: Why do flow people constantly fall back using Java classes? In my case, I tried to avoid it as the plague. Sorry, hit the wrong key and sent the email ;-) Let me continue. Do they put to much into the flow layer? The expectations for the flow layer seem to be so various. I fear that this fact does more harm than good to Cocoon. Hm, I don't even have a definition of flow layer. Why is there no library of flow components readily available? I don't know but I suspect it's harder to build reusable flow components than it is to build reusable sitemap components (the level of component reusability of the sitemap is unparalleled). At the same time it is too easy to just get my stuff finished with flow. Which is exactly what makes flow currently so powerful and what may count in many cases. However this particular advantage may be just temporary. I think that if we come up with with reusable FOM components, we have failed. on the other hand, I think there are reusable FOM aspects that might be reusable, but let's not go there now. sitemap is declarative glue while flow is procedural glue. if there is too much spaghetti code in between them, there is something wrong and we have to fix that. I believe that inputmodules/outputmodules do already pose a significant complexity to the clean separation. I think input modules *are*not* necessary once you have a clearly defined way for flow to pass parameters to the sitemap. You might be right here but don't forget that it is not always web _applications_ why our users take Cocoon. It is very often simple _publishing_. Input modules make it *very* easy for them to e.g. read out a request parameter without having to go the detour of using flowscript. -- Reinhard
Re: Continue Development of 2.1.x
Carsten Ziegeler wrote: Ralph Goers wrote: It is highly unlikely that the project I am working on will use 2.2 as we have to be in production early next year and a significant amount of work has already been done. I am very much in favor of continuing to add new features to 2.1 (such as the patch I just submitted), especially when they are completely binary compatible. I believe 2.1 has a long life ahead of it. Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible changes go into a new 2.2. It is my impression that what is now in 2.2 is going to end up being quite different from 2.1 and that it should not just be a point release. Yes, this is true for blocks. This would allow me to migrate to stay on 2.1 and maintain binary compatibility, move to 2.2 at the risk of minor incompatibilities, or move up to 3.0 where major differences happen. I realize there is a risk with this, as nobody really likes to maintain two releases at one time, so 2.1 is likely to stagnate. Yes, and we would have to need some restructuring of the cvs as it wouldn't make much sense to have our current blocks in the 2.1 repository while having 2.1, 2.2 and 3.0 repositories. Ah, and we still have of course the 2.0 one :) Now, I totally understand the binary compatibility reason, but if this is the only reason for having three repos (2.1, 2.2 and 3.0), than I'm against it. +1 We don't have binary releases, so if you update to a new Cocoon version, you have to compile at least Cocoon anyway. In addition, you can never really be sure, that two 2.1.x versions are really binary compatible. We have too many dependencies to other projects that might have changed and sometimes we change something in an incompatible way without realizing it (this is very rarely but it happens). So, at least recompiling your own java code is imho strongly suggested (and you can use a never java compiler etc.) I think so too. If I upgrade Cocoon I *always* recompile my own Java classes. So I have never had any problem. As I said, the incompatibilities I mentioned is a) only in the Java source code, nothing else is affected, and even these changes are internal ones, so noone should suffer from them. And of course, we document the incompatible changes clearly, so even if you are affected, you will know what you have to change. So in the end, I really would only have one repository for 2.1.x and one for the new blocks system (which is the current 2.2). +1 I think we should keep the blocks in the 2.1 repository because if we follow Ralph's proposal we would end in a separate blocks repository. And as soon as the _new_ blocks infrastructure is set up we will have to create another blocks repository and we end in 6 repositories: - 2.0 - 2.1 - 2.2 - 2.x blocks - 3.0 - 3.x blocks In order to keep it as simple as possible I'm -1 on this and +1 on Carsten's proposal. -- Reinhard
RE: Continue Development of 2.1.x
Ralph Goers wrote: 1. I don't understand why you need separate repositories. Why are CVS branches not good enough? Yes, we discussed this some time ago and there were many reasons that a new repository is better and that it makes migration to subversion easier (at least I think this was one reason, I might be wrong). Anyways, from the maintenance POV, it's not really different if you have to maintain three branches or three repositories without branches. On an unrelated topic, I would suggest looking at subversion. I had to use if to grab something from the incubator and its pretty cool. Plus it easily went through my companies firewall as it is http based. Yes, and some ASF projects have already moved/are moving to subversion. Sooner or later all projects will move; but even if we would use subversion I think there is no difference as you still have to maintain the three different versions. If anyone wants to discuss the use of subversion for Cocoon, please don't do it in this thread and start a new one (This is not targetted at you, Ralph.) 2. Yes, we have to compile now. But that doesn't eliminate the binary compatibility issues, it just reduces them. In fact, I was using the APIs you want to eliminate up until a few months ago when you posted the proper way to get what I wanted. The bottom line here is that once an API is public you cannot know that it isn't being called by a user, unless it has requirements that just can't be met in a user component (whatever that is). Yes, unfortunately this is true. Now, we try to document that a user is using not supported API in the Java code, so it's the risk of the user to use it :) But as always, it might not be documented very well in all places. 3. The issues you raise regarding not being able to maintain binary compatibility are one of my greatest concerns with using Cocoon and open source in general. Oh, this is not only a concern of Cocoon or Open Source in general. If you are using commercial frameworks, they sometimes change even due to a bug fix and No, I'm not refering to MS here, this happened even with Apple (or more precisly with Next). Once a formal release is made the project should be rather draconian in its view of dependencies - they shouldn't be updated unless they ONLY contain bug fixes. IMO product stability should be the number one goal of point releases (i.e. 2.1.x), and it should improve with each one. Yes, I absolutely agree here in general...but :) I think it's ok to change the private API and in rare cases it's ok to change public API that does only affect very few users if any. But the later one of course only if it's well documented and there is a new way of doing the old things. However, I am not a Cocoon committer, so it really isn't up to me to say how the respository is organized. But you belong to the Cocoon community and we really value everyone's opinion. It doesn't mean that a committer is always right. So, please keep on posting your comments and suggestions. Really appreciated. But as a user of Cocoon I care greatly about how I am going to be able to maintain it after my system goes live. I'd prefer not to have to freeze it at a particular point release and perform hand patches after that. Yes, I totally understand that and as I said, in general I agree but the changes I mentioned should really be harmless. Remember, that most of us committers are users, too. E.g. we (sn, my employer :) ) are using Cocoon in many projects ranging from small to very big installations and we don't want to change our applications just because we are upgrading from let's say 2.1.4 to 2.1.5. So, in the end, I think, yes, all 2.1.x versions should in general be compatible but there should be (as always) exceptions to this rule. Carsten
RE: Continue Development of 2.1.x
Don't worry. It takes a lot to shut me up. :) I think we in general agreement. Ralph -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Sunday, April 18, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: RE: Continue Development of 2.1.x However, I am not a Cocoon committer, so it really isn't up to me to say how the respository is organized. But you belong to the Cocoon community and we really value everyone's opinion. It doesn't mean that a committer is always right. So, please keep on posting your comments and suggestions. Really appreciated. But as a user of Cocoon I care greatly about how I am going to be able to maintain it after my system goes live. I'd prefer not to have to freeze it at a particular point release and perform hand patches after that. Yes, I totally understand that and as I said, in general I agree but the changes I mentioned should really be harmless. Remember, that most of us committers are users, too. E.g. we (sn, my employer :) ) are using Cocoon in many projects ranging from small to very big installations and we don't want to change our applications just because we are upgrading from let's say 2.1.4 to 2.1.5. So, in the end, I think, yes, all 2.1.x versions should in general be compatible but there should be (as always) exceptions to this rule. Carsten
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: I don't even have a real proposal. But I'm thinking about restricting flow to FOM and flow-intended components (or their flow-intended interface like with CForms). Another part may be some guidelines on how to create (which should be simple of course :-) and use such components. Just exposing Avalon or whatever components to flow doesn't seem to be a big (the right) step forward (and part of this wrong step seems to be cocoon.getComponent/releaseComponent) as this implicitely tells the user: yes, flowscript and Java components share the same API. Completely disabling the use of arbitrary Java classes from flowscript doesn't seem doable either (it _is_ a useful thing for the developer) or even desirable. What may be a good idea IMO (and please tell me if I'm talking bullshit) is to let flow-intended components implement a Scriptable interface (which should always be high level and easy to be used by users) and provide some kind of doclet mechanism that generates the docs for our official flowscript API. I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't eager to write reusable components. But currently it's just that hard to come up with components really making the user's life easier. The problem I have with cocoon.getComponent() is the user's side of the fence. getComponent() doesn't say anything about the granularity of a component as Avalon allows for (and encourages) components of any granularity. Avalon has been there before flow and is intended to make the Java developer's life easier not the flow user's. The services for flow users should be coarse grained and high level. And I believe that the user shouldn't have to deal with technical details like component lifecycle (and having to call releaseComponent()). Please note that I don't want to discuss the pro/vs. release(). I really don't care wether the developer has to call release (at least right now :-). I for sure don't want to increase overall complexity. But if I could trade reduced user complexity for increased developer complexity I would do. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? the JSR 170 is a complex beast. I would wrap it with a Repository avalon component, make the interface really simple and pass this to the scripting layer, hiding all the complexity inside. Exactly. I'm just thinking about a better way than an Avalon component (and thought it might be the right time to speak up now that we are designing a new container). That's how I would do it. And yes, I still believe in the pyramid of contracts, even more than in the past, but the sitemap is not enough, we need something else, we can't write script in XML. Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space. I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user. Guido -- Guido Casper - SN AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
RE: Documentation TOC started
I mean that our core documentation, i.e. the xdocs and the key Wiki pages, should be be written by this community and should be the definitive view on the topic. Aha, that's a clear point. Especially the latter. I currently have a feeling that definitive views on several topics are changing (e.g. flow vs actions, jx vs xsp), it would be nice to get certain things down in writing to make it easier to decide on which learning curve to take. In general we should not make links to outside documentation because we have absolutely no control over what they say about Cocoon. They might have some good statements then a heap of misguided statements. We would be leading the users astray because our core documentation would appear to recommend that document as some authority. True, on the other hand I think that a good product can defend itself and linking to the enemy might just as well be an indication of that. Sure, this shouldn't be included in the core documents, but a Wiki page with such links (e.g. the TSS article lately AS WELL AS the discussions about it, both here and on the TSS article reviews) might prove to be just enough to newbies to decide to start with Cocoon or to drop it before getting into it. Besides that, constantly changing URLs and dead links are too hard to manage over time. Right, although I find that less irritating in a Wiki page than in the xdocs. I was thinking along this line: - references to external URLs that explain add-ins for Cocoon, e.g. the flowscript debugger, the Sunbow plugins for Eclipse etc. - references to blog entries which explain some otherwise hard to find info. - references to mail archives. - references to articles on Cocoon (e.g. the TSS article lately) - anything else I've forgotten The latter 2 are stuff for the Wiki page. For the first 3 I'm thinking of getting in touch with the original authors and ask permission to include/rewrite the information and include it in the Cocoon xdoc itself. When components are involved, links are included to the authors pages for more info and downloads. It is the external links that can lead to problems. Yes, but how to include information on e.g. the sunbow plugins for Eclipse? Either the you include the entire text in the xdocs (with the authors' permission of course), but are still left with links to the actual code, or you need to refer to Wiki pages (which are currently changing URL :-) ) which contain such information. Sure. You are preaching to the converted on cocoon-dev :-) Sorry, I'm used to the male technical geeks that write better code than their native language. And usually consider code enough documentation anyway. ;-) Bye, Helma
Re: flowscript bizData AOP
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
So you can set a Flowscript function as an attribute of a Session?
Well, I suppose it makes sense, since in the end it's just an Object,
but it would have never occurred to me.
Since both Flow script (cocoon.load()) and JXTemplateGenerator
(jx:import/) support including other files you can factor such
code into supporting library files and include them in your
application code.
That's true, but I suspect it's going to quickly become a FAQ unless
we do something to support it out-of-the-box. The number one FAQ
related to XSP is already How do I insert an XML fragment taken from
whatever source inside my output without having special characters
escaped? or a similar one.
Ugo
I see your point. So +1 to adding built-in support for string-SAX to
JXTG (should also support streaming byte[], char[], InputStream, and
Reader?).
The above approach has a serious drawback anyway - namely, that it won't
work for sub-sitemaps. They share the same session and would overwrite
each other's session attributes. As I understand it currently each
sitemap has its own Flow interpreter with its own independent JS global
scope. It's currently not safe to share JS objects between them because
thread synchronization occurs on those global scopes, and all JS objects
created within a flow interpreter are linked to the global scope object.
I still don't think the flowscript global scope should be exposed
directly to the view as that prevents the flowscript from having private
data shared between top level functions independent of the view. But I
think Leszek's point is valid - you might want to create variables that
remain accessible to the view between different invocations of sendPage*().
Maybe what is needed is an additional variable scope that is
accessible to the view and into which the flowscript can store data
which persists between invocations of sendPage*(). This scope would be
read-only from the POV of the view. I'm not sure what to call this scope:
- cocoon.request
- cocoon.session
- cocoon.context
- cocoon.currentFlow (or cocoon.sitemapScope, or )
Otherwise, another approach would be to create exactly one flow
interpreter per session and synchronize access to it based on the
session. This would result in all sitemaps sharing the same JS global
scope as well as session attributes. The drawback of this approach is
that functions and variables defined in flowscripts under different
sitemaps would collide with each other.
WDOT?
Chris
Re: [cforms] Weird behaviour of flow and fb:javascript binding
Christopher Oliver wrote:
I can't say that I fully understand your problem, but I just looked at
o.a.c.f.util.JavascriptHelper, and that appears to have some major
bugs. If it isn't called from a flow script it uses a static
JavaScript object as the top level scope (where JS global variables
are created), but does not even synchronize access to it. That means
any global variables you set in one of your Javascript snippets
(intentionally or accidentally) will be visible to all users and you
will see undefined behavior if multiple threads read and write the
same variables.
Learning the internals of Rhino and how this scope and context machinery
works is not an easy task :-/
So the solution is to create a new scope for each call, right? Also,
instead of creating an intermediate scope to hold snippet-specific data,
I was think of using functions where this intermediate scope would be
function parameters. That way global variables in the snippet actually
are local variables of the function.
If it is called indirectly from a flow script (i.e. from sendPage*())
you share global variables with the flow script (that's why you could
access the cocoon object in some cases but not others). But this is
also bad because it makes bugs related to accidentally overwriting
global variables very hard to find.
I consider this the availability of the cocoon object and global
flowscript variables an essential feature, as form event listeners are
an integral part of the controller.
However, as a hack for the time being, you could probably set the
request attribute it uses to obtain the flow script global scope
yourself before calling the binding.
As regards evaluating JavaScript snippets in form definition and
binding files, I don't think the flowscript global scope should used.
Rather, a special scope should be created (- and unique per thread) in
which to evaluate those snippets. The binding framework and form
framework can make available appropriate Cocoon system objects in this
scope if that is required (such as an object that allows you to get an
avalon component).
Mmmh... how would this cocoon object be different from the one in
flowscript?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: #{//foo/bar} doesn't work within forEach!
No. That won't work. With the current implementation of JXTG XPath
evaluation of absolute paths with a forEach only works if the
expression passed to forEach is an XPath expression. Does this work:
jx:forEach var=something items=#{myList}
#{//foo/bar}
/jx:forEach
Chris
Stephan Coboos wrote:
Hello,
I've tried to retrieve an object within a JXTemplate:
#{//foo/bar}
This works fine outside any forEach. If I'am using it inner forEach,
nothing will be printed out:
jx:forEach var=something items=${myList}
#{//foo/bar}
/jx:forEach
Because // refers to the root, the value should be printed out within
this context, right? Whats wrong?
Thank you.
Regards
Stephan
Jexl and JXPath give different results! -- reposted!
I do hope someone can look at this and tell me where I'm wrong.
Bye, Helma
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 23:31
To: [EMAIL PROTECTED]
Subject: Jexl and JXPath give different results!
Hi,
I've been fiddling around with retrieving info from a custom built object.
For clarity I'll explain the object here:
Class Person {
private Hashtable cocoonTraits;
private String ID;
public String getID() { return ID; }
public Map getTraits() { return cocoonTraits; }
}
Class CocoonTrait {
private Hashtable cocoonTraits;
private Hashtable cocoonValues;
private String name;
public String getName() { return name; }
public Map getTraits() { return cocoonTraits; }
public Map getValues() { return cocoonValues; }
}
Class CocoonValue {
private String name;
private Object value;
public String getName() { return name; }
public Object getValue() { return value; }
}
I've instantiated the above and added some values to the CocoonValue
objects. Then I want to display them:
jx:template xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
html
headtitleA person/title/head
body
pA person = ${person.ID} /p
table border=1
jx:forEach var=trait select=${person.traits}
trtd colspan=2Trait = ${trait.name}/td/tr
jx:forEach var=value select=${trait.values}
tr
td${value.name}/tdtd${value.value}/td
/tr
/jx:forEach
/jx:forEach
/table
table border=1
jx:forEach select=#{person/traits}
tr
td colspan=2#{./name}/td
/tr
jx:forEach select=#{values}
tr
td#{./name}/tdtd#{./value}/td
/tr
/jx:forEach
/jx:forEach
/table
/body
/html
/jx:template
The first table correctly shows all Trait names and all Value names and the
values of those that are filled in.
The second table only shows:
table border=1
tr
td colspan=2[EMAIL PROTECTED]/td
/tr
/table
So either I've done something wrong in the syntax (which I cannot conclude
from the docs}, or there is something really wrong.
Bye, Helma
Re: [cforms] Weird behaviour of flow and fb:javascript binding
Sylvain Wallez wrote: Christopher Oliver wrote: I can't say that I fully understand your problem, but I just looked at o.a.c.f.util.JavascriptHelper, and that appears to have some major bugs. If it isn't called from a flow script it uses a static JavaScript object as the top level scope (where JS global variables are created), but does not even synchronize access to it. That means any global variables you set in one of your Javascript snippets (intentionally or accidentally) will be visible to all users and you will see undefined behavior if multiple threads read and write the same variables. Learning the internals of Rhino and how this scope and context machinery works is not an easy task :-/ See http://www.mozilla.org/rhino/scopes.html. So the solution is to create a new scope for each call, right? Also, instead of creating an intermediate scope to hold snippet-specific data, I was think of using functions where this intermediate scope would be function parameters. That way global variables in the snippet actually are local variables of the function. If it is called indirectly from a flow script (i.e. from sendPage*()) you share global variables with the flow script (that's why you could access the cocoon object in some cases but not others). But this is also bad because it makes bugs related to accidentally overwriting global variables very hard to find. I consider this the availability of the cocoon object and global flowscript variables an essential feature, as form event listeners are an integral part of the controller. See below. However, as a hack for the time being, you could probably set the request attribute it uses to obtain the flow script global scope yourself before calling the binding. As regards evaluating JavaScript snippets in form definition and binding files, I don't think the flowscript global scope should used. Rather, a special scope should be created (- and unique per thread) in which to evaluate those snippets. The binding framework and form framework can make available appropriate Cocoon system objects in this scope if that is required (such as an object that allows you to get an avalon component). Mmmh... how would this cocoon object be different from the one in flowscript? Depends on the requirements of the Form and Binding frameworks (in other words a design is needed). But, for example, I think we can all agree it should not have a sendPageAndWait() function. Chris
Cocoondev.org offline?
Does someone know what's wrong? I get a timeout on cocoondev.org (blogs, wiki etc.). Bye, Helma
Re: Cocoondev.org offline?
[EMAIL PROTECTED] wrote: Does someone know what's wrong? I get a timeout on cocoondev.org (blogs, wiki etc.). AOIndustries, which hosts the Wiki, has had a power outage. They are in the process of repowering all of the machines as we speak (I've just talked to them on the 'phone about my own servers). Regards, Upayavira
RE: Cocoondev.org offline?
Thanks. Helma -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Sunday, 18 April 2004 21:42 To: [EMAIL PROTECTED] Subject: Re: Cocoondev.org offline? [EMAIL PROTECTED] wrote: Does someone know what's wrong? I get a timeout on cocoondev.org (blogs, wiki etc.). AOIndustries, which hosts the Wiki, has had a power outage. They are in the process of repowering all of the machines as we speak (I've just talked to them on the 'phone about my own servers). Regards, Upayavira
Re: flowscript bizData AOP
Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto: The above approach has a serious drawback anyway - namely, that it won't work for sub-sitemaps. They share the same session and would overwrite each other's session attributes. Do you really need to use the session? Can't you store the toSAX function as a request attribute or as a bizData object? Ugo
Re: flowscript bizData AOP
On Sun, Apr 18, 2004 at 10:41:10PM +0200, Ugo Cei wrote: Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto: The above approach has a serious drawback anyway - namely, that it won't work for sub-sitemaps. They share the same session and would overwrite each other's session attributes. Do you really need to use the session? Can't you store the toSAX function as a request attribute or as a bizData object? The thing is you want to set it ONCE. Just as you have a User object filled up during login and then you would like to have it available for all views without explicit declaring (For example you insert Hello, user! on every page). request attribute or bizData is fine for one request only. lg -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
Re: Continue Development of 2.1.x
Carsten Ziegeler wrote: The development of blocks for 2.2 has started, but as others have already pointed out, it might take time to get it implemented and running well. So, I would suggest that we change our development plan a little bit and consider adding those features to our 2.1.x code base that are independent from blocks, like e.g. the virtual sitemap components etc. Of course we should take care that the changes are not incompatible (apart from the one below :) ). +1. Please consider also sitemap logging as discussed in previous threads (map:log): I really feel a need for that, especially now, given the sometimes hard to debug roundtrips between sitemap and flow... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
IOUtils testcase failing
Our latest CVS head has (at least) one failing testcase:
Testcase: testNormalizedFilename took 0,158 sec
Caused an ERROR
0
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.cocoon.util.IOUtils.normalizedFilename(IOUtils.java:203)
at
org.apache.cocoon.util.test.IOUtilsTestCase.testNormalizedFilename(IOUti
lsTestCase.java:80)
I gave a look at the IOUtils and IOUtilsTestCase classes and it looks
like they haven't changed in quite some time, so the problem lies
somewhere else.
public static String normalizedFilename(String filename) {
if(File.separatorChar == '\\')
filename = filename.replace('/','\\');
else
filename = filename.replace('\\','/');
String[] path = StringUtils.split(filename, File.separator);
int start = (path[0].length() == 0) ? 1 : 0;
The last line is line 203 and the error happens when the method is
invoked with an empty string as its argument. According to the API
docs, the StringUtils.split function returns an empty array when
invoked with an empty string argument. Thus, referencing path[0] causes
an AIOOB exception. So, the problem is clear, and the fix should be
easy.
What I'd like to know is: when did this test start failing? Probably
after an upgrade to commons-lang, it seems. Then, why do we never
bother to run our (very limited) test suite before committing a patch?
Ugo
Re: flowscript bizData AOP
Christopher Oliver dijo:
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
Yep. We share flow script modules for common code. ie:
auth.js and utils and jx:macros. And this works. For example in session we
save the user name, and other session related stuff and we can access it
in any flow accross subsitemaps without problem. As a rule we avoid the
use of global variables in flow script. Here is the code that retrieves
the user name from session:
function auth_getUserID() {
var handler = authhandler;
var authMgr;
var result = null;
try {
authMgr =
cocoon.getComponent(Packages.org.apache.cocoon.webapps.authentication.AuthenticationManager.ROLE);
// autentificación
if (authMgr.checkAuthentication(null, handler, null)) {
// Usuario autenticado, tomamos el userID
result = parseInt(authMgr.getState().getHandler().getUserId());
}
} finally {
cocoon.releaseComponent(authMgr);
}
return result;
}
So you can set a Flowscript function as an attribute of a Session?
Well, I suppose it makes sense, since in the end it's just an Object,
but it would have never occurred to me.
Since both Flow script (cocoon.load()) and JXTemplateGenerator
(jx:import/) support including other files you can factor such
code into supporting library files and include them in your
application code.
Yep. I think this is the idea.
That's true, but I suspect it's going to quickly become a FAQ unless
we do something to support it out-of-the-box. The number one FAQ
related to XSP is already How do I insert an XML fragment taken from
whatever source inside my output without having special characters
escaped? or a similar one.
Ugo
I see your point. So +1 to adding built-in support for string-SAX to
JXTG (should also support streaming byte[], char[], InputStream, and
Reader?).
Not sure. AFAIK the JXTG already make SAX events, right? We only need to
care in the parsed file that is conforms an XML doc.
The above approach has a serious drawback anyway - namely, that it won't
work for sub-sitemaps. They share the same session and would overwrite
each other's session attributes. As I understand it currently each
sitemap has its own Flow interpreter with its own independent JS global
scope. It's currently not safe to share JS objects between them because
thread synchronization occurs on those global scopes, and all JS objects
created within a flow interpreter are linked to the global scope object.
I still don't think the flowscript global scope should be exposed
directly to the view as that prevents the flowscript from having private
data shared between top level functions independent of the view. But I
think Leszek's point is valid - you might want to create variables that
remain accessible to the view between different invocations of
sendPage*().
Well, for this purpose there is already cocoon.session.
Maybe what is needed is an additional variable scope that is
accessible to the view and into which the flowscript can store data
which persists between invocations of sendPage*(). This scope would be
read-only from the POV of the view. I'm not sure what to call this scope:
- cocoon.request
- cocoon.session
- cocoon.context
- cocoon.currentFlow (or cocoon.sitemapScope, or )
Otherwise, another approach would be to create exactly one flow
interpreter per session and synchronize access to it based on the
session. This would result in all sitemaps sharing the same JS global
scope as well as session attributes. The drawback of this approach is
that functions and variables defined in flowscripts under different
sitemaps would collide with each other.
Yep. :-( And this is serious problem). In particular, we are sharing
function names in subsitemap. ie:
Each subsitemap have function names:
create(), save(), delete(), etc.
As you posted above, the isolation of each subsitemap is good to avoid
confusions and other advantages. If not, will be find to share code
between developers, because we will need to know what others are using as
names to avoid conflicts. Personally, I think it is bad. I would recommend
Leszek to use session variables instead of a change of this kind.
I understand the problem of lack of documentation in Flow, but a good doc
is always a good helper.
Best Regards,
Antonio Gallardo.
Re: flowscript bizData AOP
Leszek Gawron dijo: On Sun, Apr 18, 2004 at 10:41:10PM +0200, Ugo Cei wrote: Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto: The above approach has a serious drawback anyway - namely, that it won't work for sub-sitemaps. They share the same session and would overwrite each other's session attributes. Do you really need to use the session? Can't you store the toSAX function as a request attribute or as a bizData object? The thing is you want to set it ONCE. Just as you have a User object filled up during login and then you would like to have it available for all views without explicit declaring (For example you insert Hello, user! on every page). request attribute or bizData is fine for one request only. What about session attributes? They live in the user session. You can call them as many times as you wish. Best Regards, Antonio Gallardo
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Guido Casper dijo: I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't eager to write reusable components. But currently it's just that hard to come up with components really making the user's life easier. Yep. One of the things that refrained us to write components is the too much overhead they have: 1-Implementations of the lifecycle: Configurable, composable, etc. 2-The (1) give you even more code to write based on the implementations you choosed in (1). And people just want to write a simple hello wold component. The question is how much lines I need to write. And when we realize it is more than 20 lines. We are lost. It is really the better way to do things? I think the key is in KISS. The Flow Engine is so popular because of his own simplicity. And that is cool. I realize that components are a diferents than FlowEngine scripts. But I try to sell the concept of easy components writing is what the users need. An alert is already out: People is starting to (ab)use of FlowEngine code because they feel it is easier to write the full logic on FlowEngine instead of writing a component. I think we need think about this fact. On the mail list are clear samples of how they are even making workarounds to make things works in Flow at any cost, even when using a component will be easier (you have full access to many thins and in flow you have not the same access). But the perception win in this case. Components are existed before Flow, but Flow is more popular than writing components, the question is why? The problem I have with cocoon.getComponent() is the user's side of the fence. getComponent() doesn't say anything about the granularity of a component as Avalon allows for (and encourages) components of any granularity. Avalon has been there before flow and is intended to make the Java developer's life easier not the flow user's. The services for flow users should be coarse grained and high level. And I believe that the user shouldn't have to deal with technical details like component lifecycle (and having to call releaseComponent()). Please note that I don't want to discuss the pro/vs. release(). I really don't care wether the developer has to call release (at least right now :-). I for sure don't want to increase overall complexity. But if I could trade reduced user complexity for increased developer complexity I would do. a big +1. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? the JSR 170 is a complex beast. I would wrap it with a Repository avalon component, make the interface really simple and pass this to the scripting layer, hiding all the complexity inside. Exactly. I'm just thinking about a better way than an Avalon component (and thought it might be the right time to speak up now that we are designing a new container). That's how I would do it. And yes, I still believe in the pyramid of contracts, even more than in the past, but the sitemap is not enough, we need something else, we can't write script in XML. Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space. I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user. I think we share the same feeling :-D I will add I will prefer to change the default FlowEngine language from javascript to Groovy. I really believe it will give the user a more productive language with the best Java integration. It will be really a good tradeoff. Best Regards, Antonio Gallardo.
