Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <45F8F9BE.5040301@apache.org>
Date: Thu, 15 Mar 2007 08:46:06 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: GSoC
References: <45F87D8C.9010605@tuffmail.com>
In-Reply-To: <45F87D8C.9010605@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit

Grzegorz Kossakowski wrote:
> Hello,
> 
> I would like to ask you about my possible participation in GSoC and having Cocoon as a project of choice, of course. Do
> you think it's good idea in general?
> 
> I also wonder why only Reinhard offered mentoring this year. Are others so busy or missed the chance to add themselves?
> 
> Now to discuss some details of my possible work. I'm going to discuss/question shortly almost all the options.
> 
> * Rework our samples in trunk so that they use the servlet-service framework
> As you probably guess this one is my favorite. Given that I have some knowledge about servlet-service-fw I wonder if
> it's not too simple task for 2 months period? Maybe you could soak little bit more from me?  ;-)

The ideas come from me so far and this one would be definitly to easy for _you_. 
Since I will mentor a students' project in Vienna this summer and my students 
most probably don't have any experiences with Cocoon, I will propose to them a 
rework and redesign of our samples.

> * Attribute-based templates (extend cocoon-template for this purpose)
> I recall some discussions on this topic but cannot now find exact archives. Could someone provide little introduction in
> this topic? Why it's needed? What features it's going to have that our Template block does not have?

see http://wiki.apache.org/cocoon/Templates, the section about Attribute Driven 
Templating (ADT)

But this requires either Leszek or Daniel as mentor. I definitly don't have an 
in-depth understanding of it.

> * Documentation of our blocks (+ sitemap component documentation)
> I think this one is important but cannot be project idea for GSoC:
> http://code.google.com/support/bin/answer.py?answer=60315&topic=10727

but would be perfect for the OSC project in Vienna :-)

> * use Dojo throughout in cForms
> What does this mean exactly?

AFAICS we still include the "matt-kruse" libs and htmlarea. The latter should 
become optional and there should be an additional implementation of WYSIWIG 
input fields using Dojo functionality. The matt-kruse libs are used for some 
advanced widgets.

If you are interested in working on cForms, "use Dojo throughout in cForms" will 
probably only be one part of a project IMO. I would also like to see some more 
refactorings:

  - Springifying cForms
    (http://marc.theaimsgroup.com/?t=116954345700002&r=1&w=2)
  - support a simple styling that works *without* Javascript
  - make cForms work with Saxon

and some more ideas that could go into a cForms proposal:
  - make Forms objects serializable
  - replace xreporter expressions using some other expression library

Sidenote: All those steps go towards cForms 2.0 as I'm not sure whether we can 
implement everything in a backwards compatible way.

> Given that you have some idea of my skills and Cocoon knowledge I would like to ask if you possibly have some other
> ideas that I could bring into the code?

As I said before, if there are students here in Vienna who want to work on 
Cocoon, I want to propose to them a refactoring of our samples and writing 
documentation.
Aside from being feasible for beginners, this is a task that can be split into 
smaller sub-tasks much easier than e.g. implementing ADT. Opposed to GSoC, there 
will be mixed teams of 4 to 6 students (e.g. 3 programmers + 2 designers) at the 
Vienna students' projects.


                                   - o -


And finally some more project ideas:

  a) cleanup input modules: IIRC there was some discussion about
     reducing the number of input modules in favor of one that uses an expression
     language that works on a well-defined object model.

  b) cleanup expression language usage throughout Cocoon
     Daniel, do you have any pointers?

  c) provide an alternative continuations manager that can work with
     distributed caches

  d) refactor <map:call function=""/> and <map:flow>
     * make it possible to support more than one flow language per sitemap
     * find some better naming than "function" because it feels strange to
       call e.g. an Apple or a JavaFlow

  e) Cocon Javaflow 1.0 + integration with the reloading classloader stuff:
     --> whatever needs to be done to get it stable ;-)


I think that (a + b) or (c + d + e) could be interesting projects.


                                   - o -


Grek, my personal preference for your GSoC project goes towards the c+d+e 
project. This needs some involvement by Torsten and, highly recommended, him as 
mentor but I don't know whether he wants to take mentorship again.
*My* second choice is the cForms refactorings. Of course you are free to suggest 
to us whatever you like :-)


-- 
Reinhard P�tz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de