Re: CForms Summer of Code project
Dear Devs, Thank you all very much for your help! Thanks to Tim for the last minute comments! I've submitted my application last night ( way before time in California ;) ). Lets see what comes out of it. I've updated the proposal a little yesterday, see http://wiki.apache.org/cocoon/CocoonFormsLibraryProject. I hope I got things right, I got a little confused about the exact terms and structure of CForms... Bye! max On 6/14/05, Tim Larson <[EMAIL PROTECTED]> wrote: > 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 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 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
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, I wasn't aware that Tim has already started with the work. But AFAICS Tim has worked on the library import part and the "inheritance" part is still missing. Hence I think that there is some work left for you. If you're right and the remaining work doesn't justify two months of work, I'm sure, we will come up with new ideas (refactor cforms/flowscript and cforms/javaflow API, refactor cforms standard XSLTs for better reuse, test suite to ensure backwards compatibility, ...). Take them as ideas for now - of course we will discuss this in depth when your project has been accepted by Google. Maybe you can add a note to your proposal that - the work on the project has already been started but is stalled because the original committer working on it is very busy ATM. - the first part of your work is to find out what *exactly* of the requested features is still open and what has already been solved - if the remaining work doesn't justify 2 months of work, you will work on other parts of cForms (see above) HTH -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: CForms Summer of Code project
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. Bye! max On 6/14/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Max Pfingsthorn wrote: > > Hi everyone! > > > > I've posted my preliminary proposal at > > > > http://wiki.apache.org/cocoon/GoogleSummerOfCode2005 > > > > Any comments are very welcome! > > > The proposal looks very good to me, only one thing to add: Don't forget to > refer > to the project proposal --> > http://wiki.apache.org/general/SummerOfCode2005#cocoon-cforms-library > > > -- > Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach > > {Software Engineering, Open Source, Web Applications, Apache Cocoon} > > web(log): http://www.poetz.cc > >
Re: CForms Summer of Code project
Max Pfingsthorn wrote: Hi everyone! I've posted my preliminary proposal at http://wiki.apache.org/cocoon/GoogleSummerOfCode2005 Any comments are very welcome! The proposal looks very good to me, only one thing to add: Don't forget to refer to the project proposal --> http://wiki.apache.org/general/SummerOfCode2005#cocoon-cforms-library -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
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: 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 . > 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
Hi everyone! I've posted my preliminary proposal at http://wiki.apache.org/cocoon/GoogleSummerOfCode2005 Any comments are very welcome! Bye! max On 6/13/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Max Pfingsthorn wrote: > > Hi all! > > > > Yes, I will. The deadline is on the 14th, so does that mean the 14th > > 0:00 or 23:59? Its a big difference for me as a student ;) > > don't know. But as you work for a Dutch company you gain a few hours as Google > has its headquaters in California AFAIK ;-) > > Anyway, > > I'll get to it this afternoon, still have to work before. Don't worry > > though, I didn't (and won't) forget! > > :-) > > > -- > Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach > > {Software Engineering, Open Source, Web Applications, Apache Cocoon} > > web(log): http://www.poetz.cc > >
Re: CForms Summer of Code project
Max Pfingsthorn wrote: Hi all! Yes, I will. The deadline is on the 14th, so does that mean the 14th 0:00 or 23:59? Its a big difference for me as a student ;) don't know. But as you work for a Dutch company you gain a few hours as Google has its headquaters in California AFAIK ;-) Anyway, I'll get to it this afternoon, still have to work before. Don't worry though, I didn't (and won't) forget! :-) -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: CForms Summer of Code project
Hi all! Yes, I will. The deadline is on the 14th, so does that mean the 14th 0:00 or 23:59? Its a big difference for me as a student ;) Anyway, I'll get to it this afternoon, still have to work before. Don't worry though, I didn't (and won't) forget! Thank you very much for your help! max
RE: CForms Summer of Code project
> Could you please publish your proposal today so that I (and > hopefully Sylvain) > can review it this evening? IIRC proposals have to be handed > in by tommorrow. And don't forget to include (time for) documentation. Bye, Helma
Re: CForms Summer of Code project
Reinhard Poetz wrote: Sylvain Wallez wrote: I also want a second person as official mentor as I will be offline for some weeks over the summer. Anybdoy volunteering? Me, me :-) Thanks Sylvain, I've just added your name to the Wiki page. Hi Max, Could you please publish your proposal today so that I (and hopefully Sylvain) can review it this evening? IIRC proposals have to be handed in by tommorrow. Thanks in advance! -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: CForms Summer of Code project
Sylvain Wallez wrote: I also want a second person as official mentor as I will be offline for some weeks over the summer. Anybdoy volunteering? Me, me :-) Thanks Sylvain, I've just added your name to the Wiki page. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: CForms Summer of Code project
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. 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.) I also want a second person as official mentor as I will be offline for some weeks over the summer. Anybdoy volunteering? Me, me :-) 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. leave it open for now. We will have to talk more about usecases and decide then. 2. Can any widget type be macro-ized or only fields? I guess any would make sense... any type Can macros be extended in the form definition? hmmm, good questions. I'd say yes, but I can't think of a simple syntax now. Ideas? 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? I hope somebody who with in-depth knowledge can answer this. Me too :-) 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? same here as before 5. What about caching or reloading libraries if they changed? How is that handled right now? AFAIU, when the form is created by the FormManager it gets all its widgets set. If a library of the form is changed after that, this doesn't have an impact on "living" form instances. Sorry if I am rambling a bit... Once I get this straightened out, I will post my ideas for a solution on the wiki, like requested. Fine! -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: CForms Summer of Code project
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. 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.) I also want a second person as official mentor as I will be offline for some weeks over the summer. Anybdoy volunteering? 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. leave it open for now. We will have to talk more about usecases and decide then. 2. Can any widget type be macro-ized or only fields? I guess any would make sense... any type Can macros be extended in the form definition? hmmm, good questions. I'd say yes, but I can't think of a simple syntax now. Ideas? 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? I hope somebody who with in-depth knowledge can answer this. 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? same here as before 5. What about caching or reloading libraries if they changed? How is that handled right now? AFAIU, when the form is created by the FormManager it gets all its widgets set. If a library of the form is changed after that, this doesn't have an impact on "living" form instances. Sorry if I am rambling a bit... Once I get this straightened out, I will post my ideas for a solution on the wiki, like requested. Fine! -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: CForms Summer of Code project
Hi Reinhard, Good. Err, should I put my SoC application there then? Seems to me more like a problem statement (for CocoonRefDocProject) than a proposal for a solution... Thanks and bye! max On 6/9/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Max Pfingsthorn wrote: > > Hi! > > > > I have a question. There are two, somewhat conflicting descriptions of > > the CForms project on the wiki: > > > > http://wiki.apache.org/cocoon/CocoonFormsScratchpad > > http://wiki.apache.org/cocoon/WhiteBoardCocoonForms > > > > I guess the most recently edited one (WhiteBoard...) is the most > > preferred one... is that so? I just would like to make sure. > > > > Oh, I am finalizing my proposal now, should I send it here first for a > > quick glance over? > > yes to both questions. I propose that you add your proposal to the wiki > (http://wiki.apache.org/cocoon/GoogleSummerOfCode2005) > > -- > Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach > > {Software Engineering, Open Source, Web Applications, Apache Cocoon} > > web(log): http://www.poetz.cc > > > > > > > ___ > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: > http://mail.yahoo.de > >
Re: CForms Summer of Code project
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. 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? 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? 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? 5. What about caching or reloading libraries if they changed? How is that handled right now? Sorry if I am rambling a bit... Once I get this straightened out, I will post my ideas for a solution on the wiki, like requested. Good night! max On 6/9/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: > Hi Reinhard, > > Good. Err, should I put my SoC application there then? Seems to me > more like a problem statement (for CocoonRefDocProject) than a > proposal for a solution... > > Thanks and bye! > max > > On 6/9/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > > Max Pfingsthorn wrote: > > > Hi! > > > > > > I have a question. There are two, somewhat conflicting descriptions of > > > the CForms project on the wiki: > > > > > > http://wiki.apache.org/cocoon/CocoonFormsScratchpad > > > http://wiki.apache.org/cocoon/WhiteBoardCocoonForms > > > > > > I guess the most recently edited one (WhiteBoard...) is the most > > > preferred one... is that so? I just would like to make sure. > > > > > > Oh, I am finalizing my proposal now, should I send it here first for a > > > quick glance over? > > > > yes to both questions. I propose that you add your proposal to the wiki > > (http://wiki.apache.org/cocoon/GoogleSummerOfCode2005) > > > > -- > > Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach > > > > {Software Engineering, Open Source, Web Applications, Apache Cocoon} > > > > web(log): http://www.poetz.cc > > > > > > > > > > > > > > ___ > > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier > > anmelden: http://mail.yahoo.de > > > > >
Re: CForms Summer of Code project
Max Pfingsthorn wrote: Hi! I have a question. There are two, somewhat conflicting descriptions of the CForms project on the wiki: http://wiki.apache.org/cocoon/CocoonFormsScratchpad http://wiki.apache.org/cocoon/WhiteBoardCocoonForms I guess the most recently edited one (WhiteBoard...) is the most preferred one... is that so? I just would like to make sure. Oh, I am finalizing my proposal now, should I send it here first for a quick glance over? yes to both questions. I propose that you add your proposal to the wiki (http://wiki.apache.org/cocoon/GoogleSummerOfCode2005) -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de