Grzegorz Kossakowski skrev:
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?
Yes!
I also wonder why only Reinhard offered mentoring this year. Are others so busy
or missed the chance to add themselves?
Unfortunately I am and have been far to busy and have not been able to
give Cocoon the attention that I would like. So I don't think I would be
able to give a student, that might be fairly new to open source and our
project, the direction that he or she would deserve.
In your case it is of course quite different as you already are part of
the community and know how things work. So I would be happy to mentor
whatever project you would like to work on (given that it is within some
area that I know something about).
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? ;-)
I agree that we should strive for a little bit more. Do you have any
ideas about what?
What about postable servlet services, or do you think that you have
finished them long before the summer starts ;)
* 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?
http://wiki.apache.org/cocoon/Templates,
http://wiki.apache.org/cocoon/AttributeTemplates.
Why it's needed?
It is much friendlier to tools like Dreamweaver. The idea is that a
designer and/or content provider create a html page example and that a
developer adds "life" to the page by providing attributes. For tools
like Dreamweaver you need to provide special configuration files to make
it able to work with a tag based template system like JXTG. Tools
Dreamweaver don't care about foreign attributes.
What features it's going to have that our Template block does not have?
No extra features at all ;) In fact I would suggest to make it as
minimal as possible.
Actually I working on implementing a browser side (see
http://ajaxpatterns.org/Browser-Side_Templating for explanation of the
concept) attribute template language in Javascript right now. What would
be really cool would be to have a server side implementation of it as
well so that we get "Dual-Side Templating"
http://ajaxpatterns.org/Dual-Side_Templating. So that you can use the
same template both server side and client side depending on the
situation and need.
* 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
OK
* use Dojo throughout in cForms
What does this mean exactly?
Don't know.
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?
A modern form framework
=======================
Being a little bit provocative I'm starting to find CForms rather old
fashioned in style. Why so much server side stuff wouldn't it be better
with a form framework where most of the form framework is client side
and invokes REST style web services for the CRUD operations on the
server side resource that the form updates.
Also we could need some "convention before configuration" and "don't
repeat yourself" in our forms framework. JBoss Seam (
http://labs.jboss.com/portal/jbossseam/,
http://www.infoq.com/articles/jboss-seam) does some cool stuff that we
could imitate. Especially it uses Hibernate annotations for form
validation
http://docs.jboss.com/seam/1.2.0.PATCH1/reference/en/html/validation.html.
Spring actions
==============
With AJAX it is much easier to have a stateless web server as backend.
But Cocoon's "recommended" controllers: Flowscripts and Javaflow main
focus is on session based servers. And Cocoon actions isn't exactly the
most exciting technology around.
I'd like actions that embrace dependency injection, doesn't need to
implement some obscure interface and that can be easily used with a
reloading classloader. IMO the action part of Struts2
(http://www.infoq.com/articles/converting-struts-2-part1) has a lot of
god ideas. Either we could try to make it possible to use the Struts2
action framework as Cocoon actions or steal some of their ideas.
REST
====
Gianugo has evangelized using Cocoon as a REST framework (couldn't find
any link though). Steve Loughran says that the Cocoon folk has a better
idea about what to do in the REST area than the WS projects:
http://www.1060.org/blogxter/entry?publicid=8C08746C8C0462CC6FB4E4D69098F1AE.
That is soomething to live up to ;)
Cocoon already have a lot of what is needed but lacks e.g. a mechanism
for content negotiation and ETags support and more work is needed on
return codes. What especially is lacking is REST samples and a tutorial
on how to use Cocoon as a REST web service server.
OSGification
============
With Spring-OSGi (http://www.springframework.org/osgi) and a lot of work
done for using OSGi for enterprise systems in the Felix and Eclipse
communities, it would be much more feasible to OSGify Cocoon today than
it was a year ago.
/Daniel
