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
