cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: GSoC
Date Thu, 15 Mar 2007 20:20:02 GMT
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


Mime
View raw message