You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/03/14 23:56:12 UTC
GSoC
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?
I also wonder why only Reinhard offered mentoring this year. Are others so busy or missed the chance to add themselves?
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? ;-)
* 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? Why it's needed? What features it's going to have that our Template block does not have?
* 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
* use Dojo throughout in cForms
What does this mean exactly?
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?
Looking forward your answers and comments.
--
Grzegorz Kossakowski
Re: GSoC
Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.03.2007 07:10, Grzegorz Kossakowski wrote:
>>> I would like to ask you about my possible participation in GSoC and
>>> having Cocoon as a project of choice, of course.
>>>
>> Just wondering if you are allowed to as you are already committer?
>>
> As far as I understand this:
> http://code.google.com/support/bin/answer.py?answer=60310&topic=10727
> I'm allowed. Anyway, I'm going ask them.
Ok, this and that should make it clear: "Many of our past participants
had never participated in an open-source project before GSoC; others
used the GSoC stipend as an opportunity to concentrate fully on their
existing open source coding activities over the summer." [1]
>>> * use Dojo throughout in cForms
>>> What does this mean exactly?
>> I thought this is already done (replacing different JS libraries in
>> use with Dojo). We talked about it at last Cocoon GetTogether and
>> Jeremy did much about it in the meantime.
> Aha. So we can forget about this one?
I didn't follow the development that closely in the latest months to be
sure. But probably Jeremy can comment on this.
Jörg
[1] http://code.google.com/support/bin/answer.py?answer=60266&topic=10726
Re: GSoC
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke napisał(a):
> On 14.03.2007 23:56, Grzegorz Kossakowski wrote:
>
>> 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?
>
> Just wondering if you are allowed to as you are already committer?
> IIRC the original goal of GSoC was to bring people into open source
> software development.
As far as I understand this:
http://code.google.com/support/bin/answer.py?answer=60310&topic=10727
I'm allowed. Anyway, I'm going ask them.
>
>> * use Dojo throughout in cForms
>> What does this mean exactly?
>
> I thought this is already done (replacing different JS libraries in
> use with Dojo). We talked about it at last Cocoon GetTogether and
> Jeremy did much about it in the meantime.
Aha. So we can forget about this one?
--
Grzegorz Kossakowski
Re: GSoC
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.03.2007 23:56, Grzegorz Kossakowski wrote:
> 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?
Just wondering if you are allowed to as you are already committer? IIRC
the original goal of GSoC was to bring people into open source software
development.
> * use Dojo throughout in cForms
> What does this mean exactly?
I thought this is already done (replacing different JS libraries in use
with Dojo). We talked about it at last Cocoon GetTogether and Jeremy did
much about it in the meantime.
Jörg
Re: RESTapples
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> I've been working on rest block that is based on Apples. It won't do
>> much but to provide a controller interface that extends the
>> StatelessApplesController
>>
>> public interface RestApple extends StatelessAppleController {
>>
>> void doGet(AppleRequest req, AppleResponse res) throws Exception;
>
> Given the recent crusade against Cocoon environment, I gotta ask, why
> 'RestApple' and not 'Servlet'; why 'AppleRequest' and not 'ServletRequest'?
because I want to write a Cocoon REST server now without having to reinvent Cocoon.
> I'm sure Daniel will support this question too ;-)
LOL, I think so too.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: RESTapples
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> I've been working on rest block that is based on Apples. It won't do
> much but to provide a controller interface that extends the
> StatelessApplesController
>
> public interface RestApple extends StatelessAppleController {
>
> void doGet(AppleRequest req, AppleResponse res) throws Exception;
Given the recent crusade against Cocoon environment, I gotta ask, why
'RestApple' and not 'Servlet'; why 'AppleRequest' and not 'ServletRequest'?
I'm sure Daniel will support this question too ;-)
Vadim
Re: RESTapples
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> 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.
>
> I've been working on rest block that is based on Apples. It won't do
> much but to provide a controller interface that extends the
> StatelessApplesController
>
> public interface RestApple extends StatelessAppleController {
>
> void doGet(AppleRequest req, AppleResponse res) throws Exception;
>
> void doPost(AppleRequest req, AppleResponse res) throws Exception;
>
> void doPut(AppleRequest req, AppleResponse res) throws Exception;
>
> void doDelete(AppleRequest req, AppleResponse res) throws Exception;
>
> }
>
> and provides an abstract implementation. Based on the method of the
> incoming http request, one of the 4 methods is invoked. Currently this
> switch is implemented in the AbstractRestApple but should be moved to
> the Apples processor.
One of my main learning from the Cocoon projects is that I have become
severely allergic against depending on tons of interfaces, classes and
libraries ;)
So while the above might look innocent enough I'm not exactly thrilled
by the thought of letting all my controllers extend some abstract class
and use some questionable interfaces. Take a look at
http://jra.codehaus.org/ and
http://weblogs.java.net/blog/mhadley/archive/2007/02/jsr_311_java_ap.html
and compare.
For my controller I'd like to inject the dependencies that I want and
not having anything to do with some "object model" etc.
> If we worked on the Apples processor, we could even drop the
> requirement of implementing an interface and do the same like Struts 2.
Yes.
> But I wonder what we gain except from being more modern,
That is an important gain in itself. But what is more important is that
people will get up to speed faster if we are close to what they would
expect.
> if we used annotations (actually it doesn't bring much because you
> still have to add an import statement for the annotation) or a
> reflection mechanism to determine which method to execute ;-)
The point is that by using annotations you don't get the configuration
spread out. And by using "convention over configuration", you will not
need any annotations if you follow the recommended idioms.
/Daniel
RESTapples
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> 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.
I've been working on rest block that is based on Apples. It won't do much but to
provide a controller interface that extends the StatelessApplesController
public interface RestApple extends StatelessAppleController {
void doGet(AppleRequest req, AppleResponse res) throws Exception;
void doPost(AppleRequest req, AppleResponse res) throws Exception;
void doPut(AppleRequest req, AppleResponse res) throws Exception;
void doDelete(AppleRequest req, AppleResponse res) throws Exception;
}
and provides an abstract implementation. Based on the method of the incoming
http request, one of the 4 methods is invoked. Currently this switch is
implemented in the AbstractRestApple but should be moved to the Apples processor.
If we worked on the Apples processor, we could even drop the requirement of
implementing an interface and do the same like Struts 2.
But I wonder what we gain except from being more modern, if we used annotations
(actually it doesn't bring much because you still have to add an import
statement for the annotation) or a reflection mechanism to determine which
method to execute ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jorg Heymans napisał(a):
> Grzegorz Kossakowski wrote:
>
>> I recall some discussion about it in the past. Does it mean that even
>> we integrate Dojo into cocoon-forms very nicely user will be forced
>> to break all the modularity and use the compressor? Am I missing
>> something?
>>
>
> Aggregating and compressing [1] the required dojo modules is part of
> the build process IIUC. There is no impact on code modularity.
Actually, I was referring to the Cocoon's modularity. Compressor seems
to be not what we are talking about because it only compresses single
file by string operations. We are talking about merging many files into
one big one. This document discuss actual process:
http://redesign.dojotoolkit.org/node/19
Given that we calculate Dojo dependencies on runtime we cannot use this
tool. One solution would be special, magical pipeline component which
could take care of compiling building JS files on the fly and cache
them. I only wonder if anyone can imagine this solution simple and reliable?
Any other options?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Jorg Heymans <jh...@apache.org>.
Grzegorz Kossakowski wrote:
> I recall some discussion about it in the past. Does it mean that even we
> integrate Dojo into cocoon-forms very nicely user will be forced to
> break all the modularity and use the compressor? Am I missing something?
>
Aggregating and compressing [1] the required dojo modules is part of the
build process IIUC. There is no impact on code modularity.
Jorg
[1] http://dojotoolkit.org/docs/compressor_system.html
Re: [RT] Modernizing CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Sylvain Wallez napisał(a):
>> Grzegorz Kossakowski wrote:
>>
>> The "IE gives me shudders" feeling is partly one of the reasons for Ajax
>> toolkits to exist. This unfortunately doesn't solve everything, but
>> helps a lot!
>
> This only partly address my doubts. I really ask about the prospects for
> AJAX. If I'm going to invest my time in learning AJAX toolkits I would
> like to be sure that they are capable to do much more than flashy
> examples. What's questionable for me if AJAX can become _platform_ for
> building Rich Client Applications as we already would like to use it for
> building such.
> I agree that REST is great because it's more standard way of doing
> things (HTTP-compliant) and in theory would both reduce server's load
> and improve user's experience. I also can see that this reduces a
> complexity a little bit because it's more client-server architecture and
> no viewer-(server+view producer) as it's now. However, what I'm trying
> to say is that reduced complexity on server's side does not only come
> from building REST-style applications but also from moving some
> significant part of whole complexity from the server to client.
The idea is that total complexity for a "rich" AJAX+REST application is
lower than for a "rich" MVC model 2 application. See
http://www-128.ibm.com/developerworks/java/library/wa-ajaxarch/ for a
detailed argument for this.
So for me it is quite clear that the AJAX+REST architecture is very
promising. As I just have started to explore this way I have far to less
experience of it to know if the promise holds in practice yet.
> Now it
> becomes clear that we need tools and execution platform on the client side.
> What we have now is only bunch of quite compatible and
> standard-compliant browser's and IE. There are toolkits that try to
> improve the situation but they still need to be run on IE and I fear
> that we are going to hit their limits in near future. I would like to
> see strong arguments that my doubts are just unjustified...
It is of course always hard to know with Microsoft. I actually build my
first (and this far only) Ajax widget (a lazy loading tree menu) on IE5
long before the technology was dubbed AJAX. At that time all other
browsers where far behind. Then Microsoft pulled the brake and stoped
development of IE for a long time.
Now there seem to be some reasons to hope that they take browser
development serious again. First they decided to consider browser update
security critical. So thanks to that the vast majority of users have a
modern browser now. And secondly they have given up their resistance and
have developed a cross browser Ajax framework
http://ajax.asp.net/Default.aspx which probably will make them more
motivated to make IE a good Ajax platform. But you never know about
their priorities.
> Said that, I would like to stress that I do not stop anyone from taking
> this approach and even I would be happy to help make Forms more
> REST-like. What I wouldn't like to see is a Forms client app that we are
> going to support. Haunting for IE bugs is not fun for me and I think we
> could hardly find folks that I are enthusiastic about it either.
>
>>
>>> Maybe I'm just ignorant but... is there any multi threading capability
>>> on browser side? Is it only me experiencing Firefox freezing while dojo
>>> toolkit is being loaded?
>>>
>>
>> No, JavaScript is not multi-threaded, and although there are discussions
>> IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
>> on our browsers for many years.
>
> I'm really sad and even more doubtful hearing that :/
Although JavaScript as a language doesn't contain multi threading DOM
objects like XMLHttpRequest obviously executes JS code in multiple
threads, so I'm not certain that it is such a big problem if the
language lacks such constructions.
/Daniel
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Sylvain Wallez napisał(a):
> Grzegorz Kossakowski wrote:
>
> The "IE gives me shudders" feeling is partly one of the reasons for Ajax
> toolkits to exist. This unfortunately doesn't solve everything, but
> helps a lot!
This only partly address my doubts. I really ask about the prospects for
AJAX. If I'm going to invest my time in learning AJAX toolkits I would
like to be sure that they are capable to do much more than flashy
examples. What's questionable for me if AJAX can become _platform_ for
building Rich Client Applications as we already would like to use it for
building such.
I agree that REST is great because it's more standard way of doing
things (HTTP-compliant) and in theory would both reduce server's load
and improve user's experience. I also can see that this reduces a
complexity a little bit because it's more client-server architecture and
no viewer-(server+view producer) as it's now. However, what I'm trying
to say is that reduced complexity on server's side does not only come
from building REST-style applications but also from moving some
significant part of whole complexity from the server to client. Now it
becomes clear that we need tools and execution platform on the client side.
What we have now is only bunch of quite compatible and
standard-compliant browser's and IE. There are toolkits that try to
improve the situation but they still need to be run on IE and I fear
that we are going to hit their limits in near future. I would like to
see strong arguments that my doubts are just unjustified...
Said that, I would like to stress that I do not stop anyone from taking
this approach and even I would be happy to help make Forms more
REST-like. What I wouldn't like to see is a Forms client app that we are
going to support. Haunting for IE bugs is not fun for me and I think we
could hardly find folks that I are enthusiastic about it either.
>
>> Maybe I'm just ignorant but... is there any multi threading capability
>> on browser side? Is it only me experiencing Firefox freezing while dojo
>> toolkit is being loaded?
>>
>
> No, JavaScript is not multi-threaded, and although there are discussions
> IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
> on our browsers for many years.
I'm really sad and even more doubtful hearing that :/
>
> The freezing you experience is that because you're using an uncompressed
> Dojo, and every dojo.require() potentially does a _synchronous_
> XmlHttpRequest, hence freezing the browser. The solution, that has to be
> used for any production deployment, is to use Dojo's compressor to group
> all JS files used by an application into a single compressed one. No
> more freezing in that case.
I recall some discussion about it in the past. Does it mean that even we
integrate Dojo into cocoon-forms very nicely user will be forced to
break all the modularity and use the compressor? Am I missing something?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Grzegorz Kossakowski wrote:
> Daniel Fagerstrom napisał(a):
>
>> I don't propose that we should throw out the current Forms framework.
>> What I do propose is that it could be improved so that it would
>> require less work to use and so that it would support AJAX+REST style
>> webapps better.
>>
>> Don't repeat yourself
>> =====================
>>
>> As an alternative to using XML configurations for form definition and
>> binding both the form definition object and the binding object could
>> be configured from annotations in the model bean. With some decent set
>> of conventions, people who follow the conventions would be able to
>> connect forms to the business model with considerably less code
>> writing. JBoss Seam is a good example of what I have in mind.
>>
>
> I tend to agree with this one. I'm also supporter of less
> configuration-demanding solutions and conventions where applicable. I
> fear only if Java world (and we in particular) eventually leap from the
> "XML hell" to the "annotations hell". I can imagine this situation and
> would like to avoid it.
>
>
>> AJAX+REST friendliness
>> ======================
>>
>> IMHO the preferred webapp architecture will move from MVC model 2
>> towards the kind of architecture described in figure 2 in
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> One way to support such a architectural style with our forms framework
>> would be to refactor it so that it allows for a more RESTish
>> communication style. Think about the form instance as a resource that
>> can have JSON (or XML) representation that you can GET, PUT, POST or
>> DELETE. One could also have support for letting the client ask for
>> tthe data types of the form for supporting client side validation.
>>
>
> I wonder where are the limits. Is it valid to treat browser as VM
> machine where we execute complicated (name them Rich) client
> applications? Although such an idea is nice, when I think of "IE" all
> the simplicity and flexibility of the solution seems to flow away to
> some nowhere land. Am I only one not so enthusiastic about AJAX
> everywhere vision?
>
The "IE gives me shudders" feeling is partly one of the reasons for Ajax
toolkits to exist. This unfortunately doesn't solve everything, but
helps a lot!
> Maybe I'm just ignorant but... is there any multi threading capability
> on browser side? Is it only me experiencing Firefox freezing while dojo
> toolkit is being loaded?
>
No, JavaScript is not multi-threaded, and although there are discussions
IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
on our browsers for many years.
The freezing you experience is that because you're using an uncompressed
Dojo, and every dojo.require() potentially does a _synchronous_
XmlHttpRequest, hence freezing the browser. The solution, that has to be
used for any production deployment, is to use Dojo's compressor to group
all JS files used by an application into a single compressed one. No
more freezing in that case.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom napisał(a):
>
> I don't propose that we should throw out the current Forms framework.
> What I do propose is that it could be improved so that it would
> require less work to use and so that it would support AJAX+REST style
> webapps better.
>
> Don't repeat yourself
> =====================
>
> As an alternative to using XML configurations for form definition and
> binding both the form definition object and the binding object could
> be configured from annotations in the model bean. With some decent set
> of conventions, people who follow the conventions would be able to
> connect forms to the business model with considerably less code
> writing. JBoss Seam is a good example of what I have in mind.
I tend to agree with this one. I'm also supporter of less
configuration-demanding solutions and conventions where applicable. I
fear only if Java world (and we in particular) eventually leap from the
"XML hell" to the "annotations hell". I can imagine this situation and
would like to avoid it.
>
> AJAX+REST friendliness
> ======================
>
> IMHO the preferred webapp architecture will move from MVC model 2
> towards the kind of architecture described in figure 2 in
> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>
> and in http://websphere.sys-con.com/read/196269.htm.
>
> One way to support such a architectural style with our forms framework
> would be to refactor it so that it allows for a more RESTish
> communication style. Think about the form instance as a resource that
> can have JSON (or XML) representation that you can GET, PUT, POST or
> DELETE. One could also have support for letting the client ask for
> tthe data types of the form for supporting client side validation.
I wonder where are the limits. Is it valid to treat browser as VM
machine where we execute complicated (name them Rich) client
applications? Although such an idea is nice, when I think of "IE" all
the simplicity and flexibility of the solution seems to flow away to
some nowhere land. Am I only one not so enthusiastic about AJAX
everywhere vision?
Maybe I'm just ignorant but... is there any multi threading capability
on browser side? Is it only me experiencing Firefox freezing while dojo
toolkit is being loaded?
--
Grzegorz Kossakowski
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez skrev:
<snip/>
>> A very concrete example: within a Wicket application, we needed to have
>> areas of the screen be the result of the transformation of some XML
>> document. We ended up doing coding pipelines in plain Java. If Cocoon
>> had provided a simple way to use its pipeline machinery, we would have
>> used it.
>
> Although it could be even easier and most definitively should require
> less dependencies it is not that hard to use the pipeline standalone:
> http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
>
>
> For the dependencies we have done some work on splitting up Cocoon so
> that you can use just the pipeline part (see
> http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing
> left to do is to de-Avalonize a number of core components.
Very cool!
>> All this to say that by trying to address too many concerns, Cocoon
>> dilutes the message of where its strengths are, and leads potential
>> newcomers to simply look somewhere else.
>
> We clearly need to have a more focused message. But I think that
> saying that we should not provides a webapp framework anymore but just
> some components would be to go far to long. We need to find the right
> balance.
>
>> A way to address this would be to have several subprojects in the Cocoon
>> top-level project, ensuring a greater technical separation, giving a
>> clear view of the various features the top-level project provides and
>> thus allowing people to pick-up what they need, and ultimately use more
>> and more of what this project provides.
>
> We are going in this direction. Both the cocoon-spring-configurator
> and the cocoon-servlet-service-fw (and maybe some more) are intended
> to be separate Cocoon sub projects. Lots of work left to do though.
IMO this is key for the future of Cocoon: showing that it's not (or no
more) a take-it-all-or-nothing beast, but a component statck where you
can pick up only what you need.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez skrev:
> Daniel Fagerstrom wrote:
>
>> I don't propose that we should throw out the current Forms framework.
>> What I do propose is that it could be improved so that it would
>> require less work to use and so that it would support AJAX+REST style
>> webapps better.
>>
>> Don't repeat yourself
>> =====================
>>
>> As an alternative to using XML configurations for form definition and
>> binding both the form definition object and the binding object could
>> be configured from annotations in the model bean. With some decent set
>> of conventions, people who follow the conventions would be able to
>> connect forms to the business model with considerably less code
>> writing. JBoss Seam is a good example of what I have in mind.
>>
>> AJAX+REST friendliness
>> ======================
>>
>> IMHO the preferred webapp architecture will move from MVC model 2
>> towards the kind of architecture described in figure 2 in
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> One way to support such a architectural style with our forms framework
>> would be to refactor it so that it allows for a more RESTish
>> communication style. Think about the form instance as a resource that
>> can have JSON (or XML) representation that you can GET, PUT, POST or
>> DELETE. One could also have support for letting the client ask for
>> tthe data types of the form for supporting client side validation.
>
> I heartfully agree with these goals and it's true that CForms, more than
> old-fashioned, looks heavyweight compared to more recent solutions that
> considered partial page update and/or RPC-style interaction right from
> the beginning.
>
> Now the question that comes to mind when considering these goals is: "Is
> this still Cocoon?"
Considering the excess of ideas, languages and areas that are covered in
our repository, I'd say that Cocoon seem to be whatever at least one
comitter want it to be ;)
> So what is Cocoon:
> - an XML processing engine?
> - a REST platform (sitemap matchers)?
> - a webapp framework (flowscript, CForms)?
> - a block container for Spring components?
> - an OSGi bridge/integration platform for blocks?
>
> The still unique distinguishing features of Cocoon are the two first
> ones. When we progress in the stack, more competition and more modern
> solutions appear.
I'd say that we are in the forefront and have some unique ideas in the
"block container for Spring components" area as well. But I'm fairly biased.
For OSGi, developing bridge/integration framework is clearly better done
in other communities. But it would still be nice to apply their results
at Cocoon.
> Also, XML processing is powerful for data aggregation,
> filtering and transformation, but quickly shows its limits for business
> logic (nah, XSP+SQLTransformer is not a nice solution).
Agree.
> For RPC-style webapps, you definitely don't need Cocoon, because there's
> no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected
> to plain Java code.
Yes. Personally I'm much more attracted to AJAX+REST than AJAX+RPC, though.
> For component-based webapps with partial page
> updates, Wicket [2] is really productive. All this actually reminds me
> of some old prophecy [3].
>
> Rather than coming with its own solution for each and every aspect of
> server-side app development, the future of Cocoon is IMHO paradoxically
> in its past: XML processing engine and REST platform. By providing a
> very simple way to integrate these features in any context, it will
> allow people that use other more modern/mainstream approaches to use Cocoon.
I agree about that XML-pipeline + REST is our core offering and that it
would deserve more attention and polishing from us.
> A very concrete example: within a Wicket application, we needed to have
> areas of the screen be the result of the transformation of some XML
> document. We ended up doing coding pipelines in plain Java. If Cocoon
> had provided a simple way to use its pipeline machinery, we would have
> used it.
Although it could be even easier and most definitively should require
less dependencies it is not that hard to use the pipeline standalone:
http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
For the dependencies we have done some work on splitting up Cocoon so
that you can use just the pipeline part (see
http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing left
to do is to de-Avalonize a number of core components.
> All this to say that by trying to address too many concerns, Cocoon
> dilutes the message of where its strengths are, and leads potential
> newcomers to simply look somewhere else.
We clearly need to have a more focused message. But I think that saying
that we should not provides a webapp framework anymore but just some
components would be to go far to long. We need to find the right balance.
> A way to address this would be to have several subprojects in the Cocoon
> top-level project, ensuring a greater technical separation, giving a
> clear view of the various features the top-level project provides and
> thus allowing people to pick-up what they need, and ultimately use more
> and more of what this project provides.
We are going in this direction. Both the cocoon-spring-configurator and
the cocoon-servlet-service-fw (and maybe some more) are intended to be
separate Cocoon sub projects. Lots of work left to do though.
> And also providing bridges to
> the other mainstream solutions rather than trying to embrace them, thus
> giving mindshare to Cocoon in other communities.
Exactly.
/Daniel
Re: [RT] Modernizing CForms
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> I don't propose that we should throw out the current Forms framework.
> What I do propose is that it could be improved so that it would
> require less work to use and so that it would support AJAX+REST style
> webapps better.
>
> Don't repeat yourself
> =====================
>
> As an alternative to using XML configurations for form definition and
> binding both the form definition object and the binding object could
> be configured from annotations in the model bean. With some decent set
> of conventions, people who follow the conventions would be able to
> connect forms to the business model with considerably less code
> writing. JBoss Seam is a good example of what I have in mind.
>
> AJAX+REST friendliness
> ======================
>
> IMHO the preferred webapp architecture will move from MVC model 2
> towards the kind of architecture described in figure 2 in
> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>
> and in http://websphere.sys-con.com/read/196269.htm.
>
> One way to support such a architectural style with our forms framework
> would be to refactor it so that it allows for a more RESTish
> communication style. Think about the form instance as a resource that
> can have JSON (or XML) representation that you can GET, PUT, POST or
> DELETE. One could also have support for letting the client ask for
> tthe data types of the form for supporting client side validation.
I heartfully agree with these goals and it's true that CForms, more than
old-fashioned, looks heavyweight compared to more recent solutions that
considered partial page update and/or RPC-style interaction right from
the beginning.
Now the question that comes to mind when considering these goals is: "Is
this still Cocoon?"
So what is Cocoon:
- an XML processing engine?
- a REST platform (sitemap matchers)?
- a webapp framework (flowscript, CForms)?
- a block container for Spring components?
- an OSGi bridge/integration platform for blocks?
The still unique distinguishing features of Cocoon are the two first
ones. When we progress in the stack, more competition and more modern
solutions appear. Also, XML processing is powerful for data aggregation,
filtering and transformation, but quickly shows its limits for business
logic (nah, XSP+SQLTransformer is not a nice solution).
For RPC-style webapps, you definitely don't need Cocoon, because there's
no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected
to plain Java code. For component-based webapps with partial page
updates, Wicket [2] is really productive. All this actually reminds me
of some old prophecy [3].
Rather than coming with its own solution for each and every aspect of
server-side app development, the future of Cocoon is IMHO paradoxically
in its past: XML processing engine and REST platform. By providing a
very simple way to integrate these features in any context, it will
allow people that use other more modern/mainstream approaches to use Cocoon.
A very concrete example: within a Wicket application, we needed to have
areas of the screen be the result of the transformation of some XML
document. We ended up doing coding pipelines in plain Java. If Cocoon
had provided a simple way to use its pipeline machinery, we would have
used it.
All this to say that by trying to address too many concerns, Cocoon
dilutes the message of where its strengths are, and leads potential
newcomers to simply look somewhere else.
A way to address this would be to have several subprojects in the Cocoon
top-level project, ensuring a greater technical separation, giving a
clear view of the various features the top-level project provides and
thus allowing people to pick-up what they need, and ultimately use more
and more of what this project provides. And also providing bridges to
the other mainstream solutions rather than trying to embrace them, thus
giving mindshare to Cocoon in other communities.
Sylvain
[1] http://getahead.org/dwr
[2] http://incubator.apache.org/wicket/
[3] http://thread.gmane.org/gmane.text.xml.cocoon.devel/55131
--
Sylvain Wallez - http://bluxte.net
[RT] Modernizing CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom napisał(a):
>> Grzegorz Kossakowski skrev:
...
>> 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...
[And from earlier in the thread]
>> 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.
I don't propose that we should throw out the current Forms framework.
What I do propose is that it could be improved so that it would require
less work to use and so that it would support AJAX+REST style webapps
better.
Don't repeat yourself
=====================
As an alternative to using XML configurations for form definition and
binding both the form definition object and the binding object could be
configured from annotations in the model bean. With some decent set of
conventions, people who follow the conventions would be able to connect
forms to the business model with considerably less code writing. JBoss
Seam is a good example of what I have in mind.
AJAX+REST friendliness
======================
IMHO the preferred webapp architecture will move from MVC model 2
towards the kind of architecture described in figure 2 in
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
and in http://websphere.sys-con.com/read/196269.htm.
One way to support such a architectural style with our forms framework
would be to refactor it so that it allows for a more RESTish
communication style. Think about the form instance as a resource that
can have JSON (or XML) representation that you can GET, PUT, POST or
DELETE. One could also have support for letting the client ask for tthe
data types of the form for supporting client side validation.
/Daniel
Re: GSoC
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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
Re: GSoC
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: GSoC
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>
>> And finally some more project ideas:
>>
>> a) cleanup input modules: IIRC there was some discussion about
>> reducing the number of input modules in favor of one that uses an
>> expression
>> language that works on a well-defined object model.
>>
>> b) cleanup expression language usage throughout Cocoon
>> Daniel, do you have any pointers?
...
> After reading lots of archives I'm in favour of (a+b) option. I hope you
> are not going to be disappointed too much with choice. :)
> I think that unified expression should be done already at least I year
> ago but I wasn't a committer, at that time. ;P
I added a project description for this
http://wiki.apache.org/general/SummerOfCode2007#cocoon-expression.
>
> More seriously, I would like to ask who is going to be my mentor. I
> would be grateful for quick responses as there is not so much time left.
I can be your mentor.
> Would you like me to sketch my plan and share early thoughts on the
> topic in separate thread?
Yes
/Daniel
Re: GSoC
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>
> And finally some more project ideas:
>
> a) cleanup input modules: IIRC there was some discussion about
> reducing the number of input modules in favor of one that uses an
> expression
> language that works on a well-defined object model.
>
> b) cleanup expression language usage throughout Cocoon
> Daniel, do you have any pointers?
>
> c) provide an alternative continuations manager that can work with
> distributed caches
>
> d) refactor <map:call function=""/> and <map:flow>
> * make it possible to support more than one flow language per sitemap
> * find some better naming than "function" because it feels strange to
> call e.g. an Apple or a JavaFlow
>
> e) Cocon Javaflow 1.0 + integration with the reloading classloader
> stuff:
> --> whatever needs to be done to get it stable ;-)
>
>
> I think that (a + b) or (c + d + e) could be interesting projects.
>
>
> - o -
>
>
> Grek, my personal preference for your GSoC project goes towards the
> c+d+e project. This needs some involvement by Torsten and, highly
> recommended, him as mentor but I don't know whether he wants to take
> mentorship again.
> *My* second choice is the cForms refactorings. Of course you are free
> to suggest to us whatever you like :-)
After reading lots of archives I'm in favour of (a+b) option. I hope you
are not going to be disappointed too much with choice. :)
I think that unified expression should be done already at least I year
ago but I wasn't a committer, at that time. ;P
More seriously, I would like to ask who is going to be my mentor. I
would be grateful for quick responses as there is not so much time left.
Would you like me to sketch my plan and share early thoughts on the
topic in separate thread?
--
Grzegorz Kossakowski
Re: GSoC
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom napisał(a):
> Grzegorz Kossakowski skrev:
>
> I don't think that you have misunderstood the "refactoring" word. I
> wanted to point out that I think that refactoring where the only goal
> is to clean up the design is a complicated business. The concept of a
> "cleaner design" is rather vague.
>
> I mean: How do you evaluate that the new design is cleaner? When is it
> clean enough? Why should it be cleaner? How do you keep your
> motivation when the works get tough?
>
> In my experience it is much better to a refactoring with the explicit
> goal of making it possible (or easier) to implement this or that
> particular new functionality.
>
> By doing that it will be much easier to find an answer of the above
> questions. You know that the refactoring leads to a "better" design if
> it allows both for the current tasks and the new one.
Ah, thanks for reminder! :)
Almost forgotten why people refactor the code: to enable it to handle
new functionality. Given that, I'm going to collect all the painful
situations with existing implementation of pipelines and describe them
eventually. Then it should be quite obvious what's need to be done to
improve the situation. Also when most of the pain is gone we can be sure
that at the time we are done.
And yes, making code capable of new functionality is all the fun about
refactoring...
Thanks again!
--
Grzegorz Kossakowski
Re: GSoC
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom napisał(a):
...
>>> I would add even one more:
>>> * refactoring of pipeline stuff
>>> While working on improving HTTP-compliance of pipelines I had a
>>> feeling (expressed in few comments) that pipeline code really needs
>>> major redesign and refactoring. Current code is really obscure,
>>> hard-to-follow and full of hacks. It's really a challenge to make a only
>>> minor change in it being sure that nothing is going to break. Situation
>>> is even worse, that there are only few tests provided for pipeline code.
>>> My idea was to write lots of tests _before_ doing any refactorings
>>> covering all the code in pipeline module and start reimplementing
>>> classes with effort to not change APIs too much. However, small changes
>>> would be needed IMHO.
>>
>> Just refactoring something sounds a little bit boring. I think you
>> should add something also. One idea would be to make pipelines usable
>> outside Cocoon sitemaps. I started to work on it
>> http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
>> But one still need to depend on the cocoon-core module. It would be
>> much neater to just need to depend on the cocoon-pipeline-impl.
> I think that refactoring would lead to cleaner contracts and lesser
> amount of dependencies. Maybe I misunderstand "refactoring" word. Is
> what I'm talking about mor a redesign?
I don't think that you have misunderstood the "refactoring" word. I
wanted to point out that I think that refactoring where the only goal is
to clean up the design is a complicated business. The concept of a
"cleaner design" is rather vague.
I mean: How do you evaluate that the new design is cleaner? When is it
clean enough? Why should it be cleaner? How do you keep your motivation
when the works get tough?
In my experience it is much better to a refactoring with the explicit
goal of making it possible (or easier) to implement this or that
particular new functionality.
By doing that it will be much easier to find an answer of the above
questions. You know that the refactoring leads to a "better" design if
it allows both for the current tasks and the new one.
/Daniel
Re: GSoC
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom napisał(a):
>
>>> And finally some more project ideas:
>>>
>>> a) cleanup input modules: IIRC there was some discussion about
>>> reducing the number of input modules in favor of one that uses an
>>> expression
>>> language that works on a well-defined object model.
>>>
>>> b) cleanup expression language usage throughout Cocoon
>>> Daniel, do you have any pointers?
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110963086900150&w=2,
> http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2,
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109941971317696&w=2,
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/java/org/apache/cocoon/components/accessor/AccessorTestCase.java
Wow, lots of reading; luckily weekend has just started. Thanks! :)
>> I would add even one more:
>> * refactoring of pipeline stuff
>> While working on improving HTTP-compliance of pipelines I had a
>> feeling (expressed in few comments) that pipeline code really needs
>> major redesign and refactoring. Current code is really obscure,
>> hard-to-follow and full of hacks. It's really a challenge to make a only
>> minor change in it being sure that nothing is going to break. Situation
>> is even worse, that there are only few tests provided for pipeline code.
>> My idea was to write lots of tests _before_ doing any refactorings
>> covering all the code in pipeline module and start reimplementing
>> classes with effort to not change APIs too much. However, small changes
>> would be needed IMHO.
>
> Just refactoring something sounds a little bit boring. I think you
> should add something also. One idea would be to make pipelines usable
> outside Cocoon sitemaps. I started to work on it
> http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
> But one still need to depend on the cocoon-core module. It would be
> much neater to just need to depend on the cocoon-pipeline-impl.
I think that refactoring would lead to cleaner contracts and lesser
amount of dependencies. Maybe I misunderstand "refactoring" word. Is
what I'm talking about mor a redesign?
>> Also, I wonder if it's even doable in two months as this
>> changes would involve lots of discussion and the task in general is
>> really challenging.
>
> As a refactoring consists of a sequence of behavior preserving
> transformations you can stop in any moment, so it is of course doable
> in two months or in any given period of time ;)
>
> A possible problem with doing it during the summer is that the list
> might be less responsive. So it requires that you are confident enough
> to make some tough decisions without that much feedback.
Thanks for bringing this. After thinking it over I agree that summer is
not good time for such a task. It would involve lots of question about
design decision made in the past and about those are going to happen etc.
It means that I think it's not good candidate for GSoC project but I do
not abandon the idea in general. If time permits I will return to this
issue.
--
Grzegorz Kossakowski
Re: GSoC
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Reinhard Poetz wrote:
>> Grzegorz Kossakowski wrote:
...
>> And finally some more project ideas:
>>
>> a) cleanup input modules: IIRC there was some discussion about
>> reducing the number of input modules in favor of one that uses an
>> expression
>> language that works on a well-defined object model.
>>
>> b) cleanup expression language usage throughout Cocoon
>> Daniel, do you have any pointers?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110963086900150&w=2,
http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109941971317696&w=2,
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/java/org/apache/cocoon/components/accessor/AccessorTestCase.java
> I would add even one more:
> * refactoring of pipeline stuff
> While working on improving HTTP-compliance of pipelines I had a
> feeling (expressed in few comments) that pipeline code really needs
> major redesign and refactoring. Current code is really obscure,
> hard-to-follow and full of hacks. It's really a challenge to make a only
> minor change in it being sure that nothing is going to break. Situation
> is even worse, that there are only few tests provided for pipeline code.
> My idea was to write lots of tests _before_ doing any refactorings
> covering all the code in pipeline module and start reimplementing
> classes with effort to not change APIs too much. However, small changes
> would be needed IMHO.
Just refactoring something sounds a little bit boring. I think you
should add something also. One idea would be to make pipelines usable
outside Cocoon sitemaps. I started to work on it
http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
But one still need to depend on the cocoon-core module. It would be
much neater to just need to depend on the cocoon-pipeline-impl.
> I only wonder if there is a volunteer that woud like to mentor such a
> project.
I could mentor it.
> Also, I wonder if it's even doable in two months as this
> changes would involve lots of discussion and the task in general is
> really challenging.
As a refactoring consists of a sequence of behavior preserving
transformations you can stop in any moment, so it is of course doable in
two months or in any given period of time ;)
A possible problem with doing it during the summer is that the list
might be less responsive. So it requires that you are confident enough
to make some tough decisions without that much feedback.
/Daniel
Re: GSoC
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz wrote:
> Grzegorz Kossakowski wrote:
>
> see http://wiki.apache.org/cocoon/Templates, the section about
> Attribute Driven Templating (ADT)
>
> But this requires either Leszek or Daniel as mentor. I definitly don't
> have an in-depth understanding of it.
Thanks for this link. I'll look into this little bit later and share my
thoughts.
>
>> * 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
>
> but would be perfect for the OSC project in Vienna :-)
:-)
>
>> * use Dojo throughout in cForms
>> What does this mean exactly?
>
> AFAICS we still include the "matt-kruse" libs and htmlarea. The latter
> should become optional and there should be an additional
> implementation of WYSIWIG input fields using Dojo functionality. The
> matt-kruse libs are used for some advanced widgets.
>
> If you are interested in working on cForms, "use Dojo throughout in
> cForms" will probably only be one part of a project IMO. I would also
> like to see some more refactorings:
>
> - Springifying cForms
> (http://marc.theaimsgroup.com/?t=116954345700002&r=1&w=2)
> - support a simple styling that works *without* Javascript
> - make cForms work with Saxon
>
> and some more ideas that could go into a cForms proposal:
> - make Forms objects serializable
> - replace xreporter expressions using some other expression library
>
> Sidenote: All those steps go towards cForms 2.0 as I'm not sure
> whether we can implement everything in a backwards compatible way.
Intersting and ambitious enough :-)
I would even one more point:
* expose servlet services that can be used for handling forms rendering
(including support for AJAX) so you don't have to include those scarying
sitemap snippets that are responsible for forms rendering.
>
>> 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?
>
> As I said before, if there are students here in Vienna who want to
> work on Cocoon, I want to propose to them a refactoring of our samples
> and writing documentation.
> Aside from being feasible for beginners, this is a task that can be
> split into smaller sub-tasks much easier than e.g. implementing ADT.
> Opposed to GSoC, there will be mixed teams of 4 to 6 students (e.g. 3
> programmers + 2 designers) at the Vienna students' projects.
Ok, I'll be happy to leave this simpler tasks for them.
>
>
> - o -
>
>
> And finally some more project ideas:
>
> a) cleanup input modules: IIRC there was some discussion about
> reducing the number of input modules in favor of one that uses an
> expression
> language that works on a well-defined object model.
>
> b) cleanup expression language usage throughout Cocoon
> Daniel, do you have any pointers?
>
> c) provide an alternative continuations manager that can work with
> distributed caches
>
> d) refactor <map:call function=""/> and <map:flow>
> * make it possible to support more than one flow language per sitemap
> * find some better naming than "function" because it feels strange to
> call e.g. an Apple or a JavaFlow
>
> e) Cocon Javaflow 1.0 + integration with the reloading classloader
> stuff:
> --> whatever needs to be done to get it stable ;-)
>
>
> I think that (a + b) or (c + d + e) could be interesting projects.
I was thinking about (a+b) too. I think that it would be great
achievement for Cocoon to have one, unified, coherent object model and
at least one expression language having our support and being a
reference implementation of expressions languages that could be plugged
into Cocoon.
I agree that (c+d+e) is also interesting but I fear it would be much
more difficult for me. I have only a little expierence with JavaFlow and
do not know much about both continuations manager internals and
reloading classloader stuff. I could accept challenge only being sure
that good support from mentor is provided.
>
> Grek, my personal preference for your GSoC project goes towards the
> c+d+e project. This needs some involvement by Torsten and, highly
> recommended, him as mentor but I don't know whether he wants to take
> mentorship again.
> *My* second choice is the cForms refactorings. Of course you are free
> to suggest to us whatever you like :-)
I'm really grateful for your response; all ideas are really interesting!
I would add even one more:
* refactoring of pipeline stuff
While working on improving HTTP-compliance of pipelines I had a
feeling (expressed in few comments) that pipeline code really needs
major redesign and refactoring. Current code is really obscure,
hard-to-follow and full of hacks. It's really a challenge to make a only
minor change in it being sure that nothing is going to break. Situation
is even worse, that there are only few tests provided for pipeline code.
My idea was to write lots of tests _before_ doing any refactorings
covering all the code in pipeline module and start reimplementing
classes with effort to not change APIs too much. However, small changes
would be needed IMHO.
I only wonder if there is a volunteer that woud like to mentor such a
project. Also, I wonder if it's even doable in two months as this
changes would involve lots of discussion and the task in general is
really challenging.
What do you think?
--
Grzegorz Kossakowski
Re: GSoC
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> 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?
>
> I also wonder why only Reinhard offered mentoring this year. Are others so busy or missed the chance to add themselves?
>
> 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? ;-)
The ideas come from me so far and this one would be definitly to easy for _you_.
Since I will mentor a students' project in Vienna this summer and my students
most probably don't have any experiences with Cocoon, I will propose to them a
rework and redesign of our samples.
> * 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? Why it's needed? What features it's going to have that our Template block does not have?
see http://wiki.apache.org/cocoon/Templates, the section about Attribute Driven
Templating (ADT)
But this requires either Leszek or Daniel as mentor. I definitly don't have an
in-depth understanding of it.
> * 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
but would be perfect for the OSC project in Vienna :-)
> * use Dojo throughout in cForms
> What does this mean exactly?
AFAICS we still include the "matt-kruse" libs and htmlarea. The latter should
become optional and there should be an additional implementation of WYSIWIG
input fields using Dojo functionality. The matt-kruse libs are used for some
advanced widgets.
If you are interested in working on cForms, "use Dojo throughout in cForms" will
probably only be one part of a project IMO. I would also like to see some more
refactorings:
- Springifying cForms
(http://marc.theaimsgroup.com/?t=116954345700002&r=1&w=2)
- support a simple styling that works *without* Javascript
- make cForms work with Saxon
and some more ideas that could go into a cForms proposal:
- make Forms objects serializable
- replace xreporter expressions using some other expression library
Sidenote: All those steps go towards cForms 2.0 as I'm not sure whether we can
implement everything in a backwards compatible way.
> 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?
As I said before, if there are students here in Vienna who want to work on
Cocoon, I want to propose to them a refactoring of our samples and writing
documentation.
Aside from being feasible for beginners, this is a task that can be split into
smaller sub-tasks much easier than e.g. implementing ADT. Opposed to GSoC, there
will be mixed teams of 4 to 6 students (e.g. 3 programmers + 2 designers) at the
Vienna students' projects.
- o -
And finally some more project ideas:
a) cleanup input modules: IIRC there was some discussion about
reducing the number of input modules in favor of one that uses an expression
language that works on a well-defined object model.
b) cleanup expression language usage throughout Cocoon
Daniel, do you have any pointers?
c) provide an alternative continuations manager that can work with
distributed caches
d) refactor <map:call function=""/> and <map:flow>
* make it possible to support more than one flow language per sitemap
* find some better naming than "function" because it feels strange to
call e.g. an Apple or a JavaFlow
e) Cocon Javaflow 1.0 + integration with the reloading classloader stuff:
--> whatever needs to be done to get it stable ;-)
I think that (a + b) or (c + d + e) could be interesting projects.
- o -
Grek, my personal preference for your GSoC project goes towards the c+d+e
project. This needs some involvement by Torsten and, highly recommended, him as
mentor but I don't know whether he wants to take mentorship again.
*My* second choice is the cForms refactorings. Of course you are free to suggest
to us whatever you like :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de