Re: document('file.xml') and entity resolver
This issue has been raised a number of times, most recently
on the users list a few days ago [1].
Even though the use of document() function is not ideal,
it should still be supported.
The bug seems to show that the catalog entity resolver
is not being used via whatever parser that reads the
included xml document.
The xml parser that is used to read the xslt file itself is fine
- see the test described at [1].
I am trying to do some research into the problem but have not
made much progress yet.
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=108242715027646
--David
Juan Jose Pablos wrote:
Hi there,
I am just wondering if on a transformation say:
map:transform src=welcome.xslt
Added this line:
xsl:value-of select=document('book-cocoon.xml')/
to load this file:
[EMAIL PROTECTED]:~/xml/cocoon-2.1/build/webapp$ more book-cocoon.xml
?xml version=1.0?
!DOCTYPE book PUBLIC
-//APACHE//DTD Cocoon Documentation Book V1.0//EN
book-cocoon-v10.dtd
book/
should resolve that DTD, or this exception is normal:
WARN(2004-04-24) 22:44.04:492 [core.xslt-processor] (/)
PoolThread-4/TraxErrorHandler: Error in TraxTransformer:
file:/home/cheche/xml/cocoon-2.1/build/webapp/welcome.xslt; Line 7;
Column 59;
; SystemID: file:/home/cheche/xml/cocoon-2.1/build/webapp/welcome.xslt;
Line#: 7; Column#: 59
javax.xml.transform.TransformerException: No se puede cargar el doc
solicitado: /home/cheche/xml/cocoon-2.1/build/webapp/skinconfig-v06.dtd
(No such file or directory)
Thank you!
Cheers,
Cheche
[REMINDER] IRC Meeting - 10:00 AM EST Sunday 25 2004
A very late reminder!! Date: Sunday 25 2004. Time: 14:00 UTC Place: irc.freenode.net Agenda: * The Proposal of Gang of Nine - Move ECM+Fortress to CodeHaus. * The Counter-proposal of Niclas Hedhman - Merlin TLP Here is the schedule of what this means in other time zones. http://www.timeanddate.com/worldclock/fixedtime.html?day=25month=4year=2004hour=10min=0sec=0p1=179 Quicklist (non-authorative); 07:00 San Francisco 10:00 New York 14:00 UTC 16:00 Paris/Berlin 22:00 Singapore/HongKong 23:00 Tokyo 24:00 Sydney See you all on IRC!!! Note; This invitation is sent to; [EMAIL PROTECTED] - Primary list [EMAIL PROTECTED] - Some users have expressed their interest. [EMAIL PROTECTED] - Perhaps wants to monitor what we are trying to solve. [EMAIL PROTECTED] - Cocoon being one of the major users of Avalon. Gang Of Nine - Invited explicitly, since they raised the Proposal under discussion. Cheers Niclas -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+
Re: JXTG jx:attribute
On Sat, Apr 24, 2004 at 04:51:35PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Sorry to bother you privately but I did not get the answer on cocoon group
and
I see you're the main JXTG developer.
My question is: Is there any real reason that jx:attribute is not
implemented?
Something that would work as xsl:attribute or xsp:attribute to allow
generation of dynamic content of an attribute?
lg
Please direct all questions to the dev list. The only reason is that it
seems hard to implement it efficiently. Consider:
foo
jx:attribute name=bar namespace=http://www.bar.org; value=${bar}/
jx:if test={$fubaz 1}
jx:attribute name=xyz value=100/
/jx:if
jx:forEach var=item items=${items}/
jx:attribute name=${item.name} value=${item.value}/
/jx:forEach
...
/foo
The start element event for foo must be buffered until all potential
jx:attribute tags have been processed. Since these are within
conditional blocks and loops determining when that is the case in an
efficient way isn't easy.
It looks like you have to buffer foo until you reach another startElement or
get a endElement for /foo.Am I missing sth?
lg
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/generation JXTemplateGenerator.java
Il giorno 24/apr/04, alle 23:35, [EMAIL PROTECTED] ha scritto:
coliver 2004/04/24 14:35:35
Modified:src/java/org/apache/cocoon/generation
JXTemplateGenerator.java
Log:
Allow a nodeset to be returned as the result of xpath evaluation
Before this change, I had a template which contained something like the
following:
jx:forEach select=#{/docs}
#{.}
/jx:forEach
where docs was passed from flowscript as an array of DOM objects. The
template serialized all the DOMs. Now, it does not work anymore. After
a few trials and errors, I was able to make it work again by changing
it to:
jx:forEach select=#{/docs}
#{*}
/jx:forEach
Is this an expected side-effect of the change? Can you explain why the
former version does not work anymore?
Ugo
CForms flowscript API musings
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
* allows to add custom code to be executed before the form is displayed,
and before a form submission is processed. This last one is useful for
multiple things:
- adding checks to see if the user is allowed to submit the form
at this moment (could be disallowed if he/she has gone
forward/backward in the flow and changed stuff on another form)
- if multiple forms were put on the page, allows to check using
eg a request attribute which form submission should be
processed.
- or more generally, it allows to put other links on the page
pointing to the same continuation but causing something else to
be done then processing the form submission.
* allows to use sendPage instead of sendPageAndWait for stateless
applications.
For convenience we could still leave the form.showForm() function, but
make its content as simple as the one above.
Custom validation
=
The current CForms flow API's allow to specify a javascript function
that will be called to do custom validation. However, there seems to be
a problem with this.
Normally, it is the (java) form.process() method that will handle the
different stages of a form submission, which simplified is as follows:
- widgets read values from request
- events generated by this are processed
- widgets are validated *if needed*
(see also http://cocoon.apache.org/2.1/userdocs/forms/eventhandling.html
for the full cycle description)
Note the if needed for the validation: it could be that validation
must not be triggered, e.g. when an action widget has been activated.
However, the additional flowscript validation function seems to be
called always.
Since we now have the generalized concept of WidgetValidators, I propose
we use those to plug in the custom validation. In this way, the custom
validation will automatically be peformed as part of the normal form
processing cycle. WidgetValidators are currently however only part of
the WidgetDefinitions, we could make it possible to define additional
ones on the instances.
The same should probably be done for event handlers. Currently the v2
API works around this limitation by using the FormHandler to allow to
add instance-specific event handlers.
Multiple bindings
=
A simple one, but often requested on the user mailing list: it should be
possible to use multiple bindings with one form.
Currently we have the following functions:
form.createBinding(bindingURI);
form.load(object);
form.save(object);
To allow multiple bindings, we can extend the functions as follows:
form.addBinding(name, bindingURI);
form.load(name, object);
form.save(name, object);
The current functions can be left in place use default as the binding
name.
ScriptableWidget
This is a difficult issue, and touches right on the problem of how to
integrate java and javascript logic.
The ScriptableWidget makes that we have different form objects in the
javascript and java world (with somewhat different though equivalent
API's).
To make things more confusing, the javascript snippets that can be put
in the binding and form definition files are supplied with the original
Java widget objects, as is the validator function in the old (non-v2)
API.
There has been some discussion on pro/con ScriptableWidgets before, see:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107945863719119w=2
and follow that thread.
The main pro/cons according to me are:
* pro: ScriptableWidget makes it much more natural to work with the form
in a javascript environment. Working directly with the Java objects
feels clumsy. If you look at the v2 API, it allows to easily do some
powerful stuff like assigning javascript functions as event handlers.
* con: different objects, different API's, different documentation,
needs work when new widgets or features/concepts are added. Makes it
more difficult to do one part of logic in javascript and another part in
Java. Makes the javascript code harder to move to Java if you want to.
I'm still undecided on this topic (ScriptableWidget). I'd like to hear
what others think of this, and how they
Re: JXTG jx:attribute
On Sat, Apr 24, 2004 at 04:51:35PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Sorry to bother you privately but I did not get the answer on cocoon group
and
I see you're the main JXTG developer.
My question is: Is there any real reason that jx:attribute is not
implemented?
Something that would work as xsl:attribute or xsp:attribute to allow
generation of dynamic content of an attribute?
lg
Please direct all questions to the dev list. The only reason is that it
seems hard to implement it efficiently. Consider:
foo
jx:attribute name=bar namespace=http://www.bar.org; value=${bar}/
jx:if test={$fubaz 1}
jx:attribute name=xyz value=100/
/jx:if
jx:forEach var=item items=${items}/
jx:attribute name=${item.name} value=${item.value}/
/jx:forEach
...
/foo
The start element event for foo must be buffered until all potential
jx:attribute tags have been processed. Since these are within
conditional blocks and loops determining when that is the case in an
efficient way isn't easy
After a longer thinking it really does not look so easy. As it is not known if
an element has dynamic attributes or not the start element on the output would
have to be postponed for EVERY elemeny till we reach startElement for a child
node a endElement for current one.
Still I do not see any efficiency issuses here: only one element has to be
cached so it does not impart neither speed nor memory requirements.
lg
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: [vote] Versioning Guide
On 24 Apr 2004, at 18:48, Carsten Ziegeler wrote: Apache HTTPD is (I believe) doing this: 2.0 is stable, 2.1 is unstable, and it will be released further down along the platform either as 2.2 (if backwards compatibility can be preserved) or 3.0 (if the new design emerged in 2.1 requires major changes). Ah ok, yes, I think this makes sense. I thought we don't use versions for this, so we have something like a sandbox in our repository for such things. But I'm fine with that as well. A sandbox is fine for developing a small bit... For example, my version of the kernel is in the sandbox now... When (let's say) we want to start rewriting stuff (Cocoon core) around it, we'll have to take it out of the sandbox, and break a lot of contracts... Having a separate tree of unstable versions allows people to go on for longer with broken / not compiling code without being worried of having broken the main stable build. Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Repository Usage and Versioning
On 23 Apr 2004, at 10:03, Carsten Ziegeler wrote: I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). Can't we just have ONE repository for ALL? it's just makes life easier when copying/moving files around and we can fragment that repository as finegrained as we want... For example: /cocoon/ - this is the repository /2.0/ /trunk/ - trunk of 2.0 /tags/ - tags of 2.0 /2.1/ /trunk/ - trunk of 2.1 /tags/ - tags of 2.1 And so on and so forth... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [cforms] Weird behaviour of flow and fb:javascript binding
Gianugo Rabellino wrote:
We are currently building a cforms based application with fairly
decent complexity level. Our (rather convoluted but, take my word for
that, legit) business logic requires the usage of an Avalon component
during the binding phase, so we thought to use the fb:javascript
binding method, hoping to find (even if not explicitely documented)
the good old FOM, together with the cocoon object.
That was indeed the case, and we were cheerfully using logic like the
one in the following snippet:
fb:load-form
var validation = cocoon.getComponent(bindinghelper);
var today = new Packages.java.util.GregorianCalendar();
var executionDate = validation.getValidExecutionDate(today);
widget.setValue(executionDate.getTime());
/fb:load-form
At a certain point, though, we mangled the form *definition* and
modified a selection list so that it was taking its data from a
cocoon:/ pipeline instead than from a static file (which we used
during prototyping). Such pipeline, in turns, calls the flow which
sendPage()s to a JXTG (data are in a business object we need to stream):
snip/
I found the cause of the problem.
The flowscript scope is stored in a request attribute (see
FOM_JavaScriptFlowHelper) and this attribute is cleared upon termination
of the script execution to prevent any further usage after the script
execution is finished.
The problem comes from the fact that request attributes are shared
between the real request and all internal requests that are created to
answer the real one. This means that when your selection list pipeline
is executed :
1/ the original scope (from form.showForm) is overriden by the scope for
the selection list
2/ when the selection list has been generated, the request attribute is
cleared, and there is therefore no more cocoon object in the request
for subsequent js bindings.
The solution is to use a storage means that is independent for each of
the various internal requests used to produce the response. In Cocoon,
this is the object model. It also has the additional benefit that a
child requests starts with a copy of the parent's object model and
locally overrides it (works like InheritableThreadLocal)
The problem is potentially the same for every other data issued by the
flowscript (continuation, view data, request, etc).
I modified FlowHelper and FOM_JavaScriptFlowHelper so that they use the
object model. I also moved to private all static strings defining
storage keys as I found some direct references to them to store data as
request attributes that violate the encapsulation provided by the
setters in these two classes. This may cause incompatibilities in
external code that does the same, but there's no way around it if we
want the use of setters to be enforced, which hides the storage location
for this data.
This should solve your problem. Please cross-check!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Vote] Repository Usage and Versioning
On 23 Apr 2004, at 11:44, Nicola Ken Barozzi wrote: with SVN we will have this dir structure: /cocoon /trunk /site /src ... /branches /cocoon2.1 /site /src ... Please read play with SVN a bit, as it has a different and better way to handle these things I think that every version should have its own trunk and tags so that parallel development on more than one revision can happen easily... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Repository Usage and Versioning
On 23 Apr 2004, at 19:14, Ralph Goers wrote: As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. +1 :-) And move kernel development in 2.3 so that _THAT_ tree of versioning can be unstable A-LA linux! :-P Pier Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning I don't think new policy which is being voted in should be applied retroactively. Meaning, I'd suggest this policy to be in effect starting with Cocoon 2.1.5. Thus, plan of action would be in this case: * Let Cocoon 2.1.5 out. * Move to Subcersion. * Start Cocoon 2.2. * Remove deprecated classes in 2.2 which Carsten mentioned recently. Vadim smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Repository Usage and Versioning
On 24 Apr 2004, at 18:43, Carsten Ziegeler wrote: Upayavira wrote_ Personally, I think getting CForms out in its current form is worth a release. Yes! IMO it's worth a release as a 2.2 since CForms are a quite a huge addition (even if not breaking compatiblity)... Pier smime.p7s Description: S/MIME cryptographic signature
Re: CForms flowscript API musings
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
As Chris pointed out some time ago, this way of doing things, although
fully functionnal, creates an unnecessarily long chain of continuations.
This can be avoided by using bookmark continuations (see the v2 JS
stuff), but makes the code less trivial.
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
* allows to add custom code to be executed before the form is displayed,
and before a form submission is processed. This last one is useful for
multiple things:
- adding checks to see if the user is allowed to submit the form
at this moment (could be disallowed if he/she has gone
forward/backward in the flow and changed stuff on another form)
- if multiple forms were put on the page, allows to check using
eg a request attribute which form submission should be
processed.
- or more generally, it allows to put other links on the page
pointing to the same continuation but causing something else to
be done then processing the form submission.
Never encountered these use cases up to now, but they seem valid ones.
* allows to use sendPage instead of sendPageAndWait for stateless
applications.
I was thinking about proposing to deprecate showForm in favor of
sendForm and sendFormAndWait, which are more similar to sendPage
and sendPageAndWait, along with the removal of the custom validator
(more below).
For convenience we could still leave the form.showForm() function, but
make its content as simple as the one above.
Custom validation
=
The current CForms flow API's allow to specify a javascript function
that will be called to do custom validation. However, there seems to be
a problem with this.
Normally, it is the (java) form.process() method that will handle the
different stages of a form submission, which simplified is as follows:
- widgets read values from request
- events generated by this are processed
- widgets are validated *if needed*
(see also http://cocoon.apache.org/2.1/userdocs/forms/eventhandling.html
for the full cycle description)
Note the if needed for the validation: it could be that validation
must not be triggered, e.g. when an action widget has been activated.
However, the additional flowscript validation function seems to be
called always.
Since we now have the generalized concept of WidgetValidators, I propose
we use those to plug in the custom validation. In this way, the custom
validation will automatically be peformed as part of the normal form
processing cycle. WidgetValidators are currently however only part of
the WidgetDefinitions, we could make it possible to define additional
ones on the instances.
The same should probably be done for event handlers. Currently the v2
API works around this limitation by using the FormHandler to allow to
add instance-specific event handlers.
+1. form.validator was a hack needed before the generalized validation,
and isn't needed anymore. Also, do we still need FormHandler? My
impression is that we can remove it completely.
Multiple bindings
=
A simple one, but often requested on the user mailing list: it should be
possible to use multiple bindings with one form.
Currently we have the following functions:
form.createBinding(bindingURI);
form.load(object);
form.save(object);
To allow multiple bindings, we can extend the functions as follows:
form.addBinding(name, bindingURI);
form.load(name, object);
form.save(name, object);
The current functions can be left in place use default as the binding
name.
ScriptableWidget
This is a difficult issue, and touches right on the problem of how to
integrate java and javascript logic.
The ScriptableWidget makes that we have different form objects in the
javascript and java world (with somewhat different though equivalent
API's).
To make things more confusing, the javascript snippets that can be put
in the binding and form definition files are supplied with the original
Java widget objects, as is the validator function in the old (non-v2)
API.
There has been some discussion on pro/con ScriptableWidgets before, see:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107945863719119w=2
and follow
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Marc Portier wrote:
snip/
Sorry for the massive commit, however when walking around the code it
only looked like the proverbial tip of the iceberg.
Sorry for the delay, but, as we say here later is better than never!
- left quite some TODO markers for next sweaps
Maybe some of you have some suggestions on some of them, feel free to
step in and comment:
1/ should getWidget(id) be removed from Widget? It is already on
ContainerWidget (which is the true context that makes sense IMHO)
+1 from a theoretical POV, but -1 from a practical one! This will lead
to many casts to traverse a widget tree, e.g.
form.getWidget(choice).getWidget(union).getWidget(foo)
will become
((UnionWidget)((ChoiceWidget)form.getWidget(choice)).getWidget(union)).getWidget(foo)
Or we may extend getWidget() so that it accepts a path (dotted notation)
instead of a simple name, which would allow e.g.
form.getWidget(choice.union.foo)
2/ should getNamespace() exist at all, it seems to return the same
thing as getFullQualifiedId()? Maybe a historical idea waiting to get
thrown out?
+1 to remove
3/ can getId() ever return null or on a widget instance? Can't we
carefully asume programming error and allow for the accidental NPE to
be thrown
4/ same question on getDefinition()
What's the need for getDefinition() for users of a widget? I consider
this as an implementation concern of widgets and would remove it from
the public API (i.e. make it protected in AbstractWidget).
5/ should we rename ContainerDelegate to simply WidgetList (and the
ContainerDefintionDelegate to WidgetDefinitionList)
WidgetList is more understandable than ContainerDelegate ;-)
6/ union seems to generate fi:field in stead of fi:union this
surprised me a bit, is that the goal?
+1 for fi:field as, for the view, it isn't different from a field and
avoids duplicating the styling (the same is already done for action,
submit, repeater-action and row-action)
7/ should validation stop as soon as possible or continue to allow all
validation errors to be set?
Continue to get all validation errors.
8/ setParent() on abstractWidget should be write-once IMHO, possibly
yielding RTE (IllegalState?) when someone tries to reset it
Don't know... A sure thing is that definitions don't need a parent (also
they should be immutable). As for reparenting widgets, I don't know if
there are some valid use cases...
9/ should not all generateSAXFragments include the
getDefinition.generateDisplayData() by default
+1
And I would add:
10/ Split generateSAXFragment() into startSAXFragment() and
endSAXFragment(), which will make it so much easier on the view side to
handle custom SAX fragments for container widgets and embedding of the
wi:styling.
Note that I'd like also that wi:styling could be written in the
definition also, as defining the styling in the widget definition can be
a productivity boost with widget repositories!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Vote] Repository Usage and Versioning
Pier Fumagalli wrote: On 24 Apr 2004, at 18:43, Carsten Ziegeler wrote: Upayavira wrote_ Personally, I think getting CForms out in its current form is worth a release. Yes! IMO it's worth a release as a 2.2 since CForms are a quite a huge addition (even if not breaking compatiblity)... Well, a stable CForms would be worth a 2.2, but for now all I'm looking for is a release that contains the woody-cforms renaming, for which 2.1.5 would be enough. Regards, Upayavira
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
On Sun, 2004-04-25 at 15:10, Sylvain Wallez wrote: Marc Portier wrote: snip/ Sorry for the massive commit, however when walking around the code it only looked like the proverbial tip of the iceberg. Sorry for the delay, but, as we say here later is better than never! mieux vaut tard que jamais! (had to cheat for this one, you don't want to see my first attempt ;-) And I would add: 10/ Split generateSAXFragment() into startSAXFragment() and endSAXFragment(), which will make it so much easier on the view side to handle custom SAX fragments for container widgets and embedding of the wi:styling. +1 What do you have in mind with the custom SAX fragments for container widgets? Note that I'd like also that wi:styling could be written in the definition also, as defining the styling in the widget definition can be a productivity boost with widget repositories! Should be trivial to store this in the form definition. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: CForms flowscript API musings
Bruno Dumon wrote:
On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
As Chris pointed out some time ago, this way of doing things, although
fully functionnal, creates an unnecessarily long chain of continuations.
This can be avoided by using bookmark continuations (see the v2 JS
stuff), but makes the code less trivial.
What's the problem with a long chain of continuations? I mean, the
continuation is created anyhow, does it matter where it's added in the
continuation tree? Ah, just realizing: maybe because it allows faster
expiring of continuations?
It enables back/forward navigation. IIUC only after a valid form submit
the continuation is added to the continuation tree.
Maybe this can be solved with the wizard API that Sylvain proposed some
month ago.
I'm not sure how we can solve multi-forms per page support though ...
:-/ Any ideas?
--
Reinhard
Re: CForms flowscript API musings
On Sun, 2004-04-25 at 16:25, Reinhard Poetz wrote:
Bruno Dumon wrote:
On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
As Chris pointed out some time ago, this way of doing things, although
fully functionnal, creates an unnecessarily long chain of continuations.
This can be avoided by using bookmark continuations (see the v2 JS
stuff), but makes the code less trivial.
What's the problem with a long chain of continuations? I mean, the
continuation is created anyhow, does it matter where it's added in the
continuation tree? Ah, just realizing: maybe because it allows faster
expiring of continuations?
It enables back/forward navigation. IIUC only after a valid form submit
the continuation is added to the continuation tree.
I see. (but not sure yet we should give up the elegant while loop for
this)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/generation JXTemplateGenerator.java
Ugo Cei wrote:
Il giorno 24/apr/04, alle 23:35, [EMAIL PROTECTED] ha scritto:
coliver 2004/04/24 14:35:35
Modified:src/java/org/apache/cocoon/generation
JXTemplateGenerator.java
Log:
Allow a nodeset to be returned as the result of xpath evaluation
Before this change, I had a template which contained something like
the following:
jx:forEach select=#{/docs}
#{.}
/jx:forEach
What is the type of #{/docs} i.e. what does #{getClass(/docs)} output?
What is the type of #{.}i.e.what does #{getClass(.)}output?
What were the types of these objects before the change?
where docs was passed from flowscript as an array of DOM objects.
The template serialized all the DOMs. Now, it does not work anymore.
What happens instead?
After a few trials and errors, I was able to make it work again by
changing it to:
jx:forEach select=#{/docs}
#{*}
/jx:forEach
Is this an expected side-effect of the change? Can you explain why the
former version does not work anymore?
No it is not. But I can't explain it until you provide more information.
Chris
Re: CForms flowscript API musings
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
Can you describe this in more detail or provide some pseudo code on how
a page with multiple forms would be sent and processed (or point to the
documentation if there is already something about this)?
Thanks,
Chris
Re: CForms flowscript API musings
Christopher Oliver wrote:
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form(my_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {form: form});
finished = form.processSubmit();
}
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
Can you describe this in more detail or provide some pseudo code on
how a page with multiple forms would be sent and processed (or point
to the documentation if there is already something about this)?
I've had need for this before: having a login form on every page as well
as another form. This is my attempt:
With Bruno's code above, you could put a input type=hidden
name=formID value=login/ hidden field into each form that
identifies which form was submitted. Then you'd do:
var loginForm = new Form(my_login_form_definition.xml);
var mainForm = new Form(my_main_form_definition.xml);
var finished = false;
while (!finished) {
cocoon.sendPageAndWait(my-pipeline, {login-form: loginForm,
main-form, mainForm});
if (cocoon.request.formID == login) {
finished = loginForm.processSubmit();
} else {
finished = mainForm.processSubmit();
}
}
That ought to do it. There's a little hack with the
cocoon.request.formID, but it should work, as far as I can see.
Regards, Upayavira
Re: [Vote] Repository Usage and Versioning
Pier Fumagalli wrote: On 23 Apr 2004, at 11:44, Nicola Ken Barozzi wrote: with SVN we will have this dir structure: /cocoon /trunk /site /src ... /branches /cocoon2.1 /site /src ... Please read play with SVN a bit, as it has a different and better way to handle these things I think that every version should have its own trunk and tags so that parallel development on more than one revision can happen easily... It was just OTOMH, but your proposal seems better :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
lenya sprint: may 14th-15th 2004, zurich
the lenya community is organzing a lenya sprint on may 14 and 15 in zurich, switzerland. we will focus on repository integration, but people with other interests are also welcome, of course. more information is available at: http://wiki.cocoondev.org/Wiki.jsp?page=LenyaSprints http://wiki.cocoondev.org/Wiki.jsp?page=LenyaSprintZurich20040514 please sign up on the wiki (and watch the wiki for updates) if you would like to attend. best, -gregor -- Gregor J. Rothfuss Wyona Inc. - Open Source Content Management - Apache Lenya http://wyona.com http://cocoon.apache.org/lenya [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Sylvain Wallez wrote: Marc Portier wrote: snip/ Sorry for the massive commit, however when walking around the code it only looked like the proverbial tip of the iceberg. Sorry for the delay, but, as we say here later is better than never! yep, thx for chiming in - left quite some TODO markers for next sweaps Maybe some of you have some suggestions on some of them, feel free to step in and comment: 1/ should getWidget(id) be removed from Widget? It is already on ContainerWidget (which is the true context that makes sense IMHO) +1 from a theoretical POV, but -1 from a practical one! This will lead to many casts to traverse a widget tree, e.g. form.getWidget(choice).getWidget(union).getWidget(foo) will become ((UnionWidget)((ChoiceWidget)form.getWidget(choice)).getWidget(union)).getWidget(foo) aargh, did this already Or we may extend getWidget() so that it accepts a path (dotted notation) instead of a simple name, which would allow e.g. form.getWidget(choice.union.foo) makes sense, but I haven't seen that much so deep nested structures yet, but surely one we could add to the virtual todo list :-) 2/ should getNamespace() exist at all, it seems to return the same thing as getFullQualifiedId()? Maybe a historical idea waiting to get thrown out? +1 to remove done 3/ can getId() ever return null or on a widget instance? Can't we carefully asume programming error and allow for the accidental NPE to be thrown 4/ same question on getDefinition() What's the need for getDefinition() for users of a widget? I consider this as an implementation concern of widgets and would remove it from the public API (i.e. make it protected in AbstractWidget). I had the same feeling in fact, but didn't go so far yet. would need to check consequences 5/ should we rename ContainerDelegate to simply WidgetList (and the ContainerDefintionDelegate to WidgetDefinitionList) WidgetList is more understandable than ContainerDelegate ;-) was done 6/ union seems to generate fi:field in stead of fi:union this surprised me a bit, is that the goal? +1 for fi:field as, for the view, it isn't different from a field and avoids duplicating the styling (the same is already done for action, submit, repeater-action and row-action) thx for the extra info, tim already explained the first part 7/ should validation stop as soon as possible or continue to allow all validation errors to be set? Continue to get all validation errors. yeah, that seems to be the consensus, I've dropped the event/validation/lifecycle stuff for the moment and am focussing on the @extend/@define reuse first I'll pick this up later by making a catalogue of the validation stuff now (I thought I saw some inconsistency to the above rule, but the special cases might make sense after all, just need some detail look, discussion and additional dev-docs IMO) 8/ setParent() on abstractWidget should be write-once IMHO, possibly yielding RTE (IllegalState?) when someone tries to reset it Don't know... A sure thing is that definitions don't need a parent (also they should be immutable). As for reparenting widgets, I don't know if there are some valid use cases... haven't touched this yet removing it on the widget-definition is part of my current work on doing the @extend @defines stuff 9/ should not all generateSAXFragments include the getDefinition.generateDisplayData() by default +1 done that And I would add: 10/ Split generateSAXFragment() into startSAXFragment() and endSAXFragment(), which will make it so much easier on the view side to handle custom SAX fragments for container widgets and embedding of the wi:styling. hm, actually since the start/end is always grouped and quite similar to all widgets I've made the spilt slightly different: generateSAXFragment will do the start/end of the containing element, by asking getXMLElementName() and getXMLElementAttributes from the derived concrete subclass inserting other stuff in between is done by subclassing generateItemSAXFragment hope you can live with that to get the same flexibility? (the only flexibility you loose imho is the ability to produce not welformed XML by mismatching your end and start events :-)) Note that I'd like also that wi:styling could be written in the definition also, as defining the styling in the widget definition can be a productivity boost with widget repositories! maybe we could just treat it like the display-data? (we made that move to the wi namespace as well, so it doesn't seem to unlogic, no?) wdyt? -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Repository Usage and Versioning
Upayavira wrote: Pier Fumagalli wrote: On 24 Apr 2004, at 18:43, Carsten Ziegeler wrote: Upayavira wrote_ Personally, I think getting CForms out in its current form is worth a release. Yes! IMO it's worth a release as a 2.2 since CForms are a quite a huge addition (even if not breaking compatiblity)... Well, a stable CForms would be worth a 2.2, but for now all I'm looking for is a release that contains the woody-cforms renaming, for which 2.1.5 would be enough. hm, as you might now, I'm actively refactoring cforms as we speak (cleaning out, adding javadocs to get us in shape for efficient bugfixing... next to some more serious refactoring to get us passed some long due feature requests) IMO just some progression towards 'stable' the stuff I had planned for this week (have started on it in fact) was the widget-reuse/repo stuff through @extends @defines @fdns (see wikipage WoodyScratchpad) What this means: - this is to replace the new/class stuff, CONSEQUENCE: these changes are going to be quite incompatible (and I mean: loads more then the minor things of my recent work) - I'ld like to proceed in babysteps so progression can be followed and discussed, and I get to have some intermediate cvs-save-points as well. CONSEQUENCE: I'm quite sure some of these intermediate steps are going to be maybe broken here or there (I'm aiming at end of the upcoming week to be passed the bulk, needing us all maybe another week to test our use cases and fix possible stuff?) How do we fit it into this request for a cforms specific 2.1.5? (if possible without too much hastle on my work in progress here, I personally thought some tag like CFORMS_0_0_1 would've been enough) other suggestions? regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/generation JXTemplateGenerator.java
Il giorno 25/apr/04, alle 13:43, Leszek Gawron ha scritto:
What about simple content#{/docs}/content?
Wouldn't this put a docs element in the output? I don't need it.
Ugo
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/generation JXTemplateGenerator.java
On Sun, Apr 25, 2004 at 11:15:43PM +0200, Ugo Cei wrote:
Il giorno 25/apr/04, alle 13:43, Leszek Gawron ha scritto:
What about simple content#{/docs}/content?
Wouldn't this put a docs element in the output? I don't need it.
AFAIU docs variable is an array of DOM objects - how can it emit docs tag ?
First I thought you meant a NodeList, but with an array I do not think my
solution would work. Not for that it would emit docs but that you do need a
forEach tag to process an array.
lg
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(501)720812 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
RE: [Vote] Repository Usage and Versioning
As I recall CForms is still Woody in 2.1.4 and marked unstable to boot. The decision to rename it to CForms was OK'd on the basis that it hasn't been marked stable yet. If it is still unstable in 2.1.5 then you don't have to guarantee compatibility. However, once you mark it stable you need to leave drastic changes to 2.2 - or find a way to keep them compatible. Ralph -Original Message- From: Marc Portier [mailto:[EMAIL PROTECTED] Sent: Sunday, April 25, 2004 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning What this means: - this is to replace the new/class stuff, CONSEQUENCE: these changes are going to be quite incompatible (and I mean: loads more then the minor things of my recent work) How do we fit it into this request for a cforms specific 2.1.5? (if possible without too much hastle on my work in progress here, I personally thought some tag like CFORMS_0_0_1 would've been enough) other suggestions? regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: processToStream and ConcurrentModificationException
On Apr 25, 2004, at 11:18 PM, Leszek Gawron wrote: Could anybody explain why I get ConcurrentModificationException with this code: this is a known issue with the FileSource: if you look at your context directory, you will see a test.xml.tmp file (or something of sort). Remove it and you'll be fine, but keep in mind that such things might happen in the future. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: [cforms] Weird behaviour of flow and fb:javascript binding
On Apr 25, 2004, at 2:14 PM, Sylvain Wallez wrote: Gianugo Rabellino wrote: At a certain point, though, we mangled the form *definition* and modified a selection list so that it was taking its data from a cocoon:/ pipeline instead than from a static file (which we used during prototyping). Such pipeline, in turns, calls the flow which sendPage()s to a JXTG (data are in a business object we need to stream): snip/ I found the cause of the problem. I modified FlowHelper and FOM_JavaScriptFlowHelper so that they use the object model. I also moved to private all static strings defining storage keys as I found some direct references to them to store data as request attributes that violate the encapsulation provided by the setters in these two classes. This may cause incompatibilities in external code that does the same, but there's no way around it if we want the use of setters to be enforced, which hides the storage location for this data. This should solve your problem. Please cross-check! Thanks so much Sylvain. Cross-checking will require a bit of time since it involves mangling a quite complex app (we had to put together a workaround), but I'll let you know ASAP! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
RE: JXTG jx:attribute
On Sat, Apr 24, 2004 at 04:51:35PM -0700, Christopher Oliver wrote:
foo
jx:attribute name=bar namespace=http://www.bar.org;
value=${bar}/
jx:if test={$fubaz 1}
jx:attribute name=xyz value=100/
/jx:if
jx:forEach var=item items=${items}/
jx:attribute name=${item.name} value=${item.value}/
/jx:forEach
...
/foo
The start element event for foo must be buffered until
all potential
jx:attribute tags have been processed. Since these are within
conditional blocks and loops determining when that is the
case in an
efficient way isn't easy
Leszek Gawron wrote:
After a longer thinking it really does not look so easy. As
it is not known if
an element has dynamic attributes or not the start element on
the output would
have to be postponed for EVERY elemeny till we reach
startElement for a child
node a endElement for current one.
... or a characters() event containing non-whitespace.
Whitespace characters() between an element an jx:attribute should not be output at all.
Re: [REMINDER] IRC Meeting - 10:00 AM EST Sunday 25 2004
A very late reminder!! Date: Sunday 25 2004. Time: 14:00 UTC ...to late for me. Is there a log online? What are the results of the discussion? cheers -- Torsten
[SUMMARY] IRC Meeting - 10:00 AM EST Sunday 25 2004
Time: 1400 UTC Date: 25 April 2004 Venue: irc.freenode.net Channel: #ApacheAvalon Agenda; * The Proposal of Gang of Nine - Move ECM+Fortress to CodeHaus. * The Counter-proposal of Niclas Hedhman - Merlin TLP Full log available at; http://www.apache.org/~niclas/irc/2004-04-25.150335.txt Active Attendees; Noel Bergman Niclas Hedhman Stephen McConnell Leo Simons Peter Donald J Aaron Farr Michael Nash Andreas Oberhack Peter Royal Mauro Talevi Alex Karasulu Leif Mortenson Shash Chatterjee Lurkers --- (chicmome?) Johan Sjöberg (Spline) (T'lexii) Peter Courcoux (I may have missed some lurker. Sorry if that is the case.) Summary; Everyone in this group agrees that Avalon is, and has been for a long time, suffering from social illness. The meeting was scheduled to try find a solution that everyone can work with. Most of the Fortress-proponents (a.k.a. Gang-of-Nine and Light-weight camp) agreed that there was no real difference of keeping Fortress at ASF from moving it to CodeHaus, other than the automatic split of community and resolution of social illness. Noel's proposal of a Fortress TLP had slightly better support than an Avalon without the Merlin-proponents (a.k.a CitySlickers and Heavy-weight camp). The attendees came to the following consensus, being the most viable way forward, both technically and socially. * Merlin TLP is to be formed. * Fortress/ECM TLP is to be formed * Avalon becomes the neutral collaboration forum * Each project depending on Avalon has a representative in Avalon PMC. * Each container project has an additional representative in Avalon PMC. * J Aaron Farr remains the Avalon Chair. * Avalon Framework, LogKit, Cornerstone and Sandbox stays within Avalon at least for the time being. * Excalibur+Fortress (already in the same CVS module) is moved to the Fortress TLP. * Meta, Repository, Util, Merlin, Composition, Activation is moved to Merlin TLP. After-math; Noel's initiative http://wiki.apache.org/avalon/Reorganization was edited frequently afterwards (a total of 30 revisions so far) to formulate the new structure. Work on this document should continue. Unresolved and Not discussed issue; Avalon Logging is at the moment purely used by Merlin, but is rather generic and can remain in Avalon. However, currently there is a dependency in Avalon Logging on Repository, which probably is not in the interest to remain at Avalon. This issue should be discussed separately on the mailing list, and I think it will not be difficult to reach consensus on this. Thank you all for attending, and let's all work in positive spirit to move forward. Niclas Hedhman P.S. This is a cross-post. Discussions on this should ONLY appear on the [EMAIL PROTECTED] mailing list. Thanks for your cooperation. CC: Avalon PMC List Avalon Users List Cocoon Development List Apache Board BCC: Gang-of-Nine, to ensure everyone involved receives the summary. -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+
