You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Max Pfingsthorn <ma...@gmail.com> on 2005/06/09 16:11:02 UTC
CForms Summer of Code project
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?
Bye!
max
Re: CForms Summer of Code project
Posted by Tim Larson <ti...@keow.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Tim Larson <ti...@keow.org>.
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
Posted by Tim Larson <ti...@keow.org>.
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
Posted by Max Pfingsthorn <ma...@gmail.com>.
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 <re...@apache.org> 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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Max Pfingsthorn <ma...@gmail.com>.
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 <re...@apache.org> 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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Max Pfingsthorn <ma...@gmail.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms Summer of Code project
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Tim Larson <ti...@keow.org>.
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
Posted by Max Pfingsthorn <ma...@gmail.com>.
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 <ma...@gmail.com> 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 <re...@apache.org> 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
Posted by Max Pfingsthorn <ma...@gmail.com>.
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 <re...@apache.org> 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
Posted by Reinhard Poetz <re...@apache.org>.
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