Re: summer of code
Will Holcomb wrote:
Hi, I'm a student with a project idea that I think might be a good
addition to Cocoon and I have a couple of questions.
#1. Does Cocoon have to apply to SoC on it's own, or will it be inducted
as a part of Apache?
It's the Apache Software Foundation.
I ask because the mentorship applications are only open March 8-12. My
web researchings suggest nothing has to be done right now by anyone in
this project, but I'm only about 90% sure.
Do you have any suggestions for a project? Unfortunately I won't have
time to get involved myself this year.
#2. When is a production release expected for Cocoon 3?
I will work on another release some time later this month or in April.
It will take some time until we get a production release out of the door.
I'm hoping for my SoC project to power my Burning Man art. I've done
tests with both versions 2 and 3, and I'm leaning toward 3, but I don't
want my art to crash. ☺
Some Cocoon 3 APIs might change (e.g. we have to find some way to make
the output type of a pipeline more flexible), but the implementation is
rather stable IMO. I also expect that your chances of finding a mentor
are best with Cocoon 3. As mentioned above, write down your ideas of a
Cocoon 3 GSoC project and share them with this community. Then let's
find a mentor for your project.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
summer of code
Hi, I'm a student with a project idea that I think might be a good addition to Cocoon and I have a couple of questions. #1. Does Cocoon have to apply to SoC on it's own, or will it be inducted as a part of Apache? I ask because the mentorship applications are only open March 8-12. My web researchings suggest nothing has to be done right now by anyone in this project, but I'm only about 90% sure. #2. When is a production release expected for Cocoon 3? I'm hoping for my SoC project to power my Burning Man art. I've done tests with both versions 2 and 3, and I'm leaning toward 3, but I don't want my art to crash. ☺ -Will signature.asc Description: This is a digitally signed message part
google summer of code: ajax
Hello, I talked to Reinhard Poetz yesterday about a Google Summer of Code proposal including some ajax-enhancements for cforms. I gained experience using dojo and google-maps alongside cocoon in my latest projects and would be pleased to contribute to the community. My prososal can be found in the wiki at http://wiki.apache.org/general/SummerOfCode2006/cocoon-ajax#preview Best regards Matthias
Re: google summer of code: ajax
Matthias Epheser wrote:
Hello,
I talked to Reinhard Poetz yesterday about a Google Summer of Code
proposal including some ajax-enhancements for cforms.
I gained experience using dojo and google-maps alongside cocoon in my
latest projects and would be pleased to contribute to the community.
My prososal can be found in the wiki at
http://wiki.apache.org/general/SummerOfCode2006/cocoon-ajax#preview
First, it's great to see you on the list :-)
I've been working together with Matthiass since last year and I'm sure his
contributions via GSoC would add some great things to cForms. I'm willing to
become his mentor, but as we are working together most of our time, I would
prefer if somebody else could do it. Any volunteers?
--
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: google summer of code: ajax
Reinhard Poetz wrote: I've been working together with Matthiass since last year and I'm sure his contributions via GSoC would add some great things to cForms. I'm willing to become his mentor, but as we are working together most of our time, I would prefer if somebody else could do it. Any volunteers? I'm not a Dojo super expert, but I've digged a lot in the ajax code of cocoon forms, know the XSLTs and the repeater binding class by heart, and studied the Google Map API, and will be in my office in June, July and maybe greatest part of August. So if nobody with higher skills on Dojo is voluteering for it, I'm available. Simone -- Simone Gianni
Re: google summer of code: ajax
Simone Gianni wrote:
Reinhard Poetz wrote:
I've been working together with Matthiass since last year and I'm sure
his contributions via GSoC would add some great things to cForms. I'm
willing to become his mentor, but as we are working together most of
our time, I would prefer if somebody else could do it. Any volunteers?
I'm not a Dojo super expert, but I've digged a lot in the ajax code of
cocoon forms, know the XSLTs and the repeater binding class by heart,
and studied the Google Map API, and will be in my office in June, July
and maybe greatest part of August.
So if nobody with higher skills on Dojo is voluteering for it, I'm
available.
Thanks that's great! I just want to remind you that mentoring is not about
knowing all the technical details but being a guide for the student so that he
learns the opensource way of doing software development (or in our case the
Apache way of *open* development).
In order to become mentor, please read
http://code.google.com/soc/mentorfaq.html.
--
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: google summer of code: ajax
Hi Reinhard, Reinhard Poetz wrote: Thanks that's great! I just want to remind you that mentoring is not about knowing all the technical details but being a guide for the student so that he learns the opensource way of doing software development (or in our case the Apache way of *open* development). Yep, sure, but I think it's in the interest of the cocoon community to have the project done, so the mentor should also be able to tell the student the right direction of doing something, and to evaluate if he did things right and as expected, thus knowing what he's taling about. Anyway, if he's sitting aside you, I don't think this will ever be a problem :) Simone -- Simone Gianni
Google Summer of Code - the last minutes
Dear Cocooners, First of all I would like to thank the community for the great experience here. I really loved being part of the team! :) Now, a few minutes before the extended deadline, I am finally _done_. All samples work, docs are written and tests pass! Its a great feeling ;) Here is a little description of what I did: It is now possible to write separate collections of widget definitions and bindings which can be dynamically included. These are called libraries and can be imported into other libraries or form definitions/bindings. This doesn't mean these are automatically used in the including definitions or bindings, but they are available for reuse. Also, cache validation is checked recursively through all dependencies, so if a library deep in the inclusion tree changes, the complete path to the final definition or binding will be invalidated. This is something I always disliked with xsl:include/, so I fixed it here. There are three features implemented now: - Importing of external libraries into another library or form definition This works by mapping names to uris like so 'fd:import prefix=name uri=some/uri/to/a/library/'. Widgets inside the library can be referenced using name:widgetId. - Instantiating widgets from imported libraries This is done via 'fd:expand id=name:widgetId/' and directly evaluates to the referenced WidgetDefinition. This means that if a definition is expanded in a library, it can be reused in an importing definition/binding as if it was defined in the library itself. - Inheriting from other definitions/bindings An extra attribute extends on any widget definition or binding will cause the referenced entity to be resolved and used in the initialisation of the current definition or binding. This way, it is possible to override things like ids, datatypes, labels, xpaths and such and add things like validators or new child widgets or bindings. Widgets may also extend other widgets in the same container, meaning for example two widgets in the same group may extend each other, or two top-level widgets in a form may do the same. Not though that it is not possible to form cycles as references are resolved right away and cycles will result in silent ignores because of nonexisting widgets. This should change to complaining exceptions, and the code is there, just has to be uncommented. There are a few restrictions though: The complex Tree widget unfortunately does not support inheritance yet, however you can define it in a library and expand it in your form if you use it in many places. Also, single validators can only be added, not replaced or extended, since there is no way to address them right now. Same goes for selection list items, it is only possible to reset the selection list to something else. In case you want to know more, you can read the daisy page documenting the library subsystem [1]. My original proposal is still on the wiki [2]. To testdrive the new forms features, do this: - in your working copy of the trunk, cd to src/blocks/forms/trunk - svn switch https://svn.apache.org/repos/asf/cocoon/gsoc/mpfingsthorn/forms (svn will switch this part of the path to the repository above and update your working copy) - do a build in the root of the working copy - check out the forms samples! Thanks again for your opportunity and I am very much looking forward to contribute some more! Best regards, Max Pfingsthorn [1] Daisy page: http://cocoon.zones.apache.org/daisy/documentation/forms/685.html [2] Original proposal: http://wiki.apache.org/cocoon/CocoonFormsLibraryProject Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
Re: Google Summer of Code, cocoon-refdoc project
(FYI dev@ people: Robert Graham has been selected for the cocoon-refdoc GSoC project, more info will follow here early next week) Hi Robert, Le 2 juil. 05, à 06:27, Robert Graham a écrit : I have unfortunately been unexpectedly out of internet service for almost a week, but I finally got the news... Great! I was wondering what was happening, good to see you back. I'm anxious to get going, where to start? I have some prototype code that I will upload to the Cocoon repository early next week. I'll send info on the dev@ list when it's done, I think it will be a good basis to refine the specs for your project. If you already haven't, you should subscribe to the following Cocoon-related mailing lists: - dev@cocoon.apache.org (that's where all our project-related communication will happen) - users@cocoon.apache.org - docs@cocoon.apache.org - [EMAIL PROTECTED] And if you want to learn more about the ASF you'll find information at http://www.apache.org/foundation/how-it-works.html. I'll be offline on holidays from July 9th to 16th, so we'll need to get the project going next week, As usual before leaving for a holiday, it's going to be a busy week for me, but we'll make it happen! -Bertrand smime.p7s Description: S/MIME cryptographic signature
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
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
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:
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
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
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
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
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
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 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
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: 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
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
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
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
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
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
Summer of Code: cocoon-refdoc spec
I have written a first spec for this project, see http://wiki.apache.org/cocoon/CocoonRefDocProject Comments are welcome of course. -Bertrand, who'd love to be a student ;-) smime.p7s Description: S/MIME cryptographic signature
Added new google summer of code project: XUL based user interface for Cocoon forms
Hi: I just added a new project in Google Summer of code. I hope to expect to find nother committer that knows XUL (Joerg?). Here is the description of the project: Subject ID: cocoon-cforms-xul-user-interface Title: XUL based user interface for Cocoon forms Keywords: Cocoon, Cocoon Forms, widgets, XUL Description: The project goal is to create a new user's interface rendering for cforms using Mozilla XUL. Currently cforms has only an interface for HTML. The user interface should be easily switchable HTML-XUL depending of the client browser. Possible Mentors: Antonio Gallardo Status: Available ** Is the project OK? Best Regards, Antonio Gallardo
Re: Google Summer of Code - projects and mentors wanted
Sylvain Wallez wrote:
Don't want to rain on the party, but this is *summer* of code, meaning 2
months of work[2]. Expecting students to implement difficult things
(e.g. continuations serialization)
After skim reading the project proposals of other Apache projects and the other
OS projects I disagree that the level of continuations serialization and the
attribute based template engine is too high. 2 months of work means (at least in
Austria) 640 hours work time which is a lot. Of course, if you have to learn
Java first, the time won't be enough. And don't forget, IIRC it was a student
who founded our beloved Cocoon ;-)
From my personal experience over the last years I'm sure that there are many
clever students out there who are definitly able to implement the difficult
topics like Rhino scope and continuations serialization but they haven't had the
itch to scratch. $4500 could change their minds ;-).
And not to forget, continuation serialization in particular, is probably more a
Rhino topic than Cocoon topic. If the students get the serialization of Rhino
scopes and continuations working, we can tackle *together* the very
Cocoon-specific topics like Avalon components and the service manager.
In the worst case nobody will apply for the topic which would mean that sooner
or later we will have to do it ourselves ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Le 3 juin 05, à 08:26, Reinhard Poetz a écrit : ...From my personal experience over the last years I'm sure that there are many clever students out there who are definitly able to implement the difficult topics like Rhino scope and continuations serialization but they haven't had the itch to scratch. $4500 could change their minds ;-)... Agreed, and by selecting 200 students out of all those who apply (I guess there will be much more than 200 applications) means only the best ones will be selected. But the burden will be on us to evaluate whether the applying student has what it takes - like we'd do for an internship I guess. -Bertrand smime.p7s Description: S/MIME cryptographic signature
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: Google Summer of Code - projects and mentors wanted
Bertrand Delacretaz wrote:
Cocoonistas,
You might have noticed yesterday's announcement at
http://code.google.com/ about the Summer of Code initiative,
http://code.google.com/summerofcode.html
We should have more detailed info for the ASF communities in the next
few days (we're still ironing out the details about project sandboxes,
CLAs etc.), but as the initiative is public already, project
propositions are welcome at
http://wiki.apache.org/general/SummerOfCode2005.
Each project needs to have at least one mentor (who must be a committer
AFAIK, but various models might be possible) to happen, so that students
are not lost in the dark.
I have entered a project at
http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc, and I'm
looking for at least one co-mentor, as I'll be partially offline in July
and August. If someone's available for this, please let me know.
Are we allowed to offer another project? I would like to propose
http://issues.apache.org/bugzilla/show_bug.cgi?id=33324
(http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication).
I volunteer as mentor and as Betrand I'm looking for a co-mentor as I will be
offline for two or three weeks.
--
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: Google Summer of Code - projects and mentors wanted
Le 2 juin 05, à 11:56, Reinhard Poetz a écrit : ...Are we allowed to offer another project? I would like to propose http://issues.apache.org/bugzilla/show_bug.cgi?id=33324 (http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication)... Sure, there's no problem in having several Cocoon-related projects! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
Bertrand Delacretaz wrote:
Le 2 juin 05, à 11:56, Reinhard Poetz a écrit :
...Are we allowed to offer another project? I would like to propose
http://issues.apache.org/bugzilla/show_bug.cgi?id=33324
(http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication)...
Sure, there's no problem in having several Cocoon-related projects!
Fine! Any volonteers for the role of the second mentor?
---
One question to the role of the mentor: AFAIU it's about guiding him but I won't
be able to answer all questions in detail - if I could I would have done it
myself ;-)
Am I right here?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Le 2 juin 05, à 12:22, Reinhard Poetz a écrit : ...One question to the role of the mentor: AFAIU it's about guiding him but I won't be able to answer all questions in detail - if I could I would have done it myself ;-).. That's how I understand it: the mentor is the contact person, can help about where to find the answers but does not necessarily know them. See also http://code.google.com/mentfaq.html under What is the role of a mentoring organization?. IMO all this will be the mentor's responsibility for the mentored projects. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
Reinhard Poetz wrote: Bertrand Delacretaz wrote: Le 2 juin 05, à 11:56, Reinhard Poetz a écrit : ...Are we allowed to offer another project? I would like to propose http://issues.apache.org/bugzilla/show_bug.cgi?id=33324 (http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication)... Sure, there's no problem in having several Cocoon-related projects! Fine! Any volonteers for the role of the second mentor? --- One question to the role of the mentor: AFAIU it's about guiding him but I won't be able to answer all questions in detail - if I could I would have done it myself ;-) Am I right here? The way I see it is that the design discussion should occur through the normal develpoment channels, so the idea is they do some background work and come back to the community with a proposal or RT, once the design is complete they have to implement it. Again, problems are solved through the normal community channels. Ross
Re: Google Summer of Code - projects and mentors wanted
Ross Gardler wrote:
Reinhard Poetz wrote:
Bertrand Delacretaz wrote:
Le 2 juin 05, à 11:56, Reinhard Poetz a écrit :
...Are we allowed to offer another project? I would like to propose
http://issues.apache.org/bugzilla/show_bug.cgi?id=33324
(http://wiki.apache.org/cocoon/FlowscriptAndSessionReplication)...
Sure, there's no problem in having several Cocoon-related projects!
Fine! Any volonteers for the role of the second mentor?
---
One question to the role of the mentor: AFAIU it's about guiding him
but I won't be able to answer all questions in detail - if I could I
would have done it myself ;-)
Am I right here?
The way I see it is that the design discussion should occur through the
normal develpoment channels, so the idea is they do some background work
and come back to the community with a proposal or RT, once the design is
complete they have to implement it. Again, problems are solved through
the normal community channels.
Bertrand and Ross, thanks for your answers. Find the project description at
http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-serialization.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Reinhard Poetz wrote:
http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc
http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-serialization.
Do we have something else on our wishlists (some fancy cforms features, etc.)?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
RE: Google Summer of Code - projects and mentors wanted
Do we have something else on our wishlists (some fancy cforms features, etc.)? An effort to substancially reduce the number of open issues in bugzilla? Bye, Helma
Re: Google Summer of Code - projects and mentors wanted
Reinhard Poetz wrote: Reinhard Poetz wrote: http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-serialization. Do we have something else on our wishlists (some fancy cforms features, etc.)? I posted the answer under wrong subthread: 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... -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Google Summer of Code - projects and mentors wanted
Linden H van der (MI) wrote:
Do we have something else on our wishlists (some fancy cforms
features, etc.)?
An effort to substancially reduce the number of open issues in bugzilla?
I have thought about something similar too but it is difficult to set it up as
single project with a clearly defined project goal.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Linden H van der (MI) wrote: Do we have something else on our wishlists (some fancy cforms features, etc.)? An effort to substancially reduce the number of open issues in bugzilla? 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. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Google Summer of Code - projects and mentors wanted
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?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Google Summer of Code - projects and mentors wanted
Reinhard Poetz wrote: Reinhard Poetz wrote: http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-serialization. Do we have something else on our wishlists (some fancy cforms features, etc.)? Web service integration. It is a common user requirement and we have a number of implementations with various properties and also some variants within Cocoon. But we have nothing coherent yet. Also the Axis 2.0 architecture seem quite interesting. I'm interested enough to do some mentoring in the area but not enough to implement anything in the near future. /Daniel
Re: Google Summer of Code - projects and mentors wanted
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? I can at least be a co-mentor for the attribute driven templates. /Daniel
Re: Google Summer of Code - projects and mentors wanted
Le 2 juin 05, à 13:51, Reinhard Poetz a écrit : ...Do we have something else on our wishlists (some fancy cforms features, etc.)? People with ideas are welcome to write them up at http://wiki.apache.org/general/SummerOfCode2005, even if no mentor is available yet. In that case, putting dev@cocoon.apache.org as the contact address and a note like we're still looking for a mentor would be ok. If some of us are thinking of mentoring one project but not more, it might help in doing a dynamic allocation of mentors to projects which actually happen. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
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? I propose that me and Daniel (as he already agreed in other post) co-mentor template project and Tim does the cforms (if he wants to of course). I would surely love to contribute in both areas. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Google Summer of Code - projects and mentors wanted
Linden H van der (MI) wrote: Do we have something else on our wishlists (some fancy cforms features, etc.)? An effort to substancially reduce the number of open issues in bugzilla? Unfortunately, the bugs in bugzilla are likely to require a level of knowledge of Cocoon that we are unlikely to meet in any of our students, which is a shame :-( We really need to think of interesting projects that they are likely to be attracted to, and that form clearly defined and measurable projects. Regards, Upayavira
Re: Google Summer of Code - projects and mentors wanted
Linden H van der (MI) wrote: An effort to substancially reduce the number of open issues in bugzilla? IMO this would be more something for a FirstFriday if these are still happening. Jorg
RE: Re: Google Summer of Code - reinstate FirstFridays?
Linden H van der (MI) wrote: An effort to substancially reduce the number of open issues in bugzilla? IMO this would be more something for a FirstFriday if these are still happening. Sounds good to me too. Why was the idea dropped in the first place? I haven't joined them but got the impression that it were fun times for the committers. Bye, Helma
Re: Google Summer of Code - projects and mentors wanted
Leszek Gawron wrote: 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? I propose that me and Daniel (as he already agreed in other post) co-mentor template project and Tim does the cforms (if he wants to of course). I would surely love to contribute in both areas. Wrote a proposal for ATL: http://wiki.apache.org/general/SummerOfCode2005#cocoon-atl Leszek, add your email and update the description if you want to change or add anything. /Daniel
Re: Google Summer of Code - reinstate FirstFridays?
Le 2 juin 05, à 15:11, Linden H van der ((MI)) a écrit : ...Sounds good to me too. Why was the idea dropped in the first place? I haven't joined them but got the impression that it were fun times for the committers... I don't think it was formally dropped, but it died for lack of active participants. And yes it was fun! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
Sylvain Wallez wrote: Ralph Goers wrote: Reinhard Poetz wrote: Do we have something else on our wishlists (some fancy cforms features, etc.)? What about some ajax stylings for cforms? Some I'd love to have are: - cocoon suggests ajax styling for cforms fields providing autocompletion of inputs, - reorderable repeaters [1] 1. Convert all poolable gnerators, and transformers to be thread safe. +1 2. Modify the build process to use maven. ... or rewrite the ant builds to use the library task and without generating the blocks build file with XSLT. Don't want to rain on the party, but this is *summer* of code, meaning 2 months of work[2]. Expecting students to implement difficult things (e.g. continuations serialization) or cleaning up the bugzilla, even all this is badly needed, seem too complicated to me for a student discovering our code base. So subjects that have a chance to be successful in terms of candidates and result are those that don't need to much in-depth knowledge of the core and have a clear functionnal scope. Agreed. However, before creating proposals it would also be nice to know that there is buy-in from the committers that a proposal should be made. I wouldn't want to propose something that other committers would object to. Sylvain [1] http://tool-man.org/examples/edit-in-place.html#listExamples [2] http://code.google.com/summfaq.html Ralph
Re: Google Summer of Code - projects and mentors wanted
On Jue, 2 de Junio de 2005, 16:50, Sylvain Wallez dijo: Ralph Goers wrote: Reinhard Poetz wrote: Do we have something else on our wishlists (some fancy cforms features, etc.)? What about some ajax stylings for cforms? Some I'd love to have are: - cocoon suggests ajax styling for cforms fields providing autocompletion of inputs, - reorderable repeaters [1] What about the XUL interface for cforms? I will like to add this project. First I want to know what you think about this 2 months task? http://issues.apache.org/bugzilla/show_bug.cgi?id=25295 Best Regards, Antonio Gallardo
Google Summer of Code - projects and mentors wanted
Cocoonistas, You might have noticed yesterday's announcement at http://code.google.com/ about the Summer of Code initiative, http://code.google.com/summerofcode.html We should have more detailed info for the ASF communities in the next few days (we're still ironing out the details about project sandboxes, CLAs etc.), but as the initiative is public already, project propositions are welcome at http://wiki.apache.org/general/SummerOfCode2005. Each project needs to have at least one mentor (who must be a committer AFAIK, but various models might be possible) to happen, so that students are not lost in the dark. I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc, and I'm looking for at least one co-mentor, as I'll be partially offline in July and August. If someone's available for this, please let me know. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
Bertrand Delacretaz wrote: Cocoonistas, You might have noticed yesterday's announcement at http://code.google.com/ about the Summer of Code initiative, http://code.google.com/summerofcode.html We should have more detailed info for the ASF communities in the next few days (we're still ironing out the details about project sandboxes, CLAs etc.), but as the initiative is public already, project propositions are welcome at http://wiki.apache.org/general/SummerOfCode2005. Each project needs to have at least one mentor (who must be a committer AFAIK, but various models might be possible) to happen, so that students are not lost in the dark. I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc, and I'm looking for at least one co-mentor, as I'll be partially offline in July and August. If someone's available for this, please let me know. Bertrand, I will be willing to be a second mentor on this, although we will have to compare dates in July as I will be away for a week around ApacheCon. Also, I'm not a committer here at Cocoon only at Forrest so I'm not sure howthat affects your comment must be a committer AFAIK, but various models might be possible I've also added a Forrest project at http://wiki.apache.org/general/SummerOfCode2005#forrest-voice Ross
Re: Google Summer of Code - projects and mentors wanted
Hi Ross, Bertrand Delacretaz wrote: I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc, and I'm looking for at least one co-mentor, as I'll be partially offline in July and August. If someone's available for this, please let me know. Bertrand, I will be willing to be a second mentor on this, although we will have to compare dates in July as I will be away for a week around ApacheCon. Great! I'll be mostly online during ApacheCon, so between us two we should be able to cover the whole period. I've added you as a second mentor. ...Also, I'm not a committer here at Cocoon only at Forrest so I'm not sure howthat affects your comment must be a committer AFAIK, but various models might be possible.. I don't think this will be a problem, and IIUC the plan is to have students work in dedicated sandboxes anyway. We'll sort it out in due time I think. ...I've also added a Forrest project at http://wiki.apache.org/general/SummerOfCode2005#forrest-voice.. Sounds good (or will sound good ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Google Summer of Code - projects and mentors wanted
I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc An excellent proposal! I'll be around during that period and am keen to offer my 2p also. Mark
Re: Google Summer of Code - projects and mentors wanted
Le 1 juin 05, à 13:51, Mark Leicester a écrit : I have entered a project at http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc An excellent proposal! I'll be around during that period and am keen to offer my 2p also. Thanks! Of course, all technical discussions about these projects will happen on the respective mailing lists, so you'll be more than welcome to give feedback and/or help the students. IIUC the role of the mentors is more a committment to the student (and to Google) that someone will be here to assist them and assess their work, but actual work is meant to happen right here, in collaboration with all community members as usual. The ASF still has to clarify how to allow the students to contribute their code easily, as they won't be given full commit access unless they're committers already, but we want them to get acquainted with the actual process that we're using. We might use SVN sandboxes or branches with different access rights, but this hasn't been formally decided yet. I think it's like having an intern work at your company: you want them to have the tools but not to use the really sharp ones on their own. -Bertrand smime.p7s Description: S/MIME cryptographic signature
