Daniel Fagerstrom napisał(a):
Grzegorz Kossakowski skrev:
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).
Thanks, I'll recall it for you while hassling you about some
information/help ;-)
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 ;)
Yes, you got me :)
* 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.
Thanks for all information you provided. In general, concept is nice and
interesting but I think it's not the centre of my attention right now.
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.
Call me old fart but I really do not like too much client side coding. I
think that existence of IE can soak all the positive energy and make
development not being fun anymore. However, I would be pleased to see
your results.
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.
Yes, you are provocative here and to be honest not really convince me
but I think it wasn't your goal to do so. I really prefer having good,
stable, documented and powerful form framework than new, shiny and
fashionable form framework :-)
I think that it must be provided a long sequence of good arguments to
throw out one of the best Cocoon's block and start implementing new one...
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.
All these ideas/concepts you provided above are interesting but I think
that I have not enough knowledge/vision to drive development into
completely new field.
That's the reason why I started to collaborate on servlet-services - I
knew what's was the aim, understood the vision thus had an idea how to
work on it. I could do a lot of work in various fields but I do not
consider myself skilled enough to start something from scratch.
Given that, you can count on me when you start working on anything from
the list you provided.
--
Grzegorz Kossakowski
