Re: CForms: where and how to specify the suggestion-list?
Jason Johnston wrote: Sylvain Wallez wrote: Hi all, I'm currently working on adding a Cocoon suggest feature to CForms fields based on Scriptaculous [1]. This requires to associate an URL to the field to fetch the suggestion list using Ajax requests when the user inputs something. Question is: where and how do we specify this? Is this a concern of the form definition, or a particular styling of the field? Concretely, should it be fd:field id=foo fd:suggestion-list url=foo-suggest /fd:field or ft:widget id=foo fi:styling suggest-href=foo-suggest /ft:widget It seems more natural at first to add this to the definition, but the url attribute must define an externally addressable url providing markup suited to the particular implementation of the suggestion (in the current case, it's a li with special classes). It is therefore more related to the view. Also, we may consider that the simple fact that we want to autocomplete is a view concern. Hmm... Another solution would be for the suggestion list in the definition to be given using the same syntax as fd:selection-list and have a system-provided default pipeline to render the list: fd:field id=foo fd:suggestion-list src=cocoon:/foo-suggestion-list/ !-- or use whatever implementation of selection list you want -- /fd:field This will automatically generate a fi:styling suggest-href=_cforms-suggest-foo/ which will be answered to in the sitemap with something like: map:match pattern=_cforms-suggest-* map:generate type=jx src=resource://org/apache/cocoon/forms/system/generate-suggest-list.xml/ map:transform src=resource://org/apache/cocoon/forms/system/list2html.xsl/ map:serialize type=xml/ /map:match This approach still allows to specify the suggest-href only in the view for cases where it's considered as being a view-only concern, and it also allows to specify different renderings of the suggestion list by catching the _cforms-suggest- pattern before the generic _cforms-suggest-*. WDYT? I don't understand why we need a whole separate pipeline for generating and rendering the suggestion list. Is responding to an AJAX request for a suggestion list any different really than any other CForms AJAX request? The pipeline used by Form.showForm() already has the capability (if set up for AJAX) to whittle down the widgets' XML to just what needs to be updated and transform it into the final view format. It seems that's everything we would need. Put more concretely: The suggestion list would be declared in the form definition, just like a suggestion list. We could even possibly reuse all the existing SelectionListBuilders to create the suggestion lists. The difference between the two would be that the selection list is always Auto-suggest would be turned on in the view with a suggest=true styling attribute, much like the ajax=true attribute on the form-template element. When this attribute is present, the XSLT adds the appropriate onkeypress listener, which sends an AJAX request to the continuation consisting only of that field's name-value pair and a special parameter (cocoon-ajax-suggest or similar) indicating the desire to get a suggestion list back. The form model interprets this request by generating the appropriate suggestions into the XML, surrounded by a special BrowserUpdate element such as bu:suggest/. All the rest of the XML gets removed by the BrowserUpdate transformer (just like any other AJAX request), and the resulting snippet is transformed by the field-styling XSLT into the final format expected by the view. The client-side script takes this response and renders it into a suggestion popup. I think this is closest to your last suggested solution above, in that it can use any of the existing selection-list builders, but it eliminates the need for a specialized pipeline. Seems cleaner to me, though I'm not sure about performance impact. Just another possibility. I understand your point, but autocomplete is IMO somewhat different from the current CForms Ajax system. The current Ajax system in CForms is designed to update a number of areas in the page depending on what widgets have been modified by the processing of the current request. This means that we _must_ run the form template because this is where the form layout is defined. Suggestion lists, on the other hand, are decorrelated from the page template, firstly because they are used later, when the user does some input in a field, and secondly because displaying a suggestion list has no impact on the page layout nor on other widgets. Adding it in the form template would therefore mean having different sections in the template, one for the form layout and other for the rendering of suggestion lists. Hence the idea to separate the rendering of suggestion lists in different pipelines. Sylvain -- Sylvain WallezAnyware Technologies http
Re: [2.1.8-dev] Real exception is not logged anymore
Carsten Ziegeler wrote: Sylvain Wallez schrieb: Carsten Ziegeler wrote: Ok, I have a simple test case, go into the sitemap of the gallery coplet (coplets/gallery) and change the type attribute of the xslt transformer from xslt to xslt2 then go into the portal and to the gallery tab. The result will be an exception in the log which does not tell you anymore the reason why the sitemap couldn't be loaded. Same happens if a component could not be created or any other problem occurs. Weird... this shows up correctly in my cocoon.log (see below). The strange thing is that it does not even show up in cocoon.log but portal.log. My portal.log has this: INFO(2005-09-22) 16:09.08:185 [portal] (/samples/blocks/portal/portal) PoolThread-4/AbstractCopletAdapter: Streamed coplet Portal-Demo (instance Portal-Demo-1) in 58ms. I also double-checked that I haven't forgotten to commit something and did a clean build. :) Hmm, I've done the same What JDK version are you using? 1.4.2. Same here (1.4.2_07 on a Mac) Strange Definitely... HEY PEOPLE, can someone else check this also? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: CForms: where and how to specify the suggestion-list?
Jason Johnston wrote:
On Thu, 2005-09-22 at 17:35 +0200, Sylvain Wallez wrote:
Jason Johnston wrote:
...
I think this is closest to your last suggested solution above, in that
it can use any of the existing selection-list builders, but it
eliminates the need for a specialized pipeline. Seems cleaner to me,
though I'm not sure about performance impact. Just another possibility.
I understand your point, but autocomplete is IMO somewhat different from
the current CForms Ajax system.
The current Ajax system in CForms is designed to update a number of
areas in the page depending on what widgets have been modified by the
processing of the current request. This means that we _must_ run the
form template because this is where the form layout is defined.
Suggestion lists, on the other hand, are decorrelated from the page
template, firstly because they are used later, when the user does some
input in a field
Sort of like validation error messages? ;-)
Not exactly, as validation messages are persistent on the page whereas
suggestion lists are transient and only last for the time where the user
is typing.
and secondly because displaying a suggestion list has
no impact on the page layout nor on other widgets.
I don't get it... displaying the suggestion list is a modification of
the DOM to display something not originally there, doesn't that count as
impact on the page layout? Sure, it's normally shown as a popup on its
own layer, so it doesn't cause any shifting around of other page
elements, but that's just one way of rendering it.
It is possible also that it might have an effect on other widgets, if we
chose to build it in a way that the AJAX request triggered on-value-
changed event handlers which may affect other parts of the form. That
could either be considered a good thing or a bad thing, and could
certainly be coded either way.
The lifetime of a suggestion-list is the time where the user types in
the input field. When focus is lost, the suggestion-list is removed and
only a that moment in time the on-value-changed listeners are triggered.
So their activation don't overlap in time with that of event listeners.
Suggestions are also different from selection lists, as selection list
must be ready when the page is first displayed, which is not the case of
suggestions. And contrarily to a selection-list, suggestions depend on
the current value of the field on which suggestions are to be made.
Adding it in the form
template would therefore mean having different sections in the template,
one for the form layout and other for the rendering of suggestion lists.
Hence the idea to separate the rendering of suggestion lists in
different pipelines.
Would it really require separate sections in the template? I was
thinking it would be handled entirely by the forms-field-styling XSLT,
and therefore transparent to the form template except for the styling
hint.
Perhaps some sample code to illustrate my idea would help (very rough of
course):
1) The form definition, where the list of possible suggestions is
defined:
fd:field id=theField
...
fd:suggestion-list
fd:item value=Ben /
fd:item value=Bob /
fd:item value=Chris /
fd:item value=Doug /
/fd:suggestion-list
/fd:field
Ok. But what if it's e.g. a query in the corporate LDAP directory?
2) The form template where we have a styling hint indicating auto-
suggest is desired:
ft:widget id=theField
fi:styling suggest=true /
/ft:widget
Right. BTW, we should not have to write suggest=true if there is a
suggesion-list. That should be implicit IMO.
3) The instance XML produced by that widget on the initial request (non-
AJAX):
fi:field id=theField
...
fi:styling suggest=true /
/fi:field
Ok.
4) The initial HTML result of that template snippet, post-XSLT:
span id=theField
input id=theField-input name=theField value=
onkeypress=CForms.getSuggestions(this); /
span id=theField-suggestions ... /
/span
Right.
5) The AJAX request string sent when the user enters b in the field:
{continuation-id}.continue?theField=bcocoon-ajax-suggest=1
Ok.
6) The instance XML produced by that widget in response to the above
request:
bu:suggest id=theField
fi:field id=theField
...
fi:suggestion-list
fi:item value=Ben /
fi:item value=Bob /
/fi:suggestion-list
/fi:field
/bu:suggest
(other elements in the template would of course be removed by the BU
transformer, so this is all that's left.)
Yep. But the fact that we know in advance that we'll have to remove all
except the suggestion-list is what led me to want a different pipeline.
7) The result of the field styling XSLT:
bu:suggest id=theField
ul id=theField-suggestions onclick=... ...
liBen/li
liBob/li
/ul
/bu:suggest
Yep.
8) The client-side JS would then insert that snippet into the DOM in the
correct spot, and hook up whatever additional event listeners it needs
Re: [Proposal] Prefixing cform ids
Thorsten Scherler wrote: El mié, 21-09-2005 a las 19:13 +0100, Upayavira escribió: I was thining about this just a could of days ago. When we generate a form, why don't we prefix all names with, say cf-. That way it would be cf-submit, and there wouldn't be any problem at all. WDYT? +1 In lenya we have the usecase-fw where we trigger the submit parameter. Can you explain trigger the submit parameter? Since that is not possible anymore I needed to extend it to allow as well the ok parameter. IMO would be nicer to use cf-submit. Hmm... I personally prefer Reinhard's proposal to set an @id on the form. I updated the check for submit so that it is allowed when the form does have an id. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: CForms: AJAX problem since update
Jeremy Quinn wrote:
Hi All,
I have some forms that used the JX Macro form generator and AJAX,
that worked before the recent update to the 2.2 version of CForms,
but fail now.
The form contains some regular text fields, a repeater with a row-add
button and a union with associated selection widget.
The repeater works fine.
The union with it's selection widget stopped working when I updated.
I can see in TCPMon, when you change the selector menu, all the right
data is submitted.
I get this error when the on-change event occurs for the union
selector :
org.apache.cocoon.forms.FormsRuntimeException: Form is not a repeater
at fd:form - file:/[blah]/forms/[blah]-model.xml:5:2
at jx:if - resource://org/apache/cocoon/forms/generation/
jx-macros.xml:214:54
at ft:repeater - file:/[blah]/forms/[blah]-template.xml:30:35
. . .
If I remove the repeater, the Union and it's selector work correctly.
I get a similar error under different circumstances.
Our pages use TimeBrowserUpdate widgets. That use the same
BrowserUpdateTransformer to update small regions of the page,
triggered by a timer on the Browser (and I still mean to commit this
once I know where to put it).
This used to work as well. Since the update however, when you use one
of these widgets in a page that also has a form that is generated
using JX Macros, you get this error on update :
org.apache.cocoon.generation.JXTemplateGenerator$JXTException:
java.lang.NullPointerException
at jx:if - resource://org/apache/cocoon/forms/generation/
jx-macros.xml:45:52
at ft:widget - file:[blah]/forms/search-advanced-
template.xml:17:55
Can you give also the first lines of the java stacktrace to know where
the NPE happens?
When the TBU updates, it sends only it's own data, not that of the form.
If you set the fd:form/@ajax to false, then the union starts working,
but the TBU still has the same error.
If you process the form using FormsTransformer instead of JXMacro
generator, then it works as expected. (You have to switch between
repeater and repeater widget, I don't know why).
I can see that the implementation of JX Macros has changed
completely, but as of yet I cannot work out the cause of the problem.
Any suggestions would be welcome.
JX macros were largely refactored, and there was a little change to
widget scoping within ft:repeater. This scoping defines the base
widget that is used to resolve @id attributes on template instructions,
which is also available as the ${widget} variable.
Within ft:repeater and before we enter ft:repater-rows, $widget is
now the repeater itself whereas it previously was the parent of the
repeater.
The addcontact widget in the dynamic_repeater sample is a good example
of this change.
We previously had
ft:repeater id=contacts
...
ft:repeater-rows
...
/ft:repeater-rows
ft:widget id=addcontact/
/ft:repeater
whereas we now have
ft:repeater id=contacts
...
ft:repeater-rows
...
/ft:repeater-rows
ft:widget id=../addcontact/
/ft:repeater
Can this be the cause of your problem?
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [Proposal] Prefixing cform ids
Thorsten Scherler wrote: Yeah, that sounds as well fine. That means I need to add something like: ft:form-template id=something/. Yep. And honestly I strongly recommend not using html form inputs named submit (be it cforms or not), because sooner or later you will hit the property-that-overrides-the-function problem. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.1.8-dev] Real exception is not logged anymore
Carsten Ziegeler wrote: If you log an exception, the real cause for the exception is not logged anymore. For example, I have a problem for example in a portlet where an NPE is thrown. THis is later catched several times, the new location information is added and then finally logged. The logged exception containes the location information, but the NPE got somehow lost. Any idea how to fix this? I encountered the same yesterday on one of our portal applications, where only the TransformerException raised by the portal stylesheet was reported. I'll fix this ASAP. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems in CForms in latest from SVN]
Carsten Ziegeler wrote: Ok, now I found out the problem: No top-level widget should be named 'submit' to avoid problems with HTML form elements, at fd:submit Why did this change? It broke our application and the error message was nowhere to be seen. It would be good to see at least a message and in addition I think we should just create a warning here to keep compatibility, no? This has been added to 2.2 some months ago. Basically, the big problem with inputs named submit is that they hide the submit() function on the Form object in the browser document. This isn't really a problem until you have some event handlers on an input, that needs to programmatically call form.submit(). In that case, the form is not submited and there's an JS error in the browser such as object is not a function. I spent many hours finding such problems, and many CForms users already encountered it (see for example [1]). Hence this decision to forbid widgets named submit. So what should we do: allow widgets named submit knowing that it will break forms with event handlers, or allow it for the sake of compatibility, letting users pull their hairs with weird broken forms? Sylvain [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109947942619227w=2 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree widget example broken (was Re: svn commit: r289538)
Thorsten Scherler wrote:
El mar, 20-09-2005 a las 17:38 +0200, Sylvain Wallez escribió:
Thorsten Scherler wrote:
That is working fine. :) Very good stuff.
Any hints how I can implement the binding?
The tree widget currently doesn't have child widgets, so binding it
doesn't really make sense.
It does not provide child widgets in the cforms definition but IMO each
node of the tree is an option. The file explorer example shows that
quite nice. You can select nodes and the selected nodes are stored in
the message, right?
The tree widget keeps the paths of selected nodes, but not the nodes
themselves, to avoid keeping hard references on the tree model. You can
access the selection using tree.getSelectionPath (single selection) or
tree.getSelectionPaths (multiple selection).
From a TreePath, you can then access the actual tree node using
tree.getModel().getNode(path).
Now one way to have a binding example is to not use the message wigdet
but another widget where we store the selected option. Please have a
look at http://pastebin.com/370003.
Didn't knew pastebin. Cool!
From there I would like to change the filesOption.setValue(...) in:
...
} else {
messages.setValue(count + files selected);
filesOption.setValue(count + files selected);
}
to an array that is storing the files.selectionPath for all selected
files. From there we can extracted it in the binding again. Does that
makes sense?
You actually don't need to update the array in the event listener. Just
use tree.getSelectionPaths() to get the full selection when you need to
perform your binding.
I am still looking into a way how to get the selection to an array. Can
you point me to information about getting the event.source.selection
into an array?
What about:
TreePath[] paths = tree.getSelectionPaths();
Object[] objs = new Object[paths.length];
for (int i = 0; i paths.length; i++) {
objs[i] = tree.getModel().getNode(paths[i]);
}
What you should take a lot at though, is the TreeModel which is what
should be provided by the application to fill the tree.
I looked at the $Sample and actually I am planning to use it in lenya to
read in the sitetree.xml of a publication. I reckon I just need some
small modifications.
Great! This tree widget is very new, and just awaits users to express
their needs!
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [2.1.8-dev] Real exception is not logged anymore
Sylvain Wallez wrote: Carsten Ziegeler wrote: If you log an exception, the real cause for the exception is not logged anymore. For example, I have a problem for example in a portlet where an NPE is thrown. THis is later catched several times, the new location information is added and then finally logged. The logged exception containes the location information, but the NPE got somehow lost. Any idea how to fix this? I encountered the same yesterday on one of our portal applications, where only the TransformerException raised by the portal stylesheet was reported. I'll fix this ASAP. Fixed. Please cross-check. There's still an issue with SAXException which doesn't seem to print its cause stacktrace, even with JDK 1.4. I'm currently working on it. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree widget example broken (was Re: svn commit: r289538)
Thorsten Scherler wrote: Please stay with me and have a look at http://pastebin.com/370146. I added a binding file and a custom binding containing above code, but how can I now produce for each object a node? +/* + * How to produce for each object a new xml-node? + * Like fileobjs[1]/file, fileobjs[2]/file, ... + */ The problem is that the binding you will want to do highly depends on the TreeModel, i.e. the kind of objects returned by model.getNode(). We could imagine to have something similar to the repeater binding, executing child bindings for each of the selected paths. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems in CForms in latest from SVN]
Reinhard Poetz wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Ok, now I found out the problem: No top-level widget should be named 'submit' to avoid problems with HTML form elements, at fd:submit Why did this change? It broke our application and the error message was nowhere to be seen. It would be good to see at least a message and in addition I think we should just create a warning here to keep compatibility, no? This has been added to 2.2 some months ago. Basically, the big problem with inputs named submit is that they hide the submit() function on the Form object in the browser document. This isn't really a problem until you have some event handlers on an input, that needs to programmatically call form.submit(). In that case, the form is not submited and there's an JS error in the browser such as object is not a function. I spent many hours finding such problems, and many CForms users already encountered it (see for example [1]). Hence this decision to forbid widgets named submit. So what should we do: allow widgets named submit knowing that it will break forms with event handlers, or allow it for the sake of compatibility, letting users pull their hairs with weird broken forms? I always give my forms an ID in the definition. This creates request parameters like [form-id].[widget-id]. Enforcing form IDs or setting a default ID in the case it is missing should solve the problem too, shouldn't it? Yep, that's right. I'll take this into account in the check. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.1.8-dev] Real exception is not logged anymore
Sylvain Wallez wrote: There's still an issue with SAXException which doesn't seem to print its cause stacktrace, even with JDK 1.4. I'm currently working on it. Fixed also. SAXException doesn't have a getCause() method, thus making it a bad JDK 1.4 citizen. To circumvent this, I added some code in LocatedException and LocatedRuntimeException to ensure that JDK 1.4 causes are always initialized, by calling Throwable.initCause(). Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: furious anger: portal broken
Carsten Ziegeler wrote: snip/ For example it took us some days to update from 2.1.7 to a recent 2.1.8-dev because some things in CForms changed and broke our whole web application. Hmm... could it be that taking CForms as an example is pure coincidence? What was the problem? Ok, that's it on *that* subject (I hope), let's get into the technical discussion: Both, the JSR 168 and WSRP require the functionality to switch from http to https and back. Switching the protocol is only possible with absolute urls (for the switch itself). That's the reason why the LinkService now creates absolute urls. Can you elaborate on this protocol switch? What is it about? Any pointers? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Regression on DefaultLinkService
Vadim Gritsenko wrote: Jean-Baptiste Quenot wrote: * Carsten Ziegeler: There were several suggestions in this thread about configuration on your side. Indeed, Upa was right in suggesting that we use Apache as a proxy with ProxyPass directive. The server name used to access the application is not the same as the one returned by request.getServerName(). Use ProxyPreserveHost http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost Or, for those using Tomcat, the proxyHost and proxyHost configurations: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html#Proxy%20Support Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Bricks example app in our whiteboard, WDYT?
Upayavira wrote: So, you get my vote for putting it into the whiteboard. +1 also. I'm frequently asked about the recommended practices or design patterns for a Cocoon application. So starting to have some sample standalone applications in our SVN is a good thing. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Protocol switch in portals (was Re: furious anger: portal broken)
Ralph Goers wrote: Sylvain Wallez wrote: Ok, that's it on *that* subject (I hope), let's get into the technical discussion: Both, the JSR 168 and WSRP require the functionality to switch from http to https and back. Switching the protocol is only possible with absolute urls (for the switch itself). That's the reason why the LinkService now creates absolute urls. Can you elaborate on this protocol switch? What is it about? Any pointers? Very often you want to display a few pages, but not all, of your website using SSL. So you use http for most of the website but use https for the few pages that need it. That necessitates using the absolute path since the switch from http to https isn't relative to anything. I'm a total newbie on this matter, so that may be dumb questions. I don't see how absolutizing links allows this: the result of absolutization is that all links use the protocol that was used by the current request, i.e. if it's http than all links will use http and if it's https then all links will use https. It seems to me that the protocol to be used depends on the page that is to be displayed rather than where you come from to that page, no? Absolutization means that once you enter the site using a particular protocol, you always use that one. Or did I missed something? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: furious anger: portal broken
Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: snip/ For example it took us some days to update from 2.1.7 to a recent 2.1.8-dev because some things in CForms changed and broke our whole web application. Hmm... could it be that taking CForms as an example is pure coincidence? Huh? What do you mean? Bah, never mind... What was the problem? One problem was the split of the javascript lib into two libs which you now have to include; another one was the ajax support corrupting the layout with mozilla/firefox. While the first one was no big deal, the second one took us some time to find out. There were other problems, like the model is now immutable, so you can't change the required flag at runtime and so on. But after all no real problems as we expect problems when updating any third party library. Ok, that's it on *that* subject (I hope), let's get into the technical discussion: Both, the JSR 168 and WSRP require the functionality to switch from http to https and back. Switching the protocol is only possible with absolute urls (for the switch itself). That's the reason why the LinkService now creates absolute urls. Can you elaborate on this protocol switch? What is it about? Any pointers? A portlet can decide to switch to HTTPS for example for forms. References are the two specs, JSR 168 and WSRP. Well, I was hoping you had a bookmark at hand _inside_ these specs. I'll do my homework and dig... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals (was Re: furious anger: portal broken)
Carsten Ziegeler wrote: Sylvain Wallez wrote: I'm a total newbie on this matter, so that may be dumb questions. I don't see how absolutizing links allows this: the result of absolutization is that all links use the protocol that was used by the current request, i.e. if it's http than all links will use http and if it's https then all links will use https. It seems to me that the protocol to be used depends on the page that is to be displayed rather than where you come from to that page, no? Absolutization means that once you enter the site using a particular protocol, you always use that one. Or did I missed something? The LinkService accepts a boolean argument indicating if you want a secure link. If this is set to true then the service switches to https. Right. But AFAICS its never used. Do you have plans to update CopletTransformer or something? As I said yesterday, we could create relative links if the procotol is not changed, but there are cases where we need absolute links. Can you elaborate on use cases that need absolute links? Shouldn't the default be to keep relative URLs unless some specific secure=true|false attribute is specified on the link (i.e. the Boolean passed to LinkService is null)? That would allow the portal to run smoothly on deployments where ProxyPreserveHost or proxyHost have not been configured, or where the used server infrastructure doesn't support it. And this leads to another question: what if the deployment uses httpd+mod_ssl that proxies to the servlet engine over http? The protocol seen by the servlet engine will be http, leading all links to be switched to an insecure protocol. BTW, I guess there's a potential bug in DefaultLinkService, as the port number is added to the URL only if it's not 80, whereas https uses port 443. That means that if you ever use https on port 80 (yeah I know it's weird), generated urls will use the default port, ie 443. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree widget example broken (was Re: svn commit: r289538)
Thorsten Scherler wrote: El vie, 16-09-2005 a las 13:48 +, [EMAIL PROTECTED] escribió: Author: sylvain Date: Fri Sep 16 06:46:22 2005 New Revision: 289538 URL: http://svn.apache.org/viewcvs?rev=289538view=rev Log: Merge GSoC libraries and 2.1 branches Hi sylvain, (this time copyn' paste) ;-) Thanks for checkin in the form stuff. :) I just played around a wee bit but the tree example are broken in 2.1.x. I get: Unknown kind of widget 'tree' at file:/home/thorsten/apache/cocoon-2.1.x/build/webapp/samples/blocks/forms/forms/sampletree_model.xml:30:44 context://samples/blocks/forms/forms/sampletree_model.xml - 30:44 Calling function do_sampleTree context://samples/blocks/forms/forms/sampletree_model.xml - 30:44 [CascadingException] resource://org/apache/cocoon/forms/flow/javascript/Form.js - 47:-1 ... org.apache.avalon.framework.service.ServiceException: Non-existing component for this hint (Key='tree') at org.apache.cocoon.forms.util.SimpleServiceSelector.select(SimpleServiceSelector.java:98) at org.apache.cocoon.forms.formmodel.AbstractWidgetDefinitionBuilder.buildAnotherWidgetDefinition(AbstractWidgetDefinitionBuilder.java:145) at org.apache.cocoon.forms.formmodel.AbstractContainerDefinitionBuilder.setupContainer(AbstractContainerDefinitionBuilder.java:60) Can it be that there is still something missing? Yep: I forgot to add the declaration for this new widget in the 2.1 configuration files. Should be fixed now. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals
Carsten Ziegeler wrote: Sylvain Wallez wrote: Right. But AFAICS its never used. Do you have plans to update CopletTransformer or something? It's currently only used from the JSR 168 and the WSRP implementation. We could add it to the CopletTransformer if there is the need. Ok. I think adding support for this in the Cocoon portal itself would be a nice addition, in order for it not to be less featured than the official specifications. Can you elaborate on use cases that need absolute links? Shouldn't the default be to keep relative URLs unless some specific secure=true|false attribute is specified on the link (i.e. the Boolean passed to LinkService is null)? That would allow the portal to run smoothly on deployments where ProxyPreserveHost or proxyHost have not been configured, or where the used server infrastructure doesn't support it. yes, this is exactly what I meant above :) - *but* if you haven't configured your environment correctly, you might get into problems with jsr 168 and wsrp. Right. Now projects that use Cocoon as a complete solution don't really care about jsr168 and WSRP! So, restating my question as I'd really like to know, what are the use cases that require URL absolutization other than when a coplet/portlet wants to enforce the protocol? This is because we could avoid absolutizing except when the portlet ask for a particular protocol, i.e. the Boolean parameter in getLinkURI() is not null. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals
Carsten Ziegeler wrote: Sylvain Wallez wrote: Right. Now projects that use Cocoon as a complete solution don't really care about jsr168 and WSRP! Everyone is free to use what he wants :) I think using standardized portlets helps a lot in some cases. C'mon, I never said the contrary, but just that people using Cocoon and only Cocoon should not be bothered by jsr168 or wsrp-related problems. So, restating my question as I'd really like to know, what are the use cases that require URL absolutization other than when a coplet/portlet wants to enforce the protocol? This is because we could avoid absolutizing except when the portlet ask for a particular protocol, i.e. the Boolean parameter in getLinkURI() is not null. Yes, I already agreed to this - so someone just has to implement it which shouldn't be that hard. Ok, I'll do it. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals
Ralph Goers wrote:
Sylvain Wallez wrote:
Right. Now projects that use Cocoon as a complete solution don't
really care about jsr168 and WSRP!
You're joking right? Our plans are to use the portal for generating
the site navigation for all our various products since it is perfect
for that. The fact that it allows JSR-168 portlets to easily
integrate into that mix is a huge plus as we can get portlets from our
partners or third party vendors and easily add them to websites.
You got me wrong: I haven't said that we should not care about jsr168
and wsrp, but that people that don't use it should not be asked to take
care about deployment issues (ProxyPreserveHost et al) that are
specifically related to these features.
So, restating my question as I'd really like to know, what are the
use cases that require URL absolutization other than when a
coplet/portlet wants to enforce the protocol?
This is because we could avoid absolutizing except when the portlet
ask for a particular protocol, i.e. the Boolean parameter in
getLinkURI() is not null.
As Carsten said, what you are suggesting can be done, but if it was
that easy I'm sure it would have been done that way in the first place :-)
In DefaultLinkService.getInfo() : add a Boolean secure parameter and then
if (secure != null) {
// absolutize using either http or https depending on the value of
secure
} else {
// do not absolutize
}
Isn't it just what is needed?
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Tree widget example broken (was Re: svn commit: r289538)
Thorsten Scherler wrote: That is working fine. :) Very good stuff. Any hints how I can implement the binding? The tree widget currently doesn't have child widgets, so binding it doesn't really make sense. What you should take a lot at though, is the TreeModel which is what should be provided by the application to fill the tree. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
You got me wrong: I haven't said that we should not care about jsr168
and wsrp, but that people that don't use it should not be asked to take
care about deployment issues (ProxyPreserveHost et al) that are
specifically related to these features.
As soon as you want to switch to https for any forms in your portlets
you need it, for example if you use cforms to build them.
You're right: a working getServerName() is actually needed as soon as we
want to switch protocols. But that only happens on sites mixing http and
https for urls served by Cocoon, which isn't always the case.
In DefaultLinkService.getInfo() : add a Boolean secure parameter and then
if (secure != null) {
// absolutize using either http or https depending on the value of
secure
} else {
// do not absolutize
}
Isn't it just what is needed?
Hmm, I'm not sure - I think we should compare the current protocol with
the protocol request and if they're not equal use absolute urls, no?
Sorry: what do you mean by current protocol and protocol request? I
guess it's the protocol of the current request and the protocol asked
for by the caller of getLinkURI()?
That should be something like:
String proto;
if (secure == null) {
proto = request.scheme();
} else {
proto = secure.booleanValue() ? https : http;
}
if (proto.equals(request.getScheme()) {
// same scheme: do not absolutize
} else {
// different scheme: absolutize
}
This actually filters more cases where absolutizing will effectively
happen, which I like :-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Protocol switch in portals
Ralph Goers wrote:
Sylvain Wallez wrote:
You're right: a working getServerName() is actually needed as soon as
we want to switch protocols. But that only happens on sites mixing
http and https for urls served by Cocoon, which isn't always the case.
You'd be surprised how often you need this! Obviously, you need it
for something like the petstore where you place an order, but you need
it for almost any form that has data that might be considered
sensitive, i.e. it has account numbers, social security numbers,
passwords, etc. In fact, the login page really should be secure but
then you want to switch to http for the majority of a site.
Hmm... but if you switch to http after having authenticated through
https, then the session-id can be hijacked, thus allowing access to the
sensitive data.
Sorry: what do you mean by current protocol and protocol request?
I guess it's the protocol of the current request and the protocol
asked for by the caller of getLinkURI()?
That should be something like:
String proto;
if (secure == null) {
proto = request.scheme();
} else {
proto = secure.booleanValue() ? https : http;
}
if (proto.equals(request.getScheme()) {
// same scheme: do not absolutize
} else {
// different scheme: absolutize
}
This actually filters more cases where absolutizing will effectively
happen, which I like :-)
Yes, this looks like what is needed.
Great!
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
[vote-results] Arje Cahn as a new committer
Team, The vote ended up with 26 +1 and nothing else! As soon as Arje comes back from vacation next week, I'll ask him for his preferred loging name and send the account creation request. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon marketing
Joerg Heinicke wrote: On 14.04.2005 15:19, Sylvain Wallez wrote: Now that Cocoon has Spring and Ajax support, we really should post an article on TSS ;-) I guess this has not happened yet ;) Cocoon was also the first web framework with continuations and never really made something out of it. We could really improve in our marketing. Yup. We need to write articles. I'm sure they would easily be accepted by onjava, TSS, etc. A discussion subject for the hackaton? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: CForms branches: there can be only one
hepabolu wrote: Sylvain Wallez wrote: Hi all, I have merged all 3 branches of CForms: 2.1, 2.2 and library (Max's GSoC work). Whatever the current state is: great work. Thanks! I'm sure you're the first to fix what seems to be broken. Fixed! I couldn't live with this broken thing :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: SVN access
Joerg Heinicke wrote: On 17.09.2005 12:05, [EMAIL PROTECTED] wrote: Author: sylvain Date: Sat Sep 17 03:05:05 2005 New Revision: 289715 URL: http://svn.apache.org/viewcvs?rev=289715view=rev Log: Fix class/new binding Hello Sylvain, you seem to have access to SVN? Since a few days I can not access Apache SVN, neither http://svn.apache.org/; in the browser now svn up on my repositories. Anybody else too? Strange, as I haven't had any problems lately. Any error message? However, I see that you have access to bugzilla :-) Thanks for all this work! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
CForms branches: there can be only one
Hi all, I have merged all 3 branches of CForms: 2.1, 2.2 and library (Max's GSoC work). We now have one single version of CForms, which is the one in cocoon/blocks/forms/trunk. This is the version that was already used in 2.2 and which is now also imported in 2.1 using svn:external. I hope to have forgotten nothing during the merge. The only issue I've seen so far is that the fb:class fb:new bindings are broken, which I will fix ASAP (I wanted to commit quickly before other people do other changes). It would be good for other people to test this unified version to see if there are more issues. Libary support is there and you can learn about it here: http://cocoon.zones.apache.org/daisy/documentation/forms/685.html This tedious work will hopefully save us some time in the future :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: loc namespace and attributes in inserted nodes (CForms)
BURGHARD Éric wrote: Hi, I found that the loc namespace and several attributes are inserted during the binding phase (inser-node). Theses informations are apparently usefull for cocoon stack traces, but IMHO they should disapear during form.save(). I'm not sure. Is this a bug or feature ? Yes, this is a bug. The binding mixes instructions and elements that are copied to the target document, and these attributes should be removed in this last case. I'm currently doing a triple merge on CForms (2.2, 2.1 and Max libraries) and will take care of this afterwards. Thanks for reporting! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: AJAX + FormsGenerator
BURGHARD Éric wrote: Hi, Since i'm using xsl2 for all my forms, i'm looking for a way to enable ajax in FormsGenerator. Interesting. Can you explain how you use XSLT 2 and the FormGenerator? After quickly looking through sources, i found that this feature seems to be planned in the FormsGenerator (FIXME comments). I guess you're referring to the FIXME in AbstractWidget.generateSaxFragment. At first glance, i thought that this would be just a matter of copy and paste of the relevant code from JXMacrosHelper to AbstractWidget, so i could use the browser-update transformer (exactly like we use to do with the CForms macros). But by reading the comment (we may want to strip out completely widgets that aren't updated when in AJAX mode), i'm not sure if this is the right way to do it. Will the generator generate the bu tags, or will it generate the tags for updated widgets only (without bu) ? If Widget.generateSaxFragment() was producing the bu:replace elements, then that would mostly translate to piping the result of the FormsGenerator through the BUTransformer. Unfortunately, this is not what happens and it should not happen as the bu:replace tag is really a view concern. A way to achieve this is for widgets to produce an additional updated=true attribute when they were updates. The FormsGenerator can then easily wrap such widget elements with a bu:replace that can then be consumed by the BUTransformer and whatever comes next. I need some enlightment just to be able to contribute cleanly to this really cool feature (thx sylvain). Hope this helped :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: loc namespace and attributes in inserted nodes (CForms)
BURGHARD Éric wrote: Sylvain Wallez wrote: BURGHARD Éric wrote: Hi, I found that the loc namespace and several attributes are inserted during the binding phase (inser-node). Theses informations are apparently usefull for cocoon stack traces, but IMHO they should disapear during form.save(). I'm not sure. Is this a bug or feature ? Yes, this is a bug. The binding mixes instructions and elements that are copied to the target document, and these attributes should be removed in this last case. I'm currently doing a triple merge on CForms (2.2, 2.1 and Max libraries) and will take care of this afterwards. Thanks for reporting! It was not a regular reporting since i was not sure (and i understand that i don't need to fill-up a bugzilla ticket). Anyway it's me who need to thank you for merging :-) Can i do something for ajax support in FormsTransformer. Would it be better if i wait until your merges ? Is there a lot of change on AJAX implementation ? The Ajax stuff has not changed and is identical in 2.2 and 2.1. But there are a number of other small updates here and there, and the bigger library stuff. So it's better to wait till the merge is done. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree view?
Thorsten Scherler wrote: On Tue, 2005-09-13 at 18:08 +0200, Sylvain Wallez wrote: Thorsten Scherler wrote: Hi Silvain, That's S*y*lvain :-) sorry :( german guy speaking. ;-) No worries, but... Thanks Sylvian and thanks cocoon community. That's Sylv*ai*n! I think you really should use copy/paste :-P S?lv??n -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [CForms] Several forms per page?
Carsten Ziegeler wrote:
The forms.lib.js contains this snippet:
// Handlers that are to be called in form's onsubmit event
// FIXME: this single var implies only one form per page, and needs tobe
// visited if we decide to support several forms per page.
var forms_onsubmitHandlers = new Array();
Now, what does this actually mean if I have several forms per page? I'm
currently thinking of the portal having different portlets each with an
own form.
This feature is a provision for the case where some widget
implementations need to perform some special actions such as copying
some visible fields to hidden ones. The only widget implementation that
uses it is the double listbox (see form.js/forms_createOptionTransfer)
which could be refactored in order not to use it.
However, there has been some posts on the mailing lists showing that
some people use it to plug in some client-side validation.
So I think we should deprecate this and replace it with a per-form
system (i.e. attaching these handles to the form object itself). A way
to enforce this feature isn't used in the portal is to replace the
push method of the forms_onsubmitHandlers object by an alert:
forms_onsubmitHandlers.push = function() {
alert(You cannot use form_onsubmitHandlers in the portal) }
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [CForms] Several forms per page?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So I think we should deprecate this and replace it with a per-form
system (i.e. attaching these handles to the form object itself).
+1
A way
to enforce this feature isn't used in the portal is to replace the
push method of the forms_onsubmitHandlers object by an alert:
forms_onsubmitHandlers.push = function() {
alert(You cannot use form_onsubmitHandlers in the portal) }
Hmm, but this is only required if I have more than one form on the
portal page, or?
Yes. So this alert thing could be added only if several CForms on a
single page (other kind of forms are ok). Now we have to find a way to
detect this...
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Build broken?
Carsten Ziegeler wrote: Antonio Gallardo wrote: +import org.apache.cocoon.faces.taglib.ValidateRequiredTag; Curently the build is broken to me. I guess I am missing some block. Wich block I need to add in order to get this dependency? :-) I really hope that our forms block does not depend on faces (and taglib)? Naaah, this is this damn Eclipse that was too quick at adding an import. Or was it me hitting return too fast without looking at the autocompletion proposal? :-) Anyway, this is fixed! Sorry for the inconvenience! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Vary: Host in ResourceReader breaks IE
Ralph Goers wrote: Did you see http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html? I'm a bit lost in these gory descriptions of IE bugs. So what is the right header to put to fix this cache issue, knowing that Vary: Host breaks downloads? Hi all, I found an annoying thing today. The following straightforward sitemap statement, which is intended to download a zip file, leads IE to display an error message when the users tries to open Winzip from IE (saving the file on disk is ok): map:read src=foo.zip mime-type=application/x-zip-compressed/ After some protocol-level debugging, it appears to be caused by the Vary: Host header that is added by the ResourceReader, which leads to an error message in IE. This bug has been identified in 1999 [1]!!! Now it seems that this header was added to work around an IE cache bug [2] about which no details are given. So the fix to the unknown cache problem leads to falling into another IE bug. Can someone explain the reason for the Vary header? If not, I'd like to remove it so that downloads work again... Sylvain [1] http://archive.apache.org/gnats/4118 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=14048 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Shall we switch to Jira?
Pier Fumagalli wrote: Just an idea... I'm used to work on it at work, and it's quite an improvement on Bugzilla, and allows things like: http://issues.apache.org/jira/secure/IssueNavigator.jspa? view=rssquery=cocoonsummary=truedescription=truebody=truetempMax=2 5reset=truedecorator=none Bugzilla provides iCal todo lists, not as versatile as RSS though. A good opensource bugzilla replacement seems to be Trac: http://projects.edgewall.com/trac/ Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Lepido][Contribution] Sitemap Debugger/Trace
Jens Maukisch wrote: Hi, as there seems to be a growing demand for some Cocoon debugging tools we (sn AG) want to jump in and help to develop a debugger infrastructure for Cocoon. snip/ With this contribution and our engagement we want to help the Lepido project to grow and to attract more developers and users. This is a very welcome contribution for which the (small) Lepido community is very thankful, and it's a pleasure to see people jump in. The plans for the Lepido debugger include of course the sitemap which is an essential part of every Cocoon application, but also other important components such as XSLT, JXTemplate or Rhino. It would therefore be good to work together on the unified debugger architecture mentioned in the Lepido proposal [1], merging your experience with the sunBow debugger together with our ideas and prototypes for an extensible debugger, that would also be based on Eclipse's generic debugger infrastructure. Thanks again for this contribution. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree view?
Thorsten Scherler wrote: On Sat, 2005-09-10 at 10:01 +0200, Sylvain Wallez wrote: Ralph Goers wrote: Does CForms provide any way of generating a tree view? I was looking at http://www.tonymarston.net/xml-xsl/xml-and-xsl-treeview.html and would like to do something similar, but I'd like to use CForms to do it. I would also like to not have to collect all the data for the whole tree, but only collect data when a node is expanded. That's exactly the purpose of the Tree widget that was added in trunk some time ago [1]. It has a lightweight tree model that loads data on demand. I will port this widget to 2.1 very soon. Hi Silvain, That's S*y*lvain :-) maybe I can help you, I need it in a project. ;-) How can I port it to 2.1? Are there some special thinks that I have to watch for? I'll do it if you don't mind as I planned to sync CForms in the coming days prior to integrating Max's work on form libraries. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Vary: Host in ResourceReader breaks IE
Hi all, I found an annoying thing today. The following straightforward sitemap statement, which is intended to download a zip file, leads IE to display an error message when the users tries to open Winzip from IE (saving the file on disk is ok): map:read src=foo.zip mime-type=application/x-zip-compressed/ After some protocol-level debugging, it appears to be caused by the Vary: Host header that is added by the ResourceReader, which leads to an error message in IE. This bug has been identified in 1999 [1]!!! Now it seems that this header was added to work around an IE cache bug [2] about which no details are given. So the fix to the unknown cache problem leads to falling into another IE bug. Can someone explain the reason for the Vary header? If not, I'd like to remove it so that downloads work again... Sylvain [1] http://archive.apache.org/gnats/4118 [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=14048 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Tree view?
Ralph Goers wrote: Does CForms provide any way of generating a tree view? I was looking at http://www.tonymarston.net/xml-xsl/xml-and-xsl-treeview.html and would like to do something similar, but I'd like to use CForms to do it. I would also like to not have to collect all the data for the whole tree, but only collect data when a node is expanded. That's exactly the purpose of the Tree widget that was added in trunk some time ago [1]. It has a lightweight tree model that loads data on demand. I will port this widget to 2.1 very soon. Sylvain http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111894513815242w=2 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[vote] Arje Cahn as a new Cocoon committer
Hi all, I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. Arjé has been using Cocoon for years and has taken the responsibility of organizing the upcoming GetTogether, which shows how much he cares for Cocoon and its community. And we value this a lot. This isn't the usual committer vote, since Arjé hasn't provided a lot of code patches. But quoting Stefano, committer means 'being committed to the project' rather than being able to commit code. There are some precendents for this: Matthew Langham and Andrew Savory were made committers, because we felt they were important citizens of the Cocoon community. The same applies to Arjé today. Please cast your votes! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [vote] Arje Cahn as a new Cocoon committer
Sylvain Wallez wrote: Hi all, I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. snip/ Please cast your votes! A warm +1! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
OSGi R4 draft documents published
http://osgi.org/osgi_technology/draft_download_specs2.asp?Accept=Accept They really should learn how to build non-bookmarkable clickthrough forms :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] Jorg Heymans as new committer
Jorg Heymans wrote: David Crossley wrote: Hi Jorg, just in case you don't know this already, all the information that you should need is at http://www.apache.org/dev/ good to know thanks. You should also know that any Cocoon committer can be a member of the PMC it he/she wants to. You just have to subscribe to [EMAIL PROTECTED] and send a I wanna be in the PMC message. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Proposal] Creating better portal urls
Carsten Ziegeler wrote: The current portal creates urls like ...portal?cocoon-portal-event=XXX for most links. There are some additional things in there, like the page labels and the bookmark action and some events can create more readable urls, but I think all of this has some disadvantages. Now, I'm currently thinking of providing a general mechanism that creates/uses real urls, like .../main/weblogs or .../main/applications without any additional parameter. So, how could this work. What do you think of using this URL scheme: .../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A So, in the example from above, the object with the id main gets an event with the information weblogs or applications. In this example main is the main tab and the information tells the tab to switch to that tab. But there is more, you can add as many events to the url: .../OBJECT_ID_A/EVENT_INFO_FOR_OBJECT_A/OBJECT_ID_B/EVENT_INFO_FOR_OBJECT_B... So the url consists of key value pairs creating more readable urls. For example: .../main/docs/page/news This url switches to the docs tab and passes the info news to the page coplet and this coplet then displays the news as its content. These urls are easily bookmarkable. Of course, for actions like minimizing etc. we still use url parameters. Now, to make this work objects have to be made aware of this mechanism. I'm thinking of some marker interfaces (with some functions) for layout objects and coplets. I have no concrete idea how to implement it, but I first want to discuss the idea before getting into implementation details :) How does this sound? Don't know much about the portal, but this proposal triggered a few thoughts. First of all, using path elements to identify objects and actions, and possibly allowing to have multiple pairs is likely to cause problems by forbidding the use of relative URLs for links, images, etc. A separator other than / would solve this. Now about bookmarking. You speak about sending events. Does it make sense to bookmark a URL that sends an event? What if the bookmark is displayed again later in a system state where that event doesn't make sense? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Niclas Hedhman wrote: On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. Problem is the interpretation of line ending. On Unix, it's 0x10 which can be part of a multibyte character in a file encoded in UTF-8. In such a case, although the file is a text file, setting the eol-style=native property may well break the file... Or is there a way to specify the encoding to SVN? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: cocoon 2 speech?
Ross Gardler wrote: [CC'd to Forrest] Stefano Mazzocchi wrote: came across http://freetts.sourceforge.net/ the first demo of cocoon that I ever did in public was a hello world page in html, pdf, svg and voicexml, with the little merlin dude speaking 'hello world' to the audience (got a standing ovation for that!) It always bugged me that I needed an external tool for that that worked only on windows... but I found this. Have no time, but it would be cool if somebody could write a voicexml-wav serializer using that (it's BSD). This really would be cool. Over on Forrest we have a whiteboard VoiceXML plugin (donated by a GSoC student who did not get an award but still got us started on the plugin, thanks HANAX). This plugin renders any Forrest page as voice XML. Currently it only works with VoiceXML enabled browsers (e.g. Opera on Windows), a serialiser would be great, even better if we can then stream the result. There's more to VoiceXML than just text-to-speech. You should have a look at JVoiceXML [1], a VoiceXML browser that uses Freetts. It's LGPL though. Sylvain [1] http://jvoicexml.sourceforge.net/ -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Event handling in form libraries
Max Pfingsthorn wrote: Hi! Okay, I see what you mean, but as a user of such a library, you have to be aware of what it requires. In my conception, the usecase you describe is not valid as you try to use only a part of an obviously connected set of widgets. You can do this, however you have to override the event handler in the inheriting widget. This would solve your problem just fine and allow for specifying complex widget structures in a library. I think we shouldn't impose restrictions on the use of libraries and specific parts of widgets within libraries. As long as it is fixable by adding a line or two in your definition and being a bit more aware of what you are inheriting from, this should be fine, right? Additionally, as Sylvain pointed out, there are valid uses of event handlers in top-level library widgets... i.e. on-change for an auto-completing text field via ajax (?). Aha, that was the kind of use case I was looking for :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: map:include
Mark Lundquist wrote: Hi, I have yet to use map:include, but now that I want it I get org.apache.avalon.framework.configuration.ConfigurationException: Element 'include' is not allowed at blah blah blah... I thought this was in 2.1.7... ? But there's no mention of it athttp://cocoon.apache.org/2.1/changes.html#version_2.1.7 It's in 2.2 only... I looked at components/treeprocessor/treeprocessor-builtins.xml, thinking it would have to be in there if it's supported, and didn't find it. But then, I didn't find it in BRANCH_2_1_X either, and then I didn't find it in trunk/ in sitemap-language.xml, which I presume replaces treemap-builtins.xml, either... (I don't really know anything about the sitemap implementation, I'm just grubbing around...) It's not handled by the treeprocessor, but by the CoreServiceManager which is configured with the contents of map:components. It's not a new sitemap instruction, which is why you haven't found it in sitemap-language.xml d'uh... what am I missing? Well, that's include that is missing :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Warped Text... (off topic)
Dirk-Willem van Gulik wrote:
On Fri, 2 Sep 2005, Pier Fumagalli wrote:
http://agylen.com/2005/05/16/captcha-validator-for-cocoon-forms/
Ciao,
Yep, but SVG IMVHO is quite overkill to generate a simple image...
For something really simple:
sub getBCD {
$_ = (123567,36,13457,13467,2346,12467,24567,136,1234567,12346)[ shift
@_ ];
return (((m/1/) ? ' _ ' : ' '),
((m/2/) ? '|' : ' '). ((m/4/) ? '_' : ' '). ((m/3/) ? '|' : '
'),
((m/5/) ? '|' : ' '). ((m/7/) ? '_' : ' '). ((m/6/) ? '|' : '
'));
};
map { my @r = getBCD($_); map { $out[ $_ ] .= $r[$_].' '; } (0 .. 2); } '3231'
=~ m/./g;
print join(\n,@out);
Just kidding.
Hey, nice to see you here!
As my perl is more than limited, I had to run it to understand what it
does. Brilliant :-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Saxon and cforms revisited
Antonio Gallardo wrote: Hi: I just wanted to do a test drive with saxon 8.5.1. I configured saxon in the current branch 2.1.8-dev (r267217 - 2005-09-02 09:54:23) . The system is able to process pages, when there is no cforms code inside. I was unable to see a simple cforms working. :-( I need to said that the whole system works perfectly with xalan. No errors at all. But with saxon it fails! The interesting thing is that saxon works without problems here: map:match pattern=test-a map:generate type=file src=a.xml/ map:transform type=xslt src=object.xsl / map:serialize/ /map:match Note, I saved the a.xml from the output of the original pipeline: map:match pattern=test-original map:generate type=jx src=pattern.xml map:parameter name=a value=1/ map:parameter name=b value=2/ /map:generate map:transform type=xinclude/ !-- Here I placed a xml serializer to get the a.xml file -- map:transform type=xslt src=object.xsl / map:serialize/ /map:match This pipeline fails with message: net.sf.saxon.trans.DynamicError: Cannot output a namespace node for the default namespace when the element is in no namespace In the xslt page the offending code is the last template matcher: xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template Somebody already met a similar trouble? Hmm... start/endPrefixMapping mess again? Can you place a LogTransformer after the JXTG (or CInclude) and see if there are any problems there? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Eclipse w/ 2.1.7
Mark Lundquist wrote: Jorg Heymans wrote: FWIW i still do build eclipse-project even build eclipse-customized-project. The latter sets up the source paths of the enabled blocks only Hey, that is great... next time I won't have to cut down .classpath by hand :-) Why doesn't the regular eclipse-project target do that? Why would anybody want source paths of excluded blocks on their classpath? Because when you develop Cocoon, you want to be sure that everything compiles even if your webapp doesn't include all blocks! -=-=-=-=- Here's another one, going a little OT I guess, but... :-/ I've set it up so that my Cocoon project is remote, it's not contained in my Eclipse project (there's a symbolic link to it). I have the Cocoon src dirs in .classpath, but just for debugging... I don't want them to compile when I build my project (but of course I _do_ want Eclipse to compile my project-specific Java sources...) Any idea how to set that up? You should simply associate the source code directory to cocoon.jar in your project: select a jar file, right-click and select properties/java source attachment. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Eclipse w/ 2.1.7
Torsten Schlabach wrote: Hi again, I'm going to test with 2.1.7... but can somebody clarify what was changed in in 2.1.8 to obviate the old way? Apparently in 2.1.8, the build.sh eclipse-project is no longer necessary? Anyway, if someone cares to provide some hints for me on this, I'd be glad to update the Wiki. I am not sure, but ... I think we are collectively making progress on this list in getting this sorted out. LOL :-) The fact that it's so difficult to build Eclipse with Cocoon shows how complicated its build system is :-) Personally, I use: - svn from the command line - eclipse-project to build .classpath and .project files - separate build (build.sh webapp) - separate launch (cocoon.sh servlet) - debug in Eclipse by connecting to a remote VM started using cocoon.sh servlet-debug. Finally, two more things to think about: - Many people have been reporting that they develop in Eclipse, but then run Cocoon outside as it is getting pretty slow otherwise. I would presume this is for memory reasons as Cocoon and Eclipse will share the same VM (with a -Mx=128M ???) if you run Cocoon inside Eclipse. I haven't found out how to give the VM that the Eclipse workbench is running in more memory upfront. AFAIK, when you launch a program from Eclipse, it creates a new VM. The reason why I personally have never launched Cocoon from Eclipse is that I have most of the time a Cocoon instance running on my laptop, whose lifecycle is thus decoupled from the lifetime of the IDE. - It might have advantages to run Cocoon inside Eclipse if we ever manage to make Eclipse write a class file to the appropriate location in the webapp and reload it inside Jetty. Imaging you are developing your own Cocoon component (Transformer, Generator). You make a code change, hit Save, the class gets compiled and re-loaded in Jetty and you can do straigt to your webbrowser, hit Reload there and thus test your component. Wouldn't that be fun? It is fun, and you have it *right now* in trunk :-) Just use the classpath-per-sitemap feature in trunk! Another way of speeding up roundrips when you need to restart Jetty is to use the ParanoidClassloader and give it a parnoid-classpath (in web.xml) that points to the directory where Eclipse writes class files. Here's my paranoid-classpath: class-dir: build/eclipse/classes lib-dir: build/webapp/WEB-INF/lib The only thing you've got to take care of (in 2.1.x, not trunk) is to delete cocoon.roles from build/eclipse/classes, so that the full one in WEB-INF/lib (containing all block-defined roles) is used. You then no more need build.sh webapp, unless you make changes in configuration files. Ah, and finally, I use the mount-table matcher a lot to directly test modifications in src/webapp without having to go through the build process. Here's my mount-table.xml: mount-table mount uri-prefix=forms/ src=../../src/blocks/forms/samples// mount uri-prefix=petstore/ src=../../src/blocks/petstore/samples// mount uri-prefix=test/ src=../../src/webapp/samples/test// !-- and a lot more, pointing to prototypes and projects on my HD, thus avoiding to copy Cocoon all over the place -- /mount-table Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Event handling in form libraries
Reinhard Poetz wrote: Sylvain Wallez wrote: - event handlers in libraries are allowed, but I don't think they make sense there (e.g. on-value-changed) Why not? A library may for example contain a group of related widgets with some interactions between them, e.g. a reusable car selector :-) [Moving this discussion between Sylvain, Max and me to cocoon-dev as it's of general interest] my wording was bad: I think they would make sense but I think the implementation is a bit difficult or at least this can cause strange errors. Maybe I'm wrong ... Here a simple example why I don't think that it can work with simply using the eventhandler code of the library in the form definition. LIBRARY libWidget1 has eventhandler that references libWidget2 libWidget2 FORM DEFINITION (imports above library) myWidget1 extends libWidget1 What happens now? The form doesn't has a reference to libWidget2. And if it had, how could the reference in the event handler code can work as it probably has a different name than libWidget2 or is reused several times in the form definition. Good point. We may allow on-change listeners in form libraries only in fields that aren't top-level, i.e. part of a group. Now aren't there any valid use cases where a field has an on-change that only acts on itself? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Cocoon in your phone!
Have a look here: http://www.topcom.net/products/product.php?groep=1cat=4catsub=9 ! :-P Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: locatable exceptions in trunk, exceptions in flowscript
Leszek Gawron wrote: org.apache.cocoon.ProcessingException: Sitemap: error calling continuation at map:call - file:/C:/dev/projects/pmt/server/build/webapp/central/sitemap.xmap:37:52 at map:mount - file:/C:/dev/projects/pmt/server/build/webapp/sitemap.xmap:535:77 The problem is the location in .js file is not given any more. Hmm... I'll have a look at it. What is causing the error? Is is a pure JS exception or an exception coming from a call to some Java code? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Warped Text...
Pier Fumagalli wrote: Did you look at what Ugo did with captchas? http://agylen.com/2005/05/16/captcha-validator-for-cocoon-forms/ Ciao, Yep, but SVG IMVHO is quite overkill to generate a simple image... Plus I suspect that the blurring algorithm is quite easy to recognize (in terms of running a simple image analysis package over the generated output). Just curious: what do you use to produce the image? If it's lighter and more efficient that SVG, we may simply consider using your stuff for the captcha widget. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Done. I think we should move all sitemap components, even the core ones into included files. This allows to have your application specific sitemap without worrying how to merge this when you update Cocoon. Great! I'll try to minimize the need for patching the web.xml in the next days as well. How do you plan to do this? We cannot add ourselves an include mechanism in web.xml :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.1.8, when?
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: My original idea was to release 2.1.8 after the GT, so announcing the code freeze the week after the GT and releasing one week later. In the last years, we had the famous bug hunt at the GT and fixed/improved several things. This year we have two days for the hackathon so we should be able to do even more. But we can release sooner if required; I think the current state is very stable. I think from 2.1.8 we should simply release every two months. So everyone (developers and users) have a fixed date. So this is a little bit more of agile development as we are using fixed sprints :) Of course if there are showstoppers we will make an exception. Although I agree with the general principle of shorter release cycles, we have to define a policy regarding new features introduced in these frequent releases and the associated contracts. Again, stable / unstable state, but at a finer intra-block level. Let's take an example with the new Location stuff. It's very cool and a lot of people will want to use it. However, we may not consider the API totally finished (there are still a few minor changes I'd like to do for it to be cleaner and more straightforward). What if we make a release now? The contracts will have changed a bit in the next release! So this leads back to a discussion we already had: marking some APIs as internal, so that people are warned that they should not base their code on it. The internal status can be used for things that are really internal (like all the environment handling stuff) and things that are fully functionnal (i.e. stable from a bug point of view) but on which we still reserve the right to do some modifications. Another solution of course would be to use branches, but this isn't very practical for fine-grained things like outlined above. Just some thoughts... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Sylvain Wallez wrote: I'll try to minimize the need for patching the web.xml in the next days as well. How do you plan to do this? We cannot add ourselves an include mechanism in web.xml :-) Oh, yes we *can* - we simply take Geronimo and require all users to use that and then we can patch our extensions into the servlet spec and finally get it right :) (Ok, this is just a joke) Now more seriously, it's already there. All the settings stuff I did in the core is just for this. We use POPFs :) (plain old property files) for this. POPF: I like this :-) See [1] for the introduction. Now I'm thinking of extending that mechanism to include several block specific property files. That was the point. We have a property lookup path, what we need now is this path to be able to include a dynamic set of property files, e.g. WEB-INF/block-*.properties. See also my response to Upayavira [2] which should show that using properties enables a lot of nice things. (Hopefully I succeeded there). And all this is still compatible with the 2.1.x way of doing things! Yup. And that can be a real bonus with OSGi where a bundle can expose these properties as its configufation, meaning the block will contain its complicated xconf file but only expose to the user those parts whose configuration really makes sense, such as paths, jdbc urls, simple boolean flags, etc. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.1.8, when?
Carsten Ziegeler wrote: Sylvain Wallez wrote: Although I agree with the general principle of shorter release cycles, we have to define a policy regarding new features introduced in these frequent releases and the associated contracts. Again, stable / unstable state, but at a finer intra-block level. Let's take an example with the new Location stuff. It's very cool and a lot of people will want to use it. However, we may not consider the API totally finished (there are still a few minor changes I'd like to do for it to be cleaner and more straightforward). What if we make a release now? The contracts will have changed a bit in the next release! So this leads back to a discussion we already had: marking some APIs as internal, so that people are warned that they should not base their code on it. The internal status can be used for things that are really internal (like all the environment handling stuff) and things that are fully functionnal (i.e. stable from a bug point of view) but on which we still reserve the right to do some modifications. Another solution of course would be to use branches, but this isn't very practical for fine-grained things like outlined above. Yepp, that's all true and we agreed several times to mark the api, but unfortunately it never happened :( With your location stuff, I think the api changes effect only java developers, so I think we can even release the current state and change things there later on. Hmm... Java APIs are our contracts also... Now, if we have a fixed schedule (every two months), people know that they have to finish new work before the next release and they know when this release will be. This does not solve the problem you describe, but it might lessen it a little bit. That's right. And at the very end, some unfinished features (API-wise) can be temporarily removed to make the release and re-added afterwards. Ok, so, what about just marking those new editions with TODO or NOT FINISHED or whatever? editions? Do you mean the new features? Yes, that's the idea: put on them a special flag so that people know that these are used internally but that they should not have their code depend on them. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.1.8, when?
Daniel Fagerstrom wrote: Andrew Savory wrote: Sounds good ... the problem we have currently with ship it when it's ready is we rarely agree on when it is ready ;-) The only thing I'm wondering about is if every two months isn't a little fast for the current rate of change in the 2.1* series? A main point about shipping every second month is that we create a habit to deliver regulary and in time and that we will improve our routines so that we make it easy to do the shipping and assesing the quality of the release. If not that much have happened since the last release, it will make it easier to ship the next one and it makes it less dramatic for the users to uppgrade. Currently when we ship rather selldom, people want to do a lot of last minute additions as they know that they have to wait half a year to make it part of a relase otherwise. These additions makes testing harder and makes the deadlines slip. Furthermore the only way to make features really stable is to release them and get real usage, user feedback, bug fixes and extensions on them. These are really very good points. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r264119 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java src/java/org/apache/cocoon/transformation/CIncludeTransformer.java stat
Carsten Ziegeler wrote: Vadim Gritsenko wrote: a) what exactly do you want to revert? Both parts? Ideally, both. Change to CIncludeTransformer sounds more offending, though. I still don't get why, really. But actually I don't care and will remove it from CInclude transformer just to keep you happy. Me too will be happy :-) b) where is a working solution that fills the gap then? If you add couple of lines to that one, yes: http://issues.apache.org/bugzilla/show_bug.cgi?id=30018 Hmm, wasn't it you who said that it's better to split up the functionality (separation of concerns). So removing comments is imho a different concern as cleaning up. That was me! We can consider that the concept of cleaning an XML stream can be split into several different tasks, which include stripping comments and correcting whitespace. We may want these subtasks to be all active by default and disable some of them through configuration or parameters though. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.1.8, when?
Ralph Goers wrote: Sylvain Wallez wrote: Although I agree with the general principle of shorter release cycles, we have to define a policy regarding new features introduced in these frequent releases and the associated contracts. Again, stable / unstable state, but at a finer intra-block level. Let's take an example with the new Location stuff. It's very cool and a lot of people will want to use it. However, we may not consider the API totally finished (there are still a few minor changes I'd like to do for it to be cleaner and more straightforward). What if we make a release now? The contracts will have changed a bit in the next release! Just update the Javadoc to say what you want to say. If it isn't completely stable yet just try to make sure it doesn't stay that way for too long. That's the point: periodic releases may clash with ongoing development, meaning an interim state for one release. Now as Daniel rightly pointed out, having fixed dates will likely change our developer habits. So this leads back to a discussion we already had: marking some APIs as internal, so that people are warned that they should not base their code on it. The internal status can be used for things that are really internal (like all the environment handling stuff) and things that are fully functionnal (i.e. stable from a bug point of view) but on which we still reserve the right to do some modifications. Internal to me means that no application should ever use it and that it might be removed at a future time. What you have described is more along the lines of under development or in testing. i.e. use at your own risk. Right, but making it internal is stronger as it means don't use it, as internals can change also without notice. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Releasing 2.1.8, when?
Ralph Goers wrote: Sylvain Wallez wrote: Ralph Goers wrote: Internal to me means that no application should ever use it and that it might be removed at a future time. What you have described is more along the lines of under development or in testing. i.e. use at your own risk. Right, but making it internal is stronger as it means don't use it, as internals can change also without notice. That is fine if it accomplishes what you want it to. I got the impression that your position with the location stuff was more of a use at your own risk as this isn't fully completed - but I would like your feedback. Ah yes. Oh damn, how difficult it is to ask people to test new features while still warning them that they should nor rely on it!!! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
cocoon.exit()
Team, I have added the cocoon.exit() function to the flowscript API as was discussed in [1]. This will avoid the FOM_Cocoon.suicide() calls I see in our projects, which is a non-public API :-) Sylvain [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200503.mbox/[EMAIL PROTECTED] -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Can't this be handled by wildcard inclusion from component configurations in some catalog, so that we get rid of the snippet insertions. SNIP/ We can use wildcard inclusion in the main sitemap as well. So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf Oh yes, for sure! The more we can avoid xpatch the better IMO. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. Is your employer (or someone else) ready to pay 2 weeks of work for having a stable CForms? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r264119 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java src/java/org/apache/cocoon/transformation/CIncludeTransformer.java stat
Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: Add possibility to remove comments to all text based serializers and to cinclude transformer. Do you really think serializers and cinclude transformer are a good place for additional xml filtering logic? What if you want to indent included xml - is it good idea to add this code into serializers include transformer too? Or if you want to drop all the whitespaces. Etc ad infinitum. I'd think that separate filtering / cleaning transformer is a much cleaner approach. WDYT? +1. Otherwise, we'll end up duplicating the cleaning code (or the use of a common class) all over the place. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: VariableResolver
Ralph Goers wrote: I'm a little confused. In treeprocessor we have class NOPVariableResolver class PreparedVariableResolver class VariableResolver class VariableResolverFactory In the portal block we have class DefaultVariableResolverFactory class NOPVariableResolver class PreparedVariableResolver interface VariableResolver interface VariableResolverFactory I need to use the VariableResolver in a class I am working with and I'm a bit confused. I've used it before, but in the portal block so I guess I was using that one. Does the treeprocessor version only work when called from the sitemap? The code I am working on does not need the portal block but isn't called from the sitemap. AFAIU, the version in Portal is a componentized copy of what's in the TreeProcessor which uses static factory methods. However, looking at it, it looks it missed some updates in the TreeProcessor related to nested variables. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Repost from users list: Cforms Repeater - Cancel delete action via javascript
Christoph Hermann wrote: Hello, i originally posted this question on the users list some time ago, but nobody did respond. After some discussion on freenode/#cocoon i decided to mail the dev list. So i'm asking you: Is there a way to cancel a repeaters delete-row action in case a certain condition is met? I tried to put a javascript return false; in the on-action, but this throws an error. (Invalid return) I think there should be a simple way to prevent the action to be performed, but i did not find anything in the docs. In the docs there is only mentionned that the on-action is performed before the delete-row. What i basically want to do is disable the deleting of rows that are still referenced somewhere. I.e. you have two xml documents which reference each other and you cannot delete a parent-row if there are still children in another document referencing this element. I'd be very happy if someone of you could help me with this. Hmm... the delete-row action accepts additional listeners, but those are not supposed to be able to cancel the action. The Invalid return error you get is because the on-action is a script snippet that has no return value. To achieve what you want, you should use a plain action widget with an on-action that surrounds the row deletion with the filtering logic. Deleting a row is rather straightforward, and here's the code behind the delete-row widget: Repeater.RepeaterRow row = Repeater.getParentRow(event.getSourceWidget()); Repeater repeater = (Repeater)row.getParent(); repeater.removeRow(repeater.indexOf(row)); Which translates to JS as: var row = org.apache.cocoon.forms.formmodel.Repeater.getParentRow(event.source); var repeater = row.parent; repeater.removeRow(repeater.indexOf(row)); Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Repost from users list: Cforms Repeater - Cancel delete action via javascript
Christoph Hermann wrote: Sylvain Wallez schrieb: Hello, So i'm asking you: Is there a way to cancel a repeaters delete-row action in case a certain condition is met? Hmm... the delete-row action accepts additional listeners, but those are not supposed to be able to cancel the action. The Invalid return error you get is because the on-action is a script snippet that has no return value. ---snip from #cocoon--- timlarson_ Guschtello: I see Sylvain gave the same answer, plus a code snippet :) timlarson_ Does it work for you? ... Guschtel_ So i implemented it using a simple fd:action works fine, but i thought there would be a better way :) Guschtel_ works fine, but i thought there would be a better way :) ... timlarson_ Yes, it seems like the cocoon code should be changed to allow the way you tried first...you might want to send an email to that effect to the dev list, if it bothers you much. ... timlarson_ sylvain did not seem to catch the idea that the cocoon code should be changed, just that your first try would not work with the current code. Guschtel_ You mean i should repost to make him rethink about it? ,) ---snap--- Maybe the Cocoon Code c(sh)ould be changed to make this possible? Imho it would be very natural to allow the javascript to cancel the action. And it shouldn't be too difficult to implement this. I thought about it as well, but it's not as easy as it seems though. The moment where the event listeners are called depends on the action type (see [1]): *before* row deletion in the case of delete-row and *after* row addition or move for other row-actions. The general idea (for all actions all but delete) is that event listeners are called when the repeater is in its target state (i.e. after acting), wereas it was considered useful for deletion event listeners to be able to get some data from the row before it was deleted. So allowing event listeners to cancel the action would require to change this behaviour, which was designed to allow listeners to take complementary actions to the main one. In the end, my opinion is that if conditional action is needed, then it's better to write the few corresponding lines in a regular fd:action that has no built-in behaviour like row-actions and repeater-actions do. Sylvain [1] http://cocoon.apache.org/2.1/userdocs/forms/widget_repeater_action.html -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: VariableResolver
Carsten Ziegeler wrote: Sylvain Wallez schrieb: Ralph Goers wrote: I'm a little confused. In treeprocessor we have class NOPVariableResolver class PreparedVariableResolver class VariableResolver class VariableResolverFactory In the portal block we have class DefaultVariableResolverFactory class NOPVariableResolver class PreparedVariableResolver interface VariableResolver interface VariableResolverFactory I need to use the VariableResolver in a class I am working with and I'm a bit confused. I've used it before, but in the portal block so I guess I was using that one. Does the treeprocessor version only work when called from the sitemap? The code I am working on does not need the portal block but isn't called from the sitemap. AFAIU, the version in Portal is a componentized copy of what's in the TreeProcessor which uses static factory methods. However, looking at it, it looks it missed some updates in the TreeProcessor related to nested variables. Yepp, it's an older copy - it would be great if we would have just one version of the code, so I think moving the code from the portal to the core and using it in the tree processor as well would be the better choice. Sure, it totally makes sense. Now I'm wondering if we really need this to be components. Will there ever be more than one implementation? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r264119 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java src/java/org/apache/cocoon/transformation/CIncludeTransformer.java stat
Carsten Ziegeler wrote: Vadim Gritsenko wrote: [EMAIL PROTECTED] wrote: Add possibility to remove comments to all text based serializers and to cinclude transformer. Do you really think serializers and cinclude transformer are a good place for additional xml filtering logic? Yepp, that's why I added it there :) What if you want to indent included xml - is it good idea to add this code into serializers include transformer too? Ok, this depends - but how can you indent included xml if not the include transformer does it? You don't want to put the indentation in the included pipeline and a transformer behind the include transformer does not know what has been included and what is from the current pipeline. Anyways, I have the use case to remove comments from included documents and the only working way is to add this to the cinclude transformer. If there are better ways, fine, we can change this. Can't you add this filtering logic in the included URI? In addition I thought that it is a good idea to remove all comments from the resulting html page (with the possibility to leave a document comment at the top of the page). Sometimes comments inside a html page reveal internal information that you don't want to send to the client and removing comments reduces the size of the doc. Without virtual serializers it would be annoying to have a remove-comments-transformer before every html serializer. And I don't think that it would make sense to write such simple transformers just because of architectual elegance. Is it architectural elegance, or separation of concerns which leads to have each component to a single task so it can be reused in a number of different contexts? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Repost from users list: Cforms Repeater - Cancel delete action via javascript
Christoph Hermann wrote: Sylvain Wallez schrieb: Hello, Maybe the Cocoon Code c(sh)ould be changed to make this possible? Imho it would be very natural to allow the javascript to cancel the action. And it shouldn't be too difficult to implement this. I thought about it as well, but it's not as easy as it seems though. The moment where the event listeners are called depends on the action type [...] So allowing event listeners to cancel the action would require to change this behaviour, which was designed to allow listeners to take complementary actions to the main one. In the end, my opinion is that if conditional action is needed, then it's better to write the few corresponding lines in a regular fd:action that has no built-in behaviour like row-actions and repeater-actions do. Yes your right, but thing is that the action does not trigger the validation process. I tried form.validate() and form.endProcessing(true); and didn't success, and i don't have the time atm to investigate this any further. What i'd like to do is to trigger a validationError if the wrong row shall be deleted. Then you can simply call someWidget.setValidationError(...) from within your event listener. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Repost from users list: Cforms Repeater - Cancel delete action via javascript
Christoph Hermann wrote: Sylvain Wallez schrieb: Hello, Yes your right, but thing is that the action does not trigger the validation process. I tried form.validate() and form.endProcessing(true); and didn't success, and i don't have the time atm to investigate this any further. What i'd like to do is to trigger a validationError if the wrong row shall be deleted. Then you can simply call someWidget.setValidationError(...) from within your event listener. Well this is actually what is not working. If i do a repeater.setValidationError(...); in my normal action, i do not get any validation error (as written in the docs: When an action widget was activated, validation will not be performed. ...). Well, although a repeater, as every widget, can have a validation error, there's no associated presentation defined for it in the styling stylesheets, which explains why you don't see the error! You should either set the validation error on a field (which knows how to display it) or add a ft:validation-error id=myrepeater/ somewhere in the page template. Even when calling form.validate(); (This is what i did). form.validate() validates the whole form by calling each widget's validators. This isn't what you want to do here. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r264119 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/serialization/AbstractTextSerializer.java src/java/org/apache/cocoon/transformation/CIncludeTransformer.java stat
Carsten Ziegeler wrote: Sylvain Wallez wrote: Can't you add this filtering logic in the included URI? No, e.g. cinclude:include src=http://some-service-host/service/a/ Well, I won't rephrase Vadim here :-) Is it architectural elegance, or separation of concerns which leads to have each component to a single task so it can be reused in a number of different contexts? Or FS? :) Despite the smiley, I strongly disagree here. FS is when one wants to add too much features to a single component, which leads it to be overly complicated in code, configuration and usage. What we need here is a simple transformer that does a very specific task on the SAX stream, and that can be used wherever that task is needed, which can be at any place in a pipeline: after a transformer, before a serializer or why not after a generator to cleanup files. So it's not FS, but a simple but useful transformer. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: VariableResolver
Carsten Ziegeler wrote: Sylvain Wallez wrote: Sure, it totally makes sense. Now I'm wondering if we really need this to be components. Will there ever be more than one implementation? The current implementation in the treeprocessor is not usable outside the treeprocessor (at least it wasn't at the time the portal needed it). Don't know when you added it to the portal, but I've been using it here and there (e.g. CVSSource) for a very long time. Anyway... Now the variable resolver needs some infrastructure (mainly the service manager), therefore it could make sense to make a component out of just because of this. That's a good point. Having to pass the service manager and object model around is a pain and may justify componentization. However, that component would be declared in cocoon.xconf (or even cocoon.roles) when it may need components defined locally in the current sitemap (e.g. input modules). How can we solve that? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: JING Transformer...
Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). Is there interest to have it in Subversion? Definitely +1. (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soon :-) Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? I should also be able to commit some time in the second half of September to hopefully close the main remaining points for CForms stabilization. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Repost from users list: Cforms Repeater - Cancel delete action via javascript
Christoph Hermann wrote: Sylvain Wallez schrieb: Hello, Then you can simply call someWidget.setValidationError(...) from within your event listener. Well this is actually what is not working. If i do a repeater.setValidationError(...); in my normal action, i do not get any validation error (as written in the docs: When an action widget was activated, validation will not be performed. ...). Well, although a repeater, as every widget, can have a validation error, there's no associated presentation defined for it in the styling stylesheets, which explains why you don't see the error! Okay. Thanks for your help so far. I get the validation Error displayed, but not correctly: repeater.setValidationError(new Packages.org.apache.cocoon.forms.validation.ValidationError(general.field-required,false)); This is ok, but the error displays as . When i try to enable i18n: repeater.setValidationError(new Packages.org.apache.cocoon.forms.validation.ValidationError(general.field-required,true)); OR repeater.setValidationError(new Packages.org.apache.cocoon.forms.validation.ValidationError(someString)); i get: ---snip--- org.apache.cocoon.transformation.I18nTransformer: nested i18n:text elements are not allowed. Current state: 10 org.apache.cocoon.ProcessingException: Error executing pipeline.: org.xml.sax.SAXException: org.apache.cocoon.transformation.I18nTransformer: nested i18n:text elements are not allowed. Current state: 10 ---snap--- I copied a Stacktrace to the end of this message. Wow... are you sure you don't have a surrounding i18n:text in your template? What shows up if you place an XML serializer right before the i18n transformer? Even when calling form.validate(); (This is what i did). form.validate() validates the whole form by calling each widget's validators. This isn't what you want to do here. I thought (referring to the docs) that no validation takes place when submitted via a normal action. This is why i wanted to trigger the whole Form validation. Yes, no validation takes place with actions. And validating the form is not what you want here! What you want is to give some feedback explaining why the action cannot be performed in this case. So in that case, the validation error is actually a message, which makes me think that it may actually not be the right solution: this is more a job for fd:message whose value is reset at each form interaction, making it therefore suitable for transient information like is the case here. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Paths in sitemap
Robert Goene wrote:
Hi,
I need to retieve the absolute path of the lenya directory in a
sitemap. I cannot use the context:// protocol, because i have to pass
the directory as a parameter. Is there any way i can determine the
absolute path?
Try using {realpath:}
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: flowscript calls from sitemap: named param association
Mark Lundquist wrote:
Hi gang,
For this...
map:call function=foo
map:parameter name=something value=X /
/map:call
we deprectated this...
function foo (something) {...}
and now require this:
function foo() {
var something = cocoon.parameters['something'];
}
IIRC this was because the sitemap syntax suggests named parameter
association, which is misleading because the actual parameter
association is positional, and this was a source of errors.
Looking at the Rhino a little bit... isn't it true that any flowscript
function called from the sitemap is going to be an instance of
org.mozilla.javascript.InterpretedFunction — not just BaseFunction?
If so, then there are methods we can use to obtain the formal
parameter name for each parameter of the function (by position).
Wouldn't that let us implement real named parameter association in
FOM_JavaScriptInterpreter.callFunction()? Then we could restore the nice
function foo (something)
form.
Thoughts?
Hmm... this nice feature comes with a price: reliance on the internals
of the current Rhino, which may change without notice. Furthermore,
JavaFlow doesn't support this.
So a -1 for this...
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Another sitemap component HOWTO ready
Berin Loritsch wrote: How to Create a Reader: http://cocoon.zones.apache.org/daisy/documentation/components/sitemapcomponents/681.html I hope others proof what I've written because it is largely based on a combination of memory and implementation details as I update my knowlege base. I want to make sure I'm not disseminating anything patently false. This will be my last installment before I go on vacation next week. The earliest I can get to the Generator, Transformer, and Serializer components will be after Sept. 5. Enjoy Great work Berin! We should also integrate what I wrote at http://wiki.apache.org/cocoon/WritingForCacheEfficiency Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: caching pipeline and SourceValidity
Max Pfingsthorn wrote: Hi! I'm a bit confused with the source validity coming from a cocoon caching pipeline. Apparently, there is none, so it doesn't make it into the cache in Cocoon Forms. I ran into this problem developing my library cache. If I gave the source resolver a filesystem path, it was fine. If I gave it a uri with the cocoon protocol which pointed to a caching pipeline (org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline), source.getValidity() was null. Did I do something wrong? A caching pipeline can return a null validity if one of its components is not cacheable. What's in the pipeline you point to? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Thorsten Scherler wrote: On Thu, 2005-08-18 at 20:13 +0200, Sylvain Wallez wrote: Hi all, I just committed the Cocoon stacktraces stuff to trunk. Cheers. Especially for forrest ;-) Ah, and this includes also the update to TraxTransformer that no more eats downstream exceptions. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Carsten Ziegeler wrote: Current I can't compile trunk. It seems that this class is missing: org.apache.cocoon.util.location.LocatorToAttributesPipe; Sorry, I forgot to commit DomHelper in CForms (I guess this is where you have the error). Having different ongoing works in the same checkout isn't always easy to manage ;-) Anyway, this should be fixed now. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote: Il giorno 18/ago/05, alle 20:13, Sylvain Wallez ha scritto: I just committed the Cocoon stacktraces stuff to trunk. Neato! There's just a small problem in this. Apparently, the exception2html.xslt stylesheet is not compatible with Saxon8. I will try to investigate the issue and maybe come up with a fix later. Hmm... nothing fancy in this XSL, except the use of exslt... It was quickly hacked though, so if you can come up with something nicer, just do it! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[FYI] followers :-)
http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
More Ajax in Cocoon (was Re: [FYI] followers :-))
Ugo Cei wrote: Il giorno 19/ago/05, alle 11:34, Sylvain Wallez ha scritto: http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. At least, the demos do. I'm wondering whether we could reuse something for CForms. The icons and the CSS? I also started looking at integrating Scriptaculous [1] and Rico's LiveGrid [2] in Cocoon, but as always it requires to dedicate time, i.e. finding a project that needs it. Scriptaculous is RoR's Ajax library and it uses a very similar approach to CForms, by sending HTML snippets for partial page updates rather than requiring large amounts of client-side application-specific logic. Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. WDYT? Sylvain [1] http://script.aculo.us/ [2] http://openrico.org/rico/livegrid.page -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [CFORMS] onsubmit called twice! with text field and @submit-on-change
Josep A. Frau wrote:
I have a text field with submit-on-change and a submit button on my form:
fd:field id=P_CODPOS
fi:styling submit-on-change=true/
fd:labelC.P./fd:label
fd:hintCodi Postal/fd:hint
fd:datatype base=string/
fd:on-value-changed
javascript
...
/javascript
/fd:on-value-changed
/fd:field
fd:submit id=B_MODIFICA_PERSONA validate=true
fd:labelModificar dades/fd:label
/fd:submit
I get an alert with the message onsubmit called twice! when change
the field value and, before leave the field, push the submit button.
The same occur if I change the value of P_CODPOS and press Enter key
for submit the form.
When the field is a selection list this behavior can occur too. If I
change value and push the submit button quickly but its more
improbable the user make it voluntarily.
I have tested in Cocoon 2.1.7 with Firefox 1.0.6 and Explorer 6.0.
Is that the wished behavior?
In the forms-lib.js there is the function forms_onsubmit():
function forms_onsubmit() {
if (forms_onsubmitHandlers == null) {
alert(onsubmit called twice!);
}
for (var i = 0; i forms_onsubmitHandlers.length; i++) {
forms_onsubmitHandlers[i].forms_onsubmit();
}
// clear it
forms_onsubmitHandlers = null;
}
This function is called each time a submit is fired. The first time is
fired by the onchange event of P_CODPOS field and later the event of
submit button.
In any case, I think that this behavior of the user is possible. Must
the user see this message? It's safe just:
if (forms_onsubmitHandlers == null) {
return;
}
This don't show the alert, but follow the submit process.
This occurs because the click on the button triggers both the input's
onchange and the form submit. I'll fix this.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Ugo Cei wrote: Il giorno 19/ago/05, alle 14:25, Sylvain Wallez ha scritto: Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. What I find interesting is being able to proocess XForms on the client without plugins, applets or other proprietary extensions. Like it or not, XForms is becoming more popular and having XForms support in Cocoon means that fewer people will look somewhere else when they learn that Cocoon has a proprietary forms framework, even if it currently is the best around. Ah ok, I thought it was about the feature showcased in the demos. Being enthusiast about Ajax, I think the best way to support XForms in a browser is to use that (or the next version of Firefox, when it will have native support for XForms/SVG/etc.). Since the implementation in OPS is Open Source (AFAIK), it might be worthwhile to take a look at it. There's also Chiba which has Cocoon integration. I don't know its status though. Something that may be worth investigating also is a XForms-CForms translator. Could this be a bunch of XSLs? Of course, this means having another 12 hours extra per day, in addition to the 36 we all already need. ;-) I personally would like 42 hours a day (H2G2 just went out in theaters here) :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Ralph Goers wrote: I'd move it out if keeping it in is going to keep CForms from being marked stable in 2.1.8. This has actually no relation with Ajax being in core or in a separate block. Sylvain Wallez wrote: Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. WDYT? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote:
On Aug 19, 2005, at 11:23 AM, Sylvain Wallez wrote:
Ugo Cei wr
Hmm... nothing fancy in this XSL, except the use of exslt... It was
quickly hacked though, so if you can come up with something nicer,
just do it!
Here's the error I get:
Error on line 61 of file:/Users/ugocei/Projects/Pulse/src/webapp/
stylesheets/exception2html.xsl:
Cannot find a matching 2-argument function named {http://exslt.org/
strings}split()
Transformation failed: Run-time errors were reported
Actually, the line with split seems to be 60 and not 61:
xsl:for-each select=str:split(ex:message, '#10;')
Which looks kosher according to http://exslt.org/str/functions/split/
index.html but Saxon does not support the EXSLT string module, it
seems: http://exslt.org/str/functions/split/index.html
The extlt.org page is outdated, but the Saxon doc is clear about that:
http://www.saxonica.com/documentation/extensions/exslt.html
Too bad, the string module in exslt is my favourite :-(
The only compatible solution I see is replacing the call to str:split
with a recursive template. I'm not sure this is worth doing, as I can
work around the issue by using Xalan in my error pipelines.
WDYT?
Well, standard is the way to go as we can't assume everybody will want
to deploy Xalan just to have error pages.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: On Friday 19 August 2005 17:29, Jorg Heymans wrote: Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/ That does not seem to work either :-( Why? These are plain tgz files... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote: Il giorno 19/ago/05, alle 16:03, Sylvain Wallez ha scritto: Well, standard is the way to go as we can't assume everybody will want to deploy Xalan just to have error pages. Hmmm, I have a better idea, inspired once again by the Orbeon folks (don't whine, it was you who pointed to http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ first ;-) ). Why don't we modify the Exception generator so that, instead of outputting the Java stacktrace as a text, we do a getStackTrace on the exception, traverse the returned array of StackTraceElement's and for each one we output a ex:stackTraceElement having ex:className, ex:methoName, etc. as children? This would give us much more flexibility in presenting stacktraces, without having to convert newlines into brs and such silliness. For sure the ops stracktrace has more eye-candy at first look, but the experience shows that it often happens that Java stacktraces are copy/pasted to be send by mail or IM (happens to me at least once a day). I'm not sure a fancy html layout would survive this. And well, converting br isn't that hard. I just committed an updated version that no more uses exslt, so Saxon will be happy. Only problem, Throwable.getStackTrace was introduced in 1.4, AFAIK. So we could do this for trunk only, unless there's another method to get to the same info. Yup. That would mean either more code for JDK 1.3 compatibility or different DTDs in branch and trunk. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Jeremy Quinn wrote: On 19 Aug 2005, at 13:25, Sylvain Wallez wrote: snip/ Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. I already have a desire to separate the BrowserUpdate and DOMUtils JavaScript Objects out of cforms.js, as I am using them outside the context of CForms. I can add (either to the wiki, or as a sample in a new AJAX Block) a JX Macro and JS file (TimedBrowserUpdate) that allow you to have regions of your page update in the background using BrowserUpdate on a periodic basis, if there are changes in the underlying data. We are using it to update the user on the status of asynchronous processes. Yes, yes, please do :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
