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 Fri, 16 Mar 2007 21:48:36 GMT
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

Mime
View raw message