New selector...
I'm just adding a simple selector that works on regular expressions over a request parameter. There are two classes, one is an abstract class defining all the regexp methods, the other is the implementation using the request parameter value as the string to be matched. Let me know if I can leave them in org.apache.cocoon.selection or you prefer another package/location/whatever... :-P Pier smime.p7s Description: S/MIME cryptographic signature
[BUG] Mime type on readers?
Hmmm, as anyone ever noticed that in case you read from a remote server, somehow, the mime type gets mangled? I have the following: http://core.vnunet.com/svn/site/{1}"/> When I do a simple CURL on the resource: $ curl -s -D /dev/stderr 'http://localhost:/getit/head/webapp/resources/images/ v7_vnunet_xml.gif' > /dev/null HTTP/1.1 200 OK Date: Tue, 15 Jun 2004 18:59:39 GMT Server: Jetty/4.2.19 (Mac OS X/10.3.4 ppc java/1.4.2_03) X-Cocoon-Version: 2.1.5-dev Content-Type: image/gif Vary: Host Content-Length: 251 Accept-Ranges: none $ Now, on the other hand, when I do the same on the original baby: $ curl -s -D /dev/stderr 'http://core.vnunet.com/svn/site/head/webapp/resources/images/ v7_vnunet_xml.gif' > /dev/null HTTP/1.1 200 OK Date: Tue, 15 Jun 2004 19:01:46 GMT Server: Apache/2.0.49 (Unix) DAV/2 SVN/1.0.2 ETag: "17//head/webapp/resources/images/v7_vnunet_xml.gif" Accept-Ranges: bytes Content-Length: 251 Content-Type: application/octet-stream $ EEEK... Originally, the server is saying that the image is of mime-type "application/octet-stream", I force the reader to emit a simple "xxx/zzz" mime-type, but Cocoon emits "image/gif"... Am I the only one seeing something wrong with it? Pier smime.p7s Description: S/MIME cryptographic signature
Re: [OT] Eclipse on OS/X
On 14 Jun 2004, at 21:50, Ugo Cei wrote: Il giorno 14/giu/04, alle 17:51, Pier Fumagalli ha scritto: If you haven't done it yet, I _strongly_ suggest y'all to update your Eclipse to 3.0RC2 on MacOS/X. It's quite an impressive update! Compared to what? I have 3.0RC1 but with the current rythm of releases I was planning to wait until the final release and stop downloading 80+ Megs every week or two. That is, unless RC2 is so much better than RC1. I believe I was running M8 or M9... (Sorry, I deleted it) Pier smime.p7s Description: S/MIME cryptographic signature
Bug in HTMLSerializer?
Hello, in my XML doc I need to declare some entities. But if I do so, I cant use the HTMLSerializer to output my doc because a braket > appears on the right top corner. Why? Is it a bug in HTMLSerializer? What can I do to avoid this? My xml doc: ]> &foo; My pipeline: My browser output (source): > bar Look at the first braket > on top of the source. Why is it there? Thank you for your help! Regards Stephan
Re: [VOTE] Unrestricting the FOM
Carsten Ziegeler wrote: Sylvain Wallez wrote: Makes sense. And migrating some stuff to the env-context may help removing some dependencies on Avalon. But whe have to be very careful about what attributes we want to move from avalon-context to env-context, and be sure they will still make sense in a new container and within blocks. Yepp. The only point I'm not sure about is the object model: should it be in the env-context, since it also contains that env-context? Kind of circular dependency that may be confusing... Yepp, that's true. I would say we leave this in the avalon context then. If we do that, we can't totally cut the dependency on avalon-context... What we need actually is some kind of mini-environment that would give access only to the "safe" properties of o.a.c.e.Environment, i.e. mainly the object model and attributes, plus access to the current avalon-context attributes through type-safe getter methods. Actually, this mini-environment is the object model. Too bad it's currently an untyped Map. Or what about creating an ObjectModel class that would be that mini-environment ? Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
On 15 Jun 2004, at 18:04, Sylvain Wallez wrote: Jeremy Quinn wrote: Should I hold back on committing my changes to make ContextHelper Contextualizable, to wait to see what comes out of this proposal ? Wait a bit ;-) You can still use the ContextAccess class in your own source tree, though. OK BTW. I think there may be a related issue here with a problem noted a while ago, where it was not possible to read parameters setup in web.xml as expected using : org.apache.cocoon.environment.Context.getInitParameter(String name) Unless Cocoon was 'expecting' that parameter to be there. I don't know if this is a bug or a just a misunderstanding ;) I guess you made the (sorry!) classical mistake of adding parameters to the Cocoon servlet instead of the _webapp context_, which is what is accessed using Context.getInitParameter(). Oh no :) regards jeremy smime.p7s Description: S/MIME cryptographic signature
RE: [VOTE] Unrestricting the FOM
Sylvain Wallez wrote: > > Makes sense. And migrating some stuff to the env-context may > help removing some dependencies on Avalon. But whe have to be > very careful about what attributes we want to move from > avalon-context to env-context, and be sure they will still > make sense in a new container and within blocks. > Yepp. > > The only point I'm not sure about is the object model: should > it be in the env-context, since it also contains that > env-context? Kind of circular dependency that may be confusing... > Yepp, that's true. I would say we leave this in the avalon context then. > What we need actually is some kind of mini-environment that > would give access only to the "safe" properties of > o.a.c.e.Environment, i.e. mainly the object model and > attributes, plus access to the current avalon-context > attributes through type-safe getter methods. > > >Then in flow, cocoon.context works perfect. > > > > > > Yupp. And with an IOC type2/3 container we could even > totally remove the dependency on avalon-context by simply have a > setContext(o.a.c.e.Context) method ;-) > Yepp :), it would work today if we would move to Fortress. Carsten
RE: [VOTE] Unrestricting the FOM
Jeremy Quinn wrote: > > > Currently these attributes are not really used. > > Ah, I though these were the context attributes you could > access from FlowScript, as in: > cocoon.context.setAttribute ("name", myObject); I have > used this before . when I needed to share the same object > between several users. > Yes, that's right. I meant Cocoon itself does not use them, it's up to the users to make sense of them. > > > > And we have o.a.a.context.Context which is a map containing > > many important information about the application. > > Do you mean org.apache.avalon.framework.context.Context ? > Yupp. > > Should I hold back on committing my changes to make ContextHelper > Contextualizable, to wait to see what comes out of this proposal ? > Hmm, don't know - we are in development state so we can remove it if we find a better solution before a release Carsten
Re: [VOTE] Unrestricting the FOM
Jeremy Quinn wrote: Should I hold back on committing my changes to make ContextHelper Contextualizable, to wait to see what comes out of this proposal ? Wait a bit ;-) You can still use the ContextAccess class in your own source tree, though. BTW. I think there may be a related issue here with a problem noted a while ago, where it was not possible to read parameters setup in web.xml as expected using : org.apache.cocoon.environment.Context.getInitParameter(String name) Unless Cocoon was 'expecting' that parameter to be there. I don't know if this is a bug or a just a misunderstanding ;) I guess you made the (sorry!) classical mistake of adding parameters to the Cocoon servlet instead of the _webapp context_, which is what is accessed using Context.getInitParameter(). Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Carsten Ziegeler wrote: Sylvain Wallez wrote: We already have cocoon.context, couldn't we make things available from there? Mmmh... don't know if it's a good idea, as the Cocoon core currently doesn't rely on custom attributes in the environment objects (unless I'm mistaken). This would complexify things a bit, IMO. Hmm, ok we currently have a o.a.c.environment.Context which has some functions from the servlet context object and attributes. Currently these attributes are not really used. That's what I pointed out above: the Cocoon core currently makes no use of attributes in env-context, session and request. These are for application use, and up to now the Cocoon core has not "polluted" these objects. And we have o.a.a.context.Context which is a map containing many important information about the application. Yep. Let's list what's in avalon-context. The main DefaultContext is initialized with: - Constants.CONTEXT_ENVIRONMENT_CONTEXT : the environment context (type o.a.c.e.Context) - Constants.CONTEXT_WORK_DIR : Cocoon's work directory (type File) - ContextHelper.CONTEXT_ROOT_URL : the servlet context's URL (type String - why not URL?) - Constants.CONTEXT_UPLOAD_DIR : the upload directory (type File) - Constants.CONTEXT_CACHE_DIR : the cache directory (type File) - Constants.CONTEXT_CONFIG_URL : location of cocoon.xconf (type URL, used only to initialize the Cocoon object) - Constants.CONTEXT_DEFAULT_ENCODING : default form encoding (type String) - Constants.CONTEXT_CLASS_LOADER : CocoonServlet's classloader (type ClassLoader, used only to initialize the Cocoon object) - Constants.CONTEXT_CLASSPATH : the classpath used by the XSP engine (type String) The actual Context seen by applications is a ComponentContext that wraps the above DefaultContext with: - ContextHelper.CONTEXT_OBJECT_MODEL : the current object model (type Map) - ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER : the current sitemap's service manager - ComponentContext.OBJECT_MODEL_KEY_PREFIX : prefix to access members of the object model (could be removed, as only used in the implementation of ContextHelper.getRequest()/getResponse()) When in HTTP environment, there's also: - CocoonServlet.CONTEXT_SERVLET_CONFIG : the ServletConfig When in portlet environment, there's also - CocoonPortlet.CONTEXT_PORTLET_CONFIG: the PortletConfig For me it seems that two contexts is one too much :) Makes sense. And migrating some stuff to the env-context may help removing some dependencies on Avalon. But whe have to be very careful about what attributes we want to move from avalon-context to env-context, and be sure they will still make sense in a new container and within blocks. So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon context. Now, we could for example store all information we currently have in the avalon context into the environment context and using the environment context as the only reference for application information. If you need this context you can get it from the avalon context. The avalon context only contains this single piece of information (of course for compatibility we let everything remain there as well). The only point I'm not sure about is the object model: should it be in the env-context, since it also contains that env-context? Kind of circular dependency that may be confusing... What we need actually is some kind of mini-environment that would give access only to the "safe" properties of o.a.c.e.Environment, i.e. mainly the object model and attributes, plus access to the current avalon-context attributes through type-safe getter methods. Then in flow, cocoon.context works perfect. Yupp. And with an IOC type2/3 container we could even totally remove the dependency on avalon-context by simply have a setContext(o.a.c.e.Context) method ;-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [BUG] forms-lib.js
Am 16:29 14.06.2004 +0200 schrieb Klaus Bertram: Hi all, i test the gui form with the standard IE5.0 based on win2000 there are 2 possible bugs 1 is based in the htmlarea script. (I look at it) after excluding the load of the script there are a an error in forms-lib.js at line 65 the compare of if (name == undefined) can't work because undefined as name is not defined ;) I add var undefined; at top and it rocks Tested under IE5.0, IE6.0, Moz 1.6 Klaus Hello. Your finding and your solution is correct, IE5.0 (but not Opera, Mozilla and IE5.5+) does not know the keyword "undefined". I found this bug a year ago and used this solution: eval(navigator.userAgent.indexOf("MSIE 5.0")!=-1 ? "var undefined;" : "void(0);"); which doesn't define the variable in browsers that support the keyword (I am not talking about IE4 etc here). IE5.0 is kind of bad for javascript users, because it claims to be compatible to a javascript version but then fails to do so. I can't remember if it is version 1.2 or 1.3 but most likely 1.3. For example Array methods like push, pop, slice, splice, shift, unshift do not exist. I had quite some fun (not!) to reimplement those methods in pure javascript. I don't know about the document.getElementById method, but I wrote a simple replacement using document.all for it, too. Of course one can't rewrite all missing stuff like the function invoking string replace but it was enough to get my application running. I took a look at this forms-lib.js to check for other errors and there is this fixme entry: form["forms_submit_id"].value = name; // FIXME: programmatically submitting the form doesn't trigger onsubmit ? (both in IE and Moz) forms_onsubmit(); form.submit(); Actually, this has been the case since Javascript version 1.1 (and probably 1.0, but I lack the original netscape documentation of that version) and is _correct_ behaviour. Calling form.submit() should not trigger the onsubmit eventhandler. Buggy Opera does so, though. One can call onsubmit() by hand (after checking if it is defined) or click() of one of the submit buttons of the form to trigger the form's onsubmit handler. The latter solution is not very safe. And: Since Opera messes up at this part, relying on onsubmit not being invoked when form.submit() is called has also become very dangerous. So doing it by hand is probably the best idea. gunnar -- G. Brand - interface:projects GmbH Tolkewitzer Strasse 49 D-01277 Dresden mail: [EMAIL PROTECTED] tel:++49-351-3 18 09 - 41 Ein Unternehmen der interface:business-Gruppe
Re: [VOTE] Unrestricting the FOM
On 15 Jun 2004, at 15:57, Carsten Ziegeler wrote: Sylvain Wallez wrote: We already have cocoon.context, couldn't we make things available from there? Mmmh... don't know if it's a good idea, as the Cocoon core currently doesn't rely on custom attributes in the environment objects (unless I'm mistaken). This would complexify things a bit, IMO. Hmm, ok we currently have a o.a.c.environment.Context which has some functions from the servlet context object and attributes. This is where I would have expected to find "work-directory", being a Servlet-supplied parameter. Currently these attributes are not really used. Ah, I though these were the context attributes you could access from FlowScript, as in: cocoon.context.setAttribute ("name", myObject); I have used this before . when I needed to share the same object between several users. And we have o.a.a.context.Context which is a map containing many important information about the application. Do you mean org.apache.avalon.framework.context.Context ? For me it seems that two contexts is one too much :) + 1 It is rather complicated ;) So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon context. Now, we could for example store all information we currently have in the avalon context into the environment context and using the environment context as the only reference for application information. If you need this context you can get it from the avalon context. The avalon context only contains this single piece of information (of course for compatibility we let everything remain there as well). Then in flow, cocoon.context works perfect. WDYT? YES !!! Should I hold back on committing my changes to make ContextHelper Contextualizable, to wait to see what comes out of this proposal ? BTW. I think there may be a related issue here with a problem noted a while ago, where it was not possible to read parameters setup in web.xml as expected using : org.apache.cocoon.environment.Context.getInitParameter(String name) Unless Cocoon was 'expecting' that parameter to be there. I don't know if this is a bug or a just a misunderstanding ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Bug in HTMLSerializer?
Hello, in my XML doc I need to declare some entities. But if I do so, I cant use the HTMLSerializer to output my doc because a braket > appears on the right top corner. Why? Is it a bug in HTMLSerializer? What can I do to avoid this? My xml doc: ]> &foo; My pipeline: My browser output (source): > bar Look at the first braket > on top of the source. Why is it there? Thank you for your help! Regards Stephan
RE: [VOTE] Unrestricting the FOM
Sylvain Wallez wrote: > > >We already have cocoon.context, couldn't we make things > available from there? > > > > > > Mmmh... don't know if it's a good idea, as the Cocoon core > currently doesn't rely on custom attributes in the > environment objects (unless I'm mistaken). This would > complexify things a bit, IMO. > Hmm, ok we currently have a o.a.c.environment.Context which has some functions from the servlet context object and attributes. Currently these attributes are not really used. And we have o.a.a.context.Context which is a map containing many important information about the application. For me it seems that two contexts is one too much :) So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon context. Now, we could for example store all information we currently have in the avalon context into the environment context and using the environment context as the only reference for application information. If you need this context you can get it from the avalon context. The avalon context only contains this single piece of information (of course for compatibility we let everything remain there as well). Then in flow, cocoon.context works perfect. WDYT? Carsten
RE: excalibur: cocoon dependencies moved!
Antonio Gallardo wrote: > > Yep. Carsten = super programmer! > Thanks, really appreciated, but I think that I'm not better than most of the others here - far the different. Perhaps I more often prefer doing over discussing... > He can manage excalibur stuff, Cocoon and a lot more :-D > > > > Looking forward to seeing some cocoon people over on > > [EMAIL PROTECTED], > > Thanks, I just few days ago asked Carsten about committer > rights for excalibur. I was waiting for the new dev list. I > will subscribe now. I hope to be useful there. > > I hope the will be a good atmosphere as in Cocoon. ;-) > :) Carsten
Re: [VOTE] Unrestricting the FOM
Jeremy Quinn wrote: I made o.a.c.components.ContextHelper Contextualizable, and added the getAvalonContext() method. It all compiles but is not tested from FlowScript yet. I have to get on with some other stuff right now, but hope to have this tested and committed by this evening (unless there are objections). +1! Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Custom Transformer: attributes lost when serialized XML recording
Adam Ratcliffe wrote: I have a custom transformer that extends AbstractSaxTransformer for making XML-RPC calls. It extracts a method call element from an input document and sends this to the remote service for processing. My problem is that when I use the startSerializedXMLRecording() method from AbstractSaxTransformer to collect the method call fragment it records elements only and the namespace attribute on the top-level element is lost. This isn't a problem with the generator that creates the input document as I can see the attributes if I serialize the document after generation. Is there a configuration step that I'm missing? I think you should maintain map of namespace declarations (by processing start/end namespace mapping event) and declare all namespaces when you start recording. Look around for code samples, I think there is something similar in other transformers. Vadim public void startElement(String uri, String name, String raw, Attributes attr) throws SAXException { if (name.equals(XMLRPC_REQUEST_ELEMENT)) { this.stack.push("end"); } else if (name.equals(XMLRPC_SERVICE_ELEMENT)){ this.startTextRecording(); } else if (name.equals(XMLRPC_METHOD_CALL_ELEMENT)) { this.startSerializedXMLRecording(XMLUtils.defaultSerializeToXMLFormat(tr ue)); } else { super.startElement(uri, name, raw, attr); } }
Re: Using HTTPS as a src for a file generator
On 14 Jun 2004, at 22:56, Steven Noels wrote: It sure was - I'll Wikify my success tomorrow for posterity. http://wiki.cocoondev.org/Wiki.jsp?page=HTTPsSources Thanks! -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [VOTE] Unrestricting the FOM
On 15 Jun 2004, at 11:27, Jeremy Quinn wrote: On 15 Jun 2004, at 10:57, Sylvain Wallez wrote: Jeremy Quinn wrote: On 15 Jun 2004, at 10:11, Sylvain Wallez wrote: Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), Good but not tie the FOM to a particular Avalon object (got lots of +0's and a -1). This is more difficult to understand, but I could see why some were worried. So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon. That is fine by me. Shall I commit the sample class you provided? Do you have any preferences for where it should live? Or do you have a more sophisticated way of adding this functionality, that you would prefer to use instead? I see two possible locations for this code: - in a new o.a.c.components.flow.util.AvalonContextAccessor class (note the explicit mention to Avalon to clearly show the dependency on the framework) I can understand this one - in o.a.c.components.ContextHelper, which alread holds a number of context-related methods. I am not quite sure how this functionality would get added to o.a.c.components.ContextHelper. It currently has all static methods, which are passed an existing org.apache.avalon.framework.context.Context Object. The second solution has the benefit of concentrating all Context-related features in a single class and so has my preference. Are you suggesting that this class be made Contextualizable and be given a getContext() method ? So to use it for getting a Context, you would call cocoon.createObject (ContextHelper).getContext () on it? OK I made o.a.c.components.ContextHelper Contextualizable, and added the getAvalonContext() method. It all compiles but is not tested from FlowScript yet. I have to get on with some other stuff right now, but hope to have this tested and committed by this evening (unless there are objections). regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Unrestricting the FOM
On 15 Jun 2004, at 10:57, Sylvain Wallez wrote: Jeremy Quinn wrote: On 15 Jun 2004, at 10:11, Sylvain Wallez wrote: Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), Good but not tie the FOM to a particular Avalon object (got lots of +0's and a -1). This is more difficult to understand, but I could see why some were worried. So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon. That is fine by me. Shall I commit the sample class you provided? Do you have any preferences for where it should live? Or do you have a more sophisticated way of adding this functionality, that you would prefer to use instead? I see two possible locations for this code: - in a new o.a.c.components.flow.util.AvalonContextAccessor class (note the explicit mention to Avalon to clearly show the dependency on the framework) I can understand this one - in o.a.c.components.ContextHelper, which alread holds a number of context-related methods. I am not quite sure how this functionality would get added to o.a.c.components.ContextHelper. It currently has all static methods, which are passed an existing org.apache.avalon.framework.context.Context Object. The second solution has the benefit of concentrating all Context-related features in a single class and so has my preference. Are you suggesting that this class be made Contextualizable and be given a getContext() method ? So to use it for getting a Context, you would call cocoon.createObject (ContextHelper).getContext () on it? Thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Unrestricting the FOM
Jeremy Quinn wrote: On 15 Jun 2004, at 10:11, Sylvain Wallez wrote: Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), Good but not tie the FOM to a particular Avalon object (got lots of +0's and a -1). This is more difficult to understand, but I could see why some were worried. So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon. That is fine by me. Shall I commit the sample class you provided? Do you have any preferences for where it should live? Or do you have a more sophisticated way of adding this functionality, that you would prefer to use instead? I see two possible locations for this code: - in a new o.a.c.components.flow.util.AvalonContextAccessor class (note the explicit mention to Avalon to clearly show the dependency on the framework) - in o.a.c.components.ContextHelper, which alread holds a number of context-related methods. The second solution has the benefit of concentrating all Context-related features in a single class and so has my preference. WDYT? Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote: Reinhard Poetz wrote: Sylvain Wallez wrote: Hi all, More and more, the limitations of objects provided by the FOM seem like arbitrary constraints that go in the way of people and produce confusion. Furthermore, these restrictions only apply to the JS flowscript and not to JavaFlow, thus making JS flowscript a second zone citizen compared to Java code. That's why I propose to remove these restrictions my having cocoon.request, cocoon.response and cocoon.context providing the full API defined by the interfaces in org.apache.cocoon.environment. Furthermore, I propose to add cocoon.avalonContext to provide access to the various data held by this object. More background on this subject is available in the "Less is more... or less" discussion [1] and my answer to Jeremy's problem [2] that shows how simple it is to workaround the restricted FOM. Please cast your votes! - [+1] to remove restrictions on existing objects. - [?] to add cocoon.avalonContext. I'm not sure about avalonContext.`What happens if we really drop Avalon as base framework? Do statements containing cocoon.avalonContext still work or will they be hidden (because Flowscript is interpreted) broken? If the user has to use the workaround and she recompiles the code with Cocoon 3.0 and the compiler doesn't compile her code anymore, she knows that she has a problem. Or will a possible legacy mode hide that she may have a problem? We should really try to make moving from Cocoon 2.x to 3.x as smooth as possible and users that only use Flowscripts and the sitemap shouldn't be forced to change their applications if they want to use Cocoon in the same way as they have been used to do. Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), Good but not tie the FOM to a particular Avalon object (got lots of +0's and a -1). This is more difficult to understand, but I could see why some were worried. So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon. That is fine by me. Shall I commit the sample class you provided? Do you have any preferences for where it should live? Or do you have a more sophisticated way of adding this functionality, that you would prefer to use instead? Thanks for your help, and thanks everyone for your votes. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Unrestricting the FOM
Reinhard Poetz wrote: Sylvain Wallez wrote: Hi all, More and more, the limitations of objects provided by the FOM seem like arbitrary constraints that go in the way of people and produce confusion. Furthermore, these restrictions only apply to the JS flowscript and not to JavaFlow, thus making JS flowscript a second zone citizen compared to Java code. That's why I propose to remove these restrictions my having cocoon.request, cocoon.response and cocoon.context providing the full API defined by the interfaces in org.apache.cocoon.environment. Furthermore, I propose to add cocoon.avalonContext to provide access to the various data held by this object. More background on this subject is available in the "Less is more... or less" discussion [1] and my answer to Jeremy's problem [2] that shows how simple it is to workaround the restricted FOM. Please cast your votes! - [+1] to remove restrictions on existing objects. - [?] to add cocoon.avalonContext. I'm not sure about avalonContext.`What happens if we really drop Avalon as base framework? Do statements containing cocoon.avalonContext still work or will they be hidden (because Flowscript is interpreted) broken? If the user has to use the workaround and she recompiles the code with Cocoon 3.0 and the compiler doesn't compile her code anymore, she knows that she has a problem. Or will a possible legacy mode hide that she may have a problem? We should really try to make moving from Cocoon 2.x to 3.x as smooth as possible and users that only use Flowscripts and the sitemap shouldn't be forced to change their applications if they want to use Cocoon in the same way as they have been used to do. Looking at the vote results, the general opinion is to remove the API restrictions (got only +1's), but not tie the FOM to a particular Avalon object (got lots of +0's and a -1). So let's drop this cocoon.avalonContext proposal. Firstly because it becomes less useful if the FOM is unrestricted, and secondly because we can easily add the ContextAccess I proposed to Jeremy as a utility class. People using that class will know by doing so that their app becomes tied to Avalon. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Custom widgets in CForms
Scott Yeadon wrote: Hello, Has anyone tried to create custom widgets within the Forms framework? Beyond the business logic of their validation rules, etc, I cannot find the code which actually creates the widgets visible user interface? Anyone got a how-to on any of this? This recently created page on the cocoon wiki may help: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsCreatingWidgets Vil. -- __ o| _. / \|o._ _ _ ._ _ ._ _ _|_ \/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_ / \__ http://website.lineone.net/~vilya
Re: Looking for a HowTo on adding widgets to CForms.
Andreas Hochsteger wrote: Hi Vilya, I'm sorry that I can't point you to an existing HOWTO. I had the same problem some time ago when I wanted to write a new data type for CForms. Perhaps it's time to collect this information on the wiki. I've created two pages which can be filled by those who know something about these things or are forced to learn it (hint!): http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsCreatingWidgets I modified this page a bit, mainly about modifying the WidgetReplacingPipe which is clearly something that's not needed for most of the widgets. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Unrestricting the FOM
Sylvain Wallez wrote: Hi all, More and more, the limitations of objects provided by the FOM seem like arbitrary constraints that go in the way of people and produce confusion. Furthermore, these restrictions only apply to the JS flowscript and not to JavaFlow, thus making JS flowscript a second zone citizen compared to Java code. That's why I propose to remove these restrictions my having cocoon.request, cocoon.response and cocoon.context providing the full API defined by the interfaces in org.apache.cocoon.environment. Furthermore, I propose to add cocoon.avalonContext to provide access to the various data held by this object. More background on this subject is available in the "Less is more... or less" discussion [1] and my answer to Jeremy's problem [2] that shows how simple it is to workaround the restricted FOM. Please cast your votes! - [+1] to remove restrictions on existing objects. - [?] to add cocoon.avalonContext. I'm not sure about avalonContext.`What happens if we really drop Avalon as base framework? Do statements containing cocoon.avalonContext still work or will they be hidden (because Flowscript is interpreted) broken? If the user has to use the workaround and she recompiles the code with Cocoon 3.0 and the compiler doesn't compile her code anymore, she knows that she has a problem. Or will a possible legacy mode hide that she may have a problem? We should really try to make moving from Cocoon 2.x to 3.x as smooth as possible and users that only use Flowscripts and the sitemap shouldn't be forced to change their applications if they want to use Cocoon in the same way as they have been used to do. WDYT? -- Reinhard
Re: Custom widgets in CForms
Leszek Gawron wrote: Scott Yeadon wrote: Hello, Has anyone tried to create custom widgets within the Forms framework? Beyond the business logic of their validation rules, etc, I cannot find the code which actually creates the widgets visible user interface? Anyone got a how-to on any of this? Stylesheet .. ... in samples/resources ;-) Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Custom widgets in CForms
Scott Yeadon wrote: Hello, Has anyone tried to create custom widgets within the Forms framework? Beyond the business logic of their validation rules, etc, I cannot find the code which actually creates the widgets visible user interface? Anyone got a how-to on any of this? Stylesheet .. -- Leszek Gawron [EMAIL PROTECTED]
Custom widgets in CForms
Hello, Has anyone tried to create custom widgets within the Forms framework? Beyond the business logic of their validation rules, etc, I cannot find the code which actually creates the widgets visible user interface? Anyone got a how-to on any of this? Thanks. Scott.