[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (107 issues) Subscriber: cocoon Key Summary COCOON-2250 Wrong error message in Element.java (jx:element) https://issues.apache.org/jira/browse/COCOON-2250 COCOON-2249 XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors https://issues.apache.org/jira/browse/COCOON-2249 COCOON-2246 HttpRequest should handle encoding in getParameter and getParameterValues in the same way https://issues.apache.org/jira/browse/COCOON-2246 COCOON-2233 Update archetypes to current trunk artifact versions https://issues.apache.org/jira/browse/COCOON-2233 COCOON- Add SaxParser configuration properties https://issues.apache.org/jira/browse/COCOON- COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the servlet protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable
Re: [C3] Sitemap implemented in Scala
On 05.03.2009 00:33, Grzegorz Kossakowski wrote: Now I'll give a few words of comments why I find my implementation easier to follow. First of all, sitemap processing is divided into a few distinct stages: 1. Sitemap parsing 2. Sitemap reduction 3. Sitemap invocation 3.1 Actions execution 3.2 Pipeline building 3.3 Pipeline execution 3.4 Catching possible exception 4. If exception catched, reduction of handle errors node 5. Handling exception with reduction result What's more, for most of the time code is based on immutable structures which is the biggest advantage. What I found hard with current implementation hard is InvocationImpl passed around that quite a lot of state. If you combine it with InvocationResult switches (cases) that every node has to return in its invoke() method the result isn't really appealing. This sort of resembles mistakes from C2.x where big, mutable objects were passed around leading to unmaintainable code. I'm interested in hearing your opinions on that subject. I know that's rather hard to judge rather big piece of code in unfamiliar language but I'm sure you can easily get some overall feeling about my implementation and ideas behind it. I don't have the time to actually look into your implementation. I'm just wondering if all the insight views couldn't be used to improve the Java implementation rather than starting something in a different language. Joerg
Re: [C3] Sitemap implemented in Scala
Joerg Heinicke pisze:
I don't have the time to actually look into your implementation. I'm
just wondering if all the insight views couldn't be used to improve the
Java implementation rather than starting something in a different language.
It could.
What I'm doing at the moment is sort of wild experimentation that I don't know
where will lead me to. I'm reimplementing
sitemap in Scala because I thought that sitemap processing is something
complicated enough to get a real feel of
programming in Scala.
It's true that anything I write in Scala could be emulated in Java but when I
think about it I feel rather overwhelmed
by the possible verbosity of Java counterparts to Scala constructs. In my
implementation I exploit heavily strong typing
by defining lots of types and using lots of generics. I use closures and
pattern matching quite a lot.
Compare (Scala):
private def filterUnprefixedSimpleAttributes(attributes : MetaData) :
Map[String, String] =
Map() ++ attributes.flatMap(attr = attr match {
case ua : UnprefixedAttribute = List(ua.key -
ua.value.first.toString)
case _ = Nil
})
to translation of it (Java):
private MapString, String filterUnprefixedSimpleAttributes(MetaData
attributes) = {
return (new MapString, String()).putAll(attributes.flatMap(
new Function1MetaData, ListTuple2String, String() {
ListTuple2String, String apply(MetaData x) {
if (x istanceof UnprefixedAttribute) {
UnprefixedAttribute ua = (UnprefixedAttribute) x;
return new ListTuple2String, String().add(
new Tuple2String, String(ua.key(),
ua.value().first().toString()));
} else {
return new ListTuple2String, String();
}
})
}
And no, I didn't take the most complicated example from my code because I don't
it find funny to write such a spaghetti
code.
So certainly I could write the same in Java but I honestly believe that in Java
operating on strongly typed, immutable
collections is NOT fun and that's the reason nobody seems to do.
And if you skim through my code you'll find that it's more or less only about
mapping, reducing and filtering strongly
typed collections.
Still example above does not prove anything general (like Java sucks, let's do
it in Scala) but my reimplementation of
sitemap processing should provide a nice background for a discussion what we
want to see in C3.
For example, I'm interested in answering questions like if we are going to
introduce any other language apart from Java
in C3. Traditionally Cocoon had other languages integrated for years
(Javascript comes to mind) so it's rather natural
to ask this question. If answer was positive (based on some evaluation) another
question that pops up is why it can't be
Scala?
WARNING: Here follows some thoughts on personal experience with Scala that you
my safely ignore as they are rather
off-topic.
Might be that I'm extrapolating but my sitemap reimplementation in Scala did
work just after I finished all necessary
bits. I mean: I have written all the processing, integrated it into servlet so
it could work with the rest of C3 and it
did work just immediately. I didn't have any test-cases and I didn't run my
code while writing it.
After extensive testing with all samples C3 provides I found exactly one bug[1]
in that code. Of course, this does not
mean I don't have any other bugs but the probability that I have many of them
is really small.
Does Scala make me magically not making any mistakes? Certainly not. It only
informs me about them at the time of
writing code by reporting compilation errors.
This experience convinced me to have following standpoint:
If we are going to introduce any secondary language in Cocoon,
I would really prefer if it was strongly typed one.
Oh, and if you wonder how on the hell I could be typing non-trivial stuff for
more than one day without introducing
almost any bugs. It might be because my code cotains 5 if statements, no
return, break or continue statements and only a
few raw loops (like while, for or repeat). I believe that's the reason...
And yes, I have to admit that sitemap processing is somehow special case where
the power of concepts I've used simply
shines.
[1]
http://github.com/gkossakowski/apache-cocoon3/commit/845f7b61861827a17fb017625eb7f2281ac458df
--
Best regards,
Grzegorz Kossakowski
