Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
On Thu, Dec 22, 2005 at 01:42:50PM +, Andrew Savory wrote: He seems to have a good grasp of the guts of Cocoon. I think it's time for him to become a committer. ... Please cast your votes! +1 and welcome :) --Tim Larson
where is the box?
I have been sitting back listening to the cocoon evolution/revolution discussion, while happily coding with something else... The development of open source is dominated by emergent properties, which like their counterparts in chemistry and physics are not greatly affected by many types of environmental changes and are difficult or impossible to predict from base causes. The trick is to recognize that you are dealing with emergent properties and not a set of well-behaved laws, and then to deal with the patterns that present themselves. Where is the recent bottleneck in Cocoon? Is it the number of languages, the complexity of the core, the multi-step development process, the inability to use a common debugger across it all, the lack of a full test suit, incomplete or out of date documentation... ...or is there something more basic that is strongly contributing to all of these issues? Since we are taking a moment to think outside the box, perhaps we should pause to figure out where the box is and of what it is made. When Cocoon was started there were not many viable choices for cross-platform programming languages, so Java had much going in its favor. Now the situation has changed. Cross-platform scripting languages have become common. Java is a fairly static and verbose language compared with these new offerings...and much of the work in Cocoon lately seems to be in trying to work around this. Java has become the box. People moving to Rails hardly seem to notice the language change that comes with it. Is that because of the Rails hype (which wears off quickly) or because the language stays out of the way? Tutorials teach you the framework first, and let you pick up the language along the way because it is so easy. With Cocoon we are already dealing with a variety of languages, Java, Javascript, numerous XML dialects, and a sprinkling of Scheme to name a few. Perhaps Cocoon is ready to spawn a new breed with a Ruby core, where the language is succinct and more friendly to more dynamic code. Domain languages become possible without sacrificing a common syntax, debugger, and test suit. Pause and think about how the choice of a base language affects the development of a project...the more words and steps it takes to write code, the harder it gets to write, modify, document, and decipher the project. There are many ways to work around a verbose and predominately static language to make it seem more concise and dynamic, but each step taken in this effort diverges you further from common knowledge of the base language and complicates the core of the project...every line of code reflects the design decisions of the language used, until the project implodes. Let's find a new box, that is bigger and will fit all of our toys (we want to bring them with us, right?) There are a lot of great ideas in Cocoon, but I have come to the conclusion that Java has become to constricting to effectively develop them much further in a timely manner. I suggest we seriously consider Ruby as that larger, less constricting box. --Tim Larson
Re: Request for help with Ajax/CForms problem
On Tue, Nov 22, 2005 at 05:08:22PM +0100, hepabolu wrote: I'm trying to implement a union widget in my CForm, much along the lines of the datasource-chooser. AFAICT I've done exactly the same thing, but every time I switch the selection (i.e. the sourcetype in the datasource sample) I get an error: org.apache.cocoon.forms.FormsRuntimeException: Union 'doexhibition' has no child named 'noexhibition' Could you post your form model code for examination? --Tim Larson
Re: [VOTE] new committer: Max Pfingsthorn
On Tue, Oct 11, 2005 at 08:28:56AM +0200, Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: Happy +1 --Tim Larson
Re: [vote] Ross Gardler as a new Cocoon committer
On Wed, Oct 05, 2005 at 10:43:59AM +0200, Daniel Fagerstrom wrote: Hi all! I'd like to propose Ross Gardler as a Cocoon committer. He is one of the driving forces in the Forrest project, he has been quite active in our documentation efforts and in integrating Forrest, Lenya and Cocoon. Becoming a Cocoon committer will simplify his work and bring our communities closer. Please cast you votes. +1 --Tim Larson
Re: [vote] Arje Cahn as a new Cocoon committer
On Thu, Sep 08, 2005 at 07:41:30PM +0100, Sylvain Wallez wrote: Please cast your votes! +1 --Tim Larson
Re: [VOTE] Jorg Heymans as new committer
On Sun, Jul 31, 2005 at 01:18:34AM -0500, Antonio Gallardo wrote: So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: +1 and welcome :) --Tim Larson
Re: [VOTE] Give Robert Graham temporary and restricted commit privileges to our code repository
On Mon, Jul 18, 2005 at 09:52:30AM +0200, Bertrand Delacretaz wrote: In order to make his life and the life of his two mentors (Ross Gardler and I) easier, I'd like to give him *temporary* and *restricted* (http://svn.apache.org/repos/asf/cocoon/whiteboard/refdoc/**) commit privileges to our SVN code repository. +1 --Tim Larson
Re: Using svn whiteboard
On Mon, Jul 11, 2005 at 11:20:14AM +0200, Max Pfingsthorn wrote: Hi everyone! Hi Max :) Reinhard told me of a way to use things from the whiteboard as a block using some svn switch mechanism. This would be especially useful for the GSoC people. Can someone elaborate on this? Tim? You can find detailed directions included in the email at this link: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110567769309036w=2 --Tim Larson
Re: [vote] Give Max Pfingsthorn temporary and restricted commit privileges to our code repository
On Sun, Jul 10, 2005 at 01:23:06PM +0200, Reinhard Poetz wrote: As you all know, Max Pfingsthorn is one of our Google Summer of Code students and he will work on the implementation of the cforms library. In order to make his life and the life of his two mentors (Sylvain and I) easier, I want to give him *temporary* and *restricted* (http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/**) commit privileges to our SVN code repository. +1 --Tim Larson
Re: CForms Summer of Code project
On Tue, Jun 14, 2005 at 10:41:57AM +0200, Max Pfingsthorn wrote: Thank you very much, Reinhard! I'll fix that and submit it later today. After the email by Tim yesterday, I am a bit afraid that most work is already done and this project gets too small... I guess there is some bits of designing to be done, and the marketing anyway (i.e. docs and further examples). Does macro inheritance work yet? Or declaring single fields in the library? I'm sorry if I got a bit confused with whats already there and what is still left to be done for me. Sorry for giving the wrong impression...when I sat down to think about this some more, I found a lot of work remaining :) I will try to detail from memory what is left to do: Design and implement inheritance/extension and parameterization of macros: Import and reuse of macros works well now, but it is in the extension and parameterization where macros and macro libraries will become really useful. This will involve a fair amount of community discussion regarding what design features are desired or unwanted, and I expect that the implementation will involve a good bit of work. This part could keep you busy for quite a while. Create a better caching strategy for forms and macros: The current strategy used by the macro libs is too naive. It does not know how to retire items based on memory pressure, looks only one level deep from a stale cache entry to check for additional stale entries that need to be reloaded for changes, adds an unnecessary overhead to stable production systems by checking for stale entries on every form creation, is not integrated with the normal configuration and store system used by the rest of cocoon, and has no provision for preventing harmful caching of dynamic forms. This area could also supply you with a good quantity of work. Merge recent changes from trunk to whiteboard/forms: FormsTransformer has experienced major changes in the trunk, which will cause some work to update the template portion of the macro/lib implementation. Btw, Ajax support was added to the JX templator, and will need to be ported to the FormsTransformer. We will have to see how and if this will interact with macro support. Hope this helps, --Tim Larson
Re: CForms Summer of Code project
On Tue, Jun 14, 2005 at 07:41:55PM +0100, Tim Larson wrote: On Tue, Jun 14, 2005 at 10:41:57AM +0200, Max Pfingsthorn wrote: Thank you very much, Reinhard! I'll fix that and submit it later today. After the email by Tim yesterday, I am a bit afraid that most work is already done and this project gets too small... I guess there is some bits of designing to be done, and the marketing anyway (i.e. docs and further examples). Does macro inheritance work yet? Or declaring single fields in the library? Declaring a macro containing a single field works, but the syntax is more verbose than it should be for handling just a single widget, and iirc, it could use some work on being able to specify a new id/name for the field at the point of the macro expansion. ...And yes, there needs to be more/better documentation, and we sorely need to create some simple step-by-step examples of using the macro/library features. Another possible work area: Use the macro/library support to make full forms nestable, with either the same or different templates. The current implementation does not do this, instead requiring such dual use (stand-alone and nested) forms to be implemented as two files, the body of the form in a macro library and then another file containing a Form widget and importing the first file to act as a wrapper around it for stand-alone use. There are similar complications when it comes to using the binding and templating frameworks on nested/ dual-use forms, which could affect the structure of the base flowscripts. Drifting a little bit away from the macro/lib discussion, into my motivation for having such a facility... I would like to have a declarative way of associating bindings, form models, and templates with each other, so when a parent form tells the form framework that it wants to display some sub-form, it does not have to tie the pieces together using code/programming. My use-case is a web-based IDE for editing sitemaps, forms, flowscripts, database mappings, portal configs, etc. where any one of those may be a top-level form, and the various related files/data/configs that they reference could be opened in context as nested/sub forms. Some may think this is silly, but working toward this goal has already proven useful...causing several bugs to be discovered and the code fixed, and producing a number of new widgets now used in other contexts: struct/group, union/choose, class/new (the first implementation of macro-like reusable groups of widget definitions), and a first draft of a macro library system that works for bindings, form models, and form templates. Have fun, --Tim Larson
Re: CForms Summer of Code project
On Fri, Jun 10, 2005 at 12:46:09AM +0200, Max Pfingsthorn wrote: Hi again! This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms guru here? :) I have a question about the inheritance and namespace/inclusion semantics which are not really discussed in the wiki. 1. What about nested libraries? In the wiki it says it forms a flat namespace. Would that be like this: include library 1 as lib1 and library 2 (from library 1) as lib2, then all macros of lib2 will still be accessible as lib2:name in a definition which includes lib1? It also mentions a tree like model (I guess like java packages?), which would result in lib1:lib2:name to resolve to a macro in lib2? I guess both would be sort of easy to implement. Think of it like a tree, where each level can only see its own direct imports. For a library to expose macros from the libraries it imports it has to extend them, in effect adding those macros to its own namespace. In other words, when you import a macro library you can only see the macros that the library itself defines or extends, not macros that the library just happened to import for its own use. (This merely describes the current design and implementation in whiteboard/forms, feel free to change/improve it.) 2. Can any widget type be macro-ized or only fields? I guess any would make sense... Can macros be extended in the form definition? Any type of widget or list of widgets. 3. Extension/Inheritance of widgets may be a problem as currently the validation of configs is done within the builders' buildWidgetDefinition() method. May need to implement extendWidgetDefinition(Element, WidgetDefinition) for each of the builders. Default may be to just return the given definition. Could be called in AbstractWidgetDefinitionBuilder.buildAnotherWidgetDefinition(). Do you think that would that solve it? It has been a while since I thought about that part...try it and see how it works out. 4. What exactly is the NewDefinition for? For dynamic form generation? In that case, I guess, I can reuse some of it's parts for the MacroDefinition(Builder), yes? I copied and modified the Class and New defintions to make the macro support in whiteboard/forms. Class is for creating a blueprint of a list of one or more widgets, New says build an instance of that blueprint right here. New happens at the normal form-build time, so it is not really any more dynamic than saying fd:booleanfield.../. 5. What about caching or reloading libraries if they changed? How is that handled right now? Iirc, they are cached indefinitely, and checking for out-of-dateness only happens one level deep. An area for improvement :) Have fun, --Tim Larson
Re: CForms Summer of Code project
On Fri, Jun 10, 2005 at 08:04:26AM +0200, Reinhard Poetz wrote: Max Pfingsthorn wrote: Hi again! This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms guru here? :) IIRC the idea came from Tim Larson who has also started with some experimental code (http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/) but I have to admit that I don't know what the current status of it is. I do not remember the most current state it is in, but it was working pretty well, iirc. This means defining and instanciating macros worked, and macro libraries could be imported. The Swan code is the test case for these features, so look there to see what works. The design and the implementation will be discussed on this list and anybody who's interested can take part in the discussions. I'm willing to take the role of the official mentor but I would like a co-mentor who knows cForms in depth (Sylvain, Tim, Bruno, ...). This person doesn't need to be officially named but he is more a backup for Max if the whole community is on holidays and he needs a contact person for technical questions. Tim has already offered to help unofficially, right? (Just asking again for Max.) Yes, I am willing to help with however much time I have left over from moving :) I just do not know how much time that will be, so I will not be a full offical mentor. --Tim Larson
Re: [VOTE] Document Editors, and a new Committer
On Thu, Jun 09, 2005 at 02:14:44PM +0200, Bertrand Delacretaz wrote: Le 9 juin 05, ? 11:52, Upayavira a ?crit : ...As granting committership requires a vote, please cast your votes now: [ ] Helma Van Der Linden as a Cocoon committer +1 Welcome! Also, I'd like to invite both Mark Leicester and Glen Ezkovich to be editors... +1 Although this doesn't require a vote IIUC: +1, for Sebastien as well. +1 --Tim Larson
Re: Google Summer of Code - projects and mentors wanted
On Thu, Jun 02, 2005 at 02:08:13PM +0200, Reinhard Poetz wrote: Leszek Gawron wrote: 1. we still have not touched the subject of attribute driven template language. it would nicely suit as a project that could be finished till the end of summer. 2. cforms reusable widget repository... yes, I like both ideas! Who wants to mentor the projects? Tim, Leszek? While I would like to, I will not have enough time to be an offical mentor, due to buying a house and moving into it during this same timespan. However, I will gladly help unoffically with whatever time I end up having. About the reusable widget repository...there is already working code in whiteboard/forms, just needs to be reviewed to see what changes we may want and then updated to sync with svn trunk head. --Tim Larson
Re: Google Summer of Code - projects and mentors wanted
On Fri, Jun 03, 2005 at 02:28:36PM +0100, Tim Larson wrote: About the reusable widget repository...there is already working code in whiteboard/forms, just needs to be reviewed to see what changes we may want and then updated to sync with svn trunk head. I take part of that back...there is a good bit that still could be designed and coded with regard to extension and parameterization. --Tim Larson
Re: CForms icons problem
On Sat, May 14, 2005 at 04:55:15PM +0200, Leszek Gawron wrote: Am I the only one to have images coming from cocoon-forms-block.jar broken? They are ok in src folder but they aren't properly rendered by the browser. This is not the case of my browser because the same tool on src/ as on unpacked jar. Fixed, thanks to help from Vadim. Gif files were being keyword filtered by Ant, causing corruption. I split the copying now to handle text and binary files separately. Please fine-tune the selection of files if you notice any other binary files in addition to the gif's. --Tim Larson
Re: CForms icons problem
On Sat, May 14, 2005 at 04:55:15PM +0200, Leszek Gawron wrote: Am I the only one to have images coming from cocoon-forms-block.jar broken? They are ok in src folder but they aren't properly rendered by the browser. This is not the case of my browser because the same tool on src/ as on unpacked jar. I have the same problem, as I reported earlier. A completely fresh checkout of cocoon in a new directory and a fresh compile of this checkout by a freshly downloaded j2sdk1.4.2_08 DID -NOT- solve it. To be clear, this problem is with svn trunk only...the 2_1_X branch works fine for me. --Tim Larson
Re: resource:// protocol broken?
On Wed, Apr 27, 2005 at 04:31:54PM -0400, Vadim Gritsenko wrote: Tim Larson wrote: Looking at the Cocoon Forms samples, the first of the Basic Samples, Various (Actions), does not display its GIF's (which are loaded via resource://), and the second sample, Various (Flowscript), does not display at all. ... You mean http://localhost:/samples/blocks/forms/resources/img/help.gif ? And calendar? I see those images (2.1.x). I just did more testing and... The 2_1_X branch works for me (images load correctly and the sample flowscript form also loads,) but *trunk* does NOT work. Is anybody else also having this problem with the trunk version? --Tim Larson
resource:// protocol broken?
Looking at the Cocoon Forms samples, the first of the Basic Samples, Various (Actions), does not display its GIF's (which are loaded via resource://), and the second sample, Various (Flowscript), does not display at all. Is this expected due to refactoring somewhere, or does anybody know what's up? Btw, to be sure the problem was not local, I did a fresh svn co ... ..., ./build.sh, ./cocoon.sh servlet without changing *any* configs. --Tim Larson
Re: resource:// protocol broken?
On Wed, Apr 27, 2005 at 04:31:54PM -0400, Vadim Gritsenko wrote: Tim Larson wrote: Looking at the Cocoon Forms samples, the first of the Basic Samples, Various (Actions), does not display its GIF's (which are loaded via resource://), and the second sample, Various (Flowscript), does not display at all. Is this expected due to refactoring somewhere, or does anybody know what's up? Btw, to be sure the problem was not local, I did a fresh svn co ... ..., ./build.sh, ./cocoon.sh servlet without changing *any* configs. You mean http://localhost:/samples/blocks/forms/resources/img/help.gif ? And calendar? I see those images (2.1.x). Yes, with svn trunk head that link shows me an empty white rectangle with a black and gray border. What do you see? --Tim Larson
Re: The value of src/core (or lack thereof)
Sylvain Wallez wrote: So I propose to remove src/core and move all its content to src/java. +1 --Tim Larson
Fwd: [Patch] importPackage Ambiguous import error fix
I solved the Ambiguous import bug caused by importPackage,
and sent this email to the rhino list for them to check it.
- Forwarded message from Tim Larson [EMAIL PROTECTED] -
From: Tim Larson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Patch] importPackage Ambiguous import error fix
X-BeenThere: [EMAIL PROTECTED]
Attached is a patch to fix importPackage to not import the
same package more than once. This fixes an error that
shows up if a call to importPackage is encountered twice
before classes from the package actually get referenced.
I encountered this error while working with a flowscript
(Cocoon's name for javascript+continuations) for a set of
Cocoon forms. Quickly starting more than one instance of
a form triggers this bug.
The patch replaces a comparison using '=' between two
NativeJavaPackage's with a comparison using string equality.
This effectively compares the package names instead of
checking for object identity.
The other thing which we might need to check is that the
two NativeJavaPackage's both use the same classloader.
I would appreciate it if somebody more knowledgeable of
Rhino internals could sanity check this patch.
--Tim Larson
--- rhino1_6R1/src/org/mozilla/javascript/ImporterTopLevel.java 2004-11-30
22:11:10.0 -0500
+++ rhino1_6R1_modified/src/org/mozilla/javascript/ImporterTopLevel.java
2005-03-22 19:52:43.0 -0500
@@ -213,7 +213,7 @@
{
synchronized (importedPackages) {
for (int j = 0; j != importedPackages.size(); j++) {
-if (pkg == importedPackages.get(j)) {
+if (pkg != null
pkg.toString().equals(importedPackages.get(j).toString())) {
pkg = null;
break;
}
- End forwarded message -
Re: how to handle lots of little modifications for forms samples files?
On Fri, Mar 18, 2005 at 05:38:16PM +0100, Linden H van der (MI) wrote: Guys, I've been working on bug fixing the forms samples which results in 1 - 3 line patches of about 40 files. What's the most efficient way of creating and submitting these patches? I only have Eclipse to create patches. Given how simple the patches are (few lines each) probably just make one big patch file and add it to bugzilla. One of us can then grab it and apply it to the various branches, while making the required changes per branch (if any.) --Tim Larson
importPackage() bug in trunk
There appear to be 2 bugs with importPackage() in flowcript in trunk. If importPackage() is not placed before all other code lines, then it acts imperative, importing the requested package again, even if it has already been imported via a previous run of the script. This causes Ambiguous import errors when you try to use the imported classes on the second and following runs of a script. Also, if a script calls importPackage() (even as the first code line as required by the above bug) but then does not use any of the imported classes on that run, then following runs which do attempt to use the imported classes will get the Ambiguous import error. Anybody familiar with the code to help track this down? --Tim Larson
Re: widget data type
On Fri, Mar 18, 2005 at 03:26:56PM -0500, Vadim Gritsenko wrote: Spelling... lable-path-is-i18n-key label i18n-catalog catalogue www.dictionary.com lists catalog first, but if people prefer the longer spelling that's ok. I will just have to check the docs each time I try to refer to it ;) --Tim Larson
Re: Supported and unsupported blocks
On Wed, Mar 16, 2005 at 01:25:35PM +0100, Reinhard Poetz wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: I propose to reflect these lifecycle-states in our SVN directory structure. Why do you think directory structure is required here at all? What's wrong with plain list of all blocks in one directory? IIRC the idea was to give a quick overview of the current status. Having a list iwth 50+ blocks makes it more difficult. This overview can be accomplished in better ways than by inducing churn in the svn archive as projects change state. Why not just make the current state of a block be reflected in its meta-data and then use this to generate documentation pages with separate lists of the groups of blocks in different states? --Tim Larson
Re: Supported and unsupported blocks
On Wed, Mar 16, 2005 at 09:41:37AM -0500, Vadim Gritsenko wrote: Daniel Fagerstrom wrote: IMO it is an esential service for our users that we in a honest and realistic way tell what we actually, in practicem, with real work, support rather than what we whish we supported. And I think nobody disagrees with that. Status page (suggested somewhere up the thread) indicating the status of the block, some additional information about the block, etc, will accomplish this even with flat directory structure in SVN. What exactly changing directory structure buys you? If there is clear and structured documentation about the blocks (it can use structure like supported/unsupported/contributed/abandoned/whatever) and similarly structured hierarchy in the sample webapp, what, on top of this, directory structure in SVN gives? I'm not so against moving stuff, but I'm just trying to understand why to move. I can live with dividing blocks up into directories and moving blocks around occasionally if that is what we decide, but I have a hard time understanding the reason for doing this, unless... ...are we dividing into separate directories so we can have separate downloads, e.g. cocoon-core.tgz, cocoon-extras.tgz, etc.? If so, then perhaps the distinction should be made by what is commonly used together, rather than by how supported, tested, etc. the components are (with an exception for truly experimental, not really released code.) Otherwise we are just creating more decisions to make when developing and downloading while not saving ourselves or our users any bandwidth. I think it is very important to create the types of distinctions between blocks which we are talking about (level of support, liveliness of development, degree of test coverage, etc.) I just don't see the benefit of doing this via division into directories. Directories only allow for one dimension of grouping, and as we already see we have several orthogonal concerns along which there is a tension to create a clear categorization. Meta-data used to generate separate documentation listings seems ideal for this usecase. --Tim Larson
Re: Supported and unsupported blocks
On Wed, Mar 16, 2005 at 03:57:34PM +0100, Carsten Ziegeler wrote: Vadim Gritsenko wrote: And I think nobody disagrees with that. Status page (suggested somewhere up the thread) indicating the status of the block, some additional information about the block, etc, will accomplish this even with flat directory structure in SVN. What exactly changing directory structure buys you? If there is clear and structured documentation about the blocks (it can use structure like supported/unsupported/contributed/abandoned/whatever) and similarly structured hierarchy in the sample webapp, what, on top of this, directory structure in SVN gives? I'm not so against moving stuff, but I'm just trying to understand why to move. Documenting the state is one thing, but imho just doing this in some descriptor isn't very visible. Who reads documentation or looks into a meta descriptor? :) So, by using a directory structure, it's immediately visible for everyone. If the documentation is clear and easy to find and read, and the user still does not bother to check it how are we going to give them any help? ...by also putting this documentation where they will read it, embedded in the samples pages, just like the current stable/unstable distinction. FWIW, When I evaluate other projects I view distinction of modules via directories with a grain of salt, because I know there is a higher threshold (more inertia) to moving directories around to mantain an accurate reflection of status than to just update a descriptor. --Tim Larson
Re: Supported and unsupported blocks
On Wed, Mar 16, 2005 at 11:59:09AM -0600, Antonio Gallardo wrote: On Mie, 16 de Marzo de 2005, 10:53, Reinhard Poetz dijo: Can anyone of you explain to me why it should be harmful following the proposed directory structure? I understand that some of you think that it is useless for you, but some of us (Carsten, Daniel, Bertrand, I, and maybe some others) appreciate this information at directory level. Upayavira already answered this. Lets start a vote? need we to discuss more the topic? I do not need to discuss more, as Upayavira captured my thoughts on the matter very well. Since we do not have a vote thread started yet, my *opinion* is +1 flat structure, -0 directories. (i.e. Strongly prefer flat, but would not try to veto directories.) --Tim Larson
Re: [cforms] Widget states in request-scoped forms
On Mon, Mar 14, 2005 at 09:44:44PM +0100, Reinhard Poetz wrote: Today I've tried to run a form that uses the widget state INVISIBLE and when the form state is saved in the request. (my experiments are based on the form1 action example) If I use the event framework to change the state from ACTIVE to INVISIBLE, toggling works, but the value of the changed widget gets lost. Looking at the samples I can't figure out ... - How can a widget have the state INVISIBLE? Where is this information stored, or better from where is it read? - If I'm right and the described behavior (losing the values of INVISIBLE widgets) is a bug, how can it be fixed? Any ideas? I do not know if it is the same bug or not, but I re-encountered the bug that made me temporarily change fireEvents to be public so it could be called from flowscript (iirc it was reverted when I forgot how to trigger the bug.) The bug is that the firing of events sometimes get delayed until after showForm returns, causing very strange behavior. Sorry I have not had time yet to track down the source of the problem. Sounds like there is at least a chance this is related to your problem. --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote: I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms and I liked what I saw. Thanks for taking a look. Any refinements are welcome. Side note: Remeber items in the whiteboard are often initially motivated by an individual, but are intended for community ownership and involvement and potential merging into the mainline when/if ready. So, anybody can dive right in and make any changes that are needed. This document defines reusable macro libraries. I'm sure this is useful for some usecases (e.g. editors) but I have a simpler one that goes into the direction of reusable form definitions. Macros give saving in maintenance, processing time, and memory usage. Maintenance -- one shared definition to edit instead of x instances. Processing -- definitions are are only parsed and built one time. Memory -- only one copy is stored for use in multiple forms. The maintenance savings are my main concern. By permitting reuse of snippets of bindings, form definitions, and templates you can more readily create and maintain consistent applications. For example, macros could be used to implement a common search sub-form for use throughout the many forms in an application, or to load and display common data in a consistent manner in multiple forms. In many of my forms date widgets are used: birthdate, start date, end date, ... Definining those widgets is nearly always the same, except the label. IMO it would make sense not only to have reusable macro libraries but also reusable widget libraries (renamed fd:macros to fd:library): I was already considering renaming fd:macros to fd:library; do you want to change it or should I? !-- Snip specific example to discuss in separate email. -- --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 11:09:08AM +0100, Daniel Fagerstrom wrote: Then in the template you write: ft:widget name=date ft:labelbirthday/ft:label /ft:widget By placing labels, hints etc in the template (view) instead of in the widget definition you get rid of the view info from the model and by improving SoC it becomes easier for people that are web designers rather than programmers to work with on the view aspect of the application. The label was put in the model to facilitate the common case of using the same label across multiple templates. While this can be handy, it also causes problems because labels are logically a view concern. Perhaps we could relieve this tension by treating any label specified in the model as merely a default, and allowing templates to override this by supplying an optional explicit ft:label element. --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 12:15:48PM +0100, Reinhard Poetz wrote: Daniel Fagerstrom wrote: Macros as reusable data types is OK in my (model view SoC fundamentalistic ;) ) opinion. I wouldn't call them macros then :-) Perhaps we should add more emphasis (via examples) on the wiki page to show that the macro concept is also shared with the bindings and templates, and not solely for form definitions. Having a parallel syntax for all three concerns is very much on purpose. Usually (but not always) you will use parallel macros in two or three of these areas, so I was striving for the concepts and syntax to match to ease learning and use of macros. Just wanted to point out that your first usesace could be attaced from a different POV. And finally my comment on the specific example: Full agreement with Daniel that there are better approaches to the label problem. (See my other email about default labels for my preference.) That stated, I still want to create a macro extension facility which would allow the extension to modify any aspects it inherits from the base macro, including labels, validation logic, widget names, adding and/or removing widget definitions, etc. So I am not shooting down the general idea of label replacement on macro expansion, but just cautioning that it will not usually be the most fitting solution. Your other examples (credit card info with aggregate fields and validation logic, etc. used across multiple forms) much better showcase use cases for macros. --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote: Tim Larson wrote: On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote: In many of my forms date widgets are used: birthdate, start date, end date, ... Definining those widgets is nearly always the same, except the label. IMO it would make sense not only to have reusable macro libraries but also reusable widget libraries (renamed fd:macros to fd:library): I was already considering renaming fd:macros to fd:library; do you want to change it or should I? can do it. What do you thing about reusable widgets as mentioned in my initial mail of this thread? Shall I add them? Practicality may change this (feel free to comment), but in my initial design I wanted to create these abilities: (1) Define a base macro. (2) Define a macro extending from a base macro. (3) Create an unmodified expansion of a macro. (4) Create an inline-extended expansion of a macro. (5) Create an inline-extended expansion of a macro, while also creating a new reusable macro based on the extension. (6) Import collections of macros for expansion and/or extension. (7) Define collections (libraries) of macros, possibly themselves based on other collections of macros via imports and extensions. Extension facility should eventually include such things as: Adding/modifying/removing widget definitions, templates, bindings. Changing names, labels, hints, and help on widget definitions. Adding/removing/modifying validation elements/logic. Adding in a previously unspecified or different datatype. Supplying/changing default values/selection lists/selections. Adding/removing/modifying styling (for template macros) Changing paths and ids (for binding macros) Etc. I may also want to separately support parameterized macros, the difference being that parameters would be expected and coded for in the macro definitions, while extensions could be seen more as sculpting a statue out of an unsuspecting (copy of a) block of wood. With this context (which we can refine or restrict as necessary) how do you picture merging the reusable widgets syntax and and semantics? I mainly see some potential to make extensions more concise (less wear on the fingers and eyes,) due to removing the fd:macro wrapper around those macros/reusable-widgets which happen to only contain a single widget. --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 04:40:04PM +, Tim Larson wrote: On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote: can do it. What do you thing about reusable widgets as mentioned in my initial mail of this thread? Shall I add them? !-- Snip design notes. -- Btw, I do not mean to scare you off. Go ahead and add reusable widgets to whiteboard/forms, write some samples using them and see how they turn out in actual use. This type of active, physical testing of ideas is what whiteboard/forms is for :) --Tim Larson
Re: Whiteboard Forms - Reusable form definitions (imports)
On Tue, Mar 08, 2005 at 08:10:36PM +0100, Reinhard Poetz wrote: Tim Larson wrote: Btw, I do not mean to scare you off. No you haven't :-) Great :) Go ahead and add reusable widgets to whiteboard/forms, write some samples using them and see how they turn out in actual use. This type of active, physical testing of ideas is what whiteboard/forms is for :) I've added a proposal for reusalbe widgets to the wiki page Should that be expanded to cover all types of widget definitions (booleanfield, aggregatefield, repeater, etc.) instead of limited to just field widgets? I would think that the same needs would be present for the other widget types. --Tim Larson
Re: Version $Id$ style for xml files (Was: SVN behaviour with Id keyword)
On Wed, Feb 02, 2005 at 02:39:49PM +0100, Sylvain Wallez wrote:
Conal Tuohy wrote:
What about a processing instruction?
?version $Id$?
This has the advantage over a comment that it can be retrieved
unambiguously with an XPath query: processing-instruction('version')
Question is: do we need that? IMO no, as I don't see valid use cases for
analyzing the version string of an XML document or XSL stylesheet at
runtime in Cocoon.
I like the idea of having _some_ way to access the version
info in xml files, because someday we may have tools like
javadocs which would collect and display this info (think
for xml files like sitemaps, cforms definitions, models,
templates, etc.) Since the work of standardizing the Id's
(to get rid of spurious CVS references, etc.) is tedious
I would like to do it only once, hence this discussion.
--Tim Larson
Re: Version $Id$ style for xml files (Was: SVN behaviour with Id keyword)
On Wed, Feb 02, 2005 at 01:49:35PM +, Tim Larson wrote:
On Wed, Feb 02, 2005 at 02:39:49PM +0100, Sylvain Wallez wrote:
Conal Tuohy wrote:
What about a processing instruction?
?version $Id$?
This has the advantage over a comment that it can be retrieved
unambiguously with an XPath query: processing-instruction('version')
Question is: do we need that? IMO no, as I don't see valid use cases for
analyzing the version string of an XML document or XSL stylesheet at
runtime in Cocoon.
I like the idea of having _some_ way to access the version
info in xml files, because someday we may have tools like
javadocs which would collect and display this info (think
for xml files like sitemaps, cforms definitions, models,
templates, etc.) Since the work of standardizing the Id's
(to get rid of spurious CVS references, etc.) is tedious
I would like to do it only once, hence this discussion.
Would the benevolent dictator please speak, so I can finish
the changes? Oops, that's in Linux kernel land ;)
More seriously, could a few more people respond so we can
come to a conclusion. I'm champing at the bit to get this
done, so I can move on to more real cocoon work :)
--Tim Larson
Re: Using the same object model in forms and jxtg
On Wed, Feb 02, 2005 at 07:30:59PM +0100, Carsten Ziegeler wrote: Currently we have two sitemap components, the jxtg and the forms transformer, that are able to evaluate dynamic expressions. Today I found out, that even these two components use different identifiers: for example if you want to access the continuation id, you use cocoon/continuation/id in jxtg. But this doesn't work in the forms transformer. There you have to use continuation/id. And the annoying part is that this last expression works in jxtg but is deprecated. I think this is really confusing. So, anyone against using the same object model in these components? This means introducing the cocoon object in the forms transformer and at the same time deprecating the access without the cocoon object. No problem. It would be much better to have them match. Just follow the normal deprecation cycle for such a change. --Tim Larson
Re: Using the same object model in forms and jxtg
On Wed, Feb 02, 2005 at 06:38:36PM +, Tim Larson wrote: snip/ So, anyone against using the same object model in these components? This means introducing the cocoon object in the forms transformer and at the same time deprecating the access without the cocoon object. No problem. It would be much better to have them match. Just follow the normal deprecation cycle for such a change. ..and document the change, of course :) --Tim Larson
Version $Id$ style for xml files (Was: SVN behaviour with Id keyword)
On Sun, Jan 30, 2005 at 11:21:30AM +0100, Sylvain Wallez wrote: Hi all, I found today some interesting things regarding how SVN handles keyword expansion. As part of my effort to keep whiteboard/forms mergeable, I am fixing a bunch of Id's and ran across a minor issue. How do we want to mark the version in xml files? There is quite a variety+possibilities: CVS $Id$ SVN $Id$ !--+ | $Id$ +-- Version $Id$ version $Id$ @version $Id$ etc... Could we pick a style, and then I will make the files I happen to touch match it? --Tim Larson
Re: Version $Id$ style for xml files (Was: SVN behaviour with Id keyword)
On Tue, Feb 01, 2005 at 01:20:10PM -0800, Ralph Goers wrote: Tim Larson wrote: As part of my effort to keep whiteboard/forms mergeable, I am fixing a bunch of Id's and ran across a minor issue. How do we want to mark the version in xml files? There is quite a variety+possibilities: snip/ I only see one choice that is within a comment. How do the others keep from breaking the document? The others are all in comments such as: !-- Blaw, blaw, blaw Foo $Id$ -- I just included the comment delimiters for the one example to show that in some documents the comments have extra decoration (the ascii-art +---+ stuff.) I would use !--+ | SVN $Id: $ +-- I personally do not like including a reference to the revision control system, especially since we have already experienced the data moving from one rcs system to another, invalidating all the CVS comments. FWIW, I fully expect another move in the future (not yet, don't get worried.) --Tim Larson
Re: Version $Id$ style for xml files (Was: SVN behaviour with Id keyword)
On Wed, Feb 02, 2005 at 10:35:03AM +1300, Conal Tuohy wrote:
Tim Larson wrote:
As part of my effort to keep whiteboard/forms mergeable,
snip/
Could we pick a style, and then I will make the files I
happen to touch match it?
What about a processing instruction?
?version $Id$?
This has the advantage over a comment that it can be retrieved unambiguously
with an XPath query:
processing-instruction('version')
I like the ability to retrieve the Id info...not knowing
much about processing instructions, will this produce
valid processing instructions when the version control
system expands $Id$? This expands into lots of stuff:
datestamp, filename, submitter, etc.
Also, can this mess up any existing document processing?
--Tim Larson
Re: SVN behaviour with Id keyword
On Sun, Jan 30, 2005 at 11:21:30AM +0100, Sylvain Wallez wrote: The nice thing once all this has been fixed, is that SVN doesn't consider as being modified a file where expanded keyword have been replaced by their unexpanded counterpart. You can then use whatever diffmerge tool you want to sync 2.2 and 2.1, since only files having real differences (and not only a different $Id$) will show up in the tool. Are other people interested in this small Id-unexpander script? I am interested in that script. --Tim Larson
MountTableMatcher '/' change?
Would it hurt anything to make this
change in the MountTableMatcher?
From:
// Append a '/' at the end of the prefix
// this avoids flat uri matching which would cause
// exceptions in the sub sitemap!
if (!prefix.endsWith(/)) {
prefix = prefix + '/';
}
To:
// Append a '/' at the end of a not-empty prefix
// this avoids flat uri matching which would cause
// exceptions in the sub sitemap!
if (!prefix.endsWith(/) prefix.length() != 0) {
prefix = prefix + '/';
}
This change is to allow a mount-table to perform a
similar function as a passthrough mount, permitting
the mount-table'ed sitemap to match at the same
level as the parent sitemap.
WDYT?
--Tim Larson
CForms in whiteboard with macros and macro repositories
As discussed previously, I made a copy of cforms in the whiteboard and added macro and macro repository support to the form model, binding, and template code. The code works, but there are still issues to resolve, such as svn propset's, code reorganizations, design issues, etc. I just had a narrow window of time to work on this commit today, so I thought it best to commit now while I had the chance, so others can see and work on the code, because I do not know when I will get my next chance to work on it myself. --Tim Larson
Re: CForms in whiteboard with macros and macro repositories
On Thu, Jan 13, 2005 at 10:59:02PM +0100, Sylvain Wallez wrote: Release early, release often, and whiteboard isn't even supposed to really work. So that's ok ;-) I left some bugs so it would be allowed into the whiteboard ;) Specifically, the editor which combines the editing of the model, binding, and template in a single page does not quite work yet, and there is an issue with dynamically detecting changes in macro repositories which are included by other macro repositories (just the classic when should we check for updates, and how deep down the tree should we check problem.) There are some code design issues which will need to be cleaned up (e.g. TopDefinition, ugh!) After the fact I realized that macros should probably use the same namespace wherever they are used (model, binding, template,...) since they have the same syntax and semantics everywhere. There are more features to add, but basic functionality is working, as you can see in the separate Swan editors for xreports, sitemaps, models, bindings, and templates, so I figure it is ready for others to check for usefulness and start to refine into something which we may eventually want to merge into the main distribution. If anybody would like to check this out, read this link: http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-4-sect-5 then change to the forms directory: cd cocoon/src/blocks/forms be sure to record your current branch for later reference: svn info | grep URL and use the svn switch command to switch to the whiteboard forms: svn switch http://svn.apache.org/repos/asf/cocoon/whiteboard/forms or like this (note the https) if you are a committer: svn switch https://svn.apache.org/repos/asf/cocoon/whiteboard/forms When you want to switch back to the your old branch make sure you are in the forms directory: cd cocoon/src/blocks/forms then switch back to the branch you recorded earlier: svn switch branch-URL-you-recorded-earlier I am not sure, but you might have to do a build clean between building the two branches to get a sucessfully running build. Note that the whiteboard branch of Cocoon Forms is NOT supported and the interfaces in it *can and will* be modified on a whim. This is to allow ideas to be experimented with and refined via actual shared code (in addition to using chat and email), without prematurely incurring the burden of support and deprecation cycles. Since Swan is a heavy user of the current set of experimental features, it could be viewed as a guinea pig for testing them. If you modify, add, or remove a cforms feature then please also edit the Swan samples to match your changes. This way you can judge the changes by how they work in practice, rather than just in the abstract. Thanks for this! You're welcome :) --Tim Larson
Re: [Vote] Component confs per sitemap [was: [RT]]
On Mon, Dec 20, 2004 at 11:54:01AM +0100, Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: What about providing the possibility to add components/roles on a per sitemap level? For example by providing a reference from within a sitemap in the map:components sections: So, please cast your votes! Here is my: +1 +1 --Tim Larson
Re: [RT] Component confs per sitemap
On Fri, Dec 17, 2004 at 03:06:20PM +0100, Carsten Ziegeler wrote: The current solution for adding own components to Cocoon is to (optionally) add the role to the cocoon.roles file and to add the component (configuration)to the global cocoon.xconf file. What about providing the possibility to add components/roles on a per sitemap level? For example by providing a reference from within a sitemap in the map:components sections: map:components roles-file=... config-file=... .. /map:components So all of these components are available in this sitemap and in all subsitemaps. Adding this (to 2.2) should be very easy and makes adding own stuff imho easier. (As a second step - but this is independent it would be possible to move all definitions of sitemap components into these files as well, leaving just the pipelines in a sitemap). WDYT? I like both ideas, because they allow more modular configuration. It seems this may also help with virtual hosting via subsitemaps? Could we allow live updates from changes made to the roles-file and config-file like we do for changes to sitemaps? --Tim Larson
[RT] CForms Triage/Staging in Whiteboard
Should we svn copy cocoon forms into the whiteboard to create a triage/staging area for (large, controversial) cforms ideas. This would allow us to try out ideas with code, rather than just with talk, before user support would become an issue. Any ideas which prove themselves and are accepted would be moved into the svn trunk for polishing before being added to a release. Examples of code I would plan on adding for discussion: Importable macros for bindings, models, and templates. First-class support for multiple bindings per form. Template code for walking x widget trees in parallel. WDYT? --Tim Larson PS: This idea (or a seed for it) was suggested by Sylvain previously, and over time I have started to warm up to it. It is OK to admit when I was wrong, right? :)
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
On Sat, Dec 04, 2004 at 09:37:10AM +0100, Bertrand Delacretaz wrote: For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is simple enough for such people to grasp. Perhaps I am not the only person on this list that has never used DreamWeaver...would anybody care to list or describe the how's and why's of its benefits and limitations? For context, all I have managed to glean so far from this discussion is a vague idea that visual people like it, that it does not work well with namespaced tags, and that it does seem to work ok with custom attributes. Not having ever used it, I do not know why visual designers like it, why it does not like namespaced tags, etc. Could somebody knowledgeable on the topic expand on the description? --Tim Larson
Re: [Design] JXTG 2.0 (Just say no!)
On Thu, Dec 02, 2004 at 01:27:09PM -0500, Stefano Mazzocchi wrote: Sylvain Wallez wrote: You miss an important point here: many Cocoon users are not able to write Java code, and even less a Tag implementation. The purpose of taglibs and template languages is to provide pre-packaged higher-level constructs that hide the underlying complexity. I'm sorry but I can't take this argument any longer. Programming is not just learning a syntax, but it's the mapping of a mental model. Mental model that people that write templates simple *DO NOT* have, nor care to have. Thank you, Stefano, for emphasizing the split between the mental model of the programmer versus that of the template designer. I would like to now accentuate another aspect of our problem and solution space. Babel-Driven Separation of Concerns (BDSoC) versus Graduated Complexity Separation of Concerns (GCSoC) We are currently using Babel (different languages) to enforce separation of concerns, and this has its merits, in that it creates a high barrior between different concerns, but also carries an obvious price. Another (complementary?) route would be to separate concerns via Graduated Complexity (same languages, with different levels of feature-sets available.) This would at least allow the people assigned to the different concerns to talk the same languages, with just the specific vocabularies varying. For example, picture a generic tag engine with sets of tag libraries. Configure one instance of the tag engine, giving it access to only the programming tags (such as to duplicate ESQL functionality.) Configure another instance of the (same) tag engine with access to only the templating tags. The framework development community now is in the easier position of supporting one instead of two languages, while the separation of concerns is still enforced upon the framework users. A side effect in this example is that the programmers and template makers gain a common base language, possibly making their needs easier to express to each other, maybe even leading to cross-pollination between their skillsets, allowing them to work more smoothly together while working on their respective concerns. WDYT? --Tim Larson
choose/when: container or control-structure?
The use of a choose in the form model should be invisible to the form template and form binding, just like use of a choose in the form template is invisible to the form model. Only structural differences between choices should force the parallel use of a choose in the template and binding. A choose may be used in the form model without causing structural changes. For example, identical sets of widgets may be referenced into two or more when branches, with the sole pupose of the choose control structure being to trigger event handlers to toggle the widgets' states. In this case it would be an unnecessary mixing of concerns to force the knowledge of the form model's choose onto the form template. This leads to choose not being treated as a container, but rather as a control structure. The id of the choose should not be injected in the id's of the widgets which it controls because this would force the template and binding to know about its presence even when they do not need to, needlessly increasing the coupling between the layers. WDYT? --Tim Larson PS: There is a list of other issues to resolve about the choose widget (naming, optional id, referencing widget defs versus inlining widget defs in the when clauses, different widgets defs in each when clause with matching id's, etc.), but let's addres them one at a time to reduce confusion. After this first issue is resolved I will start separate threads to discuss the other issues.
SVN is up again
Infra just said that SVN is up again. --Tim Larson
Re: svn commit: rev 57516 - cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel
On Fri, Nov 12, 2004 at 01:35:27PM -, [EMAIL PROTECTED] wrote: Author: sylvain Date: Fri Nov 12 05:35:27 2004 New Revision: 57516 Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Field.java Log: Optimize lazy parsing of value. Tim, I think we finally got it :-) Thanks :) --Tim Larson
Re: [Vote] Remove woody and portal-fw in 2.2?
On Wed, Nov 10, 2004 at 08:09:15AM -0800, Ralph Goers wrote: I'm +1 for removing woody and portal-fw from 2.2. +1 --Tim Larson
[Question] Re: cforms plans, templating engines, etc.
On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote: Tim Larson wrote: concerns before. I will try to take some time this weekend to see how to resolve this. I really do not want to revert the code if we can just improve it instead. I just feel pressured by the short time before we plan to release. So let's discuss your concerns. I started looking at Swan, and it seems to me that what's needed is simply and additional output state. Do you want me also to explain more clearly how states are implemented and behave (lacked the time to write some docs)? I finaly got to look at the widget states implementation, and even port parts of Swan to use it (working on porting the rest now). I see some things we can improve, but it looks good overall because of the separation between how we set states and how we query them. This will allow us to add more fine-grained state setting logic without disturbing existing state querying logic (if we find we need these changes in the future.) I will comment on the possible improvements later when I have collected my thoughts more, since they should not affect back- compatibility anyways. [Question:] http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109994348811745w=2 Is this change acceptable for keeping in the trunk and including in the stable branch? (The part about changing from isAcceptingInputs() to isValidatingValues() in the widgets' validate() methods?) Currently both methods will return the same value, but this will allow us to split the logic later if needed. Well, you've got a point here: yes, you should probably explain more what you want to do. The group's feedback will strengthen the ideas and turn them into a collective creation rather than a one-man show. Agreed. I will update my wiki page to explain my current plans, so they can be discussed, changed, and improved :) Well, I only saw changes to the template transformer, and no corresponding change in the form model, hence my impression you were writing a new template language. I also do not consider the WoodyScratchpad page a formal specification: we discussed for a while there, wrote down some ideas, and let them apart for quite a long time with still a lot of open questions and things to formalize. Great, I'm glad we solved some misunderstandings :-) Me too :) --Tim Larson
Re: [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
On Sun, Nov 07, 2004 at 09:29:56PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote: Ok. Does this mean choose/when will replace union/case? Also, the wiki [1] shows several alternatives for choose/when, and unless I missed something we have not decided which approach to use. Yes, choose/when is intended to replace union/case (following with any deprecation pattern that is needed). There are two alternatives, with the intention to have *both*, to service different usecases. Preliminary notice: don't get me wrong with all these questions and remarks. I'm shaking the concept so that it solidifies and we all agree on how it should behave before starting to write down some code. Thanks for providing feedback :) So, why do we need *both* versions? Isn't it FS? Can you give some examples that justify this need? Up to now, I personally never had the need for evaluated conditions. I sometimes would like to use types other than String, and that can easily be done by associating adding a convertor that defines how values for the different cases are to be converted to typed values. Your converter idea for handling other datatypes sounds good. I personally only need the simple switch version that references a widget (via a path passed to lookupWidget()) for the switch value and selects the case which has the id matching the value. Others requested the expression-on-every-case version, so they would have to supply usecases for that version. Furthermore, what expression language will be used? This leads us back to the discussion about expressions in JXTG, and the necessary unification of expression evaluation within Cocoon as a whole. I'm also not a fan of xReporter's expression language which is really specific to CForms. I got stuck on this point also. Perhaps someone with a usecase for the e-o-e-case version could comment? Also, there are some points I'd like us to to formalize. 1/ The wiki uses choice and case for the definition and choose and when for the template. IMO, this is confusing and we should have the same wording in the definition and in the template. I would use the same names in template, model, and binding. choose/when seemed to me to be the closest to consensus. Anyone have a different opinion? 1/ Is it a container? Looking at the wiki, the valued expression selects case version has no id. Also, are each fd:case also containers? My opinion is that fd:when should be a container, but not fd:case. This is enforced by the reuse of widgets between cases. Choose and when would both be *implemented* as containers, but they would not affect the paths/namespaces of the widgets they contain. Think of it as a control structure rather than as a real container widget. Also the id on the choose should be optional. For example, this would allow the model to choose between two widgets with the same id but with different datatypes without having to modify the corresponding template to recognize that a choice is even being made. In this example there is no need for choose to have an id, because the choice does not need to be referenced. For a choose that picks between different sets of widgets, or whenever you want the template or binding to be able to react to the selected choice, then the choose control structure will need an id. 2/ Widgets for a case: do we allow inline widgets to be defined in a fd:case, or only have references with fd:ref? Allowing both may cause some naming problems (this is also related to the previous question about containment), as an inline widget's name may conflict with a widget defined in fd:when. Similarily, if fd:case is not a container, widgets having the same name in different fd:cases will conflict. Allow widget definitions in the choose for cherry-picking in the when's (refered to as fd:case's above,) and also allow widget definitions in the when's. This allows for the type of example I described above. WDYT? --Tim Larson
Re: [Question] Re: cforms plans, templating engines, etc.
On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote: Tim Larson wrote: concerns before. I will try to take some time this weekend to see how to resolve this. I really do not want to revert the code if we can just improve it instead. I just feel pressured by the short time before we plan to release. So let's discuss your concerns. I started looking at Swan, and it seems to me that what's needed is simply and additional output state. Do you want me also to explain more clearly how states are implemented and behave (lacked the time to write some docs)? I finaly got to look at the widget states implementation, and even port parts of Swan to use it (working on porting the rest now). I see some things we can improve, but it looks good overall because of the separation between how we set states and how we query them. Do you mean the distinction between getState() and getCombinedState()? I implemented it that way because I felt that we may need to now the actual state of a widget and not always the combination with it's parent state according to the state priority rules. Yes, I like the the getState()/getCombinedState() split, and also the split between how we set a state (currently all attributes at once: readable, writeable, styling hint) versus how we query the state with isXXX (quering the attributes individually.) This will permit us to later allow setting the different attributes independently (if the need develops.) This will allow us to add more fine-grained state setting logic without disturbing existing state querying logic (if we find we need these changes in the future.) I will comment on the possible improvements later when I have collected my thoughts more, since they should not affect back- compatibility anyways. Ok, waiting :-) The most visible problem is that getCombinedState() is called several times per widget, and (iiuc) it climbs up to the root of the widget tree on each call. This would be rather inefficient for a deeply nested form, such as an xml editor. Perhaps we should reverse and cache the updates, having a parent notify its children when its state changes? This would cut the number of tree passes considerably, at the cost of some memory use for caching the combined states. [Question:] http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109994348811745w=2 Is this change acceptable for keeping in the trunk and including in the stable branch? (The part about changing from isAcceptingInputs() to isValidatingValues() in the widgets' validate() methods?) Currently both methods will return the same value, but this will allow us to split the logic later if needed. Good idea. The various isXXX methods on WidgetState are meant to avoid direct reference to actual state constants within the code. That firstly avoids inconsistencies and also allow later extension if needed (once again, I think we'll need to add an output state). So go on merging in the stable branch! Ok :) Well, you've got a point here: yes, you should probably explain more what you want to do. The group's feedback will strengthen the ideas and turn them into a collective creation rather than a one-man show. Agreed. I will update my wiki page to explain my current plans, so they can be discussed, changed, and improved :) Good idea, but rather than your page or WoodyScratchpad, what about a new CFormsScratchpad or a [RT] so that we can all work collaboratively towards well-defined evolutions? Yes, that sounds like a better way. --Tim Larson
Re: CForms: merge of 2.1 and 2.2 branches
On Thu, Nov 04, 2004 at 11:33:53AM +0100, Sylvain Wallez wrote: Done, I've committed the two-way merge of CForms. However, there are some items that I have not synchronized: - form.fireEvents in Form.js: why is it needed? The form object buffers events only during the readFromRequest phase, and otherwise always broadcasts them immediately This one is puzzling me. I had a case where events generated before sending a page were not fired until after a POST was received. Looking at the code again, I do not see how this could happen, so I will have to keep searching... Btw, we seem to have a bug in our value-changed event generation. For example, in Field.java we do not generate a value-changed event when the value goes from non-null to null, because our event generation code is wrapped in the same if construct as we use to determine if the value should be validated. - field.removeSelectionList: there's a big problem behind it, as it calls definition.setSelectionList(null). It's important that widget definitions be *immutable* as they a reused for different instances of a form. We could implment this correctly via: this.selectionList = new EmptySelectionList(null); Then the definition would rightly be treated as immutable. Should we do this and keep the new removeSelectionList method, or should we just make the calling code explicitly use: setSelectionList(new EmptySelectionList(null); and remove the new method? - getProcessMyRequests: we have to see how this relates to widget states. Discussion going on in other threads. - ft:choose: we've talked about it already, and I removed it until we know more about Tim's experiments. Discussion going on in other threads. A few questions, also: - no generation of fi:union and fi:struct: does it have to be removed at template execution level, or should it be filtered by the XSLs? In other words, can the stylesheets do something useful with it? If we consider that fi:struct can be renamed to fi:group, we obtain at the form definition level the instance-only fi:group we have today to build tabbed forms and automatic layout. I found no use for these elements, did anybody else? The fi:group idea is interesting, but I wonder if it would cause more trouble than it is worth? Specifically, how would you handle when grouping in the model does not match the view-designer's idea of grouping in the template? - what's the difference between nestedHandler and skipHandler? nestedHandler is not used anymore and really should be removed. The difference is that the skipHandler suppreses output of the current start and end element events, while the nestedHandler does copy them to the output. In other words, the nestedHandler wrongly let elements in the ft namespace slip through to the output. - ft:widget id= now considers not only child widgets, but also paths using lookupWidget(). That's a good idea, but now the id is no more an identifier in the strict meaning of the word. Should we rename it to ft:widget ref= (with the additional meaning that it _references_ a widget in the form definition), or leave it as is? While the behaviour has been changed, the id never was a strict identifier, because we have been using relative id's, thus they never were guaranteed to be globally unique within the template file. ref _might_ be a better attribute name (I just don't know) but this switch to lookupWidget() did not change the situation but rather only made it more apparent, iiuc. --Tim Larson
Re: cforms plans, templating engines, etc.
On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote: Tim Larson wrote: Sorry for this late answer, I was out of office today (woke up a 5am to go to the airport :-/ ) No problem, we all have different schedules to juggle. Thank you very much for taking the time to consider and answer my concerns. Comments inline. and binding. Based on this, I believe choose/when should be reinstated in at least the dev branch (svn trunk.) During the merge, I have not touched at it choose/when in trunk. Ok, I must have misunderstood this: ft:choose: we've talked about it already, and I removed it until we know more about Tim's experiments. to mean removed from both dev and stable when you only meant that it was excluded from stable for now, like we decided. (Sorry, I felt pressured by the impending release and am just now starting to go through your actual commit.) The development of all this does not break backwards compatibility and has been discussed and (iiuc) agreed on, so I see no reason to fork the development away from the svn trunk, with the corresponding lack of feedback and testing this would produce. Ok. Does this mean choose/when will replace union/case? Also, the wiki [1] shows several alternatives for choose/when, and unless I missed something we have not decided which approach to use. Yes, choose/when is intended to replace union/case (following with any deprecation pattern that is needed). There are two alternatives, with the intention to have *both*, to service different usecases. Macros, widget types, and type libraries: Right. This is a necessary evolution. Great! Compiled templates: The problem is _where_ in the dev branch? What are the areas where this compiled template stuff is applicable? Is it limited to CForms? Yes, at this stage this will only be useful to CForms. As I understand it, this is a rewrite of the FormsTransformer. This can happen in the CForms block, but _besides_ the current code. Just as your EffectPipe lived besides the original FormsTransformer before replacing it once we all considered it was better. What makes this subject controversial is that you seem to want to replace the EffectPipe right now. Yes it is a rewrite of that code. And my plan from the start was to implement it beside the existing code, just like you describe. Sorry for any confusion on that. Globally optimized template/transform pipelines: This is an extension of the previous idea, compiled templates. Because it is of more general use than just for cforms, it would probably have to migrate into its own block at some point. However, since it would be based on the cforms compiled template code and its initial driving usecase would be supporting the cforms view layer, imho it would not be too out of place to start the development on it within the cforms block, so this could be resolved when we get to the point of implementing it. Mmmh... I don't agree here. What you describe here is a general-purpose feature, which happens to be applicable to CForms, but to other areas as well. We can make a parallel here with XSP: there's a general-purpose core engine, and some blocks who provide their own logicsheet to extend XSP in particular areas. The location of this code (forms block or its own block) is not a big issue to me. At first it would only be useful to cforms, but as it progresses it will become more general purpose like you describe. And this code is still several projects away timewise anyways... Basically, please delay worrying about this sub-project at least until the steps before it are finished :) Because I would like to delay any worry about this until we reach a point where this could be implemented, and thus would be useful to discuss, I will not go into detail here about this sub-project. What worries me is the fact that you want to explore new directions which, although they seem really interesting and worth exploring, will disturb the way to stability of the CForms block *if* they are developped within that block. To summarize: Choose/when, macros, widget types, and libraries are aimed at backwards-compatible development in-place. Compiled templates are aimed to be developed beside the current FTT, but still in the same block and java package, just like how the EffectPipe code got started. The optimized pipeline code is still a ways off, but it would also be developed beside existing code rather than in-place, and its location is not an issue to me (its own block is fine if necessary.) Any remaining issues with the above plan? Widget States (tm): Separate control of output, input, styling, and validation: It has been discussed that there are times when we need separate control of these aspects for individual widgets and groups of widgets, but also that the common cases would be handy to select via named states that set all these aspects at the same time. Various proposals
cforms plans, templating engines, etc.
,) instead of on the fairly readable, modular code of the FormsTemplateTransformer? Even if we do follow the current JXTT rehabilitation plan, could I not continue to improve the forms transformer? The official Apache line is that we allow for competing technology to coexist, as long as they all have potential and actively being persued and used. Could I have a chance to try to improve the forms transformer past the abilities and usage patterns of the JXTT? This would involve adding conditionals (choose/when,) macros, imports, compilation, etc. I have been careful to not make a habit of breaking backwards compatibility or the build process for others, and I have been pursuing and incorporating feedback from the community via the ml's, irc, and wiki, and I have been supporting the components that I have added. So could there please be room for both approaches to have a chance to prove themselves? Sorry this email is so long and covers so many topics, but I wanted the community to know where I am trying to head, and to eliminate any confusion caused by me not explaining myself in a clear enough way. *Please* do not take this as directed at any individual. --Tim Larson
Re: [rant] please backport bugfixes to 2.1!
On Tue, Nov 02, 2004 at 09:12:28PM +, Tim Larson wrote:
I am working on the port now and have it almost finished,
but I have a few questions about some recent changes that
the commit comments did not make clear to me:
AbstractWidget.java
From: public Widget getParent()
To: public final Widget geParent()
Field.java
From: super validate
To: super validate widget != null
Repeater.java
In inner class RepeaterRow
From: getParent() returns Repeater.this and
setParent() throws a RuntimeException
To: setParent(Repeater.this)
(This seems to be caused by the AbstractWidget
change above.)
Could you explain what these changes are for, and then
I can finish the porting.
Sorry for the quick, unformatted email; I had to rush out to vote.
(hmm, perhaps not early and often enough to have an effect ;(
What I was wondering was why getParent was made final in
AbstractWidget, thus causing RepeaterRow to not be able
to enforce that its parent cannot be changed.
And I was wondering if this from Field.java in BRANCH_2_1_X:
if (super.validate() value != null) {
// New-style validators were successful. Check the old-style ones.
this.validationError = getDatatype().validate(value, new
ExpressionContextImpl(this));
}
...needs to be ported to the trunk? I think so, but my mind is
a little cloudy from all the porting and I wanted to doublecheck.
--Tim Larson
Re: [rant] please backport bugfixes to 2.1!
On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote: I am working on the port now and have it almost finished, Buhooo... I missed your post and am also almost finished :-((( :( but I have a few questions about some recent changes that the commit comments did not make clear to me: AbstractWidget.java From: public Widget getParent() To: public final Widget geParent() I had a bug while writing widget states because Repeater.RepeaterRow was redefining getParent() while I was using this.parent. So I made it final in order to be able to use this.parent throughout AbstractWidget. Ok, but I predict Marc will be unhappy ;) Field.java From: super validate To: super validate widget != null That's value != null. This check is required as old-style validators (the ones that were inside fd:datatype) assume a non-null value and this was therefore leading to NPEs. Ok, thanks for explaining. Could you explain what these changes are for, and then I can finish the porting. Mmmh... I nearly finished it on my side... how do we proceed? I'm ready to finish that job if you don't mind. Please go ahead and commit, then I will comment if necessary. Note that there are some new features in 2.2 that I wouldn't like to be ported now to 2.1 as I'm not very happy with them and would like some discussion about them: - the get/setProcessRequest() stuff which seems to overlap with widget states Yeah, I did not think that design was ready either...but we may need to expand widget states (tm) a little bit, but I will see after your commit. - the new choose/when statement in EffectWidgetReplacingPipe: for complex control structures, we have template languages like JTXG and XSP. It doesn't seem good to me that every transformer reinvents it's own control structure language. There is reason to this madness, if you will just bear with me for a bit. I will hold off on porting that to BRANCH_2_1_X. I have a plan, an experiment, but if it is too disruptive for the dev line (svn trunk) then I could move it to the whiteboard. It involves compiled templates and transformers (yes, I figured out an efficient way to compile and cache transformer-templates) with fairly human-friendly syntax, view widgets, and parallel structure between the binding, model, and templates, including things like having choose/when being in all three (as a more functional, flexible replacement for union/case). WDYT, do I need to move this effort to the whiteboard? (not a vote ;) --Tim Larson
Re: [rant] please backport bugfixes to 2.1!
On Wed, Nov 03, 2004 at 07:05:49PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote: Tim Larson wrote: On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote: I had a bug while writing widget states because Repeater.RepeaterRow was redefining getParent() while I was using this.parent. So I made it final in order to be able to use this.parent throughout AbstractWidget. Ok, but I predict Marc will be unhappy ;) Why? Does he have special widgets that redefine getParent(). If that's the case, we can remove the final and replace this.parent by getParent(). Just the general rule of preventing the possibility of making changes to things that should not be changed, such as a RepeaterRow's parent, but maybe someone will find a usecase to justify it :) Ok. Something that's seem more and more necessary to me is an output state that would sit between disabled and invisible, in order to render widgets as text and not as disabled inputs without having to use styling type=output. Yes, lets start by adding that, and see where that gets us. You already told us about this idea, and it seems to me much more general than CForms. However, I also understand that you may want to use CForms as a playground for this experiment. But doing it in the main dev line when we are trying to achieve stable state for CForms is IMO dangerous. So whiteboard/scratchpad seems a good idea. Remember: flowscript started there ;-) I have no problem with this, as long as it is ok with others for me to clone cforms in the whiteboard for this purpose. --Tim Larson
Re: [RT] Attribute Rendering and CForms Convertors
On Wed, Nov 03, 2004 at 09:46:27PM +0100, Daniel Fagerstrom wrote: I prefer the request processor idea to the current form population where each widget reads it data from the request object. The current scheme makes CForms unecesarily bound to the request parameter model of input data. With a request processor that is reponsible to write input data into the form model, it would be easy to plug in a different request processor if one gets xml input from a browser that implements XForms, e.g. This change would also be good for xmlhttprequest support. --Tim Larson
Re: [lazy vote] cforms request processing
On Tue, Nov 02, 2004 at 12:33:48PM -0700, Jason Johnston wrote: On Mon, 2004-11-01 at 22:08, Tim Larson wrote: This can open some posible security concerns at all? The form model would still be in control of which request parameters get processed. The only change is that a missing request parameter would cause no change to the corresponding widget instead of causing it to be reset to null. Can you think of any way for this to be exploited? A client could change a value that was not made visible by the current page view, but it would still be subject to the normal validation rules. And if this is an important issue for your use-case, then your page-splitting is a data model (form model) concern rather than a pure view concern and you should have used a union/choose or other *model* means to control it. I'm concerned about a particular scenario; perhaps you can explain how this would work in the proposed behavior... It seems to me that implementing the proposal would make required=true on widget definitions pretty much useless. IIUC, such widgets would not be validated as required if their request parameters were not present. So it would be possible to successfully submit (i.e. encounter no validation errors and pass successfully through the form.showForm() loop) a single-page form with a blank required field by simply removing that field's name from the request. This creates a problem where it's no longer guaranteed that the values in the form model post-validation are all valid; required widgets can have null values (assuming their initial values from form.load() were null). Is this actually the case in the proposal? Thoughts on how this can be avoided? We would still perform validation. The only thing we would not do is automatically reset a widget's value to null when its request parameter is missing. Because we would still validate the widget, required widgets would still catch empty values like they do now. --Tim Larson
Re: [lazy vote] cforms request processing
On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrote: I see the point.I am more convinced that we are pushing HTTP to the maximum and we need more well, can we implement that only for stateless forms? Why we need to cut all with the same scissors? This is only a thought. ;-) If necessary, we could implement an in-form config that would choose between the two missing-request-parameter behaviors. This can open some posible security concerns at all? The form model would still be in control of which request parameters get processed. The only change is that a missing request parameter would cause no change to the corresponding widget instead of causing it to be reset to null. Somebody else on this thread mentioned about the @required. How we will manage that, if we don't get back the required field? I answered below this question ;-) Please see my other email for the @required answer. Summary: we still validate, the only change is we do not automatically reset to null, so @required widgets should still work as they do now. Can you think of any way for this to be exploited? A client could change a value that was not made visible by the current page view, but it would still be subject to the normal validation rules. Exploited? Not sure, but you can do pretty funny thing with the forms. For example: Given a form that first allow you to select a quantity discount: Said you get 0% discount is you buy 1-10 items, 5% if you buy 11-20 items and 10% if you buy 21 or more items. Suppose the form first ask for the quantity to be buyed and then based on this select a discount. Then you change the quantity to 1 and the discount is already set. I know this is a very dumb sample, but the point I want to show is: I don't see how this change affects that scenario. Under some condition this could allow to hack the form. Could you give such a sample condition? Or what if I sent back an authentication form with empty fields? It hard to think in a sample. And we know we never can trust on the client. This is a basic web development rule. But in this caseI see we are trusting on the client.maybe we need to think a little bit more to see a sample. Please see the @require answer. What is the performance impact of that??? For each checkbox, we would send the client two widgets instead of one, and on POST we would get two widgets back instead of one. This only affects checkboxes, not other widgets such as fields, repeaters, etc. Remember on the repeaters we have the select boxes. If we are showing 20 rows on the repeater we are adding 20 new request params. I remember a system that did that and then they fixed on the next release by allowing users to define wich parameters need to return to the server to improve the performance I just expect this could not be our bottleneck later. More hidden parameters also mean bigger responses (pages). If it is that bad, we could make a config for it, as mentioned above. What do we want to do? [ ] leave as is [ ] make the changes described above Please think about that. I am sure you have the best intentions to improve the cforms-fw. To be honest I am not sure how to vote in this case, so is this is a big problem. I can put a -0 (this is not a VETO) for that. Let's see what the other people has to said about that. ;-) I do not mean to railroad this issue. The lazy vote is just to get attention put on the issue so we can finally resolve it. I am not in a hurry, so let's make sure everybody is comfortable with whatever solution(s) we settle on :) --Tim Larson
Re: [rant] please backport bugfixes to 2.1!
On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote: Unusual for me, but time for a rant: I wrote the new CForms widget state feature in 2.1 and tried to port it to 2.2. WHAT A PITA! There are a number or *bug fixes* or minor new features that only exist in 2.2. Why aren't they ported also to 2.1? Please, please, consider upgrading both branches at the same time. There will be some time before 2.2 is out and not everybody runs a snapshot of trunk. snip/ Grmbl... lost 2 hours this morning to do the merge, and finally reverted all :-( Very sorry that you lost time :( I had not ported my changes to 2_1_x yet because I was not sure they were ready, but addmittedly there were some bugfixes included that I should have ported immediately. I am working on the port now and have it almost finished, but I have a few questions about some recent changes that the commit comments did not make clear to me: AbstractWidget.java From: public Widget getParent() To: public final Widget geParent() Field.java From: super validate To: super validate widget != null Repeater.java In inner class RepeaterRow From: getParent() returns Repeater.this and setParent() throws a RuntimeException To: setParent(Repeater.this) (This seems to be caused by the AbstractWidget change above.) Could you explain what these changes are for, and then I can finish the porting. Going to port Tim's swan to widget states so that cforms in 2.2 and 2.1 can be *identical*. From a very quick look at the widget states implementation, I suspect a few problems will come up while doing this, but I am sure we can resolve them without too much trouble. --Tim Larson
[lazy vote] cforms request processing
We have talked several times about changing the request processing in cforms to not touch any widget whose request parameter is missing (to prevent these widgets' values from being reset to null,) the end result being that it would be easier for the view to decide how to split a form across multiple pages without breaking the SoC between the form model and the view. As discussed before, this change would involve sending a hidden field along with every checkbox to indicate the presence of the checkbox, because an unchecked checkbox does not generate a request parameter on POST. This would allow to distinguish between a checkbox that is unchecked versus a checkbox that is not on the page. What do we want to do? [ ] leave as is [ ] make the changes described above This is my +1 to make the change. --Tim Larson
Re: CForms work to do before marking it stable
On Thu, Oct 14, 2004 at 12:11:06PM +0200, Bart Molenkamp wrote: Another thing that may be needed is to do some modifications on the FormsTransformer and the forms stylesheets. Forms using unions and structs still have f* tags in their code, eg. fi:union, ft:case and fi:struct. Fixed in the forms transformer in the head of svn trunk :) --Tim Larson
Re: CForms : fd:case for union widget ?
On Mon, Nov 01, 2004 at 11:19:15PM +0100, Joerg Heinicke wrote: On 01.11.2004 09:20, Sylvain Wallez wrote: I'd like to know if a fd:case for the union widget is still planned to give more flexibility than the fd:struct or if there is another way to give a matching expression to the fd:struct. There were discussions about this [1] which unfortunately have stalled. IIRC, using an expression for cases was considered to bring too much overhead, as it expressions would need to be computed for each request. Additional flexibility can be achieved though by having the union's case widget be an output whose value is computed, eventually reacting to change to other widget values. When I talked the last time with Tim about it (yes I think it was just Time and me) we agreed that the missing fd:case causes just troubles. It was not about an additional expression, but about needing fd:struct, which results in needing ft:struct and fb:struct - where you need ft:case and fb:case anyway. Furthermore the inconsequence is just irritating. Yes there are two issues here, parallel structure between the binding, model, and template (binding and template use *:case, model does not,) and allowing cases to specify their own conditions rather than being simple cases like in a switch statement. For the first issue (parallel structure), we should add fd:case to the form model for consistency's sake, to simplify learning the union/ choose concept. As for the second issue (conditions on cases), it should be an option. This way you can have the choice of fast switch-like behaviour versus slower if...elseif...elseif...else behaviour depending on your needs. --Tim Larson
Re: [lazy vote] cforms request processing
On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote: Tim Larson dijo: We have talked several times about changing the request processing in cforms to not touch any widget whose request parameter is missing (to prevent these widgets' values from being reset to null,) the end result being that it would be easier for the view to decide how to split a form across multiple pages without breaking the SoC between the form model and the view. Is not posible to do that before sending the page? IMO given blind truting to what the client is sending back is not good at all. (Please see further down the page for a discussion on the security aspects.) An alternative that has been suggested in the past is to collect a list of the widgets present in the view, and to use this list to filter which widgets would get to process their request parameters upon a POST. The drawback to this approach is that it would not work for stateless forms, which is one of the use cases supported by cforms. Since with stateless forms the form model gets recreated on each POST, where would you store the view's widget list? And if the view is dynamic (uses union, choose, if, etc.) then you would have to store the list per form instance, clearly preventing stateless form semantics. In contrast, the design presented in this lazy vote would cause no problems for stateless form support because it does not require storing the list of widgets currently present in the view. This can open some posible security concerns at all? The form model would still be in control of which request parameters get processed. The only change is that a missing request parameter would cause no change to the corresponding widget instead of causing it to be reset to null. Can you think of any way for this to be exploited? A client could change a value that was not made visible by the current page view, but it would still be subject to the normal validation rules. And if this is an important issue for your use-case, then your page-splitting is a data model (form model) concern rather than a pure view concern and you should have used a union/choose or other *model* means to control it. In other words, excess request parameters would still be ignored just like they are now, so this would _not_ open a security hole like we had with xmlforms, so I do not see a case of blind trust being given to the client. As discussed before, this change would involve sending a hidden field along with every checkbox to indicate the presence of the checkbox, because an unchecked checkbox does not generate a request parameter on POST. This would allow to distinguish between a checkbox that is unchecked versus a checkbox that is not on the page. What is the performance impact of that??? For each checkbox, we would send the client two widgets instead of one, and on POST we would get two widgets back instead of one. This only affects checkboxes, not other widgets such as fields, repeaters, etc. What do we want to do? [ ] leave as is [ ] make the changes described above Hmm.. I am still not sure. Can you explain a little bit about the above first or just point to some links? Please let me know whether the above explanation makes sense or has holes in it, or if anybody has better ideas. Many thanks in advance. ;-) No problem :) --Tim Larson
Re: [VOTE] Leszek Gawron and Ralph Goers as committers
On Thu, Oct 28, 2004 at 05:04:31PM +0200, Torsten Curdt wrote: Folks please cast your votes for: [ ] Leszek [ ] Ralph as Apache Cocoon committers. +1 for both. Glad to have you here :) --Tim Larson
Re: getInputStream() in FOM_Cocoon.FOM_Request ?
On Tue, Oct 26, 2004 at 01:49:24PM +0200, Unico Hommes wrote: On 24-okt-04, at 13:47, Unico Hommes wrote: The Request interface itself does not have getInputStream method, only HttpRequest does. So first step would be to add getInputStream method to the Request and then add it to FOM. Done. I've applied the changes to the trunk only for now because I had to do an incompatible change. HttpRequest.getInputStream method returned ServletInputStream which has been changed to InputStream. Should I port the changes to the branch anyway ? I've also deprecated ActionRequest.getPortletInputStream in the portlet environment. Accessing the root page from a clean build of the trunk gives: Initialization Problem Message: Error during configuration Description: org.apache.avalon.framework.configuration.ConfigurationException: Error during configuration Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet cause java.lang.NullPointerException request-uri / full exception chain stacktrace org.apache.avalon.framework.configuration.ConfigurationException: Error during configuration at org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:207) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:240) at org.apache.cocoon.core.container.ComponentFactory.newInstance(ComponentFactory.java:131) snip/ Caused by: java.lang.NullPointerException at org.apache.excalibur.source.impl.ResourceSource.getInputStream(ResourceSource.java:97) at org.apache.cocoon.components.axis.SoapServerImpl.setManagedServices(SoapServerImpl.java:366) at org.apache.cocoon.components.axis.SoapServerImpl.configure(SoapServerImpl.java:201) snip/ --Tim Larson
Re: Compiling ClassLoader
On Fri, Oct 22, 2004 at 10:24:48AM -0400, Vadim Gritsenko wrote: Heya, Was looking at the flow, found CompilingClassLoader. Seems to me that this piece is a bit out of place sitting deep in the flow implementation. Does it make sense to move it a bit up, to the level of sitemap's component manager? This way, all sitemap components can benefit from dynamic compilation. WDYT? Vadim +1000 (While of course retaining the ability to configure it on/off.) --Tim Larson
svn head sitemap 1.0 not recognized
Fresh ./build.sh clean ./build.sh of cocoon svn trunk head produces this error for me (and is confirmed by tonyc on #cocoon): Internal Server Error Message: This version of Cocoon does not handle sitemap version 1.0 at file:/home/tim/pkg/svn/cocoon/cocoon/build/webapp/sitemap.xmap Description: org.apache.avalon.framework.configuration.ConfigurationException: This version of Cocoon does not handle sitemap version 1.0 at file:/home/tim/pkg/svn/cocoon/cocoon/build/webapp/sitemap.xmap Sender: org.apache.cocoon.servlet.CocoonServlet Source: Cocoon Servlet Request URI cause java.lang.NullPointerException request-uri / --Tim Larson
Re: svn head sitemap 1.0 not recognized
On Thu, Oct 21, 2004 at 09:33:27PM +0200, Carsten Ziegeler wrote: I think this is related to my latest changes in preparing the trunk for ecm++. I'm currently in the process of adding ecm++ to the trunk, so it should work soon again. No problem, just please drop a note here when you think it is ready to try again. Thanks for your work on creating ecm++ :) --Tim Larson
Re: [RT] applying SoC on cocoon itself
On Wed, Oct 20, 2004 at 07:06:54PM +0200, Sylvain Wallez wrote: Reinhard Poetz wrote: Or another alternative map:transformer type=three-source-transformer map:parameter name=first value=bar type=source/ ... /map:transformer Typing parameters. That's *really* interesting. I prefer Reinhard's proposal which leaves room for future expansion to other types. Should we use the string-typed-java-objects converters from CForms, perhaps enhanced with a few new types such as URI/URL's? --Tim Larson
Re: CForms Transformer plans...
On Thu, Oct 14, 2004 at 09:04:25AM +0200, Sylvain Wallez wrote: Tim Larson wrote: I plan to modify the forms transformer to match the builder/widget compiled model like the form model and bindings currently use. This will allow caching of compiled templates, and allow for more (possibly optional) complex template analysis during the build/compile stage, such as finding missing required widgets. Can you elaborate on caching of compiled templates? With the transformer, the template is defined by the generator's output and therefore the transformer has no means to cache it. I am wanting to create a generic template/transformation engine, as Bertrand phrased it on #cocoon, something between XSLT and full-blown java transformers, and I want it to perform global optimization over a sequence of template/transform steps. And for its first use-case it needs to have a set of cforms template handlers loaded into it, as well as some standard transformation handlers. You are right that the current design of transformer could not get the compile+cache behaviour, but we could split this new code out as a new generator and/or transformer getting the template from a src parameter (with the option of using a cocoon:/ source). The generator variant would be similar to the current forms transformer; for example, pulling its data from the form object and possibly other objects, while the transformer varient would just happen to have one more input available (the sax stream). Perhaps this would also be a good time to re-evaluate the separation of concerns between the form model and the template concerning the choice of which widgets to display on any particular page. Right now the form model controls this, because widgets not present in the template get reset to null. That's something I really think we should change: a widget should change its value if and only if it's present in the request. The only problem is for booleanfields since HTML sends no parameter for unchecked inputs. An easy solution to this can be for the booleanfield styling to add an hidden field indicating the presence of the booleanfield widget in the form (i.e. set the value of mybool if the hidden mybool.present exists in the request). I think this makes sense, don't change the value if there is no value to change. But we would still have to fire any validation rules in case there were any cross-widget validation rules present. If we had compiled templates, then there would be a place to record which widgets were sent and thus which widgets would need to process their request parameters. Still thinking about how this would interact with stateless forms. I don't see why we need compiled templates to allow this. Either with the current transformer and the JX macros, the view can flag (using a widget attribute) the widget it ouputs, and a check can be performed at the end of the template processing in search of missing required fields. Good catch, I missed that widget attributes already provide a good place to store this present-in-template info :) The missing-required-fields check is more expensive if we have to do it on every template application, but that may be acceptable. We also want to be able to use xmlhttprequest to process updates to individual widgets and sets of widgets, as well as to update various markup or styling. This implies that the view implementation for cforms needs to be able to process restricted collections of widgets and markup and have an xml format for communicating these updates to the client. We have a good start toward this because our cforms templates are already structured to process widget by widget, but using these templates is very slow for interactive update of small parts of a page via xmlhttprequest, putting us at a significant disadvantage compared with more primitive client-side js solutions... Well, using xmlhttprequest will always be slower than pure client-side behavior! But you're right that allowing finer grained update is needed (Ugo's xhrCarSelector is a good example of this). Generalizing this mechanism may IMO be simply achieved by augmenting the FormsGenerator, that currently dumps the full widget tree, by allowing it to dump only a particular widget subtree of a given form. Within the form display loop, the choice between full-html rendering and partial tree dump could be made by examining the value of a request parameter indicating the subtree path that needs to be updated. It is a little more complex than that...a client-side update of one widget may trigger changes to multiple subtrees of widgets, meaning that we may need to process multiple subtree-roots, and then have client js that splits the resulting xml back out. We also have to make sure we put enough id info in the markup surrounding the widgets that we can identify it to change it based on the data returned by the xmlhttprequests. But the server-side
CForms Transformer plans...
I plan to modify the forms transformer to match the builder/widget compiled model like the form model and bindings currently use. This will allow caching of compiled templates, and allow for more (possibly optional) complex template analysis during the build/compile stage, such as finding missing required widgets. Perhaps this would also be a good time to re-evaluate the separation of concerns between the form model and the template concerning the choice of which widgets to display on any particular page. Right now the form model controls this, because widgets not present in the template get reset to null. If we had compiled templates, then there would be a place to record which widgets were sent and thus which widgets would need to process their request parameters. Still thinking about how this would interact with stateless forms. We also want to be able to use xmlhttprequest to process updates to individual widgets and sets of widgets, as well as to update various markup or styling. This implies that the view implementation for cforms needs to be able to process restricted collections of widgets and markup and have an xml format for communicating these updates to the client. We have a good start toward this because our cforms templates are already structured to process widget by widget, but using these templates is very slow for interactive update of small parts of a page via xmlhttprequest, putting us at a significant disadvantage compared with more primitive client-side js solutions... What if we modify the forms transformer as described above and make it more a general transformation engine that can perform work similar to an xslt processor? Then we could feed it a pipeline of transforms to process and it could do global optimization to the pipeline during its build/compile stage. A sample optimization would be replacing transforms like A-B-C-D-E with A-E, allowing more clear, modular transform steps to be created by the programmer, while still allowing the compiled system to run very efficiently. Another optimization would be detecting what information later transformation steps need and automatically registering listeners/counters/aggregators to earlier transformation steps to record this info to prevent having to do whole-DOM searches like the current xsl stylesheets perform. WDYT? --Tim Larson
cforms xml editor committed
I committed the pre-alpha cforms xml editor (Swan). It has some pipelines commented out to not expose some security holes, so just uncomment those on a private server to try it out. There are lots of bugs, and visual mis-design for anybody interested to jump in and help fix :) I committed it in the forms samples, and we can move it somewhere else if we need to. --Tim Larson
[lazy poll] Commit cforms-based editor?
This is a lazy poll to see if I should commit the cforms-based editor for sitemaps, xreports, cforms, and any other xml files. It is nowhere near production-ready, has a security hole in it (so don't put it on an exposed server yet), has copy-and-paste bugs all through it, and it does not enforce the various schemas very well yet because it is still under heavy development... However, several people have expressed interest in seeing the code and possibly even helping with the implementation :) So to summarize, I am willing to swallow my pride and commit this ugly duckling code if it is ok to create a temporary branch for it in svn so we can more easily work together to finish the implementation. MrTompkins has graciously offered the codename swan to use for the branch name, which I think is rather fitting considering the transformation I expect it to undergo once we get more people working on it ;) So WDYT? --Tim Larson
Re: Wizard using CForms doesn't work?
On Wed, Sep 15, 2004 at 07:08:20PM +0200, Sylvain Wallez wrote: Stephan Coboos wrote: I need to implement a wizard using CForms. For this I had created one form definition which contains all fields of all wizards. Within the flowscript I only create one form instance for all shows. Each wizard form will contain a subset of fields of the form definition. At the end of the wizard trip I want to get all datas into one model. My flowscript looks something like this: snip example/ But this doesn't work. The first wizard will be shown and the second one, too. But after filling out and sending the second form cocoon will allways display the second wizard and not go to the ok.html page. Isn't it possible to make several calls of showForm on one instance? Whats wrong here? Is this a known problem? Yup, this is a know problem if your form contains required fields, as you won't exit a form.showForm until the form is valid, i.e. all required fields have a value. And they may not be present on the page you display... The problem is that any widget that is not displayed on the current page does not have its request parameter and value submitted on form POST, so its value is reset to null. So when you post one page of your form, all the widgets in all the other pages lose their values. There are several different solutions: * Wrap each page in a struct widget and use the new methods I recently added (e.g. setProcessRequests()) to control which sets of widgets process their request parameters. You can call these methods from your flowsript or from event handlers. * Wrap your form in a union widget and put the pages in struct widgets as the cases of the union. The unions in the model, template, and (if you use one) binding controls which widgets are displayed and which widgets process their request params. * Split your form into several separate forms, and use your flowscript to go from one to the next. Btw, anybody have comments about the new methods? Are they acceptable to keep, properly implemented, etc.? --Tim Larson
Re: Wizard using CForms doesn't work?
On Wed, Sep 15, 2004 at 09:24:30PM +0200, Sylvain Wallez wrote: Tim Larson wrote: On Wed, Sep 15, 2004 at 07:08:20PM +0200, Sylvain Wallez wrote: Stephan Coboos wrote: That's an additional problem, but even if this is solved, there's still the problem that form.showForm() doesn't exit is some fields are not valid (e.g. some who are displayed in a following screen). True. There are several different solutions: * Wrap each page in a struct widget and use the new methods I recently added (e.g. setProcessRequests()) to control which sets of widgets process their request parameters. You can call these methods from your flowsript or from event handlers. Can you elaborate on the use case that led you to add these new methods? I am writing a type-aware gui xml editor using cforms, for editing sitemaps, xreports, cform models, bindings, and templates, etc. The content of the file being edited is stored in a recursive tree of widgets, and since this tree is often large it is convenient to be able to hide (fold) parts of it and also to display parts as compact read-only summaries. Union's suffice for showing and hiding subtrees of widgets, but do not handle the display-read-only versus display-editable use case. The only option was to have a mirror set of output widgets to correspond with the field, repeater, etc. widgets and use a union to switch between them, but this creates a *lot* of work to keep the output-only mirror set in sync with the editable set, plus there is no output-only equivalent of many widget types, such as multivaluefield, aggregatefield, repeater... So I decided to create another option, which has been discussed before but never finalized or coded, of allowing every widget to have an output-only mode. You can separately control whether a widget processes its own request parameters and whether it allows the subtree of children under it to process their request parameters. This separate control might still need some tweaking. Also, we might want to introduce some attributes to the model schema to set default values for these new settings. Does this explanation help any? * Wrap your form in a union widget and put the pages in struct widgets as the cases of the union. The unions in the model, template, and (if you use one) binding controls which widgets are displayed and which widgets process their request params. Mmmh... IMO, the union widget should be strict about the selected case, and should allow to access widgets other than the selected one. Is this different from how the union works now? --Tim Larson
Re: cforms: add initialize widgets stage?
On Thu, Sep 09, 2004 at 05:50:08PM +0200, Sylvain Wallez wrote: Tim Larson wrote: On Thu, Sep 09, 2004 at 03:46:52PM +0200, Sylvain Wallez wrote: Exactly. In flat forms, custom initializations can be done in the flowscript between new Form() and form.showForm(), but I the case of dynamically created widgets, this cannot be done that way. I have some complex use cases where the case field of an union, itself in a class, has a selection-list that is defined by analyzing the values defined somewhere else in the form. Still following me? If not, you need to attend my presentation at the GT ;-) Following you fine. Wish I could come, but we are going to have a baby any day now, so I will be pretty busy at home this time. So the idea is that in on-create, the widget gathers in the form the necessary data to build and set its own selection list. Even for flat forms, this create-event can allow custom initialization code that currently is written in the flowscript back in the definition, thus making the form definition self-contained in a single file. Turns out I am also going to need your on-create support so this works out quite nicely :) +1. I'll add the on-create stuff on top of this. Committed. --Tim Larson
cforms: add initialize widgets stage?
A little context first: I was working with the union widget and decided to change the case id lookup to use lookupWidget(path) so it could reference widgets at other levels in the widget tree (../../somewidget.) While implementing this I found that this lookup needs to happen after all the setParent(widget) calls have happened (after the widget tree has been fully built) or the lookup can fail. Because widgets are not currently notified when tree building is finished, there was no place to plug in this lookupWidget() call, so I added initialize() to the Widget interface and added code to the form manager, AbstractContainerWidget, etc. to propagate a notification so I would have a place to initialize union widgets. Now I realize I could have instead used a lazy lookup when the case widget is first referenced, and I wonder if I should strip out the initialize() code or if it would help a use case anyone else has. WDYT? --Tim Larson
Re: cforms: add initialize widgets stage?
On Thu, Sep 09, 2004 at 03:46:52PM +0200, Sylvain Wallez wrote: snip/ I started implementing an on-create event listener, but failed on that same problem, as the whole form must be in a consistent state before that event can be fired, because the event listener can potentially reference any other widget. What were you going to use on-create events for? I am guessing mainly for new repeater rows and newly referenced union cases? So your initialize() stuff could be a solution to finish the implementation of create-event. However, that event must also be fired when a widget is creater later during the life for the form, e.g. when a new repeater row is created. So initialize() must also be called in that case. I already handle that case, and also calling initialize() for the created-on-demand child widgets of union widgets. Should I commit? --Tim Larson
svn viewcvs link
On http://cocoon.apache.org/2.1/ the old cvs viewcvs link is aging http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/ Should we add a link to the new svn viewcvs? http://svn.apache.org/viewcvs.cgi/cocoon/?root=Apache-SVN I would do it, but I still do not dare update the website ...how many steps are there again? :) --Tim Larson
Re: [QVOTE] Locking Down CVS
On Fri, Jul 23, 2004 at 07:52:48AM -0400, Vadim Gritsenko wrote: Hi All, Next step in CVS to SVN migration is locking down CVS and doing real conversion into SVN. I propose to lock down CVS today evening (say, 4pm on US east coast). How is everybody with this decision? Vadim +1 --Tim Larson
Re: [cforms] xreporter expressions on (Avalon) steroids
On Thu, Jul 22, 2004 at 01:27:55PM +0200, Gianugo Rabellino wrote: On Jul 21, 2004, at 7:54 PM, Bruno Dumon wrote: Maybe you could refactor some of that code into java classes that you call from the javascript. Or you can also write the validators directly in Java (which doesn't require declaring them in cocoon.xconf and making builder classes for them, there is also something like fd:java class=.../) Yup, this solves the language issue but not the architectural one: still no avalon context available. I did not dig in the code much, but I think we could extend an avalon context to the validators the same way it is done for a FormHandler. In: cocoon-2.1\src\blocks\forms\java\org\apache\cocoon\forms\acting\HandleFormSubmitAction.java see the line: LifecycleHelper.setupComponent(formHandler, null, null, manager, null, null); Not sure how efficient this would be, but if it gets the job done... --Tim Larson
Re: Form sample doesn't work
On Tue, Jul 20, 2004 at 10:14:02PM +0200, Stephan Coboos wrote: I'am using 2.1.5.1. It seems that the CForms samples doesn't work on this release? If I'am trying to start such an example the following error message will be thrown: Caused by: org.apache.avalon.framework.component.ComponentException: Could not find component (key [org.apache.cocoon.forms.FormManager]) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:263) But the forms block exists and the necessary libs (the class FormManager), too. What can I do? Is it fixed in the nightly build? Or is it a problem on my side? If you are copying jars to another place to run them, this problem is often caused by forgetting to copy the updated cocoon jar, which contains the roles file that maps the various cforms keys to the corresponding classes. --Tim Larson
Re: [cforms] enabling all widgets to listen to value changed events
On Wed, Jul 14, 2004 at 12:41:36PM +, Joerg Heinicke wrote: I have a form where for legal and natural persons different widgets have to be presented. I implemented it using a union widget and storing the persontype on a field with datatype ineger, the value is bound to a bean. To make this value usable in the union's case widget it must be transformed into a string. So my form definition looks like the following: Btw, Do you have ideas on how we should lift the string type restriction? snip sample/ I wonder why we do not enable all widgets to listen to value changed events. Though the user can not fire the event, it can happen programmatically like in my use case above. Besides this one (which is more a work around of the union widget's restriction) there are also other use cases imaginable, e.g. in a simple game: one widget is number of trial, another one is trials left. The second one is only updated if the first one has changed - of course the user must not update them by hand, so they are output widgets. WDYT? Yes, let's fix that, and while we are at it, I would also like widgets to have these dynamically selectable options: Via the model (secure, does not rely on well-behaved clients) Read/write - Like a normal widget Readonly - Like an output widget. Writeonly - For sensitive input (e.g. passwords not echoed to the client.) Neither - For server-side data (e.g. to still allow use of the other benefits of cforms widgets, such as validation, value-changed-events, and the ability to load and save via bindings.) Via the model and/or the view (not secure, relies on well-behaved clients) Inline - displayed but not in an input box (like an output widget.) Enabled - displayed in an editable input box (like a field widget.) Disabled - displayed in a non-editable input box. Hidden - not-displayed, hidden input box. Default mapping from model to view (can be overriden by the view): Read/write - Enabled Readonly - Inline Writeonly - Enabled Neither - Output to view suppressed WDYT? --Tim Larson
Re: question on UnionBinding
On Thu, Jul 01, 2004 at 11:46:55AM +, Joerg Heinicke wrote: Starting with the question: Does it make sense to process all sub bindings of a UnionBinding? At the moment the UnionBinding behaves just like a ContextBinding, all sub bindings are processed. While the processing of a UnionWidget depends on the caseWidget the same is not true for the binding. My use case: I have different cases that need the same widget to be displayed and later on saved back to bean. But the value is not saved to the bean only for the current case but for all cases and so my case5 always wins, though another case might have been selected. snip example/ The usage of voucherAvailable on the bean is exclusive, so I don't want to have 5 fields were one would be sufficient. Was the UnionBinding implemented that way because nobody thought about my use case or was there a use case for the current behaviour? I do not have time to dig in the code right now, but this looks like a bug (oversight) that needs fixed. Only the current case should be processed. --Tim Larson
Re: question on UnionBinding
On Thu, Jul 01, 2004 at 08:16:01AM -0600, Jason Johnston wrote: snip example/ Maybe I'm not understanding your example, but shouldn't all those fb:structs be wrapped in fb:cases with the same id? If I understand correctly it's actually the fb:case binding that does conditional processing of its subbindings; the fb:union binding just acts as a dumb container. Thanks for spotting this. I updated the TimLarson wiki page by adding the union binding syntax. --Tim Larson
Re: question on UnionBinding
On Thu, Jul 01, 2004 at 07:27:35PM +0200, Joerg Heinicke wrote: On 01.07.2004 16:32, Joerg Heinicke wrote: snip remember-to-use-case-with-union-binding/ But it has another drawback: The model binding is now also load only conditionally. What I need is to load the whole model but to save only the one selected. For this I had to add this binding twice: once with direction=load as direct child of union binding and once with direction=save as child of case binding. That seems is kinda strange, but probably only because your use case is different than mine. Could you explain why you need to bind the non-selected cases so I can understand your use case better? To put it another way, what makes your use case need an asymetrical binding? For example, if you look at the (admittedly needing to be worked on) Form Model GUI's binding, you will see code that figures out and sets the union's case based on the actual data that is being bound, and then that is used by the union and cases to make sure that only the relevant bindings for the current case get invoked and that the other bindings do not get invoked. --Tim Larson
Re: question on UnionBinding
On Thu, Jul 01, 2004 at 08:22:40PM +0200, Joerg Heinicke wrote: snip/ Use case: user will trigger an event, he can choose the event, the events are parameterized differently. The choose is the select box/caseWidget. The sample booleanfield is needed for a few of the cases, for other cases other fields are needed and some of them - now the reason for the asymmetry - have default values. As the switch from one case to another one is caused by submit-on-change on the select box now binding will be caused. Does this make sense? Yes, thank you. (I am just trying to make sure the masks proposal will not leave out important use cases.) --Tim Larson
Re: [VOTE] preservation policy for third-party snapshot sources
On Mon, Jun 28, 2004 at 11:13:22AM +0200, Sylvain Wallez wrote: Sylvain Wallez wrote: Please cast your votes: [ ] do not keep sources [ ] keep sources as separate zip files [X] keep sources in jar files This solution ensures permanent and unambiguous availability of snapshot sources, especially in critical situations such as commando-debugging at a customer site months after the deployment (yes, we sometimes deploy unreleased Cocoon versions). +1 To me this is a strong argument, because this seems to be when you really want the source, and need to be sure it is the exactly right version. Perhaps we could supply a source-stripping target or build property that would trim the source out for those who still do not want it? I.e. by default you are safe (source is included for the limited case of unreleased third-parties), but you could still go without if you prefer. --Tim Larson
