cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: GSoC
Date Thu, 15 Mar 2007 19:25:44 GMT
Reinhard Poetz wrote:
> Grzegorz Kossakowski wrote:
>
> 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.

Thanks for this link. I'll look into this little bit later and share my
thoughts.

>
>> * 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.

Intersting and ambitious enough :-)
I would even one more point:
* expose servlet services that can be used for handling forms rendering
(including support for AJAX) so you don't have to include those scarying
sitemap snippets that are responsible for forms rendering.

>
>> 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.

Ok, I'll be happy to leave this simpler tasks for them.

>
>
>                                   - 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.

I was thinking about (a+b) too. I think that it would be great
achievement for Cocoon to have one, unified, coherent object model and
at least one expression language having our support and being a
reference implementation of expressions languages that could be plugged
into Cocoon.

I agree that (c+d+e) is also interesting but I fear it would be much
more difficult for me. I have only a little expierence with JavaFlow and
do not know much about both continuations manager internals and
reloading classloader stuff. I could accept challenge only being sure
that good support from mentor is provided.

>
> 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 :-)
I'm really grateful for your response; all ideas are really interesting!
I would add even one more:
* refactoring of pipeline stuff
  While working on improving HTTP-compliance of pipelines I had a
feeling (expressed in few comments) that pipeline code really needs
major redesign and refactoring. Current code is really obscure,
hard-to-follow and full of hacks. It's really a challenge to make a only
minor change in it being sure that nothing is going to break. Situation
is even worse, that there are only few tests provided for pipeline code.
My idea was to write lots of tests _before_ doing any refactorings
covering all the code in pipeline module and start reimplementing
classes with effort to not change APIs too much. However, small changes
would be needed IMHO.

I only wonder if there is a volunteer that woud like to mentor such a
project. Also, I wonder if it's even doable in two months as this
changes would involve lots of discussion and the task in general is
really challenging.

What do you think?

-- 
Grzegorz Kossakowski

Mime
View raw message