subject:"\[GSoC_2008\] Project ideas"


Vadim Gritsenko pisze:


I'd change the order a bit. First I'd suggest to make sure (and fix if 
necessary) existing samples. Once this is done, the block should be 
released. After that, you could start (as necessary) avalon to spring 
migration, and development of new samples.


+1 for this proposal provided it's not too much work to get Avalon-based 
samples to work.

--
Grzegorz

Re: [GSoC_2008] Project ideas


Lukas Lang pisze:

hey everybody,


Hi Lukas,

i'm the student, who's interested in participating in a GSoC 
cocoon-project.


I've participated in GSoC last year and I'll be happy to help you with whatever 
problem you encounter.


two days ago i had a conversation with Reinhard and as i read on the list,
he told me raising CForms from Dojo 0.4 upto Dojo 1.1 as a GSoC project 
would not be the best way to do so,

due to Jeremy's work on this.

he pointed out that several blocks and related examples yet don't work 
in cocoon-2.2 and
a great part of cocoon's users would take advantage of porting 
frequently used, cohesive blocks to version 2.2.


migrating the following blocks could be a realistic aim:

- cocoon-eventcache
- cocoon-jms
- cocoon-webdav
- cocoon-repository


What about cocoon-linkrewriter block? It's very small but yet very important block that should be 
migrated to Spring.



my suggestion would consist of:

- creating a test-environment
- writing integration tests
- replacing avalon by spring
- making existing samples work
- developing new samples


Looks good. I would add one more thing:
  - writing general migration guide from Avalon to Spring

You could just dump your experiences gained during GSoC and as result there should be one long 
tutorial discussing different aspects of Avalon - Spring migration. This is a very desired thing 
for existing Cocoon users.


--
Grzegorz Kossakowski

Re: [GSoC_2008] Project ideas

2008-03-29 Thread Lukas Lang


hey,

I've participated in GSoC last year and I'll be happy to help you with 
whatever problem you encounter.


thanks for your dedication! i already noticed that there are great and 
ambitious activities going on.

What about cocoon-linkrewriter block? It's very small but yet very 
important block that should be migrated to Spring.


i'm not sure about including further blocks into my summer activities, but 
obviously linkrewriter is not that much.


Looks good. I would add one more thing:
  - writing general migration guide from Avalon to Spring


that's an awesome idea! i will add it to my application immediately.

You could just dump your experiences gained during GSoC and as result 
there should be one long tutorial discussing different aspects of Avalon 
- Spring migration. This is a very desired thing for existing Cocoon 
users.




i already had the idea of filing my experiences blog-shaped, but i don't mind 
if it's written more impartially to achieve more approval ,-)

@Vadim: order changed
@Reinhard: documentation added


regards,
lukas

Re: [GSoC_2008] Project ideas


Vadim Gritsenko pisze:

On Mar 17, 2008, at 11:30 AM, Grzegorz Kossakowski wrote:


Reinhard Poetz pisze:
My statement was meant to be more general (SSF + Spring migration + 
Schema support).
For an SSF project only, I don't see enough work (I only know about 
SAX buffering and support for redirects as missing features) ... but 
maybe I'm wrong here.


There is not that much work left in pure SSF 
(cocoon-servlet-service-impl module) but there is still a room for 
improvement in module containing components integrating SSF and Cocoon 
(cocoon-servlet-service-components). Mentioned SAX buffer support 
involves modifications in impl and components modules.


I would add to the list of nice-to-have-in-SSF servlet discovery 
feature based on some conditions (e.g. returning 200 status code as 
response to certain request path). This way one could discover blocks 
providing certain services (e.g. skinning).


Nothing more comes to my mind right now.


  $ find cocoon/core/cocoon-servlet-service/cocoon-servlet-service-impl 
-name *.java | xargs grep TODO | wc -l

  18

I'm not so sure that this is not much :)


Vadim, you forgot about FIXME marks ;)

find core/cocoon-servlet-service/cocoon-servlet-service-impl -name *.java | xargs grep -E 
TODO|FIXME | wc -l

27


I've been considering participation in GSoC for some time due to my tottering 
planes for summer.


Now I'm pretty sure I'll be able to do some Cocoon-related work again this year. I would like to 
focus on fixing bugs, implementing lacking features and general polishing SSF.


My goals would be:
  * get rid of most FIXME/TODO marks in SSF code
  * implement SAX buffering for service calls
  * fix COCOON-1964:  Redirects inside a block called via the servlet protocol 
fail
  * fix COCOON-2096:  Servlet source's exists() method always returns true
  * provide samples of SSF usage for both situations:
- servlets managed by SSF are pure servlets that have nothing to do with 
Cocoon itself
- servlets are both pure servlets or SitemapServlets


For samples I would like to prepare examples how to connect, call servlets. How to make service 
calls, make use of polymorphism, etc.




  --- o0o ---


Apart from that I have an idea of making Cocoon blocks/servlets distributed and enabling SSF to 
transparently handle such set up. I think it would be very interesting to have a possibility to 
deploy different servlets to different physical machines and let them talk to eacher other using HTTP.


Actually, current implementation of servlet-to-servlet connections exploits only standard HTTP API 
so this should be quite easy to implement. That would enable completely new-brand SSF usage patterns 
like:


  * setting up load balancer between blocks (servlets) provided there are few machines with the 
same block deployed

  * setting up fail-over handling (if one of machines goes down, rest takes the 
processing)
  * exceptional scalability: if one of blocks is being used extensively, you can add another 
machine with this block deployed and make load balancer aware of it

  * even block (servlets) calls through the Internet! :-)


This should be considered as an optional deliverable for my GSoC activity as it would demand lots of 
discussing, researching and implementing in the end. Nevertheless, if time permits I would like to 
start experiment with this idea during the summer.


WDOT?

--
Respects,
Grzegorz Kossakowski

Re: [GSoC_2008] Project ideas


Grzegorz Kossakowski pisze:


Vadim, you forgot about FIXME marks ;)

find core/cocoon-servlet-service/cocoon-servlet-service-impl -name 
*.java | xargs grep -E TODO|FIXME | wc -l

27


I've been considering participation in GSoC for some time due to my 
tottering planes for summer.



Now I'm pretty sure I'll be able to do some Cocoon-related work again 
this year. I would like to focus on fixing bugs, implementing lacking 
features and general polishing SSF.


My goals would be:
  * get rid of most FIXME/TODO marks in SSF code
  * implement SAX buffering for service calls
  * fix COCOON-1964:  Redirects inside a block called via the servlet 
protocol fail

  * fix COCOON-2096:  Servlet source's exists() method always returns true
  * provide samples of SSF usage for both situations:
- servlets managed by SSF are pure servlets that have nothing to do 
with Cocoon itself

- servlets are both pure servlets or SitemapServlets


For samples I would like to prepare examples how to connect, call 
servlets. How to make service calls, make use of polymorphism, etc.




  --- o0o ---


Apart from that I have an idea of making Cocoon blocks/servlets 
distributed and enabling SSF to transparently handle such set up. I 
think it would be very interesting to have a possibility to deploy 
different servlets to different physical machines and let them talk to 
eacher other using HTTP.


Actually, current implementation of servlet-to-servlet connections 
exploits only standard HTTP API so this should be quite easy to 
implement. That would enable completely new-brand SSF usage patterns like:


  * setting up load balancer between blocks (servlets) provided there 
are few machines with the same block deployed
  * setting up fail-over handling (if one of machines goes down, rest 
takes the processing)
  * exceptional scalability: if one of blocks is being used extensively, 
you can add another machine with this block deployed and make load 
balancer aware of it

  * even block (servlets) calls through the Internet! :-)


This should be considered as an optional deliverable for my GSoC 
activity as it would demand lots of discussing, researching and 
implementing in the end. Nevertheless, if time permits I would like to 
start experiment with this idea during the summer.


WDOT?



Argh, I forgot about very important issue:
Who is going to be my mentor? Any volunteers on board? :-)

--
Grzegorz Kossakowski

Re: [GSoC_2008] Project ideas

2008-03-25 Thread Reinhard Poetz


Vadim Gritsenko wrote:

On Mar 22, 2008, at 1:14 PM, Lukas Lang wrote:
Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).


Any other suggestions? (the deadline for project proposals is 
Monday, 17th of March)


hey everybody,

i'm the student, who's interested in participating in a GSoC 
cocoon-project.
two days ago i had a conversation with Reinhard and as i read on the 
list,
he told me raising CForms from Dojo 0.4 upto Dojo 1.1 as a GSoC 
project would not be the best way to do so,

due to Jeremy's work on this.

he pointed out that several blocks and related examples yet don't work 
in cocoon-2.2 and
a great part of cocoon's users would take advantage of porting 
frequently used, cohesive blocks to version 2.2.


migrating the following blocks could be a realistic aim:

- cocoon-eventcache
- cocoon-jms
- cocoon-webdav
- cocoon-repository

my suggestion would consist of:

- creating a test-environment
- writing integration tests
- replacing avalon by spring
- making existing samples work
- developing new samples

what do you think?


I'd change the order a bit. First I'd suggest to make sure (and fix if 
necessary) existing samples. Once this is done, the block should be 
released. After that, you could start (as necessary) avalon to spring 
migration, and development of new samples.


I'd like to rephrase this: Make the existing samples work which includes 
replacing all the XSP stuff. This could be the base for a 1.0.0 release.
Then we branch and Lukas can continue with the Springification and writing 
integration tests which can be the base for a 1.1.0 release.


Just to make it clear for Lukas: It's not your responsibility that something 
gets released. And don't add any dependency on some external event to your proposal.


Finally, one thing that I miss: Can you add 'documentation' to your list of 
deliverables?


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [GSoC_2008] Project ideas

2008-03-25 Thread Dev at weitling




Vadim Gritsenko wrote:
I'd change the order a bit. First I'd suggest to make sure (and fix if 
necessary) existing samples. Once this is done, the block should be 
released. After that, you could start (as necessary) avalon to spring 
migration, and development of new samples.


Concerning the samples: It would be a great improvement to have the 
related code visible with the sample in browser. It's annoying when you 
have to manually grep whole directories for the appropriate sitemap or 
flowscript with a url as only information.


Florian

Re: [GSoC_2008] Project ideas

2008-03-24 Thread Vadim Gritsenko


On Mar 22, 2008, at 1:14 PM, Lukas Lang wrote:
Yesterday I was introduced to an Austrian student who would be  
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to  
Dojo 1.x (or
replacing it with something else if that is what the community is  
interested in).


Any other suggestions? (the deadline for project proposals is  
Monday, 17th of March)


hey everybody,

i'm the student, who's interested in participating in a GSoC cocoon- 
project.
two days ago i had a conversation with Reinhard and as i read on the  
list,
he told me raising CForms from Dojo 0.4 upto Dojo 1.1 as a GSoC  
project would not be the best way to do so,

due to Jeremy's work on this.

he pointed out that several blocks and related examples yet don't  
work in cocoon-2.2 and
a great part of cocoon's users would take advantage of porting  
frequently used, cohesive blocks to version 2.2.


migrating the following blocks could be a realistic aim:

- cocoon-eventcache
- cocoon-jms
- cocoon-webdav
- cocoon-repository

my suggestion would consist of:

- creating a test-environment
- writing integration tests
- replacing avalon by spring
- making existing samples work
- developing new samples

what do you think?


I'd change the order a bit. First I'd suggest to make sure (and fix if  
necessary) existing samples. Once this is done, the block should be  
released. After that, you could start (as necessary) avalon to spring  
migration, and development of new samples.


Vadim

Re: [GSoC_2008] Project ideas

2008-03-22 Thread Lukas Lang

Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).


Any other suggestions? (the deadline for project proposals is Monday, 
17th of March)


hey everybody,

i'm the student, who's interested in participating in a GSoC cocoon-project.
two days ago i had a conversation with Reinhard and as i read on the list,
he told me raising CForms from Dojo 0.4 upto Dojo 1.1 as a GSoC project would 
not be the best way to do so,
due to Jeremy's work on this.

he pointed out that several blocks and related examples yet don't work in 
cocoon-2.2 and
a great part of cocoon's users would take advantage of porting frequently used, 
cohesive blocks to version 2.2.

migrating the following blocks could be a realistic aim:

- cocoon-eventcache
- cocoon-jms
- cocoon-webdav
- cocoon-repository

my suggestion would consist of:

- creating a test-environment
- writing integration tests
- replacing avalon by spring
- making existing samples work
- developing new samples

what do you think?

lukas

Re: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)

2008-03-19 Thread Vadim Gritsenko


On Mar 18, 2008, at 4:11 AM, Thorsten Scherler wrote:


I am not sure whether you are aware of
http://svn.apache.org/viewvc/labs/droids/trunk/


You probably missed it, it was mentioned just few emails up this same  
thread -

http://markmail.org/message/53mbfx56ubpx5and

Vadim

Re: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)

2008-03-18 Thread Thorsten Scherler

On Mon, 2008-03-17 at 11:15 -0400, Vadim Gritsenko wrote:
On Mar 17, 2008, at 11:15 AM, Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:
External HTTP crawler is not a replacement for cocoon embedding
APIs (which what our CLI was, allows you to embed cocoon and use it
from within another java application, together with simple main()
wrapper).

I believe that similar effect could be achieved by application
imitating DispatcherServlet from SSF. If application wants to embed
Cocoon it should do basic initialization that DispatcherServlet does
and call SitemapServlet.forward() method. Of course that means the
application would need to implement few classes imitating
ServletContext, Request, Respone but I don't it's that hard...

WDYT?

Yep. That's exactly how it was done -- see:
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/commandline/

I am not sure whether you are aware of
http://svn.apache.org/viewvc/labs/droids/trunk/
http://people.apache.org/~thorsten/droids/index.html

I am planing to hit the incubator in a couple of days with the
httpcomponents project sponsoring the move. Droids is 100% java/spring
based, so it will be very easy to integrate it in cocoon.

Like stated in the droids documentation I started the lab because the
CLI is gone in 2.2.. IMO the only that is missing to be a full
replacement of the former CLI is to support the whole configuration
file. This however should be very straight forward to implement.

salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions

Re: [GSoC_2008] Project ideas

2008-03-18 Thread Antonio Gallardo


I would like to propose for GSOC2008 a fix for:

https://issues.apache.org/jira/browse/COCOON-1579

WDYT?

Best Regards,

Antonio Gallardo.

Reinhard Poetz escribió:


Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).


Any other suggestions? (the deadline for project proposals is Monday, 
17th of March)

Re: [GSoC_2008] Project ideas


Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:


+1 for the ideas, but they are very specific and only for insiders 
like you. Grzegorz, do you still consider applying for GSoC this year?


Not sure. I'd love to apply and do some more Cocoon-related work during 
the summer but I'm really concerned about USD ratings. :-(


All in all, I have to pay bills like everyone other and I think that 
these days I cannot trust USD anymore. However, I'm still considering 
prons and cons...


Another idea: Provide a command-line interface again, maybe by working 
together with the Forrest folks so that they can migrate to 2.2?


+100!
I hope that you don't want to mimic our previous implementation of CLI 
that seriously impacted our APIs. I would like to see CLI implemented 
using external tools.


My first step would be looking into Droids:

| Droids - Droids aims to be an intelligent standalone crawl framework that
| automatically seeks out relevant online information based on the user's
| specifications. The core is a simple crawler which can be easily extended by
| plugins. So if a project/app needs special processing for a crawled url one
| can easily write a plugin to implement the functionality

[http://labs.apache.org/labs.html]

--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Felix Knecht


Reinhard Poetz schrieb:

Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:

On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote:

Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).




+1



Another idea: Provide a command-line interface again, maybe by working 
together with the Forrest folks so that they can migrate to 2.2?


I'm quite sure, that CForms is much more popular and used than the CLI. 
I also think that upgrading Dojo (or something else) will give a much 
larger idea of how things (Java, Javasrcipt (Flowscript), XML, XSL) can 
work together than providing a CLI.

Just my thoughts.

Regards
Felix

Re: [GSoC_2008] Project ideas


Gabriel Gruber wrote:



   Yesterday I was introduced to an Austrian student who would be
   interested in
   working on a GSoC for the Cocoon project this year.
  
   The best idea we've had so far was was an upgrade of cForms to Dojo
   1.x (or
   replacing it with something else if that is what the community is
   interested in).
  
   Yes that is a good one.
  
   +1

+1 for Dojo 1.x in CForms.


I knew that you would like it ;-)

I've posted a project description at 
http://wiki.apache.org/general/SummerOfCode2008#cocoon-forms-dojo-upgrade


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Felix Knecht





+1 for Dojo 1.x in CForms.


I knew that you would like it ;-)


Very :-)


I've posted a project description at 
http://wiki.apache.org/general/SummerOfCode2008#cocoon-forms-dojo-upgrade


I could also think about not only upgrading but also fix things never 
work in ajax mode like [1], [2] and integrate new features of dojo1.1 to 
cocoon like TreeWidget (which IMO never really worked in C2.*), 
DojoGrids, ...


[1] Doublelistbox https://issues.apache.org/jira/browse/COCOON-1822 ;-)
[2] fi:validation-errors https://issues.apache.org/jira/browse/COCOON-1570
and others

Regards
felix

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Jeroen Reijn


Felix Knecht wrote:


I'm quite sure, that CForms is much more popular and used than the CLI. 
I also think that upgrading Dojo (or something else) will give a much 
larger idea of how things (Java, Javasrcipt (Flowscript), XML, XSL) can 
work together than providing a CLI.

Just my thoughts.

Regards
Felix


Yes I think I agree with Felix on this part. It will allow the student 
to learn a lot about Cocoon.


+1 for the Dojo upgrade!

Jeroen

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Jeremy Quinn


Hi Reinhard

On 13 Mar 2008, at 15:54, Reinhard Poetz wrote:



Yesterday I was introduced to an Austrian student who would be  
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo  
1.x (or
replacing it with something else if that is what the community is  
interested in).


Argh.
I have been researching this for the past few weeks with the intention  
of starting work to make this upgrade myself.

I guess I should have mentioned this earlier .
I doubt I am eligible for GSoC :)

What should we do?

regards Jeremy

Re: [GSoC_2008] Project ideas


Jeremy Quinn wrote:

Hi Reinhard

On 13 Mar 2008, at 15:54, Reinhard Poetz wrote:



Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).


Argh.
I have been researching this for the past few weeks with the intention 
of starting work to make this upgrade myself.

I guess I should have mentioned this earlier .
I doubt I am eligible for GSoC :)

What should we do?


go ahead! I'm sure that we will find something else that is of interest to 
potential applicants that would want to work on the Dojo upgrade (broader 
support for widgets, making Javascript optional, etc.).


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Re: [GSoC_2008] Project ideas


On Mar 16, 2008, at 7:07 AM, Reinhard Poetz wrote:


Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:

On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote:

Yesterday I was introduced to an Austrian student who would be  
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to  
Dojo 1.x (or
replacing it with something else if that is what the community is  
interested in).


Yes that is a good one.

+1
Any other suggestions? (the deadline for project proposals is  
Monday, 17th of March)


Finish SSF implementation? There is a lot of TODOs in there last  
time I've seen it.

+1
Optimize SSF? Get rid of buffering on service invocations - or at  
least past SAX buffer around.
Actually, real streaming is not possible but using SAX buffer is a  
good idea so: +1 for this proposal. I would add:
1. Migrate more stuff to Spring (like i18n transformer, databases  
stuff, etc.)
2. Write complete Schema for all of our grammars (JX, Forms,  
Sitemap, etc.)

WDYT?


+1 for the ideas, but they are very specific and only for insiders  
like you.


I don't think SSF work is for insiders only. After all, you were one  
of folks saying that SSF can be used without Cocoon. Which means you  
only need javax.servlet knowledge to make progress on this work...


Vadim

Re: [GSoC_2008] Project ideas


Vadim Gritsenko wrote:

On Mar 16, 2008, at 7:07 AM, Reinhard Poetz wrote:


Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:

On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote:

Yesterday I was introduced to an Austrian student who would be 
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to Dojo 
1.x (or
replacing it with something else if that is what the community is 
interested in).


Yes that is a good one.

+1
Any other suggestions? (the deadline for project proposals is 
Monday, 17th of March)


Finish SSF implementation? There is a lot of TODOs in there last 
time I've seen it.

+1
Optimize SSF? Get rid of buffering on service invocations - or at 
least past SAX buffer around.
Actually, real streaming is not possible but using SAX buffer is a 
good idea so: +1 for this proposal. I would add:
1. Migrate more stuff to Spring (like i18n transformer, databases 
stuff, etc.)
2. Write complete Schema for all of our grammars (JX, Forms, Sitemap, 
etc.)

WDYT?


+1 for the ideas, but they are very specific and only for insiders 
like you.


I don't think SSF work is for insiders only. After all, you were one of 
folks saying that SSF can be used without Cocoon. Which means you only 
need javax.servlet knowledge to make progress on this work...


My statement was meant to be more general (SSF + Spring migration + Schema 
support).


For an SSF project only, I don't see enough work (I only know about SAX 
buffering and support for redirects as missing features) ... but maybe I'm wrong 
here.


--
Reinhard PötzManaging Director, {Indoqa} GmbH
  http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_

Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)

2008-03-17 Thread Grzegorz Kossakowski


Vadim Gritsenko pisze:


External HTTP crawler is not a replacement for cocoon embedding APIs 
(which what our CLI was, allows you to embed cocoon and use it from 
within another java application, together with simple main() wrapper).


I believe that similar effect could be achieved by application imitating DispatcherServlet from SSF. 
If application wants to embed Cocoon it should do basic initialization that DispatcherServlet does 
and call SitemapServlet.forward() method. Of course that means the application would need to 
implement few classes imitating ServletContext, Request, Respone but I don't it's that hard...


WDYT?

--
Grzegorz Kossakowski

Re: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)


On Mar 17, 2008, at 11:15 AM, Grzegorz Kossakowski wrote:


Vadim Gritsenko pisze:
External HTTP crawler is not a replacement for cocoon embedding  
APIs (which what our CLI was, allows you to embed cocoon and use it  
from within another java application, together with simple main()  
wrapper).


I believe that similar effect could be achieved by application  
imitating DispatcherServlet from SSF. If application wants to embed  
Cocoon it should do basic initialization that DispatcherServlet does  
and call SitemapServlet.forward() method. Of course that means the  
application would need to implement few classes imitating  
ServletContext, Request, Respone but I don't it's that hard...


WDYT?



Yep. That's exactly how it was done -- see:
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/commandline/


Vadim

Re: [GSoC_2008] Project ideas


On Mar 17, 2008, at 7:28 AM, Reinhard Poetz wrote:


Grzegorz Kossakowski wrote:

Reinhard Poetz pisze:
Another idea: Provide a command-line interface again, maybe by  
working together with the Forrest folks so that they can migrate  
to 2.2?

+100!
I hope that you don't want to mimic our previous implementation of  
CLI that seriously impacted our APIs. I would like to see CLI  
implemented using external tools.


My first step would be looking into Droids:

| Droids - Droids aims to be an intelligent standalone crawl  
framework that


External HTTP crawler is not a replacement for cocoon embedding APIs  
(which what our CLI was, allows you to embed cocoon and use it from  
within another java application, together with simple main() wrapper).


Vadim

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Grzegorz Kossakowski


Reinhard Poetz pisze:


My statement was meant to be more general (SSF + Spring migration + 
Schema support).


For an SSF project only, I don't see enough work (I only know about SAX 
buffering and support for redirects as missing features) ... but maybe 
I'm wrong here.


There is not that much work left in pure SSF (cocoon-servlet-service-impl module) but there is 
still a room for improvement in module containing components integrating SSF and Cocoon 
(cocoon-servlet-service-components). Mentioned SAX buffer support involves modifications in impl and 
components modules.


I would add to the list of nice-to-have-in-SSF servlet discovery feature based on some conditions 
(e.g. returning 200 status code as response to certain request path). This way one could discover 
blocks providing certain services (e.g. skinning).


Nothing more comes to my mind right now.

--
Grzegorz Kossakowski

Re: [GSoC_2008] Project ideas

2008-03-17 Thread Jeremy Quinn



On 17 Mar 2008, at 13:53, Reinhard Poetz wrote:


Jeremy Quinn wrote:

Hi Reinhard
On 13 Mar 2008, at 15:54, Reinhard Poetz wrote:


Yesterday I was introduced to an Austrian student who would be  
interested in

working on a GSoC for the Cocoon project this year.

The best idea we've had so far was was an upgrade of cForms to  
Dojo 1.x (or
replacing it with something else if that is what the community is  
interested in).

Argh.
I have been researching this for the past few weeks with the  
intention of starting work to make this upgrade myself.

I guess I should have mentioned this earlier .
I doubt I am eligible for GSoC :)
What should we do?


go ahead! I'm sure that we will find something else that is of  
interest to potential applicants that would want to work on the Dojo  
upgrade (broader support for widgets, making Javascript optional,  
etc.).


Yes, there is a lot to do in CForms, even after changing it to use  
Dojo 1.n.


IMHO all of the work CForms needs is dependant on the switch to the  
new Dojo. For instance it seems pointless working on Dojofying old  
widgets (etc.) if the API is changing.


I suggest we put together a road-map for what we need to do.

Here is a possible start (off the top of my head) :

1) Switch to Dojo 1.n, reworking current Widgets and infrastructure to  
use new Dojo APIs.


2) Re-write existing Widgets that still use 3rd-party libraries, as  
Dojo Widgets.


3) All CForms Widgets to be rendered as Dojo Widgets to get a  
consistent visual theme, theme modification, WAI behaviour etc.


4) Find a way to allow HTMLArea (etc.) to be a plugin replacement for  
Dojo Rich Text Editor (as I assume this would have been replaced in  
step 2).


5) Make use of Dojo Layout Widgets when rendering CForms.

6) Implement a nice solution for compiling minimised JavaScript to  
support a specific Form/Webapp/Project/Site.


7) Perform client-side validation (as defined in CForms Model) where  
possible eg. RegExp, Min/Max, Range, Required, etc. etc.


8) Melding Dojo's and Cocoon's I18n into a coherent whole.

9) Re-work BrowserUpdate mechanism to allow DOM/Widget Update as well  
as DOM Replacement, to overcome issues with broken round-tripping with  
certain Widgets in Repeaters (eg. populated fileupload).


10) Deprecate FormsTransformer in favour of the CForms JX Macros,  
cleanup support for obsolete schema.


There are probably many more, let's discuss :)

Apart from item (1), the order is not so important.

Unless I suddenly get more work, I can work on item (1) now.
If anyone wants to take up any of the other issues as a GSoC project,  
I would definitely consider offering myself as a mentor, if that would  
be useful.



Ugh, so now I have to GOMA and actually deliver =:-0
(Thanks for the gentle kick, Reinhard :)


best regards

Jeremy

Re: [GSoC_2008] Project ideas