RESTapples
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
GSoC mentorship
Daniel and all other who consider becoming a GSoC mentor,
please read
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators
and self-register for GSoC mentorship. At this phase it doesn't mean that you
*have to* accept any student's project but you have the chance to. Please do
this ASAP so that we are not hit by some overlooked deadline. Thanks!
--
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
Cocoon 2.1.10 jars?
Hello, I couldn't find any Cocoon 2.1.10 jar at http://repo1.maven.org/maven/cocoon/jars/ Am I looking at the wrong place or did someone forget to create them after the release? Regards, Jasha Joachimsthal Hippo Oosteinde 11 1017 WT Amsterdam The Netherlands +31 (0)20 5224466 www.hippo.nl
[ajax] How to add a handler to the BUHandler in a AjaxForm?
Hi, How to add a handler to the BUHandler in AjaxForm? The BUhandler is AjaxFrom is created within the scope of a call object in method _handleBrowserUpdate, so i do not have any way to access it and add a handler to handle the returned result? Should not the BUhandler be a attribute of the AjaxForm? Regards, Rice
RE: [vote] Jeroen Reijn as a new Cocoon committer
I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Didn't want to send in my heavily biased vote during the official round, but still want to share my enthousiasm! Good stuff, Jeroen! -- Arjé
Wrong version in commons-sandbox parent pom?
Hi, Can anyone here update the version number of the parent pom in the following file: http://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbox/pom.xml I think the parent pom's version should be 3-SNAPSHOT (it is 2-SNAPSHOT now). Can anyone here fix this, or do I need to contact people on the commons-dev list myself? Another question: it looks like all commons-sandbox projects should have org.apache.commons:commons-sandbox:pom as their parent pom. But commons-jci has org.apache.commons:commons-parent:2 as a parent. Shouldn't the parent be org.apache.commons:commons-sandbox:pom? (commons-jci builds corrently, and all tests pass btw). Thanks, Bart.
Re: Inactive Cocoon committers and PMC members
Joerg Heinicke wrote: On 14.03.2007 09:27, Ross McDonald wrote: I suppose a list of active committers will prevent people who are no longer active from receiving emails they don't want to receive from those looking for help.. so it may stop dead end investigations? In that way an up-to-date list of committers would be useful... Also perhaps some other information could be tied in.. such as who are the experts on which blocks or areas within Cocoon, so people who are newer to it could find out very quickly where to get help, given that the state of the docs is still somewhat patchy. This would save a lengthy exploration of the mailing lists, and get names up in obvious public view (such as on our soon to be released new website :-) ). Independent from the counter argument already given the Cocoon changes site [1] already gives this information in a more verbose way. Nobody needs to maintain this list explicitely and nobody might get the feeling that private mails are encouraged. Jörg [1] http://cocoon.apache.org/2.1/changes.html That's not more verbose, it also provides a simple list of contributors to a specific version and contributors to prrevious versions (see the end of the document). However, this only credits people who have an entry in status.xml, so does not credit people who have done other work, such as user support, dev discussion, issue tracking etc. Of course, status.xml could be used to record important events outside of the code base too. For example, an important design discussion could be recorded in status.xml with a link to the mail archives for reference. The onus is then on the people involved with the discussion to ensure that the details are recorded, otherwise they don't get credited with participation. An alternative would be to extract activity details from mailing list archives, issue tracker logs etc. But that all sounds like extra work to me. Ross
Re: Code metrics
Joerg Heinicke skrev: On 15.03.2007 23:50, Daniel Fagerstrom wrote: Code metrics for Cocoon: http://www.ohloh.net/projects/4271 Remarkable: Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity. This is probably good sign that interest in this project is rising, and that the open source community has embraced this project. Does it provide more than commit statistics and LOC? I would guess that the above text is based on commit statistics and LOC. And we have done a lot of refactoring the last year which create large amounts of commited lines. What I found alittle bit more interesting is: Factoid: Very large, active development team Over the past twelve months, 31 developers http://www.ohloh.net/projects/4271/contributors contributed new code to Cocoon (Apache) http://www.ohloh.net/projects/4271. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 62 developers have contributed. Which is better than I would have guessed. /Daniel
Re: RESTapples
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: [vote result] Jeroen Reijn as a new Cocoon committer
Grzegorz Kossakowski wrote: Jeroen Reijn napisał(a): Hi all, I finally found some time last night to write my introduction. I've been around europe lately, so I was in and out of the office. I was extremely surprised by Andrews nomination (thanks Andrew) and by all the trust I got back from all comitters. Congratulations again and welcome! :) Thanks! :-) At the end of 2003 I tried to help out on the userlist a bit with the little knowledge I had about Cocoon. (Thanks for spotting that Joerg!) In the meantime I've worked with a lot of Cocoon blocks and I'm really looking forward to working with Cocoon 2.2. Over the years I also noticed that Cocoon needs so much more documentation, so that will be one of my focus points. Cocoon 2.2 is going to be the next big thing, so I will try to help out with that as well. You have now ally in fight with bad, lacking, obscure documentation. Just after finishing forms and ajax refactorings I'm going to describe servlet service, and write detailed tutorial explaining how to build something more than a Hello world. I hope you can offer something even better. ;-) I do hope so too! Jeroen
Re: RESTapples
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: [graphics] New masthead version - final5
Peter Hunsberger wrote: On 3/12/07, hepabolu [EMAIL PROTECTED] wrote: Guys, Thien and I have discussed the LF of the breadcrumb trail and turned it to a more bluish color. Thien has also made the colors of the masthead stronger. Check it out: http://people.apache.org/~hepabolu/final5.html I like the darker blocks, but I think the slightly lighter background of the previous version might be better, in particular where it fades up against the breadcrumb trail background. Alternately, maybe the breadcrumb trail background can be just a bit darker; at the moment it blends in a lot with the other background. Yes I think I agree on the blending part, but I think this new version is great! All the subtle small changes make it a lot better and I see that those small IE 6 bugs were fixed now as well. Sheesh, sounds like I'm being very picky. You can ignore all of this if you'd like... Well I think that even though it sounds picky It only shows that this is something you care about, so nobody will have a problem with that. :-) Jeroen Reijn
Re: Code metrics
Daniel Fagerstrom napisał(a): I would guess that the above text is based on commit statistics and LOC. And we have done a lot of refactoring the last year which create large amounts of commited lines. What I found alittle bit more interesting is: Factoid: Very large, active development team Over the past twelve months, 31 developers http://www.ohloh.net/projects/4271/contributors contributed new code to Cocoon (Apache) http://www.ohloh.net/projects/4271. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 62 developers have contributed. Which is better than I would have guessed. Nice report :-) Yes, it's a lot of good buzz about us and I think we should consider using them in some kind of marketing along with new website, release of 2.2 etc. http://www.ohloh.net/projects/4271/badge.gif - even having this button on the main page would be great. -- Grzegorz Kossakowski
Re: RESTapples
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
Re: GSoC mentorship
Reinhard Poetz skrev: Daniel and all other who consider becoming a GSoC mentor, please read http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators and self-register for GSoC mentorship. At this phase it doesn't mean that you *have to* accept any student's project but you have the chance to. Please do this ASAP so that we are not hit by some overlooked deadline. Thanks! Done! /Daniel
Re: [GT2007] It's that time of the year again...
Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1 But you maybe expect some more substantial feedback ;) /Daniel
Re: [GT2007] It's that time of the year again...
Daniel Fagerstrom wrote:
Arje Cahn skrev:
Hi all,
(quoting Joerg quoting the Cocoon analysis report that Daniel found:)
Over the last twelve months, Cocoon (Apache) has seen a substantial
increase in activity...
Good news!
What about a Cocoon GetTogether 2007?
+1
+1 from me too!!! I think there will be a lot that we want to show to the
community!
--
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
change file maintenance, Re: svn commit: r518990 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src: changes/changes.xml main/java/org/apache/cocoon/generation/ExceptionGenerator.j
[EMAIL PROTECTED] wrote: document body -release version=1.0.0-M1-SNAPSHOT date=2007-00-00 description=unreleased +release version=1.0.0-RC1-SNAPSHOT date=TBA description=Unreleased +/release +release version=1.0.0-M1 date=2007-02-12 description=Milestone release Shouldn't / can't this be done by the release process? I'd go one step further and suggest that current tag on this module is bad since tagged changes had incorrect version and release date, which would lead to incorrect website pages generated for the module. At the very least, this has to be done before tagging. Right now I had to hunt for release date using 'svn log', and I'm sure I easily could make a mistake here. Vadim
Re: Code metrics
Grzegorz Kossakowski wrote: http://www.ohloh.net/projects/4271/badge.gif - even having this button on the main page would be great. I just corrected the project name but badge does not reflect this yet. Vadim
[GT2007] It's that time of the year again...
Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? Kind regards, Met vriendelijke groet, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 [EMAIL PROTECTED] / [EMAIL PROTECTED] -- Hippo http://www.hippo.nl Hippo CMS community http://www.hippocms.org My weblog http://blogs.hippo.nl/arje --
Re: change file maintenance, Re: svn commit: r518990 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src: changes/changes.xml main/java/org/apache/cocoon/generation/ExceptionGenerat
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
document
body
-release version=1.0.0-M1-SNAPSHOT date=2007-00-00
description=unreleased
+release version=1.0.0-RC1-SNAPSHOT date=TBA
description=Unreleased
+/release
+release version=1.0.0-M1 date=2007-02-12
description=Milestone release
Shouldn't / can't this be done by the release process?
that would be great but I don't think that there is support for this
I'd go one step further and suggest that current tag on this module is
bad since tagged changes had incorrect version and release date, which
would lead to incorrect website pages generated for the module.
At the very least, this has to be done before tagging. Right now I had
to hunt for release date using 'svn log', and I'm sure I easily could
make a mistake here.
agreed but I don't know of anything better than using the changes plugin :-(
--
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: change file maintenance, Re: svn commit: r518990 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src: changes/changes.xml main/java/org/apache/cocoon/generation/ExceptionGenerat
Reinhard Poetz wrote: agreed but I don't know of anything better than using the changes plugin :-( Sounds like the only current option is to do this manually. :( Do you already have a 'how to release cocoon 2.2' document similar to CocoonReleaseHowTo [1]? Vadim [1] http://wiki.apache.org/cocoon/CocoonReleaseHowTo
Re: change file maintenance, Re: svn commit: r518990 - in /cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src: changes/changes.xml main/java/org/apache/cocoon/generation/ExceptionGenerat
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
agreed but I don't know of anything better than using the changes
plugin :-(
Sounds like the only current option is to do this manually. :(
Do you already have a 'how to release cocoon 2.2' document similar to
CocoonReleaseHowTo [1]?
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1199.html
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [GT2007] It's that time of the year again...
On 3/16/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Reloading the mountableServlets map in DispatcherServlet
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Gosh, I have bad news :(
It does not work for me, when I change something in the class I see this
printed on console:
2007-03-14 13:34:32.657:/:INFO: Closing Spring root
WebApplicationContext
2007-03-14 13:34:32.658:/:INFO: Loading Spring root
WebApplicationContext
2007-03-14 13:34:33.043:/:INFO: Apache Cocoon Spring Configurator
v1.0.0 is running in mode 'dev'.
But changes are not visible after refreshing the page. Am I missing
something?
PS. I did svn up both for cocoon-rcl and commons-jci.
Have you update cocoon-servlet-service-* too and run cocoon-rcl:webapp
form your block's base directory?
If yes or if it reloading still doesn't work for you, please activate
logging in log4j.xml by uncommenting the two existing logging categories
(jci, rcl) and setting them to DEBUG.
Then (re)start Jetty and call http://localhost:, change
MyGenerator.java, wait 3 seconds, do a page reload again and send the
log file to me directly.
Another cause might be that I had to comment the rcl modules in
trunk/tools/pom.xml in order not to break the build for everybody. In the case
that you haven't changed this yourself for you own build, you won't get new
artifacts installed.
If I have some time this weekend, I will provide a snapshot release and put it
on a public Maven repo. Otherwise go to cocoon-rcl-wrapper and cocoon-rcl-plugin
base dirs and install both modules from there.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Reloading the mountableServlets map in DispatcherServlet
Reinhard Poetz napisał(a): Another cause might be that I had to comment the rcl modules in trunk/tools/pom.xml in order not to break the build for everybody. In the case that you haven't changed this yourself for you own build, you won't get new artifacts installed. If I have some time this weekend, I will provide a snapshot release and put it on a public Maven repo. Otherwise go to cocoon-rcl-wrapper and cocoon-rcl-plugin base dirs and install both modules from there. Oups... There is a little problem with providing necessary information because I have no access to my computer during this weekend. However I'll try to set up everything on the computer I'm writing this mail from and reproduce this problem. If wasn't able to do this I'll give you all data on Monday. -- Grzegorz Kossakowski
Re: XHTML Serializer block/Ajax: Bug
(moving to dev list) On 16.03.2007 14:58, Jason Johnston wrote: Another option might be to wrap the contents of script elements within a CDATA section so the JS could remain unencoded but it would still result in well-formed XML. I'm not sure how some browsers would handle the CDATA delimiters so they might have to be commented out so they're not mistaken for script code: script type=text/javascript/*![CDATA[*/ while(0 1 true) alert(oops); /*]]*//script Actually I don't like it. From an XML POV the above and the current solution are absolutely equal. What we are going to do with such a fix is to fix awkward browser behaviour or even wrong document contents. I understand what you're saying; it definitely creates uglier content. But in terms of fixing browser behavior, we actually already have logic in place that does just that by preventing collapsing of script / tags. From an XML point of view script/ and script/script are also equal, but we force the latter simply because browsers handle it better. I don't see this situation as any different. To be honest I'm quite intolerant in this regard: I would even remove this code. It's an all or nothing decision - where you probably can't reach all. What's actually happening? People want to use XHTML because it's cool, in or state of the art, but they have to support browsers that don't handle XHTML correctly or they break it themselves by not providing the XHTML correctly and forcing the browsers into the quirks mode. Then we get 20 bug reports for 10 issues in special cases because not all quirks have been addressed yet. And we complicate our code base more and more. Just have a look at XHTMLSerializer commits [1]: special tags handling, omit-xml-declaration and now the not-to-be-escaped characters. And what for at the end? That something formerly known as XHTML can be understood by the browsers in quirks mode and gets parsed as tag soup again. But why not staying with HTML then??? Why is the XHTMLSerializer be used in those cases? IMO we should NOT implement any special case handling in XHTMLSerializer but tell the people to use the HTMLSerializer. Jörg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
Re: XHTML Serializer block/Ajax: Bug
Joerg Heinicke napisał(a): (moving to dev list) To be honest I'm quite intolerant in this regard: I would even remove this code. It's an all or nothing decision - where you probably can't reach all. What's actually happening? People want to use XHTML because it's cool, in or state of the art, but they have to support browsers that don't handle XHTML correctly or they break it themselves by not providing the XHTML correctly and forcing the browsers into the quirks mode. Then we get 20 bug reports for 10 issues in special cases because not all quirks have been addressed yet. And we complicate our code base more and more. Just have a look at XHTMLSerializer commits [1]: special tags handling, omit-xml-declaration and now the not-to-be-escaped characters. And what for at the end? That something formerly known as XHTML can be understood by the browsers in quirks mode and gets parsed as tag soup again. But why not staying with HTML then??? Why is the XHTMLSerializer be used in those cases? IMO we should NOT implement any special case handling in XHTMLSerializer but tell the people to use the HTMLSerializer. I agree with you, Joerg, on all you said. Moreover, I wonder why we need special XHTMLSerializer? As XHTML is only XML with special namespace and tag set why we don't use just normal xml serializer and configure proper mime type? Do I miss something important? -- Grzegorz Kossakowski
Re: GSoC
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
Re: GSoC
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-devm=110963086900150w=2, http://marc.theaimsgroup.com/?t=11059582971r=1w=2, http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109941971317696w=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: XHTML Serializer block/Ajax: Bug
On 16.03.2007 21:52, Grzegorz Kossakowski wrote: Moreover, I wonder why we need special XHTMLSerializer? As XHTML is only XML with special namespace and tag set why we don't use just normal xml serializer and configure proper mime type? Do I miss something important? If you have a look into the source code [1] you can see that it handles (besides the stuff fixing the tag soup) doc type, mime type and has same special XHTMLEncoder [2], which adds the HTML 4 entities. So far absolutely ok. It puts every element in no namespace into the XHTML namespace. Still acceptable, but abdicable - it's for the lazy guys. Also the meta tag for content type it adds should be abdicable. AFAIR it's also only for IE as it stumbles on the XML declaration. But at the end it should not do more than this. Joerg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java?revision=433543view=markup [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/encoding/XHTMLEncoder.java?revision=433543view=markup
Re: [GT2007] It's that time of the year again...
On 16.03.2007, at 16:38, Gianugo Rabellino wrote: On 3/16/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon Italy!! :-D
Re: Inactive Cocoon committers and PMC members
On 16.03.2007 11:54, Ross Gardler wrote: Also perhaps some other information could be tied in.. such as who are the experts on which blocks or areas within Cocoon Independent from the counter argument already given the Cocoon changes site [1] already gives this information in a more verbose way. Nobody needs to maintain this list explicitely and nobody might get the feeling that private mails are encouraged. That's not more verbose, it also provides a simple list of contributors to a specific version and contributors to prrevious versions (see the end of the document). However, this only credits people who have an entry in status.xml, so does not credit people who have done other work, such as user support, dev discussion, issue tracking etc. My comment was not about giving any credits, it was just about assigning people to code and getting contact to experts on specific code areas (what Ross McDonald aimed to). While having this information explicitely was discouraged I said it is already there - implicitely and more verbose. Jörg
