You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2008/03/13 16:54:58 UTC
[GSoC_2008] Project ideas
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)
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Jeroen Reijn <j....@hippo.nl>.
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
Posted by Felix Knecht <fe...@apache.org>.
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: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
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: Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Embedding Cocoon (was: Re: [GSoC_2008] Project ideas)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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: [GSoC_2008] Project ideas
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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.
--
Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> 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.
I'm not sure, but isn't there some open issue with multi-part mimes handling?
Apart from this, the list seems to be complete.
>
> --- 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.
Definitly and interesting topic and making it an optional deliveralbe is a good
idea.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Felix Knecht <fe...@apache.org>.
>>
>> +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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Gabriel Gruber <Ga...@workflow.at>.
> >>> 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.
best regards, gabriel
Re: [GSoC_2008] Project ideas
Posted by Reinhard Poetz <re...@apache.org>.
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.
Grzegorz, do you still consider applying for GSoC this year?
Another idea: Provide a command-line interface again, maybe by working together
with the Forrest folks so that they can migrate to 2.2?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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?
--
Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.
> 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.
Optimize SSF? Get rid of buffering on service invocations - or at
least past SAX buffer around.
Vadim
Re: [GSoC_2008] Project ideas
Posted by Lukas Lang <lu...@inode.at>.
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
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Dev at weitling <de...@weitling.net>.
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
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Lukas Lang <lu...@inode.at>.
>> 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: [GSoC_2008] Project ideas
Posted by Antonio Gallardo <ag...@agssa.net>.
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
Posted by Jeremy Quinn <je...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: [GSoC_2008] Project ideas
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Jeremy Quinn pisze:
> 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?
Hello Jeremy,
Have you considered becoming a mentor?
--
Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Posted by Jeremy Quinn <je...@apache.org>.
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